SKOS concepts in VOTable

[Dave Morris]

Hi all,

This discussion looks very similar to one we had in the early days of VOSpace.

The current suggestions

    <someVOElement ...>
        <link content-role='type' href='http://www.ivoa.net/rdf/IAUT93#Quasar' />
        <link content-role='type' href='http://www.ivoa.net/rdf/UCD#src.redshift' />
        <link content-role='type' href='http://www.ivoa.net/myStandard/my-favourite-utype' />
    </someVOElement>

    <someVOTag ....>
        ...
        <link content-role='semantic'>iau93:Quasar</link>
        <link content-role='semantic'>ucd:src.redshift</link>
    </someVOTag>

Both look fairly similar to the solution we adopted in VOSpace-1.0.

    <node ...>
        <properties>
            <property type='ivo://ivoa.net/semantics/core#iau.rdf'>http://www.ivoa.net/rdf/IAUT93#Quasar</property>
            <property type='ivo://ivoa.net/semantics/core#ucd.rdf'>http://www.ivoa.net/rdf/UCD#src.redshift</property>
            <property type='ivo://ivoa.net/semantics/core#utype'>http://www.ivoa.net/myStandard/my-favourite-utype</property>
        </properties>
    </node>

The key differences is that we avoided using a closed vocabulary for the @type attribute choosing instead to leave it open by defining it as 'anyURI' in the specification.

The reasoning behind this was that if we used a closed vocabulary for the @type attribute, then adding new property types would require a new version of the specification.

On the other hand, if we allowed an open vocabulary then we needed some way of making sure that the names were unique.

By defining the @type attribute as anyURI, and stating in the specification that the URI should point to some form of descriptive resource we made it easy to add new types of properties while at the same time providing a mechanism for ensuring that the names were unique and a standard way of describing the types.

So in the above example, the type='ivo://ivoa.net/semantics/core#ucd.rdf' attribute should resolve to a registry resource that says

   "the value of this property is a URL pointing to a RDF description of a UCD"

For details of how the VOSpace properties are defined see

    http://www.ivoa.net/Documents/VOSpace/20111202/PR-VOSpace-2.0-20111202.html#sec3_2

Adopting this mechanism would require a change to the VOTable specification.

   * We could change the link at content-role to contain anyURI
     (old parsers may reject the new values)

   * We could add a new attribute e.g. link at content-type which would contain anyURI
     (old parsers may reject the new attributes)

   * We could add a new element, similar to, or adopting from, the VOSpace property
     (discussion of the xml schema would probably continue beyond 2019)

If VOTable did adopt a similar URI based mechanism as VOSpace then we would be able to make use of the some of the same properties, property types and registered URIs in both the VOSpace and VOTable standards. Making such a move could be a significant step towards unifying the different mechanisms in use within the VO.

Hope this helps,
Dave


On 06/01/2012 01:24 PM, Norman Gray wrote:
> 
> 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).
>