SKOS concepts in VOTable

[Mark Taylor]

On Thu, 31 May 2012, Norman Gray wrote:

> On 2012 May 28, at 10:54, Mark Taylor wrote:
> 
> >> 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.
> 
> This discussion has gone quiet -- perhaps this represents preliminary consensus.
> 
> Since VOTable 1.3 now appears to be on the cards, would it be useful
> for me to draft specific proposed replacement text for Section 3.5
> (LINK Element) of the VOTable spec?

An alternative approach is to address this in some place other than
the VOTable standard, for instance the relevant Theory or Semantics
or DM standard could prescribe that VOTables used in a particular
context should use the LINK attribute, and in particular its
content-role attribute, in such and such a way.  My personal feeling
is that if that could be made to work it would be a better way of
doing it, since it keeps VOTable as something more like a 
content-neutral container with less semantic baggage, said baggage
being best dealt with in places where its scope and requirements
are better understood.  [I admit though that the existing ucd and
utype attribures don't work this way].

Adjusting Section 3.5 in this way is also starting to fall foul of
the decision we've made not to take the opportunity of the changes
to null handling in VOTable 1.3 to overhaul other parts of the standard.
However, it's a fairly isolated change and if on further consideration
it looks like the best way of tackling this it would probably be OK.

Other opinions welcome.

> I would make basically the proposal in my email of 2012 May 28, unless
> Rick feels this doesn't adequately address his doubts.

On 2012 May 28, Norman wrote:

>    <link content-role='type' href='http://www.ivoa.net/rdf/IAUT93#Quasar' />

Couple of points occur to me:
First, is it not problematic that 'type' does not appear to be a 
SKOS-specific term?  If you were expecting to make SKOS-specific 
usage of the href in question and it was being used to refer to
some (perhaps future) alternative semantic vocabulary with similar
syntax, might it not cause confusion?  I should admit that I am
deeply ignorant about what sort of thing SKOS might be, so I may
be making unnecessary difficulties here.
Second, "type" seems like rather an overloaded term,
but I'm happy to leave that choice of word to semantics people.

> A small extra thing occurred to me.  I would also suggest constraining
> link/@content-role elements to contain only roles described in the
> VOTable spec, with the exception of roles starting "x-", which can be
> prototyped freely.

In general I like that pattern but (a) it ties the semantics of
that attribute to the VOTable standard, which as I say above I'm
not sure is the right place for it, and (b) it's not an idiom
which is used elsewhere in VOTable (if you exclude MIME types)
so I'd be a bit reluctant to introduce it here.  In general I'd
be in favour of suggesting/recommending particular content-role
values in the human-readable part of the spec rather than
enforcing them in the schema.  Again, other opinions welcome.

> I'll also suggest a @content-role value of 'seealso', which can point
> to any other documentation, machine- or human-readable, about the thing
> containing the link element.

Doesn't sound unreasonable, but it overlaps somewhat with the "doc"
value already suggested in the text.

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/