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-144) ETL: Re-written section 2.4


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

Jacob Westfall updated EMERGENCY-144:
-------------------------------------
    Description: 
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â).

Â

  was:
Section 2.4 has been rewritten and here is the suggested new text:

Â

When constructing alerts, identifying subject events and event types is often not enough. Using meaningful terms for communicating hazardous or concerning impacts to an audience, is just as important. This is the social science of alerting and this is where the concept of an alert type arises.


An alert type is usually just the type of event transposed to also being the type of alert. For example, a âblizzard eventâ, of event type âblizzardâ, would often lead to a âblizzard alertâ of alert type âblizzardâ. Since an alert message requires a subject event to center the message on, it is natural to make this simple transposition of event types to alert types. This transposition activity holds true for other event type schemes as well (i.e. a âred eventâ becoming a âred alertâ, etc.).


However, the practice of setting an alert type for alerting authorities is just as inconsistent around the world as is setting event types. For example, a âhot dry weatherâ event, conducive to the possibility of bush fires, may result in alerts with alert types of âbushfire emergencyâ or âred flag warningâ. These two alert types are not necessarily understood to mean similar things â especially across different communities.


Regardless of what event terms are already in use, and what they might truly signify, the overall social aspect of an alerting service has been established. Furthermore, for this exampled case, it should be pointed out that the alert terms âemergencyâ and âwarningâ are not uncommon variations for the choice of term for an âalertâ, or is it actually meant to be a âbushfire emergency alertâ of type âbushfire emergencyâ. Nevertheless, the conclusion is that the practice of using terms for naming events and alerts can vary considerably making comparisons difficult.


Ultimately, public alerting is not meaningful if the message is not understood. Regardless of the term assigned to the event or alert, the social responsibility of an alerting authority is to effectively communicate the hazards and concerns associated to a subject event. In each case, representatives of the alerting authorities that chose these terms felt the chosen term was the correct one for the situation.


> 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)


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