[Modeling] RE: [IP] Fipa Interaction Protocol Library Spec
G Hopmans [Morpheus]
g.hopmans@mssm.nl
Sat, 31 May 2003 12:11:48 +0200
This is a multi-part message in MIME format.
------=_NextPart_000_0006_01C3276D.D0513F90
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hell Marc-Philippe and all,
Thank you for your response! I send this message to the modeling list as
well. Hopefully that will attract more 'listeners' to the ip-list as
well ;)
(subscribe at: h <http://www.fipa.org/mailman/listinfo/ip>
ttp://www.fipa.org/mailman/listinfo/ip)
At the end of my answer to this e-mail you (and the modeling TC) can
find my comments on the Interaction Diagrams Working Draft.
~-----Original Message-----
~From: ip-admin@fipa.org [mailto:ip-admin@fipa.org] On Behalf
~Of Marc-Philippe Huget
~Sent: vrijdag 30 mei 2003 18:04
~To: Gabriel Hopmans; ip@fipa.org
~Subject: Re: [IP] Fipa Interaction Protocol Library Spec
~
~
~Hello Gabriel and all,
~
~Gabriel Hopmans wrote:
~
~> 1. The Fipa Interaction Protocol Library Spec
~>
~> I noticed that during the eXperimental to Standard TC sessions, the
~> specification for the Interaction Protocol Library has been
~> deprecated. I do not know the exact reasons but I presume that 'the
~> problem' was in the old specification chapter 3 titled the
~> representation of the Interaction Protocols. I think
~updating chapter
~> 3 together with the Modeling TC will do for working to a
~> specification. I studied the rest of the specification and
~I think it
~> is still valid.
~
~A lot of work is done in this moment in Modeling TC to
~improve Agent UML interaction diagram to represent
~interaction protocols, I agree that we need to update this
~specification as well but my question is when and how. I
~don't clearly understand what you propose as new in the
~specification. Could you help me on this point?
Well I don't propose something new, it is more updating. Updating
Chapter 3 with the alternatives of how to represent Interaction
Protocols will do.
When? Well if the FIPA FAB has no other things (then those in chapter 3)
I would say as soon as possible because it is 'strange' to have FIPA
Interaction Protocol specifications without
any introduction what it is, anything that introduces the IP-library or
what to do with it.
How? Writing a small summary about the alternatives (for representing
Ips)
~
~> The question to the Modelling TC is if there is a kind of
~> Glossary/Summary of the Interactions specifications
~available for the
~> chapter in this specification?
~
~Actually, there is no glossary and readers _must_ read the
~specification but since this latter is quite technical, I
~think we can do something more user-oriented.
~
~> The question to everyone on this list is: who would like to
~volunteer
~> working on this specification?
~
~Yes sure
Ok thank you
~
~> 2. Ontologies for Interaction Protocols
~>
~> I think it will be a good idea to discuss the following: "We need
~> associations between agent actions and Agent capability ontology
~> (association ontology)." See paper Stephen Cranefield (available at
~> http://www.fipa.org/docs/input/f-in-00076/).
~>
~> For instance in the Contract Net IP I think it would be
~good to have
~> something for how the messages between the manager and
~responders are
~> related. The core idea is about a task to be performed and thus an
~> ontology with an association between the action-to-be-performed and
~> the price that responding agents bid would be nice. Of
~course in the
~> ontology we do not find what the task is because this is for the
~> internal side of an agent but only the concept the
~responder and the
~> sender refer to.
~
~Maybe it does not answer your question but new AUML
~Interaction diagram specification includes the notion of
~actions related to message sending and receiving but this
~point is still in its infancy in the proposal
Sorry I didn't wrote this very clear, I think this is not what I meant.
Do you mean by the "notion of actions" the actions like:
Request-info, ask-identify, provide-identity etc...?
By the action-to-be-performed I more meant a whole activity that has
nothing to do with FIPA Communicative Acts. To explain a bit more I use
the following. It is a part of an older e-mail conversation between Jim
and me:
>> Gabriel: One last remark that triggers me about AUML and FIPA IP's:
The real
>> calculation of the Borda Count winner is something that is not
visible
>> within the Interaction Protocol. This is about the same for the
Contract
>> net. In the contract net one of the essentials for the initiator is
the
>> mechanism in which he decides to choose the agent to assign the task
to. (in
>> which he also checks pre-conditions etc..)
>> Is there any kind of diagram to model these kind of mechanisms?
>
>Jim: Each of the thin rectangles that go over the dashed "lifelines"
(which are
>currently called "ExecutionOccurrences" in UML 2.0) can be expressed in
more
>detail as activity diagrams. Would that help?
>
>-Jim
In the working draft there is something like the Interaction Overview
diagram I think that also can be useful in detailing some activities in
more detail. But if ExectutionOccurrences are better I would pay more
attention to it in the (working draft of the) specification.
~
~> Thus it would be good to have a broader set of different
~Interaction
~> Protocols. The details for my proposal for the Borda Count Protocol
~> can be found at the links below. This draft specification for the
~> Borda IP has not been updated yet with the work of the
~Modeling TC but
~> I would like to hear feedback before I am going to give it
~an update.
~
~Will read it once again, any deadline?
~
Thank you, well if I have to update it after your feedback before the
next FIPA meeting, 1 July would be great.
More alternatives to other Interaction Protocols are not proposed yet.
Although I saw some interesting titles of related work that will be
presented at Agentcities iD4 (papers).
Now my comments to the Interaction Diagram working Draft:
First of all, in the MS-word version on the AUML website the dates in
the Footer are still on the date of the older version
Section 2.1.3 Constraints
The parameters in the pentagon in the upper-left corner for the
instantion of a protocol is a good idea. BUT section 2.1.3 Constraints
says: the number of parameters must match exactly the number of
parameters. That is Ok but then I hope that there are different
possibilities? When I implement the IP I could for instance make a
choice between protocol 1a (1 parameter) and protocol 1b (2 parameters)
when instantiating it.
Example in figure 3 one would instantiate the protocol with a date. It
should be possible to instantiate without one (or use NULL).
Next sentence: What does "prepend" means?
In the previous version there was a line (if was the first sentence):
"even if it is not mandatory, it is preferable that protocol names are
different over the set of protocols, in order to distinguish them each
other"
Jim didn't understand this line and is deleted now. But I think I
understand the sentence if it is changed to:
"even if it is not mandatory, it is preferable that protocol names are
different over the available set of FIPA Interaction Protocols, in order
to distinguish them from each other"
I think that when people would like to design their own new FIPA
Interaction Protocols they can come up with their own names and some
protocols can be variations of existing ones.
Section 2.3 Messages
An introduction or referring to FIPA ACL Communicative Act would be
helpful.
2.3.1. Description
Page 9 we have the sentence: The content of the message is given above
the arrow. I would propose to change that into: Parts of ACL-structure
levels like the performative is given .. or
The performative of the message and some parameter information is given
..
The next sentence: There is no formalization to depict message content
and depends greatly on the agent communication language used. Why ?
Don't we all use FIPA ACL?
subsection 2.3.5 Examples
In this subsection we find figures with messages like Request-info:
Needs some introduction.
I don't completely understand the difference between asynch/synch.
messages. If there is no control over the messages then it is for
instance possible that in figure 14 the first message that is send and
understand by both agents could be the third message: provide-identity?
(Or are we only talking about TIME-control?)
Section 3: Interaction Overview Diagrams
These diagrams are really helpful. More with ExecutionOccurences. (see
my reply above)
Best regards,
Gabriel Hopmans
Morpheus Software
http://www.mssm.nl
------=_NextPart_000_0006_01C3276D.D0513F90
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DVerdana>Hell =
Marc-Philippe and=20
all,<BR><BR>Thank you for your response! I send this message to the =
modeling=20
list as well. Hopefully that will attract more 'listeners' to the =
ip-list as=20
well ;)</FONT></FONT></FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>(subscribe at: h<A=20
href=3D"http://www.fipa.org/mailman/listinfo/ip"><U><FONT =
color=3D#0000ff=20
size=3D2>ttp://www.fipa.org/mailman/listinfo/ip</U></FONT></A>)</FONT></P=
>
<P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DVerdana>At the end =
of my answer=20
to this e-mail you (and the modeling TC) can find my comments on the =
Interaction=20
Diagrams Working Draft.</FONT><BR></FONT><BR> ~-----Original=20
Message-----<BR> ~From: ip-admin@fipa.org [<A=20
href=3D"mailto:ip-admin@fipa.org">mailto:ip-admin@fipa.org</A>] On=20
Behalf<BR> ~Of Marc-Philippe Huget<BR> ~Sent: vrijdag 30 mei =
2003=20
18:04<BR> ~To: Gabriel Hopmans; ip@fipa.org<BR> ~Subject: Re: =
[IP]=20
Fipa Interaction Protocol Library =
Spec<BR> ~<BR> ~<BR> ~Hello=20
Gabriel and all,<BR> ~<BR> ~Gabriel Hopmans=20
wrote:<BR> ~<BR> ~> 1. The Fipa Interaction Protocol =
Library=20
Spec<BR> ~><BR> ~> I noticed that during the =
eXperimental to=20
Standard TC sessions, the<BR> ~> specification for the =
Interaction=20
Protocol Library has been<BR> ~> deprecated. I do not know the =
exact=20
reasons but I presume that 'the<BR> ~> problem' was in the old=20
specification chapter 3 titled the<BR> ~> representation of the=20
Interaction Protocols. I think<BR> ~updating chapter<BR> ~> =
3=20
together with the Modeling TC will do for working to a<BR> ~>=20
specification. I studied the rest of the specification and<BR> ~I =
think=20
it<BR> ~> is still valid.<BR> ~<BR> ~A lot of work is =
done in=20
this moment in Modeling TC to<BR> ~improve Agent UML interaction =
diagram to=20
represent<BR> ~interaction protocols, I agree that we need to =
update=20
this<BR> ~specification as well but my question is when and how.=20
I<BR> ~don't clearly understand what you propose as new in=20
the<BR> ~specification. Could you help me on this =
point?<BR><BR><FONT=20
color=3D#0000ff>Well I don't propose something new, it is more updating. =
Updating=20
Chapter 3 with the alternatives of how to represent Interaction =
Protocols will=20
do.<BR><BR>When? Well if the FIPA FAB has no other things (then those in =
chapter=20
3) I would say as soon as possible because it is 'strange' to have FIPA=20
Interaction Protocol specifications without<BR>any introduction what it =
is,=20
anything that introduces the IP-library or what to do with =
it.<BR><BR>How?=20
Writing a small summary about the alternatives (for representing=20
Ips)<BR></FONT><BR> ~<BR> ~> The question to the Modelling =
TC is if=20
there is a kind of<BR> ~> Glossary/Summary of the Interactions=20
specifications<BR> ~available for the<BR> ~> chapter in =
this=20
specification?<BR> ~<BR> ~Actually, there is no glossary and =
readers=20
_must_ read the<BR> ~specification but since this latter is quite=20
technical, I<BR> ~think we can do something more=20
user-oriented.<BR> ~<BR> ~> The question to everyone on =
this list=20
is: who would like to<BR> ~volunteer<BR> ~> working on this =
specification?<BR> ~<BR> ~Yes sure<BR><BR><FONT =
color=3D#0000ff>Ok thank=20
you<BR></FONT><BR> ~<BR> ~> 2. Ontologies for Interaction=20
Protocols<BR> ~><BR> ~> I think it will be a good idea =
to=20
discuss the following: "We need<BR> ~> associations between =
agent=20
actions and Agent capability ontology<BR> ~> (association =
ontology)."=20
See paper Stephen Cranefield (available at<BR> ~> <A=20
href=3D"http://www.fipa.org/docs/input/f-in-00076/">http://www.fipa.org/d=
ocs/input/f-in-00076/</A>).<BR> ~><BR> ~>=20
For instance in the Contract Net IP I think it would be<BR> ~good =
to=20
have<BR> ~> something for how the messages between the manager=20
and<BR> ~responders are<BR> ~> related. The core idea is =
about a=20
task to be performed and thus an<BR> ~> ontology with an =
association=20
between the action-to-be-performed and<BR> ~> the price that =
responding=20
agents bid would be nice. Of<BR> ~course in the<BR> ~> =
ontology we=20
do not find what the task is because this is for the<BR> ~> =
internal=20
side of an agent but only the concept the<BR> ~responder and=20
the<BR> ~> sender refer to.<BR> ~<BR> ~Maybe it does =
not=20
answer your question but new AUML<BR> ~Interaction diagram =
specification=20
includes the notion of<BR> ~actions related to message sending and=20
receiving but this<BR> ~point is still in its infancy in the=20
proposal<BR><BR><FONT color=3D#0000ff>Sorry I didn't wrote =
this very clear, I=20
think this is not what I meant. Do you mean by the "notion of actions" =
the=20
actions like:</FONT></FONT></P>
<P><FONT color=3D#0000ff size=3D2>Request-info, ask-identify, =
provide-identity=20
etc...? <BR>By the action-to-be-performed I more meant a whole activity =
that has=20
nothing to do with FIPA Communicative Acts. To explain a bit more I use=20
th</FONT><FONT size=3D2><FONT color=3D#0000ff>e following. It is a =
part of an=20
older e-mail conversation between Jim and me:<BR>>> Gabriel: One =
last=20
remark that triggers me about AUML and FIPA IP's: The real<BR>>>=20
calculation of the Borda Count winner is something that is not=20
visible<BR>>> within the Interaction Protocol. This is about the =
same for=20
the Contract<BR>>> net. In the contract net one of the essentials =
for the=20
initiator is the<BR>>> mechanism in which he decides to choose the =
agent=20
to assign the task to. (in<BR>>> which he also checks =
pre-conditions=20
etc..)<BR>>> Is there any kind of diagram to model these kind of=20
mechanisms?<BR>><BR>>Jim: Each of the thin rectangles that go over =
the=20
dashed "lifelines" (which are<BR>>currently called =
"ExecutionOccurrences" in=20
UML 2.0) can be expressed in more<BR>>detail as activity =
diagrams. =20
Would that help?<BR>><BR>>-Jim<BR><BR>In the working draft there =
is=20
something like the Interaction Overview diagram I think that also can be =
useful=20
in detailing some activities in more detail. But if =
ExectutionOccurrences are=20
better I would pay more attention to it in the (working draft of the)=20
specification.<BR></FONT><BR> ~<BR> ~> Thus it would be =
good to=20
have a broader set of different<BR> ~Interaction<BR> ~> =
Protocols.=20
The details for my proposal for the Borda Count Protocol<BR> ~> =
can be=20
found at the links below. This draft specification for =
the<BR> ~> Borda=20
IP has not been updated yet with the work of the<BR> ~Modeling TC=20
but<BR> ~> I would like to hear feedback before I am going to =
give=20
it<BR> ~an update.<BR> ~<BR> ~Will read it once again, =
any=20
deadline?<BR> ~<BR><FONT face=3DVerdana color=3D#0000ff>Thank you, =
well=20
if I have to update it after your feedback before the next FIPA =
meeting, 1=20
July would be great. </FONT></FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>More alternatives to =
other=20
Interaction Protocols are not proposed yet. Although I saw some =
interesting=20
titles of related work that will be presented at Agentcities iD4 =
(papers).=20
</FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>Now my comments =
to the=20
Interaction Diagram working Draft:<BR>First of all, in the MS-word =
version on=20
the AUML website the dates in the Footer are still on the date of =
the older=20
version </FONT></FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>Section 2.1.3 =
Constraints</FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>The parameters in =
the pentagon=20
in the upper-left corner for the instantion of a protocol is a good =
idea. BUT=20
section 2.1.3 Constraints says: the number of parameters must match =
exactly the=20
number of parameters. That is Ok but then I hope that there are =
different=20
possibilities? When I implement the IP I could for instance make a =
choice=20
between protocol 1a (1 parameter) and protocol 1b (2 parameters) when=20
instantiating it.<BR>Example in figure 3 one would instantiate the =
protocol with=20
a date. It should be possible to instantiate without one (or use=20
NULL).</FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>Next sentence: =
What does=20
"prepend" means?</FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>In the previous =
version there=20
was a line (if was the first sentence): "even if it is not mandatory, it =
is=20
preferable that protocol names are different over the set of protocols, =
in order=20
to distinguish them each other"<BR>Jim didn't understand this line and =
is=20
deleted now. But I think I understand the sentence if it is changed=20
to:</FONT></FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2> "even if it is =
not mandatory,=20
it is preferable that protocol names are different over the available =
set of=20
FIPA Interaction Protocols, in order to distinguish them from each=20
other"<BR></FONT><FONT face=3DVerdana color=3D#0000ff size=3D2>I think =
that when=20
people would like to design their own new FIPA Interaction Protocols =
they can=20
come up with their own names and some protocols can be variations of =
existing=20
ones. </FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>Section 2.3 =
Messages</FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>An introduction or =
referring to FIPA=20
ACL Communicative Act would be helpful. </FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>2.3.1. =
Description<BR>Page 9 we have=20
the sentence: The content of the message is given above the arrow. I =
would=20
propose to change that into: Parts of ACL-structure levels like the =
performative=20
is given .. or<BR>The performative of the message and some parameter =
information=20
is given ..</FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>The next sentence: =
There is no=20
formalization to depict message content and depends greatly <U>on the =
agent=20
communication language used</U>. Why ? Don't we all use FIPA =
ACL?</FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>subsection 2.3.5 =
Examples</FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>In this =
subsection we find=20
figures with messages like Request-info: Needs some=20
introduction.</FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>I don't =
completely understand=20
the difference between asynch/synch. messages. If there is no =
control over=20
the messages then it is for instance possible that in figure 14 the =
first=20
message that is send and understand by both agents could be the third =
message:=20
provide-identity? (Or are we only talking about=20
TIME-control?)</FONT><BR></FONT><FONT size=3D2><FONT face=3DVerdana=20
color=3D#0000ff></FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>Section 3: =
Interaction Overview=20
Diagrams </FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>These diagrams =
are really=20
helpful. More with ExecutionOccurences. (see my reply =
above)</FONT></P></FONT>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>Best =
regards,</FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DVerdana color=3D#0000ff>Gabriel=20
Hopmans</FONT></FONT></P>
<P><FONT face=3DVerdana color=3D#0000ff size=3D2>Morpheus Software<BR><A =
href=3D"http://www.mssm.nl">http://www.mssm.nl</A></FONT><FONT =
size=3D2></P></FONT>
<P><FONT size=3D2><FONT face=3DArial=20
color=3D#0000ff></FONT> </P></FONT></BODY></HTML>
------=_NextPart_000_0006_01C3276D.D0513F90--