Главная > semap_ru > Проект семантической шины semap

Проект семантической шины semap

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

Новый подход к работе с информацией

К разработке проекта semap (название появилось из игры двух слов: «семантика» и окончание нейрона «сенапс») нас подтолкнула идея создания информационных менеджеров нового поколения, в которых управление информацией будет осуществляться на смысловом (семантическом) уровне, а не с помощью файлов и каталогов. Благодаря этому пользователи смогут оперировать такими сущностями как фильмы, музыкальные альбомы/песни, фотографии, программы, книги, журналы, статьи, электронные письма, контакты в большей мере, нежели файлами.

iPod

Рис. 1. После некоторого времени работы с Apple iPod пользователи забывают о существовании файлов

Возьмём, для примера, mp3-плеер Apple iPod или программу для проигрывания музыки Apple iTunes. Они, с нашей точки зрения, имеют передовой интерфейс, так как с их помощью очень удобно прослушивать музыку по альбому, музыканту, рейтингу, последнему добавлению без непосредственного манипулирования музыкальными файлами. Целью данного проекта является достижение того же уровня управления информации, но не только по отношению к музыкальным файлам, а вообще, к любой информации хранимой на компьютере. Технологии Semantic Web позволяют реализовать это видение на практике, но существующие реализации излишне сложны, изобилуют техническими деталями и, как следствие, крайне неудобны в использовании. Если вы не знакомы с Semantic Web, то хорошей отправной точкой может являться статья её автора Тима Бернерса-Ли или прочтите заметку про эту технологию на Wikipedia.

В качестве примера тестовых данных может послужить моя домашняя коллекция, содержащая цифровую библиотеку, музыкальные произведения, фотографии, скачанные приложения, исходные тексты программ, а также видео. Все эти данные потенциально можно описать семантически, чтобы компьютеры понимали смысл хранимой в них информации. Сейчас же мы вынуждены работать с ними как с иерархической структурой каталогов и файлов и производить полнотекстовый поиск с помощью таких инструментов как Google Desktop:

1. collection – моя домашняя коллекция, для которой я время от времени делаю резервные копии
1.1
library – цифровая библиотека
1.1.1
business
1.1.2
combat
1.1.3
computer
1.1.3.1
algorithm
1.1.3.2
architecture
1.1.3.3
artificial intelligence
1.1.3.4
automation
1.1.3.5
charsets

1.1.4
dictionary
1.1.5
economy

1.2
music – музыкальные произведения
1.2.1
classic
1.2.2
pop

1.3
photo – фотографии, часть из которых доступна в открытом доступе
1.3.1 2003
1.3.2 2005_04
1.3.3 2005_09

1.4
program – хронология скачанных программ
1.4.1 2003
1.4.2 2005_04
1.4.3 2005_09

1.5
source – исходные тексты используемых мною программ
1.5.1
css
1.5.2
java
1.5.3
prolog

1.6
video – видео
1.6.1
english videos
1.6.2
russian videos

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

Для описания данных для различных предметных областей используются онтологиии, описывающие их специфику и позволяющие осуществлять автоматизированый логический вывод «скрытой» информации. Исходя из приведенной выше цифровой коллекции и личного опыта выделены наиболее востребованные предметные области и общепринятые онтологии для них, ориентировочно, именно они будут востребованы пользователями в первую очередь:

· Категорий (основой для создания таксономий является онтология SKOS);

· Географических месторасположений (онтология GEO);

· Людей (онтологии FOAF и vCard);

· Организаций (онтология SWRC);

· Проектов (онтология DOAP);

· Публикаций (онтология biblio и SIOC);

· Музыкальных произведений (онтология MO);

· Видеофильмов (пока нет общепринятых онтологий);

· Фотографий (пока нет общепринятых онтологий);

· Программ (пока нет общепринятых онтологий);

· И конечно же, файлов и каталогов (такой онтологии также пока нет).

Идея семантической шины

Со времени выхода основных стандартов семантического Веба в феврале 2004 году прошло более трех лет, но до сих пор персональные семантические сервисы не получили широкого распространения. Мы связываем это с двумя факторами: во-первых, с отсутствием достаточного количества внешних источников метаданных, а, во-вторых, с трудностями обмена семантическими данными между семантическими сервисами.

Благодаря проекту Linking Open Data стали появляться Веб-источники разнообразных RDF данных и даже универсальные поисковые сервисы для них, например Zitgist. Тем самым проблема внешних источников постепенно будет решена. Но, к сожалению, пока не предпринято достаточных усилий для создания инфраструктуры для обмена пользовательскими семантическими данными. Эту архитектурную задачу призвана решить семантическая шина, впервые упомянутая создателем Веба Тимом Бернарсом-Ли два года назад. Наше видение семантической шины также дополнено идеями, используемыми в Google Desktop, Gnowsis и Zitgist.

Архитектура семантической шины semap

Рис. 2. Архитектура семантической шины semap

Основой решения выступает независимая от предметной области семантическая шина, аккамулирующая пользовательские семантические данные и предоставляющая централизованный доступ к ним через SPARQL. Хранимые ей семантические данные могут добавляться и изменяться семантическими сервисами непосредственно или косвенно через указание URL обновленного ресурса. Запрашивать RDF данные можно через платформенно-независимые HTTP(S)-интерфейсы XMLRPC или REST точки доступа SPARQL. Для поддержки различных семантических форматов используются точки расширения (plugins) шины. Таким образом семантические сервисы смогут обмениваться семантическими данными ничего не зная друг о друге – semap выступает посредником в этом взаимодействии.

