VOEvent 20110215 notes

[Norman Gray]

Rob and Roy, hello.

Here are a few notes on the VOEvent draft of 20110215.  The notes are in document order.

The references are out of sync.  I didn't check all of them, but for example in the Introduction, you cite "PTF [32]", which is one out.

Just before section 1.1, you mention transport mechanisms.  You've noted that VOEvent doesn't define transport mechanisms, but I think the reader here would be at least interested in any discussion of the various tradeoffs and experience here.  Is that published anywhere (and if it's not, shouldn't such an article be in PASP or at least on arXiv?)

Sect. 2, Usage: this document defines the _syntax and_ semantics of VOEvent packets.

Sect 2.1: Can an _author_ be a machine, or a program, or do they have to be a person or an organisation?.  Ditto for publishers.  I see from Sect. 3.2.1 that the author has to be a human or corporate body, but this might be worth making explicit here.

You defined a Repository saying that "[r]epository subscribes to one or more VOEvent streams".  Does it have to?  What if the repository is a database at the originating facility, which gets its content from the same source from whicha set of VOEvent packets was generated.  That is, it holds the entire VOEvent stream, but not through a VOEvent subscription.  For example, the LIGO event database (which might generate LIGO VOEvents) will have all the events, and one can imagine it being able to respond to VOEvent queries, but not because it read any VOEvents -- is that excluded as a VOEvent Repository?

Sect 2.2: "For the purposes of VOEvent, the principal schemata are...".  Is "Author Organization" a schema?

You say "Thus VOEvent identifiers are overloaded; they contain a stream identifier, then the "#" sign, then the local reference within that stream.".  I don't think this is overloading -- the two things simply have a systematic relationship to each other.

URL design: you mention the IVORN <ivo://nvo.caltech/voeventnet/catot#1004071150784109051>.  The semantics of URIs mention that fragments are intended to be interpreted/resolved client-side:

>    As such, the fragment identifier is not used in the scheme-specific
>    processing of a URI; instead, the fragment identifier is separated
>    from the rest of the URI prior to a dereference, and thus the
>    identifying information within the fragment itself is dereferenced
>    solely by the user agent, regardless of the URI scheme.
> <http://www.ietf.org/rfc/rfc3986.txt>

I can't help feeling that using the fragment in this way is rather going against the URI grain, in a way I could elaborate if given any encouragement.

Sect 2.3: This is titled ""Authentication and Authorization", but the content of this section doesn't really discuss these, other than glancingly, or by implication.  Also, you say "These questions are addressed elsewhere." -- a reference would be useful.

Sect 3: "The VOEvent schema [6]" -- broken reference.

You say "Multiple <VOEvent> elements may be jointly contained within a larger XML document, but these should be handled as separate alert packets."  How?  In a namespace?  What is the VOEvent namespace?

s/responsibel/responsible/

You say "the ordering of elements is immaterial to interpretation, but may be important for efficient processing in demanding applications".  Since the schema doesn't constrain the order of the elements, it's not clear what's being stated here.

Sect 3.1: You say "The identifier actually contains TWO IDENTIFIERS".  No, the identifier contains one identifier, but the URI is constructed systematically, so that the identifier of a different resource -- the stream -- is deducible from the identifier of an event.  Ie this is a non-opaque identifier: this can be regarded as a bad thing or an acceptible practical compromise, but it _is_ a decision.

Sect 3.2.3: Are you accepting _all_ of ISO-8601?  I hope not.  The W3C ISO-8601 profile might be better <http://www.w3.org/TR/NOTE-datetime.html>, aka W3CDTF.  Or even something more restricted than that.

Sect 3.3.1.1: I feel that 'name' is somewhat underspecified here.  Is it just for intra-document crossrefs?  It's the "may be used elsewhere" that's odd: does this 'may' mean 'is permitted to be' or 'be warned that..."?

Sect 3.3.3: Ah, <table>.  Not touching it!

Sect 3.4.1.  I see that this includes STC, but by cut-and-paste rather than by reference.  I can see the motivation for this (less schema-ugliness), but it might be worth 'fessing-up to this.

Sect 3.6.3, Concept

My suggestion here would be to require that the content of the <Concept> element is a URI which is defined to be a SKOS concept.  That's perfectly compatible with the 'Vocabularies in the IVOA' Recommendation, is flexible, and just as constrained as is necessary here.

But I know there's a long on-list discussion about this, so I should wade in to that (tomorrow).

Sect 3.6.6: Inference.  I'd like to know what sort of probability is being mentioned here.  It's obviously unlikely to be a frequentist one, if it's an observation, but is it some careful bayesian estimate, some rule-of-thumb one, or something notional?  Perhaps it doesn't matter.

Sect 3.7.1.1, cite:  You say "When a citation is made with a "supersede" or "retraction" attribute, it is assumed that *all* of the previous information is superseded: and so the cited event is no longer needed."  You might add "...other than for archival or historical purposes".  Is there an implied guarantee that a superseded or retracted event won't be referred to by a future packet from this same source?




That's me, I think!  I hope this is helpful.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk