Difference: VOEventV21RFC (1 vs. 11)

Revision 112025-01-07 - BaptisteCecconi

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments


Contents

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:

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

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?

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

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

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

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

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

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

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

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

-- 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 (4) Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"

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.

(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.
Added:
>
>
  • Response again (BaptisteCecconi, 2025-01-07): I reviewed the changes from the VOEvent 2.0 schema and the version proposed here. The v2.1 changes are just added on top of version v2.0. The scope of v2.1 doesn't include fixing the v2.0 schema, which has been used to validate VOEvent for some time now. I propose to ignore the changes that would break the VOEvent 2.0 XSD validation. Hence the proposed XSD (see latest version on github) should do the job.
 

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.

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        

Added:
>
>

Revision 102024-11-19 - BaptisteCecconi

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments


Contents

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:

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

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?

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

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

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

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

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

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

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

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

-- 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 (4) Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"

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.

(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

Added:
>
>
 

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        

Revision 92024-11-19 - BaptisteCecconi

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments


Contents

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:

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

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?

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

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

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

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

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

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

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

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

-- 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 (4) Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"

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.

(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:
Changed:
<
<
    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.
>
>
  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.
Deleted:
<
<
 

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.

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        

Deleted:
<
<

Revision 82024-11-17 - BaptisteCecconi

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Changed:
<
<
Contents
>
>
Contents
 

Summary

Changed:
<
<		VOEvent 2.1 defines the content and meaning of a
>
>		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.
Deleted:
<
<		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:

Changes since 2.0

Changed:
<
<		This document describes an update to the IVOA VOEvent recommendation for the representation of solar system events. It has been developed
>
>		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.
Deleted:
<
<		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

Comments by MarkusDemleitner 2024-09-27

Changed:
<
<		(1) My main concern here is reference implementations. Do we have
>
>		(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.
Deleted:
<
<		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.
 
Changed:
<
<
  • 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).
>
>
  • 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).
 
Changed:
<
<		(2) Abstract: I consider it really odd to have something like a
>
>		(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.
Deleted:
<
<		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)

Changed:
<
<		(4) The section "Status of this Document" has a comment "to be removed".
>
>		(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.
Deleted:
<
<		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.
Changed:
<
<		(5) "IVOA’s Space-Time Coordinate (STC) metadata specification (Rots,
>
>		(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.
Deleted:
<
<		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).
Changed:
<
<		(6) Sect. 2.1 cites the "IVOA VOEvent Transport Note". I can't be
>
>		(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.
Deleted:
<
<		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)
Changed:
<
<		(7) Sect. 2.2 still talks about IVORN-s, a term we have have given up in
>
>		(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?
Deleted:
<
<		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?
 
Changed:
<
<		(8) Sect 2.2 still abuses the fragment identifier when building the
>
>		(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?
Deleted:
<
<		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.
Changed:
<
<		(9) Sect. 2.2 promises a VOEventStreamRegExt and a VOEventServerRegExt,
>
>		(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?
Deleted:
<
<		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?
 
Changed:
<
<		(10) Sect. 3.1 "The version attribute is required to be present and to
>
>		(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.
Deleted:
<
<		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.
Changed:
<
<		(11) Sect 3.1 "The xmlns attribute refers to one-or-more standard XML
>
>		(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.
Deleted:
<
<		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.
Changed:
<
<		(12) Throughout: Don't use {\tt x} any more. It's a miracle that still
>
>		(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.
Deleted:
<
<		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.
 
Changed:
<
<		(13) 3.3.1.5 "it may return zero or NaN, but no exception should be
>
>		(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".
Deleted:
<
<		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.
Changed:
<
<		(14) 3.3.3 "the number ofelements in each row should be the same
>
>		(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.
Deleted:
<
<		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.
 
Changed:
<
<		(15) 3.6 "pending a standard VO ontology or formal UCD-like vocabulary
>
>		(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.
Deleted:
<
<		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.
Changed:
<
<		(16) 3.6.2 "expressed as an ISO-8601 representation of some date and
>
>		(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".
Deleted:
<
<		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".
 
Changed:
<
<		(17) 3.9 "packet to describe an association with external content via a
>
>		(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).
Deleted:
<
<		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).
 
Changed:
<
<		(18) 3.9.3 it's better to not say "MIME type" any more. It's of course
>
>		(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"
Deleted:
<
<		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"
 
Changed:
<
<		(19) 3.9.5 The example contains a link to
>
>		(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.
Deleted:
<
<		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.
 
Changed:
<
<		I'd say you should either replace that by a link into the SVO filter
>
>		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.
Deleted:
<
<		profile database or comment that that's just a fictional example.
 
  • Response (BaptisteCecconi 2024-10-22): yes, SVO filter example would be better.
Changed:
<
<		(20) I'm not wild about the reference to kafka; this formats really
>
>		(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".
Deleted:
<
<		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".
 

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

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

Deleted:
<
<
  • Title Page: Shows "Interest Group == Time Domain".. the 2.0 version is identified with the DAL working group.
 
Changed:
<
<
    • Response (BaptisteCecconi 2024-11-17): No, DAL has the VTP document (VOEvent Transport Protocol), VOEvent schema is in Time Domain (formerly VOE).
>
>		(1) Title Page: Shows "Interest Group == Time Domain".. the 2.0 version is identified with the DAL working group.
Added:
>
>
  • 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 (4) Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"
 
Changed:
<
<
  • 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.
>
>		More Specific on content:
 
Changed:
<
<
    • Response (BaptisteCecconi 2024-11-17): Then we point to RefFrame, in which we are about to pour heliophysics and planetary reference frames. ok.
>
>		(1) Section 3.2.1: "We propose to use here the list of contributorType"... The REC should make a firm statement about this.
Added:
>
>
 
Changed:
<
<
  • Section 5: has a version 2.0 example.. a second example targeting the v2.1 elements would be helpful
  • Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"
>
>		(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.
Deleted:
<
<		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.
  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?
 STC-esque changes: For these, I am also looking at the schema file in the Git repository
Changed:
<
<
  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?
  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) 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:
Added:
>
>
  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.
Added:
>
>
  • 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.

Changed:
<
<		(1) "The concept of AstroCoords/PositionName is introduced"
>
>		(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.

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        
Changed:
<
<
StdProc        
>
>
<nop>StdProc        
 

Revision 72024-11-17 - BaptisteCecconi

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Contents

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:

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

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?

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

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

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

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

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

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

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

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

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

Changed:
<
<
  1. Title Page: Shows "Interest Group == Time Domain".. the 2.0 version is identified with the DAL working group.
  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.
  3. Section 5: has a version 2.0 example.. a second example targeting the v2.1 elements would be helpful
  4. Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"
>
>
  • 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).
Added:
>
>
  • 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): Then we point to RefFrame, in which we are about to pour heliophysics and planetary reference frames. ok.

  • Section 5: has a version 2.0 example.. a second example targeting the v2.1 elements would be helpful
  • Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"
 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.
Changed:
<
<
  1. 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?
>
>
  1. 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?
 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?
  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.

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.

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        
StdProc        

Revision 62024-11-13 - MarkCresitelloDittmar

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Contents

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:

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

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.

Changed:
<
<
  • 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).
>
>
  • 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.

Changed:
<
<
  • 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).
>
>
  • 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?

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

Changed:
<
<
>
>
  (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.
Changed:
<
<
  • Response (BaptisteCecconi 2024-10-22): Agreed. The correct value should be 2.1 fort this version. This should be fixed in the text.
>
>
  • 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.

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

Changed:
<
<
  • Response (BaptisteCecconi 2024-10-22): it is indeed strange: why would a float data type be a null string, should be NaN indeed.
>
>
  • 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
Changed:
<
<		as the number of elements" -- does anyone remember why this was
>
>		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.

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

Changed:
<
<
  • Response (BaptisteCecconi 2024-10-22): This is from the previous version, but I agree that we promote the use of the UAT terms here.
>
>
  • 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
Changed:
<
<		https://www.w3.org/TR/xmlschema-2/#isoformats [in this case, the
>
>		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".

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

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

(19) 3.9.5 The example contains a link to

Changed:
<
<		http://www.ivoa.net/rdf/IVOAT#Filter/h, which these days is misleading;
>
>		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".

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

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

Added:
>
>		 General Comments
  1. Title Page: Shows "Interest Group == Time Domain".. the 2.0 version is identified with the DAL working group.
  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.
  3. Section 5: has a version 2.0 example.. a second example targeting the v2.1 elements would be helpful
  4. Figure 2 caption: "VOEvent 2.0 in a Nutshell" should maybe go minor version agnostic "VOEvent Version 2 in a Nutshell"
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.
  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?
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?
  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.
 

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.

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        
Changed:
<
<
StdProc        
>
>
StdProc        
 
Added:
>
>

Revision 52024-10-22 - BaptisteCecconi

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Contents

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:

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

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.

Added:
>
>
  • 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.
Added:
>
>
  • 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.

Added:
>
>
  • 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.
Added:
>
>
  • 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.
Added:
>
>
  • 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?
Added:
>
>
 (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?
Added:
>
>
  • 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?
Added:
>
>
 (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.
Added:
>
>
  • 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.
Added:
>
>
  • 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.
Added:
>
>
 (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".
Added:
>
>
  • 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.
Added:
>
>
 (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.
Added:
>
>
  • 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".
Added:
>
>
 (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).
Added:
>
>
 (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"
Added:
>
>
 (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.

Added:
>
>
  • 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".
Added:
>
>
 I have also done some editorial changes in PR#20.
Added:
>
>
 -- 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.

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        
StdProc        

Deleted:
<
<

Revision 42024-10-17 - MarkKettenis

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Contents

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:

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

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.

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

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

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

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

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

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

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

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

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

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

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

Changed:
<
<		(14) 3.3.3 "the number of
elements in each row should be the same
>
>		(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.

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

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

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

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

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

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

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

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

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

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

Added:
>
>

Revision 32024-09-27 - MarkusDemleitner

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Contents

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:

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

Added:
>
>

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.

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

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

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

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

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

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

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

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

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

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

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

(14) 3.3.3 "the number of

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

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

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

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

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

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

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

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

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

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        
SSIG        
Theory        
TD        
StdProc        

Deleted:
<
<

Revision 22024-09-02 - PierreFernique

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Contents

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:

Changed:
<
<
>
>
 

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

Changed:
<
<

Comments from the IVOA Community during RFC/TCG review period: 2024-05-01 - 2024-06-15

>
>

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

Changed:
<
<

Comments from TCG member during the RFC/TCG Review Period: 2024-05-01 - 2024-06-15

>
>

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

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        
SSIG        
Theory        
TD        
StdProc        

Added:
>
>

Revision 12024-04-22 - PierreFernique

 
META TOPICPARENT name="VOEventV2RFC"

VOEvent2.1 Proposed Recommendation: Request for Comments

Contents

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:

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-05-01 - 2024-06-15

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

Comments from TCG member during the RFC/TCG Review Period: 2024-05-01 - 2024-06-15

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

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        
SSIG        
Theory        
TD        
StdProc        

View topic | History: r11 < r10 < r9 < r8 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback