TWiki> IVOA Web>IvoaVOEvent>VOEventRFC (revision 10)EditAttach

VOEvent Proposed Recommendation: Request for Comments

This document will act as RFC center for the VOEvent V1.1 Proposed Recommendation.
Specification at http://www.ivoa.net/Documents/PR/VOE/VOEvent-20060629.html
XML Schema at http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the VOEvent mailing list, voevent@ivoa.net.

Comments from the Community

  • (1) This first comment is a sample comment

-- RoyWilliams - 2006-07-11


  • (2) I have a comment about the content of the Description element. I agree that it will sometimes be desirable to use plain text and sometimes to use HTML, but for software which encounters the content the current proposal presents the problem of how to present it - does it assume it's HTML and attempt to format it thus (which will look wrong if it's plain) or assume it's plain text and display it raw (which will look wrong if it's HTML) or attempt to guess by looking which it is (which is hard and error-prone). Can I suggest an additional attribute format on Description which may take (at least) the values plain (the default) and html. I'd suggest that it is not limited to these values so that specialised applications can use other formatting methods if they wish to in the future (on the understanding that not all software may know what to do with exotic formatting methods).

-- MarkTaylor - 12 Jul 2006

  • Thank you Mark, good call. We suggest that "Description" have a "format" attribute, and that a parser be considered compliant if it recognizes two values: text/plain and text/html, the default being text/plain.

-- RoyWilliams - 2006-07-12


  • (3) I have a comment about Param tag. Did you ever try to write XML parser? Do you know how big pain is it when you have attributes and you need to search for value of particular one?

You are making in my point-of-view classical XML-designers mistake. XML was designed to transport well organized data, so they can be machine readable. Param fields with UCDs are not well organized - because you cannot validate document for UCD validity, and you cannot reasonably parse it and store in target language (you can save it to collection holding parameters and then search in parameters..think how much overhead you will create by such decision, and how many tests will you need to perform - and XML was created to remove from you burden of such tests, and you just put them the different way inside).

To solve that, I recomend putting UCDs in tags. So instead of the example:

<Param name="TRIGGER_NUM" value="114299" ucd="meta.id" />
<Param name="RATE_SIGNIF" value="20.49"  ucd="stat.snr" />
<Param name="GRB_INTEN  " value="73288"  ucd="phot.count" />

Let's have something like:

<GRB>
  <trigger_num>114299</trigger_num>
  <rate_signif>20.49</rate_signif>
  <grb_inten>73288</grb_intent>
</GRB>

etc. for other events (transits,..).

In schema that will maternize as choice for different event types.

By letting free UCDs parameters you actually say: we don't care about researching which ever possible events can be transported by VOEvent, so we left submiters freedom to create mess of different parameters, so as results no machine will be able to use VOEvent entry and it will be again human, who have to read it and understood what was author intention. Mayby that's right for scientics, but for computer programmer it's a nightmare. And for robotic telescope operation it is nearly useless.

You really need to define possible content, most probably starting from what we know and use currently (e.g. GCN format is well established) and going to more difficult areas, where GCN example is not available.

-- PetrKubanek - 2006-08-07

While your suggestion certainly has advantages, the best choice is not obvious.

The difference here is between what I call a generic container and a semantic container. The latter is helpful when the scope of meaning is well contained. As you allude, a generic container is necessary when you can't constrain the semantics at the time the schema is defined, perhaps because it may change either depending on the application or just over time. In my experience, sometimes the advantage of Schema-based validation works against you in the face of this change.

If we are to have interoperable semantics that allow machines to interpret these terms, then the terms must be well documented and standardized--whether they are part of the XML Schema or not.

(BTW, just to avoid confusion, UCD refers to the values of the ucd attribute.)

-- RayPlante - 2006-08-07

The difference here is between what I call a generic container and a semantic container. The latter is helpful when the scope of meaning is well contained.

The later is useful if you know the contents the message will carry, the "Param" element was designed the way it was precisely because we have absolutely no idea the semantic content that the message will have to carry. If you look at, for instance, OGLE and GCN messages, the "Param" elements carry totally different things. That's why it has a ucd="" attribute to provide the semantic meaning that you seem to want.

-- AlasdairAllan - 2006-08-07

This is not a mistake, but on the contrary, there was a great deal of thought (and argument) went into it. This is a compromise between structure (special elements) and flexibility (generic Param elements).

The structured approach is certainly easier for the computers to validate, and makes nicer code when the code-binding tools are used. But the problem here is that we don't know in advance what kind of measurements will be made. Perhaps one group measures something called "trigger_num", other VOEvent providers have other names for parameters. It would be very difficult for those providers to use a structured approach. There would be "extra" schemas for each dialect of VOEvent, the authors would need to build and document such a sub-schema, put the schema into a permanent web-accessible repository, and be careful with versioning every time it changes. The subscriber to such events would also have trouble bringing in the correct schema and validating it.

