The OASIS EMTC (Emergency
Management Technical Committee of the Organization for the Advancement of
Structured Information Systems), has developed a list of “event” terms for use
in alert messaging systems. The list of terms attempts to help alert message
consumers put some consistency into an important piece of information found in
alert messages – the type of subject event.
A hazardous or concerning subject
event justifies why an alerting authority created an alert message in the first
place. It helps the authority anchor the information contained in the message to
a specific time and place for the message audience. The subject event is essential
to alert messages that use the OASIS CAP messaging standard.
The EMTC generated the
“event” terms list in response to concerns expressed by the Global Disaster
Preparedness Center (GDPC), a resource center hosted by the American Red Cross.
The GDPC raised concerns that the varied and free form usage of event terms is
inconsistent in CAP Services making it difficult to compare messages from
different originating sources. As consumers of alert messages, they found there
is no quick and definitive way to compare the language and meaning of the event
terms found in various CAP messages.
Understanding this, the EMTC
approach to the “event terms list” (referred to as the “list” in this document)
has been to focus on “how” the list can help when comparing event terms. The
design and management of the list is such that consumers of CAP messages,
looking to compare event terms from different originating sources, will have a
means to do so.
The EMTC also recognizes that
many alerting authorities have their own terms; and that these terms, some long
established, already work well in the communities they serve. Therefore, with
the advent of the list, it is not suggested that alerting authorities
change to using the OASIS event terms as listed, it is only suggested that the
originating CAP systems for those authorities make a reference to the terms
found in the list.
Understandably, the EMTC
defers to each and every alerting authority their choice of terms. Those
authorities have had many years to cultivate a relationship with their
audiences and the EMTC has no wish to change that. The goal of the EMTC list is
only to facilitate a more interoperable exchange of information to consuming
parties that process alert messages from many authorities. Interoperability
means that consumers, even those not associated with an alerting authority,
should also be able process the message information in a standard way. With
the methodology outlined in this document, the EMTC hopes this objective can be
accomplished. The OASIS EMTC is asking CAP originators and CAP consumers to
play a part in making this happen. Ultimately, OASIS hopes users like the GDPC
will see the benefits.
CAP is designed as a means to
convey alerting information associated to a hazardous or concerning event of
interest. It does this for the purposes of alerting audiences to the impacts of
that same event.
Identifying an event of
interest starts the process of creating an alert, with the event becoming the
subject of discussion for each message of the alert. In CAP-based alerting
systems, message originators employ CAP to house all the pieces of information
associated to that subject event. Consumers of CAP messages, those considered
partners to the alerting authorities, help disseminate and present that
information to the intended final audiences.
Before a discussion on
conveying event type information can be made, additional background is required
on a variety of concepts pertaining to the alerting information - including the
meaning of the terms “event” and “event type” as used in CAP.
An event is something that
happens in a given place during an interval of time. It is the recognition of
some activity that is a deviation from the normal state of things. An event
only becomes significant when affected parties observe, or are anticipated to
observe, some known measure of impact. On a very basic level, simply existing
is enough for an event to generate interest. On a more practical level,
authorities, with expertise on the nature of certain hazardous or concerning
events, may classify an event as significant based on the real or anticipated
impacts of the event.
In the case of “Public
Alerting”, alerting authorities determine whether the impacts of an “event of
interest” is concerning enough to issue a formal alert. This is their
responsibility; and they can do this consistently because they have built up a
pre-defined and deterministic cause for alarm based on a known set of
conditions of similar events. In this situation, the alerting authority has
assumed the role of defining the impacts of significance on behalf of the
public audience they serve. An event, based on those measures, becomes the
subject of an alert.
CAP consumers are aware that
some of the pieces of information within a CAP message are optional while some
of the information is required. The <event> element within a CAP message
is a required element. It is the only required element in a CAP message that by
definition is directly associated with the subject event. Unfortunately, this
has resulted in many CAP consumers attempting to rely on the element as a means
of comparing the subject events across messages.
However, the <event>
element is a free form text element meant to communicate with the final
audience and not meant for the automated systems to process. The only
constraint on <event> is that it be in the same language as indicated by
the <language> element of the <info> block - but even that
constraint is not easily validated. Therefore, for consumers such as the GDPC,
the ability to rely on this element as currently defined, for uses other than
display purposes, is not always possible.
Consequently, it is
understandable that some believe that the varied use of the <event>
element contradicts the concept of interoperability. One possible solution
might be to have originators standardize the use of the <event> element
to some standard list of values. However, it is the opinion of the EMTC, that
the <event> element in CAP should not be re-purposed for this task. The
<event> element has been established as an audience element and should
remain as such. The EMTC believes other existing CAP elements should be
employed to facilitate interoperability.
To “type” something is to
declare something as sharing similar characteristics to things that went before
it. If those characteristics create a classification, whether formally or
informally, then a “type” is declared. One can then use a type in a sentence
(i.e. “an object of type X”, or more commonly, “an X object”). This
understanding is the basis for how “typing” works in any system.
For example, using a term
like “apple pie”. The object of interest is a pie classified as being of type
apple (as compared to other pies). The same concept exists when using a term
like “hot pie”, the object of interest is still a pie but this time classified
as being of type hot.
Both typing schemes in this example
serve a purpose, but the type classification “apple” is more substantial than
the type classification “hot”, as “hot” is open to wider opinion and
interpretation. The difference extends from “apple” being a word that is able
to describe another thing (a noun), whereas the word “hot” does not. The word
“hot”, as used here, is simply a qualitative modifier (an adjective) that describes
some quality of the object. This distinction is important.
When a noun functions as a
type, like “apple” does in “apple pie”, it is referred to as a noun adjunct.
Noun adjuncts are not the object in a sentence and only serve to modify another
noun. Adjuncts as types generally make for easier type comparisons with other
types as opposed to adjectives. For example, “apple” compared to “berry”, is an
easier comparison to react to as opposed to “hot” when compared to “warm”.
Comparing adjectives is more subjective. Typing strategies focusing more on
noun adjuncts, and less on qualitative modifiers, often make comparisons easier
to interpret.
Furthermore, as an additional
advantage, noun adjuncts can have their own modifiers. For example, “red”,
which is a modifier for “apple”, leading to the combination “red apple”, which
is a more narrowly defined multi-word modifier for “pie”. Multi-word modifiers improve
the precision of types, but conversely can also grow in number if left
unchecked. Overuse can lead to lists too large to be manageable or effective.
This interpretation of type
will figure prominently in this document.
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”).
An alert is a transmitted
“signal” to heighten attention and/or initiate preparation for action. For
this attention and preparation to be meaningful, a real or anticipated subject event
is necessary. As stated, it is by reference to this subject event that the
alert ties the message found in the alert to a time and place.
For many alerting
authorities, an event, simply by its event type definition, is an alert-able
event. For example, a “dangerous animal” is an alert-able event simply because
of what its event type definition is. For other authorities, the event is only
significant and alert-able when a marked set of environmental conditions define
its type. For example, an authority may declare a “wind” event an alert-able
event based on a certain wind speed level marker. Regardless of how the need
for an alert was determined, the authority went through a subjective analysis
identifying event types of interest. All this so that the subject event for any
given alert message has a type classification that aids in constructing alert
messages for an audience.
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.
Since the inception of the
CAP standard, event term usage in the <event> element in CAP based
systems around the world has evolved to be wide ranging and varied. Alerting
authorities, and their CAP originators, have fallen to a number of differing
practices that makes comparisons of the <event> element values difficult.
The list below is not a complete list of these practices but does demonstrate
various interpretations and aspects of the larger problem of assigning an event
term in CAP.
The list below is not a
complete list but does demonstrate various practices and interpretations of the
larger problem of assigning an event term in CAP.
1)
The same event
can affect different communities differently. For example, a “smoke” event can
affect one community concerned with Air Quality and Health while at the same
time it can affect another community concerned with Transportation.
2)
The same event
can affect a national community in one way and a local community in other ways.
For example, a “forest fire” can affect logistical firefighting exercises on a
large scale but cause evacuation activities on a smaller scale.
3)
The same event
may be easy to describe in one language but not another. For example, the term
“AMBER alert” is well known in the English language but its direct translation
may not easily survive into another language.
4)
An event may be
composed of many smaller events and the communication of many smaller events
simultaneously may require the use of a broader term to get the message across.
For example, “storm surge”, “heavy rain”, “strong winds”, “coastal flooding”,
“tornadoes”, etc… may all be part of a “hurricane” event but an alert message
full of references to the many smaller events may not be effective as they
could overwhelm the audience. However, any of these smaller events occurring on
their own could easily make up the subject event of a separate alert.
5)
An event often
comes with descriptive modifiers that authorities have used for many years
based on a how the subject event was viewed in the past. The use of these
descriptors can create confusion especially when compared against the
established measures in the CAP standard. For example, a “thunderstorm” event
and a “severe thunderstorm” event. “Severe” is one of several allowable CAP
<severity> values used by agents to filter CAP alert messages, but if the
value is set to “Extreme” and the event is still termed as a “severe
thunderstorm” confusion can arise.
6)
An event may be
described differently in cause and effect situations. For example, an
“earthquake” event that spawns a possible “tsunami” event may result in
different originators referencing either event type in a CAP message. The alert
is conveying a “Tsunami Warning” for an anticipated “tsunami” event but the
cause event was the “earthquake” event. Alerting Authorities could focus on
one, or the other, or the combination of the two, as the subject event of the
CAP alert message
7)
An event may be
considered a trigger event by an alerting authority causing the authority to
issue an alert focusing on a secondary event that they themselves want to
initiate. For example, an “evacuation order” that contains a message that talks
about the act of evacuating, and may involve very little discussion to the
trigger event that spawned the order in the first place.
8)
An event may be
described by using a proxy term. For example, “red flag” is a term that can be
used to describe an event where a triggering weather event is underway that is
conducive to a secondary “fire” event occurring. Much like a “tsunami” event
prompted by an “earthquake” event, the possible “fire” event is prompted by an
existing “weather” event. However, in this case, the term “red flag” is a proxy
term generalizing the possibility of several “fire” events.
9)
Two event terms
may have the same core term but be quite different types. . For example, a
“bush fire” and a “chemical fire”. While related due to the core term “fire”,
they are actually quite different event terms only connected through the
broader term “fire”.
10)
The event term
wording may be a broader generalization than the actual intended meaning. For
example, “air quality” as a term should have a broader definition than what is
often implied as the more narrowly defined “poor air quality”. The repeated
usage of the term “air quality”, for the purposes of issuing alerts for “poor
air quality”, has led to a subtle training of the audience over time to
interpret “air quality” as “poor air quality”.
11)
An event term
choice may be subject to the behaviors and constraints of the presentation
systems in play. For example, the idea of keeping messages short for a
particular presentation medium, or only including a short attention-grabbing
<headline>. For example, “congestion ahead” designed specifically for an
electronic road sign.
12)
An event term may
appear as a plural form, or verb form, or another form, instead of a simple
noun. For example, an event type of “flood” may be expressed using terms such
as “floods” or “flooding”.
13) An event term may not even be associated to an event
at all. For example, “road”, “waste management”, etc… are terms that are not
events on their own, but when used as a noun adjunct ahead of another noun like
issue, situation, or service, the net result is an event term that is a very
broad description of an event, but still a type of event.
14) An event term choice may include a scale reference. For
example, a “UV index” event. UV is the actual concern and index is simply a
mis-directed proxy for the true event, which may be a period of “dangerous UV
radiation”.
Consequently, for an event
terms list to be manageable and useable for automated comparison purposes,
users of the list need to recognize that the EMTC list of terms is not able to
accommodate all these interpretations. The EMTC list of terms will be an ever-growing
list, but it will be a list of subject to a number of constraints to keep the
list manageable.
One strategy to help
automated systems that auto-process the delivery of the alert message to the
final audience is to codify values for certain pieces of information in the
message. Coded values, if formatted properly, can alleviate the dimension of
language as an issue to resolve when processing an alert. Applying a code to
each item in a list is desirable for automated systems and systems that deal
across languages.
Codifying event types is also
helpful for applying advanced processing in consuming alerting systems. For
example, a coded value for a pre-defined event type allows consumers to have a
pre-defined response to any alert message identifying to that event type. That
response could be for simple tasks such as routing or filtering or it could be
for more advanced tasks such as creating a unique presentation for a certain
type of event. In CAP, originators populating the <eventCode> element
help facilitate consuming responses by codifying event types.
A group is a collection of
participants that share a common trait. In the case of XML, a language based
messaging protocol, there are two basic user groups. One group is the final
intended audience (the end clients of the information contained within the XML
message), and the other is the partner group (the agents along the path of
distribution that source the XML for decision making information). Both these
groups are served by the same CAP-XML alert message.
There are elements in the CAP
schema that are intended for one group or the other. For example, many of the
free form elements in the CAP-XML schema are intended for the final audience,
while many of the enumerated elements are intended for agents along the path of
distribution. As stated, the <event> element is free form and conveys an
event type to the final audience. Conversely, the <eventCode> element is
a pre-determined element with managed values, and conveys an event type to
agents along the path of distribution, allowing them to set up something
specific in advance such as filtering or routing.
There is one additional
event-based decision-making element in CAP. Unfortunately, like <event>,
it does not come with much guidance on how to use it properly and existing
practices with this element are as varied as the <event> element itself.
Besides, it is a very general element and is not specific enough for consumers
to use for most event comparison purposes. This element is the <category>
element.
Like the <event>
element, the CAP standard defines a <category> element to broadly
categorize subject events referenced in CAP messages. The <category>
element is a required element with a set of pre-defined values. Automated
processing on the consumer side could potentially use <category> to
filter to some sort of subset list of events of interest. Unfortunately however,
consumers have to rely on the originators upstream to set the values
appropriately and consistently if interoperability is the goal.
Furthermore, originators often
just include one <category> for the hazardous or concerning event of
interest in a CAP message, and that assignment usually just aligns with the
jurisdiction of the alerting authority. This defeats the purpose of
<category>. For example, an alert issued for a “volcanic ash” event may
have a <category> assignment of only “Health” if a health agency issued
the alert, whereas it may have a <category> assignment of only “Met” if a
meteorological agency issued the alert. The recommended use of <category>
is to have multiple instances of the <category> element present in the
CAP message - one instance for each category that applies. The CAP consumer
could then reliably use a filter to look for the categories that interest them
and then just present the <event> value as is to the intended audience.
If an alerting authority added a new event type to their list of alert-able
events, a consumer could build a system filtered to <category> and not
miss any new type of alert that the authority added.
OASIS is not intending to promote
<category> as a solution to the <event> issue stated in the outset
of this document, but understanding <category> and its traits, as
compared to <event>, will help us address the event issue. The two
important traits are re-listed here.
1) <category> is allowed to have
multiple instances of the element in a single CAP message. Therefore, CAP does
not constrain subject events to being in only one category. The <event>
element however is constrained to one value.
2) <category> is a pre-set broad
categorization, not enough to inform on the full nature of the event.
Therefore, consumers can use it to filter alerts only at the broad scale. The
<event> element as broad or narrow as needed for the audience of interest
These two differences figure
in the methodology to solve the event type comparison issue discussed in this
document.
As mentioned earlier, the
social aspect of alerting is a primary concern for alerting authorities. The
chosen terms used in an alert message exist for the purposes of communicating
effectively with an audience. However, when inspecting the terms used across
various systems, not surprisingly, a wide range of terms are used. Upon further
inspection, the terms are not just similar terms for the same thing, but terms
that span a wide range across one or more spectra of terms. This happens both
at the event level and the alert level and even authorities themselves
sometimes have a hard time interpreting one another’s choice of terms.
The following is discussion
on terms across spectrums. This will factor into the decisions made regarding
what event terms may make it into the list.
Terms can be very specific or
very general depending on the information that needs to be conveyed. This is
especially true for public alerting. For example, usually the term used for an event
is often the same term used for the alert (i.e. a “wind” event leading to a
“wind warning”). However, some alerting authorities generalize the type of
alert by using broader terms (i.e. a “wind” event leading to a “wind” alert). Alerting
authorities may choose to broaden the chosen event and alert terms for many
reasons. For example, these include, but are not limited to…
-
alerting for fast changing
situations, where the event type is subject to change in updated messages over
time (i.e. a “rain” event, changing to a “sleet” event, changing to a “snow”
event and then back again, can be collectively referred to as a “winter storm”
event)
-
alerting to reduce message fatigue
and confusion of an audience, where the audience might otherwise be subjected
to different event terms for similar events
Furthermore, if a combination
of events tends to occur at the same time due to the connected nature of the
events, alerting authorities often use broader terms used as a catchall for the
individual events (i.e. a “wind” event, plus a “rain” event, plus a “storm
surge” event all associated to a “tropical storm” event). From any one physical
location, for a segment of the audience affected by all these individual
events, the event term “tropical storm” makes sense as a catchall term for the
alert message. However, for a segment of the audience affected by only a subset
of the events, such as those on higher ground, should they be subjected to the messaging of the “storm surge” component of the
catchall term?
The example below shows a
simple example of “wind” that includes the CAP category “Met”.
An authority could elect to
use the broad event term “weather” or the narrow term “small craft wind” when
naming an event. For example, the following combination of CAP elements is
possible
<event> = “weather”
<category> = “Met”
as well as…
<event> = “wind”
<category> = “Met”
or even…
<event> = “small craft wind”
<category> = “Met”
and so on.
Additionally, reference terms
can appear on more than one broad to narrow spectrum. This is one area where
the <category> discussion above is relevant. For example, using the
“smoke” example from earlier, smoke is a broad term that one can narrow to
“dense smoke”, affecting Transportation, or “chemical smoke”, affecting Air
Quality and Health.
The impacts of a “smoke event”
could be associated to two different CAP <category> values, “Health” and
“Transport”. In this case, the broad term would need more context if there were
a consumer that wants to filter for alert messages in just one of either
category.
Furthermore, if the “dense
smoke” is from a chemical fire, and the alerting authority is issuing an alert
for this smoke with both the Health and Transport communities in mind, do they
issue two alerts or one? Do they issue a general alert message discussing
impacts of both, or two alert messages discussing the impacts in each category
knowing there may be a separate audience for each category?
Practices are many and varied
and often go to how the authority conveys the impacts in the message. OASIS has
no jurisdiction over such alerting practices leaving that up to the authorities
themselves, but the practices affect the terms used.
Alerts can be used to alert
audiences to events of interest that have happened, are presently happening, or
are expected to happen in the future. If an event is moving, such as a “storm”,
it can be considered happening now to some and happening in the future to
others. Furthermore, if an event is only anticipated to happen, it may end up
not happening if the conditions leading up to the event change before the anticipated
event happens. All this can affect the chosen terms used to describe an event
across the time spectrum.
Consider for a moment a term
like “forest fire”. Since a forest fire is an event by its nature, something
that deviates from the normal condition of no fire, the term “forest fire” is
an acceptable event type term. However, if an authority wants to define forest
fire types for both “existing” forest fires, and “future” forest fires, how is
that accomplished? Terms such as “forest fire situation” or “forest fire
threat” come to mind, along with many others similar terms. When inspecting
these choice of terms, a sense of timing can be inferred by the additional word
in the term. The word “situation” suggests a current event and the word
“threat” suggests a future event. For completeness, a word like “incident”
could be used for a past event.
An important observation for
terms like… incident, situation, threat, etc…is that these terms on their own without
a modifier can convey the idea of an event (i.e. a simple message stating,
“there is a threat” refers to a “threat” as the subject event). Such events are
abstract, as opposed to real, but abstract events do not contravene the idea of
a subject event.
When it comes to typing
abstract events in CAP, the word “threat” is still a noun. As a noun adjunct to
the base word event, it too may also be typed. Using the example above, the net
result could be a multi-word event of type “fire threat”, or the even more
narrowly defined “forest fire threat”.
The term “threat event”, does
not provide anything helpful on its own for comparison purposes other than
timing. Furthermore, if a qualitative modifier is used, such as “strong
threat”, it still does not provide anything helpful for comparison purposes.
Abstract events, like timing spectrum events, are best served with another
adjunct as a modifier instead of qualifying modifiers. With “fire threat”,
there is both tangible information on the hazardous or concerning event plus
information on the timing.
One advantage of adding
timing spectrum words to the term is that they aid in pre-planning shorter
audience messages when length of message is a concern. Another advantage is
that the noun adjunct for words like threat, situation, incident, etc… does not
necessarily have to convey a sense of an event because threat, situation,
incident, etc… already do.
Alerts can be used to alert
audiences to events of interest that have impacts that are minor, major, or
anywhere in between. Often, the desire of many alerting authorities is to
express that degree of impact quickly and succinctly as possible. In CAP, this
is what the <headline> element is designed for; however, another way to
do this is to encapsulate the degree of impact into the event type term. If an event
type has an additional adjunct in the term that infers some sense of impact,
such as “concern”, “problem”, “issue”, “hazard”, “emergency”, etc… then simply
presenting the event type may be enough to get enough of the message across in
presentation mediums where succinctness is key. 
Much
like time-based terms, impact-based terms on their own are abstract. They
convey the idea of an event and do not contravene the idea of a subject event
in a CAP message. Impact-based terms come with the same advantages of
time-based terms. For example, a “beach hazard” is an acceptable event type
when “beach” on its own is vague for comparison purposes. Even the implied full
event term “beach event” is vague - it really only answers the question of
where, as opposed to what. Adding in the impact term “hazard”, as in “beach
hazard” (or “beach hazard event” - as implied) makes the term much more helpful.
On occasion, alerting
authorities use alerts to engage an audience to take action as a secondary
event in response to some primary triggering event. The action requested by the
alerting authority can range from monitoring for more information; evacuating
the area; sheltering in place; or engaging in specific actions intended for the
well-being of the individual or community. These secondary events may be simple
recommendations or mandated orders to do something specific.
The COVID-19 pandemic
re-acquainted world to “stay-at-home order” alerts. These alerts were becoming
common during the pandemic and alerting authorities were becoming very
prescriptive in their alert naming to get the message across. Rather than
issuing hundreds of alerts, all referred to as “COVID-19” alerts or “infectious
disease” alerts, authorities altered the wording and named the alerts to such
things as “stay-at-home order” and “fake vaccine warning”. As an alert type,
their names directed the audience to the secondary event cited.
The corresponding event type could still easily be “infectious disease”, but a
modified situation occurs where authorities are instead inspired to cite the
secondary event as the event type, but that argument is a based on the
mis-conception that the event type and alert type should be the same thing.
Other action spectrum
examples are “advisory”, as with “travel advisory”, “alert” as with “AMBER
alert”, “orders” as with “boil water order” and “evacuation order”, etc… Even
“warning” as with “weather warning” is an example of this. In this latter
example, the word “weather” is an adjunct to warning, meaning the event of
interest is the warning itself and the audience engagement of the information
they have just received, not the real or anticipated weather that triggered the
alert.
The term “AMBER Alert” is an
alert type created to heighten the awareness of the secondary response event
that involves the participation of the audience. There is no actual secondary
event unless some or all of the audience takes part. NOTE: AMBER is an acronym
for “America’s Missing: Broadcast Emergency Response” where the idea is to
illicit a response by the audience. The word “alert” is added to distinguish
the acronym from the color amber if heard or seen in a message.
The recommended approach in
CAP for secondary action events is to keep the <eventCode> element tied
to the triggering event for comparison purposes; use the <headline>
element for the alert type referencing the secondary event; and use either
option for the <event> element as preferred by the alerting authority.
Using the examples above, the text snippet “stay-at-home order” or “AMBER
Alert” would appear as part of the <headline>, with the “infectious
disease” code or “missing persons” code indicated in the <eventCode>
element. As for the <event> element, either “stay-at-home order” and
“AMBER Alert” as references to the secondary event, or “infectious disease” and
“missing person” as references to the triggering event.
Spectrums can intersect. This
becomes important when trying to compare terms from across spectrums. For
example, if one alert message uses an event term, that includes a narrow time modifying
term; and another alert message uses a broad impact modifying term, how
difficult is it for automated systems to compare the two terms? For example, an
event type term like “weather threat” as compared to an event type term like “hurricane
emergency”.
Furthermore, there are subject
events where the individual event type terms incorporate concepts from two different
spectrums (i.e. “fire threat emergency”). When intersecting spectrums are used,
it increases the difficulty of comparing terms across messages.
Bearing in mind the previous discussions,
a sub-committee of the EMTC has attempted to compile a reference list of event
type terms that alerting authorities and originators can use or reference in
CAP alert messages. The concept of a term being part of a spectra of terms was
established. The EMTC will use the concept as a way to help facilitate the
ongoing task of incorporating and managing new terms over time. Users of the
list will not necessarily have to be familiar with the spectrum concept, but it
will help. Contributors to the list will hopefully have a better understanding
of how their submission is being treated if they understand the spectrum
concept.
A spectrum, in the context
used here, where a grouping of terms is brought together under one defined
range, provides a means of comparing terms. With that, a number of concepts
arise with respect to spectrums. They are introduced and discussed below.
Identifying a Spectrum begins
with identifying a primary term (i.e. wind) and a broad term (i.e.
Meteorological) and pairing them together to establish a range. The primary
term needs to be an adjunct (another thing) otherwise the spectrum does not
have a basis for comparison. The broad term will come from the list of CAP
categories where the CAP category term applies. For example, “wind” is paired
with “meteorological” creating one spectrum, whereas, “wind” is not paired with
“security” as no identified pairing term is known at this time. NOTE: The CAP
category CBRNE is broken up into its five constituent components for this
exercise. The secondary event category “rescue” is fine for a broad-spectrum
end point as a “rescue issue” is interpreted to mean an issue came up during a
rescue event unrelated to the trigger event (i.e. “suspended search”)
For every event term, there
are other related event terms that others may feel are better terms to use.
This is of course a matter of opinion, but in a spectrum approach the EMTC can
show a given term as relatable to other terms simply by being in the same
spectrum. For example, if a reference term falls onto one or more broad to
narrow spectrums, all terms on those spectra are considered related terms.
How narrow (or specific) do
event terms need to be? For example, a term for every intensity rating on the
Enhanced Fujita Scale (EF0 to EF5), each based on the likely damage expected
with a tornado event, could arguably help consumers better understand the
threat. However, would the majority of agents along the public alerting path
of distribution use the distinction? Unlikely.
If an <eventCode>
existed for each narrow term, the audience experience could be enhanced as the
narrower term increases the precision of the message. However, it is usually
only a smaller subset of the audience that has a need for such specificity.
In the tornado example given,
the term is actually the code itself (i.e. “EF0”). However, for other scales,
such as a marine scale for wind speeds where a modifying term is used (i.e.
small craft wind = 15-19 knots, strong wind = 20-33 knots, gales = 34-47 knots,
etc…), the discussion remains relevant.
In such cases the EMTC
purposely does not venture into the very narrow edge of the spectrum. The
feeling is that the general public would be better served, as with the first
example, by the event term “tornado”, or in the second example, by the event
term “wind”. For those looking for more specificity of scale, the “Other Lists”
section below does offer up a complimentary solution that CAP can easily
accommodate.
Preferred terms, within a
spectrum of terms, is a matter of opinion. The EMTC will not concern itself
with choosing a preferred term. Alerting authorities are free to choose their
preferred term when considering their audiences. The list however makes it
possible to compare the terms used with other terms preferred by other
authorities.
Other language terms are
considered to be in the same spectrum. Spectrums are language independent. If a
term is used in one identified language, and it has an equivalent term in
another identified language, it is a related term. Filters by language can be
used to when working in one language (viewing the list), or when using the list
to translate from one language to another (processing CAP with the help of the
list).
Other word forms of a term
introduce other possible spectrums to consider. Plural forms, verb forms,
ideological forms, etc..., all add extra meaning to a term. For example,
“floods”, “flooding”, and “flooded” all add context to the term flood. As a
type however, they do not add to the base term flood. Additionally, the base term
flood does not preclude the notion of multiple floods; nor does it imply the
state of the flood during the event. These variations do not serve any benefit
when comparing events except in exceptional cases. The EMTC is creating a list
of event types for general comparisons, not exceptional cases.
CAP has the facility to house
term references from more than one list in any single CAP message. The
<eventCode> element is a multi-instanced element in CAP, specifically
defined to allow for codes from many different lists to be simultaneously
incorporated into a message. For that reason, the EMTC has decided not to
include terms and codes based on preferences or specificity of scale, leaving
that exercise up to sub-communities of users to define their own lists.
Any such community is welcome
to define and publish additional event term codes. Those additional codes, if
necessary, can easily cover the narrow edge of the broad to narrow spectrum.
For an alert message that goes out to a multitude of consumers, serving both
specific and general audiences, an additional event code could convey the
preferred or specific details to subset
audiences and the EMTC code could convey general details to general audiences.
As mentioned in the outset,
the EMTC has developed a list of “event” terms for use in alert messaging
systems. There was no shortage of challenges with this initiative. Determining
how to build and structure the list first meant understanding the bulk of the
problems the list was intended to solve. Also, stewards of the list, as well as
users of the list, would each have their own objectives when working with the
list. Furthermore, how to apply and present the list afterwards to all users
was also difficult since many existing alerting practices are already underway
and had to be accommodated for in the methods chosen.
For users, the EMTC list was developed to be open-ended. An
open-ended approach is considered evergreen – the resulting material retains
its relevance by growing continuously to meet the needs of a community. For the
sub-committee, managing an open-ended reference list, where new terms can be
submitted over time, is possible, but only when a solid evaluation process for
upkeep is established. This is possible with the concept of spectrums.
Secondly, strategies such as
a thesaurus approach emerge. With a thesaurus approach, each term is related to
other similar terms and by selecting one term, other similar or related terms
can be found using the various spectra the term can be found in. The thesaurus
then leads the user down a path where the user can choose for themselves the
best term as they deem appropriate for the situation. Through the spectrum
approach, the EMTC will be able to list related terms for any given reference
term when using a thesaurus.
For consumers of CAP, the <event> element is free form, and
consumer systems should already be accepting free form values for this element.
The consuming systems should not require any refactoring if the terms from the
EMTC list start to appear in CAP messages. This of course assumes consumers use
the <event> element for what it was intended – as a display element only.
Secondly, for consumers that
want more – that want the ability to auto-process and compare event types across
systems and platforms – the EMTC is suggesting an alternative procedure
requiring the cooperation of CAP originators and consumers alike. The EMTC is
asking originators to populate at least one instance of the <eventCode>
element with a code value from the EMTC list – the value that most closely
represents the event type used by the alerting authority. For example, if the
alerting authority has an established event term, and it closely mirrors an
EMTC term, the following should be placed into any associated CAP alert message.
<eventCode>
<valueName>OET:v1.0</valueName>”
<value>OET-537</value> --a coded value of the closest
EMTC event term
</eventCode>
If a term does not closely
resemble any EMTC term, then following should be used.
<eventCode>
<valueName>OET:v1.0</valueName>”
<value>OET-000</value> --a coded value for the EMTC
event term “other event”
</eventCode>
For alerting authorities, if one does not already have their own list, one may
freely use the terms from the EMTC list. If one already has their own event
terms list, the EMTC requests a mapping of those terms to equivalent terms in
the EMTC list by the alerting authorities and CAP originators when generating
an alert message (as exampled above). The sub-committee will periodically
expand the list and release updated versions.
Secondly, the EMTC is also
asking authorities to submit terms for inclusion into the list. As mentioned, the
sub-committee will periodically expand the list but will only do so acting as a
custodian of the list rather than the subject matter experts for the terms on
the list. If there is a situation where the “other issue” coded value is used
in a CAP alert message, then the native event type used in that message is a
candidate for inclusion on the EMTC list going forward.
The following is the general
procedure used when considering a new term for inclusion into the list.
-
A submitting agency
identifies an event term for submission
-
The submitting
agency identifies one or more CAP categories for the event term (to set the
broad edge of the spectrums of interest)
-
The EMTC assesses
whether it is truly an event type term or not (based on the earlier
discussions)
-
The EMTC assesses
whether it truly fits the spectrums or not
-
Once accepted the
term will be added to the list
o It will be roughly ordered within the
indicated broad to narrow spectra
o It will be assigned a new EMTC event
term code if it has no sibling term
o It will be assigned an existing EMTC
event term code if it has a sibling term
-
All other terms
in the associated spectra will be considered related terms
-
Suggestions for
other language terms will be accepted and added
o Equivalent other language terms will
be considered sibling terms
The sub-committee will only
review the terms as indicated above. For that, we need the help of the
submitting agency - either the alerting authority itself or an agency on behalf
of an alerting authority.
The list below demonstrates
what OASIS will accept…
1)
event type terms
that convey a sense of time and space.
2)
event type terms
that fall within a broad to narrow spectra of terms.
3)
multiple event
type terms in different languages for a single event type.
4)
event type terms
that are used to service multiple user communities, regardless of the number of
authorities it affects.
5)
event type terms
that are regional event terms (i.e. “monsoon”).
6)
event type terms
that are proxy terms (i.e. “AMBER Alert”), if the proxy term is well associated
to an event type.
7)
event type terms
that are multi-word terms (i.e. “falling object”) where the multi-words are
needed to convey the concept of an event.
8)
event type
terms that collectively subsume a number of smaller events (i.e. “tropical
storm” which may subsume “wind”, “rain”, “high seas”, “flood”, etc…).
9)
event type terms
that are secondary event terms when the secondary event is truly the subject
event (e.g., “boil water advisory”, “evacuation order” or “AMBER alert”). The
secondary event is what the alerting authority is truly directing the attention
of the audience (for AMBER Alert, that secondary event is the search for the
missing child, as opposed to the original abduction event that triggered the
AMBER Alert).
10)
new spectrum
mappings to existing terms (i.e., adding terms to other spectrums).
The list below is not a
complete list of ideas applicable to the process of not accepting event
terms, as new ideas may emerge, but the list does example what OASIS will not
accept…
1)
terms not
associated to an event on their own (i.e., “terrorism).
The term “terrorism” is not associated to an event, as
it is an ideology. Consequently, the implied full term “terrorism event” does
not even suggest a CAP category as it could be any of them making it difficult
for comparison purposes of events. NOTE: “terrorist incident” is in the event
terms list as an event type as it suggests a CAP category of “Safety”. NOTE:
This explanation is not necessarily directly applicable to all languages;
however, the intent still applies.
2)
terms that are
actually secondary event terms that are often mistaken as a primary event term.
(i.e. “thunderstorm warning”).
The term “thunderstorm warning” is a secondary event
term that refers to the act of responding to a warning, not the real or
anticipated presence of a thunderstorm event itself. With all possible
secondary event terms making a long list of terms, it makes it difficult to
manage a list of terms for comparison purposes. Furthermore, such secondary
events are not what the CAP elements, <severity>, <onset>, etc.
were designed to address, although many authorities just use a value
representative of the primary event. However, in this case, the primary term
“thunderstorm” will suffice as it makes comparisons and list management easier.
3)
terms that are
multi-word terms that use a modifier to classify an event by scale rather than
distinguish the event from another event by its nature (i.e., “gale force
winds” and “hurricane force winds” are derived terms based on a level marker).
However, the terms “chemical fire” and “forest fire” would be accepted
separately as the nature of the two events are quite different. Therefore, the
terms “gale force wind” and “hurricane force wind” are not considered for the
OASIS event terms list, but the term “wind” is acceptable. NOTE: Communities,
such as marine based communities, are welcome to establish a set of terms and
codes for scale based terms with the recommendation that those generally
narrower terms be mapped to the closest more general OASIS term (and associated
event code). Originators of CAP messages for these events are asked to include
a reference to the OASIS event code in one instance of the multi-instanced CAP
<eventCode> element.
4)
terms that are
multi-word terms where the modifier is a general reference to a scale. For
example, “UV index”, which has an implied level marker scheme based on the word
“index” but by its presence in an alert message implies an event out of the
ordinary. Therefore, the term “UV index” is not considered acceptable for the
list, but the term “UV” is.
5)
proxy terms that
are otherwise not event terms (i.e., “red”).
Red is not an event on its own, it is a quality tied
to an impact scale. “Red” may be used by the authority in the <headline>,
<description>, <parameter> or other elements as an alerting
authority based preferred term but as an event these terms do not convey the
idea of an event and make comparisons difficult. Multi-word terms that try to
make an event out of a proxy event (i.e., “red issue”) are also not accepted,
as this assumes a scale-based term. Turning the proxy term into an event in
this manner provides no context to the term event as the definition of red on
its own is a color. NOTE: Communities, such as public alerting based
communities, are welcome to establish a set of color based terms and codes,
however, originators of CAP messages are asked to also include a reference to
the OASIS event code in one instance of the multi-instanced CAP
<eventCode> element based on the actual event.
6)
terms tailored
for a specific dissemination channel or display medium (i.e. “congestion
ahead”).
Channel based terms are often
tailored and leave out details. For example, an electronic road sign that says
“congestion ahead” assumes the audience understands the context of viewing the
message while driving. Such messages are actually private messages, built for a
specific channel; the information is still public, only the tailoring is
private. Without the context of the display medium, the event type becomes
vague and difficult for comparison activities.
7)
terms that are
plural, verb, or other word forms of an event term (i.e. “floods”, “flooding”,
“flooded”, etc…).
Unless the natural form of the term is in one of these
forms, “floods”, “flooding” and “flooded” do not imply anything more as an
event type than does just the word flood. Flood is actually more versatile as a
corresponding alert type as the alert can pertain to all these variations. The
various forms of the word flood are free to be used in other event typing
schemes; however, the EMTC list will constrain such entries to its base form.
The CAP Subcommittee is Chaired by Jacob Westfall who has led
the committee in the development of this Committee Note. The tireless efforts
of Norm Paulsen supported by lead editor Rex Brooks and Scott Roberson have
made this document possible. The following individuals have participated in
the subcommittee creating this specification and are gratefully acknowledged:
Jacob Westfall Individual
Rex Brooks Individual
Mike Gerber NOAA/NWS
Elysa Jones Individual
Don Mason IEM
Norm Paulsen Environment Canada
Mark Wood Disaster Relief
Communications Foundation
Herbert White NOAA/NWS
Chris Chiesa Pacific Disaster Center
Steve Hakusa Google Inc.
Gary Ham Individual
Andrea Hardy NOAA/NWS
Scott Robertson Kaiser Permanente
Andreas Schaffhauser EUMETNET
Sabrina Weber IEM
A.1 Special Thanks
The Committee would like to acknowledge the assistance
provided to the initial work of the CN from:
Frank Bell Kybernetix
The Committee would like to acknowledge the assistance
provided to the initial work of the CN from the Subject Matter Experts (SMEs)
who attended the two Special SME Sessions held by the CAP SubCommittee.
A.2 TC Participants
The following individuals were members of the EMTC during the
creation of this document and their oversight and guidance are gratefully
acknowledged:
Elysa Jones Individual
Gary Ham Individual
Mark Wood Disaster Relief Communications
Foundation
Rex Brooks Individual
Toby Considine University of North Carolina at
Chapel Hill
William Cox Individual
Thomas Ferrentino Individual
Mike Gerber NOAA/NWS
Steve Hakusa Google Inc.
Andrea Hardy NOAA/NWS
Alfred Kenyon DHS Office of Cybersecurity and
Communications
Mark Lucero DHS Office of Cybersecurity and
Communications
Don Mason IEM
Thomas Merkle DHS Office of Cybersecurity and
Communications
Joel Myhre Pacific Disaster Center
Norm Paulsen Environment Canada
Scott Robertson Kaiser Permanente
Andreas Schaffhauser EUMETNET
Jeff Waters US Department of Defense
(DoD)
Sabrina Weber IEM
Jacob Westfall Individual
Herbert White NOAA/NWS
The OASIS event
code value is for use in the cap.alertInfo.eventCode.value element
Note: “OET”
represents “OASIS Event Term”
The version of
the OASIS Event Terms list that the OASIS event code is taken from is indicated
in the cap.alertInfo.eventCode.valueName element.
Note: It is of
the form "OET:m.n", where "m.n" is the
major.minor version of this document.
The OASIS event
term is for use in the cap.alertInfo.event element
Note: The OASIS
Event Term is supporting material for comparison purposes and for systems that
have no Event term list.
The
"Grouping" column is used to indicate other CAP Event terms which are
related.
Note:
Most often, the grouping term is a broad grouping term on the broad to narrow
spectrum, where the term on the row is a more specific term on the same
spectrum. The Grouping term can lead to other related terms if the given Event
term "doesn't quite fit" the situation.
The CAP
Category Code(s) value is for use in the cap.alertInfo.category element
Note: The
"CAP Category Code(s)" column, lists the known CAP Categories the
OASIS Event term is associated, and OASIS recommends all values listed should
be included in the multi-instanced cap.alertInfo.category element in a CAP
message.
|
OASIS Event Code
|
OASIS Event Term
|
Grouping
|
CAP Category Code(s)
|
|
OET-000
|
other
|
other
|
Other
|
|
OET-001
|
accumulating
ice
|
safety
|
Safety;
Transport
|
|
OET-002
|
active
shooter
|
criminal
activity
|
Safety;
Security
|
|
OET-003
|
administrative
action
|
testing &
system activity
|
Other
|
|
OET-004
|
air
hazard
|
aviation
hazard
|
Meteorological;
Transport
|
|
OET-005
|
poor air
quality
|
health hazard
|
Environmental;
Health
|
|
OET-006
|
stagnant
air
|
air
hazard
|
Meteorological
|
|
OET-007
|
aircraft
crash
|
aviation
hazard
|
Transport
|
|
OET-008
|
aircraft
incident
|
aviation
hazard
|
Transport
|
|
OET-009
|
airport
closure
|
aviation
hazard
|
Transport
|
|
OET-010
|
airspace
closure
|
aviation
hazard
|
Transport
|
|
OET-011
|
airspace
restriction
|
aviation
hazard
|
Transport
|
|
OET-012
|
ambulance
|
health
issue
|
Health
|
|
OET-013
|
animal
disease
|
health issue
|
Health
|
|
OET-014
|
animal
feed
|
health
issue
|
Health
|
|
OET-015
|
animal health
|
health issue
|
Health
|
|
OET-016
|
arctic
outflow
|
temperature
hazard
|
Meteorological
|
|
OET-017
|
ashfall
|
air hazard;
marine; aviation
|
Geological;
Health; Meteorological; Safety; Transport
|
|
OET-018
|
avalanche
|
|
Geological
|
|
OET-019
|
aviation
hazard
|
aviation
hazard
|
Transport
|
|
OET-020
|
aviation
security
|
aviation
hazard
|
Transport;
Security
|
|
OET-021
|
beach hazard
|
marine
|
Safety
|
|
OET-022
|
biological
|
biological
hazard
|
CBRNE
|
|
OET-023
|
blizzard
|
winter
weather
|
Meteorological
|
|
OET-024
|
blood
supply
|
health
issue
|
Health
|
|
OET-025
|
blowing dust
|
air hazard
|
Meteorological
|
|
OET-026
|
blowing
snow
|
winter
weather
|
Meteorological
|
|
OET-027
|
blue-green
algae
|
water hazard
|
Environmental
|
|
OET-028
|
bomb
threat
|
criminal
activity
|
CBRNE
|
|
OET-029
|
bridge
closure
|
road hazard
|
Transport
|
|
OET-030
|
bridge
collapse
|
road
hazard
|
Transport
|
|
OET-031
|
building
collapse
|
infrastructure
issue
|
Infrastructure
|
|
OET-032
|
building
structure hazard
|
earthquake
|
Geological
|
|
OET-033
|
bush fire
|
fire
|
Fire
|
|
OET-034
|
cable
service issue
|
utility
issue
|
Infrastructure
|
|
OET-035
|
canal issue
|
utility issue
|
Infrastructure
|
|
OET-036
|
chemical
fire
|
fire
|
CBRNE;
Fire
|
|
OET-037
|
chemical
hazard
|
|
CBRNE
|
|
OET-038
|
chemical
smoke
|
|
Health;
CBRNE
|
|
OET-039
|
child
abduction
|
criminal
activity
|
Safety;
Security
|
|
OET-040
|
Civil
issue
|
civil
issue
|
Security
|
|
OET-041
|
civil protest
|
civil issue
|
Safety
|
|
OET-042
|
coal
gas
|
utility
issue
|
Infrastructure
|
|
OET-043
|
coastal flood
|
flood
|
Meteorological
|
|
OET-044
|
cold
|
temperature
hazard
|
Meteorological
|
|
OET-045
|
cold weather
|
winter
weather
|
Meteorological
|
|
OET-046
|
communications
service disruption
|
utility
issue
|
Infrastructure
|
|
OET-047
|
contagious
disease
|
health hazard
|
Health
|
|
OET-048
|
contaminated
water
|
health
hazard
|
Health
|
|
OET-049
|
contamination
|
|
CBRNE; Health
|
|
OET-050
|
criminal
activity
|
criminal
activity
|
Safety
|
|
OET-051
|
cybercrime
threat
|
criminal
activity
|
Safety;
Security
|
|
OET-052
|
cyclone
|
tropical
storm
|
Meteorological
|
|
OET-053
|
dam break
|
flood
|
Geological; Meteorological
|
|
OET-054
|
dam
issue
|
infrastructure
issue
|
Infrastructure
|
|
OET-055
|
dangerous
animal
|
civil issue
|
Safety
|
|
OET-056
|
dangerous
person threat
|
criminal
activity
|
Safety
|
|
OET-057
|
debris flow
|
geophysical
|
Geological
|
|
OET-058
|
demonstration
|
testing
& system activity
|
Other
|
|
OET-059
|
dense fog
|
air hazard
|
Meteorological
|
|
OET-060
|
dense
smoke
|
air
hazard
|
Meteorological
|
|
OET-061
|
diesel fuel
issue
|
utility issue
|
Infrastructure
|
|
OET-062
|
disease
|
health
issue
|
Health
|
|
OET-063
|
disease
outbreak
|
health issue
|
Health
|
|
OET-064
|
drought
|
weather
|
Meteorological
|
|
OET-065
|
drug safety
issue
|
public health
|
Health
|
|
OET-066
|
drug
supply issue
|
public
health
|
Health
|
|
OET-067
|
dust storm
|
air hazard
|
Meteorological
|
|
OET-068
|
dyke
break
|
flood
|
Meteorological
|
|
OET-069
|
earthquake
|
earthquake
|
Geological
|
|
OET-070
|
electronic
infrastructure issue
|
infrastructure
issue
|
Infrastructure
|
|
OET-071
|
emergency
responder incident
|
criminal
activity
|
Safety
|
|
OET-072
|
emergency
responder threat
|
criminal
activity
|
Safety
|
|
OET-073
|
emergency
support facilities incident
|
infrastructure
issue
|
Infrastructure
|
|
OET-074
|
emergency
support services incident
|
infrastructure
issue
|
Infrastructure
|
|
OET-075
|
emergency
telephone outage
|
infrastructure
issue
|
Infrastructure
|
|
OET-076
|
environmental
issue
|
environment
|
Environmental
|
|
OET-077
|
explosion
threat
|
civil issue
|
CBRNE
|
|
OET-078
|
falling
object
|
safety
hazard
|
Safety
|
|
OET-079
|
fire
|
fire
|
Fire
|
|
OET-080
|
flash
flood
|
flood
|
Meteorological
|
|
OET-081
|
flash freeze
|
winter
weather
|
Meteorological
|
|
OET-082
|
flood
|
flood
|
Meteorological
|
|
OET-083
|
fog
|
air hazard;
winter weather
|
Meteorological
|
|
OET-084
|
food
contamination
|
biological
hazard
|
Health
|
|
OET-085
|
food safety
issue
|
public health
|
Health
|
|
OET-086
|
food
supply issue
|
public
health
|
Health
|
|
OET-087
|
forest fire
|
fire
|
Fire
|
|
OET-088
|
freeze
|
winter
weather
|
Meteorological
|
|
OET-089
|
freezing
drizzle
|
winter
weather
|
Meteorological
|
|
OET-090
|
freezing
rain
|
winter
weather
|
Meteorological
|
|
OET-091
|
freezing
spray
|
winter
weather; marine
|
Meteorological
|
|
OET-092
|
frost
|
winter
weather
|
Meteorological
|
|
OET-093
|
fuel issue
|
utility issue
|
Infrastructure
|
|
OET-094
|
geophysical
issue
|
geological
|
Geological
|
|
OET-095
|
grass fire
|
fire
|
Fire
|
|
OET-096
|
hail
|
severe
weather
|
Meteorological
|
|
OET-097
|
hazardous
seas
|
marine
|
Transport
|
|
OET-098
|
health
issue
|
health
issue
|
Health
|
|
OET-099
|
heat
|
temperature
hazard
|
Meteorological
|
|
OET-100
|
heating
oil issue
|
utility
issue
|
Infrastructure
|
|
OET-101
|
high seas
|
marine
|
Meteorological
|
|
OET-102
|
high
surf
|
marine
|
Meteorological
|
|
OET-103
|
high tide
|
marine
|
Transport
|
|
OET-104
|
high
water
|
utility
issue; marine
|
Infrastructure;
Transport
|
|
OET-105
|
home crime
|
criminal activity
|
Safety
|
|
OET-106
|
humidity
issue
|
temperature
hazard
|
Meteorological
|
|
OET-107
|
hurricane
|
tropical
storm; tropical cyclone
|
Meteorological
|
|
OET-108
|
ice
|
winter
weather
|
Meteorological
|
|
OET-109
|
ice pressure
issue
|
ice issue
|
Meteorological
|
|
OET-110
|
ice
storm
|
winter
weather
|
Meteorological
|
|
OET-111
|
iceberg
|
ice issue
|
Meteorological
|
|
OET-112
|
industrial
crime
|
criminal
activity
|
Safety
|
|
OET-113
|
industrial
facility issue
|
safety hazard
|
Safety
|
|
OET-114
|
industrial
fire
|
fire
|
Fire
|
|
OET-115
|
infrastructure
issue
|
infrastructure
|
Infrastructure
|
|
OET-116
|
internet
service issue
|
utility
issue
|
Infrastructure
|
|
OET-117
|
lake effect
snow
|
winter
weather
|
Meteorological
|
|
OET-118
|
lake
wind
|
air
hazard
|
Meteorological
|
|
OET-119
|
landline
service issue
|
utility issue
|
Infrastructure
|
|
OET-120
|
landslide
|
geophysical
|
Geological
|
|
OET-121
|
law
enforcement issue
|
civil issue
|
Security
|
|
OET-122
|
levee
break
|
flood
|
Meteorological
|
|
OET-123
|
lightning
|
thunderstorm;
severe weather
|
Meteorological
|
|
OET-124
|
limited
visibility
|
air
hazard
|
Transport
|
|
OET-125
|
low tide
|
marine
|
Transport
|
|
OET-126
|
low
water
|
utility
issue; marine
|
Infrastructure;
Transport
|
|
OET-127
|
low water pressure
|
utility issue
|
Infrastructure
|
|
OET-128
|
meteoroid
|
space
|
Transport
|
|
OET-129
|
meteorological
issue
|
meteorological
|
Meteorological
|
|
OET-130
|
missile
threat
|
national
hazard
|
CBRNE
|
|
OET-131
|
missing child
|
safety hazard
|
Safety
|
|
OET-132
|
missing
person
|
safety
hazard
|
Safety
|
|
OET-133
|
mobile communication
issue
|
utility issue
|
Infrastructure
|
|
OET-134
|
monsoon
|
weather
|
Meteorological
|
|
OET-135
|
mudslide
|
geophysical
|
Geological
|
|
OET-136
|
natural
gas
|
utility
issue
|
Infrastructure
|
|
OET-137
|
network
message notification
|
testing &
system activity
|
Other
|
|
OET-138
|
nuclear
power plant issue
|
infrastructure
issue
|
Infrastructure;
CBRNE
|
|
OET-139
|
oil leak
|
beach hazard,
environmental
|
Environmental
|
|
OET-140
|
oil
spill
|
beach
hazard, environmental
|
Environmental
|
|
OET-141
|
overland
flood
|
flood
|
Meteorological
|
|
OET-142
|
pipeline
rupture
|
utility
issue
|
Infrastructure
|
|
OET-143
|
plant health issue
|
health issue
|
Health
|
|
OET-144
|
heavy rain
|
health
issue
|
Health
|
|
OET-145
|
pollen
|
health issue
|
Health
|
|
OET-146
|
potable
water issue
|
utility
issue; water hazard
|
Infrastructure
|
|
OET-147
|
power outage
|
infrastructure
issue
|
Infrastructure
|
|
OET-148
|
power
utility issue
|
utility
issue
|
Infrastructure
|
|
OET-149
|
product
safety
|
safety hazard
|
Safety
|
|
OET-150
|
public
facility issue
|
infrastructure
issue
|
Infrastructure
|
|
OET-151
|
public health
|
health issue
|
Health
|
|
OET-152
|
public
service issue
|
infrastructure
issue
|
Infrastructure
|
|
OET-153
|
public
transit issue
|
infrastructure
issue
|
Transport
|
|
OET-154
|
pyroclastic
flow
|
volcano
hazard
|
Geological
|
|
OET-155
|
radiation
issue
|
radiological
hazard
|
CBRNE
|
|
OET-156
|
radio
transmitter
|
safety
hazard
|
Infrastructure
|
|
OET-157
|
radioactive
material release
|
radiological
hazard
|
CBRNE
|
|
OET-158
|
radiological
fire
|
fire
|
CBRNE;
Fire
|
|
OET-159
|
railway issue
|
infrastructure
issue
|
Transport
|
|
OET-160
|
rain
|
weather
|
Meteorological
|
|
OET-161
|
rapid ice
closing of water passage
|
ice issue
|
Transport
|
|
OET-162
|
red
tide
|
health
issue; marine issue
|
Health
|
|
OET-163
|
rescue
|
rescue
|
Rescue
|
|
OET-164
|
retail
crime issue
|
criminal
activity
|
Safety
|
|
OET-165
|
rip current
issue
|
beach hazard
|
Safety
|
|
OET-166
|
road
closure
|
road
hazard
|
Transport
|
|
OET-167
|
road issue
|
road hazard
|
Transport
|
|
OET-168
|
road
vehicle accident
|
road
hazard
|
Transport
|
|
OET-169
|
rogue wave
|
marine
|
Geological
|
|
OET-170
|
safety
|
safety
hazard
|
Safety
|
|
OET-171
|
sandstorm
|
air hazard;
weather
|
Meteorological
|
|
OET-172
|
satellite
debris
|
space
|
Other
|
|
OET-173
|
satellite
service
|
utility issue
|
Infrastructure
|
|
OET-174
|
school
bus issue
|
infrastructure
issue
|
Transport
|
|
OET-175
|
school
closing
|
infrastructure
issue
|
Infrastructure
|
|
OET-176
|
school
lockdown
|
infrastructure
issue
|
Infrastructure
|
|
OET-177
|
search
|
search
|
Rescue
|
|
OET-178
|
security
|
security
|
Security
|
|
OET-179
|
sewer
|
utility issue
|
Infrastructure
|
|
OET-180
|
shoreline
threat
|
beach
hazard
|
Safety
|
|
OET-181
|
sinkhole
|
safety hazard
|
Safety
|
|
OET-182
|
sleet
|
winter
weather
|
Meteorological
|
|
OET-183
|
smoke
|
air hazard
|
Meteorological;
Transport; Health
|
|
OET-184
|
snow
|
winter
weather
|
Meteorological
|
|
OET-185
|
snowstorm
|
weather
|
Meteorological
|
|
OET-186
|
space
debris
|
space
|
Other
|
|
OET-187
|
space weather
|
space
|
Other
|
|
OET-188
|
squall
|
weather;
marine
|
Meteorological
|
|
OET-189
|
storm
|
weather;
marine
|
Meteorological
|
|
OET-190
|
storm
drain
|
utility
issue
|
Infrastructure
|
|
OET-191
|
storm surge
|
weather;
flood
|
Meteorological
|
|
OET-192
|
structure
fire
|
fire
|
Fire
|
|
OET-193
|
swells
|
marine
|
Safety;
Transport
|
|
OET-194
|
telephone
|
utility
issue
|
Infrastructure
|
|
OET-195
|
terrorist
incident
|
criminal
activity
|
Safety
|
|
OET-196
|
thin
ice
|
safety
|
Safety
|
|
OET-197
|
thunderstorm
|
weather
|
Meteorological
|
|
OET-198
|
tornadic
waterspout
|
severe
weather
|
Meteorological
|
|
OET-199
|
tornado
|
severe
weather; tornado
|
Meteorological
|
|
OET-200
|
toxic
plume
|
contamination
hazard
|
CBRNE
|
|
OET-201
|
toxic spill
|
contamination
hazard
|
CBRNE
|
|
OET-202
|
traffic
|
road
hazard
|
Transport
|
|
OET-203
|
transport
issue
|
transport
|
Transport
|
|
OET-204
|
tropical
depression
|
tropical
storm; tropical cyclone
|
Meteorological
|
|
OET-205
|
tropical
storm
|
weather;
tropical cyclone
|
Meteorological
|
|
OET-206
|
tsunami
|
marine
|
Geological
|
|
OET-207
|
typhoon
|
tropical cyclone
|
Meteorological
|
|
OET-208
|
ultraviolet
|
safety
|
Safety
|
|
OET-209
|
utility
|
utility issue
|
Infrastructure
|
|
OET-210
|
vehicle
crime
|
criminal
activity
|
Safety
|
|
OET-211
|
volcanic
activity
|
volcano
hazard
|
Geological
|
|
OET-212
|
volcanic
eruption
|
volcano
hazard
|
Geological
|
|
OET-213
|
volcanic
lahar
|
volcano hazard
|
Geological
|
|
OET-214
|
volcanic
lava
|
volcano
hazard
|
Geological
|
|
OET-215
|
waste
management
|
utility issue
|
Infrastructure
|
|
OET-216
|
water
|
utility
issue; water hazard
|
Geological;
Transport
|
|
OET-217
|
water main
break
|
utility
issue; water hazard
|
Infrastructure
|
|
OET-218
|
waterspout
|
marine
|
Meteorological
|
|
OET-219
|
weather
|
weather
|
Meteorological
|
|
OET-220
|
wildfire
|
fire
|
Fire
|
|
OET-221
|
wind
|
air hazard
|
Meteorological
|
|
OET-222
|
wind
change
|
air
hazard
|
Meteorological
|
|
OET-223
|
wind chill
|
temperature
hazard
|
Meteorological
|
|
OET-224
|
wind
shear
|
air
hazard
|
Meteorological
|
|
OET-225
|
winter storm
|
winter weather
|
Meteorological
|
|
OET-226
|
winter
weather
|
weather
|
Meteorological
|
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
02
|
09-23-2020
|
Scott Robertson
|
Appendix A Acknowledgments added
Appendix B Event Terms. added
Appendix C Revision History added
First Complete Draft
|
|
03
|
10-28-2020
|
Rex Brooks
|
First Complete Edited Draft
|
|
04
|
10-01-2021
|
Norm Paulsen,
Rex Brooks
|
Multiple additions
Appendix A Acknowledgments edited
Second Complete Edited Draft
|
