VOEvent2.1 Proposed Recommendation: Request for Comments

Summary

VOEvent 2.1 defines the content and meaning of a standard information packet for representing, transmitting, publishing and archiving information about a transient celestial event, with the implication that timely follow-up is of interest. The objective is to motivate the observation of targets-of-opportunity, to drive robotic telescopes, to trigger archive searches, and to alert the community. VOEvent is focused on the reporting of photon events, but events mediated by disparate phenomena such as neutrinos, gravitational waves, and solar or atmospheric particle bursts may also be reported.

Proposed Recommendations (PRs) for VOEvent 2.1 can be found at:

• 2024-05-22: last PR

Changes since 2.0

This document describes an update to the IVOA VOEvent recommendation for the representation of solar system events. It has been developed by the Solar System and Time Domain Interest Groups. Details of changes from v2.0 are described in the document.

Reference Interoperable Implementations

Implementations Validators

Comments from the IVOA Community during RFC/TCG review period: 2024-09-15 - 2024-10-31

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments by MarkusDemleitner 2024-09-27

(1) My main concern here is reference implementations. Do we have active VOEvent streams? To me, this is particularly relevant with respect to the registry part, where I have tried fairly hard to register a VOEvent stream so people can try the discovery queries but failed to do so. I'd actually be fairly unhappy if this went to RFC without an actual resource in the Registry.

• Response (BaptisteCecconi 2024-10-22): This is a good question. I don't have an answer, but we should be able to monitor this. I know there is an FRB VOEvent "stream", but I'm not sure it uses VTP, since they provide their own access library (https://github.com/CHIMEFRB/voe).

(2) Abstract: I consider it really odd to have something like a hyperself-citation ("\citep{2011ivoa.spec.0711S}") in the abstract, even more so in that cites an earlier version of the current standard. Unless I'm missing something big time, I'd strongly suggest to remove that citep.

• Response (BaptisteCecconi 2024-10-22): yes, I agree, this should be removed.

(3) (Retracted)

(4) The section "Status of this Document" has a comment "to be removed". I'd second that, because you have a lot of nonstandard information in there that people used to ivoatex won't expect there; and you'll keep forgetting updating this because that's really ivoatex's turf, which has already added such a section right below the abstract. Just remove the section and re-distribute the material you think you still need somewhere else. I have taken the liberty to move the relationships to other standards to where it normally belongs in ivoatex documents.

• Response (BaptisteCecconi 2024-10-22): yes, I agree, this should be removed.

(5) "IVOA’s Space-Time Coordinate (STC) metadata specification (Rots, 2007). Some of the VOEvent structure is provided by this document" This perhaps can't be done for this round of the document, but for the next one I'd strongly advocate picking some subset of STC and describing it in this spec (or do something completely different). STC 1.30 itself is just too much to grok as a dependency of this standard, and it's been superseded anyway.

• Response (BaptisteCecconi 2024-10-22): This section is from the past version. We could update it, if someone wants to write up the content. However, as you say, STC has been superseded by coords. I don't know how to use coords in VOEvent (I asked to several DM experts, with no success).

(6) Sect. 2.1 cites the "IVOA VOEvent Transport Note". I can't be bothered to properly investigate, but I think that's basically what's now the "VOEvent Transport Protocol" REC. If so, let's cite that. By the way, commenting on that REC would be appropriate in the Role within the VO subsection, too, since it's in the role diagram.

• Response (BaptisteCecconi 2024-10-22): ok (this is just copied from the previous version)

(7) Sect. 2.2 still talks about IVORN-s, a term we have have given up in the registry as unhelpful, and the term "IVORN" is also baked into quite a few element names and other stuff we can't change without breaking things. So, I'd suggest to give a bit of a historical note and state that "IVORN" is a term specific to VOEvent and outside of it people should say IVOID. I'd happily contribute text like that. May I?

• Response (BaptisteCecconi 2024-10-22): ok, fine with me.

(8) Sect 2.2 still abuses the fragment identifier when building the IVOIDs of the Events. You see, ivo://authorityID/resourceKey#local_ID implies that when you resolve and retrieve ivo://authorityID/resourceKey, the resulting document will have a part identified as (e.g., through an id attribute in XML) local_ID. That is simply not the case here. Hence, it would be a lot better if we used a ? here, implying "use a service on that the identifier (sc. without the query part) identifies". Years ago I was told that would break a lot of software. This little wart is probably not worth that. But if that software is decommissioned now, perhaps this is the time to fix this problem?

• Response (BaptisteCecconi 2024-10-22): That comes back to your first question, since we should check which syntax the currently produced VOEvent are using.

(9) Sect. 2.2 promises a VOEventStreamRegExt and a VOEventServerRegExt, and it claims the Registry could hold VOEvent instances. VOEventStreamRegExt now comes with the present document, while VOEventServerRegExt never materialised, and there is no place for VOEvent documents themselves in the Registry. Frankly, I would like to rewwrite that entire passage. May I?

• Response (BaptisteCecconi 2024-10-22): please do !

(10) Sect. 3.1 "The version attribute is required to be present and to equal "2.0" for all VOEvent packets governed by this version of the standard." – I have no particular concern with that as such (I don't know why the minor version was included here, though), but I predict everyone will be confused unless you comment why something specified in a 2.1 spec would have 2.0 here. Or bump this to 2.1.

• Response (BaptisteCecconi 2024-10-22): Agreed. The correct value should be 2.1 fort this version. This should be fixed in the text.

(11) Sect 3.1 "The xmlns attribute refers to one-or-more standard XML namespace declarations that may optionally help define the contents of a packet." – that's not all wrong but wrong enough that I'd prefer to drop it (and the xmlns in the example above). This is no place to discuss XML namespaces, but we shouldn't confuse people with cloudy statements either.

• Response (BaptisteCecconi 2024-10-22): Could we rather tell that the content of the VOEvent can use external namespaces.

(12) Throughout: Don't use {\tt x} any more. It's a miracle that still works. Rather, do \texttt{x} or, perhaps better suited to code-like strings, \verb|x|. Ask me and I'll do a PR; I didn't want to spoil the diff for the minor fixes PR, else I'd already have done it.

• Response (BaptisteCecconi 2024-10-22): ok

(13) 3.3.1.5 "it may return zero or NaN, but no exception should be thrown." -- I think allowing a zero here is an exceptionally bad idea. Does anyone remember why that was allowed? Anyway, I'd suggest doing a "lightly-breaking" change here (meaning: it's still minor) and saying "if it doesn't parse, it's a NaN. If you can't produce NaNs, then bail out".

• Response (BaptisteCecconi 2024-10-22): it is indeed strange: why would a float data type be a null string, should be NaN indeed.

(14) 3.3.3 "the number ofelements in each row should be the same as the number of elements" -- does anyone remember why this was written in this way? You see, I think this should have been a MUST, and if it's just a should we'd need to say what clients are supposed to do when there are too many or to few TDs. Perhaps we can use this opportunity to sneak in a MUST? To me, that would still be "lightly-breaking", i.e., ok for a minor version.

• Response (BaptisteCecconi 2024-10-22): ok with me.

(15) 3.6 "pending a standard VO ontology or formal UCD-like vocabulary of astronomical concepts" -- can anyone give an assessment of what the UAT is missing to qualify? Ditto in 3.6.3. If you do chose to somehow recommend or adopt the UAT here, the thing to reference within the VO is 2022ivoa.spec.0722D.

• Response (BaptisteCecconi 2024-10-22): This is from the previous version, but I agree that we promote the use of the UAT terms here.

(16) 3.6.2 "expressed as an ISO-8601 representation of some date and time in the future" -- don't quote the mess that is ISO-8601 here, in particular since the schema disagrees; it says expires is of type xs:dateTime. That, in turn, is discussed in some length in https://www.w3.org/TR/xmlschema-2/#isoformats [in this case, the fragment identifier is appropriate...], which, for instance, says: "Truncated formats are, in general, not permitted for the datatypes defined in this specification with three exceptions".

• Response (BaptisteCecconi 2024-10-22): Can you propose a rewording ?

(17) 3.9 "packet to describe an association with external content via a Uniform Resource Identifier (Demleitner and Plante et al., 2016)" -- what you cite is the IVOID spec, and that is inappropriate if you want to allow generic URIs (which you do). I'd say either drop the reference entirely (people who read the spec should probably know enough about URIs without further ado) or cite std:RFC3986 (it's in ivoatex already).

