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 Received on 2007-04-30Z15:54:33