Wykład10, 11 ACL - język komunikacji między agentami ACL -

(1)

Wykład10, 11

ACL - język komunikacji między agentami ACL - Agent Communication Language

(na podstawie specyfikacji FIPA

Publication date: 23rd October, 199828th November, 1997

SPECYFIKACJE FIPA

KOMUNIKACJA MIĘDZY AGENTAMI

MECHANIZM TRANSPORTU WIADOMOŚCI STRUKTURA WIADOMOŚCI - FIPA ACL

PROSTE I ZŁOŻONE AKTY KOMUNIKACYJNE – SYNTAKTYKA ACL FORMALNE PODSTAWY SEMANTYKI ACL

KATALOG AKTÓW KOMUNIKACYJNYCH – OPIS FORMALNY I NARRACYJNY PROTOKOŁY INTERAKCJI

(2)

SPECYFIKACJE FIPA

1.1.normy- specyfikują zewnętrzne zachowania agenta i jego współpracę z innymi podsystemami ujętymi w specyfikacji FIPA

1.2.informacje o aplikacjach– określające sposób użycia technologii FIPA

Specyfikacje FIPA 97 składają się z siedmiu części:

 trzy części typu normy dotyczące podstawowych technologii agentowych:

zarządzanie agentami, język komunikacji między agentami oraz integrację między agentami i nieagentowymi programami

 cztery zawierające informacje o aplikacjach prezentujących użycie specyfikacji typu normy: asystent podróżującego, asystent osoby, aplikacje audio-wizulne oraz transmisje, zarządzanie i pośredniczenie w sieci

(3)

Część 1 Agent Management Część ta opisuje normy dotyczące:

 istnieniem agentów

 operacyjnością agentów

 zarządzaniem agentami

Deinicja platfomy agenta, pojęcie białej i żółtej ksiegi, przysyłaniem wiadomości oraz zarządzaniemcyklami życia agenta, akty komunikacyjne agenta wyrażaj.ace jego inteligentne zachowanie oraz odpowiadająca ontologia oraz język zawartości wiadomości

Częśc 2 Język komunikacji agenta

The FIPA Agent Communication Language (ACL) jest oparty na teorii aktów mowy:

wiadomości są akcjami lub akty komuniakcyjne. Specyfikacja składa się :

 ze zbioru typów wiadomości, które zawierają opis pragmatyki tych wiadomości wyrażające stosunek typu BDI agenta do innego agenta/agentów. Opis jest przedstawiony w formie narracyjnej i formalnej opartej na lopgice modalnej.

 Ze zbioru opisów protokołów komunikacji Część 3 Integracja Agent/Software

Część ta opisuje sposób integrowania oprogramowania nieagentowego z oprogramowaniem agentowym:

 Systemy baz danych

 Oprogramowanie sieciowe

 Oprogramowanie narzędziowe

(4)

Część 4 –Osobisty Asystent Podróży Turystyka obejmuje następujące komponenty:

 Zaopatrzeniowiec

 Pośrednik

 Usługi osobiste

Role te pełni agent typu PTA - Personal Travel Agent

(5)

Część 5– Osobisty Asystent

Jest nim półautonomiczny agent typu PA (Personal Assistant) o nastepujących cechach:

 Realizuje usługi zaopatrzeniowe

 Informuje

 Zarządza podstawowymi danymi

 Organizuje rozrywkę

 Planuje czas przeznaczony na pracę i odpoczynek

 Organizuje spotkania

Częśćt 6 - Przedsięwzięcia Audio/Video i transmisje

 Wybór właściwych programów uwzględniając preferencje użytkownika

 Negocjuje zmiany w programach

Część 7 – Zarządzanie i zabezpieczanie sieci

 Dostarczanie usług końcowym użytkownikom zgodnie z zasadą jakości usług i kosztu usług

 Idea VPN (Virtual Private Network) – połączenia z wybranymi użytkownika na ich życzenie

Zapewniają te usługi trzy typy agentów:

 The Personal Communications Agent (PCA) – reprezentuje interes użytkownika

 The Service Provider Agent (SPA) - reprezentuje interes zaopatrzeniowca w zakresie usług

 The Network Provider Agent (NPA) – reprezentuje interesy zaopatrzeniowca sieci

(6)

KOMUNIKACJA MIĘDZY AGENTAMI Cechy komunikacji:

Komunikację rozważa się na poziomie aplikacji w zakresie spełnianiej misji przez agenta operując jego mentalnymi atrybutami:

 Belief (stosunek typu wiara) oznacza zbiór propozycji, które agent akceptuje i zbiór propozycji, które agent nie akceptuje podczas negocjacji (stan wiary i niewiary w odniesieniu do propozycji)

 Uncertainty (stosunek typu niepewność) oznacza zbiór propozycji, które agent akceptuje lub nie akceptuje z pewnym poziomem niepewności, czy są prawdziwe lub fałszywe. Oznacza to, że agent przyjmuje model negocjacji, gdy przedmiotem jest niepewna informacji bez uciekania się do modeli statystycznych

 Intention (stosunek typu intencja) oznaczają wybór lub właściwość lub zbiór właściwości, które agent życzy sobie, aby były prawdziwe i te, w ktore agent nie wierzy. Intencje są przedstawiane w postaci planu akcji (np. Mapy stanów ), wyznaczonych przez wybór agenta, które wynikają ze stanu świata rzeczywistego

Np. W odniesieniu do danych propozycji p, stan wiary p, stan niewiary p, stan niepewności p i stan pewności p wykluczają się wzajemnie.

Dodatkowo, agents wie i jest zdolny do wykonania pewnych akcji. W rozproszonych systemach agent jest jedynie zdolny do spełnienia swoich intencji za pomocą wpływu wywieranego na innych agentów do wykonania akcji.

Wpływ wywierany na innych agentów osiąga się za pomocą specjalnej klasy akcji zwanych aktami komunikacyjnymi (communicative acts). Polega to na wysyłaniu komunikatów zawierających zakodowany ak przez nadawcę do odbiorcy.

Ważną rolę odgrywa budowa wiadomości oraz posiadanie tej samej wiedzy na temat BUI

Np. Agent i wierzy, że “lepiej jest czytać książki niż oglądać TV” i uważa, że agent j będzie uważał podobnie. Agent i w ACL inform informuje j swojej o wierze typu prawda. Agent j na podstawie semantyki inform wie, że agent i chce wpłynąć na jego intencje dotyczące wiary w wartość czytania książek, ale dla agenta j przyjęcie wiary agenta i może stanowić pewien problem.

(7)

Stąd ważnymi problemami są:

 transport wiadomości między agentami

 struktura wiadomości

 syntaktyka transporu wiadomości ACL w strumieniu bajtów

 katalog standardowych aktów komunikacyjanych

 zbiór i definicja podstawowych protokołów komunikacji zawierających zbiór wiadmości

 definicja modelu komunkacji

MECHANIZM TRANSPORTU WIADOMOŚCI

Usługę transportu wiadomości spełnia system zarządzania agentami Wymagania usług transportu wiadomości (niezbędne):

a) przesyłanie zakodowanej wiadomości w postaci sekwencji bajtów b) usługi transportu powinny być niezawodne, dokładne, uporządkowane

(kolejność)

c) nie spełnienie tych własności powinno być sygnalizowane

d) agent ma opcję wyboru sposobu odebrania wiadomości: uśpienie lub oczekiwania na wiadomość (tryb synchroniczny) lub wykonywanie innych czynności podczas oczekiwania na odpowiedź

e) czas przeterminowania nie jest parametrem aktu komunikacyjnego, tylko systemu usług transporu wiadomości

f) po wykryciu błędów, system może wysłać informację o tym fakcie do nadawcy w postaci wiadomości o błędzie

g) system zapewnia wybór poprawnego mechanizmu transportu (TCP/IP, SMTP, http, etc)

Kodowanie wiadomości : 7-bitowy odpowidający standardowi ISO/IEC 2022 oraz wykorzystuje inne sposoby kodowania znaków specjalnych:

 ISO/IEC 646 (US ASCII) jest zastosowane do G0;

 ISO/IEC 6429 jest zastosowane do C0 ;

 G0 jest wyrażone w GL;

 C0 jest wyrażone w CL;

 SPACE w 2/0 (0x20) oraz

 DELETE w 7/15 (0x7f)

(8)

STRUKTURA WIADOMOŚCI - FIPA ACL

Typ wiadomości jest zgodny z typem zawartości wiadomości, którą powinna charakteryzować:

 kompletność

 prostota

 zwięzłość.

Wiadomość reprezentuje akt komunikacyjny, jest jego synonimem

Semantyka języka komunikacji pownien być oparta na precyzyjnym formaliźmie, pozbawionym sprzeczności. W praktyce podstawy formalne są zrealizowane w postaci protokołów komunikacji (w postaci narracyjnej), a nie w postaci formalnej semantyki (semantyki operacyjnej)

