Open aleberti opened 1 month ago
@aleberti: The FollowUp
schema allows for additional properties where you could demo your concept, although it is not the only application of an unique id. You can consider the following options, if you haven't done so already, which do not require adding new properties:
(topic, offset)
, which is unique to my knoledge. (mission, instrument, record_number)
, if Kafka generates the record_number
. If producers assign this number, then it is less likely to be guaranteed. I'm not clear on who does it.(mission, instrument, alert_datetime)
. Date time is assigned by the producer, so the comment about record_number
applies here as well.Whether the tuple above is used or it is some other identifier, you have to think how to reference circulars or even sources outside GCN. Other sources may or may not have available unique identifier, not to mention it may change over time.
Description
In the current VOEvent format, there are two important fields that I think the JSON format should have:
ivorn
, an unique identifier attached to each alert (see https://voevent.readthedocs.io/en/latest/reading.html?highlight=ivorn#ivorns-and-identifiers). This can be used also to reference specific alerts in follow-ups by other instruments e.g. using theFollowUp
core schema or by the same instrument in the case it sends updates on the same event. More importantly, it can be used in general for the provenance of alerts, and used by subscribers to properly store the alerts (e.g. in their local DB or files on disk)alert_tense
andalert_type
is the same, but the content is different (one contains RA and Dec, the other has a link to a skymap). It would be good to have an additional field inAlert
core schema that identifies the type of alert, similarly to thePacket_Type
of VOEvents. It does not need to be an integer, but it can be a string (but definitely the same variable type for all JSON alerts, not a mix of integers and strings). In the cases above, e.g. something likeSWIFTBAT_GUANO_LOC_ARC_MIN
andSWIFTBAT_GUANO_LOC_MAP
. In this way, subscribers know immediately what they would find in the JSON, and code the parsing accordingly.