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

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

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

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

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

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

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

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

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

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


Понравилась статья? Поделитесь с друзьями!


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

  1. Lite:

    Склонен не согласиться. Требуется N-арное отношение, которое RDF напрямую не поддерживает. Единственный способ — объявить сам триплет субъектом с тремя свойствами (hasSubject, hasPredicate, hasObject) и навесить на него свойства авторства (DC проще всего, конечно). Наглядный пример, когда Topic Maps были бы элегантнее. 😉

  2. DC конечно проще, но с другой стороны DC работает на уровне, где свойство принадлежности информации к автору например будет распространятся на все описываемые объектны предметной области, а любое n-арное отношение или любая другая пользовательская конструкция будет все равно работать только на пользовательском уровне (уровне где пользователь определяет свои классы).
    Я не зря упомянул, о смысловом соответствии моделей DC и RDF ( по правилам онтологий).

    А как вы переопределите содержимое базового класса (корневого класса типа Thing) , по сути как изменить основу описываемого вами мира или его фрагмента (ПрО)?
    Topic Maps элегантнее ,наверное, но расширяемость RDF средство это «что-то»! ))

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


Ответить с помощью ВКонтакте: