VOEvent 20110215 notes

[Rob Seaman]

Hi Norman,

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

Thanks!  Note that the most recent version is currently:

	http://www.ivoa.net/Documents/VOEvent/20110314

Changes as described below and in the next few messages should appear in a 20110318 version.

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

This was already corrected in the PR version.

> 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?)

I see Bob Denny has already replied.  I'll add pointers to the current transport notes.

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

Done.

> Sect 2.1: Can an _author_ be a machine, or a program, or do they have to be a person or an organisation?

I've added some text.

> 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?

Not excluded, I've reworded.  These are roles filled by different components in a system.  A repository (of whatever content) has one or more inputs (possibly wholly internal) and one or more outputs with some mechanism for persistence in the middle.

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

Added a reference to IVOA RM.

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

Have reworded.

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

You are encouraged.  Don't know what to do here unless you elaborate.  I suspect the implications will be broader than VOEvent.

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

Will add a reference.

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

Fixed.

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

Have reworded.

> In a namespace?  What is the VOEvent namespace?

Any comments on this topic from the peanut gallery?

> s/responsibel/responsible/

fixed.

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

Reworded.

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

Reworded.

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

Will be reworded.

> 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"

Have removed that phrasing.  Underspecification perniciously persists.

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

Somehow I'm reminded of Sprockets with SNL's Mike Myers.

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

Trying not to modify the text in 3.4.  Fessing may be addressed in the future.

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

We had hoped precisely to bring more semantic juju to <Why>.  Perhaps there is still time for v2.0 if the changes are small and backwards compatibility is maintained in some fashion.  Suggestions for the exact language?  Otherwise this will have to wait until v2.1.

> 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".

done.

> Is there an implied guarantee that a superseded or retracted event won't be referred to by a future packet from this same source?

No, and this is now stated.

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

Yes indeed.  I've also added you as an author.  There's no escape now!

Rob