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

Mon Sep 17 12:27:11 PDT 2012

Hi Seb, Norman and all VOTable contributors,

I would like to bring your attention to an already existing "href" usage 
in order to avoid potential problem concerning the proposal 
usage/definition of "href" and "content-role" attributes of VOTable 
field. I do not want to discourage the idea just to take care of 
potential incompatibilities.

The "href" attribute is already used for several years by data 
providers, notably VizieR, NED, Simbad, LEDA, ESO, IMCCE and some other 
VOTable data providers. These data providers are defining "href" 
(alternatively "gref") and "content-type" attributes for accessing 
ancillary data (documentation, images, fov, ...). In Aladin client, it 
corresponds to the links and buttons in the list of source measurements 
(see below). These data providers use the "content-type" attribute (MIME 
type of data)  and not the "content-role". It is enough for Aladin to 
decide the action that it has to do with the provided href=url.

In the state of the proposal, there is no real incompatibility, notably 
as suggested, it is possible to duplicate the <LINK> element as many as 
necessary for various purposes.
But for Aladin, the main problem will be the generation of wrong links. 
Only the first <LINK> element is presently taken into account, and 
potentially, it will use a SKOS URIs (just a string) and not a real URL. 
In this case, some wrong links will appear in the Aladin measurement 
table (generating errors when the users will click on them).

The process to update Aladin takes always a very long time (for 
instance, NED web site is always using Aladin v4 - 5 years old) - so it 
is quite impossible to change Aladin for supporting rapidly this new 
href proposal.

So, I have to say that I do not see other solution that to discourage 
the usage of "href" for another things that true URLs. In my 
understanding, the "utype" attribute is certainly more relevant for 
describing the SKOS type if we consider that the SKOS concepts can be 
see as a model of metadata.

Sincerely,
Pierre

Le 19/07/2012 19:06, Norman Gray a écrit :
> 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
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.png
Type: image/png
Size: 7194 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/apps/attachments/20120917/d9110bb2/attachment-0001.png>