> >> 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 effect.
-Mike Received on 2007-04-30Z22:08:07