В опеределенной степени, функционал семантической шины перекликается с функционалом традиционной файловой системы. Обе призваны обеспечить обмен данными, одна семантическими, другая файловыми. Обе независимы от предметной области и обеспечивают права доступа к данным. Но пока рано говорить о возможности полной замены файловой системы семантической шиной, для этого необходимо собрать первые положительные и отрицательные аспекты её практического использования и решить целый ряд технических задач.

Важно отметить, что наличие семантической шины не являться обязательным условием для семантических сервисов работающих с исходными семантическими данными самостоятельно. Но даже в этом случае они получат выгоду от использования semap благодаря асинхронным уведомлениям шины при изменении их исходных ресурсов и получению обновлений через формат RSS. Этот сценарий важен для интеграции традиционных приложений с новым поколением семантических сервисов работающих с семантической шиной непосредственно.

Возможно два варианта работы semap с исходными семантическими данными. По умолчанию, шина может просто кешировать и обновлять пользовательские семантические данные и в любой момент времени она будет хранить лишь актуальные RDF данные. Но возможен вариант, когда шина будет накапливать все изменения и хранить не только актуальные пользовательские семантические данные, но и историю их изменения. Благодаря последнему сценарию появляется возможность отслеживать хронологию модификации информации на компьютере пользователя и искать «во времени».

Резюмируя сказанное ниже перечислены основные задачи семантической шины semap:

1. Централизованная точка доступа SPARQL;

2. Сбор и актуализация семантических данных;

3. Поддержка всевозможных форматов семантических данных;

4. Набор конфигурационных файлов и консольных утилит для настройки и управления;

5. Аутентификация пользователей и управление правами доступа к данным;

6. Использование других экземпляров semap в качестве источников RDF данных;

7. Поддержка различных вариантов разрешения противоречивости данных;

8. Интеграция RDF данных и автоматизированный логический вывод «скрытой» информации.

Примеры практического применения

Семантическая шина сама по себе бесполезна пользователям, так как им не интересны особенности компьютерных технологий. Им нужны конкретные инструменты для решения повседневных задач, удобные и интуитивно понятные. Но сами по себе такие инструменты малоэффективны из-за отсутсвия обмена семантическими данными. Именно совместная работа множества семантических сервисов, обменивающихся семантической информацией через семантическую шину, способна изменить принципы работы пользователей с информацией и перевести её на качественно новый уровень. Чтобы доказать это рассмотрим ряд практических примеров, которые станут возможными при появлении semap.

Приложение Apple iTunes использует заложенную в mp3-файлы метаинформацию. Работая с этой утилитой пользователи могут импортировать отсутствующую метаинформацию из Интернета или вводить её вручную. Также iTunes собирает информацию о часто прослушиваемых произведениях и позволяет составлять рейтинги. Все эти данные могут быть переведены в семантический формат, либо благодаря расширениям iTunes, либо через независимые сервисы. Если же проиндексировать эту информацию в семантической шине, то в других популярных музыкальных проигрывателях, например для платформы MS Windows это могут быть Winamp, foobar2000, можно сразу же использовать эти данные для навигации по музыкальным произведениям. Единожды заведенная семантическая информация сразу же становится доступной всем заинтересованным в ней приложениям и при этом не важно кто является первоисточником этих семантических данных – iTunes или какой-то другой сервис. Поставляя semap семантические данные iTunes также может выступать и их потребителем, так как метаданные о музыкальных произведениях могут быть заведены или изменены с помощью других семантических сервисов, например, благодаря все тем же Winamp или foorbar2000. Получая информацию от шины в формате RSS iTunes может следить за такими обновления.

Если предыдущий пример функционально не даёт пользователям ничего нового, кроме гибкого обмена музыкальными метаданными, то следующий пример более уникален в этом отношении. Каждый из нас имеет какие-то увлечения или заинтересован в получении определенной информации. Эту информацию легко представить в семантическом виде на основе тематического тезауруса. После того как персональным семантическим сервисам будет доступна информация об увлечениях пользователя, они смогут уведомлять его об интересующих его телепередачах, книгах, статьях. В качестве примера, представим, что вы фанат Ралли и Формулы 1. Зная это семантические сервисы будут уведомлять вас о всех посвященных этим тематикам телепередачах, даже если это повторы, исторические хроники или другой телеканал. Такой функционал невозможен без обмена семантическими данными и в отсутствии внешних источников семантической информации.

Когда в семантической шине будет накоплено достаточно информации над точкой доступа SPARQL может быть разработан полноценный семантический поисковик пользовательских ресурсов по аналогии с Google Desktop, Apple Spotlight или Beagle. Но в отличие от них поиск будет осуществляться благодаря семантическим связям, а не на основе полнотекстового индекса и ключевых слов. Если же semap будет также хранить историю изменений пользовательской информации, то возможен и хронологический поиск.

Семантический сервис адресной книги

Чтобы направлять разработку semap нам необходимо иметь хотя бы один работающий семантический сервис. Он также понадобится при первых презентациях семантической шины и будет служить «эталонной реализацией» семантического сервиса. В этом качестве выбрана небольшая, но всем необходимая, утилита для управления пользовательской адресной книгой. Сформируем основные пользовательские истории для этого сервиса:

