VOEvent References

[Norman Gray]

Greetings, all.

Sorry to come at this a bit late.

Below, I'm mostly agreeing with Rick, but adding a couple of qualifications.  I've worked through the other messages in this thread, but this seems the most natural place to hop on this particular bus.

By the way, should we be talking about this on both the Semantics and VOEvent lists?  I'd suggest limiting it to just the VOEvent list.

On 2011 Mar 17, at 09:51, Frederic V. Hessman wrote:

> 	<Reference content="ivoat:lightCurve" type="vos:votable" uri="http://nesssi.cacr.caltech.edu/catalina/20110314/1103141070764142069p.xml">
> 		Light curve for the alert, in the form of a standard VOTable, the only reasonable way to transport light curves or any other stuff within the VO (even if it is ugly).
> 	</Reference>
> 
> where the vos namespace reference is  to vo://net.ivoa/vospace/core#votable.  Note that I have put the semantic reference in a special "content" attribute (couldn't think of a better name), since the function of "type" seems switched: the "type" attribute is most often used as something mime-ish or data-model-ish.
> 
> This puts all of the required info into clearly delinated segements, making life for people like Roy much easier:
> 	- "content" gives the semantic content/context in an easily human- (directly readable) and machine-processable (i.e. a permanent link to a machine-readable vocabulary) form.

Yes, _somewhere_ the element has to say what it is that's at the end of that URL.  It doesn't say anything syntactical -- whether it's a PNG or a VOTable -- but it is something that represents a light-curve in the non-virtual world.

Detail: Now, the syntax that Rick has chosen is namespaceprefix:name, which 'expands' into a URI which names a SKOS vocabulary element.  Excellent -- standardised (as a 'CURIE"), decoupled, deployed, library-supported -- all good things.

There's a wrinkle in that "string:string" parses like a URI, so there may be some fuss there; however the CURIE spec describes how to get round that ('safe_curie').

I'm sure someone's going to mention that they don't want 'ivoat' to have to be declared before this, but instead to be taken as read.  That was the conclusion of an earlier discusson about vocabulary names and utypes.  I think that was a poor resolution, but hell, it's only storing up problems for developers in the future, so we needn't bring it up again now.

Suggestion: I think this attribute should be named 'contenttype', and its content should be "URI | safe_curie | curie" (see <http://www.w3.org/TR/curie/>).  That is, either a URI, or prefix:string optionally with [...] round it.

> 	- "type" gives the VO "mime" content description in a (soon to be?) standard VO format.

If it's a MIME type, then why not call it a MIME type?

And I can't see any reason why it shouldn't be a MIME type.  The only complication is that it's a bit redundant.  When you dereference the URI in the @uri attribute, you'll get what you're given.

What happens when what you get (ie the MIME type included in that response) doesn't match what the @type attribite promised?

What happens when the URI can return a variety of formats, such as a PNG or a VOTable, depending on what you Accept when you request it?

Suggestion: the content of this should be a MIME type, and its meaning should be that it indicates the default/expected/nominal content of dereferencing the URI with an Accept:*/* header.  That is, dereferencing the @uri rfc2119-SHOULD return something with the MIME type given in @type, but the application shouldn't depend on it.

> 	- "ucd" is an addition for backwards compatibility while UCD makes the transition from an ASCII vocabulary to an RDF one.

Perhaps.  We don't really need UCDs at this point, presuming we have a set of standardised things to go in the @content or @contenttype attribute (which incidentally includes UCDs).

> 	- "uri" says where to find the final conten

Yes.

We might note here that content can be made available in a variety of formats.  When the URI is dereferenced, you can accept:image/png to retrieve a PNG or 404, or accept:application/x-votable+xml (ugh!) to retrieve a VOTable or 404, or accept:image/*,application/x-votable+xml to retrieve whatever's going.

> We have UCD's, vocabularies, mime-types, data-models, etc. all jumbled up right now.

Yes -- these various things are bandied around, and we only need two of them in this spec: vocabularies and MIME-types.

The vocabulary term in the @contenttype attribute tells you what sort of information is at the end of the @uri, but gives no clues about what format it's in.  The MIME type in the @type attribute, and more authoritatively the content-type in the retrieval of the URI, tells you what syntactic format the URI-content has, but gives no clues about what it means.

They're orthogonal and complete.  Job done.

> I'm afraid, however, that this kind of problem is omnipresent in various VO working groups, which begs for a standard solution.   On the other hand, VOEvent was always leading in efforts along this line, so......


So VOEvent could be an examplar here, to the rest of the IVOA.  Cover VOEvent in glory, again!

All the best,

Norman


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