Wymagania wobec agentów Wymaganie 1:

Agenty mogą wysłać not-understood, jeśli otrzymają wiadomość, której nie rozpoznają lub nie są w stanie odczytać zawartości wiadomości. Agenty muszą odebrać i obsłużyć taką wiadomość

Wymaganie 2:

Agent powinien posiadać pre-definiowany zbiór typów wiadomości i protokołów, zgodnych z definicją aktów semantycznych.

Wymaganie 3:

Nie należy przedefiniować znaczenia istniejących predefiniowanych aktów komunikacyjnych

Requirement 4:

Agenty mogą wprowadzać nowe akty komunikacyjne zrozumiałe przez odbiorcę, jednak nie wolno im nadawać znaczenia istniejących aktów komunikacyjnych.

Requirement 5:

Agent powinien poprawnie formułować zawartość generowanej wiadomości oraz z taką samą poprawnością odczytywac wiadomości.

(9)

Struktura wiadomości – s-wyrażenie

Akt komunikacyjny wiadomości odpowiada aktowi KQML zwanym performative

(10)

Parametry wiadomości

Obowiazujacym parametrem jest receiver, ale wiadomość jest sensowana wtedy, gdy ma więcej parametrów

Tab. 1 — Pre-definiowane parametry wiadomości :Parametry

wiadomości

Znaczenie:

:sender Nazwa agenta nadającego akt komunimacyjny.

:receiver Nazwa agenta, do którego wysylana jest wiadomość. Może to być pojedyncza nazwa lub zbiór nazw agentów - multicasting :content Zawartość wiadomości, czyli treść akcji

:reply-with Wprowadza wyrażenie, które identyfikuje oryginalną wiadomość.

Może być używane w wątku konwersacji, jeśli jednocześnie prowadzi się kilka dialogów jednocześnie

Np. Jeśli agent i wysyła wiadomość do agenta j wiadomość, która zawiera

:reply-with query1, agent j powinien odpowiedzieć :in-reply-to query1.

:in-reply-to Oznacza wyrażenie, które odpowiada wcześniejszej akcji, dla której stanowi odpowiedź.

:envelope Oznacza wyrażenie, które jest użyteczne dla systemu usług transportowych i zawiera czas wysłania, czas odbioru, trasę itp.

Struktura koperty jest listą par słów kluczowych, które oznaczają pewne aspekty usług wiadomości

:language Oznacza schemat kodowania zawartości wiadomości.

:ontology Oznacza ontologię, która jest używana do podania znaczenia symboli używanych w wyrażeniu.

:reply-by Oznacza czas i/lub datę wyrażenia, ktora oznacza ostatni czas, kiedy wysyłający agent wystapił w roli odpowiadajacego

:protocol Wprowadza identyfikator, który oznacza protokół, który zastosował wysyłajacy agent. Protokół dodatkowo podaje kontekst wiadomości.

:conversation-id Wprowadza wyrażenie, które jest używane do identyfikacjisekwencji wychodzących wiadomości, które tworzą konwersację.

Konwersacja może być użyta do zarządzania strategią

komunikacji i aktywności agenta oraz do dodatkowej interpretacji znaczenia wiadomości

(11)

Zawartość wiadomości

Zawartość wiadomości odpowiada przeznaczeniu aktu komunikacyjnego. Wiadomość czyli akt komunikacyjny jest zdaniem, natomiast zawartość jest gramatycznym obiektem zdania. Zawartość jest zapisana w języku podanym w parametrze :language.

Wymaganie 6:

Ogólnie, język zawartości wiadomości musi wyrażać propozycje, obiekty i akcje.

Język ten nie musi wyrażać nic więcej, jedynie typy akcji: propozycje informowanie, żądania itp.

Stany propozycji - true lub false

Obiekty – rzeczy abstrakcyjne lub konkretne

Akcje – agent staje sie aktywny (iota <variable> <term>) np. iota x(P x) oznacza, że x taki, że P [jest prawdziwe] dla x. Słowo iota jest konstruktorem dla termów.

Definicja 1:

Język zawartości wiadomości FIPA jest oparty na gramatyce s-wyrażeń lub jej podgramatyce i umożliwia wyrażanie propozycji, obiektów i akcji odpowiadających cyklowi życia agenta.

Wymaganie 7:

Agent jest zobowiązany do wyrażania swoich możliwości wymieniając wiadomości napisane za pomocą języka zawartości wiadomości i stosując określoną ontologię-oznaczone jako fipa-agent-management

Reprezentowanie zawartości wiadomości

Zagnieżdzony łańcuch \"Ian\" zawiera znaki \" w zawartości wiadomości ograniczonej znakami " "

(inform :content "owner( agent1, \"Ian\" ) "

:language Prolog … )

lub podanie długości łańcucha do zawartości wiadomości (przez zdaniem reprezentującym wiadomość)

(inform :content #22"owner( agent1, "Ian" ) :language Prolog

… )

Użycie MIME do wyrażania dodatkowej zawartości wiadomości

Wyrażanie wiadomości zawierającej informację o błędzie w języku angielskim na język japoński może okazać się bardzo niewygodne

< English tekst> na < Japanese tekst>”

The Multipurpose Internet Mail Extensions (MIME) standard jest przeznaczony do wyrażania kontekstu internetowych wiadomości [Freed & Borenstein 96]. Syntaktyka wiadomości MIME jest odmienna od gramatyki ACL, jednak może stanowić rozszerzenie informacji zawartej w podstawowym wyrażeniu ACL (rozszerzenie syntaktyki ACL)

(12)

PROSTE I ZŁOŻONE AKTY KOMUNIKACYJNE – SYNTAKTYKA ACL

Proste akty komunikacyjne są atomowe. Złożone akty komunkacyje są budowane z prostych aktów komunikacyjnych w następujący sposób (w języku SL, ktory spełnia wymagania dotyczące gramatyki s-wyrażeń):

 tworząc jeden akt komunikacyjny jako obiekt innego aktu komunikacyjnego np.

"I request you to inform me whether it is raining" - jako akt komunikacyjny typu query-if .

 Używając composition operator “;” np. a ; b (b po a)

 Używając composition operator “|” do niedeterministycznego wyboru akcji a | b (albo a, albo b)

Syntaktyka wiadomości - format standardu EBNF

Prawa gramatyki Przykłady

Końcowy znak "("

Wyrażenie nieterminalne zapisane kapitalikami Expression

Opcjonalna konstrukcja ["," OptionalArg ] Alternatywa (pionowa kreska) Integer | Real Gwiazdka oznacza zero lub więcej powtórzeń

poprzedzającego wyrażenia Digit *

Plus oznacza jeden lub więcej powtórzeń

poprzedzającego Alpha +

Nawiasy służą do grupowania ekspansji ( A | B ) * Produkcje są zapisane za pomocą

nieterminalnych nazw z prawej strony, ekspansji z prawej strony, końcowych jako końcowa postać zapisu produkcji

ANonTerminal = "an expansion".

Reguły gramatyczne dla znaków leksykalnych są podobne, jednak są jeszcze dodatkowe reguły leksykalne:

Reguły leksykalne Example

Zbiór znaków ["a", "b", "c"]

Zakres znaków ["a" - "z"]

Tylda oznacza uzupełnienie w postaci

zbioru znaków, jeśli jest pierwszy znak [ ~ "(", ")"]

Post-fiksowy znak zapytania oznacza, że poprzedzające wyrażenie leksykalne jest opcjonale (może pojawic się zero lub jeden raz)

["0" - "9"]? ["0" - "9"]

(13)

Reguły gramatyczne syntaktyki wiadomości ACL ACLCommunicativeAct = Message.

Message = "(" MessageType MessageParameter* ")".

MessageType = "accept-proposal"

| "agree"

| "cancel"

| "cfp"

| "confirm"

| "disconfirm"

| "failure"

| "inform"

| "inform-if"

| "inform-ref"

| "not-understood"

| "propose"

| "query-if"

| "query-ref"

| "refuse"

| "reject-proposal"

| "request"

| "request-when"

| "request-whenever"

| "subscribe".

MessageParameter = ":sender" AgentName | ":receiver" RecipientExpr

| ":content" ( Expression | MIMEEnhancedExpression ) | ":reply-with" Expression

| ":reply-by" DateTimeToken | ":in-reply-to" Expression | ":envelope" KeyValuePairList | ":language" Expression

| ":ontology" Expression | ":protocol" Word

| ":conversation-id" Expression.

Expression = Word | String | Number

| "(" Expression * ")".

(14)

MIMEEnhancedExpression – optional extension. See Annex D.

KeyValuePairList = "(" KeyValuePair * ")".

KeyValuePair = "(" Word Expression ")".

RecipientExpr = AgentName

