From ajd at cacr.caltech.edu  Mon Nov  1 16:11:03 2010
From: ajd at cacr.caltech.edu (Andrew Drake)
Date: Mon, 1 Nov 2010 16:11:03 -0700 (PDT)
Subject: VOEvent 2.0 WD comments
In-Reply-To: <20101029100306.ACS33185@comet.stsci.edu>
References: <alpine.DEB.2.00.1010282034310.3873@covm>
	<20101029100306.ACS33185@comet.stsci.edu>
Message-ID: <Pine.LNX.4.63.1011011526190.5827@moriori.cacr.caltech.edu>


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.



From roy at cacr.caltech.edu  Tue Nov  2 08:17:16 2010
From: roy at cacr.caltech.edu (Roy Williams)
Date: Tue, 02 Nov 2010 08:17:16 -0700
Subject: VOEvent 2.0 WD comments
Message-ID: <4CD02B7C.3010204@cacr.caltech.edu>

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>

From seaman at noao.edu  Mon Nov 22 12:48:45 2010
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Nov 2010 13:48:45 -0700
Subject: Factoid regarding QB14.3 .H68 2010
Message-ID: <352BE2C2-9B16-4AA7-AD9A-5570A49B37BC@noao.edu>

The NOAO librarian has assigned "Hot-Wiring the Transient Universe" an LCC designation of:

	QB14.3
	.H68
	2010

Interesting factoid.  LCC identifiers are actually only local to the particular library.  A library will, of course, use an identifier provided by the actual Library of Congress if such is available, but otherwise is on their own for attaching an ID.  In a case like a discipline library such as astronomy it is quite possible that a center such as NOAO or Caltech may have more extensive (or at least deeper and more idiosyncratic) holdings than the LCC.  It appears that no ultimate registry exists for resolving global LCC identifiers (although see http://www.loc.gov/catdir/pcc/saco/saco.html).

Sarah and Roy have done a great job of putting the content for the HTU book online:

	http://hotwireduniverse.org

from whence one can click through to purchase your own physical copy:

	http://www.lulu.com/product/paperback/hotwiring-the-transient-universe/13205496

Numerous such were sent out and many authors and attendees should already have received a copy in addition to the three crates distributed at ADASS.  Copies are also available in Tucson and Pasadena if you are in the area.

Rob


From seaman at noao.edu  Mon Nov 22 13:10:24 2010
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Nov 2010 14:10:24 -0700
Subject: Factoid regarding QB14.3 .H68 2010
In-Reply-To: <352BE2C2-9B16-4AA7-AD9A-5570A49B37BC@noao.edu>
References: <352BE2C2-9B16-4AA7-AD9A-5570A49B37BC@noao.edu>
Message-ID: <3114A2B8-E6C8-4988-8987-696D9A658178@noao.edu>

And the LoC doesn't even guarantee that its own designations are unique and permanent:

	http://www.loc.gov/catdir/cpso/050uniqu.html

Rob
---

On Nov 22, 2010, at 1:48 PM, Rob Seaman wrote:

> The NOAO librarian has assigned "Hot-Wiring the Transient Universe" an LCC designation of:
> 
> 	QB14.3
> 	.H68
> 	2010
> 
> Interesting factoid.  LCC identifiers are actually only local to the particular library.  A library will, of course, use an identifier provided by the actual Library of Congress if such is available, but otherwise is on their own for attaching an ID.  In a case like a discipline library such as astronomy it is quite possible that a center such as NOAO or Caltech may have more extensive (or at least deeper and more idiosyncratic) holdings than the LCC.  It appears that no ultimate registry exists for resolving global LCC identifiers (although see http://www.loc.gov/catdir/pcc/saco/saco.html).
> 
> Sarah and Roy have done a great job of putting the content for the HTU book online:
> 
> 	http://hotwireduniverse.org
> 
> from whence one can click through to purchase your own physical copy:
> 
> 	http://www.lulu.com/product/paperback/hotwiring-the-transient-universe/13205496
> 
> Numerous such were sent out and many authors and attendees should already have received a copy in addition to the three crates distributed at ADASS.  Copies are also available in Tucson and Pasadena if you are in the area.
> 
> Rob
>