Непосредственно в запросе ты указываешь графовый шаблон поиска, т.е. ты определяешь какую часть существующего графа ты хочешь получить. Другой вопрос что это за граф. Это может быть обычный граф c RDF данными, либо граф с RDF данными + выведенные новые данные из OWL. Непосредственно в языке запросов SPARQL нельзя указать, использовать ли при поиске вывод над OWL или нет. Но это возможно если предоставить две точки доступа SPARQL – одна с поддержкой OWL, другая нет. Или предусмотерть включение вывода над OWL отдельным параметров, дополнительно к SPARQL pапросу.

Я ответил на вопрос и как обсуждаемая тема касается проекта semap?

И. – пользовательские истории.
Р. – рассуждения.

И.1. Мы должны иметь персонализированное хранилище (для чего, объясним позже). В нашем хранилище мы хотим накапливать и иметь постоянный доступ к следующей информации:
- об объектах, событиях и т.п. реального мира (далее называем просто объекты),
- о файлах и папках (далее называем просто объекты),
- об объектах и утверждениях в нашем хранилище (далее называем просто объекты),
- и т.п.

И.2. Какую информацию мы прежде всего хотим накапливать и иметь к ней доступ?
1. Мы хотим знать характеристики объектов реального мира (то же относится к файлам), заметки о них.
2. Мы хотим знать о связях объектов с другими объектами.
3. Наши метаданные должны идентифицировать объекты так, чтобы данные об одном объекте из разных источников были сопоставимы, состыковывались в одно целое.
4. Наши метаданные должны идентифицировать объекты так, чтобы мы могли найти эти объекты в том «мире», в котором они существуют (если это объект реального мира – прийти к нему и посмотреть, если человек – связаться с ним, если книга – найти её в магазине, если файл – найти его в сети и т.п.).

Р.1. Требования 3 и 4 пользовательской истории И.2. достижимы, если идентифицировать объекты их местоположением в том «мире», в котором они существуют. Например, географическими координатами, URL, ISBN и т.д. Проблемы такого подхода в том, что в силу условности и многочисленности «миров» в которых существуют объекты невозможно избежать модельных приближений:
Пример 1. Интернет пользователя можно идентифицировать по email, icq и т.п. Не следует забывать, что всё это приближения. Если человек не пользуется интернетом, то его можно идентифицировать по паспорту, в качестве объекта из «мира государство Россия» и т.п.
Пример 2. Книгу можно идентифицировать по ISBN, можно различать каждый бумажный экземпляр книги по инвентарному номеру, можно идентифицировать электронную версию книги по URL её местонахождения, можно по контрольной сумме файла (как в осле), и т.п.
Как же идентифицировать правильно? Эти вопросы должны решаться не данной системой, а на этапе разработки онтологий. Возможно, они и будут решены в общем виде в будущем.

Р.2. Для удовлетворения всех требований пользовательской истории И.2. в качестве универсального формата нас устроит Dublin Core. Кроме того должна быть возможность предоставления этих метаданных в другом универсальном формате, либо формате специфичном для соответствующего типа объекта.

Р.3. Где эта информация, описанная в И.2. будет содержаться? Храниться распределённо или у нас в хранилище, или ещё где? Это зависит от критичности наших требований к доступности хранилища, чтобы мы могли беспрепятственно добавлять свою информацию и читать всю накопленную нами ранее.

И.3. Допустим, в нашем хранилище содержится лишь часть информации о каком либо объекте. А в других хранилищах содержится дополнительная информация об этом же объекте. Мы должны иметь возможность составив запрос на получение информации увидеть полную информацию об этом объекте, с указанием из каких хранилищь она получена. Мы должны иметь возможность подключать, и наоборот, исключать другие хранилища в качестве наших источников информации. Файлы с метаданными стоит рассматривать не как отдельную сущность, а как вид источника информации, наряду с хранилищами.

И.4. Информация из других источников информации не должна копироваться в наше хранилище без нашего разрешения. Но с нашего разрешения мы должны иметь возможность скопировать информацию в наше хранилище.

Да, я хочу Semap

С этой идеей я давно хожу, но, к сожалению, четкой картины в голове все-равно не имею ;( Давно собирался подробнее рассказать о задумке semap, но есть масса нерешенных задач, рад что появляются единомышленники.

Конечно связывайся, буду рад. С командой хуже всего, но благодаря открытой разработке я и хотел найти заинтересованных людей. Планировал разработку по лицензии Apache, так как закрытая разработка, как мне кажется, менее выгодна стратегически. По этому поводу у меня есть ряд мыслей. Никак не опубликую статью про бизнес модель Open Source, давно уже собираюсь, все некогда.

Но меня интересуют не только вопросы, чисто технические, но и организационные. Твой проект задумывается как исследовательский, или коммерческий? Есть ли уже команда разработчиков? И т.д. и т.п.

Если не возражаешь я попытаюсь связаться с тобой в понедельник по аське.

-Михаил