Разработка распределенных приложений основанных на рассуждениях для Семантической Паутины

Перевод  статьи «Developing Distributed Reasoning-Based Applications for the Semantic Web« (D. Koutsomitropoulos и др.)
выполнил Запольский Святослав.

В переводе возможны ошибки, просьба указывать на них в комментариях или на форуме Semantic Future.

Аннотация

Для того чтобы приложения Семантической Паутины были успешными, ключевым компонентом должна быть их способность разными способами принимать преимущества описания, богатого содержанием. Рассуждения составляют ключевую роль в этом процессе и, следовательно, представляются в основе архитектуры стека Семантической Паутины. Однако с практической точки зрения не всегда ясно как приложения могут использовать возможности Инженерии знаний и что рассуждения могут предложить Семантической Паутины. В этой работе мы приводим обзор современных методов, которые могут быть использованы для интеграции сервисов, основанных на логическом выводе с такими приложениями. Важно, чтобы решение задач было логически и физически распределенное. Для этого мы обсудим соответствующие протоколы и языки, такие как DIG и SPARQL и дадим обзор Интерфейса Инженерии знаний. Кроме того мы опишем урок извлечения рассуждения из удаленного сервиса посредством OWL API.

Введение

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

Поздний успех Дескриптивной Логики (ДЛ), кажется, многим обязан тесной связи с языками онтологий, такими как OWL и OWL2. Соответственно стали популярными ДЛ системы, основанные на рассуждении, такие как RACER, FaCT++ и Pellet. Тем не менее, использование этих систем в приложениях может добавить «аромат» нынешней Web и превратить ее в Семантическую Паутину.

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

Кроме того использование сервисов вывода подразумевает, что приложения распределены в пространстве. Проблемы OWL DL оптимально решаются за время 2-NEXP, а для OWL 2 это 3-NEXP. Нельзя ожидать, что случайный пользователь согласится терпеть такими большие задержки во времени просмотра и запросов, и нет никаких возможностей для уменьшения задержек, по крайней мере для ДЛ. Таким образом, должен быть найден способ облегчить механизм задачи конечным пользователям и делегировать на более мощные серверы, что создаст трех уровневую систему распределенных приложений.

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

  • наличие протоколов для эффективной связи/обмена логическими выводами;
  • спецификация соответствующих языков запросов, что даст конъюнктивные запросы, по удобству напоминающие реляционные системы БД.

Поэтому мы рассматриваем варианты в этих двух категорий, делая акцент на DIG и SPARQL. Затем мы обсудим значение децентрализованной архитектуры для приложений Семантической Паутины как сценарий текущего Интерфейса Инженерии знаний (KDI) в качестве одного из ранних экземпляров для таких приложений. Наконец мы ссылаемся на наш опыт в разработке промежуточного ПО, что позволяет удаленно использовать машину логического вывода на OWL API и наметить наши результаты и выводы.

Языки запросов для Семантической Паутины

Инженерия знаний не совпадает с традиционным извлечением данных, по крайней мере не так, как последний стандартизированный язык запросов и протоколов – например, как в реляционной базе данных. Однако это тоже предполагает формулировку и композицию каких-то интеллектуальных запросов, ответы на которые составит запрошенные знания. Например, типичный запрос в SQL или XQuery не подходит для получения ответов от механизма логического вывода. Однако ни одно последнее предложение по языкам запросов для Семантической Паутины кроме SPARQL не кажется достаточно для моделирования таких декларативных запросов, так как они не могут полностью охватить выразительность OWL.

Следовательно, в этом разделе мы обсудим некоторые первые протоколы для запроса документов Web-онтологий. Затем мы сконцентрируем внимание на SPARQL и язык запросов для Семантической Паутины de facto и рассмотрим попытки распространения этого языка запросов в конкретном OWL документе.

Первые попытки

Наряду с первыми усилия по стандартизации языка онтологий для Web, таких как DAML+OIL и затем OWL возникли предложения с точки зрения использования этих языков путем механизмов запроса. Это привело к предложению в литературе язык запросов DAML (DQL) и OWL-QL как протоколы отвечают за обмен информацией и запросов/ответов в отношении онтологии документов. Тем не менее, по определенным причинам не представляется возможным найти эти очень перспективные спецификации в любой существенной реализации, не говоря уже о производстве.

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

SPARQL и SPARQL / OWL

SPARQL вышел из научной конкуренции между различных кандидатов по стандартизации и перешел в определенный стандарт W3C через процесс не совсем гладкий.

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

