VOEvent 2.0 WD comments

[Andrew Drake]

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