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

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

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

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

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

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

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

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

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

Ответ на это прост, если не учитывать проблемы, которые я освещал в одном из предыдущим постов.

Cначала давайте определимся, что будем понимать под приложением Semantic Web.

Итак, если приложение построено с использованием таких средств Semantic Web, как XML,  RDF, OWL, SPARQL, то такое приложение будем называть приложением Semantic Web первого типа.

В случае, если приложение реализует идеи Semantic Web, как концепции,  тогда такое приложение назовем приложением Semantic Web второго типа.
Читать продолжение »

Или что проиcходит когда технологии Web 2.0 объединить с Semantic Web...

Широкое развитие технологий Web 2.0 и социальных сетей привело к созданию новой концепции - Социальный Семантический Веб (Social Semantic Web).

Социальный Семантический Веб - это развитие концепции Semantic Web, в рамках которой социальные взаимодействия в Web можно использовать для создания семантически богатых (semantically rich) представлений знаний

К слову, семантически богатые знания (semantically rich knowledge) - это наиболее простая форма представления "поверхностных" знаний об объектах или процессах реального мира.
Читать продолжение »

Онтология – явная спецификация знаний о предметной области (Грубер). Знания в онтологии могут быть выражены с помощью логик 1-го (или n-го) порядка или в терминах свойство-центричной модели представления знаний.

Логики в онтологиях реализованы с помощью языка LBASE.

LBASE определяет формальные семантики для языков Semantic Web.

Наиболее популярным языком представления онтологий, основанном на LBASE, является OWL (Язык веб-онтологий).

Логики дают возможность выражать в онтологиях практически все, что связано с материальным миром. Ценой таких широких выразительных возможностей является низкая скорость автоматической обработки инструкций онтологий, а иногда и невозможность проведения логического вывода за конечное время. Т.е. Возможна ситуация, когда послав запрос к web-сервису, использующего онтологию, Вы не получите на него ответ за приемлемое для Вас время.

Ускорение работы и логический вывод за конечное время можно получить используя свойство-центричность онтологий.

Свойство-центричность онтологии выражается в том, что объекты предметной области и свойства описываются отдельно, при этом свойства описываются в терминах объектов, к которым они применимы, путем указания области применения свойства (domain) и области значений свойства (range).

В рамках свойство-центричной модели представления знаний объединяются выразительные возможности объектно-ориентированного подхода с возможностями хранения распределенных по Web знаний, что позволяет разрабатывать высокоэффективные web-сервисы, скорость обработки которых сравнима с объектными CУБД.

Редактор онтологий Protege позволяет выбирать на основе какого подхода Вы будете создавать онтологии, т.е. Вы выбираете «Logic View», если используете логики, и «Property Centric View» при использовании свойство-центричной модели представления знаний.

Читать продолжение »

Из моего раннего творчества об анализе информации на основе онтологии --

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

Читать далее