VOEvent session

[Mike Fitzpatrick]

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 ....



> In addition to near real time notification, the goal is to provide a path
> for the historical human language telegrams to transition to parse-able
> schema/utypes/ontologies/DMs/etc - exactly the stuff you say are too complex
> for the packet.
>

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?   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.

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?

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.


-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20101215/8bb06995/attachment-0001.html>