SKOS concepts in VOTable

[Mark Taylor]

On Fri, 25 May 2012, Sebastien Derriere wrote:

>   Hi all,
> 
>   The need to express SKOS concepts emerged during this interop,
> for example to indicate what SKOS concept corresponds to a column
> contents for the Theory WG.
>   There is no dedicated VOTable element or attribute to do this,
> and so several ideas have been suggested. I try to list these below,
> in order to see what people are thinking would be the best way to go.
> The question of the VOTable representation is only one aspect of the
> problem, because there are issues like being able to query on SKOS
> concepts in TAP for example...
>   Several concepts coming from different SKOS vocabularies could in
> principle be associated to a single VOTable column.

I'm with Norman on this.

> Solution 1 :
> Use the "ucd" attribute. The UCD gives a semantic information on what
> a quantity is. With SKOS vocabularies, we have more flexibility, so the
> UCD attribute could be broadened to other vocabularies.
> PROs : use an existing attribute
> CONs : the regexp for ucd attribute in VOTable does not allow the '/'
> character, so it cannot contain URIs. It could break some apps expecting
> to find words from the UCD vocabulary if some alternate vocabularies are
> allowed in the same attribute. Is is not possible to describe several
> SKOS concepts, because there is only one attribute.

Valid syntax aside, using the existing ucd attribute clearly counts
as abuse of it, since it is intended to hold a UCD, that is something
defined by the UCD1 or UCD1+ standards (or possibly successors to these).
Using the ucd attribute for a SKOS concept would also preclude tagging
a column with an actual UCD.

> Solution 2 :
> Create another attribute (or element) dedicated to SKOS vocabularies.
> PROs : clean way to do things. Well defined scope, no ambiguities.
> CONs : makes metadata generation more complicated or confusing for data
> providers (generate ucds, utypes, skos, ...). If it is an attribute,
> not possible to describe several SKOS concepts. Requires schema change in
> VOTable 1.3 to allow this solution.

Although this is quite clean, I don't like the idea of adding a new
attribute to FIELD every time somebody comes up with a new item of
per-column metadata; VOTable will keep getting more complicated.
If it was absolutely necessary to do something like this, I would
favour some extensible mechanism (value='...' role='skos' or similar).

> Solution 3 :
> Use <LINK> subelements for <FIELD>.
> PROs : already allowed in VOTable 1.2. URIs can be expressed in href="".
> Possible to use content-type and content-role attributes to give additional
> context. Possible to have multiple <LINK> for one <FIELD>.
> CONs : not sure how parsers would handle this or how this can be used
> in TAP...

Since LINK is already present, and seems to be syntactically and
semantically capable of doing what's required here, it looks to me
like the best option.

> Other solutions ?
> Like custom use of PARAM / GROUP.

PARAM/GROUP is probably doable, but can get a bit fiddly.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/