> - It seems to me that VOThing is unlikely to be embraced as a name.
> Suggestions? Perhaps this facility should exist underneath VOEvent
> itself in some fashion. Other VO projects needing access would then
> simply reference us in return.
Remember: I purposefully used this terrible name to emphasize the need for a VO-wide solution. How about "VOConcept"?
It seems that the UCD community will also have to address the usefuless of the present UCD usage: one requires a separate parser to disentagle what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas parsing something like
<group><ucd>em.X-ray</ucd><ucd>phot.count</ucd><ucd>obs.image</ ucd><group>
would fall out of the normal processing of the XML document with no real additional effort. This is why I've been playing with UCDType and VOThingType in the experimental VOEvent schema (http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ SchemaTableOfContents). This is a good chance to force our VO colleagues to think a bit more about how different VO projects can be made more compatible (at least) and more useful (we hope) in the near future. I'd like to see VOEvent's <What> and <Hypothesis> turn into something like ("concept" <--> "VOConcept" = "VOThing")
<What> <group> <ucd>em.opt</ucd> <concept>process.burst</concept> </group> <group> <ucd>phot.flux</ucd> <ucd>em.opt.R</ucd> <Param value="1.23e-4" error="0.12e-4" units="Watts/m^2"> </group> </What> <Hypothesis> <concept>supernova.Type_Ia</concept> <group> <name>NGC 1234</name> <concept type="associated">galaxies</concept> </group> </Hypothesis>
The whole point of XML, after all, is to do as much as possible in XML, othewise one can stick to old ASCII formats.
> - There appears to be no purpose for the "type" attribute of the
> VOEvent element. This functionality is encapsulated under the
> citations. Comments on section 3.2 would be quite welcome.
I think it's a bit tricky that the ultimate purpose of the document is hidden in the cite attributes in a lower-level element. Yes, we can agree what everything is supposed to mean, but you certainly can't call it elegant. And no, I don't really have a better suggestion.....
> - Timestamp? I vote for subelement of Curation, not attribute of
> VOEvent.
Unless I get some immediate support for my suggestion, I assume we keep the original syntax.
> - There is no error attribute for a VOTable Param, so there should be
> none for VOEvent.
I FIRMLY disagree with this. With VOTable, the syntax is designed to describe rows and columns in a table and errors are often kept in separate entries. VOEvent needs to be able to describe a measurement, and I've always told my students that a measurement without an error and some units isn't a measurement. It's artificially cumbersome to force people to use <Group>s in order to attach an error by adding another element which is identical with the partner element except for the ".error" appendix on the ucd.
> - I think all elements of a packet should be optional. A completely
> empty VOEvent should be acceptable, for instance, for testing. It is
> not our job to try to limit usage only to sensible packets. The first
> thing any subscribing client will do is to perform a reality check on
> the semantics of the message *from the point of view of the needs of
> the client itself*. If a client driving a robotic telescope receives
> a discovery packet with no WhereWhen, it will be a simple matter to
> reject it. It would, on the other hand, be a hellaciously complicated
> job to try to construct a protocol/language in which no nonsense could
> be spoken. (See the Sunday morning talk shows for examples.)
I started to say that a packet without a <Curation> is anonymous, but that's not entirely true: if the packet HAS to have a unique ivo: ID, then there's at least somebody who knows where the message came from. Is this enough? What if your system gets a message with the id "ivo://other/message12345678"? Do you assume that somebody within the IVOA was wise in letting somebody who knows what s/he's doing insert a nearly blank message claiming to have found a optical transient?
> - We are relying on STC and RTML (and other stuff like UCD). How
> should we mandate (or not) what versions of each standard are
> acceptable for a packet conforming to VOEvent vM.n? Should we
> constrain the usage to the latest stable version of each dependency at
> the time of our own releases? Surely the VO must have run into this
> before?
When STC and RTML is inserted in the schema, one is forced to specify a particular version. As the schema is updated, the appended schemata can also be updated.
A performance issue is implicit here: if extremely fast processing times are required, either your system will have to forget about formal schema-based parsing or probably should force the parser to use local copies of the schemata (e.g. updated regularly from the IVOA).
> - I think How should continue to live at the top level (not underneath
> Curation). It should, however, typically only correspond to a pointer
> to an RMTL document or earlier VOEvent packet. (This is the
> equivalent of the familiar "N more" syntax for commanding additional
> exposures under a variety of data acquisition systems.) In many
> cases, How will be omitted entirely.
Hear! Hear! If somethings comes from Raptor or a similarly trustworthy source, for instance, we won't need to have the grimy details in the message. Good practice should dictate, however, that there really should be a useful link (a <Ref type="RTML"/>, for example) which permits one to take a look if needed.
Rick
Dr. Frederic V. Hessman Hessman-at-Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ -------------------------
http://monet.uni-goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2005-05-06Z10:15:20