VOEvent References

[Frederic V. Hessman]

> Where your description of utility breaks down is in 5-10 years when  
> the
> satellite making the observations is dead and the people on the  
> project
> have moved on to derivatives trading in the new world economy.  All we
> have at that point is the XML event packet itself sitting in a  
> repository
> and some poor grad student trying to write a thesis, or some app  
> processing
> a current stream and mining old repository events to create Nobel  
> science.
> If we have to rely on what the humans who created the packet *meant  
> to say*
> we may be well screwed.  In the absence of the original Mayan High  
> Priest,
> how do we know the original voevent carvings they left really mean  
> we're all
> dead next year?
>
> Packets have two clear audiences:  humans like the Keck telescope  
> scientist
> that might appreciate seeing a PNG of a possible GRB on their cell  
> phone to
> decide whether to slew the telescope, and software that needs other  
> forms
> of data to make automated decisions and can make use of that data.   
> For
> presentation purposes, clearly only *some* information in a packet  
> will be
> useful to humans, and some will be needed by machines only. The XML  
> doc
> standard should accommodate both uses (and others), not simply declare
> itself to be pragmatic and machine-readable when there are examples  
> that
> still require humans for events to be usable.

My original point was that one of Roy's goals is already here (or  
almost here), because hard-wiring of content is not necessary  
(although hard-wiring of use may be).

My example said that the link was to a light curve and that the  
content was an HTML link to that data.  If one would have wanted to  
specify that the link was to the data itself, then something like

	<Reference type="ivoat:lightCurve" ucd="meta.code.xml.votable" uri="http://nesssi.cacr.caltech.edu/catalina/20110314/1103141070764142069p.xml 
" />

would be good (note: I don't think that "meta.code.xml.votable"  
exits...).  Even better would be the possibility to concatenate types,  
but the use of attributes kills that.   Anticipating VOSpace (about  
which I know practically nothing), how about something like

	<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.
	- "type" gives the VO "mime" content description in a (soon to be?)  
standard VO format.
	- "ucd" is an addition for backwards compatibility while UCD makes  
the transition from an ASCII vocabulary to an RDF one.
	- "uri" says where to find the final conten

The use of a separate semantic attribute saves Roy from having to  
parse daughter tags for enumerated types/contents (the more elegant  
solution) and pushes people to keep the various contents clearly  
separated.   We have UCD's, vocabularies, mime-types, data-models,  
etc. all jumbled up right now.

Sorry to make these suggestions so late in the process, but the  
chances are fairly trivial.  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......

Rick


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20110317/1fc9541b/attachment.html>