Add unique identifier and property to recognize alert type

[aleberti]

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 the FollowUp 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)
• at the moment, it is not straightforward to recognize easily which type of alert is received. I take as an example https://github.com/nasa-gcn/gcn-schema/blob/main/gcn/notices/swift/bat/guano.loc_arc_min.example.json and https://github.com/nasa-gcn/gcn-schema/blob/main/gcn/notices/swift/bat/guano.loc_map.example.json . The alert_tense and alert_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 in Alert core schema that identifies the type of alert, similarly to the Packet_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 like SWIFTBAT_GUANO_LOC_ARC_MIN and SWIFTBAT_GUANO_LOC_MAP. In this way, subscribers know immediately what they would find in the JSON, and code the parsing accordingly.

[shb46]

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