[Modeling] Re: [IP] Fipa Interaction Protocol Library Spec

[Marc-Philippe Huget]

Hello Gabriel and all,

"G Hopmans [Morpheus]" wrote:

> 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)

A small summary gee! By alternatives, you mean every (in)formal
description techniques to represent IPs, that is not a small summary, we
have at least ten different FDT for this purpose even if some are quite
confidential


>  ~> 2. Ontologies for Interaction Protocols
>
>  ~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...?
> 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.

That's exactly what we propose with actions in interaction diagrams, the
ability to anchor some actions based on receiving messages, see the
specification, if an agent receives an inform message, the associated
action is: update belief with this new information.

> 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

Argh, I think you read the previous 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).

But if you have two protocols as proposed by you, we have no problems,
if we just have one protocol with a template, that's right the situation
is different, well, I will think if it is really a problem and if I need
to change the sentence

> Next sentence: What does "prepend" means?

Argh, my english! prepend=prefix

> 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.

I don't understand your point, if I remember my FIPA lessons, it is said
that adopting the FIPA names means that we adopt the semantics attached
to it, as a consequence if designers want to modify even a little bit a
FIPA protocol, they have to change the name, thus we don't have name
problems.

> Section 2.3 Messages
> 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?

Even if this is a standardization for FIPA, I don't think it is a good
idea to lock the description with a specific content format, if you want
I can use SL0

> 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?)

Synchronous communication in MAS is not really used, I am not even able
to give an example but for sake of generality, we need to address this
specific kind of communication, synchronous communication when not
addressed by function calls is performed through handshake protocol, the
recipient resumes the sender as soon as it sends an ACK to the sender.
About message ordering, messages are ordered through a time axis, as a
consequence it is not possible to send the third message prior the first
two messages except if conditions attached to these two messages are not
satisfied.

Hope it helps even it is not easy to speak about an "old" version of the
document.

Cheers,
Marc-Philippe



--
Marc-Philippe Huget

Agent Applications, Research and Technology Group
Department of Computer Science
University of Liverpool
Chadwick Building, Peach Street
L69 7ZF Liverpool
United Kingdom

email: mph@csc.liv.ac.uk
http://www.csc.liv.ac.uk/~mph