SKOS concepts in VOTable (strawman proposal text for Sect 3.5)

[Norman Gray]

Hello, all.

I'd like to propose some modified text for Section 3.5 of the VOTable spec.

Meta: I've cc-ed the semantics list for information; I suggest further discussion happens on the VOTable list, unless it gets too semanticky, in which case post it to the semantics list.

----

The following proposal springs from the desire, on the part of the VOTheory WG, to be able to refer to SKOS concepts within VOTables, and their discovery that there was no standards-blessed way to do that.

The text has been discussed in strawman terms on the semantics list, and the version below incorporates various consequent changes and clarifications (though without quite representing a Semantics WG consensus), enough that it seems now appropriate to take this strawman from that list to votable at ivoa.

The proposal develops an idea initially proposed by Sébastien Derriere, that the VOTable LINK element already exists to indicate a link between a part of the VOTable and another resource.  The LINK element already has href and content-role attributes, and this proposal simply suggests (i) blessing the use of a content-role='type' value, which asserts a 'type-like' relationship between this part of the VOTable and the thing named by the href; and (ii) blessing the user of a content-role='doc' value, which creates a link to another document, which can return any or all of HTML, RDF, XML, .doc (!), or others, which give further information about elements within the VOTable.

In the paradigmatic use, with a content-role='type', this href URI would name a SKOS concept, but the text has been phrased in such as way that it is not restricted to SKOS, and can instead be anything, current or future, that has a 'type-like' relationship to (the part of) the VOTable.  The wording is intentionally open.

That's the essential content of the proposal, detailed at (possibly excessively detailed) length below.

This proposal comes in two variants: (i) the content-role is of type NMTOKEN, but relaxing the enumeration currently in the VOTable schema to permit any NMTOKEN (this in principle represents a schema change, but a very minor one, which does not invalidate any existing conformant document); or (ii) changing content-role to be anyURI (this is a more substantial broadening of the content model, but again would not invalidate any existing document, since NMTOKEN is a subset of anyURI).


vvvvvvvv

Strawman v2

VOTable Section 3.5, "LINK element"

The LINK element provides pointers to other documents or data servers on the Internet through a URI. In VOTable, the LINK element may be part of a RESOURCE, TABLE, GROUP, FIELD or PARAM elements. The href attribute of the LINK element must contain a URI; this specification places no restrictions on the URI or what it returns, beyond the syntactical requirement that it be a valid URI.  The gref attribute -- which refers to a linking protocol preferred by the initial versions of the VOTable specification [???GLU ref] -- is permitted but has been deprecated since version 1.1.

NOTE: it is not a requirement that the URI for a 'type' relation can be successfully dereferenced, nor is it a requirement that what is returned when dereferencing a URI is unique (for example it is permissible for an origin server to return representations with different MIME types in response to different Accept headers in an HTTP request).  Even when a URI is being used as a name rather than as a source of bytes, however, it is recommended that the URI be dereferenceable, producing documentation about the name.

NOTE: In the Astrores format, from which VOTable is derived, there are additional semantics for the LINK element: the href attribute is used as a template for creating URL's. This behavior is described for information in Appendix A.1, but does not form part of this current specification.

The LINK element has a name and ID, like many other elements in the VOTable specification.   It may also have a content-role and a content-type attribute.

The content-role attribute indicates the relationship between the element which contains the LINK element, and the resource named by the href attribute.  There is no restriction on the values of the content-role attribute, but the following values are given meanings by this specification:

    * doc: the URI is dereferenceable and provides documentation about elements within the VOTable (the URI of the VOTable will act as the Retrieval URI for the purposes of calculating a Base URI, in the sense of RFC 3986 Section 5.1).  The URI in the @href attribute may provide human- or machine-readable representations or both, depending on the retrieval mechanism (for example a URI might provide text/html content if it is retrieved through an HTTP URI with suitable Accept headers).

    * type: the element containing this LINK element has a 'type-like' relationship to the resource named in the href attribute.  If the href attribute names a SKOS Concept, for example, the containing element represents something which could be labelled by that Concept.  This relationship requires a rather heuristic interpretation, by design; if more precise documentation is required, then this can be provided through a link with content-role='doc'.  The @href URI may or might not be dereferenceable; if it is dereferenceable, it provides information about the thing named by the @href URI itself (for example, a SKOS concept), rather than the LINK element.

Future versions of this specification may attach a meaning to other values of the content-role attribute, but will never define a role which starts with the string "x-".

The content-type attribute provides a MIME type, which may indicate the type of the representation provided by the URI.  Some protocols (for example HTTP) provide a mechanism for indicating the MIME type of the content being transported; in such a case, the MIME type in the response from the origin server overrides any MIME type indicated in the LINK element's content-type attribute.

For example, consider a fragment of VOTable such as the following:

   <table id='foo'>
       <field .... >
           <link content-role='doc' href='http://www.example.org/document-001'/>
           <link content-role='type' href='http://purl.org/dc/elements/1.1/creator'/>
       </field>
   </table>

(In practice, it is unlikely that an element would have two such link elements, and this example is purely for illustrative purposes).

Here, the document <http://www.example.org/document-001> can be expected to provide further information about the elements within the VOTable, and can refer to elements within the document by URIs such as <X#foo>, where <X> is the URI of the VOTable, and 'foo' is the value of an ID attribute within the document.   The remote resource is not required to document any or all elements.

The <field> in this example is indicated to be of type dc:creator (using a term from the Dublin Core <http://dublincore.org/> metadata set); this is not a SKOS concept.  Alternatively, it might be declared to be of type <http://purl.org/astronomy/vocab/InputParameters/InputParameter>; this is one of the SKOS concepts developed by the VOTheory WG.

^^^^^^^^

VARIANT: permit content-role to have type anyURI.  This would permit a VOTable author to write:

    <field ...>
      <link content-role='http://example.org/ObsXMetadata/provenance'
              href='http://example.org/metadata-for-table-1234567' />
    </field>

This means that Observatory X could include private metadata (in this case a provenance statement for this field) in a standards-compliant way, which would be intelligible to anyone who wishes to dereference the content-role URL for an explanation.






All the best,

Norman


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