Annotations [was Re: Apps Messaging -- A New Approach
fitz at tucana.tuc.noao.edu
Mon Apr 30 13:07:45 PDT 2007
> >> 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.
I'm not sure 'magical' is quite the right word, this is very much
a designed interaction in a task that 1) knows TOPCAT can/may issue an
'append_to_table1' annotation and 2) that receiving that annotation means
the app should restructure its menus accordingly. Magic is when I can
send the uncontrolled 'apTab1' annotation from my task and get the same
More information about the apps