And there's the rub: the more effort we demand from authors, the less likely they are to become part of VOEvent.

By letting free UCDs parameters you actually say: we don't care about researching which ever possible events can be transported by VOEvent,

No. We have said that in one part of the VOEvent there will be data whose structure we cannot know in advance, and that the structure there will change faster than our versioning process.

Perhaps you could help us in a constructive way by defining what kind of parameters the INTEGRAL instruments will be producing when they report an event. We would be happy to help you to add structure in the form of Group elements and UCDs.

When evaluating a VOEvent for possible follow-up, we see different approaches by different groups. Some may look at the name of the author organization and the "importance" score of the event, and know the meaning of that scale of importance. Others may look at the "Why" section where the author has a hypothesis ("80% chance it is a supernova"). Others may know the meanings of the Group names and Param names in the "What" section and be able to decide based on these values.

-- RoyWilliams - 2006-08-07

You are making in my point-of-view classical XML-designers mistake.

I disagree - we are making avant garde XML choices, not classical XML mistakes. An explicit architectural trade-off was made between supporting general purpose params versus elements custom tailored for each alert type. VOEvent happens to be realized using XML, but it isn't an XML technology per se. Just as XML itself has a broader range of applicability than just as a delivery mechanism for the zen of schema.

In an ideal world, your suggestion is superior. We have known this from the beginning. Note that nothing about VOEvent should be taken as forbidding such usage in a future version, say v2.0. We would need to be clear on the VOEvent ground rules (not just the XML rules) for including additional alert-specific schema. The success or failure of these hand-tailored schema would be driven by market pressures, just like VOEvent itself.

The current state of the VOEvent community is different. We are attempting to bootstrap VOEvent from today's complex world of many non-interoperable, non-XML, astronomical alert systems. The choices made under such circumstances may be quite distinct from some idealized vision. We should all be gratified at the success that VOEvent has demonstrated to date. Success speaks for itself.

Mayby that's right for scientics, but for computer programmer it's a nightmare. And for robotic telescope operation it is nearly useless.

Well, actually, it is the robotic telescope community who have adopted VOEvent most enthusiastically. VOEvent compliant code is already driving nightly robotic operations.

It has certainly been entertaining to watch the recurring debates between the astronomy side and the computer science side of the Virtual Observatory efforts. I've yet to see a single issue where one side is entirely right or entirely wrong. The more genuine disagreements tend to come between the scientific programmers and the computer science programmers - the folks who need to make it work. Whatever else is true of all of the many fascinating VO projects - at the end of the day, a pragmatic real world solution must exist and must be proven to be sustainably operable.

You really need to define possible content, most probably starting from what we know and use currently (e.g. GCN format is well established) and going to more difficult areas, where GCN example is not available.

VOEvent is the same type of effort as GCN was originally. GCN-2 will be VOEvent compliant. We are precisely in the business of defining formats, just as GCN has been before us. To require a full formal data-modeling effort in advance of permitting new alert types to be issued, would be to cut the legs out from under the entire concept of issuing alerts for transient astronomical phenomena.

It is precisely the poorly characterized phenomena whose alerts are the most valuable. We could do a wonderful job of crafting a fully specified, semantically rich, content-complete alert for eclipsing binary stars. Few would bother to either author or subscribe to such alerts.

-- RobSeaman - 2006-08-07

Note: this thread of comments continues in a philosophical vein for several more messages, see the mail archive for full details.


Comments from the IVOA Chairs

  • Applications Interest Group (Chair: Mark Allen)

  • Astronomical Grid Community Research Group (Chair: Nic Walton)

  • Data Access Layer Working Group (Chair: Doug Tody)

  • Data Curation and Preservation Interest Group (Chairs: Francoise Genova and Reagan Moore)

  • Data Models Working Group (Chair: Jonathan McDowell)

  • Event Working Group (Chair: Roy Williams)

  • Grid and Web Services Working Group (Chair: Guy Rixon)

  • Query Language Working Group (Chair: Pedro Osuna)

  • Registry Working Group: (Chair: Tony Linde)

  • Semantics Working Group: (Chair: Andrea Preite-Martinez)

  • Standards and Processes Working Group: (Chair: Bob Hanisch)

  • Table Working Group (Chair: Francois Ochsenbein)

  • Theory Interest Group: (Chair: Gerard Lemson)


Edit | Attach | Watch | Print version | History: r16 | r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r10 - 2006-10-09 - RoyWilliams
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback