Агенты и онтологии на примере AgentOWL

В прошлый раз я описывала использование AgentOWL. Сейчас  я предлагаю рассмотреть некоторые теоретические и практические аспекты поддержки и использования RDF/OWL моделей агентами. Целью будет выявления возможностей и ограничений подхода AgentOWL.

Как выглядит теория

«AgentOWL library was developed to support RDF/OWL ontology models in JADE agent system. «

Библиотека AgentOWL разработана для JADE , а JADE представляет собой наиболее полную реализацию спецификаций FIPA (Foundation for Intelligent Physical Agents). Поэтому начнем со спецификаций.

Спецификация  FIPA Ontology Service specification определяет основные аспекты моделирование взаимодействия агентов, основанного на онтологиях.

Ontology Agent должен обладать функциональностью для участия во взаимодействии по выполнению следующих задач:

1. оказание содействия  FIPA-агентам в выборе совместно используемой онтологии для взаимодействия;

2. создание и изменение онтологий, или некоторых элементов онтологии;

3. перевод выражений между различными онтологиям(различные названия элементов с одинаковых смыслом, например, на разных языках);

4. выполнения запросов о взаимосвязям между элементами онтологий и онтологиями в целом;

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

Проведем параллели между спецификацией и возможностями AgentOWL.

В AgentOWL у агентов есть внутренняя модель знаний, однако они не могут свободно использовать внешние онтологии, потому что при этом надо устанавливать соответствия с внутренней моделью.

Агенты, использующие AgentOWL, могут добавлять информацию в онтологии, составлять sparql запросы, выполнять некоторые операции(union, intersection and difference) средствами Jena. Однако это все требует написание довольно большого количества программного кода, который можно сократить добавив необходимые механизмы в AgentOWL(как обертку механизмов Jena).

Важным аспектом является установление соответствий между онтологиями(ontology mapping, merging, alignment). //На данный момент поддерживается merging средствами Jena.

Обобщая все вышесказанное выделим некоторые ограничения AgentOWL:

— нет возможности установления связи между элементами различных онтологий
— нет подбора онтологии для взаимодействия
— нет организации работы с внешними онтологиями

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

Что дает практика: некоторые недостатки, обнаруженные при практическом использовании AgentOWL

Далее представлен небольшой список проблем, возникших на практике, который не претендует на полноту и абсолютную объективность. //Кроме того, нагрузочного тестирования и других видов испытаний я не проводила:)

1. Обработка исключений слишком упрощена и не слишком информативна: часто используется  catch (Exception e) , кроме того исключения не выносятся на верхние уровни для последующей обработки.

2. У агентов нет возможности отслеживать внешние изменения в owl-онтологии, которую они загружают в память и реагировать на них в интерактивном режиме. Т.е по сути онтология становится активным ресурсом(который может изменяться вне зависимости от контролирующего агента)

«Active resources may provide a listener-based interface so that the controlling agent can immediately detect changes inside the resource. In other cases, the resource may provide an interface with methods that block until a change is detected, e.g. a network socket where some data is expected to be received. Finally, in certain cases the only way to detect relevant changes in an active resource is to periodically poll the resource itself.»(методология jade)

3. Все агенты используют один файл, описывающий модель знаний
(agent.core.onto.Config.SOURCE_FILE  by default memory_init/agents.owl). Поэтому агентов, которые не вписываются в единую модель, но при этом должны поддерживать OWL/RDF модели необходимо программно отделять от остальных.

Подведем итоги

Для организация эффективного взаимодействия агентов с использованием OWL онтологий с учетом FIPA-спецификаций, можно рассмотреть возможность расширения AgentOWL агентами-сервисами, которые будут реализовать спецификации  FIPA.
Как альтернатива можно также рассмотреть направление преобразование всех агентов , использующих AgentOWL в FIPA-compliant ontology agents.


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


4 Responses to Агенты и онтологии на примере AgentOWL

  1. Эх, а ведь несколько записей отдалось в rss полностью, а теперь опять вот только кусочек из начала. Нельзя ли вернуть?

  2. Вернуть то можно. Как только появится время сделать приличный вывод в RSS это будет сделано. Хочу сделать стилизированный текстовый вывод записей в RSS без оформления — может кто нибудь посоветует плагин для WordPress реализующий подобную функциональность буду благодарен.
    PS Комментарии не по теме заметки я удалю через некоторое время.

  3. Хотелось бы спросить по-поводу недостатков AgentOWL:
    — нет организации работы с внешними онтологиями
    Имеется в виду тот факт, что для работы агента с произвольной онтологией — она обязательно должна быть вставлена в мета-онтологию AgentOWL (т.е. вся иерархия концептов становится подклассом RESOURCE в онтологии AgentOWL)?

  4. В каком-то смысле , да. В том случае, если используется предложенная автором AgentOWL модель знаний агента. Т.е. при этом агенты расширяют свою модель, создавая подклассы Resource(чаще всего), иногда Domain, Actor, Task и некоторые другие. Но кроме того, библиотека может быть использована независимо от предложенной модели, хотя при этом все равно для всех агентов поддерживается только одна модель и всю информацию нужно добавлять в нее. При этом нет механизмов установления соответствия между элементами локальной модели и полученной извне информацией(допустим, на основании онтологии верхнего уровня) и решения возможных других задач, возникающих при добавлении информации.

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

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


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