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@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2007-04-30Z14:11:52