VOEvent v2.0 is ready for prime time

[Norman Gray]

Greetings, all.

[I've added semantics at ivoa back to the CC list, since this VOEvent-specific thread has now taken over the semantic concerns of the other two-list thread]

Rick's suggestion here...

On 2011 Mar 23, at 17:04, Frederic V. Hessman wrote:

> 	- throw out "name"
> 	- change the name of "type" to something else and leave it in the spec for things like mime types (Norman's "mimetype" is great).  Or simply dump this attribute alltogether.
> 	- add an officially semantic attribute (e.g. with the name "meaning") with the strict content specification "anyURI" with the intent of using controlled vocabularies of some type.

...seems to fit all constraints.  The only change I'd suggest is calling @name something generic like @comment, just in case someone wants to include, say, a reference to a journal article.  That sounds useful, though I may be misunderstanding what folk expect to do with this.

It sounds like we should go with that, and turn it into standardese.  How does the following look?





A <Reference> MAY be included in any element or sub-element of a VOEvent packet to describe an association with external content via a Uniform Resource Identifier [REF].  The element MUST include a 'uri' attribute, the value of which is a dereferenceable URI giving the content of the reference.  The nature of this external content is indicated by the value of a separate, optional, 'meaning' attribute; if present, the value of this MUST be an absolute HTTP URI.

This version of this specification does not constrain the set of allowable URIs in the 'meaning' attribute, nor does it require them to be dereferenceable. 

The 'meaning' attributes indicates the nature of the information that this reference URI will add to the VOEvent packet.  This is at a higher level than the representation format of the resource named in the 'uri' attribute: for example, if the 'uri' attribute resolves to an image, the 'meaning' URI might indicate that this is a finding chart, rather than a quick-look observation.

The <Reference> element MAY also include a 'mimetype' attribute.  If present, it SHOULD indicate the MIME type of the representation which would be returned if the 'uri' attribute's URI were dereferenced, with an absent HTTP 'Accept' header.  A client is free to include any 'Accept' header in an HTTP request for the referenced resource.  Note: This attribute is intended to provide auxiliary information to the client application reading the VOEvent packet, to help it decide whether it should retrieve the referenced resource, and how it expects to process the result.  As is usual with HTTP transactions, the application MUST process the retrieved resource in accordance with the MIME type in the 'content-type' header of the response, irrespective of whether it matches the <Reference> element's 'mimetype' attribute.

A client application SHOULD compare 'meaning' URIs by case-sensitive string comparison (that is, two URIs are equivalent in this context if they are equal byte-for-byte; there is no character encoding issue, since all of the characters in a URI are ASCII).  No URI resolution or normalization should be done.  The DNS name in the URIs SHOULD be lowercase.

A client application MAY (and generally will) ignore any <Reference> elements which have an unrecognized 'meaning' URI.

Although it is not required, the 'meaning' URIs SHOULD be dereferenceable, and be able to return an HTML description of the nature of the information this URI represents.

Note: The authors of this specification expect that an application may reasonably process the contents of the <Reference> based on only the opaque string value of the 'meaning' URI.  Future versions of this specification will probably add further requirements, including requiring that the URIs be dereferenceable or specifying a machine-readable representation.  This specification also refrains from specifying any 'meaning' URIs, and the authors of a VOEvent packet may include any URI they wish.  Obviously, the freedom to be expressive here must be balanced against the requirement to be understood, and the authors of this specification anticipate that best practice will rapidly emerge, and expect to codify it in future versions of this specification.  Several SKOS-based vocabulary efforts are under way within the IVOA, including work in this area by the VOEvent WG.

The <Reference> element MAY include a 'comment' attribute.  The value of this attribute is arbitrary text, which may, for example, be shown to an end-user.

The <Reference> element has empty content.

It is anticipated that VOEvent packets will often include references to such content as finding charts, cut-out images, light-curves, object catalogs, SQL queries and instrumental configurations — to list only a few. This content will be expressed in various graphics and image formats such as FITS, as VOTables [21], as RTML [14] documents, as MIME-typed web content in general, or as native VOEvents.






  * I've specified that 'meaning' URIs are HTTP URIs.  This somewhat interacts with the stuff on long-term URIs (which should be able to indicate, for example, FITS files) which I'm trying to encourage the Data C&P WG to take an interest in <http://www.astro.gla.ac.uk/users/norman/ivoa/long-term-uris.html>.

  * I haven't pushed the idea of the 'meaning' URIs being dereferenceable, or machine-readable.  Neither is necessary for the most basic use of the <Reference> element, though there are obviously more interesting things one might do in future, with machine-readable explanations here.

  * I haven't included any examples in the above.  It'd surely be good to add some.

--------

Matthew was the only one who confidently voted 'No' to 'Ready for RFC?'  Matthew: how do you feel about this now?

Mike asks:

> Let me pose a different reality check:  If we get to RFC and there is still debate about Reference in the comments, how will they be addressed to everyone's satisfaction?

Perhaps we could simply recapitulate the reasoning that led us away from overspecifying here, and towards trusting that a set of good practices will promptly emerge.  As Rick commented, removing the sciencetype vs format distinction does seem a bit weird at first sight.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5341 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20110324/b3a2f2c9/attachment.bin>