SKOS concepts in VOTable (example problems?)

[Norman Gray]

Dave and all, hello.

On 2012 Jun 1, at 19:10, Dave Morris wrote:

> Changing LINK/@content-role from NMTOKEN to anyURI allows us to use the
> same URIs in both VOTable and VOSpace.

I like this idea, partly because it's tidy, and partly because it harmonises the fairly extensive linked-data work of VOSpace with the very tentative linked-data experiment represented by this (still only potential) VOTable proposal.  The problem is that it _does_ represent a schema change, and that's an argument that has yet to be really made.

Such a change would probably have minimal effect -- possibly no practical effect at all -- but this not actually zero, so as you note, Dave, the question is whether the gain is worth any side-effects.

One rather abstract payoff is flexibility; but flexibility to do what?

The motivation for the present thread is that the Theory folk want to refer to SKOS Concepts within a distributed VOTable.  This is to provide a form of 'type' relationship which goes beyond the specific cases of @ucd and @utype.

One can imagine other annotations such as the writer (human or machine) of a VOTable, the date, and so on.

Does anyone (Dave, Theory IG people, or others) have particular concrete use-cases or user-stories which might motivate a design here?  We know we've got them, but it'd be good to assemble a manifest list of real-world examples?  Hmm: I smell a wiki....

(It would appear that a <PARAM> element would support annotations for TABLE elements and some others.  However: (i) there's no standardisation of the PARAM/@name fields, and (ii) this mixes up data and annotation/metadata.)

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK