Блуждая по Хабрахабру, наткнулся на пост, в котором авторы рассуждали на тему, как добавить информацию об авторе триплета в RDF. Идея проста - RDF представляет собой совокупность триплетов, но эти триплеты могут быть добавлены различными авторами. Вопрос: Как добавить информацию об авторе триплета. Как авторы правильно заметили, если информацию об авторе вынести в отдельное хранилище или таблицу, то проблем нет. Но что, делать, если не хочется привлекать сторонние средства? Одним из вариантов было предложено ввести свойство «hasAuthor» в корень объектной иерархии.
Но этот подход имеет свои недостатки. Представьте себе, некоторый объект, например, ягода вишня. Что у нас получается -«вишня» как экземляр класса Ягода, у которой автор Вася Пупкин - как то глупо звучит. И вообщем-то и не в Васе дело, а в том, что автор ягоды вишни Вася. Если мое рассуждение верно, тогда вынос hasAuthor в корень объектной иерархии ничего не дает, так как всегда будут существовать объекты для которых отношение hasAuthor не будет иметь смысла.
Хотя, например, в редакторе онтологий Protege есть наборы служебных классов, выполняющие подобные функции, которые не отображаются в основном дереве представления RDF
А решение задачи, как оказалось в результате моих рассуждений на Хабрахабре, очень простое.
В RDF нет языковых конструкций для установления авторства триплетов, но такие средства есть в Dublin Core.
Таким образом, рассматривая Dublin Core, как расширение RDF, мы можем легко ввести понятие авторства информации (триплета).
Вы можете сказать, а чем же отличается введение понятия авторства через Dublin Core от введения нового отношения hasAuthor?
А все просто - когда мы вводим новое отношение hasAuthor мы имеем ягоду вишню автора Васи, а при использовании дублинского ядра мы такого не имеем, как минимум потому, что у описания Dublin Core другое пространство имен и как результат описание некоторого объекта через Dublin core идет как описание объекта в некоторой другой семантической плоскости. А самое интересное - при проведении логического вывода мы не нарушим ни одного канона онтологий - ягоды будут успешно собраны и проданы потенциальному клиенту, а агенты будут также иметь возможность взглянуть на автора информации.
А может я не прав?
2 комментария к этой записи
Оставить комментарий
Склонен не согласиться. Требуется N-арное отношение, которое RDF напрямую не поддерживает. Единственный способ – объявить сам триплет субъектом с тремя свойствами (hasSubject, hasPredicate, hasObject) и навесить на него свойства авторства (DC проще всего, конечно). Наглядный пример, когда Topic Maps были бы элегантнее.
DC конечно проще, но с другой стороны DC работает на уровне, где свойство принадлежности информации к автору например будет распространятся на все описываемые объектны предметной области, а любое n-арное отношение или любая другая пользовательская конструкция будет все равно работать только на пользовательском уровне (уровне где пользователь определяет свои классы).
Я не зря упомянул, о смысловом соответствии моделей DC и RDF ( по правилам онтологий).
А как вы переопределите содержимое базового класса (корневого класса типа Thing) , по сути как изменить основу описываемого вами мира или его фрагмента (ПрО)?
Topic Maps элегантнее ,наверное, но расширяемость RDF средство это «что-то»! ))