VOEvent session

[Rob Seaman]

Hi Mike,

There is little in what you say with which I disagree.  Other, perhaps, than the implicit suggestion that these various topics have been neglected.  That said, it is obvious that the various Notes and other documentation you call out for should indeed be a high priority - and perhaps be sections in the 2nd edition of the Hotwired book.

> On Tue, Dec 14, 2010 at 10:00 AM, Rob Seaman <seaman at noao.edu> wrote:
> 
> It isn't obvious why a telegram can't also be a data product.  
> 
> I would argue that it isn't obvious why it *should* be a data product ....

This is basically the same question of terminology that distinguishes the view of "archive" as a scientifically searchable database (meaning "metadatabase") from the more basic view that an archive is the careful accumulation of a permanent cache of the actual science data.

A succinct statement of the VO "vision" might be something like:

	"The Virtual Observatory seeks to reinvent the digital practices of Astronomy."

Similarly, VOEvent seeks to provide a path forward for the publication of "astronomical telegrams" using 21st century digital technologies.  A telegram always has been a coherent document.  One can imagine this turning into a portfolio of nothing but links - but is the astronomical community likely to follow such a path?  Here we would be reinventing not just digital notions in astronomy, but the entire publication model - astro-ph wouldn't deliver PDFs, but a bundle of links.  Not obvious how such would be curated or read offline on an iPad.  Perhaps a laudable goal - but pragmatic?

> My issue is with unnecessary complexity:  Time Series, for instance, might be done in the general simple table (although that doesn't seem preferred), the <simpleTimeSeries> schema, plain STC, or even the Group/Param mechanism in the v1.0 REC.  IVOA is now planning to serialize a TS in a standard way that is yet another means, which uses standard utypes/DMs/schema/etc, so how will that fit into future versions without needing a v3.0 spec to accommodate major changes?

There may eventually be a v3.0 spec - after my term as Chair ends.

The v2.0 working draft is just that - a working draft intended to spark comment.  It looks like it may finally be achieving that goal.

> Note that 'utype' is never used in the v2.0 spec, and 'data model' is used only in describing a <Reference>, I'm not sure where your argument is going with that.

It's interesting to see where the VO "vision" is going.  In 2005, "XML Schema" was the answer to all questions.  Rather, now folks suggest that actually building a Schema as complex as the underlying data is unacceptable.  Instead we are supposed to have a simple Schema - perhaps just a sequence of Params - but with utype attributes that map (not clear if this is either surjective or injective) onto some ideal data model.  The complexity is now all in the utypes, and validating against the Schema doesn't actually tell you anything about the contents of the file.

Whatever the technological realization, a VOEvent packet is a document representing a report of a celestial transient event.  There must be trade-offs.  We are discussing these for the next generation of the standard.  I am deeply skeptical that the appropriate trade-off is simply to point to a bunch of external content.  A typical packet will contain astronomical information, not just computer science metadata.  This was just about the first issue debated in the working group.  Does "event" mean a computer sciencey event, or an event in the sky?
> 
> Likewise, if the idea is a packet will contain science info then what is the plan for including spectra or images (or ....) that might be desired by some use case?  Is this then the planned use for simple tables, or is there future schema to be supported by parsers?

Roy has pointed to one vision for "advanced" content.  Perhaps there are others.  Another early talking point was the idea of data-rich packets.  I floated this trial balloon at least as early as Hotwired I - with little response at the time.  A later notion was portfolios (basically data entrained with the packets) - this has been prototyped through VOEventNet and SkyAlert.  It appears to have "legs", but a full realization will require registry improvements for VOEventStreams (first discussed in Trieste, I think).  It remains very clear, however, that many projects will prefer a basic packet structure including whatever simple astronomical data they absolutely require.  Where the dividing line is, is a key issue for v2.0.

> I don't necessarily object to including data in a packet, but I do think there is a problem when a voevent describes that data in some way different than other serializations of IVOA data of the same type without good reason, and when it isn't a simplification but perhaps something incompatible entirely.  I also don't see where this possible divergence will end, and thus how much more work might be required by developers.

Any divergence or incompatibility would have to be passed by the TCG and IVOA Exec.  Another key goal of v2.0 is an improved Schema to improve the conformance of the many projects now pursuing VOEvent compliance.

Rob