Frederic V. Hessman
Hessman at Astro.physik.Uni-Goettingen.DE
Thu Mar 17 02:51:43 PDT 2011
> Where your description of utility breaks down is in 5-10 years when
> satellite making the observations is dead and the people on the
> 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
> and some poor grad student trying to write a thesis, or some app
> a current stream and mining old repository events to create Nobel
> 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
> 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
> 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
> of data to make automated decisions and can make use of that data.
> presentation purposes, clearly only *some* information in a packet
> will be
> useful to humans, and some will be needed by machines only. The XML
> standard should accommodate both uses (and others), not simply declare
> itself to be pragmatic and machine-readable when there are examples
> 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).
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......
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the semantics