| "(" AgentName + ")".

AgentName = Word

| Word "@" URL.

URL = Word.

Lexical rules

Word = [~ "\0x00" - "\0x20",

"(", ")", "#", "0"-"9", "-", "@"]

[~ "\0x00" - "\0x20", "(", ")"] *.

String = StringLiteral

| ByteLengthEncodedString.

StringLiteral = "\""

( [~ "\"" ] | "\\\"" )*

"\"".

ByteLengthEncodedString = "#" ["0" - "9"]+ "\""

<byte sequence>.

Number = Integer | Float.

DateTimeToken = "+" ?

Year Month Day "T"

Hour Minute Second MilliSecond (TypeDesignator ?).

Year = Digit Digit Digit Digit.

Month = Digit Digit.

Day = Digit Digit.

Hour = Digit Digit.

Minute = Digit Digit.

Second = Digit Digit.

MilliSecond = Digit Digit Digit.

TypeDesignator = AlphaCharacter.

Digit = ["0" – "9"].

(15)

Wyjaśnienia

a) przyjęto standardową definicje typów całkowitych i zmiennoprzecinkowych b) słowa kluczowe są niezależne

c) długość łańcucha wynika kontekstu nagłówka # liczba całkowita" i zakłada się, że znaki są 8-bitowe

d) wiadomość powinna być sformułowana zgodnie z zasadami gramatyki SL

e) łańcuchy powinny być zapisane w gramatyce ISO/IEC 2022 wyrażonej w notacji EBNF, znaki w kodach ESC (0x1B), SO (0x0E) oraz SI (0x0F

f) Znaki czasu są oparte na formacie ISO8601 rozszerzone do czasu absolutego i względnego i opóźnień milisekundowych. Czas względny jest wyróżniany za pomocą znaku +. Desygnator UTC jest znakiem Z i jest stosowany przy niejednoznacznym określaniu czasu

Np. 8 :30 am on April 15th 1996 czasu lokalnego jest zapisany : 19960415T083000000

lub w UTC 19960415T083000000Z

lecz 1 godzina, 15 minut i 35 milisekund jest zapisane jako +00000000T011500035.

g) nazwy agentów są wyrażane w standardzie FIPA 97 ; poprawnie sformułowany adres URL jest następujący :

AccessTypeSpecifier "://" InternetAddress ":" PortNumber "/" Identifier

(16)

FORMALNE PODSTAWY SEMANTYKI ACL Wprowadzenie

Model przedstawiany jedynie prezentuje znaczenie pewnych elementów komunikacji między agentami w odniesieniu do zastosowanego języka.

Wymiana informacji między dwoma agentami SL – JĘZYK SEMANTYKI ACL

Podstawy języka:

 p, p1, ... formuły zamknięte reprezentujące propozycje

 φ i ψ są schematami formuł

 i i j są zmiennymi reprezentującymi agentów

 |=φ oznacza, że φ jest prawidłowy.

Mentalny model agenta oparty jest na trzech postawach : belief, uncertainty and choice i czasem na goal). Są one reprezentowane przez operatory B, U, i C.

Formuły oparte na tych operatorach są odczytywane następująco:

 B ip “i (bezwarunkowo) wierzy (że) p”

 U ip “i jest niepewny, czy co do p, ale myśli, że p jest pewniejszy niż ¬p”

 C ip “i oczekuje, że p obecnie działa”

Mówiąc o złożonych planach, zdarzeniach lub akcjach używa sie następujących wyrażeń:

 a1 ; a2 is a sequence w której a2 wystąpi po a1

 a1  a2 is a nondeterministic choice, w której albo wydarzy się a1 lub a2, ale nie razem.

(17)

Operatory Feasible, Done i Agent , Single są wprowadzone w celu wnioskowania o akcjach:

 Feasible( a, p ) znaczy, że a może się wydarzyć, i jeśli a wydarzy się, p będzie prawdziwe zaraz po zakończeniu a

 Done( a, p ) znaczy, że a już sie wydarzyło i p było prawdziwe tuż przed wykonaniem a

 Agent( i, a ) znaczy, że i oznacza tylko działanie agenta, lub działanie, które dopiero się wykona podczas zdarzenia a.

 Single( a ) oznacza, że a oznacza wyrażenie akcji, które niejest sekwencją.

Każda indywidualna akcja jest Single. Złożona akcja a ; b nie jest Single.

Złożona akcja a | b jest Single, jeśli a i b obie są Single.

Formuła dotycząca celu

PGi p oraz Iip oznacza, że i ma p jako trwały (P) cel (G) i i ma intencję (I) podjęcia p Formuły można zagnieżdżać: Ui BjIi Done(a, Bip ) oznacza, że agent i

prawdopodobnie uważa, że agent j wierzy, że i ma intencję, że akcja a bedzie wykonana, kiedy i będzie wierzyć w p

Podstawową własnością logiki jest modelowanie agenta zgodnie z jego mentalną postawą - czyli z tego, że prawdziwy jest schemat formuły φ wynika, że agent

bezwarukowo wierzy w schemat formuły φ, i z tego, że agent bezwarunkowo wierzy w schemat formuły φ, wynika że jest ona prawdziwa.

|=φ ⇔ Bi φ, gdzie φ jest schematem formuły, w którą bezwarunkowo wierzy agent i Skróty

i) Feasible( a ) ≡ Feasible( a, True ) ii) Done( a ) ≡ Done( a, True )

iii) Possible( φ ) ≡ (a)Feasible( a, φ )

po wykonaniu akcji a możliwe jest, że schemat formuły φ jest prawdziwy iv) Bifiφ ≡ Biφ ∨ Bi¬φ

albo agent i wierzy w schemat formuły φ lub nie wierzy w schemat formuły φ v) Brefiδ(x) ≡ (y)Bi (ιx)δ(x) = y

gdzie ι jest operatorem definiującym opis i (ιx)δ(x) są czytane “ (x który jest) δ“.

Brefiδ(x) oznacza, że agent i wierzy, że wiadomo że (x który jest) δ, jest równy y.

vi) Uifiφ ≡ Uiφ ∨ Ui¬φ

Uifiφ oznacza, że gent i is niepewny (w sensie podanym wyżej), czy schemat formuły φ jest prawdziwy lub jest niepewny, czy schemat formuły jest

nieprawdziwy ¬φ.

vii) Urefiδ(x) ≡ (y)Ui (ιx)δ(x) = y

Urefiδ(x) oznacza to samo co Brefiδ(x), za wyjątkiem, jeśli i ma niepewny stosunek do δ(x) równego y zamiast wiary

viii) ABn,i,jφ ≡ BiBjBi … φ

wprowadza koncepcję o alterantywnej wierze, n (dodatnia liczba całkowita) jest liczbą operatorów B występujących naprzemian między i oraz j.

(18)

Termin "knowledge" jest używany w sensie "wierzy lub jest niepewny".

Semantyka Modelu

Własność 1

Jeśli agent ma intencje otrzymania odpowiedzi, to w celu wyrażenia jego możliwości planowania, agent musi spełniać nastepujące własności:

Niech ak jest takim aktem, że:

i) (x) Bi ak = x, //agent i wierzy, że dla danego x formuła ak jest spelniona przez x

ii) p is the RE of ak and // p jest racjomalnym efektem aktu ak

iii) ¬Ci¬Possible( Done(ak) ); //agent i wybiera jedynie możliwy akt ak do wykonania

wtedy zachodzi formuła:

Ii p ⇒ Ii Done(a1...an) gdzie a1, ...,an są aktami typu ak.

Własność ta mówi, że jeśli agent ma intencję osiągnięcia celu p, generuje intencję realizacji tego celu. Czyli, jeśli racjonalny efekt jakiegoś aktu spełnia cel agenta, agent nie ma powodów, aby nie zrealizować tego aktu.

Zbiór warunków przed dla aktu komunikacyjnego składa się z dwóch zbiorów: warunki zdolności wykonania oraz warunki wynikające z kontekstu.

Własność 2

Własność wyrażająca intencje agenta, że po wykonaniu akcji a będzie on wierzył lub będzie wierzył i miał intencję.

|= Ii Done(a) ⇒ Bi Feasible(a) ∨ IiBi Feasible(a) Własność 3

Z tego, że agent ma intencję wykonania akcji a, wynika, że agent ma intencje uzyskania racjonalnego efektu związanej z akcją a.

|= Ii Done(a) ⇒ Ii RE(a)

gdzie RE(a) to racjonalny efekt akcji a.

Własność 4

Komplementarny efekt planowania aktu komunikacyjengo –Agent i wierzy, że z tego że akt a może być wykonany i że uczestniczy w nim agent j wynika, że agent j ma intencję otrzymania racjonalnego efektu tego aktu– efekt intencyjny:

|= Bi( Done(a) ∧ Agent( j, a ) ⇒ Ij RE(a) )

(19)

Inna, pełna postać własności 4:

Agent i wierzy, że z tego że akt a może być wykonany i że uczestniczy w nim agent j wynika, że agent j ma intencję, że agent i wierzy, że agent j ma intencję otrzymania racjonalnego efektu tego aktu.

|= Bi( Done(a) ∧ Agent( j, a ) ⇒ Ij Bi IjRE(a) ) Własność 5

Niektóre skutki wykonania FP (Persistent Feasibility) ujawniają się po wykonaniu aktu komunikacyjnego, stąd formuła ta określa własności dla FP.

Agent i wierzy, że z tego że wykonany został akt a wynika, że pojawią się możliwe skutki jego działania

|= Bi( Done(a) ⇒ FP(a) )

Notacje

Akt komunikacyjy jest reprezentowany nastepująco:

<i, Act( j, C )>

FP: φ1

RE: φ2

gdzie i jest inicjatorem akcji, j jest uczestnikiem , Act jest nazwą aktu, C reprezentuje semantyczny kontekst lub proponowany kontekst i φ1 and φ2 są propozycjami, FP jest możliwym skutkiem działania Act, RE jest racjonalnym efektem działania Act.

Przykład ( Act

:sender i :receiver j :content C )

(20)

Uwagi osymbolach używanych w formule

Symbol

: Użycie:

A Oznacza akcję

Np a = <i, inform(j, p)>

act Oznacza typ akcji Np. act = inform(j, p) Stąd, jeśli

a = <i, inform(j, p)>

i

act = inform(j, p) wtedy

a =<i, act>

φ Oznacza schemat formuły P Konkretna formuła

φ jest schematem formuły, czyli zmienną oznaczającą formułę, p jest gotową formułą

Pomocnicze definicje

a) Możliwe jest wystąpienie aktu e, gdy prawdziwa jest formuła φ, co oznacza, że przed wykonaniem aktu e formuła była nieprawdziwa, natomiast po wykonaniu aktu e

formuła stała się prawdziwą

Enables(e, φ ) = Done( e, ¬φ ) ∧φ

b) Nigdy nie wykona się akt e’, jeśli prawdziwy jest schemat formuły φ, co oznacza, że jeśli akty e1 i e2 są wykonywane sekwencyjnie po e’, to z tego wynika, że akt e2 może wykonać się tylko wtedy, gdy nieprawdziwa jest formuła φ.

Has-never-held-since( e', φ ) = (e1) (e2) Done( e'; e1 ; e2 ) ⇒ Done( e2, ¬φ )

(21)

KATALOG AKTÓW KOMUNIKACYJNYCH – OPIS FORMALNY I NARRACYJNY Kategorie aktów komunikacyjnych

Communicative act Information passing

Requesting information

Negotiation Action performing

Error handling

accept-proposal +

agree +

cancel +

cfp +

confirm +

disconfirm +

failure +

inform +

inform-if (macro act)

+ inform-ref (macro

act)

+

not-understood +

propose +

query-if +

query-ref +

refuse +

reject-proposal +

request +

request-when +

request-whenever +

subscribe +

(22)

accept-proposal

Działanie: Akcja akceptowania poprzednio odebranej propozycji wykonania akcji Zawartość

wiadomości :

Krotka zawierająca akcje do wykonania i warunki akceptacji propozycji

Opis: Accept-proposal jest całkowitą zgodą na poprzednio złożoną propozycję najczęściej w akcie propose. Agent wysyłając zgodę informuje odbiorcę o warunkach wykonania przez niego akcji.

Np. Odebrano propozycję “hold a meeting anytime on Tuesday”.

Wysyłając akceptacje propozycji podaje się dodatkowy warunek:

godzinę spotkania np. 11.00. Ten warunek nie był uwzględniony

podczas składania propozycji, ale jest akceptowany przez składającego propozycję.

Model formalny

<i, accept-proposal(j, <j, act>, φ))>≡

<i, inform(j, Ii Done(<j, act>, φ))>

FP : Biα∧¬Bi (Bifjα∨ Uifjα) RE : Bjα

gdzie α = Ii Done(<j, act>, φ)

i informuje j, że i ma intenecję, że j wykona akcję, jeśli podane warunki staną się prawdziwe (φ)

Przykład Agent i informuje j, że akceptuje jego ofertę, która dotyczy

skierowania podanego tytułu multimedialnego 1234 do kanału 19, kiedy klient 78 będzie gotowy. Agent i inform j o tym fakcie:

(accept-proposal :sender i

:receiver j

:in-reply-to bid089 :content

(

(action j (stream-content movie1234 19)) (B j (ready customer78))

)

:language sl)

(23)

agree

Dzialanie: Akcja wyrażania zgody na akcje, które będą wykonywane w przyszłości Zawartość

wiadomości :

Krotka zawierająca identyfikator agenta, wyrażenie reprezentujące akcję do wykonania i propozycję warunków akceptacji

Opis: Agree jest zgodą na odebraną wcześniej wiadomosć typu request z poleceniem wykonania akcji. Agent wysyłajacy zgodę zapowiada wykonanie akcjji tylko wtedy, gdy podane warunki wstępne będą prawdziwe.

Model formalny

<i, agree(j, <i, act>, φ))>≡

<i, inform(j, Ii Done(<i, act>, φ))>

gdzie

α = Ii Done(<i, act>, φ)

Agent i informuje j, że ma intencję wyrażenia zgody na na wykonanie prze siebie akcji, pod warunkiem, że pewne warunki będą spełnione (φ) Przykład Agent i (kolejkowanie zadań) żąda od agenta j (robot), aby przestawił

pudło w inne miejsce- j zgadza się, lecz zaznacza, że to zadanie ma niski priorytet.

(request :sender i :receiver j

:content (action j (deliver box017 (location 12 19))) :protocol fipa-request

:reply-with order567 )

(agree :sender j :receiver i

:content ((deliver j box017 (location 12 19)) (priority order567 low))

:in-reply-to order567 :protocol fipa-request )

(24)

cancel

Działanie: Kasowanie akcji, które mają charakter przejściowy Zawartość

wiadomości :

Akcja określona w zawartości wiadomości jest kasowana

Opis: Kasowanie umożliwia przerwanie wykonywanej akcji, której żądano wcześniej. Zakłada się, że akcja przerwana jeszcze się nie wykonała lub jeszcze nie zaczęła się. W odpowiedzi na kasowanie wysyła się wiadomość typu refuse do wysyłającego wcześniej żądanie

wykonania akcji.

Model formalny

<i, cancel(j, a)>≡

<i, disconfirm(j, Ii Done(a))>

FP : ¬Ii Done(a) ∧ Bi (Bj Ii Done(a) ∨ Uj Ii Done(a)) RE : Bj¬Ii Done(a)

Kasowanie jest akcją kasowania dowolnej żądanej akcji. Oznacza to, że agent i żądał, aby agent j wykonał pewne akcje, jeśli określone warunki byłyby spełnione. Jest to efekt informowania przez i agenta j o swoich intencjach. Kiedy i odrzuca swoje intencje, informuje o tym j za pomocą aktu disconfirm.

Przykład Agent j0 prosi i o skasowanie poprzedniej akcji request-whenever (cancel

:sender j0 :receiver i

:content (request-whenever :sender j …) )

Agent j1 prosi i o skasowanie akcji żądanej poprzednio w podanej konwersacji:

(cancel

:sender j1 :receiver i

:conversation-id cnv0087 )

(25)

cfp

Działanie: Zapraszanie do podawania propozycji do wykonania podanej akcji Zawartość

wiadomości :

Krotka zawiera wyrażenie określające akcję do wykonania oraz warunki wykonania akcji

Opis: CFP jest akcją podejmowania negocjacji przez zapraszanie do składania propozycji. Protokół negocjacji jest określany za pomocą parametru wiadomości typu :protocol .

Agent, który otrzyma cfp, odpowiada wiadomością typu propose, z

podaną propozycją oraz warunkami jej wykonania – propozycja musi być kompatybilna z warunkami podanymi w cfp. Np. cfp zawiera propozycję wyjazdu pociagiem, stąd propozycja nie może dotyczyć lotu samolotem, natomiast może określić typ pociągu (normalny, ekspres..)

Model formalny

<i, cfp( j, <j, act>, φ(x) )>≡

<i, query-ref(j,ιx (Ii Done(<j, act>, φ(x)) (Ij Done(<j, act>, φ(x))))>

FP : ¬Brefi(ιx α(x)) ∧¬Urefi(ιx α(x)) ∧¬Bi Ij Done(<j, Inform-ref(i,ιx α(x))>)

RE : Done(<j, Inform(i,ιx α(x) = r1)>| … |<j, Inform(i,ιx α(x) = rk)

>) gdzie

α(x) = Ii Done(<j, act>, φ(x)) ⇒ Ij Done(<j, act>, φ(x))

Agent i pyta agenta j: "Jakie jest x, dla którego wykonasz akt a, bo będzie prawdziwe φ (x)?"

Przykład Agent j składa propozycję agentowi i sprzedania mu 50 skrzynek śliwek (cfp

:sender j :receiver i

:content ((action i (sell plum 50)) true)

:ontology fruit-market )

(26)

confirm

Działanie: Nadawca informuje odbiorcę, że podana propozycja jest prawdziwa, gdy odbiorca jest niezdecydowany, czy propozycja jest prawdziwa Zawartość

wiadomośc i:

Propozycja

Opis: Agent nadawca:

• wierzy w prawdziwość propozycji

• wyraża intencję, że odbiorca tak samo wierzy w prawdziwość propozycji

• wierzy, że odbiorca ma pewien poziom nieufności dotyczącej prawdziwości propozycji

Dwie pierwsze własności oznaczają, że odbiorca zna propozycję,

natomiast trzecia oznacza otrzymanie przez j wiadomości typu inform, która wyjaśnia wątpliwości agenta j. Z punktu widzenia odbiorcy, wiadomość typu confirm określa jego wiarę, że:

• nadawca wierzy w propozycje podane w zawartości wiadomości

• nadawca oczekuje, że odbiorca również wierzy w propozycje Model

formalny

Prosty akt komunikacyjny

<i, confirm( j, φ )>

FP: Biφ∧ BiUjφ RE: Bjφ

Przykłady Agent i utwierdza agenta j, że prawdą jest, że dzisiaj pada śnieg.

(confirm :sender i :receiver j

:content "weather( today, snowing )"

:language Prolog)

(27)

disconfirm

Działanie: Nadawca informuje odbiorcę, że dana propozycja jest fałszywa, gdy odbiorca uważa, że ta propozycja jest prawdziwa

Zawartość wiadomośc i:

Propozycja

Opis: Ten akt komunikacyjny jest używany, wtedy gdy jeden agent chce zmienić mentalność drugiego agenta

Nadawca:

• wierzy, że pewne propozycje są fałszywe

• ma intencję, że odbiorca także zacznie wierzyć, że propozycje są fałszywe

• wierzy, że odbiorca albo wierzy w propozycje albo nie jest pewny czy są prawdziwe.

Dwie pierwsze właściwości oznaczają, że nadawca jest szczery i ma intencję, że odbiorca zna propozycje. Ostatnia właściwość oznacza, że agent powinien wysłać akt confirm, inform lub disconfirm, ale ten ostatni akt jest użyty najwłaściwiej, gdy odbiorca wierzy w propozycje lub jest niepewny co do propozycji

Z punktu widzenia odbiorcy, wiadomość disconfirm upoważania go do wiary, że:

• nadawca wierzy, że propozycje są fałszywe

• nadawca życzy sobie, aby odbiorca także uwierzył, że propozycje są fałszywe

Zmiana przekonań odbiorcy jest funkcją ufności obiorcy w opowiedzi na szczerość i pewność nadawcy.

Model formalny

//Prosty akt komunikacyjny

<i, disconfirm( j, φ )>

FP: Bi¬φ∧ Bi(Ujφ∨ Bjφ) RE: Bj¬φ

Przykład Agent i, wierząc, że j myśli, że rekin jest ssakiem, próbuje zmienić jego przekonanie

(disconfirm :sender i :receiver j

:content (mammal shark))

(28)

failure

Działanie: Akt, w którym jeden agent przekazuje informację innemu agentowi, że podjęto próbę wykonania akcji, jednak próba nie powiodła się.

Zawartość wiadomości :

Krotka, która zawiera odbiorcę, wyrażenie opisujące akcję i wyjaśnienie przyczyn niepowodzenia akcji

Opis: Wiadomość ta jest skrótem informującym, że nadawca wie, że akcja jest wykonalna, ale nie została dokończona z podanych przyczyn.

Odbiorca otrzymujący taką wiadomość jest zobowiązany do tego, aby wierzyć, że:

• akcja nie została wykonana

• akcja jest wykonalna (w czasie, gdy agent próbował ją wykonać).

Przyczyna niepowodzenia jest wyrażona w postaci propozycji, jako trzeciego elementu krotki zawartości informacji. Przyczyna może być reprezentowana za pomocą stałej równej true. Nie ma gwarancji, że przyczynę niepowodzenia zrozumie odbiorca: to może być jedynie komunikat w postaci informacji o błędzie.

Model formalny

<i, failure(j, a, φ)>≡

<i, inform(j, (e) Single(e) ∧ Done(e, Feasible(a) ∧ Ii Done(a)) ∧φ ∧¬Done(a) ∧¬Ii Done(a))>

gdzie

α = (e) Single(e) ∧ Done(e, Feasible(a) ∧ Ii Done(a)) ∧φ∧¬Done(a) ∧¬Ii

Done(a)

Agent i informuje j, że w przeszłości i miał intencję wykonania akcji a i akcja a jest wykonalna. Agent i próbował wykonać akcję a (zdarzenie/akcja e jest próbą wykonania akcji a), ale nie udało mu się, więc teraz nie ma dłużej intencji wykonania akcji a, a przyczyna niepowodzenia jest opisana formułą φ.

Przykład Agent j informuje i, że otwarcie przez niego pliku zakończyło się błędem:

(failure :sender j :receiver i :content (

(action j "open( \"foo.txt\” )")

(error-message "No such file: foo.txt") )

:language sl)

(29)

inform

Działania: Nadawca informuje odbiorcę, że dana propozycja jest prawdziwa.

Zawartość wiadomośc i:

Propozycja

Opis: Nadający agent:

• utrzymuje, że dana propozycja jest prawdziwa

• ma intencję, że odbiorca zacznie wierzyć, że propozycja jest prawdziwa

• nie wierzy, że odbiorca ma wystarczajacą wiedzę na temat prawdziwości propozycji.

Dwie pierwsze własności definiują prosto: nadawca jest szczery i uważa (ma intencję), że odbiorca pozna propozycję. Ostatnia własność

koncentruje się na semantyce aktu. Jeżeli agent zna życie, wie że trudno zakładać (mieć intencję), że odbiorca uwierzy w formułę p wysłaną w wiadomości. Własność ta nie jest tak silna, jak można przypuszczać.

Nadawca nie wymaga, aby odbiorca znał p. To jest tylko przypadek, w którym nadawca dostrzega, co wie odbiorca.

Z punktu widzenia odbiorcy, odebrana wiadomość zoobowiązuje go do wiary, że:

• nadawca wierzy w propozycję zawartą w wiadomości

• nadawca życzy odbiorcy, aby ten również uwierzył w propozycję.

Zmiana przekonań odbiorcy jest funkcją ufności obiorcy w opowiedzi na szczerość i pewność nadawcy.

Model formalny

<i, inform( j, φ )> //prosty akt komunikacyjny FP: Biφ∧¬ Bi( Bifjφ∨ Uifjφ)

RE: Bjφ

Agent i informuje agenta j, że pewne propozycje są prawdziwe (φ), jeśli agent i wierzy w nie (φ). Oznacza to, że i nie wierzy, że j już wierzy w φ lub jej negację lub j jest niepewny co do φ. Jeśli i jest pewien, że j już wierzy w φ, nie wysyła wiadomości. W przypadku, gdy i wierzy, że j nie wiery w φ, i czeka na wiadomość typu disconfirm, w przeciwnym wypadku czeka na confirm.

Przykłady Agent i informuje agenta j, że prawdą jest, że dzisiaj pada:

(inform :sender i :receiver j

:content "weather( today, raining )"

:language Prolog)

(30)

inform-if (macro act)

Działanie: Makro akcja dla agenta nadawcy informujacego odbiorcę czy propozycja jest prawdziwa czy też nie.

Propozycja

Description: Akt inform-if (macro act) jest skrótem informującym, czy dana propozycja jest godna wiary. Agent, który uczestniczy w akcie inform-if macro-act aktualnie wykonuje standardowy akt typu inform. Zawartość aktu zależy od wiary agenta nadawcy w moc informowania. Propozycja jest wyrażona za pomoca schematu formuły φ oraz:

• jeżeli agent nadawca wierzy w propozycję, informuje innego agenta o propozycji φ

• jeżeli agent nadawca wierzy w negację propozycji, informuje, że φ jest fałszywa (czyli ¬φ)

Bez takich własności agent nie mógłby zrealizować swoich planu. Np.

jeżeli nie miałby wiedzy o φ, wysłałby wiadomość typu refuse.

Model formalny

i, inform-if(j,φ)>≡

<i, inform(j,φ)>|<i, inform(j,¬φ)>

FP : Bifiφ∧¬Bi (Bifjφ∨ Uifjφ) RE : Bifjφ

Inform-if reprezentuje dwa możliwe tory akji: i informuje j , że φ lub i informuje j, że nie φ.

Przykłady Agent i żąda od j informacji, czy Lannion jest w Normandii:

(request :sender i :receiver j :content

(inform-if :sender j :receiver i

:content "in( lannion, normandy )"

:language Prolog) :language sl)

Agent j odpowiada, że nie jest:

(inform :sender j :receiver i

:content "\+ in( lannion, normandy )"

:language Prolog)

(31)

inform-ref (macro act)

Działanie: Nadawca informuje odbiorcę, że należy zdefinować deskryptor Zawartość

wiadomości Wykonanie deskryptora

Opis: Akt inform-ref (macro act) pozwala nadawcy poinformawać odbiorcę o obiektach, które mogą być przydatne do utworzenia deskryptora.

Inform-ref jest aktem makro, gdy jest rozłączny z aktem inform, który informuje, o obiekcie o nazwie x. Np. agent może planować akt inform-ref dotyczący czasu bieżącego agenta j i wykonuje “inform j, że jest godzina 10.45”. Agent wykonujący akcję powinien wierzyć, że obiekt odpowiadający definicji deskryptora jest przekazany i nie musi wierzyć, że odbiorca wie o tym. Agent odbiorca może wysłać wiadomość refuse, jeśli warunki aktu są niewłaściwe.

Model formalny

<i, inform-ref(j,ιx δ(x))>≡

<i, Inform(j,ιx δ(x) = r1)> | ... | (<i, Inform(j,ιx δ(x) = rk)>

FP: Brefi ιx δ(x) ∧¬Bi(Brefj ιx δ(x) ∨ Urefj ιx δ(x)) RE: Brefj ιx δ(x)

Inform-ref reprezentuje niegraniczony, możliwie nieskończony zbiór akcji, w których i informuje j o powiązaniach x .

Przykład Agent i żąda od j informacji o tym, kto jest premierem Wielkiej Brytanii:

(request :sender i :receiver j :content

(inform-ref :sender j :receiver i

:content (iota ?x (UKPrimeMinister ?x)) :ontology world-politics

:language sl )

:reply-with query0 :language sl) Agent j odpowiada:

(inform :sender j :receiver i

:content (= (iota ?x (UKPrimeMinister ?x)) "Tony Blair")

:ontology world-politics :in-reply-to query0)

Zauważ, że standardowy skrót dla aktu request z aktem inform-ref w przykładzie może być akt query-ref.

(32)

not-understood

Działanie: Nadawca i informuje odbiorcę j, że przypuszczał, że j wykona akcje, ale nie rozumie, że j już to zrobił. Szczególny przypadek dotyczy sytuacji, że i powiadamia j, że nie rozumie wiadomości odebranej od niego.

Zawartość

wiadomośc: Krotka zawierająca akcje lub zdarzenie (np. akt komunikacyjny) i przyczynę

Opis: Nadawaca otrzymał wiadomość, której nie rozumie. Jest kilka przyczyn:

agent nie potrafi wykonać akcji lub spodziewał się innej wiadomości. Ten akt jest używany także w przypadkach, kiedy i informuje j , że nie

rozumie akcji j.

Drugi term z zawartości krotki reprezentuje przyczynę braku rozumienia.

Reprezentacja przyczyny ma postać tekstową i nie gwarantuje, że prawidłowo wyraża powód niezrozumienia u nadawcy.

Model formalny

<i, not-understood(j, a)>≡

<i, Inform( j, (x) Bi ((ιe Done(e) ∧ Agent(e, j) ∧ Bj(Done(e) ∧ Agent(e, j) ∧ (a = e))) = x))>

FP : Biφ∧¬Bi (Bifjα∨ Uifjα) RE : Bjα

gdzie

α = (x) Bi ((ιe Done(e) ∧ Agent(e, j) ∧ Bj(Done(e) ∧ Agent(e, j) ∧ (a = e))) = x)

Agent 'i' nie zna ostatnio obserwowanego zdarzenia (x) Bi ((ιe Done(e) ∧ Agent(e, j)) = x)

Agent 'i' wierzy, że agent 'j' zna 'a' jako ostatnie zdarzenie, które 'j' właśnie wykonał:

Bi ((∃e) Bj(Done(e) ∧ Agent(e, j) ∧ (a = e))

Przykłady Agent i nie rozumie wiadomości query-if, ponieważ nie ropoznaje ontologii:

(not-understood

:sender (agent-identifier :name i)

:receiver (set (agent-identifier :name j)) :content

"((action (agent-identifier :name j) (query-if

:sender (agent-identifier :name j)

:receiver (set (agent-identifier :name i)) :content

\"<fipa-ccl content expression>\"

:ontology www :language fipa-ccl))

(unknown (ontology \"www\")))"

:language fipa-sl)

(33)

propagate

Działanie Nadawca uważa, że odbiorca traktuje wbudowaną wiadomość jako wysłaną prosto do odbiorcy i chce, aby odbiorca zidentyfikował agentów za pomocą deskryptora i przesłał im odebraną wiadomość typu propagate razem z wiadomością wbudowaną

Zawartość

wiadomości: Krotka deskryptora, zawierająca wyrażenie wyznaczające agenta lub agentów otrzymujacego/ch: propagowaną wiadomość przekazaną przez nadawcę do odbiorcy, wbudowaną wiadomość w wiadomośc propagowaną, warunki propagacji, oraz czas przeterminowania.

Opis To jest akcja złożona z dwóch akcji. Pierwsza z nich dotyczy nadawcy, który żąda od odbiorcy traktowania wbudowanej wiadomości w wiadomości propagowanej jako wiadomości przeznaczonej prosto dla odbiorcy/ów. Druga z ich dotyczy nadawcy, który chce, aby odbiorca zidentyfikował odbiorcę lu odbiorców proppagownej widomości, czyli agenta lub agentów na postawie podanego deskryptora i wysłał jemu/im zmodyfikowaną wersję propagowanej wiadomości do tych agentów, a tym samym również domyślnie wbudowaną wiadomość.

Przy przekazywaniu informacji parametr :receiver jest ustawiany na zidentyfikowanego odbiorcę i parametr :sender jest ustawiany na bieżącego odbiorcę. Ten akt komunikacyjny jest przeznaczony do przesyłania wiadomości wbudowanych do zrzeszonych agentów np.

żądanie pośredniczenia lub stałe żądanie za pomocą aktów request- when/request-whenever wbudowanych w wiadomość typu proxy, która jest wiadomością propagowaną w wiadomości typu propagate Model

formalny

<i, propagate (j, Ref x δ(x), <i, cact>, φ)> ≡ <i, cact(j)>;

<i, inform (j, Ii((∃y) (Bj(Ref x δ(x) = y) ∧

Done (<j, propagate (y, Ref x δ(x), <j, cact>, φ)>, Bjφ))))>

FP: FP (cact) ∧ Bi α∧¬Bi (Bifj α∨ Uifj α) RE: Done (cact) ∧ Bj α

gdzie :

α= Ii((∃y) (Bj(Ref x δ(x) = y) ∧

Done (<j, propagate (y, Ref x δ(x), <j, cact>, φ)>, Bj φ)))

Agent i wysyła wbudowaną wiadomość do j <i, cact(j)> oraz i chce, aby j wysłał wiadomość typu propagate do wyznaczonych agentów za pomocą Ref x δ(x).

Zauważ, że wbudowana wiadomość <i, cact> w wiadomości propagowanej propagate nie ma parametru :receiver, ponieważ jest nim odbiorca wiadomości propagowanej

Ref x δ(x) jest jednym z wyrażeń zwiazanych: ιx δ(x), jakiś x δ(x) lub każdy x δ(x).

(34)

Przykład Agent i żąda od agenta j i jego stowarzyszonych pośredniczących agentów do pośredniczenia w usługach “video na żądanie” w zakresie osiągania programów "SF" .

(propagate

:sender (agent-identifier :name i)

:receiver (set (agent-identifier :name j)) :content

((any ?x (registered (agent-description :name ?x

:services (set

(service-description

:name agent-brokerage)))) (action (agent-identifier :name i) (proxy

"((all ?y (registered (agent-description :name ?y

:services (set

:name video-on-demand))))) (action (agent-identifier :name j) (request

:sender (agent-identifier :name j) :content

\"((action ?z

(send-program (category "SF"))))\"

:ontology vod-server-ontology :protocol fipa-reqest …))

true)"

:ontology brokerage-agent-ontology :conversation-id vod-brokering-2 :protocol fipa-brokering …)) (< (hop-count) 5))

:ontology brokerage-agent-ontology …)

(35)

propose

Działanie: Akcja przedstawiania propozycji wykonania pewnej akcji przy podanych warunkach

Krotka zwierająca opis akcji e, reprezentująca akcję, w ktorej nadawca proponuje wykonanie akcji w podanych warunkach

Opis: Propose jest używana do składania propozycji lub odpowiedzi na propozycję akcji, która ma być wykonana w podanych warukach w wyniku prowadzonych negocjacji. Aktualny protokół negocjacji jest podany w parametrze wiadomości :protocol. Nadawca wiadomości informuje odbiorcę, że ma intencje wykonania akcji, jeśli będą spełnione warunki, a odbiorca powiadamia nadawcę o swojej intencji wykonania przez nadawcę akcji.

Typowe zastosowanie to specyfikacja ceny przez pośrednika w aukcji lub w negocjacjach.

Model formalny

<i, propose(j, <i, act>, φ)>≡

<i, inform(j, Ij Done(<i, act>, φ) ⇒ Ii Done(<i, act>, φ))>

gdzie

α = Ij Done(<i, act>, φ) ⇒ Ii Done(<i, act>, φ)

i informuje j, że raz j informuje i, że j ma intencje wobec i do wykonania akcji a, i waruki wykonania a są spełnione. i przyjmuje intencję