1. Добавление и изменение нового контакта – заполнение информации для нового контакта или её модификация;

2. Импорт/экспорт контактной информации – импорт(экспорт) контактной информации из(в) наболее востребованных(ые) форматов(ы);

3. Поиск контактной информации – поиск человека по самым разнообразным семантическим параметрам;

4. Интеграции с Google Earth – отображение географического расположения для текущего контакта;

5. Показ личной страницы в Интернете – автоматический показ персональной странички в Интернете для выбранного человека;

Для демонстрации интеграционных особенностей семантической шины также планируется создать расширение для популярного Веб-браузера Firefox для просмотра адресной книги. Пользователи смогут не покидая Веб-браузера находить контакты интересующих их людей и использовать их в электронных письмах или для иных целей.

Библиографический семантический сервис

Описанный в предыдущем разделе семантический сервис адресной книги является официальным сервисов для семантической шины semap и по мере развития шины планируется включать в него поддержку самых новых её возможностей. Поддержку этого сервиса будут осуществлять непосредственно разработчики semap. В этом же разделе хочется остановится на семантическом сервисе, из-за которого я четыре года назад заинтересовался технологиями Semantic Web и именно из-за него появилась идея создания семантической шины. Речь идёт о менеджере для работы с библиографиями.

Область библиографий достаточно богата семантическими данными самого разного плана, так как теснейшим образом связана с предметными областями людей (авторы публикаций), организаций (издательства), категорий (тематика), файлов и каталогов (цифровые версии книг и статей). Для описания самой предметной области библиографий будут взяты результаты открытого проекта по разработке новой онтологии biblio. Ниже описаны основные пользовательские истории для библиографического сервиса:

1. Добавление новой книги – добавление интересующей или хранящейся в реальной или цифровой библиотеках книги; метаинформация о ней может быть занесена вручную или импортирована из внешнего источника, например, Amazon;

2. Добавление новой научной статьи – добавление интересующей или хранящейся в реальной или цифровой библиотеки научной статьи; метаинформация о ней может быть занесена вручную, импортирована из формата BibTeX или внешнего источника, например, Citeseer или DBLP;

3. Прикрепление к заведенным публикациям электронных документов для ведения электронной библиотеки – добавление электронных документов для любой заведенной публикации (книги, статье и пр.), т.е. возможность формирования цифровой библиотеки пользователя;

4. Указание физических копий публикаций для ведения реальной пользовательской библиотеки – указание наличия физического экземпляра для любой заведенной публикации (книги, статье и пр.), т.е. возможность формирования реальной библиотеки пользователя;

5. Заведение закладки – заведение закладки для публикации с указанием её расположения, связи с другими ресурсами, а также затрагиваемой темы; подвидом закладки является цитата;

6. Сохранение навеянной при прочтении мысли – сохранение навеянных при чтении мыслей с указанием самой мысли, связи её с другими публикациями, цитатами или мыслями, а также затрагиваемой тематики;

7. Поиск информации по определенным критериям – поиск публикаций, цитат и мыслей по всевозможным семантическим категориям, будь то затрагиваемая тематика, автор, ключевое слово и пр.

Имея такой библиографический сервис нетрудно представить как благодаря обмену семантическими данными через шину semap другие семантические сервисы смогут реализовать новые варианты работы с библиографической информацией:

· Вставка информации о публикациях и цитатах в документы – форматирование и вставка библиографической информации во всевозможные электронные документы, например, вставка цитаты в научную статью или формирование списка реальной пользовательской библиотеки в электронном письме или автоматическая генерация рекомендуемых или прочитанных книг на блоге;

· Обмен библиографической информацией – обмен библиографической информацией посредством различных RDF-форматом через электронные сообщения или протокол P2P;

· Обмен цифровыми версиями книг и статей – обмен семантически аннотируемых электронных версий публикаций через протокол P2P, FTP, WebDAV;

· Поиск публикации – текстовые редакторы или приложения для просмотра публикаций наравне с функцией «Открыть файл» могут предусмотреть «Открыть книгу» или «Открыть статью».

Техническая реализация и вопросы лицензирования

Нами пока не обнаружено ни одного проекта семантической шины, реализующего предложенную архитектуру, и, который мы смогли бы использовать в нашей повседневной деятельности. Поэтому мы инициировали новый проект под лицензией Apache License v2. Для хостинга выбрана площадка SourceForge. В semap будут заложены возможности к расширению с помощью plugins благодаря технологии Eclipse Platform. Для хранения RDF данных будет использовано семантическое хранилище Sesame2, а для обеспечения HTTP доступа задействован встроенный веб-сервер Jetty.

Расширяемая архитектура выбрана не только из-за необходимости добавления новых семантических форматов, но вообще для любого расширения базового функционала шины. Благодаря такому гибкому подходу мы сможем сосредоточить основные усилия на ядре шины, т.е. на сборе и актуализации семантических данных и их выдачи через точку доступа SPARQL, в то время как поддержка различных семантических форматов, автоматизированый логический вывод «скрытой» информации и другой «расширенный» функционал будет отдан на откуп разработчиков расширений. Наличие ядра шины и набора расширений для неё позволит в каждом конкретном случае формировать требуемое поведение семантической шины без необходимости включения невостребованного функционала.

