Служебная информация в RDF

Блуждая по Хабрахабру, наткнулся на пост, в котором авторы рассуждали на тему, как добавить информацию об авторе триплета в RDF. Идея проста - RDF представляет собой совокупность триплетов, но эти триплеты могут быть добавлены различными авторами. Вопрос: Как добавить информацию об авторе триплета. Как авторы правильно заметили, если информацию об авторе вынести в отдельное хранилище или таблицу, то проблем нет. Но что, делать, если не хочется привлекать сторонние средства? Одним из вариантов было предложено ввести свойство «hasAuthor» в корень объектной иерархии.

Но этот подход имеет свои недостатки. Представьте себе, некоторый объект, например, ягода вишня. Что у нас получается -«вишня» как экземляр класса Ягода, у которой автор Вася Пупкин - как то глупо звучит. И вообщем-то и не в Васе дело, а в том, что автор ягоды вишни Вася. Если мое рассуждение верно, тогда вынос hasAuthor в корень объектной иерархии ничего не дает, так как всегда будут существовать объекты для которых отношение hasAuthor не будет иметь смысла.

Хотя, например, в редакторе онтологий Protege есть наборы служебных классов, выполняющие подобные функции, которые не отображаются в основном дереве представления RDF

А решение задачи, как оказалось в результате моих рассуждений на Хабрахабре, очень простое.

В RDF нет языковых конструкций для установления авторства триплетов, но такие средства есть в Dublin Core.

Таким образом, рассматривая Dublin Core, как расширение RDF, мы можем легко ввести понятие авторства информации (триплета).

Вы можете сказать, а чем же отличается введение понятия авторства через Dublin Core от введения нового отношения hasAuthor?

А все просто - когда мы вводим новое отношение hasAuthor мы имеем ягоду вишню автора Васи, а при использовании дублинского ядра мы такого не имеем, как минимум потому, что у описания Dublin Core другое пространство имен и как результат описание некоторого объекта через Dublin core идет как описание объекта в некоторой другой семантической плоскости. А самое интересное - при проведении логического вывода мы не нарушим ни одного канона онтологий - ягоды будут успешно собраны и проданы потенциальному клиенту, а агенты будут также иметь возможность взглянуть на автора информации.

А может я не прав?

Работа посвящена вопросам анализа нечетких онтологий и их применению.

Shcherbak says: Это интересно и познавательно! Читаем ))

Интеллектуальная интеграция информации

Не коротко и ясно здесь ))

Owlgres – масштабируемый OWL2 DL-Lite Reasoner

Для обработки онтологий в стандарте OWL 2 можно использовать reasoner Owlgres.  Кстати, reasoner - это подсистема логического вывода; OWL 2 - следующая версия Web Ontology Language.

Чем Owlgres хорош? Во-первых, это опенсорсный продукт (а учитывая то, что он распространяется и по коммерческой лицензии,  есть вероятность, что проект быстро не погибнет). Во-вторых, в Owlgres поддерживается высокоскоростной логический вывод на основе дескриптивной логики. Высокая скорость поддерживается за счет реализации Owlgres поверх реляционной СУБД PostgreSQL.

Кстати, идея реализации онтологий на OWL (или других языках) поверх реляционных баз данных не нова. Вы уже слышали, на страницах моего сайта о Oracle Spatial... Кроме того, это оказывается и не так уже и сложно, когда есть математическая модель онтологий и навыки проектирования реляционных баз данных. Сложность скорее в той рутинной работе, которую нужно сделать, чтобы учесть все ньюансы OWL и LBASE.

В качестве языка запросов к онтологии OWL в Owlgres используется SPARQL-DL.

И, напоследок, уже доступна альфа-версия Owlgres, которую можно использовать как Sparql-точку доступа для создания, например, "умных" сайтов или web-сервисов.

PS. Помниться был еще один подобный проект по хранению онтологий в  Postgress (правда академический), но о нем уже года полтора ничего не слышно, а жаль - можно было бы сравнить, например, производительность.  И лицензия для использования была там получше ))

Если у вас есть информация о подобных проектах, пишите в коментариях ))