VOEvent session

[Mike Fitzpatrick]

On Thu, Dec 16, 2010 at 12:43 AM, Matthew Graham <mjg at cacr.caltech.edu>wrote:

>
> I couldn't agree more. The issue on the table is how to reconcile the
> various time series representations proposed in VOEvent 2.0 with the
> serialization of the IVOA time series data model. My preference is to drop
> simpleTimeSeries and see what needs to be done to <Table> to bring it in
> line - is it just a case of adding a 'utype' attribute and prescribing which
> utypes to use when representing a time series?
>

Yes, drop simpleTimeSeries (it's practically a groundswell at this point!)

 Adding an optional utype to <Field> shouldn't be controversial and would
allow
us to hook into the DM work and present a time series or other data more in
line
with the other IVOA work.  Prescribing the utypes could be a minor 2.1
upgrade
if this were done.

I think multiple <Table> elements should be explicity allowed (the draft
isn't
clear on this) to allow inclusion of timeseries, spectra, or whatever else
is deemed
necessary in the same packet.  Are the 'name' and 'type' attributes enough
or
should there also be something like a 'role' attr to distinguish tables as
being
THE 'timeSeries' or 'spectrum' or 'measuredPos' or 'predictedPos' or .....?

I suspect we might also want a <Param> but admit to not having a real
example
on hand.  Something to consider would be to add a <Table> to the allowed
children
of <Group>, this would solve the need for a param and might be more
expressive
of various measurements.  In that case, a 'role' attr might go on the
<Group> to
say this is e.g. the time series data.

Just some thoughts driving in....

-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20101216/023c3197/attachment.html>