Лирическое отступление
AgentOWL – небольшая java библиотека, разработанная для поддержки RDF/OWL моделей для Jade агентов.
Здесь используется описание модели знаний агента(generic agent model), основанная на пяти основных элементах: Resources, Actions, Actors, Context и Events. Поддерживается обмен сообщениями в формате RDF/OWL, включение полученной информации в модель.
Ув. читатели SHCHERBAK.NET, вашему вниманию предлагаются материалы статьи «Semantic Web как новая модель информационного пространства Интернет» авторов Ф.И. Андон, И.Ю. Гришановой и В.А. Резниченко.
В этой статье описаны базовые концепции и архитектура Semantic Web, а также положение дел по разработке данного проекта по состоянию на конец 2007 года. Выделены проблемы, которые стоят перед мировым сообществом для дальнейшего развития Semantic Web.
Полную версию статьи читаем здесь !
Щербак Сергей: Статья мне очень понравилась и я ее особенно рекомендую тем, кто хочет максимально быстро погрузится в мир семантического веба (обязательна для прочтения).
От имени читателей SHCHERBAK.NET хочу выразить благодарность Ирине Гришановой за предоставление материалов интересной статьи!
Ф.И. Андон, И.Ю. Гришанова , В.А. Резниченко
Институт программных систем НАН Украины
03680 Киев, проспект Академика Глушкова, 40
тел.: (044) 526 51 39, e-mail: reznich@isofts.kiev.ua
Semantic Web as a new model of internet information space
P.I. Andon, I.Y. Grishanova, V.A. Reznichenko
Описаны базовые концепции и архитектура Semantic Web, а также положение дел по разработке данного проекта по состоянию на конец 2007 года. Выделены проблемы, которые стоят перед мировым сообществом для дальнейшего развития Semantic Web.
Basic concepts and architecture of Semantic Web is described. State of the art concerning development of the project up to the end of 2007 year is outlined. The problems of future development of Semantic Web are noted.
Феномен World Wide Web стал возможный только благодаря практическому использованию набора широко распространенных стандартов на разных уровнях, что обеспечило интероперабельность данных. Современная тенденция развития Интернета заключается в переходе от документов, „читаемых компьютером” (machine readable) к документам, которые „понимаемы компьютером” (machine understandable).
Web разрабатывался как информационное пространство, полезное не только для коммуникации человека с человеком, но и как пространство, в котором смогут эффективно сотрудничать и компьютеры. Одно из главных препятствий на пути к этому состоит в том, что большая часть информации в Web предназначена для ее понимания человеком. Очевидно, что такая структура данных не может быть понятной для просматривающего веб-робота. Подход Semantic Web базируется на разработке языков для выражения информации в форме, пригодной для машинной обработки.
Идея Semantic Web была предложена в 1998 году Тимом Бернерсом-Ли (Tim Berners-Lee), который является изобретателем WWW, URI, HTTP и HTML.
Semantic Web представляет собой сеть информационных узлов, которые связаны друг с другом таким образом, чтобы имеющаяся информация могла легко обрабатываться компьютером. Его можно рассматривать как эффективный способ представления данных во Всемирной паутине, или как глобально связанную базу данных. Данный проект предлагает реализацию полной системы по автоматизированному созданию и хранению семантического ядра контента, предоставленного во Всемирной паутине.
Проект Semantic Web – это попытка собрать все устоявшиеся идеи и сделать так, чтобы они смогли работать вместе внутри сети Интернет. Для достижения этой цели используются стандарты, которые разработаны не только консорциумом W3C, но и другими организациями. Цель проекта – разрешить взаимодействовать этим стандартам между собой внутри децентрализованной системы без вмешательства человека.
Проект Semantic Web [1], начатый в 2001 году, на данный момент находится в стадии активной разработки, старается интегрировать в себя все уже имеющиеся на данный момент подходы, с целью создать действительно универсальное средство семантического поиска информации [2, 3]. Большое внимание отводится архитектуре и модели распределенной среды [4], архитектуре метаданных [5 – 8]. Как сказано в определении, которое предоставлено на домашней странице проекта – «Semantic Web является абстрактным представлением данных во Всемирной паутине, которое базируется на стандартах RDF и других стандартах, имеющих распространение. Проект разрабатывается Консорциумом W3C в содружестве с большим количеством исследователей, ученых и промышленных партнеров» [9].
«Semantic Web – это расширения текущего Web, в котором информация предоставляется с хорошо определенным значением, которое лучше разрешит компьютерам и людям работать вместе. … Его идея в том, чтобы иметь данные в Web, определенные и связанные между собой таким образом, чтобы их можно было использовать для более эффективного исследования, автоматизации, интеграции и повторного использования в разных приложениях… эти данные могут быть общедоступными и обрабатываемыми автоматическими средствами так же, как и людьми» [2].
В рамках данного проекта задействованы такие передовые технологии, как агентно-ориентированный подход в программировании [10] – проект DAML+OIL (DARPA Agent Markup Language + The Ontology Inference Layer) [11 – 14], онтологии [15, 16], XML [17– 19], RDF [20 – 22], и др. В настоящее время распространяется использование Web-агентов (в упрощенном виде веб-сервисов), которые разрабатываются как для частных задач, так и для создания ядра Semantic Web [23 – 28].
Как указал профессор Джон Сова, – Semantic Web – много-дисциплинарная тема, которая объединяет теории и методы трех областей:
логика – формальные структуры и правила логического вывода;
онтологии – описание типов сущностей, которые относятся к Предметной области;
теория моделей.
Интернет – это сеть компьютеров, объединенных каналами и использующие протоколы (TCP/IP) для связи между собой. Web – это сеть сайтов, использующих гиперссылки для переходов между страницами [29]. Традиционный Web базируется на языке разметки документов HTML. HTML-страница описывает форму представления информации в Web-броузере, а этот язык тяжело подвергается автоматическому содержательному анализу. Автоматизировать даже такие тривиальные задачи, как поиск людей, проектов, программ в Интернете невозможно. Следующий этап развития Интернет – Semantic Web – представляет собой переход на новый уровень представления данных – уровень знаний и автоматизированной обработки. Технология Semantic Web разрешит компьютеру интерпретировать информацию, представленную в Web, наравне с людьми, для чего разработана графовая модель описания ресурсов RDF (Resource Description Framework).
В общем виде Semantic Web (по Тиму Бернерсу-Ли) – это:
интероперабельность данных между программными приложениями и организациями;
набор интероперабельных стандартов для обмена знаниями;
архитектура для взаимосвязанных сообществ и словарей [30].
С точки зрения архитектуры Semantic Web можно рассматривать как три яруса (рис. 1):
базис, который состоит из уникальной глобальной идентификации ресурса, метаданных для
декларирования фактов о ресурсах, и общего языка для выражения метаданных и
знаний, который реализован с помощью онтологий для общедоступного понимания и
общего словаря метаданных и правил для добавления новых метаданных и знаний;
базовый сервис, например логический вывод и запросы к метаданным и онтологиям, разъяснение таких выводов, управление доверием (trust), агенты, поисковые системы, серверы
онтологий;
сервисы приложений, например сервис агентства путешествий.
Рис. 1. Три яруса сети Semantic Web
Технологии, которые задействованы в разработке Semantic Web:
семантический поиск;
вопросно-ответные системы;
агенты;
объединение знаний (интеграция баз данных);
всепроникающие вычисления (ubiquitous/pervasive computing) [29].
В 1998 году Тим Бернерс-Ли предложил следующий логический план построения Semantic Web [31]:
1. синтаксис для представления знаний, который использует ссылку на онтологии (RDF);
2. язык описания онтологий (ОWL);
3. язык описания веб-сервисов (WSDL, OWL-S);
4. инструменты чтения/разработки документов Semantic Web (Jena, Haystack, Protege);
5. язык запросов к знаниям, которые записаны в RDF (SPARQL);
6. логический вывод знаний (находится на этапе обсуждения);
7. семантическая поисковая система (например, SHOE).
Базовая модель Semantic Web (пирог Тима) в редакции 2006 года показана на рис. 2 [32].
Рис. 2. Базовая модель Semantic Web в редакции 2006 года
Фундаментальными основами Semantic Web являются:
графовая модель представления полуструктурированных данных (OEM, Lore);
формальная логика (логика первого порядка, базы знаний, фреймы);
архитектура WWW (URI/IRI, Unicode, XML, HTTP);
криптография с открытым ключом.
Рассмотрим структуру базовой модели Semantic Web более детально.
В Web для идентификации элементов используются «Унифицированные идентификаторы ресурсов», или сокращенно URI (Uniform Resource Identifier). URI можно присвоить чему угодно, и если эта сущность имеет URI, то о ней можно говорить, что она находится «в Web»: это может быть человек, книга, абстрактная концепция, т.е. все, что имеет название.
URI является базисом Web. «URI – это компактная строка символов, которая используется для идентификации абстрактного или физического ресурса» [33].
Одной из форм URI есть URL (Uniform Resource Locator), унифицированный указатель ресурса. URL это адрес, по которому загружаемся Web-страница.
Также необходимо указать, что в начальной базовой модели в нижнем ярусе было указано еще и базовое кодирование – т.е. общий для всех принцип кодирования всех возможных
символов многих языков – кодовая таблица UNICODE.
За синтаксисом URI следит комитет IETF. Документ, который опубликованный этим комитетом RFC 2396 является общей спецификацией URI. Консорциум W3C поддерживает список схем URI.
В 2005 году на смену URI был предложен интернационализированный идентификатор ресурса – Internationalized Resource Identifiers (IRI), идентифицирующий абстрактный или физический ресурс на любом языке мира. URI могут содержать только латинские символы и знаки препинания из набора символов US-ASCII (в общей сложности около 60 символов).
Для обеспечения принципов интернационализма, сохранения «читабельности» для человека, в IRI было предложено, что эти идентификаторы могут содержать любые
символы Юникода (Unicode/ISO10646) в чистом виде, без всякого кодирования. IRI не ущемляют права вторых языков и ведут к более высокой степени равноправия
пользователей Интернет. В будущем идентификаторы IRI призваны заменить URI.
XML[34] (eXtensible Markup Language) представляет собой очень простой и при этом мощный, и гибкий текстовый формат для описания документов произвольной структуры. XML был разработан и утвержден в качестве стандарта в ProductID=»1998 г» 1998 г Консорциумом W3C для упрощения реализации, а также для обеспечения интероперабельности между SGML и
HTML. Он является подклассом языка SGML, однако более прост для понимания и обработки.
Функции XML следующие:
представление синтаксиса для других языков разметки;
семантическая разметка Web-страниц. XML-представление может использоваться на Web-странице
вместе с таблицей стилей XSL, что определяет корректный вывод на экран разных элементов;
единый формат обмена данных. XML-представление может передаваться между двумя применениями как объект данных.
Язык XML разрешает каждому создавать свой собственный формат документов и потом писать документы в этом формате. Эти форматы документов могут включать разметку,
которая уточняет содержание контента документа. Документ с разметкой может «читаться» компьютером.
Для описания предметной области ресурсов предложен стандарт RDF (Resource Description Framework) [35 – 42], принятый в 1999 году консорциумом W3C и поддержанный многими ведущими производителями ПО, и поставщиками контента. Начальное назначение RDF было в описании XML-ресурсов с разных точек зрения. RDF представляет собой модель описания метаданных. Этот язык использует XML-синтаксис.
В то время, как модель данных XML является графом с обозначенными вершинами и не обозначенными дугами (т.е. без связей), модельданных RDF является графом с обозначенными как вершинами, так и дугами, который разрешает определять связи между сущностями.
Модель Resource Description Framework имеет своей целью стандартизировать определение и использование метаданных, которые описывают ресурсы Web. Однако, RDF также хорошо подходит и для представления данных [43].
Стандарт RDF (Resource Description Framework) включает две основные части – собственно способ описания ресурсов, а также способ задачи схем, по которым ресурс описывается.
Первая часть RDF [44] определяет простую модель для описания объекта, который рассматривается в качестве ресурса, как связей между ресурсами в терминах поименованных свойств и значений.
Вторая (RDF Schema – RDFS) [45, 46] служит для задачи структуры предметной области и аналогична диаграмме классов в UML.
На RDF можно описывать как структуру ресурса, так и связанную с ним предметную область.
RDF описывает ресурсы в виде ориентированного размеченного графа – каждый ресурс может иметь свойства, которые в свою очередь также могут быть ресурсами или их коллекциями.
Базовый строительный блок в RDF – это тройка «объект – атрибут – значение», который часто записывают в виде A(O,V), т.е. «объект O имеет атрибут A со значением V». Такую связь можно также представить как ребро с меткой A, которое объединяет два узла, O и V: [O] – A –> [V]. Такая нотация довольно полезна, поскольку RDF разрешает менять местами объекты и значения. Таким образом, каждый объект может играть роль значения, которое в графическом представлении отвечает цепочке из двух ребер с метками.
Кроме всего вышеупомянутого, RDF допускает форму представления, в которой любое выражение RDF в тройке может быть объектом или значением, т.е. графы могут быть
как вложенными, так и линейными. В Web это разрешает, например, выражать сомнение или согласие с выражениями, созданными другими людьми.
Главная цель RDF – предложить базовую модель данных «объект – атрибут – значение» для метаданных. Кроме этой семантики, которая описана в стандарте лишь неформально, RDF не содержит каких-либо четких правил, ориентированных на моделирование данных. Также, как XML Schema используется для
определения словаря, RDF Schema разрешает разработчикам определять конкретный словарь для данных RDF (такой, как authorOf) и указывать виды объектов, к которым могут применяться эти атрибуты. Другими словами, механизм RDF Schema предоставляет базовую систему типов для моделей RDF.
Таким образом, RDF предоставляет возможность формулировать утверждения в виде, пригодном для обработки компьютером и это является основой Semantic Web.
В базовой модели Semantic Web, представленной выше, предложенной Тимом Бернерсом-Ли, явно не выделено наличие средств описания метаданных. Тем не менее, в своих работах, например, [30, 31], а также в работах других ученых указывается на важность включения в концепцию Semantic Web понятия метаданных.
Метаданные это данные о данных. Более точно, это данные, предназначенные для идентификации, описания или локализации (местоположения) информационных ресурсов, не зависимо от физической природы ресурса.
Было разработано множество схем описания метаданных, среди которых следует упомянуть следующие:
Topic Maps (XMT) [47] – стандарт ISO (ISO/IEC 13250:2003) для представления и обмена знаниями с точки зрения поиска информации.
Text Encoding Initiative (TEI) [48] – международный проект по разработке нормативов для разметки (marking up) электронных текстов, таких как романы, пьєсы, стихи; главным образом для поддержки исследований в гуманитарной сфере.
Metadata Encoding and Transmission Standard (METS) [49] – стандарт кодирования и передачи метаданных, был разработан для удовлетворения потребности в стандартной структуре данных для описания сложных цифровых библиотечных обьектов.
Metadata Object Description Schema (MODS) [50] – схема метаданных описания обьектов, которая была выведена из MARC 21, и предназначена для перенесения отобранных данных из существующих записей метаданных MARC 21 или для создания оригинальной записи описания ресурса.
Encoded Archival Description (EAD) [51] – закодированное архивное описание, было разработано как способ разметки данных, которые содержатся в поисковых средствах, для того, чтобы они находились и показывались в оперативном режиме.
Learning Object Metadata (LOM) [52] – стандарт IEEE 1484.12.1-2002 метаданных обьектов учебного процесса для повторного использования ресурсов учебного характера, таких как компьютерного и дистанционного обучения.
Online Information Exchange (ONIX) [53] – международный стандарт схемы метаданных, который разработан издателями книжной промышленности Соединенных Штатов и Европы.
Однако, базовыми для Semantic Web в данный момент признаются стандарты Dublin Core, FOAF, SIOC и DOAP [54].
FOAF (Friand-Of-A-Friend) [55 – 57] – это формат машинно-обрабатываемых страниц, описывающих персональную информацию о людях и их деятельности (фотографии, календари, блоги и прочее) в формате XML.
SIOC (Semantically-Interlinked Online Communities) [58] – документы, описывающие онлайн-сообщества. SIOC обеспечивает взаимосвязь таких средств обсуждения информации, как блоги, форумы и почтовые рассылки между собой.
Description of a Project Description of a Project (DOAP) [59] – документы, описывающие в сети проекты с открытым исходным кодом.
Среди данных стандартов выделяется Dublin Core [60], как один из базовых стандартов для представления данных об информационных ресурсах в Semantic Web. Dublin Core [61, 62] – набор элементов (свойств) для описания документов, который первоначально был разработан в марте 1995 года. Цель Dublin Core – обеспечение минимального набора элементов описания, которые оказывают содействие внедрению описания и автоматической индексации документоподобных сетевых объектов по принципу, подобному карточкам библиотечного каталога. Набор метаданных Dublin Core предназначался для использования средствами исследования ресурсов Интернета, такими как веб-кроулеры поисковых систем, а также предполагалось, чтобы Dublin Core был достаточно простым набором для понимания и использование широким кругом авторов и случайных публикаторов, которые размещают информацию в Интернете. Элементы Dublin Core широко используются в документировании Интернет-ресурсов. На данный момент элементы Dublin Core определены в Dublin Core Metadata Element Set, Version 1.1: Reference Description [63].
Расширять сам набор элементов можно как самостоятельно, так и с использованием уже имеющихся стандартов. Например, для описания людей и организаций (которые выступают в качестве элементов матаданных Dublin Core: Creator, Publisher или Contributor) можно применить стандарт для электронных бизнес-карт (vCard [64]). Общие соображения по этому поводу даются в [65], а конкретное предложение предоставляется в [66 – 68].
Как отмечается в официальном описании RDF, метаданные могут быть встроенными (embedded) в сам ресурс, например, в HTML страницы [69] или документы, например, MsWord (это простейший подход для описания страниц), а могут сохраняться и обновляться независимо от ресурсов. Многие из производителей программного обеспечения уже выпускают ряд продуктов, которые автоматически формируют некоторый небольшой блок RDF-описания внутри документа. Второй подход является более универсальным, так как в этом случае метаданные могут быть созданы для любого ресурса. В настоящее время уже начат проект на базе Open Directory [70] (поисковая система Google) по автоматическому созданию репозитория RDF-описаний ресурсов Интернет.
В случае размещения метаданных отдельно от ресурса, сами метаданные преимущественно сохраняются (и передаются) в формате XML. При этом максимально используются возможности модели RDF и обеспечивается свободный обмен информацией (interoperability). Обмен метаданными сводится к пересылке RDF/XML-файлов (т.е. текстовых файлов в формате XML или просто ссылок на эти файлы), т.е. может быть полностью автоматизирован.
Первым «пластом» Semantic Web над только что обсужденным синтаксисом является простая модель типизации данных. Схема и онтология – это средства для описания содержания и связи между термами.
На основе RDF 23 января 2003 был предложен рабочий проект RDF Vocabulary Description Language 1.0: RDF Schema [71]. Схема RDF была разработана как простая модель типизации данных для RDF. Как указывается в документе, RDF является языком общего применения для представления информации в Интернет. Данная спецификация описывает как использовать RDF для описания RDF-словарей. Она определяет базовый словарь, предназначенный для этих целей и принятые соглашения, которые могут быть использованы при создании приложений Semantic Web для поддержки более сложных словарей RDF-описаний. Язык описания словаря RDF определяет классы и свойства, которые могут быть использованы для описания других классов и свойств, а также производить некоторые более сложные вещи, такие, как создание диапазонов и областей для свойств.
Три наиболее важных понятия, которые дает нам RDF и схема RDF – это «Ресурс» (rdfs:Resource), «Класс» (rdfs:Class) и «Свойство» (rdfs:Property). Эти понятия являются «классами» в том понимании, что этим классам могут принадлежать термины.
Как уже было указано, RDF Schema определяется в терминах базовой информационной модели RDF – структуры графа, который описывает ресурсы и свойства. Все словари RDF используют некоторую базовую структуру: они описывают классы ресурсов и типы связей между ресурсами. Эта общность разрешает
использовать разнородные словари, созданные для машинной обработки, и отвечает требованиям по созданию метаданных, в которых утверждения могут быть получены из множества разнородных децентрализованных словарей, созданных различными сообществами по разным принципам и разными методами.
Описание с помощью RDF не ограничивается только описанием документов Интернет. Этот стандарт довольно универсальный и гибкий для того, чтобы описывать большинство типов структурированных данных. Например, в RDF естественно выражаются диаграммы сущность-связь, которые широко применяемы для проектирования баз данных. Описание семантики ресурса на RDF может быть как «внешним», когда описывается ресурс в целом, так и «внутренним», когда описывается внутренняя структура ресурса – будь-то база данных, XML-документ, или целый сайт.
Важной особенностью стандарта RDF, как и лежащего в его основе XML, является расширяемость.
На RDF можно задать структуру описания источника, используя и расширяя встроенные понятия RDF-схем, такие как классы, свойства, типы, коллекции. Модель схемы RDF включает наследование; наследоваться могут как классы, так и свойства.
Кроме описания структуры, RDF разрешает оперировать утверждениями. Выражение «ресурс R1 как свойство P имеет ресурс R2» можно проинтерпретировать и как предикат P(R1, R2), а потом использовать это утверждение как объект других утверждений. Такая интерпретация разрешает описывать с помощью RDF концептуальную информацию.
Таким образом, RDF целиком подходит на роль универсального языка описания семантики ресурсов и взаимосвязей между ними.
Однако, как утверждают сами авторы стандарта, RDF имеет и ряд отсутствующих свойств, которые они указывают как следующие:
невозможность указания мощности множества значений свойства, например, что «Человек имее только одного биологического отца»;
невозможность указания того, что представленное свойство (например, hasAncestor – имеет предка, прототип) является транзитивным, например, что «если A hasAncestor B, и B hasAncestor C, тогда A hasAncestor C»;
невозможность указания того, что два разных класса, определенных в разных схемах, фактически представляют одно и то же понятие;
невозможность указания того, что два разных экземпляра (instances), определенные раздельно, фактически представляют один и самый субъект;
невозможность определения новых классов в терминах операций (например, объединение и пересечение) над другими классами.
Онтологии, в общем виде определяются как совместно используемые формальные концепции конкретных предметных областей, они дают общее представление о понятиях, информацией из которых могут обмениваться люди и приложения. Они разрешают концептуализировать домен фиксированием сущностей (entities) и связей в домене. Указание в каких связях принимает участие сущность частично разрешает понять и ее значение (содержание), поскольку это предоставляет возможность видеть, где данная сущность входит в отношения с другим доменом.
Онтологии основываются на математическом аппарате формальной логики (descriptive logic, DL), малое подмножество которого охвачено RDF-схемой. DL является подмножеством логики первого порядка, которое вычислимо.
Дополнительные возможности, выше указанные, в дополнении к имеющимся в RDF, является целью онтологических языков, таких, как DAML+OIL [72, 73] и OWL [74, 75]. Данные два языка основаны на RDF и RDF Schema. Цель данных языков – обеспечение ресурсов дополнительной машинно-обрабатываемой семантикой, т.е. они направлены на обеспечение машинного представления ресурсов в форме, которая более соответствует их оригиналу из реального мира.
Разметка документов Semantic Web с помощью онтологических терминов позволит производить автоматическую обработку их контента. Таким образом, онтологии определяются как ключевая технология для развития Semantic Web.
Онтологии в состоянии сыграть критически важную роль в организации обработки знаний на базе Web, их общего использования и обмена ими между приложениями.
Язык DAML (DARPA Agent Markup Language) (2000 год) был разработан агентством передовых оборонных исследовательских проектов (Defense Advanced Research Projects Agency) как расширение XML и RDF. Последняя версия языка DAML+OIL обеспечивает большой набор конструкций для создания онтологий и разметки информации таким образом, чтобы компьютеры были способны их прочитать и понять. В этой связи необходимо также упомянуть еще одну разработку DARPA – язык DAML-S – Semantic Markup for Web Services.
DAML+OIL является языком семантической разметки для Веб-ресурсов. Он основывается на ранних стандартах W3C таких, как RDF и RDF Schema, и расширяет эти языки более полными примитивами моделирования. DAML+OIL обеспечивает примитивы моделирования, которые по обыкновению используются в языках, основанных на фреймах. Онтология DAML+OIL (или база знаний, knowledge base) есть коллекция RDF – троек. Онтология, как правило, содержит иерархию понятий предметной области и описывает важные свойства каждого понятия с помощью механизма «атрибут – значение». Связи между понятиями могут быть описаны с помощью дополнительных логических утверждений.
Язык OWL. Наиболее развитым языком представления онтологий в настоящее время является OWL (Web Ontology Language), который расширяет возможности XML, RDF, и RDF Schema. Этот язык основан на DAML+OIL. Проблемы, которые возникли в DAML+OIL, были вызваны постоянным изменением ядра спецификаций RDF, на котором основан DAML+OIL.
Как указывается в основном рабочем проекте, OWL почти полностью похож на DAML+OIL. Основные и существенные отличия от DAML+OIL состоят в следующем:
устранение некоторых ограничений;
способность прямо указывать, что свойство может быть симметричным;
устранение некоторых неиспользуемых конструкций DAML+OIL, особенно ограничение с дополнительными компонентами.
Существует также несколько маловажных расхождений, которые включают в себя некоторые изменения имен некоторых конструкций, однако основная цель, преследуемая при создании OWL, заключалась в том, чтобы максимально корректно сохранить имена DAML+OIL.
Онтология OWL является последовательностью аксиом и фактов с добавлением ссылок на другие онтологии, которые считаются включенными в онтологию. Онтологии OWL являются Web-документами и на них можно ссылаться. Онтологии также имеют не связанную с логикой компоненту (пока еще не определенную), что может быть использовано для записи авторства, и другая не связанная с логикой информация, ассоциированная с онтологией. Фактически это словарь, который расширяет набор терминов, определенных в RDFS.
Онтологии включают информацию о классах, свойствах и частных случаях, каждый из которых может иметь идентификатор ID, который является ссылкой URI.
OWL имеет три модификации:
OWL Lite (простой);
OWL DL (с полной разрешимостью);
OWL Full с полной выразительной мощностью).
Каждая из этих модификаций (кроме Lite) является расширением предыдущей. Как следствие: любая OWL Lite онтология является OWL DL онтологией, а любая OWL DL онтология является OWL Full онтологией.
Главные характеристики языка веб-онтологий OWL:
OWL использует синтаксис XML;
OWL имеет инструкции для представления дерева классов;
OWL имеет инструкции для указания принадлежности индивидов классам;
OWL имеет систему описания свойств: область определения, область значений;
OWL может задавать характеристики свойств: симметричность, транзитивность,
функциональность;
OWL имеет инструкции для указания эквивалентности (склеивание) классов.
Говоря о языках запросов, фактически речь идет о интеграции разных языков (информационно-поисковых, баз данных, манипулирования данными,
обмена данными и т.п.) в единый язык запросов Web. При этом все специалисты едины во мнении, что это должен быть декларативный язык, построенный на модели неполноструктурированных данных (semistructured).
Документ «XML-QL: A Query Language for XML» [76] был подготовлен к семинару W3C по поисковым языкам, который прошел в конце 1998 года и явился далеко не единственной попыткой обобщения такого рода.
В настоящее время появилось несколько языков запросов к XML-источникам данных: XQL (1998) [77], XML QL (1998) [78 – 80]. Поиск в XML-документе состоит в нахождении элементов, которые удовлетворяют условиям запроса, с последующим преобразованием найденных элементов в структуру, заданную в запросе.
Язык запросов к RDF-источникам данных (RDF Query) предложен в 1998 [81 – 85] и в данное время имеет уже практическую реализацию в проекте Sesame [86].
В 2006 году консорциум W3C начал разработку языка запросов к RDF и OWL-хранилищам – SPARQL Query Language for RDF, который сейчас имеет статус рекомендованного кандидата (candidate recommendation) [87].
SPARQL – язык запросов, который базируется на паттернах графов.
SPARQL одновременно является как языком запросов, так и протоколом доступа к данным, является одним из ключевых компонент приложений Web 2.0: в качестве стандарта для поддержки гибкой модели данных он дает общий механизм запросов для всех приложений Web 2.
Принцип «логического вывода» очень простой: это возможность выводить новые данные из данных, которые уже есть. В математическом смысле, выполнение запроса является одной из форм логического вывода (например, возможность вывести из массы данных некоторый результат поиска). Логический вывод является одним из ведущих принципов Semantic Web, так как он разрешает очень легко создавать SW-приложения [88].
Для того, чтобы Semantic Web стал довольно выразительным и смог помогать людям в разных ситуациях, возникает необходимость построения мощного логического языка, который поддерживает
логический вывод. Дискуссии относительно методов, и даже возможности выполнения этой задачи, до сих пор ведутся очень активно; обращается внимание на то, что в RDF недостаточны возможности квантификации, и что эта область определена недостаточно хорошо. Проблемы логики предикатов подробно рассмотрены в базовой монографии Джона Сова (John Sowa’s) «Математические предпосылки (логика предикатов)» – «Mathematical Background (Predicate Logic)» [89].
Rule Interchange Format (RIF) – формат обмена правилами. Цель этого разрабатываемого консорциумом W3C стандарта [90] – определение формата, который бы разрешил транслировать правила между разными языками правил и благодаря этому обеспечить обмен правилами между системами, основанными на правилах.
Системы, основанные на правилах, получили широкое распространение в информационных технологиях. К их числу относятся, например, экспертные системы и системы дедуктивных баз данных. Разработки технологий Semantic Web обеспечивают новую среду использования таких систем. Поэтому консорциум W3C уделяет отдельное внимание этой области. Спецификация RIF может рассматриваться как составная часть комплекса стандартов Semantic Web.
В настоящее время рабочей группой, организованной при консорциуме для разработки этого стандарта, подготовлен и обсуждается рабочий проект документа, который систематизирует случаи использования RIF и требования к этому языку. Важнейшее требование к создаваемому стандарту – обеспечение возможности его использования не только при текущем состоянии технологий, основанных на правилах, но и его гибкости, достаточной для обеспечения его использования в процессе их эволюции.
Рабочий проект документа, который описывает случаи использования, даст возможность определить функциональные требования к RIF и на этой основе разработать адекватные спецификации языка.
Правила вывода новых фактов SWRL. Благодаря дополнению OWL языком RuleML [91] (подмножество Datalog) в виде словаря SWRL (A Semantic Web Rule Language) [92] появилась возможность использовать дизъюнкты Хорна (Horn-like rules) для явного указания способа вывода новых фактов из RDF-утверждений. Пока словарь SWRL находится в стадии стандартизации [93].
Хотя работы над этим уровнем Semantic Web продолжаются, однако в нашем распоряжении есть уже достаточный набор средств для построения Semantic Web: утверждение, цитирование (материализация) в RDF, классы, свойства, области, документирование в схеме RDF, непересекающиеся классы, свойства однозначности и уникальности, типы данных, инверсии, эквивалентности, списки и прочее.
Следующий шаг в разработке Semantic Web – доверие и доказательство. Об этом уровне написано очень мало, что является недопустимым, так как в будущем он будет очень важным.
Для обеспечения целостности и непротиворечивости информации, представленной в Semantic Web, важно обеспечить связь приложений Semantic Web с контекстом, а также механизмы проверкидоказательства и цифровых подписей.
Приложения Semantic Web будут учитывать контекст в целом для того, чтобы сообщать пользователям, могут ли они доверять предоставленным данным. Если пользователь получает поток RDF-данных от другого пользователя о прочитанной им книге и о его оценке этой книги, то он должен знать, кто этот человек, и можно ли доверять этой информации. Более того, пользователь может потом воспользоваться этой информацией, не сомневаясь в ее источнике. Далее пользователь оставляет на свое собственное усмотрение насколько ему верить полученному критическому отклику о книге.
Необходимо помнить и о том, что над разделяемыми контекстами работают также и группы людей. Если какая-то группа разрабатывает в Semantic Web информационную службу для художников, каталогизируя людей, их имена и места, где находятся картины этих людей, то доверие пользователя к этой группе зависит от того, насколько он доверяет людям, которые принимают участие в этой группе.
В связи с этим в Semantic Web для определения источника информации предлагается использовать цифровые подписи.
Цифровые подписи это есть небольшие фрагменты кода, которые можно использовать для однозначной проверки того, кто написал тот или другой документ. Основанная на работах по математике и криптографии, цифровая подпись является доказательством того, что документ или утверждение написал (или с ним согласен) определенный человек. Разработчики Semantic Web планируют, что каждый пользователь или агент все свои RDF-утверждения будет подписывать персональной уникальной цифровой подписью.
Еще одним аспектом доверительности информации является проверка истинности. Язык проверки истинности это просто язык, который позволит проконтролировать, является или нет утверждение правдивым. Реализация языка проверки обычно составляется из списка «элементов» логического вывода, которые используются для получения искомой информации, а также для последующей проверки информации о доверии для каждого из этих элементов.
Ведущую роль в Semantic Web должны сыграть программные агенты. При выше описанной архитектуре информационного пространства, предполагается, что агенты, обладающие интеллектуальными способностями, смогут выполнять поставленные им пользователями цели и задачи самостоятельно. Например, по поиску необходимой информации, подбору и выбору оптимальных вариантов и т.п. Это в перспективе мобильные, интеллектуальные агенты, способные к целеполаганию, планированию, совместному взаимодействию с другими агентами для достижения цели, имеющими знания как о себе, так и о внешнем мире. Для достижения поставленных задач они должны иметь возможность пользоваться некоторыми стандартными наборами услуг, представленными в Web в качестве веб-сервисов.
Веб-сервис – это программная система, предоставляющая некоторую услугу и обеспечивающая взаимодействие по сети. Обычно это веб-ресурс, характеризующийся абстрактным набором функциональных возможностей, которые в нем реализуются. Функционально веб-сервис может являться агентом, а может быть обычной программой.
Определение веб-сервиса, данное в википедии следующее: это «программная система, идентифицируемая строкой URI, чьи общедоступные интерфейсы определены на языке XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью интернет-протоколов.»
Архитектура веб-сервисов базируется на компонентном подходе, т.е. сервис должен быть достаточно автономным, а также может состоять из нескольких сервисов, подбираемых динамически для выполнения конкретной задачи в соответствии с различными критериями.
Немаловажным аспектом при выборе сервиса является его доступность. Интернет представляет собой динамичную среду, и вопрос доступности ресурса или сервиса является очень актуальным. При проектировании композиции сервисов очень важно учитывать данный аспект.
Задача построения новых сервисов из уже имеющихся поднимает проблему синтеза сервисов.
Для того, чтобы воспользоваться услугами, должна быть возможность их обнаружения, механизм получения информации о том, какие услуги они предоставляют, как к ним обращаться, формат сообщений. Решением этой задачи стало создание каталогов услуг с помощью стандартных методов доступа. Сервисы должны быть описаны в стандартных терминах, а информация о том, как к ним обращаться и другая имеющаяся информация должна кодироваться стандартным способом.
Технология веб-сервисов базируется на следующих открытых XML-стандартах:
SOAP (Simple Object Access Protocol) [94 – 100] — XML-протокол для удаленного вызова методов веб-сервисов;
UDDI (Universal Description, Discovery and Integration) [101] — описывает модель данных, предназначенную для каталогизации и обнаружения услуг, предоставляемых веб-сервисами;
WSDL (Web Services Description Language) [102] — язык описания интерфейсов веб-сервисов.
Формирующиеся дополнения к ним, например, WSCoordination/WS-Transaction (транзакции), WSSecurity (безопасность), WS-Routing (маршрутизации сообщений) и т.д., призваны расширить
возможности этой платформы в удовлетворении требований задач интеграции приложений. В рамках инициативы WS-I разрабатываются примеры прикладных решений, предложения и дополнительные требования, призванные гарантировать совместимость решений разных поставщиков. Это сулит широкие возможности по интеграции различных информационных систем в рамках единого согласованного набора спецификаций.
Во многих случаях интеграция информационных ресурсов требует комбинирования обращений более чем к одному веб-сервису для реализации пользовательского запроса. Таким образом, веб-сервисы должны иметь возможность поддерживать взаимодействие с другими приложениями в дополнение к стандартным процедурам обработки данных. Более того, процесс предоставления агрегированной распределенной информации может включать в себя разбиение на набор взаимосвязанных этапов обработки данных, взаимодействие ряда веб-сервисов, вмешательство людей в процесс обработки пользовательских запросов и другие элементы прикладной логики. Поэтому процесс сбора и интеграции гетерогенных данных может представлять собой логически сложную композицию обращений к хранилищам информационных сущностей посредством интерфейсов веб-сервисов — определять автоматизированный поток обработки данных.
Для описания композиций веб-сервисов на данный момент различными ассоциациями предлагается ряд стандартов. Среди них можно отметить следующие языки описания автоматизированных потоков работ, участниками которых являются веб-сервисы:
WSFL (Web Services Flow Language) — позволяет определять композиции веб-сервисов в виде графовой модели рабочего процесса;
BPML (Business Process Modeling Language) — определяет блочную модель композиции веб-сервисов;
BPEL4WS (Business Process Execution Language For Web-Services) — представляет собой гибрид блочной и графовой моделей описания взаимодействий веб-сервисов.
Эти языки позволяют описывать композиции веб-сервисов, что позволяет определять сложные, распределенные процессы по извлечению, обработке и интеграции информации.
Для решения таких сложных распределенных задач особенно хорошо подходит мультиагентная технология.
Как уже было выше сказано, для выполнения конкретных задач веб-сервисы должны обмениваться сообщениями, сообщать информацию о себе и предоставляемых услугах в виде, удобном как для машинной обработки, так и доступном для понимания человеком. Для решения этой задачи консорциумом были предложены языки метаописаний сервисов WSDL, а также онтологический язык веб-сервисов OWL-S [103]. В настоящее время консорциумом предложен проект языка моделирования сервисов – Service Modeling Language (SML) [104].
Наиболее часто используемое определение агента состоит в том, что программный агент это программная сущность, которая функционирует продолжительно и автономно в конкретном окружении, часто – вместе с другими агентами. Агенты могут быть специализированные, они должны уметь общаться с другими агентами с целью обнаружения сервисов, продуктов, информации или других агентов. Сервисы, представленные в сети, могут быть реализованы как агенты. Возникает проблема создания архитектуры для взаимодействия агентов, где бы агенты могли описывать свои цели с использованием заранее определенных словарей, где возможно было бы производить поиск и подбор необходимых сервисов и информационных ресурсов, а также использовать многие другие возможности.
Технология Semantic Web на данное время успешно решает следующие задачи:
независимость данных от приложений;
семантическая интеграция данных;
создание основы для повсеместного использование компьютерных агентов
(сервисов).
Формирование Semantic Web станет возможным только при условии обеспечения более высокого уровня интероперабельности. Однако уже сейчас сделано много практических шагов по реализации данного проекта. Новый проект на базе поисковой системы Google недавно предоставил свои ресурсы для запросов агентам на выполнение поисковых функций и проверки правописания [105]. Также представляет интерес новый проект по автоматическому созданию RDF-описаний и хранилища метаданных, создаваемый на базе Open Directory [70] поисковым механизмом Google [106]. Кроме того, необходимо также отметить и проект консорциума W3C SWAD-Europe [107], который занимается проблемой связи хранилищ семантических данных с используемыми реляционными системами баз данных, особенно лицензированных как Free Software / Open Source (FS/OS).
В настоящее время необходимо констатировать, что общий объем мета-информации достиг уже критической массы и неуклонно растет. На сентябрь 2006 года пространства имен OWL были использованы в 113 000 документах Semantic Web (это 8% общего объема), пространство имен RDFS объявлено в 677 000 (47%). Owl:Class является наиболее используемым термом из пространства имен OWL, он используется в 1 800 000 высказываниях из 68 000 документов. В августе 2007 года в сети насчитывалось более 2 биллионов RDF-троек [32, 54, 108, 109].
Интерес к использованию данной информации также постоянно повышается. На март 2006 года [108] из анализа запросов поисковой системы Google видно, что обычными рядовыми
пользователями было призведено 2 120 000 запросов к типу „RDF filetype:rdf” и 13 600 “ontology filetype:owl”. Такие цифры говорят о популяризации идей Semantic Web и дает возможность уже реально начинать использовать данную мета-информацию в прикладной сфере.
Дальнейшему развитию Semantic Web оказывает содействие наличие свободно распространяемых систем для разработки приложений Semantic Web:
Jena Framework (Java);
Drive RDF Parser (C#).
В настоящее время уже существуют:
библиотеки для интерпретации стека языков RDF для всех популярных языков программирования (Jena, Redland, RDFLib);
редакторы онтологий (Protege);
системы рассуждений над онтологиями (Racer, KAON, FACT);
семантические хранилища (Sesame, Kowari, YARS);
семантические браузеры (Simile, Piggy Bank, Gnowsis, Haystack);
поисковики семантических данных (Swoogle);
конверторы из разных форматов представления данных в/из RDF/XML (Aperture, RDFizers, D2R);
прикладные программы (Bibster, FOAF Explorer).
Также необходимо указать и существующие коммерческие продукты: Adobe’s XMP – инструментарий для создания метаописаний о файлах;
Oracle’s 10.2 Database – уже имеет встроенную поддержку модели RDF; Tucana’s Knowledge Discovery Suite – платформа для интеграции информации применений (Enterprise Information Integration, EII)
На последней VI международной конференции по Semantic Web – Sixth International Semantic Web Conference, которая проходила 11-15ноября 2007 г. в Корее [109], обозначено следующее положение дел в направлении распространения Semantic Web:
обозначился резкий рост и возникновение компаний, использующих технологию Semantic Web (Joost, Radar Networks, MetaWeb, Siderean, SandPiper, SiberLogic, Ontology Works, Intellidimension, Intellisophic, TopQuadrant, Data Grid, etc.);
произошло вовлечение крупных поставщиков ПО – Adobe, Cisco, HP, Microsoft, Nokia, Oracle, Sun, Vodaphone;
активно развиваются правительственные программы – в США, Объединенной Европе, Японии, Корее, Китае;
сильно возрос такой важный рынок, как медико-фармацевтический – создана специальная группа
при консорциуме Health Care and Life Sciences Interest Group at W3C;
появилось много инструментов с открытым кодом – Kowari, RDFLib, Jena, Sesame, Protégé, SWOOP, Onto(ххх). Wilbur.
На этой конференции Semantic Web рассматривался как коллекция всех формальных, машиннообрабатываемых, доступных в Web, основанных на онтологиях утверждений (семантических метаданных) о веб-ресурсах и прочих сущностях мироздания, выраженных на языке представления знаний, основанном на синтаксисе XML (например, OWL, DAML, DAML+OIL, RDF, etc.). Необходимо
констатировать, что в Web уже представлено достаточно большое количество такой информации. Все больше встает проблема ее обработки, объединения, выравнивания, выявления связей.
С 2003 года ежегодно проводится всемирный конкурс Semantic Web Challenge [110], призванный собрать самые последние наработки и показать миру состояние дел по практической реализации идей Semantic Web. При этом был сформулирован следующий перечень минимальных критериев, определяющих понятие «приложение Semantic Web».
Во-первых, приложение должно использовать информационные источники, которые:
географически распределены;
имеют различных владельцев, что предполагает отсутствие контроля за их развитием;
являются гетерогенными (синтаксически, структурно, и семантически);
содержат данные реального мира, т.е. источники должны быть больше, чем игрушечные примеры.
Во-вторых, приложение должно воспринимать открытый мир; это значит, что оно знает, что информация никогда не бывает полной и постоянно меняется.
В-третьих, приложение должно использовать некоторое формальное описание значения данных.
Помимо этих минимальных критериев, были определены несколько желательных качеств. Приложение должно использовать источники данных в других целях или по-другому, чем первоначально было намечено. Оно также должно использовать контент мультимедийных документов. Пользователи должны быть в состоянии получить доступ к приложению на множестве языков или с других,
отличных от PC, устройств. Приложение должно использовать как статические, так и динамические знания, например, комбинация статических онтологий и динамических технологических процессов. Наконец, приложение должно быть масштабируемым (в терминах количества используемых данных и совместно работающих распределенных компонент).
Итоги состязания между представленными проектами ежегодно подводятся на Всемирной конференции по Semantic Web, где обсуждаются
научные решения и проблемы, возникшие на данном этапе развития Semantic Web. На
последней VI конференции 2007 г. в Корее было выделено 2 поколения приложений Semantic Web [111]. Первое поколение – Семантически привязанные приложения Semantic Web – Semantically Closed SW Applications. Эти приложения используют единую онтологию, очень привязаны к семантическим ресурсам, ограничены в интерактивности. Такие приложения предоставляют однородное представление гетерогенных источников данных и очень ограниченно используют существующие в Semantic Web данные. Существующие на данный момент приложения Semantic Web более похожи на традиционные системы, ориентированные на знания.
В настоящее время встает задача создания приложений второго поколения. Второе поколение приложений Semantic Web должны использовать весь огромный запас уже накопленной семантики. Приложения Semantic Web 2-го поколения должны быть способны использовать:
множество онтологий;
быть открытыми для семантических ресурсов;
быть открытыми для работы с пользователем (user interaction).
В идеале они также должны уметь использовать не только данные Semantic Web, но и другие форматы данных, например, фолксономии и т.п.,
следовательно должны иметь мощные механизмы по автоматическому извлечению информации.
Также на этой конференции было показано, как Semantic Web предлагает решение проблемы объединения данных, а также практические результаты этой работы.
Результаты VI конференции по Semantic Web показали, что:
большинство из событий, которые были предположены, свершились, или свершаются в данный момент, темпы этого движения ускоряются;
некоторые достижения происходят быстрее, чем планировалось ранее (массовый рост RDF-хранилищ, представление рассуждений, наличие онтологий – но очень плохо связанных);
некоторые планы пока слабо реализуются, но движение в этих направлениях продолжается (публичные источники информации RDF, OWL, зарождение «всепроникающих» вычислений);
слабое развитие технологии агентов [108].
Semantic Web – это динамичная, постоянно развивающаяся концепция, а не набор комплексных, работающих систем.
С точки зрения машинной обработки данных – «Semantic Web – это идея хранения данных в Web таким образом, чтобы они были определены и связаны для дальнейшей возможности автоматизированной обработки, интеграции и повторного использования их в различных приложениях.» [9]
С точки зрения интеллектуальных агентов «целью Semantic Web является сделать существующий Web более машинночитаемым с тем, чтобы иметь возможность использовать интеллектуальных агентов для поиска и обработки соответствующей информации.» [112]
С точки зрения распределенных баз данных «концепция Semantic Web заключается в «… обеспечении достаточной гибкости для возможности представления всех баз данных и правил логики таким образом, чтобы связать их все вместе…» [9] «Простое описание Semantic Web заключается в том, что он представляет собой попытку реализовать машинную обработку данных…В частности, трансформировать обработку информации обеспечением общего принципа, по которому данные могут быть получены, связаны вместе и поняты. Перевод Web от типа «большой книги с гиперссылками» к большой связанной базе данных”[112].
С точки зрения автоматизированной инфраструктуры – «Semantic Web является инфраструктурой, а не приложением» [113].
С точки зрения обслуживания человеческих потребностей – идея Semantic Web заключается в освобождении человека от обременительных рутинных задач по добыче, поиску, учету и индексированию информации, содержащейся в Web. «Semantic Web – это видение следующего поколения Интернет, который позволит веб-приложениям автоматически собирать веб-документы из различных источников, учитывать и обрабатывать информацию, а также взаимодействовать с другими приложениями для выполнения сложных задач» [114].
С точки зрения улучшения аннотирования – «идея Semantic Web состоит в обеспечении существующего Web аннотациями, выраженными в машиннообрабатываемой форме и связанными между собой» [115].
С точки зрения улучшения поиска – реализация поиска не только по ключевым словам, но и по контенту.
С точки зрения веб-сервисов – «Semantic Web должен обеспечить доступ не только к статичным документам, содержащим полезную информацию, но и к сервисам, которые предоставляют полезные услуги» [116].
Таким образом, задачи Semantic Web, а равным образом и его проблемы заключаются в следующем:
индексация и поиск информации;
разработка и поддержка метаданных;
разработка и поддержка методов аннотирования;
представление Web в виде большой, интероперабельной базы данных;
организация машинной добычи данных;
обнаружение (discovery) и предоставление веб-ориентированных сервисов;
исследования в области интеллектуальных программных агентов.
Дополнительная библиография по представленной тематике приведена в [117].
Литература
1. W3C Semantic Web
Activity. – http://www.w3.org/2001/sw/Activity
2. SemanticWeb organization. – http://www.semanticWeb.org/
3. Getting into RDF “Semantic
Web using N3”, Tim Berners-Lee – http://www.w3.org/2000/10/swap/Primer.html
4. Web Architecture: Describing and Exchanging Data”, Berners-Lee, Connolly, Swick, W3C Note 7 June 1999. – http://www.w3.org/1999/04/WebData
5. Metadata Architecture, W3C Design Issues. – http://www.w3.org/DesignIssues/Metadata
6. RDF and Metadata, Tim Bray, June 09, 1998. – http://www.xml.com/xml/pub/98/06/rdf.html
7. The Power of Metadata, book chapter by Rael Dornfest, Dan Brickley. – http://www.openp2p.com/pub/a/p2p/2001/01/18/metadata.html
8. Web Metadata: A Matter of Semantics by Ora Lassila, IEEE Internet Computing, July-August 1998. – http://computer.org/internet/ic1998/w4030abs.htm
9. W3C, The Semantic Web Home Page. – http://w3.org/sw/
10. AgentWeb, resource guide and newsfeed covering Agent-related technologies. – http://agents.umbc.edu/
11. A Model-Theoretic Semantics for DAML+OIL, W3C Note 18 December 2001. – http://www.w3.org/TR/daml+oil-model
12. An Axiomatic Semantics for RDF, RDF-S, and DAML+OIL, W3C Note 18 December 2001. – http://www.w3.org/TR/daml+oil-axioms
13. DAML+OIL (March 2001) Reference Description, W3C Note 18 December 2001. – http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218
14. XML Schema, RDF Schema & DAML Comparison. – http://www.isi.edu/expect/Web/semanticWeb/comparison.html
15. W3C Web Ontology. – http://www.w3.org/2001/sw/WebOnt/
16. Requirements for a Web Ontology Language, W3C Working Draft. – http://www.w3.org/TR/Webont-req/
17. SemanticWeb: роль XML и RDF/ С. Декер, С. Мельник, Ф. ван Хермелен, Д. Фенсел, М. Клейн, Д. Брукстра, М. Эрдманн, Я. Хоррокс // Открытые системы. 2001 – № 9. – http://www.osp.ru/os/2001/09/041.htm.
18. Distributed XML: the role played by XML in the next-generation Web, Edd Dumbill. – http://www.xml.com/pub/2000/09/06/distributed.html
19. XML and the Web, by Tim Berners-Lee, XML World 2000, Boston 2000/09/06. – http://www.w3.org/2000/Talks/0906-xmlWeb-tbl/
20. An Introduction to the Resource
Description Framework by Eric Miller, D-Lib Magazine, May 1998. – http://www.dlib.org/dlib/may98/miller/05miller.html
21. Putting RDF to Work, Edd Dumbill. – http://www.xml.com/pub/2000/08/09/rdfdb/index.html
22. RDF tutorial, Pierre-Antoine Champin (for developers). – http://www710.univ-lyon1.fr/~champin/rdf-tutorial/
23. W3C Web Service`s Home
Page. – http://www.w3.org/2002/ws/
24.Web Services Architecture, W3C Working Draft 14 November 2002. – http://www.w3.org/TR/ws-arch/
25.Web Services Architecture Requirements, W3C Working Draft 14 November 2002. – http://www.w3.org/TR/wsa-reqs
26.Web Services Architecture Usage Scenarios, W3C Working Draft 30 July 2002. – http://www.w3.org/TR/ws-arch-scenarios/
27. Web Services Description Requirements, W3C Working Draft 28 October 2002. – http://www.w3.org/TR/ws-desc-reqs/
28. Web Services Glossary, W3C Working Draft 14 November 2002. – http://www.w3.org/TR/ws-gloss/
29. Лифшиц Ю., Семантический Веб, лекция, 2006. – http://logic.pdmi.ras.ru/˜yura/internet.html
30. The Semantic Web. By Tim Berners-Lee, James Hendler and Ora Lassila. Scientific American, May 17, 2001. – http://www.scientificamerican.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21
31.The Semantic Web Roadmap, Tim Berners-Lee, 1998. – http://www.w3.org/DesignIssues/Semantic.html
State of The SemanticWeb, Ivan Herman, Stavanger, Norway, 2007.
33. Semantic Web for Developers. – http://logicerror.com/semanticWeb-Webdev
34. Extensible Markup Language (XML) 1.0, W3C Recommendation 10.02.1998. – http://www.w3.org/TR/1998/REC-xml-19980210
35. RDF/XML Syntax Specification (Revised), W3C Working Draft 25 March 2002. – http://www.w3.org/TR/rdf-syntax-grammar/
36. RDF Model Theory, W3C
Working Draft 29 April 2002. – http://www.w3.org/TR/rdf-mt/
37. RDF Semantics, W3C Working Draft 23 January 2003. – http://www.w3.org/TR/2003/WD-rdf-mt-20030123/
38.RDF Primer, W3C Working Draft 11 November 2002. – http://www.w3.org/TR/rdf-primer/
39.RDF Test Cases, W3C Working Draft 12 November 2002. – http://www.w3.org/TR/rdf-testcases
40.RDF Tutorial, W3C. – http://www.w3.org/TR/rdf-tuturial
41.Resource Description Framework (RDF): Concepts and Abstract Data Model, W3C Working Draft 29 August 2002. – http://www.w3.org/TR/rdf-concepts/
42.Resource Description
Framework (RDF) Model and Syntax Specification, W3C Recommendation 22 February 1999. – http://www.w3.org/TR/REC-rdf-syntax/
43.Using RDF to model multimedia content – slide «Relation with MPEG-7″. – http://www.w3.org/Architecture/1998/06/Workshop/paper29/slides/slide13-0.html
44. RDF syntax, W3C Recommendation. – http://www.w3.org/TR/PR-rdf-syntax
45. RDF Schema, W3C Working Draft. – http://www.w3.org/TR/PR-rdf-schema
46.RDF Vocabulary Description Language 1.0: RDF Schema, W3C Working Draft 23 January 2003. – http://www.w3.org/TR/2003/WD-rdf-schema-20030123/
47.Topic Maps (XMT). – http://www.topicmaps.org/
48.Text Encoding Initiative. – http://www.tei-c.org/
49.Metadata Encoding and Transmission Standard. – http://www.loc.gov/standards/mets/
50. Metadata Object Description Schema (MODS). – http://www.loc.gov/standards/mods
51.Encoded Archival Description (EAD). – http://www.loc.gov/ead
52.Learning Object Metadata (LOM). – http://www.ltsc.ieee.org/wg12/
53. Online Information Exchange (ONIX). – http:// www.editeur.org/onix.html
54.Introduction to the Semantic Web, Ivan Herman, W3C, International Conference on Dublin Core and Metadata Applications, Singapore, 2007-08-31. – http://www.w3.org/2007/Talks/0831-Singapore-IH/
55.The Friend of a Friend (FOAF) project. – http:// www.foaf-project.org/
56.FOAF Vocabulary Specification. – http://www.xmlns.com/foaf/0.1/
57.FOAF Vocabulary Specification. – http://www.xmlns.com/foaf/spec/
58.Semantically-Interlinked Online Communities. – http://www.sioc-project.org/
59.Description of a Project Description of a Project (DOAP) vocabulary. – http://www.usefulinc.com/doap/
60.RFC2413, Dublin Core Metadata for Resource Discovery. – http://www.faqs.org/rfcs/rfc2413.html
61. «DublinCore Qualifiers/Substructure”. – http://www.loc.gov/marc/dcqualif.html
62. «DublinCore qualifiers». – http://www.roads.lut.ac.uk/Metadata/DC-Qualifiers.html
63.Dublin Core Element Set, Version 1.1 – Reference Description. – http://www.dublincore.org/documents /1999/07/02/dces/
64.vCard. – http://www.imc.org/pdi/
65. Names in Dublin Core, Diane I. Hillmann. – http://purl.org/dc/documents/notes/notes-hillmann-19981027.htm
66.»Guidance on expressing the Dublin Core within the Resource Description Framework
(RDF)». – http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/
67.Representing vCard v3.0 in RDF, Renato Iannella. – http://www.dstc.edu.au/RDU/RDF/draft-iannella-vcard-rdf-00.txt
68.ROADS. – http://ukoln.bath.ac.uk/roads/
69.Resource Description Framework (RDF) Model and Syntax Specification, W3C Recommendation 22 February 1999. – http://www.w3.org/TR/REC-rdf-syntax/
70.Open Directory Project. – http://dmoz.org/
71.RDF Vocabulary Description Language 1.0: RDF Schema, W3C Working Draft 23 January 2003. – http://www.w3.org/TR/2003/WD-rdf-schema-20030123/
72.DAML+OIL Project Homepage. – http://www.w3.org/TR/daml+oil-reference
73.DAML+OIL Primer. – http://www.w3.org/TR/rdf-primer/#ref-damloil
74. Язык OWL. – http://www.w3.org/TR/owl-ref/
75. OWL, Primer. – http://www.w3.org/TR/rdf-primer/#ref-owl
76.XML-QL: A Query Language for XML. Submission to the World Wide Web Consortium 19.08.1998. – www.w3.org/TR/NOTE-xml-ql/
77.XQL Tutorial (XML Query Language), Jonathan Robie. – http://www.metalab.unc.edu/xql/xql-tutorial.html
78.XML-QL : A Query Language for XML User’s Guide Version 0.9. – http://www.research.att.com/~mff/xmlql/doc/
79.Home of the W3C’s XML Query working group. – http://www.w3.org/XML/Query
80.A Query Language for XML. Alin Deutsch, Mary Fernandez, Daniela Florescu.University of Pennsylvania, Philadelpha. – http://www8.org/w8-papers/1c-xml/query/query.html
81.RDF Query Language (RQL). – http://139.91.183.30:9090/RDF/VRP/index.html/RQL/index.html
82.The RDF Query Rules, W3C. – http://www.w3.org/2001/11/13-RDF-Query-Rules/
83.The RDF Query Language (RQL), W3C. – http://139.91.183.30:9090/RDF/RQL/
84.RDF Query Specification, December 3, 1998. – http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html
85.TRIPLE HomePage. – http://triple.semanticWeb.org/
86.Sesame, storage and querying middleware system for RDF and RDF Schema. – http://sesame.aidministrator.nl/
87.SPARQL Query Language for RDF W3C Candidate Recommendation 14 June 2007. – http://www.w3.org/TR/rdf-sparql-query/
88.The Semantic Web In Breadth, Aaron Swartz. – http://logicerror.com/semanticWeb-long
89.Математические предпосылки (логика предикатов) – Mathematical Background (Predicate Logic), Джон Сова (John Sowa’s). – http://www.jfsowa.com/logic/math.htm
90. RIF: Use Cases and Requirements, W3C Working Draft 10 July 2006. – http://www.w3.org/TR/2006/WD-rif-ucr-20060710/
91.RuleML. – http://www.ruleml.org/
92.SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission 21 May 2004. – http://www.w3.org/Submission/SWRL/
93. Презентация доклада «Семантический Веб: текущее состояние исследований и перспективные направления», Уланов Д., ИСП РАН, 03.02.2006.- http://dulanov.wordpress.com/2006/02/02prezentatsiya_o_proekte_semanticheskii_veb/
94. SOAP Version 1.2 Part 0: Primer, W3C Candidate Recommendation 19 December 2002. – http://www.w3.org/TR/2002/CR-soap12-part0-20021219/
95.SOAP Version 1.2 Part 1: Messaging Framework, W3C Candidate Recommendation 19 December 2002. – http://www.w3.org/TR/2002/CR-soap12-part1-20021219/
96.SOAP Version 1.2 Part 2: Adjuncts, W3C Candidate Recommendation 19 December 2002. – http://www.w3.org/TR/2002/CR-soap12-part2-20021219/
97.SOAP Version 1.2 Specification Assertions and Test Collection, W3C Working Draft 26 June 2002. – http://www.w3.org/TR/soap12-testcollection
98.SOAP Version 1.2 Usage Scenarios, W3C Working Draft 26 June 2002. – http://www.w3.org/TR/xmlp-scenarios/
99.SOAP 1.2 Attachment Feature, W3C Working Draft 24 September 2002. – http://www.w3.org/TR/soap12-af/
100.SOAP Version 1.2 Email Binding, W3C Note 3 July 2002. – http://www.w3.org/TR/soap12-email
101.Universal Description, Discovery, and Integration (UDDI) OASIS Standard. – http://www.uddi.org
102.Web Services Description Language (WSDL) Version 1.2, W3C Working Draft 24 January 2003. – http://www.w3.org/TR/2003/WD-wsdl12-20030124/
103.Semantic Markup for Web Services, W3C Member Submission 22 November 2004 http://www.w3.org/Submission/OWL-S/
104.Service Modeling Language, Version 1.1 W3C Working Draft 3 March 2008, http://www.w3.org/TR/sml/
105.Open Directory Project, RDF dumps. – http://dmoz.org/rdf.html
106.Google Search Engine. – http://google.com
107.SWAD-Europe: Mapping Semantic Web Data with RDBMSes, W3C Semantic Web Advanced Development for Europe (SWAD-Europe), 2003-01-23. – http://www.w3.org/2001/sw/Europe/reports/ scalable_rdbms_mapping_report/
108.Introduction and Overview to the Semantic Web, James A. Hendler , Rensselaer Polytechnic Institute, The 6th
International Semantic Web Conference and the 2nd Asian Semantic Web Conference, 11-15 ноября 2007г. – http://videolectures.net/iswc07_hendler_ios/
109.The 6th International Semantic Web Conference and the 2nd Asian Semantic Web Conference, 11-15 November 2007, Busan, Korea. – http://iswc2007.semanticweb.org/main/default.asp
110.Semantic Web Challenge Homepage. – http://challenge.semanticWeb.org/
111.Enrico Motta, The Open University, Semantic Web Applications, The 6th International Semantic Web Conference and the 2nd Asian Semantic Web Conference, 11-15 ноября 2007 г. –http://videolectures.net/iswc07_motta_swa/
112.Sean B. Palmer, The Semantic Web: An Introduction, 2001-09. – http://infomesh.net/2001/swintro
113.Semantic Web As “Perfection Seeking:” A View from Drug Terminology, Tuttle M., Brown S., Campbell K., Carter J., Keck K., Lincoln M., Nelson S., Stonebraker M., 2001.
114.Semantic Web Modeling and Programming with XDD, Anutariya, Wuwongse, Akama, Wattanapailin, In Proceedings of SWWS’2001.
115.Towards a principled approach to semantic interoperability, Euzenat, IJCAI 2001, Workshop on ontology and and information sharing, 2001, Seattle (WA US)
116.“Explorer’s Guide to the Semantic Web”, Thomas B. Passin, June, 2004, 304 p.
117.Библиография по тематике Semantic Web, Type of content, Class blog. – http://typecontent.net/blog/wp-content/uploads/2007/02/semanticbibliography.pdf
УДК 004.738.52
В связи с тем, что в Рунете зарождается сообщество веба данных, целями которого является развитие идей семантического веба, хочу несколько своих рассуждений опубликовать…
Все, что ниже написано, это мои рассуждения на тему веба данных и семантик веб, и имеет очень косвенное отношение собственно к сообществу веба данных. Я сам являюсь участником этого сообщества и рад тому, что оно создано. Давно пора )
Почему сообщества веба данных, а я говорю о развитии технологий Семантик Веб, а все просто, в последнее время, во многих зарубежных статьях активно продвигается термин «веб данных» (web of data), как ассоциация с понятием «Семантический Веб». Несмотря, на кажущуюся одинаковость этих понятий, эти понятия не являются эквивалентными. Да, в рамках концепции связанных данных (LinkedData) можно провести много параллелей между вебом данных и семантическим вебом, но разница то все таки есть… Начиная с основных акцентов в названии… По сути – веб данных – это связанные данные, но главный акцент Семантического Веба не на данные, которые связанные через Веб, а на знания (семантику данных), которые распределены по Веб. Вроде бы это одно и тоже – вот только данные, как факты о реальном мире, это часть знаний, распределенных по Веб. Часть!!!
А с другой стороны, данные – это вообще не знания – а структурированная информация, то есть веб данных – это структурированная информация, связанная между собой через Веб. А структура, всем известно, легко описывается в XML, и даже RDF, не надо привлекать. И связи через WEB в XML создаются легко через XLINK и XPointer. В контексте этих технологий я бы воспринял веб данных (конечно не как семантический веб, а как концепцию, имеющую право на жизнь)
Конечно, есть еще RDF, как связанные между собой ресурсы (семантические графы), и до появления RDFS не являющийся полноценной реализацией объектно-ориентированной системы (пусть и распределенной по веб). Но даже здесь RDF – это данные – факты о мире – ресурсы, как наборы связанных между собой экземляров классов. Но это же, один из нижних уровней Semantic Web (посмотрите по ссылке в википедии на рисунок стека понятий семантической паутины (семантического веба)). Нижних уровней!
Я, конечно понимаю, маркетинг это страшная сила. Так было, когда искусственный интеллект застрял в развитии – придумали онтологии и семантическую сеть (семантик веб), который можно населить интеллектуальными агентами (неявно подразумевая создание ИИ, только потом…). Два года назад Семантик Веб застрял в развитии, пропустив вперед web 2.0 и социальные сети. А теперь пришло время веба данных – время низкоуровневого семантического веба.
Но я, как и надеюсь, большинство читателей SHCHERBAK.NET, считаю,
что пусть будет лучше низкоуровневый Семантический Веб, чем ни какого.
Но всегда, есть другая сторона – я, как человек, работающий над проблемами онтологий и семантического веба почти уже десять лет, считаю, что Веб, может стать действительно семантическим, если внедрение Семантического Веба будет идти через положения инициативы Интеллектуального Веба (Intelligent Web). Вот это будет качественный рывок вперед!!! Рывок в мир агентов «Смитов» 
Мой и путь развития сайта SHCHERBAK.NET можно выразить в двух словах так:
«Semantic Web – > Intelligent Web»
10 февраля 2004 года Web Ontology Language (OWL) получил статус рекомендации W3C. Эту знаменательную дату многие считают официальным днем рождения Семантического Веба, потому хочу поздравить всех заинтересованных с этим праздником.
5 лет это конечно не много, но это время, за которое Семантический Веб превратился из академической разработки в технологию, применяемую в промышленных кругах. Пусть были времена «падения», когда говорили, что Семантический Веб – это технология, которую практически нереально внедрить в жизнь, ан нет, время берет свое, и практически все «большие» корпорации, начинают в той или иной мере внедрять Семантик Веб у себя, кто выборочными компонентами, а кто и интегрированными решениями.
Ведь уже ни для кого, не секрет, что развитие веб-сервисов и SOA, привлекло инвестиции в область Семантического Веба. А при чем здесь веб-сервисы и SOA спросите Вы, и я отвечу – «веб-сервисы стали отправной точкой для бизнеса в мир Семантического Веба». Они (веб-сервисы) показали эффективность слабосвязных систем, что на фоне финансовой целесообразности использования таких систем привело к росту инвестиций. Далее, все просто – наборы связанных веб-сервисов реорганизованы в слабосвязанные сервисные шины предприятий, целесообразность которых на сегодняшний день проверена ведущими американскими корпорациями».
Особенностью сервисных шин является использование таких известных технологий, как XML и XSLT. Но, вот проблема, XML и XSLT это технологии, которые обеспечивают эффективное развитие, расширение информационной инфраструктуры предприятий, только вот, с устранением противоречий есть проблемы и синтаксическая интероперабельность (способность к взаимодействию) уже все, что могла предложить – предложила, а этого оказалось мало.
А Семантик Веб в идее может на порядок усилить сервисные шины XML. Ведь простое внедрение RDF в XML через формат RDF/XML обеспечивает уже семантическую интероперабельность таких систем через уже разработанное программное обеспечение Семантического Веба. А это для мира бизнеса открывает качественно новые перспективы
Ответ на это прост, если не учитывать проблемы, которые я освещал в одном из предыдущим постов.
Cначала давайте определимся, что будем понимать под приложением Semantic Web.
Итак, если приложение построено с использованием таких средств Semantic Web, как XML, RDF, OWL, SPARQL, то такое приложение будем называть приложением Semantic Web первого типа.
В случае, если приложение реализует идеи Semantic Web, как концепции, тогда такое приложение назовем приложением Semantic Web второго типа.
Read the rest of this entry »
== Семантическая Паутина. Часть 4 ==
Сегодня я продолжу и завершу рассмотрение технологий, составляющих основу Семантической Паутины. В прошлой статье я начал рассказ об одной из наиболее популярных (и уже нашедших практическое применение в ряде веб-приложений) технологий – FOAF. FOAF позволяет нам создавать описания “своего профиля”, указывать то, с какими сайтами или документами вы взаимосвязаны, и (самая “соль” технологии) указывать “дружеские” отношения с другими участниками сети.
Однако перед тем как я перейду к рассмотрению программных средств позволяющих находить и визуализировать FOAF-информацию, рассмотрим смежную с FOAF технологию – XFN. Read the rest of this entry »
== Семантическая Паутина. Часть 3 ==
Я продолжаю рассказ о технологиях, которые составляют ядро Семантической Паутины. В прошлый раз я завершил краткое введение в RDF и рассказал о проекте Dublin core. Сегодня фокус внимания будет посвящен FOAF, XFN, openid, социальным сетям.
Люди – социальные существа: любят жить в коллективе, общаться, распространять сплетни и обсуждать других. К этому можно относиться по разному: осуждать бездельников, которые тратят свое или (что еще ужаснее) время вашего работодателя на бесконечных “одноклассниках” или “в-контактах”. Можно восхищаться новыми возможностями открытого обсуждения и обмена опытом. А можно просто делать деньги. Read the rest of this entry »
== Семантическая Паутина. Часть 2 ==
Я продолжаю рассказ о Семантической Паутине и технологиях, которые, возможно, никогда не изменят будущего, если вы не окажите им немного помощи. Вкратце: основная идея семантической паутины – добавить к существующим веб-страницам немного информации ориентированной на машинную обработку, добавить сведения о самой информации и о том в каких отношениях она находится с другими страницами сети. Когда это случится, то по Сети будут путешествовать автономные Семантические Агенты, похожие на ИскИны, (Искусственные Интеллекты из популярных научно-фантастических рассказов). Они будут помогать искать информацию, планировать рабочий день, брать на себя все больше и больше рутинной работы.
Почему я сказал “возможно, никогда не изменят будущего”? Read the rest of this entry »
== Семантическая Паутина. Часть 1 ==
Прогресс в IT похож на морские приливы: сначала волна энтузиазма штурмует берег обыденности и коммерческой целесообразности. Затем, будучи не в силах удержаться, волна отходит назад, с тем, чтобы набраться сил и спустя некоторое время попробовать еще раз захватить плацдарм. Сегодня я хочу поговорить о Семантической Паутине и микроформатах.
В начале 2000-ых годов я впервые услышал о идее которую пропагандировал Тим Бернерс-Ли. Это была идея Семантической Паутины (Semantic Web) и о том как она изменит привычный нам internet. Не секрет, что с самых первых дней развития internet предпринимались попытки создать такой способ представления информации в ней, чтобы указывать на ее логическое значение. Указать, что же хранится в том или ином абзаце или таблице. Придумали теги, такие как STRONG, EM – они должны были играть роль указателей на то, что какие-то части веб-страницы имеют более важное значение, дать акцент на них. Или, например, тег CITE, который должен был служить для хранения цитат или сносок на другую информацию. Тег ACRONYM мог бы указать на … акронимы. Или тег ADDRESS, который должен был бы хранить информацию об авторе документа. Все эти теги не только имели особые шрифты или отступы, но, прежде всего, должны были дать больше “информации об информации” поисковым машинам и браузерам. А теперь, положа руку на сердце, признайтесь, кто из вас слышал и тем более использовал эти возможности? Во всевозможных книжках про веб-программирование и верстку говорят, прежде всего, о том, как создать какой-то красивый эффект, о том, как сделать, чтобы что-то мигало, вертелось и двигалось. Все теги, о которых я упомянул выше (EM, CITE, ACRONYM), пали жертвой ряда обстоятельств: отшумевшая война браузеров, слабые визуальные возможности html заставляли использовать эти теги, прежде всего, для визуального оформления, не обращая внимания на их логический смысл. Эти теги были первой робкой попыткой сделать internet более целостным, что же … покойтесь с миром. Первоначальный этап, когда при разработке сайтов говорили только о его визуальном наполнении, картинках, flash-роликах прошел. Конечно, и сейчас визуальное оформление является важнейшим фактором, но по мере увеличения количества людей постоянно пользующихся internet-ом, ростом широкополосных сетей, бумом социальных сетей, с тем как internet становится все более близким для “домохозяек” и появлением новых моделей коммерции в internet, произошел возврат к старым идеям и попытка их реализовать на новой технологической базе.
УДК 519.71
Кучеренко Е.И., Павлов Д.А.
Рассмотрены проблемы анализа неполноты и избыточности онтологий при изменении и развитии их версий. Предложены критерии и алгоритмы выявления и локализации данных свойств. Установлены математические и логические связи неполноты и избыточности. Приведены рекомендации к практическому использованию теоретических результатов.
About problems of displaying of incompleteness and superfluity of subject of inquiry in ontological spaces
Ye.I. Kucherenko, D.A. Pavlov
There has spotted problems of appearance of elements of incompleteness and superfluity of ontologies during changes or development of their versions. There were suggested criteria and algorithms for displaying and localization of these properties. There were determined mathematical and logical relations between incompleteness and superfluity. Listed recommendations how to use these theoretical results in practice.
В настоящее время получили широкое распространение распределенные системы обработки данных и управления. В связи с чем, начали значительно развиваться идеи унификации представления информации. Одной из самых важных и разрабатываемых идей является использование онтологий. Сегодня уже предложен ряд высоко специфицированных языков представления онтологической информации, такие как OWL, OIL и DAML [1]. В основе всех указанных языков заложены возможности распределения информации, то есть написание отдельных частей онтологии и синхронизация их на основе механизмов ссылок.
Одной из сложнейших задач поддержки распределенной онтологии является сохранение ее целостности в процессе развития. Так, например, некоторое изменение версии одного из элементов онтологии может негативно сказаться на всей онтологии в целом. В ней могут возникнуть противоречия, неполнота либо избыточность, которые в ходе ее использования часто приводят к изначально ошибочным результатам. Сегодня предложен ряд методов по устранению проблем, связанных с тем, что информация, с которой работают автоматизированные либо автоматические системы обработки информации, является неполной либо избыточной [2, 3, 4, 5]. Однако эти подходы в значительной степени обладают функциональной ограниченностью, что требует новых подходов и решений. Поэтому формализованные новые методы решения данной задачи являются важными и актуальными.
Целью этой работы является нахождение на этапах использования онтологий таких противоречий как неполнота и избыточность данных. Поставленная цель может быть достигнута за счет введения оценочных критериев и алгоритмов их расчета, которые свидетельствуют о том, является ли новая онтология неполной либо избыточной по сравнению с предыдущей версией.
1. Постановка задачи
Существующие методы анализа онтологий разработаны как для общего решения задач [2, 3], так и для частных решений [4]. Данная статья имеет целью предложить ряд схем
выявления проблем неполноты и избыточности для последующей обработки. Данные формализмы должны быть применимы в системах, оперирующих онтологическими данными.
Необходимо:
- предложить и обосновать формальные критерии выявления неполноты (
) онтологической информации:
(1)
где 
– версия 
в момент времени 
, 
– пространство времени, в котором существует альтернативная версия онтологии;
- предложить и обосновать формальные критерии выявления избыточности ( 
) онтологической информации:
(2)
- разработать алгоритмы выявления и локализации свойств неполноты и избыточности в условиях заданных ограничений.
Для снижения сложности решения принять ограничения на входящую информацию типа:
- поступающие данные предоставлены строго в онтологическом виде;
- в системе должны храниться все предыдущие версии онтологий;
- при изменении версии онтологии специалист должен иметь возможность определить степень подобия версий.
2. Формальное представление неполноты и избыточности
Существует множество случаев, когда в обрабатываемой информации присутствует свойство неполноты (1).
Определение 1. Под неполнотой (1) будем понимать следующее: собрана не вся возможная информация (неполнота) или не вся необходимая (недостаточность) информация, для некоторых элементов определены не их точные описания, а лишь множества, которым эти описания принадлежат (недоопределенность); ряд элементов задачи описан лишь по аналогии с уже решавшимися задачами, имеется лишь «замещающее» описание (неадекватность) [6].
Помимо неточной и неполной информации в систему может зачастую поступать и избыточная информация.
Определение 2. Под избыточностью (2) будем понимать наличие в системе информации, которая не может быть использована для принятия решений.
Тогда к избыточности относятся сведения, не имеющие отношения к существу вопроса, и сведения в объеме, превышающем возможности своевременной их обработки [7].
Утверждение 1. Избыточность (2) представим как обратное подобие неполноты (1).
Справедливость утверждения 1 следует из определений (1) и (2).
Следствие 1. Положение утверждения 1 будем использовать для формализации разрабатываемых критериев.
Уточним основное понятие, используемое в данной работе [8].
Определение 3. Онтология – набор специфических выражений, используемый для описания знаний об определенной предметной области.
Основными элементами онтологии являются:
- классы – обобщенные категории вещей, используемые в предметной области;
- свойства – атрибуты, которые могут иметь представители классов.
Возможными направлениями анализа избыточности и неполноты являются методы и методики, использующие непосредственно онтологическую информацию для построения цепочек логического вывода, которые в результате формировали бы вывод о том, правильна ли данная онтология. Однако, для такой реализации требуется введение большого объема метаинформации об онтологии непосредственно, что вызывает трудности вычислительного характера [9].
Другим методом выявления неполноты и избыточности может быть непосредственное использование новой онтологии в ранее определенных условиях. В момент возникновения некоторой исключительной ситуации целесообразно определять место ее возникновения и причину, тем самым локализовать место несоответствия онтологий. Этот метод применим в условиях малых онтологий, которые постоянно полностью используются и решения, принимаемые на их основе, не используются в момент их формирования. Также такая реализация поиска требует постоянного «вживления» алгоритмов поиска во все программы, работающие с онтологией, что также вызывает трудности.
Анализ возможных решений показал, что для формализации процедур выявления неполноты и избыточности заданной онтологии целесообразно предложить методологию на основе рекурсивного анализа классов онтологий на предмет соответствия друг другу, с последующей проверкой класса контрольной выборкой объектов.
Замечание 1. Такая структура анализа логически вытекает из понятия онтологии и из поставленной задачи. Действительно, так как класс состоит из свойств, значениями которых в свою очередь выступают классы, естественно предположить, что неполнота либо избыточность одного из свойств класса влечет за собой неполноту либо избыточность класса на него ссылающегося. Данная проверка может быть осуществлена в момент прихода новой онтологии, либо в момент изменения внешней онтологии на которую ссылаются внутренние классы.
Рекурсивные процедуры анализа. Рекурсивные процедуры анализа основаны на анализе классов по их составляющим по свойствам.
Пусть заданы состояния некоторой онтологии или онтологии:
(3)
где 
– онтология в момент времени , 
– j-й класс онтологии,
(4)
где 
– онтология в момент времени 
,
– j-й класс онтологии, причем классы онтологии и подлежат сравнению на логическом уровне.
Утверждение 2. Онтология (4) является неполной относительно онтологии (3), если соответствующие в них классы обладают свойствами неполноты.
Утверждение 3. Онтология (4) является избыточной относительно онтологии (3), если соответствующие в них классы обладают свойствами избыточности.
Утверждения 2 и 3 справедливы в контексте решаемых задач, если принять истинность замечания 1.
Идентификация соответствия классов онтологий контрольным объектом. Проверка классов контрольным объектом основывается на предусловиях взятых из исходной
онтологии либо заданных отдельно. Такие предусловия оперируют со свойствами эквивалентности и неравенства объектов.
Пусть:
(5)
где 
– объект, представитель класса 
, а 
– объект, представитель класса 
.
Утверждение 4. Если 
, где 
и 
– рассмотрение объекта в контексте , то мы наблюдаем явление неполноты .
Действительно, утверждение 4 справедливо, если учесть, что суть положения заключается в том, что онтология не поддерживает различие двух объектов, принятые ранее (5), что, по сути, и является недостатком информации, которая должна была бы их различать.
Пусть:
(6)
Утверждение 5. Если 
, то мы наблюдаем явление избыточности .
Действительно, утверждение 5 справедливо, если учесть что при справедливости
новая онтология шире или глубже описывает предметную область и разделяет ранее одинаковые объекты.
Замечание 2. Проверка контрольными объектами также может включать более сложные операции на объектами, нежели эквивалентность и неэквивалентность, например, использование свойств «ни один из», но в общем случае они все сводятся к предложенной схеме.
Формирование вычисляемых критериев различия классов.
Введем критерий отличия по неполноте класса от класса 
. Он может быть определен с помощью следующей функции:
(7)
где 
– свойство класса, 
,
, 
.
Важно определить критерии отличия по избыточности от 
. Он может быть представлен в виде следующей функции:
(8)
где – свойство класса, ,, 
.
Для функций (7) и (8) характерна следующая взаимосвязь, которая проистекает из смыслового сравнения неполноты и избыточности:
(9)
Если учесть, что в ряде случаев указывает на , то есть свойство класса представлено классом, подлежащим дальнейшему анализу, то, очевидно, что (7) и (8) четко описывает рекурсивный поиск.
Эти функции оперируют с классами количество свойств которых (далее мощность) одинаково. Каждое из свойств одного класса имеет сравнимое с ним свойство в другом классе. Тогда перед их использованием будем использовать метод приведения классов:
(10)
где 
, 
, 
, 
, 
– структура выхода функции .
Таким образом, на выходе (10), имеем два класса, некоторые из свойств которых являются нулевыми и удовлетворяют следующему требованию:
(11)
где 
– функция критерия неполноты либо избыточности.
Для устранения проблем, связанных со сравнением образованных нулевых атрибутов введем ряд строго определенных значений функций:
,если 
(12)
(13)
(14)
где 
обозначает в данном контексте нулевой класс или класс, не описанный в онтологии.
Предложенные выше результаты во многом носят ограниченный характер, так как при развитии онтологий могут возникать или исключаться из рассмотрения некоторые из атрибутов
(15)
Также содержательная часть некоторых из (15) может быть представлена лингвистическими переменными [10, 11] при изменении их
мощностей:
|A| (16)
В связи с этим возникает необходимость новых подходов к оценке состояния (15) на основе нечеткой логики [11].
Анализ показал, что степенью сравнения классов согласно определений (1) – (3) и предложенных критериев (7) – (8) в нечетком пространстве состояний [10] может быть значение индекса нечеткости на основе, например, обобщенного расстояния Хемминга [11]:
(17)
где 
– мощность нечеткого множества атрибутов класса
, 
– четкое множество, ближайшее к нечеткому . Аналогично (17) определяется процедура для класса 
.
На основе нахождения нормы расстояния
(18)
Определяем степень сравнимости и как следствие, степень неполноты и избыточности в классах, согласно приведенных критериев.
Если
(19)
где 
– определенное экспертом исходя из особенностей предметной области допустимое значение расхождения, то можно говорить о близости объектов сравнения, об их полноте и неизбыточности.
Следует отметить также, что выявление нечетких критериев неполноты и избыточности с учетом (16) – (19) требует дальнейших исследований.
3. Алгоритмическое обеспечение
Рассмотрим алгоритмы реализации на примере определения различия классов и .
Пусть 
а 
В дальнейшем, примем для определенности 
, a 
, что ни в коей мере не сужает общности рассуждений. Тогда класс 
, а класс 
. Пусть попарно сравнимы между собой свойства 
и
, 
и
, 
и
.
Критерий неполноты. Алгоритм может быть представлен в виде:
Шаг 1. Выполним операцию нормализации (10).
где 
, 
теперь 
.
Шаг 2. Рассчитаем непосредственно количественное значение критерия по неполноте (7):
=(
+ 
+
+ 
+ 
+ 
)/6.
Используя (13) и (14), получим :
=(+ + + 1 + 0 + 0)/6.
Повторив рекурсивно расчет для функций
и , а также определив различия и c помощью (5) и (6), имеем четко определенное значение .
В следствие (11) имеем значение 
.
Шаг 3. Анализ полученных результатов.
Критерий избыточности.
Алгоритм может быть представлен в виде:
Шаг 1. Выполним операцию нормализации (10).
где ,
теперь .
Шаг 2. Рассчитаем непосредственно количественное значение критерия по избыточности (8):
=(
+ 
+
+ +
+ >
)/6.
Учтем взаимосвязь неполноты и избыточности (9). Тогда:
= (++ +
+
+ 
)/6.
Что в свою очередь
= (++ + 0 + 1 + 1)/6.
Пройдя рекурсию до конца, имеем значение критерия избыточности.
Шаг 3. Анализ полученных результатов.
Выполним оценку вычислительной сложности предложенных алгоритмов. Как следует из изложенного выше, в алгоритме используются преимущественно операции сравнения на предмет эквивалентности и операции суммирования. Это позволяет нам оперировать с классом операций, которые обладают близкой сложностью.
Утверждение 6. Верхняя оценка вычислительной сложности 
выполнения алгоритма по критерию временных затрат определяется согласно:
(20)
где 
– временные затраты на выполнение единичного такта алгоритма, 
– количество классов онтологии, 
– среднее число атрибутов в классе.
Действительно, максимальное число операций не может превысить число классов онтологии, тогда значения функций будут вычисляться не более чем n раз. Время выполнения одного такта алгоритма зависит от программной реализации и конфигурации вычислительной техники. С учетом ограничений на потребность онтологии в классах и атрибутах, можно предположить, что и по определению ограниченны. Тогда (20) ограничено, и число вычислительных операций растет прямо пропорционально размерам онтологии, как в ширину, так и в глубину, что и требовалось доказать.
4. Практическая реализация
Предложенные критерии и алгоритмы ориентированы на первичную обработку изменившейся структуры онтологии. Они применимы в системах онтологического поиска в сетях большой размерности, таких как Интернет либо некоторые корпоративные сети. В связи с этим, результаты данной работы могут быть востребованы в задачах упрощения разработок и развития онтологий, а также их последующей поддержки.
Существуют системы синтаксического и логического анализа [9], которые позволяют определить целостность текущей онтологии, но их применение влечет за собой большие вычислительные затраты, а также их использование не описывает динамику изменения версий.
Существуют также методы устранения неполных данных [12]. Эти методы имеют ряд практических приложений, но они используются в применении к статистическим данным, что в условиях использования онтологий не применимо. Применение полученных результатов позволило осуществить предварительный анализ динамики развития и изменения
онтологии, которые определяют различия новых версий по отношению к предшествующим. Это дает возможность определения ограничений на использование новых версий онтологий.
Важным аспектом при решении задач данного класса в системах большой размерности является оценка их сложности по критериям затрат временных и вычислительных ресурсов. При решении практических задач в Интернете подтверждено, что верхняя оценка сложности не превосходит (20).
Таким образом, требования к объему памяти при реализации предложенных алгоритмов соизмеримы с размерами описания онтологии, а время анализа значительно меньше, чем процесс непосредственной загрузки онтологии, что следует из сравнения верхней границы сложности вычисления и экспериментального замера времени загрузки. В связи с этим, к программным реализациям и техническим средствам нет необходимости предъявлять дополнительные требования, и реализация приложений может быть выполнена на персональных компьютерах, что чрезвычайно важно в практических реализациях. Минимальные требования к компьютерам для программной реализации: Intel Celeron 1000 MHz, 128 Mb Ram.
Анализ областей практического применения в значительной части определил перспективы работ. К ним, в первую очередь, следует отнести:
- взвешенное сравнение атрибутов. В настоящей схеме все атрибуты эквивалентны между собой, что в большинстве случаев не так;
- использование наработок логического анализа. Из онтологии при ее правильной организации зачастую можно извлечь дополнительную информацию, которая сама описывает изменение онтологии;
- создание механизмов динамической компоновки версий онтологии;
- представление динамики и результатов развития онтологий в нечетком пространстве состояний.
5. Выводы
1. Впервые определены и обоснованы формальные критерии выявления свойств неполноты и избыточности в онтологическом
пространстве сложных объектов.
2.На основе анализа формальных критериев впервые разработаны алгоритмы выявления и локализации свойств неполноты и избыточности онтологии в условиях заданных
ограничений. Данные подходы имеют важные преимущества над существующими решениями.
3. Для заданного класса алгоритмов определена верхняя оценка сложности по критерию вычислительных затрат при заданной версии реализации, которая не превышает
квадратичного значения от размерности объекта исследования.
4.Предложены рекомендации к практическому использованию полученных теоретических результатов в практических приложениях, что определяет практическую значимость
выполненной работы.
5. Определен круг перспективных исследований, с целью дальнейшего развития данного направления исследования критериев и алгоритмов в нечетком пространстве
состояний объекта, что позволит получить новые научные результаты и технические приложения.
Литература:
[1] Michael K. Smith, Chris Welty, Deborah McGuinness. OWL Web Ontology Language Guide, 2003 // http://www.w3.org/TR/owl-guide/.
[2] W. Liu, S. M. Easterbrook & J. Mylopoulos , Rule-Based Detection of Inconsistency in UML Model.
// Workshop on Consistency Problems in UML-Based Software Development, 2002. P. 106 – 123
[3] Paolo Liberatore Redundancy in Logic I: CNF Propositional Formulae // CoRR cs.AI/0211031: 2002
http://arxiv.org/abs/cs.AI/0211031
[4] Абрамов О.Ю. Избыточность в технических системах // Творчество во имя достойной жизни, Великий Новгород, 2001 http://www.natm.ru/triz/articles/abram/abram01.htm
Обработка нечеткой информации в системах принятия решений. / А.Н. Борисов, А.В. Алексеев, Г.В. Меркульева М.: Радиосвязь 1989. 304 с.
[7] Серый Е.С. Бизнес-словарь. Москва. 2003. http://www.businessvoc.ru/
[8] Jennifer Golbeck, Amy Alford, James HendlerOrganization and Structure of Information using Semantic Web Technologies. // Handbook of Human Factors in Web Design. Maryland, College Park 2003.
[9] Kenneth Baclawski, Mieczyslaw M. Kokar,Richard Waldinger, Paul A. Kogut Consistency Checking of Semantic Web Ontologies. // Lecture Notes in Computer Science, LNCS
2342, Springer, 2002. P. 454 – 459
[10] Кофман А. Введение в теорию нечетких множеств: Пер. с франц. М.: Радио и связь, 1982. 432 с.
[11] Tsokalas L.H. Uhrig R.E. Fuzzy and Neural Approaches in Engineering. New York: John Willer & Sons Enc., 1997. 587p.
[12] Warren Sarle. Handling missing or incomplete data. Information Technology Services at The University of Texas at Austin, 2004. http://www.utexas.edu/its/rc/answers/general/gen25.html
ДК 519.178, 519.711
Кучеренко Е.И., Павлов Д.А.
Работа в области разработки онтологий является в крайней степени наукоемкой и сопряжена с большими затратами времени и материальных ресурсов. Создание подходов, снижающих сложность такого рода разработок должно привести к массовому использованию онтологического представления знаний, что в свою очередь приведет к резкому скачку интеллектуализации информационных систем.
Некоторые из существующих подходов работы с развивающейся онтологией [1] ориентированы на внесение дополнительной метаинформации в ходе разработки онтологии и последующем семантическом анализе этих данных. Такой подход эффективен при строгой формальной разработке онтологий и не достаточно применим к стихийно развивающимся онтологическим структурам. Исследования [2-3], ориентированные на анализ процесса развития, изучают широкий набор базовых изменений в онтологии, но не уделяют внимания неявным последствиям изменений. В работе [4] предлагается метод поддержки адекватного развития онтологии, основанный на проверке целостности текущей версии.
Подходы [1-4], не смотря на то, что имеют ряд важных результатов, не достаточно полно формализуют процесс развития онтологии. Также в этих работах отсутствует возможность количественной оценки версий с точки зрения целостности, что не позволяет решать задачи максимизации и минимизации адекватности.
Работа, посвященная модульности онтологии в распределенных системах [5], ярко отразила тенденции в прикладных задачах использования онтологий, но оставила без внимания процессы изменения структуры в ходе доработки.
Разработка PROMPT [6] в рамках проекта Protégé[7] предлагает особый подход сравнения версий, но в ней не отражаются подходы использования внешних ссылок онтологии, а также не предусмотрено использование нечетких онтологий [8].
Очевидно, что исследования в области развития распределенных онтологий активно ведутся в разнообразных направлениях. Но в виду ряда недоработанных вопросов дальнейший поиск в этой области востребован и актуален. Целью работы, является разработка обобщенного подхода к представлению интенсивного онтологического развития, что должно в дальнейшем позволить создавать эффективные методы оценки и обработки таких процессов, что в свою очередь даст возможность разработать системы поддержки принятия решений при онтологическом инжиниринге.
Пусть существует онтологическая структура (ОС) представленная набором связанных нечетких онтологий [9]
где MO = {Onti} – множество всех онтологий входящих в ОС, MRI = {RIj}, конечное множество всех отношений импорта RI заданных на данной ОС.
Пусть элементы ОС подвержены изменению с течением времени. Изменения носят дискретный характер и вносятся в соответствии с синтаксисом выбранного языка представления онтологий. Такого рода изменения онтологий будем именовать интенсивным развитием.
Существует ряд основных типов различий существующих внутри онтологий одной предметной области:
терминологические отличия: для одних и тех же объектов используются различные имена AB, AI=BI;
отличия границ категорий: схожие категории не полностью совпадают; их уточненные понятия совпадают, но каждая из категорий может содержать объекты не классифицируемые, как объекты второй 
;
кодировочные: правильные значения свойств могут отличаться, могут использоваться различные шкалы
;
контекстные: терм одного значения в определенном контексте имеет абсолютно другое значение в другом 
;
уровня детализации: одна онтология более детально описывает предметную область, нежели другая Ont1 Ont2.
В рамках эволюционного развития предполагается, что будут наиболее явно наблюдаться различия в границах категорий, а также будет происходить изменение детализации описания предметной области.
Отметим, что при изменении контекста применения версий онтологии проверка адекватности перехода от версии к версии не несет смысловой нагрузки. Также в некоторой действующей онтологии переименование объектов и классов, а также изменение кодировки носит деструктивный характер по отношению к текущим пользователям данной онтологии, таким образом, такое изменение мы будем считать неадекватным.
разработать обобщенную модель интенсивного развития онтологии;
интегрировать разработанную модель с моделью экстенсивного развития ОС [9];
предложить рекомендации к прикладному использованию разработанной модели в задачах оценки адекватности развития.
Всякая онтология Ont может быть изменена с течением времени. Введем кортеж D, описывающий этапы развития Ont, при чем элементы кортежа представляются парой: онтология и момент времени создания данной онтологии. Интенсивное развитие есть
(1)
Введем функции, связывающие онтологию и время в соответствии с развитием D. Учитывая дискретность развития
, (2)
функция значения онтологии в момент t для развития D., (3)
где 
функция обратная (2).
Введем отношение версии такое, что
, то 
, (4) и наоборот, , то . В работе исследуется процесс эволюционного развития, при котором можно говорить о сравнимости версий онтологии и о том, что результат их сравнения может быть объективно интерпретирован в общем виде.
Определение 1. Сравнимыми онтологиями Ontx и Onty мы будем называть такие онтологии, для которых выполняется отношение близости
near(Ontx,Onty) = true. (5)
Работая с нечеткими онтологиями, а также при необходимости получения большей выразительности понятия близости, в ряде случаев имеет смысл применения непрерывного значения близости near(Ontx,Onty) [0,1]. Фактически, оценка близости двух онтологий – это не тривиальная задача, и она является предметом отдельных, дальнейших исследований в данной области. В статье для вычисления данного условия будем использовать упрощенную функцию, сравнивающую мощность пересечения двух версий и сумму мощностей их различий
, (6)
Исходя из исследований [10], онтология может быть отображена в виде ориентированного графа. Тогда пусть онтология Ont есть некоторый граф
Ont = <N,E>, (7)
где N – узлы онтологии, E – отношения между узлами (ориентированные дуги).
1. T-граф – концептуальная часть онтологии. На данном графе узлами являются классы T и отношения R, а дугами базовые
отношения, вводимые грамматикой данного языка онтологий.
2. А-граф – объектный граф. Его узлами является множество объектов онтологии, дуги – отношения между объектами, как вводимые грамматикой данного языка, так и введенные на T-графе отношения R.
3. ТА-граф – связующий между концептуальным и объектным. В качестве узлов содержит классы T и объекты A, принадлежащие этим классам, в качестве дуг здесь выступают отношения принадлежности объекта классу. Данный граф является двудольным.
Ont = T+ A + TA (8)
Принимая во внимание содержательную часть трех подграфов графа (8) часть его узлов в ряде случаев выступает в качестве дуг (отношения R), независимое рассмотрение описанных подграфов по отдельности снимает данную коллизию.
Исходя из поставленной задачи дуги Т-, ТА- и А-графов являются нечеткими, нечеткость которых выражается в существовании либо функции принадлежности (x), либо непосредственно ее значения, интерпретируемых как уверенность в существовании данного отношения.
Необходимо отметить, что декомпозиция (8) не является единственно возможной. В ряде источников [11] TA- и А-графы рассматриваются как один. Также возможна и более глубокая декомпозиция, зависящая от специфических особенностей онтологии. Предлагаемое разложение универсально и легко осуществляемо в рамках существующих прикладных реализаций структуры онтологии.
Подграфы онтологии неравнозначны, для них характерны зависимости и подчиненные связи.
Отметим, что независимым элементом A и от элемента B онтологии Ont – это такой элемент, для которого верно:
AI = const, 
, и записывается 
,
где AI интерпретация данного элемента онтологии с помощью некоторой функции интерпретации 
,значит, что B может принимать любые значения, возможные в рамках данной онтологии.
Тогда один подграф G1 зависит от другого G2, nezav(G1, G2) = false, тогда и только тогда когда 
. В таком случае можем строить иерархию подграфов аналогично иерархии, возникающей при интенсивном развитии ОС.
Атомарность развития
При развитии всякого графа (7) будем различать изменение структуры узлов N и структуры связей E графа онтологии. Изменение структуры узлов N для поставленной задачи может состоять только из удаления и добавления узлов inc(N), dec(N).
Изменение структуры связей также заключается в добавлении и удалении связей inc(E), dec(E), а также изменении значения функции принадлежности ch(E).
Отметим, что изменение структуры связей может напрямую зависеть от изменения структуры узлов. Так как всякая связь E соединяет два узла, то удаление одного из этих узлов автоматически влечет удаление связи E. Такое удаление будем называть подчиненным.
dec(N) {dec(E)i}
Для сохранения общности, пусть добавление на данном этапе развития всех связей E, использующих добавленный узел N, также будем называть подчиненным.
inc(N){inc(E)i}
Тогда единичный этап развития онтологии можно описать как кортеж, состоящий из пяти обособленных элементов
dev(Ont1,Ont2)= <inc_N,dec_N,inc_E, dec_E,ch_E>, (9)
где inc_N, dec_N – множества добавленных и удаленных узлов с подчиненными связями, inc_E, dec_E – множества добавленных и удаленных независимых связей, ch_E – множество измененных связей.
Отметим что для четкой онтологии ch_E всегда .
Ont* =norm(Ont)= <N,E*>|Ont =<N,E> EE*,E*/E= {Rinfi} , (10)
где Ont* –результирующая онтология, E*– измененная структура дуг графа онтологии, Rinf– неявные отношения, полученные путем логического вывода из уже имеющихся знаний.
В существующих решениях в области нормализации онтологий преобладает подход вычисления неявно заданных знаний [11, 12].
Утверждение 1. Если онтологии, полученные в результате нормализации (10), равны, то исходные онтологии равны.
если Ont*x = Ont*y, где Ont*x =norm(Ontx), Ont*y =norm(Ontx), то Ontx = Ontx.
Действительно, всякая нормализация вводит дополнительные, неявные утверждения на основании правил формальной логики. При чем семантика добавленных знаний полностью повторяет общую семантику онтологии. Таким образом, при нормализации выполняются эквивалентные преобразования.
Учитывая то, что нормализация онтологического графа является нетривиальной задачей и может решаться различными методами и при этом иметь различный результат, при сравнении двух онтологий будем использовать единые механизмы нормализации.
Рассмотрим некоторую распределенную ОС Struct = <MO, MRI>.
Пусть всякой Onti MO соответствует некоторое развитие Di (1), i=1,I.
Предположим, что для всякого значения времени t мы можем построить соответствующую структуру импортов MRI(t).
Рисунок 1 – Пример схемы гибридного
развития ОС
Тогда
, (11)
является гибридным развитием ОС. Пример такого вида структуры отражен на Рисунке 1.
Рассмотрим главные особенности структуры (11).
В целом 
зависит от двух групп переменных 
и 
. При фиксации одной из групп переменных наблюдаем следующее:
При выполнении условия
, MRI(t)=MRI=const, (12)
наблюдаем процесс интенсивного развития при статическом состоянии экстенсивной структуры. При отсутствии изменения в структуре импортов при развитии, изменение всей ОС можно рассматривать как набор параллельных процессов интенсивного развития отдельных онтологий.
Вторым случаем, в котором содержательная часть ОС постоянна, а структура импортов меняется, является процесс, рассмотренный в [9], и характеризующий композицию либо декомпозицию онтологии, а также добавление и удаление псевдоимпортных и дублирующихся связей:
, =MO=const, (13)
Гибридное развитие ОС может содержать разрывы в функциях значения онтологии. Например, представим, что некоторая онтология Ont была в ходе развития заменена двумя (или более) онтологиями Ont1 и Ont2, при чем Ont = Ont1 Ont2.
Из функции (6) очевидно, что 
.
В то же время 
.
Таким образом, мы наблюдаем разрыв развития D и появление развитий D1 и D2 (Рисунок 2) (по оси ординат комплексная оценка адекватности изменения версии Ad [13]).
D-> D1,D2.
Очевидно, что возможна и обратная ситуация
D1,D2 ->D.
В таком случае будем говорить об обобщенном интенсивном развитии,
, (14)
где J(t) – количество онтологий в момент времени t, относящихся к развитию D. Развитие (14) является частным случаем общего гибридного развития.
Тогда (2) необходимо обобщить до
. (15)
Рисунок 2 – Разветвление при интенсивном развитии
В процессе развития ОС возможно возникновение неадекватности nAd.
Рассмотрим случай когда
Struct = <{Ont1, Ont2},imp(Ont1, Ont2)>.
Пусть импортируемая онтология Ont2 развивается интенсивно:
Dont2 = <{Ont21,t1},{Ont22,t2}>
Предположим что некоторый узел A, AOnt1, зависит от элемента B, BOnt21, nezav (A,B)= false.
nezav (A,B) = false | Struct(t) = <{Ont1, f Dont2(t2)}, imp(Ont1, Ont21)>, B=U,
где U – универсум. То есть утверждается зависимость A от некоторого абсолюта, что семантически не верно.
Struct (t2)= <{Ont1, Ont21},imp(Ont1, Ont21)>
nAd(Struct(t2)) = true. (16)
Тогда если nAd(Struct(t)) = true, где 
, то время t, будем называть временем неадекватности.
Важно различать адекватность состояния nAd(Struct(t)) (16) и адекватность развития Ad(Ont1,Ont2) [13]. Состояние может быть неадекватным в силу избыточности либо неполноты в структуре. В то же время при развитии мы можем получать полностью адекватную структуру, но она будет настолько отличаться от своей предыдущей версии, что данное развитие будет рассматриваться как неадекватное.
Определение 2. Если nAd(Struct(t)) = false, tt0, то развитие такой структуры мы будем называть всюду структурно адекватным.
Определение 3. Если nAd(Struct(t)) = false, tt0, то развитие такой структуры – частично структурно адекватное.
Развитие такого рода обуславливается глубоким распараллеливанием процесса разработки, который не позволяет синхронизировать структуру на всех этапах.
Определение 4. Если nAd(Struct(t)) = true, tt0, то развитие такой структуры – структурно неадекватное.
Такого рода структуры наиболее точно описывают развития структур в Интернет, например FOAF [15].
Для случаев частичной структурной адекватности либо структурной неадекватности важным является поиск верхней границы адекватного состояния. Фиксируя некоторое время развития t онтологии Ont, мы можем обнаружить неадекватность структуры. Тогда применение предыдущих версий онтологий, связанных с Ont может привести к адекватности всей структуры.
rb(fD(t1))= fD(t2), (17)
rbi(Ont) = rb1(rb2(…(rbi(Ont))…))| i0, rb0(Ont)= Ont.
rb({Onti}) ={{rb(Ont1), Ont2,…, OntI},{ Ont1,rb(Ont2),…,OntI},…,{Ont1,Ont2,…,rb(OntI)}}. (18)
Определение 5. Если существует некоторый набор {ji}, ji min, такой, что nAd(Struct(t)) = false, где 
, то структура 
является субадекватной.
При чем, для всякой онтологии, для которой соответствующее значение из набора {ji} равно 0, то данная субадекватная структура является для нее верхней границей адекватности.
.Действительно при разработке некоторой онтологии должно проверяться, что существуют все связи описываемые в ней.
Следует отметить, что множество ОС могут не обладать свойством адекватности, а также субадекватности. Не смотря на это, оценка адекватности их развития также необходима. Тогда перейдем к численной мере независимости онтологических ресурсов
nezav(A,B) [0,1], при чем (nezav(A,B)=true) (nezav(A,B)=1).
Алгоритмизация операций с моделями и рекомендации к практической реализации
Оценка адекватности развития произвольной ОС является многогранной и многоуровневой задачей. Рассмотрим наиболее общие и выразительные алгоритмы работы с развивающейся ОС (11).
Одной из базовых задач является нахождения адекватного состояния для данной субадекватной ОС. Исходя из адекватной структуры можно оценить важность отсутствующих элементов в исходной ОС.
Алгоритм поиска верхней границы адекватности развивающейся ОС.
Пусть существует развитие , для него необходимо определить все верхние границы адекватности для онтологии Ont в момент tk.
Шаг 1. Установка входных значений: входной ОС Struct и онтологии Ont из этой ОС для которой осуществляется поиск (DOnt = <Ont,t>), добавление Struct в очередь структур Queue.
Шаг 2. Текущая ОС Struct равна первому значению в очереди Queue. Из Queue удаляем первое значение.
Шаг 3. Проверка неадекватности (16) состояния текущей Struct: nAd(Struct(t)), если nAd(Struct(t)) = true переход на Шаг 4, иначе переход на Шаг 7.
Шаг 4. Выполняем операцию rollback (17) для набора онтологий текущей структуры. rb(Struct) = {Structi}
Шаг 5. Добавляем в очередь Queue все {Structi}, при чем проверяем, что такие значения Struct еще не помещались в очередь.
Шаг 6. Переход на Шаг 2.
Шаг 7. Добавляем текущую Struct в результирующий список Res.
Шаг 8. Если очередь Queue не пуста переход на Шаг 2,иначе переход на Шаг 9.
Шаг 9. Возвращение списка адекватных структур Res.
Шаг 10. Останов.
Онтологическое представление знаний сопряжено с внушительными требованиями к вычислительным ресурсам, а именно к объемам памяти v и времени расчета t. В связи с этим любые алгоритмические решения в этой области требуют проверки на предмет сложности. Рассмотрим алгоритм на предмет верхних границ вычислительной сложности. Важнейшими параметрами в нем являются размерность ОС и длительность оценки адекватности текущей структуры adt(Struct).
Оценим верхнюю границу сложности поиска адекватного состояния структуры по критерию временных затрат,
C_RBt = k_rbt* (Ji)*adt(Struct), (19)
где Ji – количество версий i онтологии, k_rbt – параметры системы.
Очевидно, что большое количество элементов ОС порождает взрыв размерности C_RBt.
Для предлагаемого алгоритма целесообразно использование предобработки, позволяющей снизить размерность области поиска. Такая предобработка должна включать выбор заведомо правильных версий онтологий в ОС. Здесь целесообразно сохранение результатов вычислений в качестве метаинформации онтологии. Такое сохранение позволит
значительно сократить размерность каждого из Ji только до того числа, которое еще не было ни разу обсчитано.
C_RBv = k_rbv* I *adv(Struct), (20)
где I – мощность экстенсивной составляющей развития ОС, adv(Struct) – затраты памяти необходимые для вычисления адекватности, которые включают наборы элементов онтологий, которые имеют внешние ссылки, k_rbv – константа параметров среды.
Предлагаемая модель во многом базируется на подходах концепции Semantic Web, которая предполагает разностороннее использование онтологий. Это позволяет говорить об объективном отражении теоретических разработок в практической реализации модели в рамках данной концепции.
Проследим поведение модели на существующей ОС [16]. Проект SWEET (Semantic Web for Earth and Environmental Terminology) ориентирован на использование
научными сотрудниками различных направлений. Для интеграции множества разнородной информации в проекте используется ряд связных онтологий в формате OWL. Отметим, что в данный момент проект находится в стадии активной разработки, и элементы интенсивного развития присутствуют на всех уровнях структуры.
Рассмотрим процесс интенсивного развития базовой онтологии ОС SWEET, которой является онтология “units”. Она содержит информацию о физических единицах измерения. Рассмотрим ее в трех версиях Dunits= <{units1, t1}, {units2,t2}, {units3,t3}>
Известно, что переход от версии 1 к версии 2 был вызван требованием возможности добавления базовых пропорций:
«процент», «промилле» и др. Также в изменение версии вошло изменение представления понятия «ампер» в виде строки. Множество добавленных объектов отражено количественными характеристиками строки RD12 Таблицы 1.
Переход от версии 2 к версии 3 сопровождался меньшим количеством изменений, но они носили более сложный характер. Так, в частности, появился ряд новых связывающих отношений между уже существовавшими объектами, а также были исправлены некоторые строковые значения. Наиболее ярко сложный процесс изменения отражен столбцом А строки RD23 Таблицы 1.
Таблица 1 – Кортежи развития подграфов (9) онтологии units.
|
T |
TA |
A |
|
| RD12 |
<0, 0, 0, 0, 0> |
<13N+91E, 0, 0,0, 0> |
<13N+14E, 1N+1E, 0, 0, 0> |
| RD23 |
<0, 0, 0, 0, 0> |
<1N+10E, 0, 0, 0, 0> |
<3N+4E, 1N+1E, 2E, 1E, 0> |
| RD13 |
<0, 0, 0, 0, 0> |
<14N+101E, 0, 0, 0, 0> | <16N+18E, 2N+2E, 2E, 1E, 0> |
Итак, мы наблюдаем онтологическую структуру на трех этапах развития:
t1, t2 и t3. Отметим, что близость (5) для всех частных развитий выполняется. Проверим неадекватность (16) состояний на всех этапах nAd(Struct(t1))= false nAd(Struct(t2))= true nAd(Struct(t3))= true
Найдем субадекватную структуру для space2.
Расчет показывает, что такого развития не существует. Следовательно развитие space2 не адекватно.
Найдем субадекватную структуру для subst2.
Struct = <{units2,bio2,hum_act, mat_th, earth, space1,num1,prop2,subst2,time }, MRI>.
Данные разрозненные примеры прикладного использования могут быть интегрированы и задействованы в единой системе управления онтологией (СУО), которая будет использовать не только текущее состояние онтологии, но и предыдущие ее версии.
В данной статье получили дальнейшее развитие модели развития онтологий, что позволило аналитически разбить процесс изменения онтологий на ряд простых классов, что, в свою очередь, позволяет решать задачу управления развивающейся онтологией методами, соответствующими классу изменения. При анализе модели развития были затронуты вопросы близости, нормализации и декомпозиции онтологий.
Предложена векторная модель оценки процесса развития на основе критериев неадекватности, неполноты и избыточности знаний онтологии.
Данный подход позволяет строить различные аналитические методы поддержки развивающейся онтологической структуры с помощью базовых
операций с векторами.
Впервые предложена модель гибридизации развития онтологий, которая включает формальные модели экстенсивного и интенсивного развития
онтологических структур и которая позволяет рассматривать всякое онтологическое развитие в общем виде. Выделены и обоснованы основные
классы развития в контексте гибридной модели. Гибридная модель развития в конечном итоге дает возможность полностью охватить
жизненный цикл онтологической структуры, что необходимо при создании системы управления распределенной ОС.
Для разработанных моделей были предложены рекомендации к прикладному использованию, что дает возможность реализации программных решений
моделирования и анализа процессов развития онтологических структур и тем самым подчеркивает значимость теоретических исследований.
Разработаны концептуальные алгоритмы, функционирующие в рамках модели. Произведена грубая оценка верхней границы сложности
предложенных алгоритмов.
Stuckenschmidt H., Klein M. Integrity and change in modular ontologies. In Proc. IJCAI’03, Acapulco, Mexico, 2003.
Noy N. F., Sintek M., Decker S., Crubezy M., Fergerson R. W., Musen M. A. Creating Semantic Web Contents with Protege-2000 // IEEE Intelligent Systems, 2001, 16(2). P. 60-71.
Павлов Дмитрий
Цель работы заключается в устранении критичности процесса поиска в распределенной онтологии. Поставленная цель, ввиду тенденций роста применения технологии Semantic Web, является актуальной и требующей практической реализации.
Введение
За последние несколько лет IT индустрия сильно шагнула в развитии автоматического поиска, сбора и обработки информации. Одним из ведущих направлений этой отрасли является технология Semantic Web[1], продвигаемая W3 консорциумом. Среди последних значительных достижений данной технологии спецификация языка описания онтологий OWL[2]. Вместе с появлением такого мощного инструмента возник ряд практических задач его непосредственного внедрения и применения. Решенными задачами на сегодняшний день являются: визуальные среды разработки онтологии[3,4]; спецификация агентного взаимодействия по средством метаописания механизмов передачи и обработки данных[5]; проверка формальной целостности онтологии[6] и пр. В данной работе предполагается использование этих решений.
Важным аспектом развития онтологии является ее распределяемость, онтология позволяет обособить ее части и расставить в них ссылки друг на друга. В момент возникновения потребности в получении информации по ссылке передается запрос серверу, обладающему документом, соответствующим этой ссылке и работа приостанавливается на время ожидания ответа. В условиях сложных онтологий процесс получения информации по ссылке может инициироваться сотни и тысячи раз, и требовать больших временных и ресурсных затрат. Таким образом, процесс поиска в онтологии является потенциально критическим моментом общей работы и при отсутствии ресурсосберегающих алгоритмов качество работы всей системы при использовании онтологии может не удовлетворять текущим потребностям рынка.
Цель работы заключается в устранении критичности процесса поиска в распределенной онтологии. Поставленная цель, ввиду тенденций роста применения технологии Semantic Web, является актуальной и требующей практической реализации.
1 Постановка задачи
Изначально онтология предполагается как нечто, что можно разделить на элементы, путем указания ссылок друг на друга. Ввиду практической постановки задачи, условимся, что онтология представлена на языке OWL.
Разделяемая структура рождает задачу поиска элементов при использовании предоставляемых ссылок:
SELECT a FROM uri WHERE resource=»uri#a», (1.1)
где а – элемент онтологии, uri[7] – ссылка на элемент, resource – специфицированный элемент RDF[8].
Помимо простого нахождения элемента онтологии, сразу заложим требования на более глубокий поиск, а именно – поиск элементов эквивалентных данному:
SELECT a FROM * WHERE a=b, (1.2)
где а и b – элементы онтологии.
Также в углубленный поиск должна входить возможность дополнения тройки субъект-предикат-объект, при отсутствии одного из элементов, что тоже является поиском:
SELECT a FROM * WHERE [a, R, b], (1.3)
где [a, R, b] – тройка субъект-предикат-объект, а – один из недостающих элементов тройки.
Исходя из поставленной цели определим потенциальные источники повышения эффективности работы системы. Во-первых, повышение эффективности использования времени, что заключается в распараллеливании процесса поиска, и сокращении количества повторений одинаковых операций. Во-вторых, оптимизация использования ресурсов, которая предполагается в распределении элементарных задач поиска между отдельными хранилищами онтологии, так как линейный рост обрабатываемой информации в условиях одного адресного пространства ведет к нелинейному росту потребности в ресурсах. Оба направления повышения эффективности требуют организации взаимодействия между рабочими структурными единицами сети.
Таким образом, необходимо предложить алгоритм либо ряд алгоритмов онтологического поиска, выполняющие 1.1, 1.2, 1.3, а также их взаимные вариации в условиях распределения данных в сети. Представленные алгоритмы должны базироваться на общих принципах языка OWL и быть обоснованными с точки зрения оптимальности.
2 Онтологический поиск в контексте OWL
Определимся с основными понятиями, которыми мы будем оперировать.
2.1 Сеть
Ont = Σ Stori, i=1,n, (2.1)
где Ont – распределенная онтология, Stori – часть онтологии, находящаяся в i хранилище данных, n – число хранилищ.
Рисунок 2-1 Пример топологии сети
Сеть (Рис. 2-1), в которой функционирует онтология, будем рассматривать как направленный граф, обладающий не всеми дугами. Узлами графа являются хранилища данных, таким образом число узлов – n. Дуги графа – ссылки, которыми обладают хранилища.
Допущение 1. Пусть в графе нет обособленных вершин.
Этим допущением мы исключаем случаи, когда не возможно вернуть наиболее полный ответ, что противоречит условиям поставленной задачи.
Допущение 2. В топологии сети не присутствуют циклы. В случае, если каким-либо путем запрос будет адресоваться узлу, сформировавшему его, он будет игнорироваться.
Дуги между узлами возникают в момент указания внешних ссылок в элементе онтологии. Помимо определения узла-соседа непосредственно из имени документа вводится форсированное объединение, когда известно, что разные документы хранит один и тот же узел. В этом случае в данном узле помещается объект, в котором указан набор пространств имен, обрабатываемых другим узлом.
Таблица 2.1 – Формирование дуг сети.
| URI | Узел-сосед | Элемент |
| http://www.w3.org/2002/07/owl#Class | http://www.w3.org/2002/07/owl | class |
| http://www.w3.org/2001/XMLSchema#float
http://www.w3.org/2001/XMLSchema#string |
http://www.w3.org/2001/XMLSchema | float
string |
| rmi://127.0.0.1/1.owl#a
rmi://127.0.0.1/2.owl#b |
Форсировано объедине\\нный – localhost | a
b |
2.2 Поиск
Теперь определимся с непосредственным результатом выполнения глобального поиска, то есть фактическим результатом работы системы, функцией search(Ont, query0).
Определение 1. Search(Ont, query0) возвращает наиболее полно описанную элементарную сущность языка OWL, отвечающую базовому запросу query0.
Под элементарной сущностью OWL мы понимаем класс, свойство либо объект, а под запросом query0 мы подразумеваем один из запросов указанных в 1.1 – 1.3.
Наиболее полное описание достигается только в результате работы с онтологией целиком. Чтобы не решать задачу поиска силами одного сервера обозначим порядок дифференциации нагрузки в рамках отдельных серверов, введем понятие локального поиска local_search(Stori, queryk).
Определение 2. Под локальным поиском мы будем понимать поиск, ограничивающийся ресурсами i хранилища данных.
Введем операцию-обработчик результатов process(Stori, result), где result - результат выполнения функции глобального либо локального поиска. Данная операция отвечает за преобразование результатов локального поиска в каскад запросов к серверам-соседям, узлам к которым ведут дуги от данного узла. По возврату данных от серверов-соседей может вновь инициироваться локальный поиск, но уже с учетом полученной информации.
Ввиду допущений 1 и 2, а также топологии сети, введем возможность перемещения поиска из узла, в котором происходит обработка информации, в узлы-соседи:
Stori ->{Stori1, … Storij}, (2.2)
где j число серверов-соседей активного узла.
Вновь имеем возможность применить глобальный механизм поиска, с центром в каждом из серверов-соседей. Получаем рекурсию, глубина которой для конкретного запроса равна максимальному пути, который можно построить из заданного узла (с учетом допущения 2). Из постановки задачи очевидно, что понятие поиска сразу распадается на три направления:
Рассмотрим каждое направление в отдельности.
Поиск по ссылке (1.1) – тривиальная техническая задача, в которой, имея имя узла и имя искомого на нем объекта, требуется получить развернутое описание объекта.
Поиск эквивалентного элемента (1.2) осуществляется путем использования стандартных рекомендаций для языка OWL[2].
Заполнение недостающего элемента в N-Triple (1.3) будем решать с помощью механизмов RDQL[9].
Не смотря на разобщенность направлений поиска, они тесно связаны. Рассмотрим взаимодействие механизмов поиска (Рис. 2-2).
search(Ont, [a,R,?] ) = Σ search(Ont, [am,Rn,?] ), m=1,M; n=1,N, (2.3)
где [a, R, ?] некоторый базовый запроса, am эквивалентно a, Rn эквивалентно R, M и N – количество найденных эквивалентностей соответствующему элементу N-Triple.
В 2.3 показано взаимодействие между поиском элементов эквивалентных данному (1.2), когда базовый запрос преобразуется в серию эквивалентных ему, и поиском недостающего элемента тройки (1.3). При формировании, как расширения запроса, так и при поиске недостающих элементов возможно возникает задача поиска по ссылке (1.1). Из сказанного следует, что в данном примере показана логическая связь всех трех элементарных типов поиска.
Рисунок 2-2 Взаимодействие механизмов поиска
3 Межсерверное взаимодействие
В основе межсерверного взаимодействия лежит технология агентного взаимодействия OWL-S[10]. Во-первых, ее использование формализует процесс передачи данных внутри сети, во-вторых, позволяет оставить возможность интеграции системы с внешними пользователями, еще не специфицированными на данном этапе разработки.
Для организации межсерверного взаимодействия специфицируется следующий интерфейс:
Используя данный интерфейс, были созданы следующие алгоритмы работы сервера, получившего запрос:
Предложенные алгоритмы при общем сходстве, имеют ряд концептуальных отличий и оптимальны в разных условиях. Алгоритм 1 предназначен для случаев, когда хранимая информация на серверах-соседях тесно переплетена и взаимосвязана, скорость выполнения запросов меньше, но на способ размещения информации в сети не налагается никаких ограничений. Данный алгоритм эффективен при поиске внутри локальных сетей больших организаций, для которых область применения онтологий одна или близка.
Алгоритм 2 предназначен для случаев, когда каждый из серверов представляет в какой-то степени завершенный ресурс. Таким образом, его область имен, классы и свойства наиболее эффективно применять исключительно к его модели. Скорость выполнения запросов в таком алгоритме выше за счет сокращения числа межсерверных пересылок данных, но качество поиска падает, вследствие того, что часть данных, которые были бы выбраны более широким запросом, утеривается. Таким образом вводим Ограничение 1: ни один сервер такой сети не может не содержать ссылок на сервер, хранящий некоторый объект, эквивалентный данному, иначе данные объекты не будут распознаны как эквивалентные. Такой алгоритм в большей степени подходит Internet поисковикам, которые имеют ссылки на сервера различной принадлежности.
Область применения Алгоритма 3 шире двух первых, так как в условиях разделения информации на описательную и несущую можно использовать алгоритмы, строго предназначенные для каждого конкретного случая. Но создание непосредственно транслятора требует разного рода формализаций, определяющих грань различия структуры от содержания, что достаточно легко решается в каждом конкретном случае.
Важным аспектом оптимизации межсерверного взаимодействия является кеширование результатов в рамках конкретного поиска. Оно заключается в сохранении результатов выполнения каждого конкретного запроса. Благодаря такой организации мы предотвращаем ситуацию зацикливания, облегчаем скорость работы при ветвлении сети (как в узлах 1, 2 и 3 на рис. 2-1), а также значительно ускоряем процесс повторного запроса, который может быть инициирован функцией process.
4 Практическая реализация
Рассмотрим пример используя топологию рисунка 2-1.
Информация узла 1.
[3:Мать ID="Маша"]
[2:породил rdf:resource="#Вася"/]
[/3:Мать]
[2:Ребенок ID="Вася"/]
Информация узла 2.
[owl:class rdf:id="Родитель"/]
[owl:class rdf:id="Ребенок"/]
[owl:objectproperty rdf:id="породил"]
[rdfs:domain rdf:resource="#Родитель" /]
[rdfs:range rdf:resource="#Ребенок" /]
[/owl:ObjectProperty]
Информация узла 3.
[owl:class rdf:id="Мать"]
[rdfs:subclassof rdf:resource="2#Родитель" /]
[/owl:Class]
[owl:class rdf:about="2#Родитель"]
[owl:equivalentclass rdf:resource="4#Parent"/]
[/owl:Class]
Информация узла 4.
[owl:class rdf:id="Parent"/]
Пусть поступил запрос «Кто Parent Васи?», приведя этот запрос к форме языка запросов получим [?, instanceOf, Parent] и [?, породил, Вася]. Имеем два запроса, обладая информацией по каждому из них мы легко можем сделать пересечение ответов.
Построим модель поиска для первого запроса:
| Сервер 1:
Расширение: Поиск в локальных данных: Трансляция серверу 2 и 3: |
[?, instanceOf, Parent]
0 0 |
|
| Сервер 2:
Расширение: Поиск в локальных данных: |
[?, instanceOf, Parent]
0 0 |
|
| Сервер 3:
Расширение: Поиск в локальных данных: Трансляция серверу 2 и 4: |
[?, instanceOf, Parent]
[?, instanceOf, Родитель] [?, instanceOf, Мать] 0 |
|
| Сервер 2:
Расширение: Поиск в локальных данных: |
[?, instanceOf, Parent] – отказ в результате кеширования [?, instanceOf, Родитель] [?, instanceOf, Мать]
0 0 |
|
| Сервер 4:
Расширение: Поиск в локальных данных: |
[?, instanceOf, Parent] [?, instanceOf, Родитель] [?, instanceOf, Мать]
0 0 |
|
| Результат:
Общее расширение: Общий поиск: Решение на повторный поиск: |
изменилось расширение
[?, instanceOf, Parent] [?, instanceOf, Родитель] [?, instanceOf, Мать] 0 |
|
| Сервер 1:
Расширение: Поиск в локальных данных: Результат: Общее расширение: Общий поиск |
[?, instanceOf, Parent] [?, instanceOf, Родитель] [?, instanceOf, Мать]
0 [Маша, instanceOf, Мать] изменился результат самого поиска 0 [Маша, instanceOf, Мать] |
|
Для остальных серверов работу рассматривать не будем, так как очевидно, что большая часть запросов будут отказом, а остальные ни к чему не приведут.
Построим модель поиска для второго запроса:
| Сервер 1:
Расширение: Поиск в локальных данных: Результат: Общее расширение: Общий поиск |
[?, породил, Вася]
0 [Маша, породил, Вася] изменился результат самого поиска 0 [Маша, породил, Вася] |
Дальнейший поиск результатов не изменит, поэтому не будем рассматривать дальнейший ход событий.
Итак «Кто Parent Васи?» – «Маша».
Предлагаемый пример показывает работу только Алгоритма 1, но базовые элементы этого алгоритма присущи всем остальным предложенным алгоритмам и их детальный анализ не дополнит общей картины.
Выводы
Литература:
[1] T. Berners-Lee, J. Hendler, and O. Lassila. The Semantic Web. Scientific American, 284(5):34-43, 2001.
[2] D. L. McGuinness and F. van Harmelen. OWL Web Ontology Language Overview. http://www.w3.org/TR/owl-features/ . August 2003. World Wide Web Consortium (W3C) Candidate Recommendation.
[3] Jeremy J. Carroll, Ian Dickinson, Chris Dollin. Jena: implementing the semantic web recommendations. International World Wide Web Conference. pp. 74 – 83, 2004.
[4] W. E. Grosso et al. Knowledge Modeling at the Millennium (The Design and Evolution of Protege-2000). In Proc. of KAW99, 1999.
[5] D. Martin, M. Burstein, O. Lassila, M. Paolucci, T. Payne, and S. McIlraith. Describing Web Services using OWL-S and WSDL. http://www.daml.org/services/owl-s/1.0/owl-s-wsdl.html, October 2003.
[6] Bijan Parsia, Evren Sirin, Aditya Kalyanpur «Debugging OWL Ontologies», In The 14th International World Wide Web Conference (WWW2005), Chiba, Japan, May 2005.
[7] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. 1998.
[8] Graham Klyne, Jeremy J. Carroll Resource Description Framework (RDF): Concepts and Abstract Syntax, http://www.w3.org/TR/rdf-concepts/ 2004
[9] Andy Seaborne, RDQL – A Query Language for RDF HP Labs Bristol http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/ 2004
[10] OWL-S Home Page. http://www.daml.org/services/. 2003.
Автор: Алексей Скороходов
Для создания агента как видно из названия нам понадобится JADE, eclipse и jdk.
После того, как все это извлечено из архивов и установлено, мы можем создать своего первого агента на платформе JADE (Java Agent DEvelopment Framework). Не будем нарушать традиции и первым нашим агентом будет агент «HelloWorld».
Сначала необходимо создать Java-проект нашего агента в среде Eclipse и подключить JADE к этому проекту (см. Рис 1.)
Рисунок 1.
Далее, в полученном проекте в папке src создаем Package c именем «hello». Теперь пришла очередь создать class с именем «HelloWorld» .
Ну и наконец код агента. В нашем случае он будет выглядеть так:
package hello;
import jade.core.Agent;
public class HelloWorld extends Agent
{
public void setup()
{
System.out.println(”Hello Yuhana, my name is : ” +getAID().getName());
}
}
Теперь необходимо подключить JADE (рис. 2 и 3).
Рисунок 2.
Кликаем на кнопку с именем «Add External JARs» и указываем путь к библиотекам JADE, в моем случае это «D:\diplom\stop\bin\jade\lib».
Результат наших действий:
Рисунок 3.
Перед тем как запустить нашего агента необходимо настроить параметры запуска проекта. Это можно сделать выбрав в выпадающем меню «Open Run Dialog», как показано на рис. 4.
Рисунок 4.
Далее, необходимо для «Java Application» создать новую конфигурацию. Во вкладке «Main» присвоим имя нашей конфигурации «test_agents». В «Main class» при нажатии кнопки «Search» выбираем «Boot — jade» и ставил «галочку» в «Include system libraries when searching for a main class» (см. Рис. 5 ).
Рисунок 5.
Далее, во вкладке «Arguments» в «Program argument» добавляем строку «-gui jade.Boot test:hello.HelloWorld»!!!
Ну вот и все, запускаем и получаем агента, выполнившего элементарное действие:
Рисунок 6.
Будьте в курсе!
На странице OntoLIB.COM будут собираться наиболее интересные новости русскоязычной части мира Semantic Web