Мы выбрали язык программирования Java благодаря наличию для него целого ряда необходимых для нас и совместимых с лицензией Apache License v2 библиотек и фреймворков. Конечно же мы отдаем себе отчет, что semap вряд ли снискает себе популярность среди обычных пользователей из-за высоких требований предьявляемых виртуальной Java-машиной к оперативной памяти (по ориентировочным оценкам не менее 512 Мб). Но, во-первых, мы сможем решить благодаря работе над этим проектом ряд практических задач, а, во-вторых, семантические сервисы, которые как мы надеямся, будут разработаны, смогут взаимодействовать и с альтернативными semap семантическими шинами. В будущем, мы возможно перепишем semap на более приближенном к операционным системам языке программирования, например, C или Erlang, если это будет необходимо.

Смежные проекты

Существует множество проектов так или иначе связанных с идеей управления информации на семантическом уровне, но многие из них созданы в виде одноразовых прототипов в академических кругах, изобилуют техническими подробностями и не предназначены для использования обычными пользователями. Но есть и ряд интересных проектов: DBin, Gnowsis, семантический браузер Longwell, Finnish Museums Portal, Haystack, MediaWiki, Zitgist.

Среди них хочется особо выделить проекты Finnish Museums Portal, MediaWiki и Zitgist как наиболее перспективные. Finnish Museums Portal обладает интуитивно понятным интерфейсом и демонстрирует гибкость работы с семантической информацией в области описания исторических артефактов. MediaWiki является удачной попыткой скрещения Wikipedia и Semantic Web. И наконец, Zitgist – это новый поисковой семантический сервис на основе реальных данных проекта LinkedOpen Data.

Идея создания сервиса для сбора и обеспечения централизованного доступа к RDF данным не нова и впервые была реализована в проекте Gnowsis и на первый взгляд идеи семантической шины их полностью повторяют. Но это не совсем верно и мы решили заранее отметить принципиальные отличия этих проектов:

1. semap – это лишь сервис для сбора и предоставления централизованного доступа к RDF данным, а не многофункциональный комплексный инструмент, в который заложены знания об определенных предметных областях (имеется в виду онтология PIMOPerson Information Model);

2. semap не ориентирован на поиск и индексацию всей доступной на компьютере информации, прежде чем она будет обработана семантическими сервисами, так как эта практика ведет к «замусореванию» шины;

3. semap – это прикладной, а не исследовательский проект и он призван изменить способы работы людей с информацией благодаря появлению новых независимых персональных семантических сервисов, скрывающих сложность технологий Semantic Web.

Участие в проекте

Описанный в заметке проект достаточно многоплановый и вряд ли осуществим в одиночку. Есть целый ряд направлений для участия в нем: помощь автору в разработке ядра семантической шины, разработка расширений для неё, создание всевозможных семантических сервисов или проектирование онтологий для них, написание статей и продвижение среди пользователей и программистов. Более подробную информацию можно найти на сайте проекта или в списке рассылки.

Заключение

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

Выражаю большую благодарность Михаилу Навернюку aka jupy за содержательные дисскусии, благодаря которым были выкристализованы идеи данной заметки. Посетите его ресурс http://www.semantictools.ru

Реклама
Рубрики:semap_ru
  1. Апрель 17, 2007 в 12:49 пп

    Я только не понял конечной цели. Пользователи должны сами оперировать со SPARQL? Или пока создается промежуточное звено?

    И еще мне не очень понятно (т.к. не знаком с semantic web), что делать если есть несколько классификаций (онтологий?). Ту же музыку можно классифицировать и по стилям, и по исполнителям, и по годам. А еще могут быть вообще слабо класифицируемые вещи, типа нравится/не нравится. Как semantic web справляется с различными онтологиями для одинаковых вещей?

    И еще непонятно, если никакой онтологии нет, а пользователь хочет оставить какие-то свои собственные заметки. Насколько легко/сложно создавать собственные онтологии?

  2. Апрель 17, 2007 в 1:30 пп

    Владимир, спасибо за содержательный комментарий!

    Пользователи, естественно, не будут работать с семантической шиной непосредственно. Просто это звено позволит разработать систему независимо от интерфейса и, кроме того, обеспечит интеграцию приложений на уровне семантических данных. Интерфейс же должен полностью скрыть используемые внутрях технологии, в духе iPod 😉

    Возможно, ты не до конца понимаешь что такое онтология, там таких проблем нет. Более того, модель RDF так устроена, что позволяет прозрачным образом «зацеплять» различные семантические «утверждения» друг с другом. Нормой, также, является использование десятков онтологий одновременно. Создавать же онтологии вручную проблематично — это сродни разработки предметной области для базы знаний.

    Технологии Semantic Web достаточно «тяжелые». Я убил несколько лет аспирантуры на то, чтобы понять о чём все это 😉 Но я не забрасываю эту тематику и думаю, что за ней большое будущее. В этой заметке я сделал упор на технологии, что, наверное, спугнет большинство людей, кто будет её читать. Но я сделал это сознательно, так как основная целевая аудитория — это англоязычное коммунити проекта Linked-Open Data.

    Наверное, стоит описать проект с точки зрения пользователя, потому что там скрывается масса интересных особенностей. К примеру, с помощью семантических инструментов пользователь может задавать следующие вопросы: «Найти контакты людей, которые были на выставке Комтек’2006 и чей ребенок учился с 1997 по 2002 года на физическом факультете МГУ» или «Отобразить все журналы, в которых публиковались статьи, посвященные Семантическому Вебу». И т.д. и т.п.

    В проекте semap мы хотим разработать прототип для отработки этих идей, возможно это будет полезно и другим людям. Надо попробовать работать с информацией на смысловом уровне, а не перебирая каталоги и файлы в них. Смысл примерно такой, остальное дело техники ;)))

  3. Апрель 17, 2007 в 1:39 пп

    Это неокончательная версия заметки и в выходные я постараюсь более понятно описать суть проекта. Но я не смогу обьяснить все аспекты технологии Semantic Web — это отдельная большая тема ;(

  4. Апрель 17, 2007 в 1:45 пп

    Год назад я делал обзорную презентацию по Семантическому Вебу, может заинтересует 😉

  5. Апрель 17, 2007 в 2:19 пп

    Я думаю, что это все еще недолет. Мы должны честно признаться самим себе, что то, что мы хотим — это компьютер с AI. Что-то с AI в мире пока полный тухляк (не там копаем, видимо). Надо, чтобы компьютер хотя бы слегка осуществлял мыслительную деятельность — оперировал понятиями. Разработки, видимо, на этом поприще есть, но все военные. Например, система ЭШЕЛОН.

  6. Апрель 17, 2007 в 2:30 пп

    Я вот, например, не хочу компьютер с AI. Мало того что его (надеюсь) невозможно создать, так он еще и не имеет смысла. Компьютер — помощник человека, а не его замена. Первый признак достижения компьютером AI — это его осмысленный отказ от выполнения работы. С этого момента компьютер станет бесполезен и опасен. Сколько уже фильмов на эту тему сняли 🙂

    Еще по поводу AI. В 80-х годах была куча экспериментов с AI. Все они провалились (люди не осознавали их бессмысленность). А вот одна из областей, выросших из AI — экспертные системы — замечательно живет до сих пор.

  7. Апрель 17, 2007 в 2:36 пп

    Кстати, презентация клевая. Я ее уже когда-то смотрел и запомнил, что там хорошо объясняются все эти баззворды. Сейчас еще раз посмотрел — полезная штука.

    А по поводу RDF & SPARQL — они очень напоминают мне пролог. А у пролога помнится были проблемы с производительностью на больших базах. Нет ли таких проблем с RDF? Все таки одно дело описывать таблицами и ключами, а другое дело тройками.

  8. Апрель 17, 2007 в 2:46 пп

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

    Ну точно, эксперные системы :). В принципе можно, наверное, создать онтологию тегов, заметок, todo-шек и все будут счастливы 🙂

  9. Апрель 17, 2007 в 2:52 пп

    Реальные замеры будут возможны только на реальных данных и наверняка они будут в разы уступать реляционным базам данных. Но уже сейчас существует ряд семантических хранилищ типа Sesame и ряд mapper tools для отображения баз данных и других источников на RDF (например, OpenLink Virtuoso). Так вот, они без проблем манипулируют миллиардами троек (RDF-утверждений).

    На пролог чем то смахивает язык онтологий OWL (построен на основе формальной логики, в отличие от дизьюнктов Хорна), а модель RDF даже чем то похожа на реляционную модель, мне так кажется. SPARQL же очень похож на SQL, но в отличие от него он устанавливает ограничения на ориентированный граф.

    По суте же весь Семантический Веб — это реинкарнация и развитие идей баз знаний, только на глобальном уровне. Это попытка построения всемирной базы знаний.

  10. Апрель 17, 2007 в 2:54 пп

    Ну точно, эксперные системы :). В принципе можно, наверное, создать онтологию тегов, заметок, todo-шек и все будут счастливы.

    Это не проблема, тока получится немного «плоско» и машинно не-интерпретируемо, аля RSS. Реальные же онтологии позволяют описывать предметные области более полно и машинно-интерпретируеммо. Из-за такой плоскости я не вижу большого потенциала в использовании меток — они полезны только в небольших количествах.

  11. Апрель 17, 2007 в 3:47 пп

    А какие можешь посоветовать хранилища RDF, чтобы поиграться? Чтобы можно было создать какую-нить простенькую базу и позадавать ей запросов.

  12. Апрель 17, 2007 в 4:57 пп

    Попробуй Sesame (http://www.openrdf.org) или Kowari (http://www.kowari.org). Они оба для Java заточены, но существуют интерфейсы и для других языков, а также RESTfull интерфесы. Если проникнешся идеей, может поработаем вместе 😉 А, вообще, так повелось, что большинство библиотек для Semantic Web на Java. Есть ряд хороших на C. Для остальных же языков поддержка хуже.

  13. Апрель 17, 2007 в 11:26 пп

    Спасибо за ссылки. Будем посмотреть.

    У меня еще вопрос. Как я понял, для полноценной работы «семантической шины», необходимо, чтобы все данные были приведены к одному виду, т.е. к RDF с нужными онтологиями. Тогда уже можно делать различные выводы.

    А что делать, если онтологий нет и предметная область не формализована, или онтологии вообще не нужны? Т.е. что делать с mp3, jpg, mpeg — не переводить же их в rdf. Или, например, что делать с 3д моделями — они у каждого редактора/игры свои. Или «семантическая шина» допускает использование не-rdf ресурсов?

    Еще, возьмем к примеру issue tracking — он везде разный, зависит от типа проекта, команды, фирмы. Что тут делать: каждому свою онтологию — тогда нет совместимости «шины», универсальную онтологию — вряд ли такую можно создать.

  14. Апрель 18, 2007 в 6:07 дп

    Неплохой вопрос 😉 Начну отвечать издалека.

    У графовой модели RDF, являющейся основой Semantic Web, есть удивительная возможность, напрочь отсутствующая у XML. Данные RDF можно в прямом смысле сливать в одну кучу, они не мешают друг другу. Это одна из причин почему я сильно сомневаюсь в идеи создания и продвижения native XML databases. Айтунг, давайте сдлеаем ещё для кучи и native CSV databases 😉 На нижнем уровне реляционную базу данных никто не заменит, даже семантическая шина построена на её основе и в конце я об скажу подробнее.

    Поэтому не проблема данные сливать от разных приложений на семантическую шину, только это не принесет никакой пользы. Приложения не смогут видеть данные друг друга. Чтобы это произошло нужна основа в виде онтологий. Тут возможно несколько вариантов.

    1 вариант. Разрабатывается по одной общепринятой онтологии для каждой предметной области и данные приложений «меппятся» на неё. Приложения могут конвертировать данные в RDF физически и сливать их на семантическую шину или обеспечить новую точку доступа SPARQL для построения федеративной схемы доступа к своим реляционным данным (наверное это самая предпочтительная и гибкая схема, которая напрямую конкурирует с ETL-трансформациями при создании корпоративных хранилищ).

    2 вариант. Есть несколько онтологий для одной и той же предметной области, при этом достаточно прописать правила их связывания (например, с помощью RIF — http://en.wikipedia.org/wiki/Rule_Interchange_Format) и приложения, которые даже не знают о существовании других онтологий и приложений смогут видеть эти данные! Обычно это промежуточная фаза развития и спустя какое-то время приходим к варианту 1.

    Учитывая все это, могу ответить, что если онтологий нет, то и польза может только в том, что приложения смогут обмениваться «голыми» RDF данными, типа RSS (преимущественно основан на схеме DC), на котором можно многое описать, даже для тех областей, для которых онтологий нет.

    Если и RDF данные разные, как в случае 3D моделей, то тут пользы нет, но и вред не очень сильный. Если только по скорости и лишних траблов с централизованным подходом (вспомнить хотя бы реестр Windows).

    Насчет того что issue tracking везде разный, тут я готов поспорить. Я использовать этот подход и в программировании, и даже во внедрении систем бюджетирования — универсальность очень высокая. И не зря же существует масса универсальных решения типа Bugzilla, JIRA. Эта область как раз уже покрыта онтологиями, типа FOAF, DOAP, SWRC. Это даже обсуждалось, правда давно — http://www-128.ibm.com/developerworks/library/x-think5/.

  15. Апрель 18, 2007 в 6:25 дп

    Вообще я склоняюсь к тому, чтобы приложения обеспечивали независимые точки доступа SPARQL или, как вариант, Веб-сервисы (архитектура SOA) должны поддерживать значение RDF/XML параметра accept HTTP-запроса.

    А чтобы убрать централизацию для пользовательских данных, то туть много вариантов. От внедрения метаданных в формат файла, как сделано у mp3, jpeg, как делает Adobe до создания к файлам «теневых» файлов с расширение rdf. Чтобы при копировании или сбоях оставалась возможность переиндексировать данные. Это пока идеи вслух! Собственно проект semap мне интересен для обкатки всех этих идей. Я не исключаю возможность, что Semantic Web не приживется на десктопах или в корпорациях, хотя сомнений всё меньше.

  16. Апрель 18, 2007 в 6:46 дп

    У меня ещё появилось такое ощущение, что мы постепенно отходим от приложений как таковых и главным в будущем будут именно данные. Не важно что за приложение их создало или обработало, важны данные сами по себе. Бизнес-процессы, алгоритмы, все будет доступно как данные. Идеи Lisp возвращаются 😉

  17. Апрель 18, 2007 в 8:35 дп

    Владимир, вот это тебя наверняка заинтересует — http://www.franz.com/products/allegrograph/index.lhtml

  18. Апрель 18, 2007 в 12:50 пп

    На счет отсутствия приложений и замены всего на данные я как-то не до конца уверен. По-моему нет смысла переводить mp3, jpeg, mpeg в rdf-данные.

    Да и вообще какая м.б. онтология у звука или картинки — это же чистые бинарные данные (я именно про данные, а не про описание, кто, когда их сделал). Их надо воспроизводить, анализировать, сжимать/разжимать тут никакие pdf-тройки не помогут.

    Хотя м.б. появится RDF OS, в которой вместо API будут онтологии, а все приложения превратятся в набор rdf-данных 😉

  19. Апрель 18, 2007 в 4:53 пп

    Кстати. Как я понял из презентации, онтология — это подмножество логики первого порядка. Т.е. по сути набор предикатов и правил а-ля пролог.

    Логика предикатов 1-го порядка является лишь одной из возможных вычислительных моделей и имеет свои плюсы/минусы и область применения. Наиболее удобно в ней именно описание фактов и смысловых взаимосвязей.

    Однако, для многих других задач больше подходят другие, специализированные вычислительные модели (да хотя бы lambda-calculus или ООП).

    Я просто все пытаюсь понять область применимости rdf, и пока прихожу к выводу, что все приложения и данные rdf никогда не заменит (не для всего он удобен), а вот помочь описывать общие стандартизованные взаимосвязи между различными объектами он может очень хорошо.

    Т.е. не надо заменять файлы MS Office или OpenOffice или cpp-файлы на rdf (по крайней мере пока :), а вот то, что все эти файлы имеют автора, дату создания, относятся к какому-нибудь проекту и т.д. Вот это то и можно описывать стандартными rdf-ками.

    А в дальнейшем возможно будет переводить все больше и больше данных в этот формат. Но только тогда, когда от этого можно извлечь «семантическую выгоду» 🙂

  20. Апрель 19, 2007 в 4:49 дп

    Ты абсолютно прав. Semantic Web удобен для работы с метаинформацией, т.е. с теми данными, которые сейчас представлены текстом на веб-страницах. Бинарные же форматы нет никакого смысла загонять в RDF.

    Область применения. Тут нет пока однозначного мнения или устоявшихся практик. Наверное, удобнее всего применять для формального описания предметных областей, с которыми чаще всего приходится иметь дело пользователям Интернета и корпоративным служащим. Собственно, это отражают уже существующие онтологии: FOAF — люди, интересы, DOAP — проекты, SWRC — организации, публикации, SIOC — обсуждения на формах, заметки на блог и т.п.

    Логика предикатов первого порядка. Онтологии OWL основаны на формальной логике. Программы пролог состоят из предикатов Хорна. И формальная логика и предикаты Хорна являются частью логики предикатов первого порядка. Кроме того, они сами по себе решают слегка разные задачи. К примеру, есть задачи, которые решаются предикатами Хорна, а формальной логикой нет. Но, формальная логика более удобна для описания предметной области, она более наглядна что-ли и чем-то напоминает ООП, в то время как предикаты Хорна менее понятны экспертам в предметной области. А логику предикатов первого порядка не используют, потому что вывод на ней является NP-трудной задачей и не гарантирован. Если внимательнее посмотреть на варианты языка онтологий OWL, то их там три — Lite, DL и Full. DL — это как раз Description Logic и вывод на нём точно закончится, а вот Full — это уже выход за пределы формальной логики, но это и не дизьюнкты Хорна.

    Semantic Web — не панацея и на него не будут переведены все данные и программы. Мне кажется, что это разумное развитие баз данных и Веба в глобальную базу знаний, не более того. Это возможность сформировать машинно-интерпретируемый Интернет, когда агенты будут помогать тебе формировать туристический маршрут, или когда несколько федеральных баз данных будут связаны воедино, типа того 😉

  21. sokv
    Апрель 19, 2007 в 9:11 пп

    В описании идеи проекта упоминается iPod и утверждается, что целью проекта является «…достижение того же уровня управления информации…». В то же время утверждается, что пользовательский интерфейс «не является ключевым модулем проекта». Интересно было бы узнать, что же именно тогда позволит приблизить Semantic Web к рядовому пользователю? В двух словах, в чём изюминка, если не в интерфейсе?

    По какому принципу отобраны области, на которые ориентирован semap? (Можно ли круг этих областей задать более формально, чем «те, которые нужны лично мне»?)

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

  22. Апрель 20, 2007 в 4:34 дп

    А вот и Владимир Вольфович проснулся 😉 Нестыковок в статье немерянно, ещё больше в моей голове. Надеюсь следующие ревизии будут конкретнее или я вообще откажусь от этой затеи 😉

    Есть два направления — пользовательский интерфейс и семантическая шина. Я пока разрываюсь между ними и не могу в голове четкую картинку составить. Хожу второй день думаю…

  23. Апрель 21, 2007 в 10:58 дп

    Честно говоря я просто поражен, до какой степени твои мысли и рассуждения совпадают с моими собственными. Судя по всему идея действительно витает в воздухе.

    Но меня интересуют не только вопросы, чисто технические, но и организационные. Твой проект задумывается как исследовательский, или коммерческий? Есть ли уже команда разработчиков? И т.д. и т.п.

    Если не возражаешь я попытаюсь связаться с тобой в понедельник по аське.

    -Михаил

  24. Апрель 22, 2007 в 4:48 дп

    Михаил,

    С этой идеей я давно хожу, но, к сожалению, четкой картины в голове все-равно не имею ;( Давно собирался подробнее рассказать о задумке semap, но есть масса нерешенных задач, рад что появляются единомышленники.

    Конечно связывайся, буду рад. С командой хуже всего, но благодаря открытой разработке я и хотел найти заинтересованных людей. Планировал разработку по лицензии Apache, так как закрытая разработка, как мне кажется, менее выгодна стратегически. По этому поводу у меня есть ряд мыслей. Никак не опубликую статью про бизнес модель Open Source, давно уже собираюсь, все некогда.

  25. Апрель 25, 2007 в 7:48 дп

    3.5 Заведение цитаты
    3.9 Обмен библиографической метаинформацией
    3.10 Обмен цифровыми версиями книг и статей

    Да, я хочу Semap

  26. Апрель 25, 2007 в 1:09 пп

    Начато обсуждение идей статьи в тематическом форуме — http://forum.semantictools.ru/?1-2-0-00000003-000-0-0

  27. sokv
    Апрель 26, 2007 в 9:45 пп

    Описание системы, которой лично я хотел бы пользоваться.

    И. — пользовательские истории.
    Р. — рассуждения.

    И.1. Мы должны иметь персонализированное хранилище (для чего, объясним позже). В нашем хранилище мы хотим накапливать и иметь постоянный доступ к следующей информации:
    — об объектах, событиях и т.п. реального мира (далее называем просто объекты),
    — о файлах и папках (далее называем просто объекты),
    — об объектах и утверждениях в нашем хранилище (далее называем просто объекты),
    — и т.п.

    И.2. Какую информацию мы прежде всего хотим накапливать и иметь к ней доступ?
    1. Мы хотим знать характеристики объектов реального мира (то же относится к файлам), заметки о них.
    2. Мы хотим знать о связях объектов с другими объектами.
    3. Наши метаданные должны идентифицировать объекты так, чтобы данные об одном объекте из разных источников были сопоставимы, состыковывались в одно целое.
    4. Наши метаданные должны идентифицировать объекты так, чтобы мы могли найти эти объекты в том «мире», в котором они существуют (если это объект реального мира — прийти к нему и посмотреть, если человек — связаться с ним, если книга — найти её в магазине, если файл — найти его в сети и т.п.).

    Р.1. Требования 3 и 4 пользовательской истории И.2. достижимы, если идентифицировать объекты их местоположением в том «мире», в котором они существуют. Например, географическими координатами, URL, ISBN и т.д. Проблемы такого подхода в том, что в силу условности и многочисленности «миров» в которых существуют объекты невозможно избежать модельных приближений:
    Пример 1. Интернет пользователя можно идентифицировать по email, icq и т.п. Не следует забывать, что всё это приближения. Если человек не пользуется интернетом, то его можно идентифицировать по паспорту, в качестве объекта из «мира государство Россия» и т.п.
    Пример 2. Книгу можно идентифицировать по ISBN, можно различать каждый бумажный экземпляр книги по инвентарному номеру, можно идентифицировать электронную версию книги по URL её местонахождения, можно по контрольной сумме файла (как в осле), и т.п.
    Как же идентифицировать правильно? Эти вопросы должны решаться не данной системой, а на этапе разработки онтологий. Возможно, они и будут решены в общем виде в будущем.

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

    Р.3. Где эта информация, описанная в И.2. будет содержаться? Храниться распределённо или у нас в хранилище, или ещё где? Это зависит от критичности наших требований к доступности хранилища, чтобы мы могли беспрепятственно добавлять свою информацию и читать всю накопленную нами ранее.

    И.3. Допустим, в нашем хранилище содержится лишь часть информации о каком либо объекте. А в других хранилищах содержится дополнительная информация об этом же объекте. Мы должны иметь возможность составив запрос на получение информации увидеть полную информацию об этом объекте, с указанием из каких хранилищь она получена. Мы должны иметь возможность подключать, и наоборот, исключать другие хранилища в качестве наших источников информации. Файлы с метаданными стоит рассматривать не как отдельную сущность, а как вид источника информации, наряду с хранилищами.

    И.4. Информация из других источников информации не должна копироваться в наше хранилище без нашего разрешения. Но с нашего разрешения мы должны иметь возможность скопировать информацию в наше хранилище.

  28. Dmitry
    Май 10, 2007 в 4:29 дп

    Для людей у вас выбрана онтология FOAF, а чем VCARD
    не нравиться?

  29. Май 10, 2007 в 5:46 дп

    Предметные области и онтологии скорее для примера приведены. Шина semap независима от предметной области и для неё безразлично, что за онтология будет использована.

  30. Павел
    Ноябрь 18, 2007 в 12:29 пп

    Проясните мне, пожалуйста, один момент.
    RDF язык обеспечивает максимальную выразительность, в запросах мы можем оперировать тройками (т.е. запросы вида найти тройки где объект/субъект/свойство отвечают определенным условиям).
    OWL – яык веб онтологий, там помимо таксономии объектов можно дополнительно указывать характеристики свойств (инверсивность, симметричность транзитивность, функциональность) плюс у классов можно указывать необходимые и достаточные условия принадлежности сущности к классу.
    Создаем две одинаковые онтологии в Protege – сохраняем их – одну в RDF, другую (с указанием дополнительных свойств и характеристик OWL) в OWL.
    Оба документа (если я не ошибаюсь) представляют наборы троек. Как можно (с пом-ю какого API, ) использовать доп-ные возможности OWL? Т.есь имеется ли возможность оперировать при запросами терминами OWL (класс, экземпляр, инверсивное свойство, подкласс, и.т.д), а не RDF.

  31. Ноябрь 18, 2007 в 1:44 пп

    RDF обеспечивает возможность гибко хранить данные в виде троек и не зависить от жестких схем баз данных, где характер хранимых данных заранее определен. Поиск же по RDF данным осуществляется с помощью языка запросов SPARQL.

    Непосредственно в запросе ты указываешь графовый шаблон поиска, т.е. ты определяешь какую часть существующего графа ты хочешь получить. Другой вопрос что это за граф. Это может быть обычный граф c RDF данными, либо граф с RDF данными + выведенные новые данные из OWL. Непосредственно в языке запросов SPARQL нельзя указать, использовать ли при поиске вывод над OWL или нет. Но это возможно если предоставить две точки доступа SPARQL — одна с поддержкой OWL, другая нет. Или предусмотерть включение вывода над OWL отдельным параметров, дополнительно к SPARQL pапросу.

    Я ответил на вопрос и как обсуждаемая тема касается проекта semap?

  1. Июнь 23, 2007 в 2:58 пп

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: