Ув.  читатели  сайта SHCHERBAK.NET, в переводе стандарта языка SPARQL исправден ряд ошибок как синтаксических, так и смысловых.

Обязательное обновление!

Кроме того, в переводе по рекомендации Павла Клинова заменен термин «пустая вершина» на «безымянную вершину».

PS. Это не последняя версия перевода, это скорее предпоследний релиз-кандидат перевода. Кроме того, ожидается в ближайшем будущем исправление ошибок и в других моих переводах. Следите за обновлениями!

Ув. читатели SHCHERBAK.NET, вашему вниманию предлагаются материалы статьи «Semantic Web как новая модель информационного пространства Интернет» авторов  Ф.И. Андон, И.Ю. Гришановой и В.А. Резниченко.

В этой статье описаны базовые концепции и архитектура Semantic Web, а также положение дел по разработке данного проекта по состоянию на конец 2007 года. Выделены проблемы, которые стоят перед мировым сообществом для дальнейшего развития Semantic Web.

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

Щербак Сергей: Статья мне очень понравилась и я ее особенно рекомендую тем, кто хочет максимально быстро погрузится в  мир семантического веба (обязательна для прочтения).

От имени читателей SHCHERBAK.NET хочу выразить благодарность  Ирине Гришановой за предоставление материалов интересной статьи!

Данное рассуждение было навеяно комментарием к заметке, посвященной реализации хранилища триплетов, поверх СУБД  Postgress – OWLgress’ у.

Итак, онтологии, например, в представлении Description Logic (DL), и базы данных, например, реляционные(РБД),  представители различных подходов к моделированию, причем

логический подход (DL и др.логики) по определению плохо совместим с РБД, что составляет значительную проблему при отображении элементов логических рассуждений на  РБД и еще большую проблему во время их обработки.

Как можно решить эти проблемы?

По сути, как совместить несовместимое, и, как  это несовместимое эффективно обрабатывать?

Рассмотрим,  объектный подход (классика ООП), как частный случай логического подхода. Сразу становится легче – объектный подход совместим с реляционным намного лучше.  Отображение объектов в  РБД уже реализовано десятком различных способов (это можно увидеть в различных ORM таких как hibernate, toplink и doctrine). Производительность решений на базе ORM  может быть весьма высокой (при правильном проектировании БД почти сравнима с производительностью  «native»   SQL-решений), и, конечно, удобство разработки.

Ну и что, скажете вы. В этом ну и что, есть маленький момент, при котором даже 20% потеря производительности при использовании ORM не важна.

А момент этот заключается в том, что  ORM работает с объектами!

А в основе онтологии лежит объектная иерархия – т.е объекты связанные между собой отношениями

Значит, можно эту иерархию естественным способом развернуть через ORM в РБД.

Но вот проблема объект онтологии это не объект ORM!

Как минимум потому, что свойства объекта ORM описываются внутри определения этого объекта, а свойства объекта онтологии, подключаются к описанию объекта из вне, реализуя принцип свойство-центричности (одной из центральных особеностей  SW как распределенного решения)

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

Но это не проблема для локальных нераспределенных хранилищ триплетов – в этом случае эту разницу можно скрыть

а как это можно сделать?

можно сделать адресацию компонентов онтологии через пространственные координаты как в Oracle Spatial и осуществлять сборку объектов и их экземпляров непосредственно перед обработкой

а можно … (тема одной следующих заметок )

Но это не все…

Свойство-центричность и объектность онтологии это один из нижний уровень семантического веба.

Это Уровень RDF c RDFS.

Я знаю многих умников, кричащих, что RDF с RDFS это отстой. Есть же OWL!

OWL конечно есть. Только анализ многих  OWL онтологий показал, что паттерны моделирования, которые там используются, легко могут быть реализованы стандартными средствами RDFS!

А с другой стороны, мне понравились ряд OWL Full-ориентированных онтологий по содержимому совместимых с OWL Lite (хоть это и спорное мое убеждение). В этом аспекте, мне больше всего нравятся легковесные онтологии на OWL Full… Это же надо, именно для представления легковесных онтологий (чуть ли не для простейших таксономий ) и  был создан OWL Full?!

Действительно важным является то, что на основе RDFS  логический вывод будет крайне примитивным, но зато и более производительным. Таким образом, расширяя современные ORM  средствами поддержки  RDF/RDFS мы по сути создаем Semantic ORM. Далее, необходимо расширить набор отношений, поддерживаемых Semantic ORM до уровня OWL – буду еще на эту тему рассуждать…

PS Вот так и определился перевод какого стандарта будет следующим  – Профили OWL 2.

SPARQL PROTOCOL и SPARQL готовы, как только переведу их из дока  в соответствующую форму  W3C, опубликую.

PPS  Semantic ORM – шаг вперед или два назад? 

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

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

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

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

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

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

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

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

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

Рассуждая на тему онтологий, столкнулся с тем, что Semantic Web при всей своей полезности может уйти с арены намного раньше, чем получит широкое признание и внедрение.

Причем его уход будет связан с введением какого-то нового понятия или бренда, типа Semantic Web 2 или Web 3.0. Естественно, опыт полученный в рамках Semantic Web не будет утрачен и в полной мере будет использоваться в рамках «нового бренда», но вот Semantic Web в том виде который мы знаем (пирог Semantic Web) вряд ли будет существовать. Уже четыре года Semantic Web пытается привлечь к себе внимание, а результаты с учетом глобальности Web не очень то и большие.

