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

General Comments

(1) Title Page: Shows "Interest Group == Time Domain".. the 2.0 version is identified with the DAL working group.

• Response (BaptisteCecconi 2024-11-17): No, DAL has the VTP document (VOEvent Transport Protocol), VOEvent schema is in Time Domain (formerly VOE).

(2) Section 3.4.4: "we call for an IVOA vocabulary for managing the valid terms of well-known solar system reference frames". The REC shouldn't leave this open.. there should be a seeded vocabulary which can be built upon.

• Response (BaptisteCecconi 2024-11-17): I remove the sentence, and I study this in Semantics.

(3) Section 5: has a version 2.0 example.. a second example targeting the v2.1 elements would be helpful

• Response (BaptisteCecconi 2024-11-17): ok, an example has been added.

(4) Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"

• Response (BaptisteCecconi 2024-11-17): ok.

More Specific on content:

(1) Section 3.2.1: "We propose to use here the list of contributorType"... The REC should make a firm statement about this.

• Response (BaptisteCecconi 2024-11-17): updated text, and update reference (now DataCite schema 4.5)

(2) Section 3.2.2: Going by the description, it sounds like "AuthorIVORN" does not resolve to an "Author" instance. it resolves to an Organization instance from Resource Metadata, which I believe is similar but not the same as Author as described in this section. Is that right?

• Response (BaptisteCecconi 2024-11-17): I'd rather not change this part of the text (coming from 2.0), for a minor version focussing on adding support for Solar System events. The whole thing of IVORN should probably be scrapped off the document, but I'd pass that to the next version.

STC-esque changes: For these, I am also looking at the schema file in the Git repository

(1) It looks like VOEvent does not import the STC schema in any way, but rather replicates STC elements in this schema. This is in line with Markus' comment 5, so maybe the dependency on STC-1.33 is not quite as tight as it seems. I personally think this is problematic since there are small deltas between what is here and in STC

(2) AstroCoordSystem list: moving to a string seems OK, and there is still a list of 'should be ready for' systems in the paragraph.. so users know what the baseline is. It isn't clear to me how users are to find the full set of registered coordinate systems.. but that may just be me.

(3) Annotations to Time and Position2D: apparently just means the schema description node now better describes the element. .. OK

(4) AstroCoords/PositionName:

1. this is NOT an STC element, but is added into what is 'borrowed' STC content. I suppose that can be considered extended content to the STC Position type
2. I don't get a clear picture of what that value may be, or how it is used from the description. It doesn't sound like this comes from a resource, and if it is, the resource is not specified, so I'm not sure how a user can determine a coordinate/position from this value.
3. I'm not a schema person, but the schema representation seems different. STC AstroCoords allows 1-Time and 1-Position where Time and Position are groups of various types. It looks like the VOEvent schema AstroCoords will allow 1 of each ( Time, PositionName, Position2D, Position3D ), which is probably not what is really expected?

• Response (BaptisteCecconi, 2024-11-17): update schema with sequence instead of choice for AstroCoords.

(5) TimeInterval:

1. there is a TimeInterval in STC and the spec is similar, but not identical to this.. so that is OK
2. but again, I'm not understanding the schema rep which looks like the Time type contains unbounded choice of TimeInstant (which is required?), TimeInterval (minoccur=0), Error (minoccurs=0), there is 1 unit associated with the full Time type

(6) TimeOrigin:

1. TimeOrigin is added to TimeInstant ( ISOTime, TimeOffset, TimeScale, TimeOrigin ), but is not described in the document at all.

(7) Position Errors:

1. ErrorRadius made optional, and adds optional Error2. Again, this seems like you want the a choice of one or the other, but it looks like BOTH would be OK too.

• Response (BaptisteCecconi, 2024-11-17): If anyone is willing to get the schema right, I'd be happy to merge this. At this point, the schema validates the examples I used and the VOevent 2.0 XML documents I had at hand. To me that's enough of a work.

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

• Response (BaptisteCecconi, 2024-11-17): fixed.

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.

Group	Yes	No	Abstain	Comments
TCG
Apps
DAL
DM
GWS
Registry
Semantics
DCP
Edu
KDIG
Ops
Radio				Typo in Appendix A.1 (see above)
SSIG
Theory
TD
<nop>StdProc

---