Annotations [was Re: Apps Messaging -- A New Approach

[John Taylor]

On 30 Apr 2007, at 12:54, Mark Taylor wrote:

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

In that case just substitute ivo://votech.org/votable/loadFromURL for  
process.table.votable and "#" for "@".


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

I think this is the essential difference, and that the annotations  
can be made up dynamically.  Here's an (albeit contrived) example.   
You've loaded a VOTable into Topcat, called "table1".  Topcat  
immediately declares to the world that it supports a new message:

process.table.votable at append_to_table1.

All the other applications on the user's desktop now magically have a  
new option in their menus.  Assuming that they have a table ready  
that they can send to other applications, they will have the option  
"table2->topcat->append to table 1"
No long discussion on this list required.  You don't even need to  
recompile.  Or even restart.


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

I think I see where Mike is coming from now.  To make use of these  
annotations, you need a human in the loop to interpret them.   What  
if my application depends on your app, and absolutely must have the  
function "convert votable to fits" available?   If these annotations  
aren't controlled then how can my application rely on  
process.table.votable at convertToFits?  You could change it tomorrow.
My answer would be that you don't _need_ to use the annotations all  
the time, and it's perfectly sensible to have a specialised  
unannotated mtype that maps onto the same function.  If my app is so  
closely coupled to yours that I can't do without it, then I need to  
speak to you about exposing your API through (potentially private)  
mtypes.  Ideally I'd do it through this forum, and if the function is  
of general interest then the mtype could become part of the IVOA- 
controlled vocab.

John