• Response (BaptisteCecconi 2024-10-22): ok, we can change this ref.

(18) 3.9.3 it's better to not say "MIME type" any more. It's of course ok to keep the attribute name, but I think the whole exposition profits when you then explain it as "An optional RFC 2045 media type of the referenced document"

• Response (BaptisteCecconi 2024-10-22): ok.

(19) 3.9.5 The example contains a link to http://www.ivoa.net/rdf/IVOAT#Filter/h, which these days is misleading; nobody is expected any more to understad anything like that, not to mention we've broken that link (if it ever worked, which by the wayback machine's output I doubt), and I don't think "Filter/h" has ever been in the IVOA Thesaurus. I certainly isn't in its anointed successer, the UAT.

I'd say you should either replace that by a link into the SVO filter profile database or comment that that's just a fictional example.

• Response (BaptisteCecconi 2024-10-22): yes, SVO filter example would be better.

(20) I'm not wild about the reference to kafka; this formats really awkwardly. We'd either have to fix the bst to do something more sensible with manual, or (IMHO preferably) use a misc document type. Not sure about authors here, but the "accessed Novmber 9, 2020" (if we want to keep it, which I frankly doubt) would probably look more reasonable in a howpublished clause: "Webpage, accessed 2020-11-09".

• Response (BaptisteCecconi 2024-10-22): ok, please do.

I have also done some editorial changes in PR#20.

• Response (BaptisteCecconi 2024-10-22): Thanks !

-- MarkusDemleitner - 2024-09-27

Comments from TCG member during the RFC/TCG Review Period: 2024-09-15 - 2024-10-31

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

If my understanding is correct that valid VOEvent 2.0 XML documents are still valid VOEvent 2.1 then I think the changes are ok from the viewpoint of the Radio community. This is important since the FRB (Fast Radio Burst) community uses archived VOEvents as the basis for a catalogue of events.

(1) "The concept of AstroCoords/PositionName is introduced"

-- MarkKettenis - 2024-10-17

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee

TCG Vote :

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.