OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (EMERGENCY-20) Change incidents format


    [ https://tools.oasis-open.org/issues/browse/EMERGENCY-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37624#comment-37624 ] 

Art Botterell commented on EMERGENCY-20:
----------------------------------------

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.


> Change incidents format
> -----------------------
>
>                 Key: EMERGENCY-20
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-20
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Tony Mancuso
>              Labels: CAP
>
> 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. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]