Apps Messaging -- A New Approach

[Mark Taylor]

On Fri, 27 Apr 2007, Mike Fitzpatrick wrote:

>>> Message Annotation
>>>
>> Consider an mtype used to request that an  application "loads" a table:
>>
>> process.table.votable with parameters (id="nobel prize", url="http://
>> foo.com/adf")
>>
>> We (this group) define this mtype and the argument list that goes
>> with it.  An applications that supports (ie, can receive) this
>> message is free to annotate it with non-standardized annotations, for
>> example,
>>
>> process.table.votable at load
>> process.table.votable at convert
>>
>> On or after registration, the application would declare that it
>> supports:
>>
>> 1) process.table.votable
>> 2) process.table.votable at load
>> 3) process.table.votable at convert
>
> 	I'm still not sold, angering the registry zealots by using ivorns
> might have made for a more compelling example though.  Persumably we
> would need a small, controlled vocabulary for these annotations to be
> meaningful to machines, and apps would be free to make up their own.

No, the vocabulary for annotations is completely uncontrolled,
applications always make up their own.  For a controlled vocabulary
you'd stick to the message type (opaque URI in PLASTIC, perhaps mtype in
future).

> So, how is annotation any better than simply using mtype classes such as
>
> 	1) process.votable
> 	2) load.votable
> 	3) convert.votable
>
> You can still send the data to any app responding to a *.votable message,
> use the generic 'process.votable' to get the default action or one of the
> others to get a specific action.  An annotation such as
> 'process.table.votable at flibbity' is essentially a private message since
> I would have to know what the 'flibbity' did to use it, same as I would
> for a 'flibbity.votable' mtype class.
> 	If the annotation is strictly for human readable GUI menus I'd
> prefer to see it as a 'getDescription' type of message.

Yes, the distinction between messages with the same mtype and different
annotations is intended to be intelligible by humans and not machines.
Some kind of getDescription message could work, though would have to
be capable of returning either 0, 1 or more annotations for a given
mtype (so the specification might be a bit messy).  The form of these
annotations was cooked up to be backwardly compatible with existing
PLASTIC messaging; I happen to think it looks reasonably elegant,
but other ways of providing human-directed annotations are possible.

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/