VOEvent References

[Frederic V. Hessman]

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

As alwas, VOEvent is leading the way in trying to incorporate semantic  
content, so why not?

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

This is reasonable: the "type" attribute is being used by different  
groups for different things (e.g. data models in non-standardized  
formats like UCD,....).

>> 	- "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?

Isn't the problem with MIME that it covers things like URI, HTML, JPEG  
but not other astronomical stuff (e.g. FITS).  Is there a SKOS  
vocabulary of MIME tags?  If so, then the standard stuff is easily  
covered (once everyone knows about it).

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

The problem with this is that we have different identifications for  
different types of content - people like Roy won't like you saying  
that there are 3 different and potentially conflicting ways of finding  
out what's at the end of the link.

My idea was to have as few tags as possible and force them to have  
controlled content (even if one chooses to ignore the possibility of  
checking).  All we need is
	- format (or "contentformat") : what bytes are at the end of the link
	- meaning (or "content") : what do the bytes really mean  
astronomically?

I'd say the "name" attribute suggestion should be deleted, exactly  
because one is tempted to put human-readable information in a computer- 
unintelligible place instead of doing one's homework and simply  
putting it in the few content-controlled places were it should be.    
The text content of the tag (e.g. "<Reference...>to somthing or  
another</Reference>)
can be kept for this purpose, since we all know it will be utterly  
ignored, but is good for things like sarcastic comments as above.

If the format can be named via MIME-ish means, then all we need is the  
semantic meaning.  The solution of coming up with IVOA-specific MIME- 
ish things via VOSpace labels sounds like a more flexible way of doing  
this (but, again, I admit knowing practically nothing about VOSpace).

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

You're right - in the interest of simplicity, lets cut things down to  
just 2 attributes, please!

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

Here, here!  If MIME can do it, all the better.

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

(champagne cork!)

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

(back-patting)

Rick