<< Предыдущая

стр. 20
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

Researcher [researchlnterest =» ResearchTopic;
Member0f =>> ResearchGroup;
cooperatesWith =» Researcher].
Publication [ author =» Person;
title =» STRING;
year =» NUMBER;
abstract =» STRING].

Правила

FORALL Person"!, Person2
Personl:Researcher [cooperatesWith-» Person2] <-
Person2:Researcher [cooperatesWith-» Personl].

FORALL Personl, Publieationl
Publicationl:Publication [author-» Personl] <->
Personl:Person [publication-» Publicationl].

По-видимому, в пояснениях здесь нуждаются только правила. Первое из них фиксирует симметричность отношения cooperatesWith. Второе утверждает, что если конкретная личность (экземпляр класса Person) имеет публикацию, то последняя имеет автора, который тоже является экземпляром класса Person, и обратно.
Машина вывода Ontobroker состоит из двух основных компонентов: транслятора с расширенного языка представления в ограниченный и собственно вычислителя выражений ограниченного языка, который является обычным языком логического программирования.

Аннотация Web-страниц онтологической информацией
Поскольку, как уже отмечалось выше, Web-информация чаще всего представлена на языке HTML, в рамках проекта Ontobroker разработано простое его расширение для аннотации Web-страниц. Основная идея этого расширения состоит в следующем: в язык HTML добавлено несколько релевантных для решения поставленных задач тегов, использование которых позволяет Ontobroker интерпретировать аннотированные фрагменты HTML-текста как факты языка представления онтологических знаний. При этом Web-страницы остаются приемлемыми для стандартных броузеров типа Netscape Navigator или MS Explorer.
В язык введены три эпистемологически различных примитива:
• Идентификация объекта, который может быть определен как экземпляр определенного класса, с помощью URL
• Установка значения атрибута объекта.
• Определение отношений между объектами.
Все примитивы синтаксически расширяют тег <а ...> языка HTML. Так, например, если специалист Иванов захочет определить себя как объект обсуждавшейся выше онтологии, он может на своей домашней странице ввести конструкцию вида:

<а onto=" "http://www.anywhere.ru/˜ivanov/" : Researcher"> </a>

Теперь для объекта Иванов класса Researcher можно ввести атрибут email и его значение с помощью следующей конструкции:

<а onto=" "http://www. anywhere.ru/˜ivanov/"
[email="mailto:ivanov@anvwhere. ru"1 "> </a>

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

<а onto= "REL(Obj1, Obj2, Obj3, ___ Objn)" > ... </a>

Имеются в языке и средства, которые обеспечивают уменьшение сложности аннотирования: например, возможности именования «длинных» конструкций и последующего использования этих имен.
При таком подходе Ontocrawler — компонент системы Ontobroker — простой CGI-скрипт, который периодически проверяет аннотированные страницы на Web. Для поиска таких страниц он обращается к индексным страницам провайдеров, которые зарегистрированы в рамках инициативы (КА)2.

8.3.3. Проект SHOE — спецификация
онтологии и инструментарий

Общая характеристика проекта
Проект SHOE (Simple HTML Ontology Extensions) ориентирован на решение проблемы добавления к Web-страницам семантической информации и соотнесения ее с онтологиями соответствующих предметных областей. Предполагается, что, используя эту информацию, поисковые системы смогут обеспечивать более релевантные ответы на запросы, чем это возможно сейчас на базе использования машин поиска, функционирующих в Интернете.
Для поддержки процессов аннотирования в рамках проекта SHOE разрабатывается специальный набор инструментальных средств (suite of tools), а основой кх является язык Интернет-совместимого представления знаний, который, собственно, и дал название всему проекту.
В настоящее время в проекте SHOE выделены следующие главные направления исследований:
• Разработка множества повторно используемых онтологии (reusable ontologies) для концептов, которые наиболее частотны для Web-ресурсов.
• Создание средств проектирования онтологии — аннотаторов знаний (Knowledge Annotator), которые бы упростили этот процесс.
Предполагается также, что в SHOE-инструментарий будет включена «несложная» обработка естественного языка (lightweight natural language processing techniques), которая обеспечит представление пользователям аннотаций документов.

Спецификации онтологии и инструментарий SHOE
В данном подразделе мы сосредоточимся не столько на самих онтологиях, разрабатываемых в рамках проекта SHOE [Luke et al, 1996], сколько на языке представления онтологических знаний и средствах поддержки процессов проектирования онтологии.

Формализм представления и машина вывода
Следует сразу отметить, что-SHOE по своей идее близок к уже обсуждавшейся выше инициативе (КА)2. Но концепция языка представления знаний здесь другая, хотя и она лежит в русле расширения HTML специальными тегами. А основное отличие языка SHOE в том, что здесь, по существу, предлагается «полномасштабное» расширение HTML. Для этого SHOE вводит в HTML-стандарт следующие новые теги для спецификации онтологии: ONTOLOGY, USE-ONTOLOGY, DEF-CATEGORY, DEF-RELATION, DEF-ARG. DEF-RENAME, DEF-CON-STANT, DEF-TYPE, DEF-INFERENCE, INF-IF, INF-THEN, COMPARISON, CATEGORY, RELATION, ARC и некоторые другие. Для аннотирования HTML-документов используется часть из уже перечисленных тегов и, кроме того, вводятся новые, например INSTANCE. И наконец, в SHOE вводится метатег вида <МЕТА НТТР-EQUIV =...">.
Для определенности в рамках спецификации языка SHOE предполагается, что онтология представляется в виде is_a иерархии классов/категорий, множества атомарных отношений между категориями и множества правил вывода в форме простых клауз Хорна.
Термами языка являются термы HTML и дополнительно к этому понятия Category (Class), Data (причем с типами STRING, NUMBER, DATE, TRUTH),Element, Instance, Instance Key, Name, Ontology, Relation (Relationship), Rule и некоторые другие.
Декларации онтологии задаются внутри тела HTML-документа и не могут перекрываться с другими тегами HTML. В одном документе может быть определено несколько онтологии, но такие определения тоже не может перекрываться или быть вложенными. Общая схема определения онтологии следующая:
<ONTOLOGY ID="идентификатор-онтологии"
VERSION="версия"
[BACKWARD-COMPATIBLE-WITH="список-версий”]
[DESCRIPTION^1 текст"]
[DECLARATORS="список-деклар.-экземпляров"]>
собственно-декларация-онтологии
</ONTOLOGY>

Для указания того, что данная онтология расширяет другую, уже существующую, используется специальный тег:

<USE-ONTOLOGY ID="идентификатор-онтологии"
VERSION="версия" PREFIX="префикс" [URL='W]>

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

<DEF-CATEGORY ШЕ=" имя-категории"
[ISA="список-родительских-категорий"]
[DESCRIPTION="текст"] [SHOT="текст"]>

Аналогичный подход применяется и для определения отношений:

<DEF-RELATION NFME=" имя-отношения"
[DESCRIPTION="текст”] [SHORT="текст"]>
список-аргументов
</DEF-RELATION>

Возможно определение тех же понятий и с помощью тега ONTDEF с параметрами.
Одним из важнейших компонентов определения онтологии являются правила вывода. В SHOE такие правила «похожи» на Хорновские клаузы по сути, но отличаются от них по форме:

<DEF-INFERENCE [DESCRIPTION="текст"]>
<INF-IF> тело </INF-IF>
<INF-THEN> голова </INF-THEN>
</DEF-INFERENCE>

Для примера, ниже обсуждается фрагмент определения онтологии в формализме SHOE, коррелирующий с уже обсуждавшимся фрагментом определения аналогичной онтологии в формализме Ontobroker.
Пусть нас интересуют исследователи, имеющие в Интернете свои домашние страницы. Для работы с такими страницами можно воспользоваться уже существующей в рамках SHOE онтологией общих понятий (organization-ontology version 2.1) по адресу http://www.ont.org/orgont.html. Однако предположим для определенности, что существующую онтологию необходимо расширить понятиями Person и Organization. Тогда спецификация фрагмента новой онтологии (Но-mePageOntology) может быть представлена в формализме SHOE следующим образом:

<ONTOLOGY ID="HomePageOntology" VERSION="1.0">
<ONTOLOGY-EXTENDS "organization-ontology"
VERSION="2.1" PREFIX="org"
URL="ftttp://ww.'ont. org/orgont. html">
<ONTDEF CATEGORY^"Person" ISA="org. Thing">
<ONTDEF RELATION="IastWame" ARGS="Person STRING">
<ONTDEF RELATION^ first/Va/ne" ARGS="Person STRING">
<ONTDEF RELATION="marned7o" ARGS="Person Person">
<ONTDEF RELATION^1 employee" ARGS="oro..Organization Person">
…………………………………………………….
</ONTOLOGY>

Аннотация Web-документов на базе онтологии
Аннотация HTML-документов в SHOE осуществляется также с использованием тегов. В частности, для этого служат теги USE-ONTOLOGY, INSTANCE, CATEGORY, RELATION. Последние три тега имеют следующие форматы:

<INSTANCE KEY="значение-ключа"
[DELEGATE-TO="список-примеров" ]> ... </INSTANCE>
<CATEGORY NAME="префикс, категория" [FОR-"ключ"]>
<RELATION NAME="префикс. отношение">список-аргументов </RELATION>

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

<BODY>
<МЕТА HTTP-EQUIV= "-Instance"
CONTENT="http://www. anywhere. ru/˜ivanov">
<USE-ONTOLOGY "HomePageOntology"
VERSION="1.0" PREFIX="our"
URL="nttp;//Mw. ont. org/HomePageOntology. html">
<CATEGORY "our.Person">
<RELATION "our. first Name" TO="Ivan">
<RELATION "our.lastName" TO="Ivanoy">
<RELATION "our.tnarriedTo"
TO="http://www. somewhere. ru/˜Mariya">
<RELATION "our. employee" FROM="http://www. ccas. ru">
……………………………………………………………………
</BODY>

Анализ приведенного HTML-текста показывает, что даже в таком, казалось бы, простом случае задача аннотации Web-документа достаточно сложна. Ситуация становится еще более сложной при аннотировании реальных HTML-документов. Во-первых, уже выбор объектов текста, подлежащих аннотированию, не тривиален, особенно, если Web-документ представляет объекты реального мира. Во-вторых, гиперссылки часто фиксируют лишь наличие определенных отношений между объектами, но не их семантику. И, наконец, можно, конечно, аннотировать каждую именную группу в естественно-языковом представлении HTML-страницы, но для реальных документов это слишком трудоемкая задача, которая, к тому же, чревата большим количеством ошибок.
Поэтому в рамках проекта SHOE для автоматизации процессов аннотирования Web-документов разработана специальная система Knowledge Annotator [KA, 1999], одна из экранных форм которой представлена на рис. 8.12.


Основными информационными блоками в приведенной выше экранной форме являются экземпляры (instances), онтологии (ontologies) и утверждения (claims). Пользователь может добавлять, редактировать и/или удалять любой из элементов этих блоков. При создании новых объектов пользователю выдаются соответствующие подсказки в виде, например, списка доступных онтологии, описанных в них категорий, отношений и т.п.
Для визуализации знаний, содержащихся в обрабатываемом документе, Knowledge Annotator использует различные методы, начиная с аннотированного HTML-текста и заканчивая описаниями утверждений на естественном (английском) языке. Кроме того, система осуществляет проверку корректности действий пользователя и транслирует его выборы в синтаксически правильные конструкции SHOE.

Формализм запросов
В настоящее время существуют различные примеры языков запросов к документам, проаннотированным на основе формализмов SHOE, рассмотренных выше. Так, в университете Мэрилэнд (University of Maryland at College Park) разработан робот Expos, который обрабатывает SHOE-документы и добавляет их в свою базу знаний, используя систему представления знаний PARKA [Stoffcl et al., 1997].
Пример PARKA-запроса для поиска домашних страниц может быть специфицирован следующим образом:

(query! "(:and
(ft! instanceOf ?X #! Person) (ft! instanceOf ?Y #!Person)
(tt!instanceOf ?Z #!Organization)
(tfllastName ?X "Ivanov") (#!lastName ?Y "Ivanova")
(ft! employee ?Z ?X) (#! employee ?Z ?Y)
(tflmarriedTo ?X ?Y)
(#! involvedln ?Z "РФФИ-проекты")))

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

8.3.4. Другие подходы и тенденции

В заключение настоящего параграфа необходимо, хотя бы в общих чертах, рассмотреть усилия World Wide Web Consortium (W3C) по созданию и внедрению средств маркировки Интернет-ресурсов.
До недавнего времени в распоряжении Интернет-авторов для этого почти исключительно использовался уже обсуждавшийся выше язык HTML. Однако с точки зрения семантической разметки Интернет-документов этот язык обладает рядом недостатков, основными среди которых являются следующие [Johnson, 1999]:
• жесткая ориентация на визуализацию;
• единственная «точка зрения» на данные;
• нерасширяемость;
• весьма ограниченные средства спецификации семантической структуры документов.
Справедливости ради следует заметить, что еще в конце 60-х годов в рамках исследований по представлению документов компанией IBM был разработан язык SGML (Standard Generalized Markup Language), который лишен многих из перечисленных недостатков. К середине 80-х годов этот язык стал стандартом для многих промышленных компаний и правительственных учреждений США, но, по мнению специалистов рабочей группы SGML W3C [Bosak, 1997], он слишком сложен для широкого использования Интернет-авторами. Вот почему в рамках W3C, начиная с 1996 года, предпринимаются усилия по разработке средств разметки документов, сравнимых но мощности с SGML, а по простоте использования — с HTML. И среди работ данного направления в первую очередь следует отметить язык XML (extensible Markup Language) [XML, 1998].
В языке XML «сняты» многие ограничения HTML, язык разметки стал существенно мощнее. И одновременно XML-тексты остаются понятными для всех, кто работал с языком HTML. Отличительные свойства XML и в том, что здесь фиксируется стандарт на определение синтаксиса и единообразные средства введения в языки разметки (Markup Language) новых тегов. А это, в свою очередь, позволяет конструировать на основе XML новые языки маркировки Web-документов и, кроме того, обеспечивает возможность различным приложениям (и, в частности, программным агентам) «понимать» и обрабатывать XML-документы.
Каждый XML-документ обладает определенной логической и физической структурой. Физически это композиция элементов, называемых единицами (entities), которые могут быть связаны взаимными ссылками. Логически документ состоит из деклараций, единиц, комментариев, собственно текстов и инструкций обработки, причем каждая конструкция XML маркируется специальными тегами явным образом. Все теги XML — парные, а конструкции могут быть вложены друг в друга, образуя правильно построенное дерево. Так, например, конструкция <ltem Attribute1=«Va!ue1»> </ltern> определяет единицу с именем Item и списком пар атрибут-значение, который в нашем случае представлен единственным атрибутом с именем Attribute"!, имеющим значение «Valuel».
Для иллюстрации возможностей этого языка рассмотрим содержательный пример XML-документа, описывающего домашнюю страницу исследователя Иванова.

<?xml version="1.0"?>
<Homepage>
<Nаme>Домашняя страница Иванова</Namе>
<Person>
<firstName>Ivan</firstName >
<lastName>Ivanov</lastName >
<marriedTo Homepage="http://www.anywhere.ru">
Mariya Ivanova</marriedTo>
<employee Homepage="http://www.ccas; ru">
CCAS of Russia</employee>
<publications>
<book title="First Book"/>
<book title="Second Book"/>
……………………………………………………………
</publications>
</Person>
</Homepage>

Этот XML-документ структурирован существенно лучше, чем был бы аналогичный ему HTML-текст, но пока не имеет «смысла», так как из него не следует, как интерпретируются единицы типа Person, publications, book и т. п. Для решения этого вопроса используется специальная спецификация определения типа документа DTD (document type definition). По сути дела, это грамматика языка разметки, в рамках которой определяются, какие элементы могут присутствовать в документе, какие атрибуты они имеют и как элементы соотносятся друг с другом. Понятно, что для стандарта XML такие спецификации уже разработаны самими авторами языка, но в нашем случае используется специальный его диалект, и потому именно мы должны специфицировать DTD нашего документа. Такая спецификация может быть следующей:

<!ELEMENT Homepage (Name, Person)>
<!ELEMENT Name (#PCDATA)>
<!ELEMENT Person (firstName, lastName, marriedTo?,
employee?, publications?, Homepage?)>
<!ATTLIST Person Homepage xml:link CDATA>
<!ELEMENT firstName (#PCDATA)>
<!ELEMENT lastName (#PCDATA)>
<!ELEMENT marriedTo (Person)>
<!ELEMENT employee (organization)>
<!ATTLIST organization Homepage xml:link CDATA>
<!ELEMENT publications (book*, paper*, report*)>
<!ATTLIST book title COATA «REQUIRED, coauthor Person,
publisher CDATA, year CDATA)>
<!ELEMENT paper (title, coauthor*, journal, year, vol?,
number?)>
<!ELEMENT report (title, coauthor*, organization, year)>
………………………………………………………………

Как следует из приведенного описания, в DTD специфицировано «сведение» конструкций нашего XML-документа к стандартным XML-конструкциям, понимаемым броузерами нового поколения.
В настоящее время уже разработаны DTD для различных предметных областей, и каждая такая спецификация, по сути дела, определяет новый язык разметки. Известным примером развития DTD для спецификации общих ресурсов является RDF (Resource Description Framework) [RDF, 1999], разрабатываемый W3C. Этот формат может использоваться для добавления в документы метаинформации, которая, в частности, может быть представлением семантики документа.
Использование собственных диалектов XML является важным шагом на пути формирования пространств знаний в сети Интернет. Но, по сути дела, это лишь первый шаг в этом направлении. Действительно, какие средства дает язык XML для представления знаний? Очевидно, что это, в первую очередь, средства спецификации декларативной компоненты развитых систем представления знаний. И то в ограниченном объеме. Каким же образом авторы этого языка и его расширений предполагают подключение процедур обработки XML-конструкций? На сегодняшний день в предложениях W3C явно прослеживается лишь одна идея: поскольку XML-документы не что иное, как портабельные данные, а язык Java имеет портабельный код, следует их использовать совместно. Для этого предлагаются специальные интерфейсы, например SAX (Simple API for XML), которые уже сейчас могут поддерживать многие Java-анализаторы. Основная идея здесь достаточно проста — анализатор просматривает узлы дерева документа из XML-файла и вызывает соответствующие методы, определенные пользователем. Для того чтобы этот механизм работал, программист должен создать класс, реализующий соответствующий интерфейс. Методы этого класса будут вызываться всякий раз, когда на входе распознавателя появляется нужная конструкция (тег, входная строка и т.п.). Собственно обработка информации при этом целиком в руках программиста, а среда лишь поддерживает общее функционирование и обработку исключительных ситуаций.
Такой подход имеет много общего и с подходом Ontobroker, и с подходом SHOE. Авторы обоих этих проектов активно приветствуют усилия W3C, но вместе с тем отмечают, что в предложениях соответствующих рабочих групп еще много недостатков. В первую очередь — это отсутствие стандартов на интеллектуальную обработку XML-конструкций, сравнительно небольшой практический опыт семантической разметки Интернет-документов и достаточно ограниченные средства логической обработки, используемые при этом.
Вот почему, как показывает анализ литературы и Интернет-ресурсов по данной тематике, в настоящее время:
• эффективная обработка информации на Web связывается, в первую очередь, с использованием ИИ-технологий;
• основные подходы в этой области ориентированы на решение проблемы извлечения из Web-ресурсов эксплицитных знаний на основе семантического маркирования таких ресурсов;
• во всех исследовательских и многих коммерческих проектах данного направления активно используются (или, по крайней мере, декларируется использование) агентно-ориентированные вычисления и технологии. Учитывая вышесказанное, в следующей главе обсуждаются мультиагентные системы и системы интеллектуальных агентов.











Интеллектуальные
Интернет-технологии

Ё Программные агенты и мультиагентные системы
Ё Проектирование и реализация агентов и мультиагентных систем
Ё Информационный поиск в среде Интернет

9.1. Программные агенты и мультиагентные
системы

9.1.1. Историческая справка

Проблематика интеллектуальных агентов и мультиагентных систем (MAC) имеет уже почти 40-летнюю историю [Городецкий и др., 1998; Тарасов, 1998] и сформировалась на основе результатов, полученных в рамках работ по распределенному искусственному интеллекту (DAI), распределенному решению задач (DPS) и параллельному искусственному интеллекту (PAI) [Demazeau et al., 1990; Пэранек, 1991; Rasmussen et al., 1991]. Но, пожалуй, лишь в последнее 10-летие она выделилась в самостоятельную область исследований и приложений и все больше претендует на одну из ведущих ролей в рамках интеллектуальных информационных технологий. Спектр работ по данной тематике весьма широк, интегрирует достижения в области компьютерных сетей и открытых систем, искусственного интеллекта и информационных технологий и ряда других исследований, а результаты уже сегодня позволяют говорить о новом качестве получаемых решений.
Понятно, что в рамках данного издания мы не сможем даже обозреть все направления и результаты в области MAC. Поэтому далее сконцентрируемся лишь на тех разделах, которые имеют непосредственное отношение к теме настоящей книги. С учетом сделанных замечаний и с позиций сегодняшнего дня все исследования в этой области можно выделить в две основные фазы: первая охватывает период с 1977 г. но настоящее время, а вторая — с начала 1990 г. по настоящее время.
Работы первого периода концентрировались на исследовании так называемых «смышленых» (smart) агентов, которые были начаты в конце 1970-х годов и продолжаются все 1980-е годы вплоть до наших дней. Первоначально эти работы были сосредоточены на анализе принципов взаимодействия между агентами, на декомпозиции решаемых задач на подзадачи и распределении полученных задач между отдельными агентами, координации и кооперации агентов, разрешении конфликтов путем переговоров и т, п. Цель таких работ — анализ, спецификация, проектирование и реализация систем агентов. На этом же уровне активно велись работы по теории, архитектурам и языкам для программной реализации агентов. Примерно с 1990 г. стало ясно, что программные агенты могут использоваться в широком спектре применений. Однако потенциал агентных технологий, по-видимому, стал в значительной мере осознан не только разработчиками, но и инвесторами после известного отчета консультативной фирмы Ovum [Ovum, 1994], которая предсказала, что сектор рынка длялрограммных агентов в США и Европе вырастет, по крайней мере, до $3,9 billion к 2000 г. в противовес 1995 г., когда он оценивался в $476 million.
В настоящее время множество исследовательских лабораторий, университетов, фирм и промышленных организаций работают в этой области, и список их постоянно расширяется. Он включает мало известные имена и небольшие коллективы, уже признанные исследовательские центры и организации (например, университет Карнеги Мэллон (CMU) и фирма General Magic), а также огромные транснациональные компании (такие как Apple, AT&T, ВТ, Daimler-Benz, DEC, HP, IBM, Lotus, Microsoft, Oracle, Sharp и др.). Областями практического использования агентных технологий являются управление информационными потоками (workflow management) и сетями (network management), управление воздушным движением (air-traffic control), информационный поиск (information retrieval), электронная коммерция (e-commerce), обучение (education), электронные библиотеки (digital libraries) и многие-многие другие приложения.
Существует несколько причин, почему необходимы и полезны программные агенты, MAC и, более общо, агентные технологии. Основная из них в том, что агенты автономны и могут выполняться в фоновом (background) режиме от лица пользователя при решении разных задач, наиболее важными из которых являются сбор информации, ее фильтрация и использование для принятия решений.
Таким образом, основная идея программных агентов — делегирование полномочий. Для того чтобы реализовать эту идею, агент должен иметь возможность взаимодействия со своим владельцем или пользователем для получения соответствующих заданий и возвращения полученных результатов, ориентироваться в среде своего выполнения и принимать решения, необходимые для выполнения поставленных перед ним задач.
К построению агентно-ориентированных систем можно указать два подхода: реализация единственного автономного агента или разработка Тмультиагентной системы. Автономный агент взаимодействует только с пользователем и реализует весь спектр функциональных возможностей, необходимых в рамках агентно-ориентированной программы. В противовес этому MAC являются программно-вычислительными комплексами, где взаимодействуют различные агенты для решения задач, которые трудны или недоступны в силу своей сложности для одного агента. Часто такие мультиагентные системы называют агентствами (agencies), в рамках которых агенты общаются, кооперируются и договариваются между собой для поиска решения поставленной перед ними задачи.
Агентные технологии обычно предполагают использование определенных типологий агентов и их моделей, архитектур MAC и опираются на соответствующие агентные библиотеки и средства поддержки разработки разных типов мульти-агентных систем.

9.1.2. Основные понятия

Существует несколько подходов к определению понятий в данной предметной области. По-видимому, одним из наиболее последовательных в этом вопросе является международная ассоциация FIPA (Foundation for Intelligent Physical Agents), каждый документ которой содержит толковый словарь терминов, релевантных данному документу [FIPA, 1998]. И вместе с тем практически во всех работах, где даются, например, определения понятия агента и его базисных свойств, общим местом стало замечание об отсутствии единого мнения по этому поводу [Franklin et al., 1996; Belgrave, 1996; Nwana, 1996]. Фактически, используя понятие «агент», каждый автор или сообщество определяют своего агента с конкретным набором свойств в зависимости от целей разработки, решаемых задач, техники реализации и т. п. критериев. Как следствие, в рамках данного направления появилось множество типов агентов, например: автономные агенты, мобильные агенты, персональные ассистенты, интеллектуальные агенты, социальные агенты и т. д. [Nwana; 1996], а вместо единственного определения базового агента — множество определений производных типов.
Учитывая вышесказанное, понятие агента целесообразно трактовать как мета-имя или класс, который включает множество подклассов. Ряд определений агентов, данных разными исследователями, представлен в работе [Franklin et al., 1996]. В настоящем издании будем придерживаться следующей концепции по этому поводу.

Таким образом, в рамках МАС-парадигмы программные агенты рассматриваются как автономные компоненты, действующие от лица пользователя.
В настоящее время существует несколько классификаций агентов [Nwana, 1996], одна из которых представлена в табл. 9.1.
Таблица 9.1.
Классификация агентов

Типы агентов

Характеристики
Простые Смышленые Интел-
(smart) лектуальные
(intelligent)
Действительно (truly) интеллектуальные
Автономное выполнение
+ +
+
Взаимодействие с другими агентами и/или пользователями

<< Предыдущая

стр. 20
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>