[OASIS Issue Tracker] (EMERGENCY-144) ETL: Re-written section 2.4

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/EMERGENCY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacob Westfall updated EMERGENCY-144:
-------------------------------------
    Resolution: Approved at Jun 18 2021 meeting

> ETL: Re-written section 2.4
> ---------------------------
>
>                 Key: EMERGENCY-144
>                 URL: https://issues.oasis-open.org/browse/EMERGENCY-144
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: EDXL-CAP 
>            Reporter: Jacob Westfall
>            Priority: Major
>              Labels: ETL
>
> Section 2.4 has been rewritten and here is the suggested new text:
> Â
> When an alerting authority identifies a hazardous or concerning event as a âsubjectâ event, it is helpful if the alerting authority and audience both have some prior understanding of the expected impacts of the event. That prior understanding comes from associating the subject event to a known event type. Defined event types assist in communicating to an audience the impacts of any single subject event.
> The OASIS CAP standard defines the <event> element asâ âthe text denoting the type of the subject event of the alert messageâ. This means that the authority is not actually citing the subject event in the <event> element, only its type. For example, a subject event like âhurricane Katrinaâ would have an event type classification of âhurricaneâ as hurricane is the term given to events with conditions characteristic of a hurricane.
> The full term in the context of this example is âhurricane event typeâ, where âtypeâ is the object of the sentence, âeventâ is a permanent adjunct modifier to âtypeâ, and âhurricaneâ is the actual event type being classified. Since the CAP standard established this element as âevent typeâ, there is no need to repeat the words âeventâ or âtypeâ in the list of types. NOTE: In the example, âhurricaneâ is also an adjunct describing the âevent typeâ.
> Using another example, the term âforest fireâ is also an acceptable event type for alerting. Here, there are two noun adjuncts used to describe a more narrowly defined âevent typeâ as opposed to using just âfireâ. Another example of an event type is âiceâ, and the more narrowly defined âthin iceâ. The word âthinâ however is a qualitative modifier and not an adjunct, and demonstrates the value that qualitative modifiers can occasionally bring to the task.
> Multi-word types operate equally well or even better than single-word types. For example, a single-word event type of âemergencyâ is not acceptable for comparison purposes. Consumers wanting to compare this with other event types would welcome additional modifiers. The EMTC has to evaluate each case and use or limit modifiers as needed. NOTE: multi-word event types generally have an accepted best order in English (i.e. âforest fireâ and âthin iceâ, as opposed to âfire forestâ and âice thinâ).
> Â



--
This message was sent by Atlassian Jira
(v8.3.3#803004)