The
Emergency Management Technical Committee (EMTC) of OASIS Open,
has developed this OASIS Open Event Terms List - User’s Guide
to support the objective of interoperability in the business-of-alerting.
Interoperability is the term given to systems working together for a common
cause, and this guide addresses an important aspect of that cause – the handling
of information associated with an event deemed worthy of being
alerted for. Event information is a key piece of the overall information in the
situation.
This
User’s Guide discusses the concept of an event across the alerting process –
throughout the originating phase to the consuming phase.
The aim is to help originating agents provide standardized (and interoperable)
alert-worthy event information in alert messages for consuming agents
in the process .
This guide has been constructed to address both the observation and analysis of
an event, and the larger alerting situation the event creates for
an alerting audience.
Interoperability
is a primary objective of the EMTC and many of the Common Alerting
Protocol (CAP) based alerting systems that operate world-wide. Many of
these systems are digitally connected – originating and/or consuming CAP-based messages
on a routine basis. CAP messages are XML-based document files
where interoperability is a key objective in its design. CAP is a means for alerting
practitioners (a term used to combine originators and consumers
into one reference), to exchange alerting information in a standardized way.
In
this guide, the premise is that an event is identified and an alerting process
is set to begin. Once the event’s significance is confirmed, it is designated as
an event-of-interest, and the analysis broadens to encompass the
entire alerting situation (inclusive of the event and the alerting process).
Addressing the situation, from the event inception to the audience notification,
is what OASIS Open considers to be an alerting service. The OASIS Open
Event Terms List - User’s Guide makes frequent reference to CAP in discussing
this service .
Prior
to this User’s Guide, OASIS Open had already published version 1.0 of an
OASIS Open Event Terms List resource. The resource was a
work product published for the purposes of promoting interoperability between
alerting practitioners. Subsequent to publishing, many practitioners requested
guidance on how the content of the list is best integrated within CAP. With OASIS
Open Event Terms List - User’s Guide v1.0, and with a backwards
compatible OASIS Open Event Terms List - Lookup Table v2.0, practitioners
now have guidance on how to incorporate the OASIS Open managed list of
universal event terms and codes into their service.
The
OASIS Open Event Terms List - User’s Guide is less for the casual
reader, and more for the expert practitioner (e.g. service architect,
system designer, processing agent, etc.). The aim is to help practitioners build
and operate a better system - one that connects seamlessly (i.e.
is interoperable) with agencies and audiences
on a business/client level, and with originating and consuming
agents on a technical/functional level.
The
CAP standard is a proven data standard for obtaining this goal.
It is a standard for conveying all-event, all-alert
information in an end-to-end alerting system devoted to the alerting objective.
The CAP standard allows for a “many-originator” to “many-consumer”
transfer of information on the technical and functional level, including
the use of customized alerting information (if needed), in any originator/consumer
relationship.
The
focus of this User’s Guide - the alert-worthy event
and its larger alerting situation
- is just one key component of alerting information to be conveyed to consuming
agents and audiences. To that end, the User’s Guide discusses how
to organize, structure, format, and subsequently originate and consume, the
following event-based information within a CAP alert message:
a)
the nature
of an event;
b)
the impacts
of an event;
c)
the location
and timing of an event;
d)
the event
and its relationship to any associated secondary events; and
e)
the calls-to-action
the event may warrant.
The
guide also discusses the tasks of the various processing agents involved in the
alerting service. This includes:
a)
the business
front-line alert originators (observers, analysts, social scientists);
b)
the
technical and functional back-line CAP originators (builders, publishers, data
operators);
c)
the technical
and functional back-line CAP consumers (aggregators, re-distributers,
presenters).
It
is the back-line consuming agents that are employed to service the target
alerting audience. It is the front-line originating agents that start the
process.
This
User’s Guide is also part of a series of event-focussed alerting resources
prepared by the OASIS Open EMTC to cover the full spectrum of
event-based information in a business-of-alerting.
The
OASIS Open Event Terms List (ETL) is a collection of 4 resources.
-
Event
Terms List - Lookup Table
-
Event
Terms List - User’s Guide
-
Event
Terms List - Concept Guide
-
Event
Terms List - Spectrum Analysis
The
OASIS Open Event Terms List - User’s Guide, as part of this collection,
will make reference to the other resources as needed. For more on a compiled
list of OASIS Open event terms and codes, see the OASIS Open Event
Terms List – Lookup Table. For more on understanding the basic
characteristics of an event, including ways to classify the nature, impacts,
location, timing, and behaviors of an event, see the OASIS Open Event
Terms List – Event Concepts. And finally, for more on understanding the
naming of events, and social science that accompanies those naming decisions,
see the OASIS Open Event Terms List – Spectrum Analysis.
The
OASIS Open Event Terms List - User’s Guide resource
was compiled to provide guidance for originating agencies and
their agents on how to select the best terms and codes from the OASIS
Open Event Terms List - Lookup Table, and how consuming
agencies and their agents can subsequently process the chosen terms
and codes. If alerting practitioners (originators and consumers)
are only looking to obtain a basic level of functionality with this material (i.e.
its standardized use and its basic benefit of interoperability), the
subsections marked as “Basic” in section 4 will suffice. With the
guidance of this User’s Guide, the OASIS Open EMTC is asking all CAP practitioners
to minimally incorporate the “Basic” function of the OASIS Open Event
Terms List into their business-of-alerting service to further the
objective of interoperability.
However,
if the practitioner is looking to take full advantage of the OASIS Open
Event Terms List, and gain a deeper understanding of events and the alerting
situation in the process, the subsections marked “More advanced” and “Fully
advanced” in section 4 are recommended. The advanced material presented
makes it possible to handle any conceivable type of event that may be considered
an event-of-interest worth alerting for.
This
Users’ Guide breaks down the process of creating a subject event –
the topic of discussion in an alert message. It does this by utilizing a series
of event-based sub-processes appropriate for various entities involved in the
exercise. It begins with an observing sub-process, followed by an analyzing
sub-process, leading to a CAP originating process, and ending with a CAP
consuming process .
An
OASIS Open Alerting Practices and Strategies - Glossary
(forthcoming) is a resource being assembled to house terms from across the many
OASIS Open alerting based resources. Terms that are both bold and underlined,
in this and other resources, are terms that can be found in the glossary. The
first time a term is used in a section of a resource, that is also found in the
glossary, it will be bolded and underlined to let the reader know there is a
provided definition in the glossary. Being familiar with the defined terms will
help with using this guide and will make navigating the resource quicker and
easier.
This
guide is also intended to help alerting agencies build a better system.
Most existing alerting system documentation, whether that documentation
is based on business analysis, business requirements,
system specifications, service, or training;
have been observed to use a mixture of terms from different views into the
process. Mixing views can lead to confusion for agents building,
operating, and promoting alerting systems. This guide does not go into actual
system design, but learning the language of the various processes used here
will help avoid some of the problems system builders often encounter .
This presentation of the OASIS Open
Event Terms List – User’s Guide is a Public Review presentation.
In this particular presentation all feedback will be collected and reviewed.
Suggestions, comments, and questions can be on any content, including the terms
and codes found in the OASIS Open Event Terms List – Lookup Table.
Each feedback item may be used to adjust the final release copies of the OASIS
Open Event Terms List family of resources (as applicable).
OASIS Open
plans to publish a set of resources in roughly the
following order as a best effort exercise (with no set timeline due to the
inability to predict the availability of volunteer resources):
1)
OASIS Open Event Terms List –
Lookup Table v2.0
2)
OASIS Open Event Terms List –
User’s Guide v1.0
3)
OASIS Open Alerting Practices and
Strategies – Glossary v1.0 (forthcoming)
4)
OASIS Open Event Terms List – Concept
Guide v1.0 (forthcoming)
5)
OASIS Open Event Terms List –
Spectrum Analysis v2.0 (forthcoming)
6)
OASIS Open Event Terms List –
Lookup Table v2.1 (planned)
7)
OASIS Open Alerting Practices and
Strategies – Glossary v1.1 (planned)
8)
OASIS Open Event Terms List –
User’s Guide v2.0 (planned)
9)
OASIS Open Event Terms List – Concept
Guide v2.0 (planned)
At the end of this publish cycle all resources,
in the family of OASIS Open Event Terms List
resources, will be at v2.0, with the Lookup Table having advanced to
v2.1 or greater. All version 2.X resources will be jointly compatible as a
package, all anchored to version 2.0.
The
following is a suggested list of tasks as recommended by the OASIS Open EMTC
when conducting an event-based alerting process. Each ordered
task aligns with the objectives and processes discussed in this User’s Guide
and with the material covered in the OASIS Open Event Terms List
family of resources. Many of the descriptive terms used in this list are
discussed in detail in the OASIS Open Event Terms List – Concept Guide.
Originating agents:
a)
Observe
and
identify an event situation (single or complex );
b)
Analyse
the events
in the situation and devise and form the events-of-interest (an event-of-interest
could cover the entirety of the event situation, or any subset part of the
situation, with each dependent upon the nature of it’s conditions
and impacts);
c)
Devise and form the alert-worthy
events for the target client (an alert-worthy event could also cover the
entirety of the situation, or any subset part of the situation, with each
dependent upon the nature of it’s conditions, impacts,
location and timing);
d)
Associate
the alert-worthy
events with other associated secondary events-of-interest to devise and form a subject
event for the alerting process (there is wide leeway to what
constitutes a subject-event). Subject events may be composed of a single event,
a complex event, or an even larger complex event once all the secondary events
are taken into consideration);
e)
Assemble
the
larger alerting-situation information (this includes information on the
subject-event; any and all supporting information; and any lead time,
intersection time, and follow time information the target audience needs for
coping with the subject event). This also includes using terms and codes as
given in the OASIS Open Event Terms List;
f)
Originate an alert (the
process of publishing one or more alert messages, ideally in CAP form, to
address the larger alerting situation).
Consuming agents:
a)
Initiate or confirm a connection
(for consuming CAP messages);
b)
Consume messages for processing;
c)
Interrogate each alert message and
subject event (for filtering, routing and presenting purposes);
d)
Establish, and if necessary
maintain, an alert notification signal for either:
a.
the
next agent along the path of distribution, or
b.
the last-mile
target audience at the end of the path of distribution.
In
this User’s Guide, a variety of larger alerting situations are
exampled. The
terms used in the examples are associated to one or more of the event-based processes
as discussed in the OASIS Open Event Terms List – Concept Guide. With the Concept
Guide and this User’s Guide, there are four main processes
(sub-processes to the overall process), that attributed to the four main identifiable
parties involved in the alerting process.
1)
“Observing”
process: a process that pertains to agencies and agents responsible for observing
and identifying events.
2)
“Analyzing”
process:
a process that pertains to agencies and agents responsible for analysing events,
events-of-interest, alert-worthy events, and subject
events, all for the purpose of potentially alerting for them .
3)
“CAP
Originating” process: a process that pertains to agents responsible for originating
a CAP-based alert message.
4)
“CAP
Consuming” process: a process that pertains to agents and audiences found at
the end of the path-of-distribution of a CAP-based alert message.
In
the “Observing” process, the objective is to identify any events, and
any secondary related events, as potential events-of-interest, specifically
for the purposes of advancing the alerting process. Events-of-interest can be
singular events (one identifiable event) or complex events (two or more
identifiable events that together as a group are considered one larger event).
They are identified by their nature (i.e. by their observed condition
and impact) .
In
the “Analyzing” process, the objective is to reconcile the details of
the events-of-interest from the perspective of impacted parties. The process
takes the event situation and establishes a communication framework for
the forthcoming alerting situation (i.e. the agency/audience interaction
and all which that encompasses). It is here where alert-worthy events,
the subject event, and any noteworthy secondary events, are
clarified. It also where new events, such as solicited action events the
alerting agency is asking of impacted parties (i.e. any actions to take during
the lead time (ahead of the event), the intersection time (during the event) and
the follow time (after the event) all due to instance and occasion of the
subject event).
In
the CAP Originating process, the objective is to clarify the pieces of
information that support originators building a proper alert message using the
CAP standard. Elements of information in the CAP model are designed to make the
exchange of information meaningful to all parties. The aim of CAP originating
parties is to create a set of standardized elements of technical and functional
alerting information for agents of their consuming client’s needs.
One
objective of the User’s Guide is to make the originating process easier
while simultaneously meeting the needs of all the various consuming parties. The
OASIS Open EMTC perspective for CAP originators is to not necessarily have
them create separately structured CAP product for each and every CAP consuming
party, but to have one CAP message that can service them all . The CAP
standard is designed to make this possible .
In
the CAP Consuming process, the objective is to clarify the pieces of
information that support consumers processing a proper alert message based on
the CAP standard. Elements of information in the CAP model are designed to make
the exchange of information meaningful to all parties with the aim of having consuming
parties able to properly use the elements for their needs.
One
objective the User’s Guide is to make the consuming process
easier while simultaneously allowing originating parties the ability to service
all their consuming partners simultaneously with the same set of CAP alert
messages. The OASIS Open EMTC perspective for CAP consumers is to not
have them make improper assumptions on the information received, nor have to
create additional information to make their service successful. The CAP
standard was designed to make this possible .
This section
outlines the foundational alerting workflow that underpins the four business-of-alerting
processes defined in the OASIS Open Event Terms List family of resources.
It reinforces terminology introduced in the Concept Guide and
introduces additional terms as required.
Following the
process discussion, a representative event situation is presented. This
scenario serves as a baseline case for establishing a set of baseline steps
that can be adapted to a variety of real-world situations. These steps form the
backbone of consistent alerting practices across event types.
The Example
Situations section of this guide builds upon this baseline by exploring
case-specific variations. While these examples retain the core principles
outlined here, they also highlight distinctive circumstances and considerations
unique to each scenario. The primary focus remains on the concept of "event,"
while other components of the alerting process (alerting signals, layers,
profiles, over-alerting, etc…), are covered in separate documents within the OASIS
Open set of resources
.
The
process accommodates both single-event and complex-event
scenarios. Complex-events often involve multiple events as observed and are
explored in depth in this guide. Single-events are treated as subsets of
complex-events and serve as entry points for new users. Learning to manage
single-event scenarios is encouraged before tackling complex-event cases .
The baseline case
presented here involves a complex-event that associates several individual
single-events into one event situation. It is analyzed through three
lenses:
·
Simple
alerting situation (picking one event at exclusion of the others)
·
Advanced
alerting situation (picking two events that can easily be aggregated into one
larger event)
·
Fully
advanced alerting situation (picking four events that are all associated with
each as suggested by business policy and the example event situation as given).
Each perspective
demonstrates how the Common Alerting Protocol (CAP) standard's features can be
leveraged effectively
.
This
guide presents a comprehensive, end-to-end sequence for alerting, beginning with
the observation of an event (real or imagined ), and concluding with an
alert notification of a subject event to the alerting agency’s target
audience. While the steps are described broadly, some components of the
baseline process may be unfamiliar to certain agencies.
This example
baseline case serves as the universal reference model for all subsequent
examples provided in the Example Situations section. Unless
explicitly stated, the principles outlined in this baseline case will apply
across all additional scenarios. Subsequent analyses of the additional
scenarios will focus on how each case diverges from the baseline case, shedding
light on their unique elements.
To
achieve interoperability across organizations, the OASIS Open EMTC
recommends standardizing specific steps within the CAP alerting workflow. These
universal steps span the following sub-processes: observing, analyzing, originating,
and consuming. This guide aligns these steps with the use of events, event-types,
and event terms, as discussed in the OASIS Open Event Terms List
family of resources.
The
OASIS Open EMTC strongly advises CAP originators to include at least one
event code from the Event Terms List in every CAP message. This
practice ensures consistency and facilitates system interoperability. If no
exact match is found, the event-based framework described here still applies,
and the Users’ Guide offers instructions for maintaining
interoperability in such cases.
Lastly,
it’s important to recognize that this process applies to all alerting agencies
- public, private, and restricted alike. Whether alerts are broadly
disseminated (e.g., CAP <scope> = "public") or directed to
specific recipients (e.g., CAP <scope> = "private" or
"restricted"), the core process remains consistent .
Typical process for identifying an event-of-interest for the alerting
process:
1)
An
alerting agency observes an event situation , that involves one or more events,
with each event having the potential to lead an observer to devise and form an event-of-interest.
The agency gathers data about the events (using direct observation,
sensors, and predictive models), to help with the event-of-interest
determination. The event-of-interest is an abstract concept devised and formed from
the same observable conditions of the event’s nature, impacts, location and timing. The boundaries of each event-of-interest’s
conditions, may end up being a subset part of the event it is derived from .
a.
The events
involved are determined by the alerting business and typically pertain to those
that by policy, lead to an event-of-interest (and therefore a possible larger alerting
situation). The observed events ideally would be ones to have an associated event-type
on record.
b.
The
observation is conducted with a concerned client in mind (i.e., the
target audience in the larger alerting process). Ideally, the initial
observation for each event is carried out before any impacts to the client
occur, however, the observation activity is expected to continue throughout the
life of an event - before, during, and sometimes after the impacts for the
client are realized. Sometimes, the observation process begins after the event
has already impacted the audience.
c.
The
analysis stage, the stage following the observing stage, is when the full determination
of events-of-interest is made. If the analysis confirms the nature,
impact, location and timing are indeed interesting (either for the present or for
the future), an event-of-interest marker is applied to the event and the
observation stage continues until the event is no longer interesting.
Background:
In the two diagrams below, two real events (both illustrated
in grey) are present at point-in-time A . One event is moving and
evolving, and the other is stationary and evolving . Point-in-time A serves
as the starting point for the observation exercise as in these two diagrams,
point-in-time A is when the observer became aware of the event. Note that the
events are shown as conceptual representations, without a defined scale for
space or time, and the two point-in-time A markers have no relationship to each
other in these illustrations – they represent separate cases.
In the two example cases, the nature, impacts,
location, and timing will meet or exceed the defined measures of significance (for
at least some measurable segment of time), as illustrated in the concentric
darker grey areas. The objective is simply to try and identify an observed
situation as containing a probable event-of-interest (subset or
otherwise), along with a general sense of the event-types involved.
In the two illustrated example cases, the probable events-of-interest,
as per the observing process, are devised and formed as shown in red in the
diagrams below. They are probable, as the area in red is in the future (as of
point-in-time A). The leftover event areas shown in grey in the diagrams below,
are part of the observed events that do not meet the measure of nature and
impact of significant events, and therefore are not part of the probable events-of-interest.
There are now two events shown in each of the two diagrams,
the core event in grey and the event-of-interest in red. And
while they stem from the same event situation and comprise many of the same
conditions, they are treated as separate and distinct events, each with its own
devised and formed interpretation (two grey and two red).
All four interpretations are abstract constructs. Each
construct is based on a different set of bounding criteria which form each interpretation
. Additional interpretations,
the alert-worthy alerting event and the resulting alert message subject-event,
are discussed later in the analysis stage.
2)
For
any observed event within the situation, if the level of significance
for any one of the measures listed below is not close to being met (“close”
being a subjective assessment), the observed event may be excluded as a probable
event-of-interest and dismissed from further analysis .
a.
If the
nature of an event in the observed situation does not satisfy any
measure of conditional significance, the event may be dismissed (e.g., a wind event
situation being nothing more than a breeze).
b.
If the known impacts of
an event, based on its event-type, does not meet any measure of impact
significance, the event may be dismissed (e.g., a wind situation isolated to a
mountain peak. It may fall within an agency’s area and timing of responsibility,
however, it could still be outside the audience's area-of-concern due to
no actual audience present, resulting in no audience impact ).
c.
If the spatial location
of an event in the observed situation is not significant, the event may
be dismissed (e.g., an offshore storm moving away from any agency’s areas-of-responsibility).
d.
If the timing of an event
in the observed situation is not significant, the event may be dismissed (e.g.,
a distant storm that is not expected to reach the area of responsibility until much
later, well after the agency’s current timing-of-responsibility period).
i. If the event is a moving
event, and its most likely path is anticipated to bring it into the
area-of-responsibility at some far distant time, it would likely qualify as an event-of-interest,
however, not yet leading to an alert-worthy event. It remains under observation
until some future point-in-time when the situation changes .
3)
At the
current point in time, determine whether the events-of-interest are in a
real or imagined state . This is done while
acknowledging that any imagined state may not be realized, or may change to a
real state over time as new information becomes available.
4)
The monitoring range in
space for moving situations is likely much broader than
the range in space for stationary situations. For stationary situations, the
monitoring range would typically align with the alerting agency's area-of-responsibility.
5)
The monitoring range in
time for evolving situations is likely much longer than
the range in time for static situations. For static situations, the monitoring
range would typically align with the alerting agency's timing-of-responsibility.
6)
The
criteria for measuring the significance of an event-of-interest, based
solely on the nature of the events, are likely broader in scope than the
agency's criteria for an actual alert-worthy event (see next section).
The evolving and sometimes unpredictable nature of certain events could easily
transform a nearly alert-worthy event-of-interest into an actual
alert-worthy event-of-interest at a future time.
7)
The
alerting agency typically identifies a primary event within the observed
situation. This could be an individual event (e.g., a tornado) or a complex-event
event (e.g., a storm, composed of a wind event and a precipitation event) . This preliminary
assessment may change during the subsequent analysis stage.
8)
The
alerting agency should identify any secondary events within the observed
situation. If any secondary events are deemed events-of-interest, the situation
is tentatively classified as a complex-event situation. However, the
resulting larger alerting situation may still deal with the multiple
events-of-interest separately, a determination made in the analysis stage.
9)
The
alerting agency should identify risk or threat events that may
lead to one or more follow-on events-of-interest . These risk or threat events,
which are pre-existing and/or antecedent secondary events, form part of the
larger alerting situation surrounding a follow-on alert-worthy event. Pre-existing
or antecedent condition events are treated the same as other events and are also
classified as real or imagined based on their own nature .
10)
The
alerting agency may assign a label to the observed situation, such as a
name or an incident tracking identifier (e.g., a name like "Tropical Storm
Milton" or an identifier like "AAA-001," where "AAA"
represents the reporting entity's code and "001" is the incident
tracking number for that entity). This label assignment may also be applied
during the analysis stage.
11)
The
alerting agency may choose to record the observing-process event information in
a data object for post-analysis and future research. Such activities often help
identify improved methods for observing similar situations in the future.
Observing-process event information, with its wider leeway parameters, may
extend beyond the scope of the analyzing-process event information compiled
later.
Typical process for identifying alert-worthy events and subject events in
the alerting process:
1)
An alerting
agency analyzes the event data of an observed situation to determine if any
devised and formed events-of-interest are true events-of-interest – possibly
leading to the need for an alert-worthy event construct . The analysis would apply
to both the current and future states of an event-of-interest (as per the
standard practices of the alerting agency).
a.
Each potential
event-of-interest in the observed situation would be assessed against its own measures
of significance based on condition, impacts, location, and timing (as
outlined by the alerting agency’s policies based on event-type) .
i. For each potential event-of-interest
the alerting agency assesses the accuracy of the reported situation in
the observing process and validates or adjusts the reported conditions to a
final working assessment for the remainder of the analysis process.
2)
The
alerting agency analyzes the events-of-interest to determine any alert-worthy
events. Like events-of-interest, alert-worthy events are abstract
constructs - separate events devised and formed from the same observable
conditions. Each construct (event-of-interest and alert-worthy event) is based
on a different set of bounding criteria which form the event interpretations.
i. For each event-of-interest
the alerting agency compares the alerting agency area-of-responsibility
and timing-of-responsibility with the event-of-interest area and timing. An
analysis is completed to determine where and when the two areas and timings
intersect with each other. The intersection defines the interpretation of an alert-worthy
event (i.e. it creates the space and time boundaries of an alert-worthy event).
ii. If an event-of-interest is
determined to not be an alert-worthy event after analysis, it may still be
interesting, either as an associated secondary event to another alert-worthy
event, or as a possible future alert-worthy event. It may also be worth
commenting on in the larger alerting situation for the target audience of the
associated alert-worthy event.
Background:
The diagrams below, using the same two real and
evolving events exampled in the observing process earlier, illustrate in blue
the alert-worthy space and time boundaries of concern for the two events.
In these examples, the alert-worthy event interpretation is a subset event of
the event-of-interest.
a.
For
each alert-worthy event the alerting agency determines the degree of significance
based on the nature of the event within the area and timing of responsibility.
b.
For
each alert-worthy event the alerting agency determines the degree of
significance based on impacts of the event within the area and timing of
responsibility[32].
3)
For
each event-of-interest, the alerting agency references the relevant history,
research, science, conventional wisdom, and policies from the event-type
for useable alert-worthy event based information (i.e. policies,
practices, procedures, etc.).
4)
If there
is more than one event-of-interest, the overall situation is a complex-event
situation. The alerting agency then is to decide how many alerting situations involving
alert-worthy events are actually contained within the overall situation .
a.
For
each alerting situation in the observed situation, the alerting agency
determines which alert-worthy events are to be part of which alerting situation.
b.
If two
or more alert-worthy events are placed into one alerting situation, then that
alerting situation is a complex-event alerting situation .
c.
Placing
one alert-worthy event into two or more alerting situations is also a
possibility and it is the purview of the alerting agency to do so, however, it
does presume that two or more co-existing alerting situations stemming from the
same alert-worthy event would not be providing contradictory information.
5)
Each
event-of-interest that becomes a primary alert-worthy event in one
alerting situation, could still be considered as a secondary event in another
alerting situation.
a.
As
part of the alerting situation, the alerting agency clarifies the primary
alert-worthy event and any associated secondary events-of-interests (e.g. a
secondary earthquake event-of-interest that a primary tsunami alert-worthy event
associates back to). The association can be made by standard alerting agency
policy (i.e. certain event types always associate with other event types, for
example, snow and cold), or can be made based on familiarity (i.e. certain
event types associate with each other based on the experiences of the agency
and its agents, for example, wind and electrical power grid outages) .
6)
Determining
an actual location in space and interval in time for the entire event (the grey
areas in the above diagram, including the red and blue area), is often
considered valuable information for parties that might have an interest in such
information. Such information is sometimes useful when telling the story as
part of the larger alerting situation to an audience. This would be at the
discretion of the alerting agency to decide whether to include it or not as
part of the story.
7)
During
the entire event-of-interest, if there is an oscillation (i.e. an ebb and flow
of an evolving event being in and out of significance), the decision on whether
to treat the observed situation as one or several event-of-interests is usually
a business policy decision. Often, such decisions derive from working backwards
from the alerting situation (e.g., knowing what the preferred outcome of the larger
alerting process is). This would be a consideration in the earlier analysis
process .
8)
Once
the compliment of alert-worthy events for each alerting situation has
been determined, the union of the alert-worthy events then becomes the subject-event
for the alerting situation. The subject event is another abstract construct – another
event-based definition devised and formed from the same set of observable
conditions.
a.
If the
entire event situation is a single event, the compliment of alert-worthy events
is only one event, thereby making the alert-worthy event and the subject-event
the same.
b.
For a complex-event
case, this may mean assigning some of the subject-event details from one
alert-worthy event and some of the details from another alert-worthy
event, or alternatively, having the details from one alert-worthy event
become proxies for the others .
9)
Alerting
agencies sometimes recognize that the space and time boundaries of an event-of-interest
are not measurable. If that is the case, the missing boundaries are not necessarily
a critical missing piece of the subject-event at this point. Location and
timing policies for alert-worthy events and subject events can be set by policy
to produce space and time boundaries for those constructs .
10)
Near
the end of the analysis stage, the alerting agency re-connects the subject-event
back to known event-types. The event types are likely the same as they were during
the observation stage, however, it could have changed based on the analysis of
the event situation and the larger alerting situation.
a.
The
analysis collectively includes the primary event-of-interest, the group
of associated secondary events-of-interest, and from experience, a general idea
of what the larger alerting situation for the target audience may end up being.
The re-connection back to event types can be formal (as part of alerting agency
policy), or informal (based on the experiences of the agency, community, and
their agents). Any secondary event-of-interests should be similarly re-connected
to their event types. Occasionally, during the analysis, a secondary event-of-interest
may take over as the primary event-of-interest.
11)
After
the alerting agency determines the make-up of the subject event, the
focus is on the larger alerting situation as it pertains to the
consuming audience (as shown in purple in the diagram below).
a.
If the
subject-event is an anticipated event (real or imagined), the larger alerting
situation will have a timing that includes lead timing, intersection timing,
and possible follow timing .
b.
If the
subject-event is underway within an area-of-concern, the larger alerting situation
will have no lead timing for some or part of the area, especially if the event is
a moving event. Past event information, while interesting, is outside of the
lead time period and is now just information for the larger audience story.
c.
Follow-timing
information is less often incorporated in the alerting story, however, it can
be important if follow-time impacts are expected. Follow-time situations, after
the alert-worthy event has ended, are typically used for extremely hazardous
event situations. Past information is common in follow-time alert messaging.
i. If the primary alert-worthy
event is ended (a real past event), and there are still follow time impacts
which linger, the larger alerting situation will have a timing that now includes
only follow-timing. The subject-event for the alerting situation now changes to
one of the follow time secondary events. That subject event would now have a
focus on a follow time alert-worthy event which would become the primary event
in follow time messages.
ii. The alerting situation may
still be considered the same alerting situation after the initial primary event
has ended (e.g. a “typhoon” alert-worthy event that has ended, however, a “typhoon
emergency” alert-worthy event remains - due to devastating and lasting impacts
of the recent typhoon).
1.
The alerting
agency might want to name the alerting situation a “typhoon emergency” from the
very beginning, anticipating follow-on messaging. This strategy connects
messages published before, during and after the typhoon emergency to a single
named event – supplying quick context to the follow time messaging.
12)
When the
subject-event is for a complex-event, then the larger alerting situation
is considered a complex-event alerting situation. In such cases, it is
recommended that the name of the larger alerting situation should represent the
“complex event” (i.e. a “storm” situation, when two “rain” and “wind” events
are combined to make up the complex event storm situation). Alternatively, if
two separate and distinct alerting situations are preferred by the alerting
agency (one wind, one rain), then this is a case of how the alerting process itself
can affect the overall situation analysis .
13)
The
alerting agency takes the additional details of the larger alerting situation
and reconciles these details with respect to a story they want to convey to their
alerting audience.
a.
Details
to reconcile with the larger alerting situation may be unique to the situation
and be introduced as a judgement call during the analysis (i.e. evacuation
routes that are normally used might be blocked due reasons outside of the
control of emergency responders).
b.
Details
may emerge from the larger situation involving proxies based on the
capabilities of the alerting process itself. Knowing the alerting process
capabilities, the construction of alert messages may be affected.
iii. The actual true location
of the subject event may not match with any pre-defined alerting zones used
by an agency. A true alert-worthy event location-mapping to alerting-zone
process may expand on the area, resulting in a larger alerting area than that
of the event-of-interest that triggered the alert (i.e. a case of over-alerting
the area-of-concern) .
iv. The actual true timing of
the larger
situation may
not match with the publishing timing of new alert messages. The alerting update
process typically is done based on the workload of front-line agents and often updates
or endings of an alert occur after portions of the audience are already free of
the impacts of the event-of-interest .
14)
The
alerting agency determines the name for an alert best suited to cover
the larger alerting situation. An alerting agency typically names an alert in
consideration of the alerting audience, trying for a short, accurate, descriptive
name for use in the any presentation of the alert messages (i.e. as used in
titles/headlines/etc.). Those alert names typically include a descriptor
involving the event type, however, that is not always the case .
a.
If any
associated event-of-interests and secondary events are to be covered within the
alerting situation, select a name for the alert that best covers the larger complex-event
situation.
15)
The
alerting agency constructs well suited alert message text for the larger alerting
situation. This would be based on the chosen subject-event part of the larger alerting
situation as well as any message text for each alert-worthy event that is included.
16)
The
alerting agency augments the alert message text from the previous step based on
the relevant compiled history, research, science, conventional wisdom, and
policies stored with the corresponding event types that make up the subject
event.
a.
Knowing
the primary event type for the subject event and the composition of the larger alerting
situation, the alerting agency checks the compiled history, research, science,
conventional wisdom, and business policies for helpful information on terms,
instructions, known impacts, call-to-action statements, codes, procedures, etc.
to include in the alert message.
17) If the larger alerting
situation is expected to change, or continue on past the current timing-of-responsibility
for the alerting agency, then a continuation of the alert is to be dealt with
using updated alert messages published at a later time. Knowing this, the focus
of the larger alerting situation can be weighted to the near future, leaving
the far future details for these later messages.
a.
These
later messages include ended messages (i.e. a CAP message type of “Cancel”
where the last mile presentation agency is instructed to discontinue the
alerting signal).
Typical process for originating a CAP alert message with event based
information:
The
process outlined here is typical for an agent on behalf of an alerting agency when
originating a CAP alert message. The OASIS Open EMTC recommends populating the subject-event
information and the larger alerting situation information into
CAP messages as per the following steps. The agent could either be an operator
entering alerting information into a CAP-based interface or a written program
that converts externally entered information into CAP-based alert messaging .
A CAP message revolves
around a subject event, which is a group of one or more alert-worthy
events, each with their event type. Without an event type, the alerting situation
addressed by the message would likely require a lengthier qualifying description,
demanding more time and effort than is typically ideal for an audience in the
consuming moment of concern. By introducing the event through an associated
event type (e.g., using a headline or other mechanism), an alerting agency can
convey the importance or significance of a subject event quickly and
efficiently. The full details of the actual alerting situation can then be subsequently
shared with an audience that is already engaged as a result of consuming the
headline. The event types used in this messaging process are derived from the
earlier analysis stage that has already been completed.
The alerting agency
initiates a process to originate a valid CAP file. The CAP elements outlined
below are linked to the event or event types in a CAP alert message.
1)
Element:
<event> cap.alertInfo.event.text (required).
This is a basic element that is required in CAP. A CAP
message with no <event> element is an invalid CAP message.
Definition (CAP v1.2): The text denoting the
type of subject-event of the alert message.
Objective: The objective of the <event>
element is to assist consuming agencies in clearly communicating to their audiences
the type of event associated to the subject-event in messages published by the
CAP alerting agency.
b.
With the
expectation of well-crafted text, as per the social science of the situation, the
<event> element’s value is designed to provide immediate context to
an audience the reason for the alert message. The text should generate an
association to a familiar type of event for the audience. Audiences are then prepared
to receive, with context, the remaining message information that follows.
c.
The
<event> element is a display-based, audience-facing element
composed of free-form text. It is designed in CAP to be a fully flexible
element, capable of delivering event-type information to any audience without
the limitation of pre-published values. As an audience-facing element, the
meaning of the value is only constrained to the operating language of the
alerting service, not to any functional language between agents executing the
service.
i. The <event>
element is often constrained within an alerting service to pre-set values (as
pre-set values are a sub-set of all possible values), however, the decision to
do so risks affecting the ability of alerting agencies to adjust to unexpected
situations and/or adapt to changes moving forward when constrained to a formalized
change process.
1.
New
event types are typically discovered as they are happening. Change process
delays, due to new configuration and partner coordination, may impact the
ability to provide a timely service for new event types if only pre-set values
are used. The ability to add new types quickly is highly recommended in any
alerting service.
2.
The OASIS
Open EMTC recommends, that originating agencies that employ a set of
enumerated event-types that provide pre-set values for the <event>
text element, should make it clear:
a.
that the
names associated to the event-types are for display purposes and could
change without notice; and
b.
that
consuming agents and agencies wishing to automate processing functions (based
on the <event> element), should use other CAP elements, including
the agency’s compliment of <eventCode> elements .
d.
The
originating agency expects the <event> value to be either
displayed as provided (e.g., <event>); used within a constructed
presentation that incorporates the value (e.g., "Event type:
<event>"), or omitted in favor of alternative elements such as
<headline>, or other presentation constructs derived from the <eventCode>
element (e.g., icons or symbols).
e.
The
alerting agency should construct the <event> element in a CAP
message using an attribute of the event-type that describes the
event-type by name. This name attribute should be defined as free-form text,
reflecting the alerting agency’s local terminology in accordance with the
operating language of the alerting service. The selected value should take into
account the perspective of the target audience.
i. The <event>
element is not used to describe an actual event; rather, it is populated to
indicate a type of event. For example, the <event> element would be
assigned <event>hurricane</event> (an event-type
name) rather than <event>hurricane Katrina</event> (the
name of a specific event).
f.
If no acceptable
event-type name is available locally, a term may be entered manually if the local
process allows. The entered term would be expected to be displayed by consuming
agencies as given. Alternatively, the originating agency may also check the OASIS
Open Event Terms List – Lookup Table to find an event-type term that aligns
with the local event-type’s meaning and understanding. Note that since the OASIS
Open Event Terms List is not translated into other languages, any necessary
translations should have been completed in advance and stored as part of the event-type
information.
g.
If no
exact match is found in the OASIS Open Event Terms List, a close acceptable match
may be selected. Suitable alternatives include:
i. variations of the same
term (e.g. “flood”, “floods”, “flooding”), or
ii. synonymous terms (e.g. “tropical
storm” and “tropical cyclone”), or
iii. a more general term that
serves as an acceptable proxy for a more specific term along the
general-to-specific spectrum (e.g., "wind" as a broader term for
"small craft wind") , or
iv. a best judgement call.
h.
If no
close acceptable match is found in the OASIS Open Event Terms List, then
the event term “other” should be the OASIS Open term identified for use . The use would be for the
<eventCode> element as discussed below, not for the <event>
element discussed here. The <event> element would be populated as
discussed above in the previous sub section.
i. For alerting originators,
using “other” for the <eventCode> element means the matching process
was attempted, however, nothing acceptable was found. This outcome is preferred
as compared to the outcome where the matching process gives the impression of a
step ot being attempted at all. The term “other” is an interoperability
requirement allowing consumers some recourse of action when “other” is
encountered as an <eventCode> – see the following CAP Consuming
process section below.
ii. The term “other” in the
<event> value is not prohibited; it’s typically considered meaningless
for most presentation systems and therefore is not recommended.
iii. If "other" is found
as a match, the OASIS Open EMTC recommends that the alerting agency
consider submitting a new event term for review. This term would replace
"other" in future instances of the currently unmatched event-type for
the local alerting agency. The submission process is outlined in the section on
Submitting Content in the OASIS Open Event Terms List – Lookup Table.
i.
If any
associated events-of-interest are identified, and are to be handled
collectively as one complex-event, the <event> element
value should represent the broader event situation as a whole. For example, instead
of specifying a narrower event such as <event>power grid
failure</event>, a more encompassing event term like <event>service
interruption</event> could be used instead .
i. Continuing with the complex-event
example, if the overall complex-event situation is deemed as a group the primary
event-of-interest, the complex-event becomes the event that anchors the larger
alerting situation. The individual events-of-interest that make up the
complex-event may or may not be explicitly addressed as part of this larger
situation. If the agency so chooses to address any of the individual
events-of-interest, the CAP standard allows for this to be part of the <discussion>
element (for target audiences), and as part of the <eventCode> element
(for processing agents. See <eventCode> element below). Consequently,
the alerting agency may assign the primary event-of-interest to be the
complex-event knowing that this messaging option is available for all the
individual events-of-interest in CAP .
2)
Element:
<eventCode> cap.alertInfo.eventCode.group (optional).
This is an added element that is optional in CAP. A CAP
message with no <eventCode> element is still valid CAP.
Definition (CAP v1.2): A system-specific code
identifying an event-type for the alert message.
Objective: The objective of the <eventCode>
group is to assist consuming agents when making processing decisions based on
the type of event that the originating agents designate as the subject event
for the alert messages.
a.
Sub-element:
<eventCode>.<valueName> cap.alertInfo.eventCode.valueName.text
(required).
This is a conditionally required
element in CAP. An <eventCode> element group in CAP with no
<valueName> sub-element is an invalid group.
Objective: The objective of the <eventCode>.<valueName>
element is to reference the managed set of event-type codes in use when
populating the corresponding <eventCode>.<value>
element within the group.
b.
Sub-element:
<eventCode>.<value>
cap.alertInfo.eventCode.value.code
(required).
This is a conditionally required
element in CAP. An <eventCode> element group in CAP with no
<value> sub-element is an invalid group.
Objective: The objective of the <eventCode>.<value>
element is to indicate to the consumer of the CAP message the chosen code in
use within the group. The value is from the referenced <eventCode>.<valueName>
set of event-type codes.
c.
The <eventCode>
group element is defined as a multi-instanced group element in a CAP message . The alerting agency may optionally
build none, one, or several <eventCode> element groups in a CAP
message using values from one or several sets of standardized and managed event
codes.
i. In a zero instance case,
with no <eventCode> group element, the OASIS Open EMTC
recommends that such a case be best left for closed systems where the
originator and consumer are both part of the same closed system. In open
systems, where the originator and consumer are often unknown to each other, the
zero case still allows for consuming system processing, however, it often leads
to simpler presentations without any event-based controls. Consuming systems
may interrogate less reliable elements for clues about the event-type, such as
the loosely defined <event> element, however, the OASIS Open
EMTC considers the results to be less reliable.
ii. In a single instance case,
with only one <eventCode> group element, the originating systems
would be limiting the advantage of the <eventCode> element to
consumers that use the referenced event-type set. The OASIS Open EMTC
recommends that in the single instance case, the set referenced is the OASIS
Open Event Terms List.
iii. In a multi-instanced case,
with two or more <eventCode> group elements, the elements within
each group are each considered independent groups to processed separately.
There may be single codes from two or more referenced sets of event codes, or
multiple codes from a single referenced set of event codes, or, if the
situation suggests, multiple codes from several referenced sets .
d.
If
there is a complex-event situation, the OASIS Open EMTC recommends that
for maximum flexibility of all consuming agents, all the applicable codes from
all the referenced sets in use by the agency be added to the CAP message . In such cases, the OASIS Open EMTC recommends listing the primary
event-of-interest type first.
e.
The
<eventCode>.<value> may be displayed by consuming
agencies as provided or incorporated into a presentation that includes the
value (e.g. “Event code: <eventCode>.<value>”). However,
it is considered a value primarily designed for agents along the path of
distribution to make decisions rather than for direct presentation to the final
audience.
i.
If the
target audience is emergency services personnel responding to the alert message
by providing follow-on services, the <eventCode>.<value>
itself may hold significance in that presentation.
3)
Element:
<category>: cap.alertInfo.category.code (required).
This
is a basic element that is required in CAP. A CAP message with no <category>
element is an invalid CAP message.
Definition (CAP v1.2): The code denoting the category (or categories) of
the subject event of the alert message.
Objective: The objective of the <category>
element is to assist consuming agents in making clear processing decisions
based on one or more standard CAP <category> values. These values
are selected from an enumerated set of allowable options as defined by the CAP
standard for this element.
a.
With
the expectation that categories are appropriately assigned based on the event
situation, the <category> element’s value is intended to provide
immediate filtering context for consuming agents. This helps them process or
redirect the message effectively along the path of distribution.
b.
The
<category> element is designed as a multi-instance element within
a CAP message. The alerting agency has the option to include one or more <category>
elements as needed.
i. In cases where only a
single instance of the <category> element is used, despite the
situation containing multiple applicable options, the originating systems may
be restricting the intended advantage of the <category> element as
defined.
ii. In a multi-instance
scenario where two or more <category> elements are included, each
value is treated as an independent entity to be processed separately. The OASIS
Open EMTC recommends adopting the multiple <category> approach
to maximize flexibility for consuming agents .
c.
If a
complex-event situation involves multiple event types, multiple <category>
instances should be used to list all relevant categories contributing to the
broader situation. When multiple <category> groups are necessary,
the OASIS Open EMTC recommends listing the primary
event-of-interest categories first .
d.
A
default set of one or more associated CAP <category> values should
be pre-assigned for all business event-types during the research and
science stage of event-type development. These values should be filed as
part of the event-type information. The OASIS Open EMTC advises against
selecting event-type CAP <category> values during the alerting process
(i.e. on the fly), as this approach may lead to varied interpretations among
agents and clients, potentially compromising the integrity of the agency’s
alerting service over time.
i. The <category>
element is determined locally by selecting one or more enumerated values from
the CAP standard or choosing matching event-term entries from the OASIS Open
Event Terms List .
ii. One option is to include
all categories as listed in the mapping. However, since the OASIS Open Event
Terms List – Lookup Table is also accessible to consuming agents, they can
independently use the given <eventCode> value to look up all OASIS
Open assigned CAP <category> values if they choose to do so.
iii. Consuming agencies, along
with their clients, can establish customized arrangements to incorporate a CAP
category into their partnership, ensuring clients receive services tailored to
their preferences. For example, an agency may choose to add the CAP category
"Safety" to an OASIS Open event term, even if OASIS Open
does not include "Safety" among its listed mappings .
iv. If an acceptable entry in
the OASIS Open Event Terms List is matched, but no suitable CAP category
is available (in the opinion of the alerting agency), the agency may still
select other CAP Category values from the CAP standard. Additionally, the
agency should consider submitting a new CAP category to the OASIS Open EMTC
for review to accompany the identified OASIS Open event term .
4) Element: <headline>: cap.alertInfo.headline
(optional).
This
is an added element that is optional in CAP. A CAP message with no <headline>
element is still valid CAP.
Definition
(CAP v1.2): The text headline of the alert message.
Objective: The objective of the <headline>
element is to assist consuming agents in introducing the alert message to
audiences. It provides a brief, concise summary with the most relevant details
to ensure quick comprehension.
a.
The
alerting agency should construct the CAP <headline> element, as
well as other audience-facing text-based CAP message elements (e.g., <description>
and <instruction>), using their local event term naming label (in
their operating language), to represent the broader event-type situation.
Additionally, any relevant details from the larger alerting situation that
enhance clarity may be included in a concise, attention-grabbing statement. The
<headline> should motivate the audience to explore the full alert message
for further information.
5) Element: <onset>: cap.alertInfo.onset
(optional).
This
is an added element that is optional in CAP. A CAP message with no <onset>
element is still valid CAP.
Definition (CAP v1.2): The expected time of the beginning of the subject
event of the alert message.
Objective: The objective of the <onset>
element is to assist consuming agents in communicating the expected start time
of the subject-event within the area-of-concern to audiences.
a.
If the
subject-event's beginning time is unknown, or is quite varied across the
area-of-concern, the <onset> element may be omitted from the CAP
message. In such cases, the <discussion> element can be used to
provide a descriptive explanation of the expected start time as appropriate for
the situation.
b.
If the
subject-event involves a risk or threat event that could lead to a possible
event-of-interest in the area-of-concern, the OASIS Open EMTC recommends
omitting the optional <onset> element from the CAP message.
Including the onset of the risk event could mistakenly be interpreted as the
onset of the actual event-of-interest that the risk event is attempting to
reference[58].
6)
Element:
<parameter>: cap.alertInfo.parameter.group (optional).
This
is an added element that is optional in CAP. A CAP message with no <parameter>
element is still valid CAP.
Definition (CAP v1.2): A system-specific additional parameter associated
with the alert message.
Objective: The objective of the <parameter>
group element is to assist consuming agents in processing additional,
non-standardized alert message information that originating agencies wish to
convey. This additional information may be event-based or event-type-based
and can serve either as display-based, audience-facing content or as decision-based,
agent-facing data - or both[59].
a.
Sub-element:
<parameter>.<valueName> cap.alertInfo.parameter.valueName.text
(required).
This is a conditionally required
element in CAP. An <parameter> element group in CAP with no
<valueName> sub-element is an invalid group.
Objective: The objective of the <parameter>.<valueName>
element is to provide an assigned naming reference for the information
contained in the corresponding <parameter>.<value>
element within the group.
b.
Sub-element:
<parameter><value>
cap.alertInfo.parameter.value.text
(required).
This is a conditionally required
element in CAP. A <parameter> element group in CAP with no
<value> sub-element is an invalid group.
Objective: The objective of the <parameter>.<value>
element is to indicate to the consumer of the CAP message the chosen value for
the additional, non-standardized alert message information within the group.
c.
The <parameter>
group element is defined as a multi-instanced group element in a CAP message.
The alerting agency may optionally build none, one, or several <parameter>
element groups in a CAP message providing values for as many additional,
non-standardized alert message pieces of information as desired.
7)
Element:
<effective> cap.alertInfo.effective.time (optional).
This
is an added element that is optional in CAP. A CAP message with no <effective>
element is still valid CAP.
Definition (CAP v1.2): The effective time of the information of the
alert message.
Objective:
The
objective of the <effective> element is to assist consuming agents
in determining when the presentation of the information within the alert message
should begin. The begin time is derived from the broader event situation, which
in turn in turn is composed of the subject event and, if applicable, its lead
time[60].
a.
If the
alert message is intended for presentation to an audience at a future time,
that moment marks when the originating agency seeks to initiate audience awareness
of the subject event. Such larger alerting situations are primarily used for
distant future events, where the beginning of the lead time period itself falls
to a future point in time .
b.
If the
preferred <effective> time for the alerting agency has already
passed, the <effective> element may be omitted from the CAP
message, as the effective time would then be equivalent to the message's
publish time. This is a common practice for update CAP messages when the subject-event
is already having an impact.
8)
Element:
<expires> cap.alertInfo.expires.time (optional).
This
is an added element that is optional in CAP. A CAP message with no <expires>
element is still valid CAP.
Definition (CAP v1.2): The expires time of the information of the alert
message.
Objective:
The
objective of the <expires> element is to assist consuming agents
in determining when the presentation of the information within the alert message
should conclude. The end time is typically based on the broader event
situation, which in turn is composed of the subject event and, if applicable,
its follow time .
a.
The
alerting agency fills in the optional <expires> element with
either the anticipated end time of the larger alerting situation or the end
time of the agency’s current period of responsibility (at the time of
publishing). This includes if the larger event situation extends beyond that expires
point. Typically, for short-duration events, the overall situation's end time
aligns with the conclusion of the event-of-interest.
b.
The
CAP standard permits the <expires> element to be optionally
omitted from the CAP message. However, the OASIS Open EMTC recommends
including the <expires> element and assigning a value based on an
alerting business policy - typically the current end time of the alerting
agency’s timing-of-responsibility, as determined at the time of publishing .
i. The <expires>
element is optional, but its absence can be concerning for consuming agents, as
there is no formal directive specifying when the message presentation should
end. In such cases, consuming agents must assume that the originator will
eventually provide a follow-up update or cancellation message within a
reasonable timeframe to address the expiration timing of the alerting signal.
ii. When an <expires>
time is absent, consumers must assume that no network or system issue will
disrupt the delivery of a follow-up message through the distribution path. To
avoid appearing delinquent in the alerting process (by not removing the message
presentation in a timely manner), consuming agencies and agents generally
prefer originators to include an upfront <expires> element in all
CAP messages . The OASIS Open EMTC
recommends that the <expires> element always be present and
assigned a reasonable end time for message presentation.
iii. Originators concerned
about the potential for alert messages to expire on consuming systems, before a
replacement message arrives to supersede the message, should factor in a reasonable
buffer time beyond the true expires time for the message information. This
would be a value balanced by the alerting agency recognizing the consuming
agencies desire to not have expired information be presented well after the
message, and its information, has gone stale .
9)
Element:
<incidents> cap.alert.incidents.group (optional).
This
is an added element that is optional in CAP. A CAP message with no <incidents>
element is still valid CAP.
Definition (CAP v1.2): The “group listing” naming the referent
incident(s) of the alert message.
Objective: The objective of the <incidents>
element in a CAP message is to link the current alert message to a broader
observed situation identified by a name and/or index. An alerting agency may
optionally include an <incidents> element for cross-referencing
and tracking purposes, assisting consumers in understanding the context (e.g.,
a named event like "Hurricane Katrina"). Identifiers may take the
form of incident tracking codes assigned by different reporting agencies (e.g.,
AAA-001, BBB-007), allowing multiple agencies to cross-reference their incident
records .
a.
The
incident naming or incident indexing practice is determined by the alerting
agency as part of its organizational profile. Consumers of the originating agency’s
CAP messaging can then utilize the assigned value for tracking and
cross-referencing purposes.
b.
International
naming and indexing activities for extreme events (e.g., earthquakes,
volcanoes, etc.) are among the tracking considerations an alerting agency may
take into account when utilizing the <incidents> element.
The following element(s)
(including sub-elements) outline additional OASIS Open EMTC recommendations for
improving interoperability in Common Alerting Protocol (CAP) across digitally
connected systems and are applicable to the event and event-type aspects of the
alerting process.
10) Element: <code> cap.alert.code.code
(optional).
This
is an added element that is optional in CAP. A CAP message with no <code>
element is still valid CAP.
Definition
(CAP v1.2): A code denoting special handling of the alert message.
Objective: The objective of the <code>
element is to assist consuming agencies in processing special handling
information that may be included in a CAP message.
a.
Special
handling information refers to details that go beyond the standard alerting
data in a CAP message. This may include additional information layers or
constrained elements as part of a profiled limitation (e.g., a maximum length
for a free-form text value). Some consumers may choose to ignore special
handling information so originators should treat <code> as an element
that may not be relevant to all recipients. For example, a size limitation not
relevant to a consumer, but indicated by an originator, can easily be ignored
by the consumer.
b.
The <code>
element is defined as a multi-instanced element in a CAP message.
i. The OASIS Open EMTC
recommends that alerting agencies utilizing the OASIS Open Event Terms List
populate at least one <code> element with the following value, as
defined by OASIS Open :
<code>layer:OASIS-Open:ETL-LT:v2.0</code>.
1.
The OASIS
Open EMTC classifies the Event Terms List as a layer and
specifies that the term "layer" must be included, as
demonstrated in the example.
2.
The OASIS
Open EMTC prefers the use of a hyphen to fill in blank spaces in its name
for the <code> element and specifies that “OASIS-Open” be
the form of the name, as per the example, not “OASIS Open”.
3.
The OASIS
Open EMTC defines versions for the list and specifies that the version
reference “v2.0” be included, as per the example.
c.
Omitting
or ignoring a <code> element does not negatively impact the CAP
message for originators or consumers. However, when included, advanced
consuming agents can process the <code> element and utilize it as
intended. Its presence indicates that the originating agency is adhering to the
rules of a "layer" or "profile" as defined by
the layer or profile owner.
i. In the OASIS Open Event
Terms List, the layer owner is OASIS Open, and the special handling
rules specify that at least one <eventCode> element must be
included in the following CAP message. This element will contain a code
value sourced from the OASIS Open Event Terms List – Lookup Table.
Ensuring interoperability, this approach enables consumers to rely on the
element and its assigned value.
Typical process for consuming a CAP alert message with event based information:
This
process is commonly followed by an agent, acting on behalf of an alerting
agency’s dissemination partner or target audience, when interpreting a CAP
alert message. The OASIS Open EMTC recommends decoding the subject-event
and broader alerting situation information in CAP messages according to
the steps outlined below. Refer to the baseline case example situation later in
this section for further details.
The consuming agency initiates a process to consume a valid CAP file. The
CAP elements outlined below are linked to the event or event-types in a CAP alert
message.
1)
Elements:
<eventCode> (optional) and/or <category> (required).
<eventCode> is an added element that is optional in
CAP. A CAP message with no <eventCode> element is still valid CAP.
<category> is an element required in CAP. A CAP message with no <category>
element is invalid CAP.
Objective: If any event-based filtering or routing of the CAP
message is to be undertaken, the <eventCode> element (if
populated) and the <category> element (as populated), are
recommended as the two event type-based elements to use for this purpose
.
a.
The
filter and routing process can follow either an inclusive or exclusive
approach.
i. An inclusive filter
identifies at least one event code and/or category value that matches the CAP
event codes and categories relevant to the consumer .
ii. An exclusive filter seeks
to exclude event codes and CAP categories that are not relevant to the consumer
.
iii. The OASIS Open EMTC
recommends adopting the inclusive filter approach .
b.
The
"at least one" strategy applies when a CAP message
includes multiple event codes and categories. In scenarios where two or more
events of interest are present - one related to the condition of the event
(e.g., flood) and another to its impact (e.g., evacuation) - the consumer can
match either event independently or both as part of their operational process.
For further discussion on this strategy, refer to the advanced section of the
baseline case example situation.
c.
The OASIS
Open EMTC recommends a configurable lookup table approach, allowing the
list of inclusive event types to be updated as needed without modifying the
processing software. If the processing software dynamically references this
list for each new incoming CAP alert message, the list can be updated
and implemented separately without impacting the message processing system.
d.
As an
advanced processing method, a consuming agent can retrieve <eventCode>
element values and cross-reference them with corresponding OASIS Open
CAP Category(s) from the OASIS Event Terms List. The resulting category
list can then be used to augment the existing CAP Category values within
the CAP message. This expanded list of CAP Categories has the
potential to increase the scope of an inclusive filtering process .
2)
Element:
<event> (required).
This is a basic element that is required in CAP. A CAP
message with no <event> element is an invalid CAP message.
Objective: If the <event> element is utilized by a CAP
consuming agency in a presentation, it should clearly convey its value as an
event type, rather than an actual event. For example, it should be displayed as
“Event type: <event>” instead of “Event: <event>”.
The preferred messaging should emphasize that “an alert has been issued for an
event of type X”, rather than “an alert has been issued for event X”.
a.
A key
benefit of this approach is its applicability to both condition-based and
impact-based events. It helps convey impact-based events more clearly, reducing
potential confusion. For example, presenting “Event type: emergency” is
generally better understood in the social science of alerting than “Event:
emergency”.
3)
Element:
<headline> (optional).
This is an added element that is optional in CAP. A CAP
message with no <headline> element is still valid CAP.
Objective: The CAP consuming agency should present the CAP originator’s
<headline> element as provided. While constructing a custom
headline is not an OASIS Open EMTC recommended practice, OASIS Open
acknowledges that some consuming agencies may lack presentation systems capable
of accommodating all CAP <headline> elements. In such cases,
creating a custom headline may be necessary .
a.
If
<headline> is present in the CAP message, the OASIS Open EMTC
recommends presenting it as is, ensuring it reflects the preference of the
originating alerting agency. For example, displaying "Headline: <headline>"
is preferred, though presenting “<headline>” alone is also common
and considered acceptable.
b.
If the
<headline> element is omitted, an alternative presentation may
still be effective. However, the OASIS Open EMTC strongly recommends
displaying at least the <event> element in such cases (e.g.,
"Event type: emergency").
4)
Element:
<parameter>
Objective: A CAP consuming agency may choose to process <parameter>
group elements, which are optional and may contain customized information
related to the event and event types included in the alert message. The format
of this customized information layer is defined by the alerting agency and can
take various forms, including freeform text .
5)
Element:
<incidents>
Objective: A CAP consuming agency may opt to process the <incidents>
element. This optional element can include information about related events-of-interest
and messages, indexed via a provided incident name or code.[75].
The following element(s)
(including sub-elements) outline additional OASIS Open EMTC recommendations for
improving interoperability in Common Alerting Protocol (CAP) across digitally
connected systems and are applicable to the event and event-type aspects of the
alerting process.
1)
Element:
<code> cap.alert.code.code (optional).
This
is an added element that is optional in CAP. A CAP message with no <code>
element is still valid CAP.
Objective: A CAP consuming
agency may optionally process any <code> element in a CAP
message. A <code> value, such as <code>layer:OASIS-Open:ETL-LT:v2.0</code>,
serves as a courtesy element within CAP, signaling to the consumer that
the message contains a layer of event-based information related to the
published OASIS Open Event Terms List. The <code> element
is designed to enhance processing integrity for advanced consuming systems .
a.
While
the CAP originator constructs the CAP alert message, the format and
structure rules of the <code> element instance are determined
by the layer owner - in this case OASIS Open for the OASIS
Open Event Terms List.
i. The value between the
opening and closing <code> tags is a single string that should
ideally be processed and matched in its entirety. The matching string
incorporates the colon delimiter, the “layer” designation, OASIS Open as
the owner, the OASIS Open lookup table reference, and its version
number. For the OASIS Open Event Terms List – Lookup Table v2.0, the
standardized format is: "layer:OASIS-Open:ETL-LT:v2.0".
ii. The four fields within the
value serve as courtesy fields to help consuming agents and agencies
understand the OASIS Open reference provided. Processing these fields
individually is not an expected activity in an operational environment.
The baseline case
example situation outlined here serves as the universal reference model for all
subsequent examples provided in the Example Situations section.
Unless explicitly stated, the principles outlined in this baseline case will
apply across all additional scenarios. Subsequent analyses of the additional
scenarios will focus on how each case diverges from the baseline case, shedding
light on their unique elements.
The
baseline case begins with the observing process, progresses
through various stages, and concludes with the CAP consuming process.
Each section will introduce a list of relevant terms for the process, followed
by discussions at increasing levels of complexity - starting with a simple analysis,
then advancing to a more detailed analysis, and finally concluding with
a fully advanced analysis on the larger alerting situation.
The
example situation is a complex-event case categorized as advanced.
The simple discussion presents the case as a straightforward basic alerting
scenario, while the more advanced and fully advanced discussions
explore a more comprehensive approach. These discussions involve
numerous decisions based on the inter-relationships among the various
observed events that collectively shape this complex-event advanced
situation
The
various observed events in the baseline case are interdependent
within the broader context. And even though each event could be managed
separately with individual alerts, the example also demonstrates how they can
be combined into a single complex-event situation and
handled through a single complex-event alert. The discussion offered
here examples how CAP features are designed to manage both single
and complex-event situations.
Determining
whether to handle the overall event situation as a series of single
events, each with its own alert, or as one complex-event situation
within a single alert, falls to the purview of an alerting agency.
Some may opt for the complex-event approach, using a single alert
attempting to reduce the situation down to one larger alerting situation
(in efforts to minimize the number of active alert messages in play);
while others may opt for several single-event approaches, handling each with
its own alerting situation (with overlapping active messages).
In
this constructed, baseline-case example situation, a public agency
has been alerted to a rapidly rising water levels event within its area
of responsibility. Water gauge sensors indicate that water levels are
increasing at a rate exceeding the pre-determined threshold for a flash
flood. Furthermore, the hard-set level marker for rate of
increase of water levels, and the volume of water contributing the rise, is
sufficient for a follow-on flood event to also be realized.
Recent
records indicate that water levels were normal (not high) before the
onset of this event situation. Additionally, a quick check confirmed that a broken
levee at the county reservoir is what is causing the large
volumes of water to spill into an area of concern. High degree of
certainty observations strongly support that a flooding situation is
actively unfolding .
Observed events: flash flood, rainfall, levee collapse, flood
Event-of-interest: flash flood, flood
Secondary events: rainfall, levee collapse, flash flood, flood,
evacuation
Simple Observation:
1)
1) A flash
flood situation is observed, with several key observations noted regarding
the fast-rising water levels:
a.
The
event is recognized and found to be real and occurring within a
portion of the alerting agency’s area-of-responsibility at point-in-time
A.
b.
The left
edge of the grey filled area on the left side of the marked event is when the
event is acknowledged to have started, even though it wasn’t observed
immediately at that point-in-time (it is the time at which the broken levee
occurred, i.e. the trigger event for the flash flood resulting in immediate
impacts).
c.
The
red filled area is when the event became interesting to the various observing
parties (when it came to be noticed by the various alerting agencies involved).
The red filled area covers the grey filled area completely, except for a short beginning
period. These two devised and formed events, the event (grey) and the
event-of-interest (red), are constructs identical in nature, impacts, location
and timing except for the beginning timing of when they started .
d.
The
rising water levels are observed to exceed the pre-determined threshold
for a flash flood event.
e.
The
location of concern covers only a portion of the agency’s area of
responsibility.
f.
The
situation is promptly designated as a “flash flood” event-of-interest,
as the term flash flood most accurately describes the circumstances at
the time of observation. This classification is based on the history and
social science conclusions of “flash flood” being the appropriate term.
2)
The area
of concern for the flash flood is straightforward to determine in
this baseline case. The flash flood event had a known start time, based
on recorded observations, and its end time can be estimated,
using scientific predictions and historical data from similar
past events.
a.
The
affected area is a single, low-lying location that is known to
be vulnerable to flash flood events. The outer edge fringe areas
surrounding this location will experience a reduced level of impact
compared to the inner core areas.
b.
The duration
of the flash flood situation is closely aligning with predictions from a
modeled course. Since the rainfall event has ended, no additional
water is being introduced, reinforcing the accuracy of the forecasted timeline.
c.
The flash
flood-prone area represents a zone requiring an alert. This
area includes the currently rising water areas and the soon to be rising water
areas, as the floodwaters continue to spread (westward from the Highway
1 East levee breach in the eastern part of the county).
3)
Additional
events in the event situation include a rainfall event, a levee
collapse event, and a flood event. These are summarily classified as
past and future secondary events.
a.
The rainfall
and levee collapse events are past events that provide background
context to explain the unfolding flash flood event. As such, they
are no longer relevant going forward to the ongoing observing process.
b.
The flood
event is a future event, designated as a second
event-of-interest. In a simple alerting process, it is to be
addressed separately in the future with its own alerting process. The
alerting agency will begin the separate flood event-of-interest process
immediately after the flash flood event-of-interest process is addressed. The near
term future flood event is an associated secondary event-of-interest to the
flash flood event - one needing immediate attention in turn after the flash
flood [79].
4)
Based
on history, research, scientific understanding, and conventional wisdom,
flash floods are widely recognized as high-impact events. Given this, the
analysis of the unfolding and real flash flood situation commences
immediately.
More Advanced Observation:
1)
In
this more advanced approach, the alerting agency plans to combine two events-of-interest
into one complex-event situation to be handled in one alerting
situation.
a.
In addition to bullet 1 in
the initial simple observation above, further key observations are
noted.
i. The volume of water
involved, combined with the elevation profile of the flash flood area
of concern, will result in a flood event over a larger area.
1.
The
flood observing process happens concurrently with the flash flood observing
process.
2.
As the
high water area continues to spread, its rate of rise will decrease, reducing
the flash flood concern sooner than flood concern.
b.
The flash
flood event is real and occurring within a portion of the alerting
agency’s area-of-responsibility at point-in-time A. In contrast, the flood
event is imagined and anticipated. While these two events are independent,
they are both part of a larger event situation sharing many of the same
measurable conditions. Each event has its own criteria for existence, as
well as distinct areas and timing of concern.
c.
The fast-rising
water event, actively occurring within the area of concern, serves as
antecedent conditions for the predicted flood event. Given the
established rising water levels condition, the forecasted flood event
is classified as having high certainty.
d.
The collapsed
levee is a separate event within the larger event situation
and is being handled by another agency. This other event has the
potential to impact the duration of both the flash flood and flood
events.
i. If the levee break is addressed in
a timely manner, it may shorten the timing of the two flood based events.
The collapsed levee is recognized as a standalone situation and
serves as the “incident” event within the broader event situation. The broken
levee responding agency, in this baseline case, has officially
designated a name for the levee “incident”, the “Highway 1 East Levee
Collapse” incident.
e.
The preceding
rainfall event, occurring before the levee collapse, was responsible
for elevating water levels in the reservoir beyond normal levels.
This increased water volume will further intensify the overall event
situation. While the rainfall event could arguably be classified
as the overall trigger event, and thus the primary “incident” to
use, rainfall events are common occurrences, whereas the levee
collapse is an exceptional occurrence. Given this distinction, the levee
collapse serves as the most appropriate incident identifier for the
overall event situation.
2)
Building
on the simple observation section above, at the current point-in-time
A in the diagrams, the flash flood event is the most immediate concern.
However, as the event situation progresses, the follow-on flood event
will eventually become the main concern, shifting the primary event-of-interest
from a flash flood to a flood. This situation involves at least two
events-of-interest, indicating that it qualifies as a complex-event
situation
.
a.
A judgment
call is made in this situation, determining whether the responsible
agency is losing significant advance warning time while concurrently
assessing both flood-based events-of-interest. If the observation-gathering
process for the flood event begins to delay the timely
publication of an alert for the flash flood event, the agency may
opt to proceed with issuing a flash flood alert first, with the
understanding that it will quickly by an updated message covering both
the flash flood and flood events. This will be determined in the analysis
process to follow.
i. Preliminary messages often
overdo the area and timing of concern in the haste to get them published, a
behavior that can be acknowledged with standard text indicating new messages
will be issued with additional details as they become available.
3)
If the
flash flood were to trigger additional secondary events, such as structural
damage to a bridge, or a building collapse concern, the
overall complex-event situation would be evolving. However, in this baseline
case example situation, the scenario is intentionally kept minimal, with no
such additional events to consider.
4)
In
addition to bullet 2 in the simple observation section above, the area of
concern for the flood events is also straightforward to determine in
this baseline case.
a.
The
affected area is a single, low-lying location that is known to
be vulnerable to flood events. The outer edge fringe areas
surrounding this location will experience a reduced level of impact
compared to the inner core areas.
b.
The
duration of the flood event is less certain than the flash flood due to it’s
much longer future-time presence, as there is still a period of high water
levels expected after the rising water nature ends.
c.
The flood-prone
area represents a zone requiring an alert. The low-lying flood-prone
area is a larger area as illustrated in the diagram.
5)
The trigger
event for the overall event situation could reasonably be attributed
to either the rainfall event, which caused the levee collapse, or
the levee collapse itself, potentially due to structural failure.
However, at this stage, the trigger event information primarily serves
as historical context for understanding the broader situation. The focus
is now shifting to the alerting process moving forward.
a.
Reporting
the trigger event is optional and depends on the alerting agency’s
discretion. Including it could either complicate the narrative or
help explain the situation quickly and concisely. The agency may choose
to introduce the trigger event in its initial messaging to
establish context, and then omit it in later updates as the alerting situation
evolves.
6)
In
addition to bullet 4 in the simple observation above, historical
data, research, scientific analysis, and conventional wisdom indicate that floods
are also high-impact events. Given this, a detailed analysis of
the flood situation can now begin, along with coordinated communication
between agencies to ensure an effective response.
7)
The
two events-of-interest as a group, the flash flood and the flood, are
considered related events of type “aggregation” .
a.
Relationship
types of aggregation are neither the weakest nor the strongest type of
relationships. Discussing either flood-based event-of-interest in isolation,
may bring to mind the other events-of-interest, as they are closely related by event-type
and the observed conditions.
b.
This
relationship type is a preliminary assessment done in the observation process.
This assessment could change in the analysis process to follow. For now, knowing
this relationship type is in play, both events should be mentioned and passed
on for analysis with full reference to each other.
Fully Advanced Observation:
1)
In
this fully advanced approach, the alerting agency plans to combine three events-of-interest,
including the creation of a new one, an evacuation event-of-interest, all
grouped into one complex-event situation .
a.
Further
to bullet 1 in the more advanced observation section above,
additional aspects of the overall event situation are identified .
i. The affected population
has limited recent experience with such flood based events, as the last
occurrence took place over 15 years ago. This lack of familiarity may
impact preparedness and response effectiveness.
ii. There has been little
to no public discussion regarding the condition of the Highway 1 East
levee for nearly the same duration - about 15 years. As a
result, the levee failure came as a surprising and unexpected event
to the affected community.
iii. An evacuation order
may be considered as a necessary action given the unfolding event situation.
It has its own criteria for existence, as well as distinct areas
and timing of concern.
1.
Due to
the population density of the affected area, any evacuation effort
could lead to severe congestion at critical travel routes, potentially
complicating emergency response and safety measures.
2.
Highway
1 East is not a viable route for evacuation. Information on viable
evacuation routes would be helpful in the messaging, if such information were
pre-determined and stored with an event-type relevant to the situation.
2)
In
addition to bullet 2 in the more advanced observation section,
considerations regarding an immediate evacuation are also incorporated
into the thinking of the observation process.
3)
In
addition to bullet 6 in the more advanced observation above,
historical data, research, scientific analysis, and conventional wisdom
indicate that evacuations are high-impact events requiring
significant coordination between emergency services agencies and personnel.
Given this, a detailed analysis of the imagined evacuation event
can now begin.
4)
In
addition to bullet 7 in the more advanced observation above, the three
events-of-interest as a group, the flash flood, the flood, and the evacuation,
are considered related events of type “association”. The two flood
events, as its own group, are considered related events of type “aggregation”,
however, the addition of the third event-of-interest puts them all into a
different relationship type “association”.
a.
Relationship
types of association are the weakest relationships. An evacuation event-of-interest
does not immediately bring to mind the flood based events-of-interest in the
event situation. An evacuation event could be triggered by many events not
flood-based. In this baseline case, they are only related by the observed
conditions.
i. Knowing this, the flood-based
events, in this baseline case, need to be explicitly mentioned and discussed separately
in the observing process.
b.
This
relationship type is a preliminary assessment done in the observation process.
This assessment could change in the analysis process to follow. For now,
knowing this relationship type is in play, all events should be mentioned and
passed on for analysis with full reference to each other.
Primary events-of-interest: flash flood, flood, evacuation
Secondary events: rainfall, levee collapse, flash flood, flood, water
barrier operations, evacuation, road closure
Alert-worthy Events: flash flood, flood, evacuation, emergency
Trigger events: rainfall, levee collapse
Primary Event type: flash flood, flood, evacuation, emergency
Secondary Event Types: rainfall, levee collapse, flash flood, flood,
deployment of emergency services, evacuation, road closure
Subject event: flash flood, flood, evacuation, emergency
Simple Analysis:
1)
Beyond
what was captured in the observing process, the analyzing process
identifies additional insights, including:
a.
Confirmation
that the flash flood event (grey) is a truly a devised and formed
event-of-interest (red), that does lead to a devised and formed alert-worthy
event (blue).
b.
In
this case, the primary difference between the event-of-interest and the alert-worthy
event is the timing of the two event constructs. The alert-worthy event is
constrained to the here and now for the client, relative to point-in-time A, and
its worthiness ends when the timing-of-concern ends, again relative to
point-in-time A. The event-of-interest construct has no such constraints,
as its entire existence is of interest to the business .
c.
Analysis
confirms the secondary flood event is also a truly devised and formed
event-of-interest, leading to a devised and formed alert-worthy event. The
simple analysis also confirms it can be
addressed separately after the flash flood alert has been issued and
published. In this baseline case, the flood event analysis would
begin immediately after the flash flood analysis due to its rapidly
developing and high impact nature .
d.
The other
agency responsible for addressing the levee collapse has initiated a
“deployment of emergency services” event. The simple analysis
here confirms that this other event remains a separate event, however, it
may be worth a mention.
2)
The analysis
confirms the alert-worthy area of concern for the client completely
matches with the flash flood event-of-interest area. Although they match,
this newly defined area construct is assigned to the alert-worthy event area
in the alerting process. The alert-worthy event area is used to ensure
focused communication and response efforts are directed to that area. For other
event-type situations, matching areas may not be the case.
a.
The analysis
acknowledges that the full extent of the area of concern
for the flash flood event-of-interest is based on a prediction.
As conditions evolve and predictions change, updated alert messages will
be able to reflect any changes to the area of concern, ensuring focused
communication and response efforts remain appropriate to the situation.
b.
The scope
of analysis also determines a set of flash flood based impacts
directly resulting from the fast-rising water levels. This would be extracted
from the flash flood event-type information stored on hand, and as constrained
by the alert-worthy area of concern.
3)
The analysis
confirms the alert-worthy timing of concern for the client is a subset
of the timing of the flood flash event-of-interest. This timing now
serves as the alert-worthy event timing, and subsequently the alert
signaling process, ensuring timely and accurate information. This timing
analysis is updated frequently to keep it accurate.
a.
The response
time for impacted parties in this baseline case will be limited. For
those located near the collapsed levee, its essentially zero. Given the confirmed
area and timing of the alert-worthy event, the urgency
level for an alert message is set to immediate to ensure as
prompt action as possible of alerting partners.
b.
The analysis
acknowledges that the timing of concern for the flash flood event of
interest extends far enough into the future that its end timing
is not currently relevant at the current point-in-time A. Future update
alert messages will provide timely information regarding the event’s
conclusion well before the ending occurs.
4)
As the
alert-worthy event is to be addressed as a single-event-based alert, the
alert-worthy event and the forthcoming devised and formed alert message subject
event have identical nature, impacts, location and timing boundaries.
5)
The subject
event is then part of what defines the larger alerting situation area
and timing.
a.
The larger
alerting situation is defined by the alert message, and includes a single set
of begin and end times, and a single set of area references (as shown above). Both
remaining fixed until a replacement message is published. In this baseline case,
the larger alerting situation area is slightly larger than the subject
event area. The difference is subtle, however in some cases, it can be more.
In this baseline case, some minimal edge areas at point-in-time A are
over-alerted spatially .
6)
The analysis confirms several key
aspects of the fast-rising water levels event.
a.
The current
rising water levels rate meets the classification of fast-rising
as opposed to its binary compliment not-fast-rising. At this stage, it
is designated as a static event, as it will remain fast-rising (above
the rate threshold) until it is not. This fast-rising classification is
expected to persist for some time.
b.
The current
rising water levels event meets the classification of growing-in-area
as opposed to its binary compliment not- growing-in-area. At this stage,
it is designated as a moving event, as it will remain growing (moving
and expanding in area until it is not). This classification is expected to persist
for some time.
7)
If time
permits, the analysis can conclude data on current water levels,
the rate of rising water, and the currently observed extent of the
affected area. While these details are not essential to the immediate
alerting process, they can be valuable for situational awareness and
future decision-making.
8)
Additional
lifecycle details are gathered to aid in constructing an alert.
These details include:
a.
If the
flash flood alert is to end when the flash flood event ends (assuming a
straight forward alerting process is determined by the analysis), both the alert-worthy
flash flood event and subject-event flash flood event will end at
the same time. The flash flood larger alerting situation would then be
deemed as no longer existing.
9)
Additional
process details are gathered to aid in constructing alert messages.
These details may include.
a.
Building
a polygon object to define the area of concern at the time of messaging.
b.
Assembling
a list of proxy zones (e.g., county-based zones) to represent the affected areas
as per the alerting agency standard operating procedures.
c.
Calculating
the expiration time for the soon-to-be-published alert message, based on
the end timing of the subject event . This would be either:
i. the end time of the
subject-event, if it was determined the subject-event timing of concern is
earlier than the end timing-of-responsibility, or
ii. the end timing of
responsibility (as of point in time A) - a time set by business policy governing
situations of event-type flash flood .
10)
Since
the event of interest and the subject-event, in this baseline
case, are fundamentally based on the same happening, the designated
label for the larger alerting situation is “flash flood”, as
dictated by event-type policy.
a.
An
alternative label, such as “high water”, could be used, but would likely
reduce the perceived urgency of the situation. Social science suggests
that “flash flood” is generally more attention-grabbing, making
it a more effective term for conveying the seriousness of the alert-worthy
event to the audience.
11)
The pre-determined
business usage type for this particular larger alerting situation
is that of “warning” . Long-standing practices,
for this baseline case example, dictates that the “warning” designation is
to be used when notifying the public about such hazardous subject-events.
This ensures consistency of communication about such hazards over time and over
multiple instances of the same hazard-type occurring.
12)
The full
named alert in this example is “flash flood warning.” It combines
the chosen event type label (“flash flood”) and the chosen business
usage type label (“warning”). While other label choices exist, long-standing
practice have established these as the standard in this baseline case
example.
13)
The alert
message intended for the audience will incorporate text derived
from the actual analysis of the observed event of interest, the
alert-worthy event, and the resulting subject event. This ensures
that the message is informative, relevant, and reflective of the ongoing
situation. In this baseline case, such text would likely not change much
between the various event constructs, but in some cases, especially complex-event
cases, it could.
14)
The
remaining text in the alert message will be shaped by the understanding
that the primary event of interest is categorized as a flash flood.
The history, research, scientific analysis, conventional wisdom, and
established policies for handling flash flood events will guide
the Alerting Agency in crafting a clear, effective, and actionable alert
message.
15)
A
review of the alerting agency’s event type classification for “flash
flood” confirms that the appropriate CAP category for this type of event
of interest is “Environmental.” This category assignment was
determined through business research conducted well before the
actual flash flood event-of-interest occurred, ensuring consistency in
classification and response. The OASIS Open subcategory is “terrestrial”,
simply confirming that the OASIS Open interpretation of such events is
one that is over land.
a.
Any
other available information on the OASIS Open Event Term “flash
flood” can now be incorporated into the originating CAP process,
enhancing the accuracy and effectiveness of the alert and the interoperability
of the CAP alert message.
16)
The levee
collapse and rainfall events, as noted in the observing process, are
not directly relevant to the current situation. However, they serve as background
information, providing context for the consuming audience to
better understand the unfolding events.
More Advanced analysis:
1)
In
this more advanced approach, the alerting agency plans to combine two events-of-interest
into one complex-event situation to be handled in one alerting
situation.
a.
Beyond
what was captured in the more advanced section of the observing process
and the simple analysing process above, the more advanced analysis
identifies additional insights, including:
i. Confirmation that the flood
event (in grey – hidden) is a truly devised and formed event-of-interest (in
red – partially hidden), that does lead to a second devised and formed alert-worthy
event (blue – fully shown) .
i. Like the flash flood, a difference
between the flood event-of-interest and alert-worthy event is the
timing of the two event constructs. Unlike the flash flood, the start time of
the flood alert-worthy event is not the current point-in-time A.
ii. All other points discussed
in bullets 1, 2 and 3 of the simple analysis section apply except for the
decision to defer the flood alert-worthy event to a following and separate
alerting situation.
iii. Other agencies may
initiate secondary response activities, such as constructing emergency
water barriers to address the concern of the advancing water, thereby
impacting the location and timing details of the flash flood and flood
events-of-interest.
2)
Like
bullet 2 in the simple analysis, the analysis confirms the alert-worthy area
of concern for the client completely matches with the flood event-of-interest
area.
a.
The scope
of analysis also determines a set of flood based impacts directly
resulting from the high water. This would be extracted from the flood
event-type information stored on file, and as constrained by the alert-worthy
area of concern.
3)
Like
bullet 2 in the simple analysis, the analysis confirms the alert-worthy timing
of concern for the client is a subset of the timing of the flood
event-of-interest.
a.
The analysis
acknowledges that the timing of concern for the flood event of
interest extends far enough into the future that its end timing
is not currently relevant at the current point-in-time A. Future update
alert messages will provide timely information regarding the flood event
ending before the ending occurs.
4)
The analysis
notes that it is antecedent rising water conditions that will cause water
levels to exceed the predefined threshold for a flood event at
some future point in time, allowing for some lead time before the
alert-worthy flood event begins.
a.
The response
window for the alerting audience is noted to be longer for the flood
event as compared to a flash flood event. The urgency to issue an
alert is less immediate for the flood than the flash flood,
making the flash flood event still the primary event-of-interest at point-in-time
A.
b.
The edge
areas of the flood event will not experience the fast-rising
water condition of a flash flood due to the gradual spread of
the rising water slowing the rate of rising in the edge areas.
c.
The severity
of the flood event of interest is deemed just as extreme as a flash
flood.
d.
The depth
of water concern across the flood-prone area will be a longer term
concern than the rising water concern, one that is expected to
persist for days.
e.
A new
set of impacts, those related to high water flood levels, is now
under consideration.
5)
Based
on history, research, scientific analysis, and conventional wisdom
surrounding the two events-of-interest - particularly as reflected in their associated
event types - the most effective terms for these two events of interest
are “flash flood” and “flood.”
6)
Additional
lifecycle details are gathered to aid in constructing an alert. These details
include:
a.
The named
alert can change names between the initial and updated messages
in the alert message series. For example, a “flash flood warning” message,
followed later by a “flood warning” message, as part of the same
continuous set of messages associated to the single complex-event alert.
The OASIS Open EMTC considers this an acceptable approach when the flood
event overtakes the flash flood as the primary event of interest .
i. If the flash flood alert
is to be updated when the flood event takes over as the primary
event-of-interest, the subject event will continue and change to the
flood event (in the updated messages). At such time, the flash flood
alert-worthy event is relegated to a secondary event to the new primary
flood event. The flash flood event-of-interest may continue on, to some lesser
degree, however, it has been overtaken by the flood event as the primary
event in the event situation.
b.
The
named alert could initially start off as “flood warning” and continue as
“flood warning” throughout its series of messages, assuming the alerting
agency feels the audience is capable of handling the situation this way.
c.
A
third option, “emergency flood alert”, where the descriptive qualifier
“emergency” is added to heighten the awareness to a higher level – hopefully one
that will result in more immediate action.
i. The term “emergency flood
warning” is also a consideration, however, the social science of warning
the audience to something specific, and using a general term like emergency,
can lead to some confusion. The term alert is a general term that works
well with emergency, as both these terms direct the audience to look
deeper into the message for the details, with the term flood providing a quick
introduction to the topic of discussion that will be given.
ii. This is one way to use “emergency”
- as a descriptive qualifier. Another way is to use “emergency” as an
event-of-interest itself. For that approach, see the fully advanced section to
follow.
7)
The condition,
impacts, location, and timing of a single subject event, derived off
a complex-event, is the union of the two alert-worthy events,
each of which were determined by their intersection with the alerting
agency’s area and timing of responsibility, as illustrated in the diagram
below .
a.
The
area in purple is the newly formed and devised subject event based on
the two alert-worthy events.
b.
Note
that the flash flood event space is smaller than the subject
event space, but their timing details align. Conversely, the flood
event space aligns with the subject event space but not
the timing details (as the flood event starts later).
i. In this more advanced
analysis, the flash flood timing-of-concern serves as a timing proxy
for the complex-event subject event, while the flood event area-of-concern
is used as a location proxy for the complex-event subject-event.
ii. To maintain a simpler
communication with the consuming audience, the subject event
location and timing are applied to both events of interest in the
alert signalling process. Each event is being over-alerted in space
individually, however, every represented space of the subject-event has
at least one alert-worthy event in play. Any necessary clarifications
regarding the event situation, as it pertains to this over-alerting,
could be addressed in the <discussion> element text if necessary.
8)
The larger
alerting situation space/time diagram is as follows:
a.
In
this baseline case, the complex-event subject event location and timing is
less aligned with the larger alerting situation than it was with the simple flash
flood only approach.
i. In the brown area
of the diagram, outside of where the purple subject event is bounded, there
is no flash flood event expected. And while there is a flood event expected, it
is during the alert-worthy flood event’s lead-time period. Such
considerations may impact the audience based messaging text used in the
<description> element. In more advanced situations, alerting agencies are
often faced with balancing the repercussions of such details in the text.
b.
If the
flash flood event of interest was also imagined, and anticipated to begin at a later
time, the purple subject event timing would also shift to start
at that later time. However, the brown larger alerting situation timing
would still be anchored to the current time, taking advantage of some
additional lead time for flash flood preparedness and response .
9)
Any other
events of interest, that might have impacted the larger alerting
situation, have either ended or do not exist within this baseline
case example situation.
a.
If
additional secondary events, such as a bridge collapse or an impending
bridge failure were apparent, they would require assessment and handling
as either:
i. A separate alerting
situation, with its own dedicated alert, or
ii. An informational
component incorporated into this larger complex-event alerting situation,
or
iii. Another event-of-interest
making it more than the two exampled.
Fully Advanced Analysis:
1)
In
this fully advanced approach, the alerting agency plans to combine up to four events-of-interest
into one complex-event alerting situation, including the creation of two
new ones, an evacuation event-of-interest and an emergency event-of-interest.
a.
In
addition to what is discussed in the fully advanced observation process,
and what is covered in the bullet 1 in the more advanced analysis
above, additional aspects of the overall larger event situation are
identified.
i. The recent rainfall
event introduced abnormally high volumes of water into the reservoir
before the levee failure occurred. This excess water has the
potential to intensify the impacts and prolong the hazards
of the flood-based events, further escalating the situation.
ii. An evacuation order
has been decided upon. This new event-of-interest is one that has been
introduced in the analysis stage as a consequence of the analysis.
1.
At
this stage, the evacuation event is imagined. An event-of-interest to be
triggered by the alerting process within the event situation.
a.
It is
considered a static event in the sense of it being an evacuation until it is
not an evacuation.
2.
The
evacuation event-of-interest would now be added to the fully advanced
observation process going forward.
2)
Bullets
2 through 5 in the simple analysis and bullets 2 and 3 in the more
advanced analysis apply. Additional analysis finds:
a.
The evacuation
event-of-interest leads to a devised and formed evacuation alert-worthy event.
It needs to be alerted to ensure public safety.
b.
In
this baseline case, as part of the alert-worthy event analysis, things like evacuation
routes, planned
to away from the advancing water rather than toward it,
could be made.
i. Providing clear
reference points to assist evacuees - such as higher ground,
designated safety markers, and passable routes like Highway 1
West, are considerations to make for the messaging.
ii. If some details are time
consuming to compile, possibly delaying the timing of the initial evacuation
message, they could be deferred and added to update messages as soon as
they are available.
3)
The evacuation
event-of-interest and alert-worthy event remain as devised and
formed until their conditions change to indicate otherwise.
a.
Their specific
details could change quickly in this rapidly developing event situation,
however, they are still based on the singular activity of evacuating,
and are types of events most likely to be coordinated with partner agencies.
b.
The
conditions, impacts, locations and timings of the various evacuation-based
event constructs likely involve the operating procedures of the other official
parties involved. This typically leads to a more adaptive approach than a
pre-set one.
4)
For a complex-event
situation, involving two simultaneous flood-based events-of-interest and
one evacuation event-of-interest, an appropriate complex-event group term the
alerting agency might prefer, is “emergency”.
a.
“Emergency”,
in this context, is a new event-of-interest that is a single complex-event that
is made up of the other three events-of-interest. It is devised and formed by
the nature, impacts, locations and timing that make up the other three.
b.
Based
on the historical data, research, scientific analysis, and conventional
wisdom surrounding such events – as fully reflected in the available event-type
information on file - the most effective terms for each single event
of interest are: “evacuation”, “flash flood,” and “flood”. For
the complex-event situation, the most suitable single complex-event term
would be “emergency”.
c.
While
the flash flood and flood events are significant, the evacuation
and emergency events are considered more important in this fully
advanced analysis. An alert labeled with “flash flood” or “flood”
may not prompt as rapid a response from the audience as “evacuation”
or “emergency”. The term “emergency evacuation” provides
even more context as would “evacuation emergency”. A term like “flood
emergency evacuation” or “flood evacuation emergency” would provide even
more context, however, these naming forms are awkward and may add confusion as per
the social science of the situation.
d.
Ultimately,
the alerting agency makes the final decision on terminology.
i. For this baseline case,
“emergency evacuation”, combined with the business usage alert type “order”
leads to “emergency evacuation order” as the named alert. Here the
evacuation is the primary event-of-interest and alert-worthy event.
ii. The flash flood and flood
are still alert-worthy events; however, they are left to the message content to
be found in the discussion section.
5)
The observation
of the evacuation event-of-interest is an engineered one, based
on the documented procedures of the alerting agency leading up to
the decision to evacuate. The space/time diagram for the evacuation event-of-interest
is as follows.
a.
The red-marked
area represents the new evacuation event-of-interest.
i. It is to begin immediately
and covers the same area and timing as the two flood-based events-of-interest
combined (as discussed in the more advanced analysis section).
ii. The exact end timing
of the flood event-of-interest remains uncertain, however, it is
confirmed to extend beyond the agency's timing of responsibility
and so the evacuation will too. Their endings will be dealt with in
later messages.
6)
The
space/time diagram for the conceived alert-worthy evacuation event,
devised and formed out of the evacuation event-of-interest, is as
follows:
a.
The blue-marked
alert-worthy event now includes the subset nature, impacts, location and
timing of the evacuation event-of-interest – the near term parts that
are relevant to the alerting client at point-in-time A.
7)
In
this baseline case, the subject-event space/time diagram is as follows,
regardless of whether the evacuation or the emergency is the
primary alert-worthy event:
a.
Apply
the more advanced analysis section bullets 2 and 3, except now the details
of the evacuation and the emergency events-of-interest
would be added to the group with one or the other as the primary event of interest.
b.
At point-in-time
A, the flash flood is real and within the intersection
timing, while the flood remains imagined within the lead
timing. The evacuation and emergency events-of-interest, while
imagined during the initial analysis process, are real at the
time of publish, so are considered as real during the analysis.
i. The alert message
has an opportunity to communicate lead time flood information,
offering insights into the condition and impacts of the flood
event before flood levels are actually reached, however, the evacuation
or emergency, as the primary event-of-interest, have priority.
8)
At the
current point in time A:
a.
The
flash flood has already begun and has some history.
b.
Flood
levels will be reached shortly after point-in-time A.
c.
The
evacuation event will commence immediately following the publication of the alert
message.
d.
All the
individual events-of-interest are fully contained within the agency’s area of
responsibility and are occurring, or are expected to begin, within the agency’s
timing of responsibility.
e.
The
area and timing of the subject event at point-in-time A covers the area
between Points A and B as well as X and Y on the diagram.
f.
Further
details beyond Point B in the larger alerting situation will be
addressed in updated messages published later. Ideally this will be done before
Point B is reached:
i. to ensure no gaps in the
alerting process, and
ii. with enough time to
provide advance notice of those details as per the agency’s operating alerting
mandate .
9)
Notably,
at Point-in-time B, the area-of-concern of the flash flood
event of interest (within the area of responsibility) is projected
to have ceased expanding.
i. Since the flash flood
event is no longer introducing new affected areas, it will not
impact lead time decisions for future alert messages.
ii. Update messages will not need to
account for new lead time related to new flash flood area .
10) Following the timing-of-responsibility
period, the flash flood event is expected to conclude once water
levels stop rising rapidly, whereas the flood event will end only
after water levels recede below flood thresholds.
a.
The evacuation
is planned to be lifted upon the end of the flood event.
b.
At point-in-time
A, the later timing-of-responsibility information beyond point-in-time
B is not critical. The timing details remains uncertain and are to
be addressed in subsequent alert message updates throughout the alerting
process.
11) In this baseline case, the
analysis of the evacuation event of interest confirms that the alerting
agency prefers the term “emergency evacuation”. Their evaluation
indicates that “emergency evacuation” creates a stronger
impression on audiences, leading to a slightly improved response
uptake compared to “evacuation emergency” or the standalone term “evacuation”.
a.
One critical
impact of an “emergency evacuation”, as opposed to simply
“evacuation”, is the necessity to evacuate as quickly as possible,
potentially leaving all non-essential belongings behind. If this is the intended
directive, the alert message should clearly address this concern,
ensuring that evacuees understand the urgency and expectations.
i. In this case, “emergency”
functions as a noun adjunct, modifying “evacuation” to specify a
particular type of evacuation response.
ii. Audiences often seek
validation of alert messages before taking significant actions. The
more context an initial message provides, the easier it is for
recipients to confirm its legitimacy and respond appropriately. Additionally,
“emergency evacuation” is a concise yet impactful term that effectively
conveys urgency without being overly wordy - ensuring that audiences
can quickly grasp the critical message while dealing with their own
situation.
iii. Another term, like “emergency”
alone, may lead to assumptions about the condition of the emergency,
potentially causing some alerts to be ignored until recipients confirm
that the situation directly affects them.
b.
Effectively
describing a situation to prompt an immediate audience response
is challenging from a social science perspective. To facilitate fast
and informed decision-making, it is essential to capture historical
insights, research findings, scientific analysis, and conventional wisdom into
the analysis.
c.
The pre-determined
business usage alert type for the alert assigned to this particular
larger alerting situation is “order” . This designation follows
a long-standing practice which consistently utilizes the “order” label
to effectively communicate an “emergency evacuation” in an alerting situation.
i. The full named alert
in this example is “emergency evacuation order.” It consists of the chosen
event type label “emergency evacuation”, and the chosen business usage
alert type label “order.”
d.
The alert
message intended for the audience will incorporate key text
elements derived from the actual analysis of the evacuation alert-worthy
event, and all the secondary alert-worthy events. These details are
to ensure that the message remains accurate, relevant, and informative.
e.
The
remaining text in the alert message will be extracted from the primary
event-type “evacuation” and the secondary event-types where
applicable. To ensure clarity and effectiveness, the alerting agency
will draw upon historical data, research, scientific analysis, conventional
wisdom, and established policies for handling evacuation events and
the secondary alert-worthy events as part of the larger alerting situation.
f.
The alerting
agency has identified a matching entry in the OASIS Open Event
Terms List for “evacuation.” As a result, any available information
related to the OASIS Open Event Term “evacuation” can now be integrated
into the originating CAP process.
i. Analysis of the alerting
agency’s event type “evacuation” determines that the appropriate CAP
category for this event of interest is “Safety.” This CAP
category assignment was established through business research
conducted well before the actual event is to be alerted.
ii. All other
events-of-interest in the larger alerting situation would also undergo this same
analysis to compliment the evacuation event-of-interest.
12)
For
the levee collapse event, see bullet 17 in the simple analysis above.
The rainfall event is treated in the same manner.
13) Note that for any one
event of interest, all other events - including additional newly
created events of interest - are classified as associated secondary
events related to the primary event.
a.
In
this situation, rainfall, levee collapse, and emergency water barrier
operations do not qualify as events of interest for alerting
purposes. However, they are still relevant and may provide valuable
contextual information.
i. These events
contribute to the overall story within the alerting process. If
any of them contain event-type information, that data should be readily
available for use as needed.
14) If the situation
analysis indicated that only a partial evacuation is necessary for
the larger impacted area, then for the non-evacuation subset
area-of-concern, a different primary event of interest may be more
appropriate. Evacuation is not the top priority in that other
subset area.
a.
The alerting
agency must decide whether to classify this event situation as one
situation or two. If two, the flash flood or flood
could take the positon of primary event of interest in the other
situation that does not involve an evacuation.
b.
A
possible directive in both subset areas would be to encourage
ongoing monitoring for updated messages. In changing situations,
especially complex-event alerting situations, the primary event of interest,
areas, and timing, can easily shift and evolve.
CAP subject-event: primary flash flood(simple), primary flash flood with
secondary flood (more advanced), primary evacuation with secondary flash flood,
flood, and emergency (fully advanced)
OASIS Open Event Term: flash flood, flood, evacuation, emergency
OASIS Open Event Term Code with CAP categories: flash flood (OET-080; Environmental,
Safety), flood (OET-82; Environmental, Safety), evacuation (OET-XXX ; Other), emergency
(OET-XXX; Safety)
Simple Message (Event-based CAP elements):
<code>layer:OASIS-Open:ETL-LT:v2.0</code>
…
<info>
…
<category>Env</category>
<category>Safety</category>
<event>flash flood</event>
…
<eventCode>
<valueName>layer:OASIS-Open:ETL-LT:v2.0</valueName>
<value>OET-080</value>
</eventCode>
<eventCode>
<valueName>[other event code scheme reference (non-OASIS Open)]</valueName>
<value>[other event code value]</value>
</eventCode>
…
<expires>[end timing of subject event]</expires>
…
<headline>flash flood warning in effect</headline>
…
</info>
1)
The primary
event-type for this baseline case example situation in the simple
analysis is the locally defined “flash flood”. Based on this event type,
specific CAP elements can be populated using stored values
associated with this event-type.
2)
The OASIS
Open EMTC recommends the <code> element is included in
all CAP messaging (from simple to advanced), where OASIS Open Event Terms
List information is to be present in the <eventCode> element.
The OASIS Open EMTC recommends the <code> element be
included exactly as shown with the value “layer:OASIS-Open:ETL-LT:v2.0”.
The inclusion of the <code> element is a simple addition to
the CAP message as it is a courtesy element for consumer use not
affecting the alerting process. Refer to the CAP Consuming Process below
for additional details regarding its value in CAP messaging.
a.
This
<code> element value signifies the presence of an additional
layer of OASIS Open-defined event-type information within the CAP
message. This extra layer enhances the standard information
contained in a CAP alert message but is not intended to replace or
override any existing standard CAP elements .
b.
The
<code> element notifies CAP consumers that the OASIS
Open Event Terms List is incorporated into this CAP message. The presence
of the <code> element provides CAP consumers with the option
to enforce stricter process handling rules when interpreting and processing
CAP alert messages .
3)
An examination
of the OASIS Open Event Terms List indicates that the most suitable event-type
match for this subject event is “flash flood.” The OASIS
Open event-type code for this situation is OET-080 and the OASIS
Open CAP Categories assigned to “flash flood” is “Environmental”.
Additionally, the listed OASIS Open subcategory for this event type is “terrestrial.”
This CAP categories and subcategory was determined by the OASIS
Open EMTC when incorporating “flash flood” into the OASIS Open
Event Terms List .
a.
As
this example is likely a Public Alert, the alerting agency has opted to include
“Safety” as an additional CAP category, citing “life” and “property” as
applicable OASIS Open subcategories in their assessment. “Safety/life”
and “Safety/property” is added to the event-type information on file.
b.
The two
<category> elements, in this example, are populated with “Env”
and “Safety” .
4)
The
<event> element, in this simple baseline case example situation,
is populated with the locally defined “flash flood” label. The <event>
element sources its value from the subject event, which for this
simple message, is composed of only the “flash flood” primary
event-of-interest.
a.
In
this instance, the “flash flood” local event term and the OASIS
Open term are identical .
5)
Other
terms that are not recommended for the <event> element
include.
a.
“flash
flood warning”, as this is an incorrect reference to the named alert, not
the event-type
b.
“flash
flood event”, as this is not the look and feel of the OASIS Open EMTC
recommended event-type naming format. The recommended format does not include
the word “event”.
c.
“flash
flood warning issued”, as this an incorrect reference to the alert,
not the event. Such text is more appropriate to a headline, not the event-type
in the <event> element.
d.
“Main
Street flood”, as this a reference to an actual named event,
not the event-type.
6)
<eventCode>
group elements may optionally be included in the CAP message and
should associate with the subject event and the larger alerting
situation. In simple cases it is one. With this User’s Guide, the aim is to
have at least one instance of this group element be present and populated with
an OASIS Open event code.
7)
One of
the multi-instanced <eventCode>.<valueName> elements
in the CAP message, the one of interest to the OASIS Open EMTC regarding
interoperability, is populated with “layer:OASIS-Open:ETL-LT:v2.0.” It
indicates a reference to version 2.0 of the OASIS Open Event Terms List -
Lookup Table for cross referencing purposes. In the simple case, other non-OASIS
Open <eventCode>.<valueName> elements in other
<eventCode> group elements would be populated with a reference to
another event code scheme.
8)
The
corresponding <eventCode>.<value> element to the <eventCode>.<valueName>
of “layer:OASIS-Open:ETL-LT:v2.0” in the <eventCode> block
in this
simple baseline case example situation is populated with OET-080 for flash flood.
a.
The OASIS
Open EMTC recommends that at least one OASIS Open event-type code be
present in every CAP message to reinforce the goal of interoperability.
b.
Any
other <eventCode> group element, based on the same or a different event
typing scheme, can be populated in a similar fashion (see the more advanced baseline
case example situation section for a case where the same event typing
scheme is used more than once).
9)
The CAP
originator does not generate the <eventCode> element for direct
audience consumption, as it is not typically presented to them in its
raw form. Instead, the <eventCode> serves primarily as a technical
reference for agents involved in filtering, routing, and
presenting activities. By incorporating an event code, these agents
can enhance presentations and execute processing actions with
greater detail and precision.
10) The expectation is
that prior to <expires> time of the CAP alert message, the initial
message’s content would likely become outdated, prompting the need for a
new message to be issued. This new issue would be before the
<expires> time, as an act to supersede the original Point A
publication. The OASIS Open EMTC recommends setting the <expires>
value to the end time of the subject event, even if the event-of-interest
is expected to be ongoing in the area of concern at that time. If
the event of interest is expected to conclude before the timing-of-responsibility
period ends, the <expires> element can alternatively be set to
the end timing of the larger event situation, which - under most
circumstances - would typically align with the subject event and the event
of interest’s conclusion as analyzed .
11)
The
<headline> element typically contains a free text headline
with the named alert as part of the headline: <headline>flash
flood warning in effect</headline>.
a.
<headline>
may or
may not be a fully formed sentence and should be devoid of capitalization and
punctuation – aside from proper nouns and intrinsic punctuation such as an
apostrophe as part of a name. Full sentence elements (such as <description>
and <instruction>) should follow standard capitalization rules,
while non-sentence elements (such as <headline> and <event>)
should be treated as text snippets. These snippets may later be merged into
larger structured text within presentations. Capitalization of text
snippets is the responsibility of the presentation agent after
the merging. The consuming agency should apply capitalization based on sentence
structure rules once a complete sentence has been formed.
b.
For
further guidance on presentation practices, refer to the OASIS Open Alerting
Practices family of documents.
12)
More Advanced Message (Event-based CAP elements
with differences from the simple messaging highlighted in grey discussed):
<code>layer:OASIS-Open:ETL-LT:v2.0</code>
…
<info>
…
<category>Env</category>
<category>Safety</category>
…
<eventCode>
<valueName>layer:OASIS-Open:ETL-LT:v2.0</valueName>
<value>OET-080</value>
</eventCode>
<eventCode>
<valueName>layer:OASIS-Open:ETL-LT:v2.0</valueName>
<value>OET-082</value>
</eventCode>
<eventCode>
<valueName>[other non-OASIS Open event code scheme reference]</valueName>
<value>[other non-OASIS Open event code value]</value>
</eventCode>
…
<expires>[end timing of subject event]</expires>
…
<headline>flash flood warning in effect</headline>
…
</info>
1)
As per
bullet 1 in the simple message, the primary event-type for this
analysis of baseline case example situation is still the locally
defined “flash flood”. Based on this event type, specific CAP elements
can be populated using stored values associated with this event-type
2)
The secondary
event-type for this example situation is the locally defined
“flood.” Based on this event type, specific CAP elements can
be populated using stored values associated with this event-type.
The OASIS Open event-type code for “flood” is OET-082.
Such secondary codes may optionally be included in the CAP
message and like the primary codes are linked to either the subject
event and larger alerting situation.
a.
The
<eventCode> element is a multi-instanced element, meaning it can
contain instances from multiple event code schemes. However, in some
cases - such as this example - it may also include multiple instances
from a single event code scheme. See the later CAP Consuming Process discussion
for this baseline case example situation for a discussion on this point
and why it is an advantage to advanced systems.
b.
The primary
event-of-interest <eventCode> for each event code scheme
should be placed first in the CAP file. While this is not a
requirement of XML or data management, it is a practical
consideration; some consuming systems only process the first code
they encounter and do not search further. By ensuring the primary
event-of-interest code appears first, it increases the likelihood
that it is successfully identified by these consuming processes .
Fully Advanced Message (Event-based CAP elements
with differences from the simple and more advanced messaging highlighted in
grey):
<code>layer:OASIS-Open:ETL-LT:v2.0</code>
…
<incidents>[incident ID (i.e. EMS-001)]</incidents>
…
<info>
…
<category>Other</category>
<category>Env</category>
<category>Safety</category>
<event>emergency evacuation</event>
…
<eventCode>
<valueName>layer:OASIS-Open:ETL-LT:v2.0</valueName>
<value>OET-XXX</value> /* evacuation */
</eventCode>
<eventCode>
<valueName>layer:OASIS-Open:ETL-LT:v2.0</valueName>
<value>OET-XXX</value> /* emergency */
</eventCode>
<eventCode>
<valueName>layer:OASIS-Open:ETL-LT:v2.0</valueName>
<value>OET-080</value>
</eventCode>
<eventCode>
<valueName>layer:OASIS-Open:ETL-LT:v2.0</valueName>
<value>OET-082</value>
</eventCode>
<eventCode>
<valueName>[other non-OASIS Open event code scheme reference]</valueName>
<value>[other non-OASIS Open event code value]</value>
</eventCode>
…
<onset>[current publish time]</onset>
<expires>[end timing of concern]</expires>
…
<headline>emergency evacuation order
in effect</headline>
…
</info>
1)
Unlike
bullet 1 in the simple and more advanced messages, the primary
event-type for this analysis of the baseline case example situation
is the locally defined “emergency evacuation”. Based on this event type,
specific CAP elements can be populated using stored values
associated with this event-type.
2)
In the
fully advanced message, the secondary event-types for this example situation are
the locally defined “flash flood”, “flood”, and “emergency”.
Based on these event types, specific CAP elements can be populated
using stored values associated with these event-types. These secondary
codes may optionally be included in the CAP message and like
the primary codes are linked to the subject event and larger
alerting situation.
3)
In the
fully advanced message, an examination of the OASIS Open Event Terms List
indicates that the most suitable event-type match for this subject
event is “evacuation.” The OASIS Open event-type code for
this situation is OET-XXX and the OASIS Open CAP Category
assigned to “evacuation” is “Other”. Additionally, the listed OASIS
Open subcategories for this event type include “other”. These categories
and subcategories were determined by OASIS Open when incorporating “evacuation”
into the OASIS Open Event Terms List .
a.
Additionally,
the secondary alert-worthy events that helped devise and form the subject
event, the “flash flood”, “flood”, and “emergency”, are also
checked for an OASIS Open event-type code. The OASIS Open event-type
code for emergency is OET-XXX and the OASIS Open CAP
Category assigned to “emergency” is “Other”. Additionally,
the listed OASIS Open subcategories for this event type include “other”.
4)
Like
bullet 4 in the simple message, the three <category> elements, in
this example, are populated with “Other”, “Env” and “Safety”.
The alerting agency policy had selected “Other” previously as the CAP
category value to store with their locally defined emergency
evacuation.
5)
The
<event> element, in this fully advanced baseline case example
situation, is populated with the locally defined “emergency evacuation.”
The <event> element sources its value from the subject
event.
a.
In
this instance, the local event term “emergency evacuation”
and the OASIS Open term “evacuation” are not identical.
The local term “emergency evacuation” should appear in the CAP message <event>
while the OASIS Open term can be obtained, if desired, by consumers
using the OASIS Open based <eventCode> element values and indexing
the values into the OASIS Open Event Terms List – Lookup Table.
b.
If no
local term is available, or if the alerting agency uses the OASIS Open Event
Terms List as provided, the terms would then match.
6)
Other
terms that are not recommended for the <event> element
include.
a.
“evacuation
warning”, as this is an incorrect reference to a named alert, not the event-type
b.
“evacuation
event”, as this is not the look and feel of the OASIS Open
recommended event-type naming format. The recommended format does not include
the word “event”.
c.
“evacuation
alert issued”, as this an incorrect reference to the alert, not
the event. Such text is more appropriate to a headline, not the event-type
in the <event> element.
7)
Refer to bullets 7 and 8 in the
simple message section as they apply.
8)
The
corresponding <eventCode>.<value> element to the <eventCode>.<valueName>
of “layer:OASIS-Open:ETL-LT:v2.0” in the <eventCode> group
element in this
simple baseline case example situation is populated with OET-XXX for evacuation.
a.
The
other <eventCode> group elements, based on the same OASIS Open
event typing scheme, can be populated in a similar fashion with OET-XXX, OET-080
and OET-082 as shown in the fully advanced example CAP
message above.
b.
See
sub bullets 2a and 2b in the previous more advanced section above as they apply.
9)
Refer to bullets 10 and 11 in
the simple message section as they apply here.
10)
The
<incidents> element should be populated with an incident ID
or incident name, if available, in accordance with the CAP standard.
If an incident identifier is provided by the alerting agency or a
partner agency, it enables consuming agencies to cross-reference
alert messages across different organizations, ensuring they are recognized as
part of the same incident situation.
11)
The
optional <onset> element is populated with the start time of the subject-event.
a.
If
present,
it will happen to match the start time of the intersection period of the evacuation
event-of-interest to the area-of-concern simply because the agency
is using the published alert message to initiate the evacuation
event. As it matches the publish time of the message, the <onset>
element could be omitted from the CAP message on the understanding that
the immediate response to the message would already be for the audience to
begin evacuating.
b.
For moving
events - though not applicable to this evacuation scenario - the
<onset> element may not be meaningful for all locations
within the area of concern. As a result, it is often omitted in
such cases. However, in the case of an ordered evacuation - where
different sections of town evacuate sequentially - the <onset>
element should reflect the timing of the first evacuation area. And then
additionally, the <discussion> element would be recommended
as the appropriate place to detail the evacuation sequence for the
remaining areas, including the specific timing for the other areas.
12)
The
<headline> element typically contains a free-text headline
that includes the named alert within it (i.e. <headline>emergency
evacuation order in effect</headline>).
CAP subject-event: primary flash flood (simple process), primary flash flood
with secondary flood (more advanced process), primary evacuation with
secondary emergency, flash flood and secondary flood (fully advanced process)
OASIS Open Event Term: flash flood, flood, evacuation, emergency
OASIS Open Event Term Code with CAP categories: flash flood (OET-080; Environmental,
Safety), flood (OET-82; Environmental, Safety), evacuation (OET-XXX; Other),
emergency (OET-XXX)
Simple Message (Event-based CAP elements):
Refer
to the Simple Message as exampled in the CAP Originating Process.
1)
The
<code> element is a courtesy element for the consuming
agent, declaring for the agent that the CAP message to follow includes special
handling elements that conform to the rules of a specific layer
or profile. The <code> element can be ignored by consuming
agencies, however, consuming agencies that make use of them are able to realize
the benefits they provide. Refer to the fully advanced message section below
for details.
a.
Supplying
the <code> element is a simple messaging activity for originators
while processing the <code> element is an advanced messaging
activity for consumers.
2)
The
<category> element is a multi-instanced element in CAP, and in
this simple baseline case example, it has a multi-instance usage. The two CAP
<category> elements in this example are populated with “Env”
and “Safety”.
a.
If
<category> element filtering is deployed, the CAP consuming agent
is recommended to process the message further simply by having at least one of the
<category> values match one of their categories of interest.
b.
They
could filter this message for specific CAP category based processing,
based on one or all of the CAP categories of interest that has a match.
c.
They
could route this message further down the path of distribution,
based on one or all of the CAP categories of interest that has a match.
d.
They
could present the message (reformatted for presentation) to an
audience based on any consuming agency special presentation rules they
may have for one or more of these <category> values.
3)
The
<event> element is populated with the value “flash flood” - a
free-text element obtained from the event-type on file with he
originating agency. This value is intended for the audience, and the
consuming agent’s role is simply to pass it through and present
it without modification.
a.
The OASIS
Open EMTC recommends that agents do not filter or route the
CAP message based on the <event> element. This element is a free-form,
audience-based display element and is not guaranteed to adhere to a standardized
set of values.
b.
The OASIS
Open EMTC recommends presenting the <event> element as
is, without modification, while optionally including a lead-in text snippet
such as: “Event type:” leading to “Event type: flash flood.” From
the CAP standard perspective, this information aims to identify the
event-type, rather than describe the specific occurrence of the event .
i. If the <event>
element were to contain something like “gale force wind”, the suggested OASIS
Open event-type would be given as “wind.” OASIS Open does not
incorporate externally managed scale-based typing schemes, however, the
originator is free to describe the <event> for the audience with
terms that best fit their service .
4)
The
optional <eventCode> element is populated in this example case with the OASIS
Open event-type code for flash flood. A CAP consuming agent -
by detecting a matching flash flood <eventCode> within its
list of event codes of interest - would continue to process the message.
a.
They
could filter and/or route the message for processing and
delivering the message further down the path of distribution.
b.
They
could present the message (reformatted for presentation) to an audience based
on any consuming agency special rules this <eventCode>.
c.
Relying
on keyword searches within a human-oriented alert message can
result in processing failures. Using event codes ensures efficient
filtering and reliable identification of relevant events-of-interest.
5)
The
<expires> time marks the point-in-time B when the alert
notification signal should be discontinued, as per instruction from
the CAP originating agency. If <expires> is provided, it is
set at point-in-time A (the time of publication) to some future point-in-time
B, with the expectation that the CAP message will expire at point-in-time
B, or be superseded by a newer, updated message, prior to point-in-time
B.
a.
This superseding
aspect is a hard rule in CAP. It effectively resets the existing and active
alert notification signal to a new <expires> time. The
signal continues and the carried information changes. It has been adjusted to
remain current and actionable .
b.
If the
<expires> time is reached before a new message arrives, the
existing message presentation should be discontinued. Some originators
let messages self-expire without a new message to formally end the alert
notification signal.
6)
The
<headline> element is a free-form snippet of text
element intended for the target audience. The consuming agent's role
is to incorporate it into a presentation with some modification . The <headline>
element should arrive devoid of capitalization and punctuation
– aside from proper nouns and intrinsic punctuation (i.e. an apostrophe or
hyphen as part of a name).
a.
<headline>
text snippets may be merged into larger structured presentations. Capitalization
of text snippets is the responsibility of the presentation agent
based on sentence structure rules once a complete structured presentation has
been formed.
b.
More Advanced Message (Event-based CAP elements):
Refer
to the More Advanced Message as exampled in the CAP Originating Process.
1)
The CAP consumer processes the More Advanced Message in the same manner as processing the Simple Message. In this process,
however, the CAP consumer will find two <eventCode> values from the OASIS
Open Event Terms List.
2)
The
two OASIS Open <eventCode> elements are populated - one
with the event-type code for flash flood, and another with the event-type
code for flood. A CAP consuming agent - upon detecting one
or more matching <eventCode> values within its event
codes of interest - would continue to process the CAP message in
accordance with their standard processing procedures.
a.
The
goal is to simplify the originating and consuming processes. The
originating agency includes the two that apply to the subject event, and the consuming
agency looks for event-types of interest to them. The OASIS Open EMTC
recommends the consuming agency take each <eventCode> in-turn and checks
their own list for a match, and if at least one code of interest is found, they
continue processing the message.
i. If the CAP originating
agent includes only one instance of the <eventCode> element, the in-turn process
is not compromised. Many CAP originators think to put only one instance into a
CAP message.
ii. A CAP consuming agent's
ability to rely on a CAP originating agent to put at least one
instance into the CAP message is based on mutual agreement. Such
agreements are typically established between partner organizations and
are reinforced within CAP through the use of layers and profiles . With the presence of the
OASIS Open Event Terms List, agreements can be made upon a pre-existing
and maintained list to reduce the work effort to establish such a list.
Fully Advanced Message (Event-based CAP elements):
Refer
to the Fully Advanced Message as exampled in the CAP Originating Process.
1)
The CAP consumer processes the Fully Advanced Message in
the same manner as processing the More Advanced Message. In this
process, however, the CAP consumer will find four <eventCode> values from
the OASIS Open Event Terms List.
2)
Four OASIS
Open <eventCode> elements are populated - one with the event-type
code for evacuation, one with the event-type code for emergency, another
with the event-type code for flash flood, and a fourth with the event-type
code for flood. A CAP consuming agent - upon detecting one or
more matching <eventCode> values within its event
codes of interest - would continue to process the CAP message in
accordance with their standard processing procedures.
a.
The
goal is to simplify the originating and consuming processes. The
originating agency includes the four that apply to the subject event, and the
consuming agency looks for event-types of interest to them. The OASIS Open EMTC
recommends the consuming agency take each <eventCode> in-turn and checks
their own list for a match, and if at least one code of interest is found, they
continue processing the message.
3)
The
<incidents> element is optional and serves as a mechanism
for consuming agencies to cross-reference alert messages that
pertain to the same incident event. While primarily used to link
messages from different agencies, it can also apply to multiple alerts
issued by the same agency for a single incident. For example, if
the flash flood, flood, and evacuation event situation, was to be
conducted as three separate alerts, they could be tied together by
assigning them the same <incidents> value, ensuring a
means to cross-reference the related alerts .
4)
The
<onset> element, when present, specifies the start time of
the subject event. It does not have a compliment timing element for the end
time of the subject event. <onset> should be presented as a distinct
value, similar to event type and headline (i.e. “Event
start timing: [onset time]”. The phrasing and formatting of the <onset>
time should be adjusted by the CAP consuming agent to ensure it
is more audience-friendly than the existing standard format for this CAP
element .
5)
The
<headline> element is processed the same as in the simple CAP
message, except it will likely have a different value based on a different
primary event-of-interest.
This section will be generated with example situations to demonstrate
many of the concepts discussed in the OASIS Open Event Terms List - User’s
Guide and the OASIS Open Event Terms List - Concept Guide. As an
unfinished section, and as part of this Public Review stage, work will be taken
to expand the section during the Public Review process. New example content
will either be inserted here, as part of this Users’ Guide, or placed
into the Concept Guide. The provided examples will run the spectrum of
simple to fully advanced involving many different event-types.
A.1 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
Johannes Fleisch
EUMETNET
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
Norm Paulsen individual
Scott Robertson Kaiser
Permanente
Andreas
Schaffhauser EUMETNET
Jeff Waters US
Department of Defense (DoD)
Jacob Westfall Individual
Herbert White NOAA/NWS
Kai Roddeck MECOM
Kasia Mohammed Google
Mandy Best MECOM
Rainer
Kaltenberger Individual
Spencer Williams FEMA
Thomas Wood Disaster
Relief Communications Foundation
A.2 CAP Subcommittee Participants
The CAP Subcommittee is Chaired by Jacob
Westfall who has led the committee in the development of this Public Review
Committee Note. The tireless efforts of Thomas Wood and Norm Paulsen supported
by lead editor Rex Brooks have made this document possible. The following
individuals have participated in the subcommittee creating this lookup table
reference and are gratefully acknowledged:
Andrea Hardy NOAA/NWS
Andreas Schaffhauser EUMETNET
Elysa Jones Individual
Johannes Fleisch EUMETNET
Gary Ham Individual
Herbert White NOAA/NWS
Jacob Westfall Individual
Kai Roddeck MECOM
Kasia Mohammed Google
Mandy Best MECOM
Mark Wood Disaster
Relief Communications Foundation
Mike Gerber NOAA/NWS
Norm Paulsen Individual
Rainer Kaltenberger Individual
Rex Brooks Individual
Spencer Williams FEMA
Thomas Wood Disaster
Relief Communications Foundation
A.3 Special Thanks
The Committee would like to acknowledge the
assistance provided to the work of the initial CN from:
Frank Bell Kybernetix
|
Revision
|
Date
|
Editor
|
Changes
Made
|
|
01
|
01-10-2025
|
Norm Paulsen
|
First Complete Public Review
Draft
|
|
02
|
|
|
|
|
03
|
|
|
|
|
04
|
|
|
|
|
05
|
|
|
|