Read the rest of this entry »

Плагин называется ARC 2 WordPress Extension («RDF Tools») и может быть скачан отсюда – http://arc.semsol.org/download

Этот плагин добавляет хранилище триплетов RDF (RDF Store) с функциональностью SPARQL в блог WordPress.

Read the rest of this entry »

Здесь вы можете задавать  вопросы по  Semantic Web и связанным технологиям и средствам.

Мы по мере возможности будем на них отвечать ))

Наиболее интересные вопросы будут рассмотрены и ответы на них будут опубликованы в виде заметок на сайте ))

Вопрос 1:

Где взять онтологии для использования в своих проектах?

Ответ:

Вы можете использовать открытую онтологию OpenCyc (весьма легко интегрируется с Jade).

Кроме того, доступны для скачивания онтологии на DBpedia и protege.stanford.edu.

каким образом можно использовать настраиваемый интерфейс Protege для графовой модели памяти? т.е. как бы подменить используемую в Protege фреймовую модель на графовую.
где можно об этом почитать?

Ответ:

Подменять не нужно, просто надо выбрать какую использовать версию редактора Protege – Protege-Frames или Protege-OWL.

Графовый (Protege-OWL) описан здесь

Protege-Frames описан здесь. Этот Protege использует протокол Open Knowledge Base Connectivity. что это почитать можно на ontolib.com в глоссарии и ссылки получить можно там же.

В каких больших коммерческих проектах технологии SW применены? Хотелось бы увидеть архитектуру этих приложений и по-возможности экономический эффект от применения semantic web по сравнению скажем с WEB 2.0.

Ответ:

Один из наиболее интересных коммерческих проектов Semantic Web это проект DBin.

Проект весьма неоднозначный, с одной стороны в нем есть черты rdf store, с другой – социальной сети. О нем немного можно почитать здесь.

В качестве основы для приложения Dbin используется среда Eclipse и новая парадигма Semantic Web Communities.

Анализом экономического эффекта от внедрения SW я не занимался, но при прочих равных разработку программного обеспечения в парадигме Semantic Web выполнить проще, а значит и дешевле. А возможности при этом будут выше. Как минимум синтаксическая и семантическая интероперабельность приложения SW будет гораздо выше, чем у любого другого приложения, построенного на классических технологиях.

К слову, интероперабельность – это способность к взаимодействию!

Вопрос 4:

Что полезного дает использование RDF для описания структуры сайта и для “сайтоделания” вообще?
Разве недостаточно “голого” XML? Насколько существенно использование в проекте именно RDF-графов?

Ответ:

RDF – это средство Semantic Web, которое сделает когда-то возможной автоматическую обработку информации агентами!

RDF – это семантическая разметка данных. Анализ такой разметки позволяет агенту делать логический вывод.

XML ориентировался на отделение структуры данных от их визуального представления, а RDF позволил внести в структуру данных XML понятие семантики. Т.е. позволил данные на веб-страницах представлять в виде наборов связанных отношениями объектов.

Анализ отношений между объектами и есть основа логического вывода.

В своих проектах более целесообразно использовать OWL (как более развитую альтернатива RDF).

Если Вы все-таки останавливаете свой выбор на RDF, то более эффективным будет использование RDF в синтаксисе n3.

RDF в XML/RDF синтаксисе весьма «тяжёлое» решение.

Конкретно, на сайте ontolib.com были доступны два вида информации, первый – html, второй – rdf со схемой данных rdfs. Внешняя программа анализируя содержимое сайта могла выделить ссылку на RDF+RDFS, а уже по ним эта программа должна (в идеале) осуществлять более точный и «осмысленный» анализ содержимого сайта.

Где можно скачать руководство пользователя для Protégé? русскоязычный вариант предпочтительнее, но и на английском дока не помешала бы…

Ответ:

Руководства пользователя, программиста и другая документация по Protege на английском здесь.

Переводы руководств (и многое другое) можно скачать здесь!

Можно ли визуализировать RDF с помощью CSS?

Ответ:

Нет, но можно с помощью XSL.

Допустим документы со связанными с ними RDF-файлами. Если ставить задачу написания поисковика по метаданным, то существует ил язык запросов к такому поисковику? Что уже сделано в этом плане вообще? Спасибо.

Ответ:

Задачу поисковика по метаданным решать не целесообразно. Уже теоретически и практически эту задачу решили, причем давно! Вот решать задачу поиска документов с учетом метаданных – это другое дело! Задача из серии неподъемных, но решив ее, Вы будете на высоте. Суть проблемы в том, что есть документ и соответсвующая ему онтология (или метаданные), надо провести поиск по содержимому документа на основе метаданных описывающих структуру и семантику этого содержимого. В случае, если вы все таки хотите только по метаданным искать, тогда SPARQL+OWL (или SWRL) может решить вашу задачу!

Вопрос 7.1:

Говоря о задаче поиска документов с учетом метаданных, что конкретно вы имеете в виду? Как перейти от ЕЯ запроса к SPARQL, или что? Непонятно.

Ответ: Нет, я имел в виду, что каждый текст нужно представить в виде связанных между собой метаданных, по которым и надо проводить поиск!  такие метаданные в принципе можно назвать семантическими аннотациями текста (но это ущербное понятие мне не нравиться, особенно если учитывать, что я имею ввиду полное семантическое описание текства – причем в некоторой форме это описание можно приравнять  экземпляру объекта онтологии)

В комментариях можно обсудить вопросы и ответы!