SPARQL-DL был введен как подмножество SPARQL, что позволяет, при определенных условиях выражать конъюнктивные запросы и их сочетание с таксономией для языка онтологий OWL DL. (см., например, Таблица I). SPARQL-DL внедрен и поддерживается, с различными оптимизациями, в последних версиях логического вывода Pellet. Кроме того, он может спокойно расширится до OWL 2, путем добавления соответствующих частей запроса, таких как Reflexive(p) для проверки reflexivity свойства р. Фактически усилия по стандартизации языка запросов для OWL и OWL 2 теперь объединены под названием SPARQL/OWL2. Наконец nRQL – это достаточно выразительный язык запросов, поддерживаемый RACER, разработанный специально для конъюнктивных запросов, которые относятся к части онтологии АВох.

DIG интерфейс

DIG это общий стандартный интерфейс для ДЛ рассуждений. Благодаря базовым API DIG позволяет c помощью различных инструментов использовать системы ДЛ стандартизированным способом. Основой DIG протокола, отвечающей за коммуникацию рассуждений является HTTP. Запрос сообщения производится с использованием собственного синтаксиса XML. Сообщения, которыми обменялись сервер и клиент чтобы разделиться на Tells и Asks позволяют клиенту следующие действия: запрос у сервера возможностей рассуждений, передача серверу онтологий,  выполнение определенных манипуляций с онтологиями и выполнение стандартных ДЛ запросов из данной онтологии, например, концепции категоризации, выполнимость, эквивалентность и т. д.

Хотя DIG ориентирован только на ДЛ системы, но фактически это надежный протокол для обмена рассуждениями и таким образом может быть использован для удаленной доставки услуг, основанных на рассуждении.

DIG 1.x и DIG 2.0

DIG 1.0 вышел в октябре 2002 года, его обновленный вариант, DIG 1.1, появился вскоре после этого, в феврале 2003. DIG 1.1 был быстро принят механизмами логического вывода, редакторами онтологий и многими другими приложениями Семантической Паутины. Но, несмотря на свою популярность, ему пришлось столкнуться с рядом проблем, таких как ограничения в поддерживаемом языке фрагмент (например, не поддерживает типы данных, плохое соответствие между понятием DIG отношений и OWL свойств), отсутствие элементарных запросов и отсутствие механизма расширения протокола.

Следующая версия DIG 1.2, была введене в качестве дополнения к оригинальному интерфейсу DIG 1.1 в отношении предоставления языка запросов аВох. В сущности, версия 1.2 предоставляет возможность создавать соединения конъюктивных запросов к рассуждениям. DIG 1.2 не исправил семантику запросов, что позволило разработчикам определять свои собственные. Версия 1.2 была реализована только путем рассуждений RacerPro и QuOnto. Некоторые недостатки DIG 1.1 были исправлены в последующей спецификации DIG 2.0. Так как DIG 1.1 был не в состоянии захватить онтологии OWL DL, еще одной проблемой обновления стало обновление концепции языка до OWL DL уровня. Кроме того стала возможным поддержка альтернативных диалектов DL (например, EL++). С конечной целью поддержки вскоре вышедшего OWL 2, DIG 2.0 предусматривал некоторые расширенные функциональные возможности, такие как поддержка условной кардинальности ограничений и роль формирования операторов.

Переход от DIG до OWLlink

Текущая версия DIG называется OWLlink. Его основная особенность в том, что он основан на самых последних OWL 2 спецификациях для примитивных языков моделирования. И так OWLlink рассматривается в качестве преемника DIG, обновленного на многих уровнях, что обеспечивает расширяемый протокол для связи с системами OWL рассуждений. Это на самом деле более усовершенствованная версия DIG, что касается запросов и экспрессивности языка, но это не имеет обратной совместимости. OWLlink поддерживает многие особенности OWL 2, как, например, понятия игры слов и структурной эквивалентности. Однако он не поддерживает какой либо части OWL 2 за пределами уровня аксиом, как, например, OWL imports.

Обмен данными между OWLlink-совместимыми клиентами и серверами осуществляется путем обмена сообщениями запросов и ответов. Благодаря этим процессам клиентские приложения обрели возможность конфигурировать рассуждения, доступа к сервисам рассуждений и передачи онтологий. Основными функциональными возможностями OWLlink являются добавление информации БЗ и получения информации из БЗ (Рис. 2). Вопросительные заявки распространяются только на очень часто задаваемые запросы по данным и выводным аксиомам БЗ. Более сложные запросы, в частности включающие коньюктивы остаются точно определенными OWLlink Query Extension. Последние, однако, все еще находятся в стадии проекта и немного устарели, так как относятся к предыдущей версии DIG 2.0.

DIG совместимые инструменты и приложения

