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

[Norman Gray]

Folks,

On 2012 Jun 1, at 13:24, Norman Gray wrote:

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

At the risk of being prematurely narrowing this discussion, can I propose some strawman text to replace Sect 3.5 of the VOTable standard <http://www.ivoa.net/Documents/VOTable/20091130/REC-VOTable-1.2.html#ToC22>.  If we can turn this into something reasonable, we can propose it on the VOTable list.  This is intended to take note of the various suggestions so far in this thread, with the exception of Brian's suggestion, which I've responded to separately.

vvvvvvvv

Strawman v1

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

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.

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 the resource <X#f>, where 'X' is the URI of the VOTable, and 'f' is the ID of the first containing element which has an ID attribute (that is, the attribute ancestor::*/@id[1], in XPath terms).  The URI <X#f> will also act as the Retrieval URI for the purposes of calculating a Base URI, in the sense of RFC 3986 Section 5.1.  The URI 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 URI may or might not be dereferenceable; if it is dereferenceable, it provides information about the URI itself, 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.

^^^^^^^^

Version 1a might be the above, modified by Dave Morris's suggestion that the type of the content-role attribute should be xsd:anyURI.  This implies a schema change, but the authors are not aware of any applications which will be affected by this in practice.

The description of the meaning of the 'type' attribute is intentionally vague, so that it can include but isn't limited to SKOS Concepts.  Does it sounds weirdly evasive rather than merely non-committal?

I mention that this specification commits not to define roles starting "x-".  Following Mark's comments on this, this avoids actually constraining values of this, but drops a strong hint about how to name experimental roles.

As usual, I've lapsed into standards-ese.  If this is too much at odds with the style of the rest of the document, we can lighten it up.

All the best,

Norman


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