SKOS concepts in VOTable

[Norman Gray]

Mark and all, hello.

On 2012 May 31, at 23:15, Mark Taylor wrote:

> 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.

Two thoughts on that:

1. One strand of this discussion is specific to VOTable in the sense that it's about a detail of VOTable syntax, the <LINK> element; though one can imagine reusing the pattern in other syntactical contexts (for example suggesting a 'type' column in TAP metadata).  Perhaps this strand is near-complete, inasmuch as the discussion quoted above suggests that IF this pattern is a good one, then LINK/@content-role is how it should be instantiated in VOTable.

2. The other strand is whether this is a good pattern, and I'd much rather that was discussed _outside_ the semantics group.  Thus, if this present discussion starts to converge on a preliminary case, I'd like to move it to the votable list pretty promptly.

That's because...

>  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].

...the votable list is probably where the scope and requirements are best understood.  If the discussion remains on the semantics list too long it'll be ghettoised.

>>   <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?

Applications need only process types they recognise, in the same way they now might process only UCDs and ignore utypes.  There's a more wordy version of this explanation at the bottom.

> 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.

There's less than meets the eye.

Something like http://www.ivoa.net/rdf/Vocabularies/IAUT93#Quasars is a name, no more.  Saying "this is a SKOS Concept" says "this is like a Library of Congress subject heading, and we suggest you use it accordingly".  Once you find out more about this name, you discover that there are related names and labels.

I don't imagine that's a name you would expect to find much in a VOTable, but one could imagine finding <http://purl.org/astronomy/vocab/InputParameters/GasPressure> in a VOTable.  I don't think Topcat would have much it could usefully do with that, but another application might be able to use this to provide units, say, or other consistency checks.  Or the units might be retrieved from the URL.

I'm suggesting overloading the term 'type' because (a) I don't think the overloading is problematic, and (b) because it would be good for this to be future-proof, and not confined to SKOS.  Neither, by the way, is this confined to RDF: there's nothing in the proposal says that RDF should be returned from the URI, nor even that _anything_ should be returned, though obviously both would be reasonable behaviours.  Perhaps dereferencing a URI could return an XML Registry entry?

The suggestion is intended to be flexible enough that one could put a (URL form of a) UCD or a utype in the link/@content-role='type' element and it makes sense.  I'm not proposing that (there are compatibility issues!), but I believe the system should be flexible enough to handle that.

>> 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.

That's reasonable.

>> 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.

That's a sotto-voce/secondary suggestion, really.  It's a sort of principled back-door (better: a 'loading bay') for anything else one may wish to say about the VOTable, absent the 'is-a' implication of the 'type' relationship.  I could elaborate, but this message is too long already.

Is the 'doc' value actually used by anyone?

Come to think of it, the 'doc' relation could be overloaded as well, and forget about 'seealso'.  Given <link content-role='doc' href='http://example.org/foo/mytable'/>, one could dereference http://example.org/foo/mytable in a browser and get HTML, or dereference the same URL using curl and retrieve any RDF (or whatever) that the table creator has provided.

All the best,

Norman


----

A longer version of the remark that "Applications need only process types they recognise", which I cut out of the main body of the email.

Suppose (and this is NOT a proposal!) that VOTable decided to replace the @ucd and @utype attributes by a single @uthing attribute, which could somehow appear multiple times (like I said, not a proposal).  Then you might have

    <FIELD name="RA" ID="col1"
      uthing="pos.eq.ra;meta.main"
      uthing="stc:AstroCoords.Position2D.Value2.C1"
      .../>

At present, applications will (I'm sure) process @ucd and @utype attributes with something like

    if attribute_exists('ucd'):
        if recognised_ucd(attribute_value('ucd')):
            process_ucd(attribute_value('ucd'))
    else if attribute_exists('utype'):
        if recognised__utype(attribute_value('utype')
            process_utype(attribute_value('utype'))
    fi

That is, they presumably switch on the presence of the @ucd or @utype attribute, preferring one or the other.  With the fantasy @uthing attribute, this would look like

    for uthing_string in attribute_values('uthing'):
        # or use this loop to find a preference between utypes and ucds
        uthing = lookup_ucd_or_utype(uthing_string)
        if uthing.is_utype():
            process_utype(uthing.get_string())
        else:
            process_ucd(uthing.get_string())
        fi

The application 'knows' what UCDs and utypes it can process, and knows that, say, 'pos.eq.ra;meta.main' is a UCD and not a utype.  As long as there are no UCDs which are string-identical with utypes, there's no problem.

The situation is exactly analogous to the (actual) proposal of a @content-role='type' link.  An application might be able to process only a subset of the possible types, but it can recognise those types it can process, and can ignore the others (analogous to an application which can recognise UCDs but not utypes).

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