Помимо этих ДЛ рассуждений, которые поддерживают DIG интерфейс редакторов онтологии (например, CEL, FaCT++, Racer, Pellet and KAON2) многие другие приложения и промежуточные ПО, используют DIG для рассуждений по OWL онтологиям (например, Instance Store, OntoXpl and Jena framework). Не смотря на то, что OWLlink все еще находится в состоянии разработки, он поддерживает или вот-вот будет поддерживать широко применяемые системы рассуждений, таких как RacerPro, Pellet and FaCT++. RacerPro начал поддержку OWLlink с версии 1.9.3, и поддерживает в нынешней версии RacerPro 2.0. QuOnto – другой механизм рассуждения, который в настоящее время с расширением OBDA поддерживает  OWLlink. Более того, Protégé и OntoTrack заявили, что обязываются поддерживать OWLlink, и различные разработчики редактирования онтологий и инструментов просмотра в скором времени тоже начнут это делать.

Достоинства трех уровневой архитектуры KDI

В этом разделе мы рассмотрим, почему так важно придерживаться распределенной архитектуры в приложениях Семантической Паутины, хотя DIG может применятся не только для этого. Сначала мы объясним, почему мы не можем всегда рассчитывать на DIG как на рассуждающий интерфейс, и за это приходится платить. Затем мы кратко представим конкретные рассуждающие предложения, которые были построенные на этих идеях.

DIG против прямого развертывания в памяти

FaCT++ и Pellet по всей видимости единственные два ДЛ-основанных инструмента, полностью поддерживающих OWL и OWL2. Однако они поддерживают только DIG 1.1, что недостаточно для полной поддержки  OWL DL, этот факт, главным образом, дал развитие подающему надежды OWLlink.

DIG 1.1 обменивается информацией через HTTP, и нет поддержки других TCP/IP подключений. Скорее, для этих рассуждений, использованных инструментами или приложениями можно использовать программный API (например, Jena или OWL API) интерфейсов этих рассуждений реализованы непосредственно в памяти. Этот подход может благоприятствовать снижению загрузки DIG протокола случайными сообщениями, но несомненно недостаточен для разработки действительно децентрализованных web-приложений и сервисов для Семантической Паутины. DIG 2.0 как спецификация, которая позволит решить вышеупомянутые проблемы в течении длительного времени была in flux, эти рассуждения не могут быть использованы в разработке распределенных web-сервисов для инженерии знаний Семантической Паутины, полностью поддерживающие OWL DL или OWL 2.

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

KDI

KDI – это web-приложение для обеспечения сервисов представления интеллектуальных запросов в документах web-онтологий. Дизайн интерфейса следует традиционной трехуровневой модели, с важным изменением: сервер базы данных будет типично использоваться, мы будим использовать систему управления базой знаний, поскольку традиционная СУБД не имеет необходимых характеристик и функций для управления и использования онтологических знаний (рис. 1). Обратите внимание, что каждый из трех уровней физически может быть расположен на различных компьютерных системах.

KDI взаимодействует с RACER в производстве логических выводов: несмотря на свои ограниченные экспрессивности, RACER представляет собой систему, вокруг которой могут быть построены децентрализованные приложения. Конструктивно KDI стремится быть децентрализованным двумя способами:

  • Базы знаний Семантической Паутины, откуда извлекаются данные, могут быть логически и физически распределены (в OWL это может обеспечиваться директивой owl:import)
  • Уровни приложений могут также распределятся как на логическом так и на физическом уровне: интерфейсный слой (браузер), логический уровень приложений (servlets, javabeans, tomcat) и слой управления базой знаний (механизм логического вывода).

Такая действительно децентрализованная архитектура, в соответствии с традиционной трехуровневой парадигмой еще не возможно с большинством текущих state-of-the-art  и очень выразительных механизмов логического вывода из-за ограничения возможностей интерфейса, как было описано ранее. С другой стороны, такой подход может иметь более существенный вклад в использование семантической информации пользователями и приложениями, выявление более очевидного значения из онтологических данных. Кроме того, она может быть расширена для поддержки нового поколения приложений Web 3.0.

Middleware для децентрализованных рассуждений

Хотя KDI может служить полезным примером для распределенных reasoning-based приложений, но proprietarily предназначен только для взаимодействия с RACER через пользовательский JRacer API. С другой стороны OWL API это хорошо известная программная абстракция Java для работы с онтологиями. Он широко используется для разработки онтологических приложений и позволяет взаимодействовать с различными средствами логического вывода, развернутых только в памяти (т.е. отсутствуют удаленный связи).

Для того, чтобы не ограничивать приложения to the particulars и/или ограничить какой либо один механизм логического вывода и в тоже время расширить возможности децентрализованной архитектуры, мы спроектировали и разработали вариант OWL API, такой что в дополнение к своим первоначальным преимуществам, может также поддерживать удаленные связи. В дальнейшем мы кратко представим эту доработку и проверим, как она может способствовать децентрализованному рассуждению.

