Major Jacob Westfall; alert.incidents: this element should be more clearly defined to ensure interoperability between systems. A recommended format is IDENTIFIER,URI with multiple values separated by whitespace. To be in line with Oasis standards XRI could be substituted but there are still problems with W3C right now. The transport method must be included in the URI to allow a receiving system to be able to download this incident message if need be and should point to the actual CAP message itself. For two-way systems even those like DM-Open using SOAP can use the URI, while one-way systems can use the identifier to correlate their received alerts.
<incident> is not a reference to a message, but rather a shared name, as per ICS, for the inherently fuzzy collection of events and activities emergency managers call an "incident." The goal was to allow multiple messages referring to different aspects or phases of an incident to be associated.
This is highly problematic in practice for a number of reasons. Incidents aren't atomic... they sometimes merge and sometimes split. Also, incident names frequently aren't assigned until well after alerts would be issued. And of course its frequently the case that a single alert may refer equally to a vast number of individual incidents, e.g. in the case of a hurricane warning.
Thus this cross-referencing may sometimes be feasible later, it's only rarely possible at the time alerts are authored. If anything I'd suggest considering whether <incident> should go on the "it was a good idea, but" stack and removed from future versions of the spec.
I agree that incident names aren't assigned until alerts are issued, but alerts can be updated. We would love any kind of clustering information we can get - even after the alerts are initially issued - that would reliably group together multiple alerts across geographic boundaries and different phases of an event.
Yes, that was the idea. However, the problem remains that in practice incidents aren't always atomic. Nor does an individual alert necessarily correlate to only one incident. What's more, in places where the Incident Command System or equivalent isn't universally applied (which is to say, in reality, almost everywhere) it's not unusual for the same incident to have multiple names/designators in different disciplines or different jurisdictions.
There's also a problem of motivation... does an alert originator see a benefit for them in adding this information (especially if it requires going back and updating?) Given the vanishing rarity of use of this field so far, that seems doubtful. Making things easier for indexers like Google doesn't appear to be a high priority for most alert issuers.
And ultimately there's the question of what "same incident" really means. Are multiple presentations of a disease separate events or all part of one event? Is a spot fire thrown off by a larger blaze the same incident or a different one? Ultimately these are administrative decisions made for administrative reasons, and they're coupled only loosely, if at all, to the alert authoring process.
This is a case where I'm thinking the obvious solution may be the best. Rather than rely on alert originators to make the connections for us, simply associate alerts that intersect or abut in space and time. That can be done downstream, automatically, and isn't contingent on whether the alert originators cooperate.
Conclusion at the July 21, 2014 CAP-SC was to remove the incidents field from the next version of the CAP spec.
Separately, https://issues.oasis-open.org/browse/EMERGENCY-30 has been opened to track a separate field for related alert linking.
Jacob provided some background discussion on how best to link related CAP alerts versus wider incident related information. Eliot Christian had questions about the intent of the incident identifier. What is an incident and how to reference it? Rob mentioned SitRep already provides some capability for incident linking. Elysa mentioned that the DE can also provide this capability. Jacob clarified the intent as being specific to CAP alerts and Eliot mentioned that the name of the element may need to be changed to make clear what is happening. Elysa asked about opening a new JIRA issue so that a new element could be introduced for related alert linking. Jacob clarified that issue 20's resolution would then be to remove incidents entirely to remove the concern about what incidents is being used for.
Need Jake for discussion for this. We also have an issue for this to change from free form to computer process version (see Issue 19). Original intent was to contain space delimited identifiers. Goes to difference between message and event (incident relates to event). Need to properly define these terms.