VOEvent 2.0 WD comments

Tue Nov 2 08:17:16 PDT 2010

Dear VOEvent group
This review from Andrew Drake.
Roy

-------- Original Message --------
Subject: [standards-protocols] VOEvent 2.0 WD comments
Date: Mon, 1 Nov 2010 16:11:03 -0700 (PDT)
From: Andrew Drake <ajd at cacr.caltech.edu>
To: standards-protocols at usvao.org
CC: voevent at ivoa.net

Dear All,

I have attached comments about the VOEvent 2.0 working draft.
I think it would also be valuable for someone less familiar
with past work on the VOEvent standard to look it through.

cheers,
         Andrew
-------------

Notes on the VOEvent 2.0 Working Draft

As Matthew mentioned in his comments the first thing that struck me was
that most of the linked reference numbering is wrong. This draft clearly
follows along from VOEvent 1.1 in most aspects. Issues of schema 
complexity the Bob warned of in his "Reflections on VOEvent 1.1 and the 
Real World" note remain to some extent because of the inclusion of 
tables and simple timeseries. Event transportation remains an open 
issue. The use of citation was unclear to me, as was the use of 
simpletimeseries (based on this document alone).

I have a number of questions and comments about the specific draft
sections below.

--------------
-In section 1

The abstract notes that the standard does not define the transport layer.
However, in the introduction the document says it will leverage the success
of GCN by generalizing its transport mechanism. Event transport is at the
core of VOEvent. I am not sure that we can generalize it without
defining it.

The selection criteria example used in the introduction seems a little
removed
from reality. Perhaps are more realistic example could replace this.

The document link to dotAstro "[31]" is not an actual link in the text.

The text says that a discovery that cannot benefit from immediate follow-up
is not a good candidate for expression as a VOEvent.
There are few event discoveries that would not benefit from some kind
additional
follow-up and more rapid follow-up is probably better for most. However,
there
are certainly some cases where later follow-up will do, and later
follow-up may
even be more useful (depending on the type of event and means of
available follow-up).
If VOEvents are for rapid follow-up, is there any machine readable means of
expressing discoveries requiring future follow-up?
Issuing VOEvents at a later time is clearly not the optimum method
because of
scheduling constraints.
Is there really a good reason to limit VOEvents to immediate follow-up?

-In SS 2.1

In the definition of "Authors" it mentions they should register with the
IVOA registry.
It would be useful if there was a link to a documents explaining how to
do this.

-In SS 2.4.2

It would be useful if there was a link to SEAP here.

-In section 3

As an event can only have one <Citations> sub-element, how does one note an
error within a follow-up VOEvent.

-In section 3.3

<Param> can now have <Description> and <Reference> elements.
Why are these contained in the event rather than in a stream definition.

The example of <Param> usage does not contain the dataType attribute.
This would be useful to include since it is new.

Perhaps the following space of the param name attribute, "GRB_INTEN ",
should be removed.

-In SS 3.3.2

In the <Group> example, shouldn't this be name="GRB_INTEN" rather than
type="GRB_INTEN".
Perhaps this is meant to specify the type of data structure, but it is
confusing.

-In SS 3.3.3

The table definition specifies that event cell must have any entry.
Since it is very common
to have missing values in a tables and it seems like a very bad idea to
exclude rows because
of missing values. How does someone represent a missing value particular
if they should have
a specific dataType? <SimpleTimeseries> appears to use an optional default.

The dataType attribute "used to interpret the values in the table"
appears to  be missing
from the <Table> example given directly below the statement about it.

-In SS 3.3.4

The usage of SimpleTimeseries was confusing. The example has elements
<VAL> and <ERR> but
these were not described in the text. The link to
http://dotastro.org/simpletimeseries/
and even http://dotastro.org/ did not work for me so I was unable to see
the full documentation.

SimpleTimeseries seems to contain significant redundant information.
In the example the <BAND> element appears to contain the same
information three times.
ucd ="...em.opt.I" bandid="I" and value "I".

The <ELEM> element had an attribute "row" which was described and the
example had
row values 1, 1.5, 2, 2.5. What does row 1.5 mean?

-In SS 3.4.1

The text notes that VOEvent subscribers should be prepared to handle
equatorial coordinate systems.
However, in section 3.4.4 the standard notes that solar subscribers need
not handle equatorial coords.
If this is the case, perhaps there should be no expectations about
handling equatorial coords.
The expectation might be better defined as simply recognizing the list
of coordinate system definitions.

-In SS 3.6

The specification requires that the <Why> contains <Concept> and <Name>
sub-elements.
Why are these required for cases when we have no concept what the event is?
Also, is it possible to negate a concept since it is often clearer what an
event is not rather than what it is?

-In SS 3.6.4

replaement -> replacement

-In SS 3.7

The citation section seems very strongly tied to VOEvents IVORNs is it
is unclear how this will work,
This sections notes that the lack of a <Citation> element asserts that
an event is a new discovery.
It is not clear to me how one can cite information about an event, for
example from an ATel, for
which a VOEvent was not issued.

-In SS 3.7.1

Since event IVORNs appear to tie events together. How do you express an
event is new while also
citing a relation to a prior event that has an IVORN?
For example, there is a new event with the same source as per CV and LBV
outbursts.
How do you cite that a new event is similar to a past event, or near a
past event while
including that event's IVORN.

-In section 3.8

The text mentions using CDATA to include complicated information. This
possibility reflects on
a VOEvent transport issue since CDATA is not allowed in XMPP and must be
escaped.

-In section 4.

This is a very minor point, but a 2005 followup VOEvent for an SN
discovered in 2009 makes an
unusal example. I would suggest changing the VOEvent example's <Date> to
post 2009, preferably
2010 since this is supposed to be 278 after the discovery of SN 2009lw.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: voevent2_comment.txt
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20101102/0c93cca6/attachment.txt>