Описание

Нашей целью является лишь один основной сервер, содержащий механизм логического вывода, который будет в состоянии обеспечить сервис рассуждение числу клиентских приложений по протоколу TCP/IP. Клиентские приложения смогут делать запросы и получать ответы из базы знаний, с помощью оригинальной OWL API.

В этом смысле мы разработали клиент-сервер на Java, с использованием «удаленных объектов». Рассуждение вместе с OWL API расположены на сервере. Наше «серверное» приложение слушает определенный порт, ожидая соединения. Наше «клиентское» приложения – вариант OWL API, физически расположенное в другом компьютере, и для того, чтобы использовать рассуждения, оно должен подключиться к серверу. После подключения, серверное приложение инициализирует объект рассуждений, читает параметры из клиентского приложения, вызывает соответствующий метод рассуждений, и отправляет обратно результат. Вся связь клиент-сервер и сообщение транзакции, происходит по протоколу TCP/IP.

На стороне клиента, идея отменить OWL API интерфейс рассуждения вместе с новым классом (myReasoner) возникла чтобы раскрыть все рассудительные методы, определенные в оригинальном интерфейсе OWL API. Эти методы делали копии с оригиналов с целью предоставить интерфейс, который можно использовать вместо оригинального OWL API, с минимальными модификациями. Таким образом приложению OWL API первоначально необходимо импортировать только класс myReasoner, а не весь оригинал.

На стороне сервера, любое OWL API совместимое рассуждение может быть подключено через класс myServer, который при инициализации создает TCP / IP сокет на требуемый порт, и будет ждать клиентских подключений. Затем удаленные объекты будут обмениваться Java Serialization.

В качестве следующего шага в целях дальнейшего расширения распределенных характеристик нашего middleware, мы в настоящее время eveloping другую версию нашего «серверного» приложения, что делает использование Java threads. В этом многопоточной версии, каждый клиент, подключенный к нашому серверу, практически обслуживается различными инстанциями класса Reasoner, в результате параллельной обработки запросов клиентов, вместо последовательного способа клиент-после-клиента. Единственной преградой использования многопоточного подхода является то, что он не может работать с FaCT++ рассуждениями, из-за JNI, который не поддерживает многопоточность.

Приложения были испытаны с обоими известными механизмами логического вывода, поддерживаемыми OWL API – FaCT++ и Pellet.

Результаты

Для того, чтобы выяснить потенциал нашей реализации, мы сделали несколько тестов и временных измерений, основанных на известном примере 8 документации OWL API, используя одну из оригинальных онтологий pizza.owl или Finance.owl. Обе онтологии диалекта OWL DL. Мы использовали две разные компьютерные системы: клиент на основе Intel Atom 1,6 GHz 2 GB RAM, и сервер Intel Core 2 Duo 2.66 GHz 2 GB RAM.

Во время эксперимента с использованием FaCT++, мы измерили время (в мс), затрачиваемое некоторыми методами и общее время рассуждения в этом примере. Мы проверили все возможные случаи: локальные настройки клиентского компьютера (без удаленного соединения) и клиент-серверные настройки для каждой онтологии. Эти результаты приведены в табл. 3.

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

Заметим, что значительное время превосходит почти все разы, потому что удаленное соединение по протоколу TCP/IP и Java Serialization как ожидалось. С другой стороны,  иметь «быстрые » серверные системы, предназначенные для процессов рассуждений значительно лучше стимулирование требовательных к процессору методов (таких как classify()) для уменьшения влияние сетевой задержки. Например, финансовые онтологии классифицируется почти на 75% быстрее при передаче этой задачи более мощным системам, через промежуточное.

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

Кроме того, протокол Java Serialization кажется, значительно способствует коммуникационной нагрузке blow-up, в связи с усложнением структуры объектов OWL API, которые должны быть переданы. Для этого, мы также экспериментировали с нашей реализацией, с тем чтобы общаться только в объектам URI, вместо отправки их через тот же самый Java Serialization. В этом случае нагрузка клиент-сервер может быть сведено к минимуму.

Выводы

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

Тем не менее, мы показали, что серьезный разрыв по-прежнему существует на пути конечных пользователей к автоматизированнымм средствам, которые могут взаимодействовать и использовать онтологии путем составления запросов и получения результатов в конкретной форме. Стандартизацией протоколов для этого процесса в настоящее время является основным вопросом исследования и подходитя в любой производственной системе. SPARQL/OWL и OWLlink спецификации считаются очень многообещающими в этом направлении.

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

 

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

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


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