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 +
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)
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>, φ))>
FP : Biα∧¬Bi (Bifjα∨ Uifjα) RE : Bjα
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 )
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 )
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 )
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)
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.
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))
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))>
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
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.
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)
inform-if (macro act)
Działanie: Makro akcja dla agenta nadawcy informujacego odbiorcę czy propozycja jest prawdziwa czy też nie.
Zawartość wiadomości :
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
Agent j odpowiada, że nie jest:
(inform :sender j :receiver i
:content "\+ in( lannion, normandy )"
:language Prolog)
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.
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
: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.
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
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
(unknown (ontology \"www\")))"
:language fipa-sl)
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
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).
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
:ontology brokerage-agent-ontology :conversation-id vod-brokering-2 :protocol fipa-brokering …)) (< (hop-count) 5))
:ontology brokerage-agent-ontology …)
propose
Działanie: Akcja przedstawiania propozycji wykonania pewnej akcji przy podanych warunkach
Zawartość wiadomości :
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.
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
:sender (agent-identifier :name j)
:receiver (set (agent-identifier :name i)) :content
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).
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)>))>.
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
:sender (agent-identifier :name i)
:receiver (set (agent-identifier :name j)) :content
((all ?x (registered(agent-description :name ?x
:services (set
(service-description
: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 …)
query-if
Działanie: Akcja pytania innego agenta, czy dana propozycja jest prawdziwa czy fałszywa
Zawartość wiadomości :
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
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
)
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
j odpowiada, że może zarezerwować bilet na pociąg, samolot, autobus
(inform
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>) ∧¬Ii 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
:sender (agent-identifier :name j)
:receiver (set (agent-identifier :name i)) :content
"((action (agent-identifier :name j) (reserve-ticket LHR MUC 27-sept-97)) (insufficient-funds ac12345))"
:language fipa-sl)
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
Opis: Akt typu reject-proposal jest odmową poprzednio przyjętej