wykonania a.

Przykład Agent j informuje i, że sprzeda 50 skrzynek ze śliwkami w cenie $200:

( propose

"((action j (sell plum 50))

(= (any ?x (and (= (price plum) ?x) (< ?x 10))) 5)"

:ontology fruit-market :in-reply-to proposal2 :language fipa-sl)

(36)

proxy

Działanie Nadawca chce, aby odbiorca wybrał docelowych agentów oznaczonych zgodnie z otrzymanym opisem i wysłał im wbudowaną wiadomość

Zawartość

wiadomość: Krotka deskryptora zawiera wyrażenie referencyjne, które wyznacza docelowych agentów odbiorców wiadomości wbudowanej, wiadomość wbudowaną, która ma być wysłana do agentów odbiorców oraz warunki ograniczające wykonanie wbudowanych aktów komunikacyjnych np. maksymalną liczbę agenów, do których rozsyła sie wbudowaną wiadomość

Opis Nadawca informuje odbiorcę o potrzebie zidentyfikowania agentów oznaczonych za pomocą deskryptora i wysłania im wbudowanej wiadomości. Podczas wysyłania wbudowanej wiadomości parametr : receiver zawiera zbiór zidentyfikowaych agentów, natomiast parametr :sender ma wartość agenta odbierającego wiadomość typu proxy.

Jeśli wbudowany akt komunikacyjny zawiera parametr :reply-to, musi on być umieszczony w wykonywanej wbudowanej wiadomości.

W przypadku żądania pośredniczącego (gdy parametr :protocol parameter jest oznaczony jako fipa-brokering), agent pośredniczący (odbiorca wiadomości typu proxy) musi sam ustawić pewne parametry wiadomości: :conversation-id, :reply-with, :sender itp.

w otrzymanej wbudowanej wiadomosci w celu wysłania odpowiedzi od agentów docelowych do agenta żądającego (nadawcy wiadomości typu proxy).

(37)

Model

formalny <i, proxy (j, Ref x δ(x), <j, cact>, φ)> ≡ <i, inform (j, Ii((∃y)(Bj (Ref x δ(x) = y) ∧ Done (<j, cact(y)>, Bjφ))))>

FP: Bi α∧¬Bi (Bifj α∨ Uifj α) RE: Bj α

gdzie:

α= Ii((∃y) (Bj (Ref x δ(x) = y) ∧ Done (<j, cact(y)>, Bj φ)))

Agent i chce, aby j wysłał wbudowaną wiadomość do agentów oznaczonych za pomoca Ref x δ(x).

Zauważ, że <j,cact> w wiadomościach typu wiadomosć ACL jest bez parametru :receiver. Jej odbiorca jest oznaczony za pomocą Ref x δ (x).

Zauważ: Ref xδ(x) jest jednym z referencjnych wyrażeń: ιx δ(x), dowolny xδ(x) lub wszystkie x δ(x).

Można wyróżnić dwa typy wiadomości typu proxy. Jedna z nich określana jest jako silna, ponieważ warunki wykonalności wiadomości wbudowanej odpowiadają wykonalności wiadomości typu proxy. Czyli jeśli agent i chce nadać wiadomość typu inform z propozycją ψ do agenta y za pośrednictwem j, agent j musi wierzyć w ψ , zanim wyśle wiadomość wbudowaną do y.

Drugi typ wiadomości typu proxy jest określany jako słaby, ponieważ nie wymaga sie, aby agent i wierzył w ψ. W tym przypadku agent j nie musi wprost informować y o ψ, ponieważ agent j nie jest usatysfakcjonowany warunkami wykonalności wiadomości wbudowanej. W tym przypadku j tylko informuje y o intencjach nadawcy i wiadomości typu proxy, wyrażonych za pomocą ψ. Słaby rodzaj może być wyrażony jako wystąpienie wiadomosci typu proxy, gdzie akcja <j,cact(y)> jest zastąpiona przez <j, inform(y, Ii Done (<i, cact(y)>))>.

(38)

Przykład Agent i żąda od agenta j, aby agent j zwerbował serwera i żądał od niego usługi “video na żądanie” dotyczącej przesłania "SF"

programów.

(proxy

((all ?x (registered(agent-description :name ?x

:services (set

:name video-on-demand))))) (action (agent-identifier :name j) (request

:sender (agent-identifier :name j) :content

"((action ?y

(send-program (category "SF"))))"

:ontology vod-server-ontology :language FIPA-SL

:protocol fipa-request

:reply-to (set (agent-identifier :name i)) :conversation-id request-vod-1)

true)

:language FIPA-SL

:ontology brokerage-agent :protocol fipa-recruiting

:conversation-id vod-brokering-1 …)

(39)

query-if

Działanie: Akcja pytania innego agenta, czy dana propozycja jest prawdziwa czy fałszywa

Propozycja.

Opis: Query-if jest aktem pytania innego agenta, czy dana propozycja jest prawdziwa (odbiorca wierzy, że jest prawdziwa). Nadawca żąda od odbiorcy informacji, czy propozycja jest prawdziwa.

Agent nadający akt query-if :

• nie ma wiedzy na temat prawdziwości propozycji

• wierzy, że inny agent zna prawdę o propozycji I wyjąsni ja pytającemu agentowi

Model Formal

<i, query-if(j,φ) ≡

<i, request(j, <j, inform-if(i,φ)>)>

FP: ¬Bifiφ∧¬Uifiφ∧¬Bi Ij Done(<j, inform-if(i, φ)>) RE: Done(<j, inform(i, φ)>|<j, inform(i, ¬φ)>)

i żąda od j, aby j informował i, czy jest lub nie prawdziwy schemat formuły φ.

Przykład Agent i pyta agenta j, czy zarejestrował się sewerze d1:

(query-if :sender i :receiver j :content

(registered (server d1) (agent j)) :reply-with r09

…)

Agent j odpowiada agentowi i, że nie zarejestrował sie na serwerze d1 (inform

:sender j :receiver i

:content (not (registered (server d1) (agent j))) :in-reply-to r09

)

(40)

query-ref

Działanie: Akcja pytania innego agenta o obiekt opisany wyrażeniem referencyjnym

Zawartość wiadomośc:

Definicja deskryptora

Opis: Query-ref jest aktem pytania innego agenta odbiorcę o informacje o obiekcie identyfikowanym przez definiowany deskryptor. Nadawca żąda od odbiorcy wykonania aktu typu inform, zawierającego informację o obiekcie odpowiadającym definiowanemu deskryptorowi.

Agent nadajacy wiadomość typu query-ref:

 nie wie, który obiekt odpowiada deskryptorowi

 wierzy, że agent odbiorca wie, który obiekt odpowiada zdefiniowanemu deskryptorowi i udzieli informacji pytającemu agentowi

Model formalny

<i, query-ref(j,ιx δ(x)) ≡

<i, request(j, <j, inform-ref(i,ιx δ(x))>)>

FP: ¬Brefi(ιx δ(x))∧¬Urefi(ιx δ(x))

∧¬Bi Ij Done(<j, inform-ref(i, ιx δ(x))>)

RE: Done(<i, Inform(j,ιx δ(x) = r1)>|...|<i, Inform(j,ιx δ(x) = rk)>) Agent i żąda od agenta j, aby ten informował agenta i o powiązaniach x Przykład Agent i pyta agenta j o usługi spełniane przez niego:

(query-ref :sender i :receiver j :content

(iota ?x (available-services j ?x)) …)

j odpowiada, że może zarezerwować bilet na pociąg, samolot, autobus

(inform :sender j :receiver i :content

(= (iota ?x (available-services j ?x)) ((reserve-ticket train)

(reserve-ticket plane) (reserve automobile)) )

…)

(41)

refuse

Działanie: Akt odmówienia wykonania akcji i wyjaśnienie przyczyn odmowy Zawartość

informacji: Krotka zawierająca wyrażenie akcji oraz przyczyny

Opis: Akt typu refuse jest skrótem zaprzeczania komuś (czyli disconfirming), że akcja jest możliwa do wykonania i wyjaśnienie przyczyn

Akt ten jest wykonywany, gdy agent nie ma warunków, zarówno jawnych jak i ukrytych, do wykonania akcji.

Agent otrzymujący akt odmowy jest zobowiązany do tego, aby wierzyć, że:

• akcja nie jest wykonana

• akcja nie jest wykonalna (z punktu widenia nadawcy)

• przyczyna odmowy jest reprezentowana za pomocą propozycji, która jest trzecim elementem krotki zawartości wiadomości (jeśli jest to stała, musi byc równa true). Nie ma gwarancji, że sposób wyrażenia

przyczyny będzie zrozumiały dla odbiorcy.

Model formalny

<i, refuse(j, <i, act>, φ)> ≡ <i, disconfirm(j, Feasible(<i, act>))>;

<i, inform(j,φ∧¬Done(<i, act>) ∧¬Ii Done(<i, act>))>

FP : Bi ¬Feasible(<i, act>) ∧ Bi (Bj Feasible(<i, act>) ∨ Uj Feasible(<i, act>)) ∧ Biα∧¬Bi (Bifjα∨ Uifjα) RE : Bj¬Feasible(<i, act>) ∧ Bjα

gdzie α = φ∧¬Done(<i, act>) ∧¬Iⁱ Done(<i, act>)

i informuje j, że akcja a nie jest wykonalna, z podanych przyczyn, oraz agent i nie ma intencji do wykonania akcji a.

Przykład Agent j odmawia agentowi i rezerwacji biletu, od momentu gdy i nie ma wystarczającej kwoty na koncie:

(refuse

"((action (agent-identifier :name j) (reserve-ticket LHR MUC 27-sept-97)) (insufficient-funds ac12345))"

:language fipa-sl)

(42)

reject-proposal

Działanie: Akcja odmowy propozycji wykonania akcji podzcas negocjacji Zawartość

wiadomości :

Krotka zawierająca opis akcji, propozycję, która zostaje odrzucona oraz przyczyny odmowy.

Opis: Akt typu reject-proposal jest odmową poprzednio przyjętej propozycji. Agent wysyłający odmowę informuje odbiorcę, że nie ma intencji wykonania danej akcji z podanych przyczyn.

Dodatkowa propozycja reprezentuje przyczyny odmowy wykonania proponowanej akcji. Trudno odnieść podane przyczyny do akcji, model formalny przyjmuje, że były one prawdziwe dla nadawcy w momencie odmowy. Syntaktycznie przyczyna jako poprzednik we wnioskowaniu jest traktowana jako przyczyna wyjaśniajacą odmowę, chociaż nie jest uwzględniania w formalnej semantyce.

Model formalny

<i, reject-proposal(j, <j, act>, φ, ψ)>≡

<i, inform(j, ¬Ii Done(<j, act>, φ) ∧ψ)>

gdzie

α = ¬Ii Done(<j, act>, φ) ∧ψ

i informuje j, że z powodu ψ i nie ma intencji wykonania akcji przy prawdziwych warunkach opisanych φ.

Przykład Agent i informuje j, że odrzuca ofertę kupna śliwek od j, ponieważ cena jest za wysoka

(reject-proposal

"((action (agent-identifier :name j) (sell plum 50))

(cost 200)

(price-too-high 50))"

:in-reply-to proposal13)

(43)

request

Działanie: Nadawca żąda od odbiorcy wykonania pewnej akcji, np.

innego aktu komunikacyjnego.

Opis akcji.

Opis: Nadawca żąda od odbiorcy wykonania pewnych akcji.

Zawartość widomości jest opisem akcji do wykonania, w języku zrozumiałyum dla odbiorcy. To może to być dowolna akcja: podniesienie skrzynki, zarezerwowanie biletu na

samolot, zmiana hasła. Ważnym zastosowaniem tego aktu jest budowa złożonej konwersacji między agentami, gdzie

wykonywane akcje są innymi aktami komunikacyjnymi np.

typu inform.

Model formalny

<i, request( j, a )> //prosty akt komunikacyjny FP: FP(a) [i\j] ∧ Bi Agent( j, a ) ∧¬Bi Ij Done(a) RE: Done(a)

gdzie

 a jest zmienną, która zastępuje dowolne wyrażenie akcji

 FP(a) oznacza skutki wykonania dla a;

 FP(a) [i \j] oznacza, że część skutków wykonania akcji a jest wyrażona własnościami mentalnymi agenta i.

Przykłady Agent i żąda od agenta j otwarcia pliku:

(request :sender i :receiver j

:content "open \"db.txt\" for input"

:language vb)

(44)

request-when

Działanie: Nadawca chce, aby odbiorca wykonał pewne akcje, jeśli pewne warunki będą spełnione.

Zawartość

wiadomości Krotka opisu akcji i propozycji

Opis: Akt request-when pozwala nadawcy informować innego agenta, że pewna akcja może być wykonana wtedy, gdy będą spełnione warunki wyrażone w postaci wyrażenia, które staje sie prawdziwe.

Agent otrzymujący request-when powinien albo odmówić albo zapewnić, że akcja będzie wykonana, gdy warunki będą spełnione. To zobowiązanie trwa do czasu, gdy warunki stają się prawdziwe i żądający agent kasuje akt request-when lub agent odbiorca decyduje się dłużej nie honorować zobowiązań i wysyła wiadomoś typu refuse.

Nie ma specjalnych specyfikacji dla zobowiązań – nie ma wpływu na specyfikację częstość wykonywaych akcji oraz związek między akcją a zobowiązaniem – liczy się tylko to, co wynegocjuje agent przyjmujący akt request-when.

Model formalny

<i, request-when(j, <j, act>, φ)> ≡

<i, inform(j, (e') Done(e') ∧ Unique(e')

∧ Ii Done(<j, act>, (e) Enables(e, Bjφ) ∧ Has-never-held-since(e', Bjφ)))>

gdzie

α = (e') Done(e') (Unique(e') ∧

Ii Done(<j, act>, (e) Enables(e, Bjφ) ∧

Has-never-held-since(e', Bjφ)) i informuje j , że i ma intencję, aby j wykonał pewne akcje, jeśli j uwierzy w φ.

Przykłady Agent i mówi agentowi j, aby zawiadomił go wtedy, gdy wystąpi alarm (wysłanie wiadomości typu inform).

(request-when

"((action (agent-identifier :name j) (inform

\"((alarm \"something alarming!\"))\")) (Done( alarm )))"

…)

(45)

request-whenever

Dzialanie: Nadawca chce, aby odbiorca wykonał pewne akcje tak szybko jak pewne propozycje (warunki) staną się prawdziwe i po pewnym czasie powtórzył je, kiedy propozycje (warunki) znowu staną się prawdziwe.

Zawartość wiadomości

Krotka z opisem akcji i propozycją

Opis: Akt request-whenever pozwala agentowi informować innego agenta, że pewna akcja może byc wykonna tak szybko jak tylko warunki stana się prawdziwe. W przeciwnym wypadku, jeżeli warunki staną się

fałszywe akcja może sie powtórzyć dopiero wtedy, gdy ponownie staną się prawdziwe.

Akt request-whenever reprezentuje stałe zobowiązanie do ponownego wykonania akcji, jeśli warunki i akcja ulegną zmianie i będą właściwe.

Bieżący agent może pozbyć się zobowiązań prze wykonanie akcji cancel.

Nie ma specjalnych specyfikacji dla zobowiązań – nie ma wpływu na specyfikację zobowiązań częstość wykonywanych akcji oraz związek między akcją a zobowiązaniem – liczy się tylko to, co wynegocjuje agent przyjmujący akt request-whenever.

Model formalny

<i, request-whenever(j, <j, act>, φ)>≡

<i, inform(j, Ii Done(<j, act>, (e) Enables(e, Bjφ)))>

gdzie

α = Ii Done(<j, act>, (e) Enables(e, Bjφ))

i informuje j, że i ma intencję, aby j wykonał pewne akcje, jeśli kiedykolwiek pewne warunki staną się prawdziwe wyrażone wiarą agenta j w φ.

Przykłady Agent i mówi agentowi j, aby powiadomił go (wysłanie wiadomości typu inform-ref), jeśli kiedykolwiek cena urządzenia wzrośnie z poziomu poniżej 50 do poziomu powyżej 50

(request-whenever

"((action (agent-identifier :name j) (inform-ref

\"((iota ?x (= (price widget) ?x)))\")) (> (price widget) 50))"

…)