CAP dictionary issues (was Re: [emergency-msg] SC meetingreminder)

[Art Botterell <acb@incident.com>]

Jerry -

Thanks for shining a light on a few of the key issues here.  We won't 
have time to do all your points justice on tomorrow's call, backed up 
as we'll be against the TC call.  So let me me offer a few top-level 
notes below and then we can drill into some or all of these issues 
further in email discussions and future conference calls.

Hope you don't mind, but I'm sharing this with the rest of the SC 
list, so everyone can participate in the discussion and (very 
important) so it gets into the SC record.

Also... I may be setting a bad precedent here.  The kind of 
point-by-point dialog on multiple issues that appears below is handy 
for one-to-one but can get unwieldy and confusing in group 
discussions.  So if anyone wants to pursue any of these issues, maybe 
it would be wise to address each one in a separate email so folks can 
follow the threads they care about more easily.

That said, here goes...

At 6:17 PM -0500 6/2/03, Weltman, Jerry wrote:
>Cap:event_cat: What is the purpose of this element? Is it to indicate which
>organizations would be responsible for handling the alert?

It's chiefly to allow receiving systems to determine whether its a 
message to which that device should respond, and secondarily to 
inform message routing systems.  And to provide a categorization for 
later indexing too, I suppose.  Basically for any automated process 
that cares about hazard type but isn't brainy enough to interpret the 
free-text description in <event_desc/>.

The current list is definitely up for discussion... I've been told 
there's a standard list of 23 or so hazard types out there 
somewhere... maybe someone can provide a pointer?

One difficulty is that it's easy unconsciously to slip-slide between 
a typology of causes and one of effects.  The current list tries to 
keep the focus on which systems are affected, since the underlying 
causes are frequently uncertain until long after the alerting 
timeframe.  But obviously it fails to reach that goal at several 
points.

Allowing multiple instances of this element sounds like it might make sense.

>Cap:info_url: It seems too limiting to have only three types of URLs (HTML,
>image, and audio). I would like to consider allowing multiple instances of
>arbitrary types.

The problem with arbitrary types, of course, is that it's hard to 
build applications to process binaries without some advance notion of 
what they might be.  If there are other types we envision wanting to 
support, we should probably add them explicitly now so implementers 
can take advantage of them.

A related question is whether to use links or to take some other 
approach like SOAP-with-Attachments that would keep the binary 
packaged with the CAP message.  The Working Group opted for links to 
keep the messages lightweight and to avoid making a SOAP 
implementation mandatory, but we can change that if it seems wiser.

>Cap:severity: I like the idea of a standard set of severity levels, but one
>problem is that different agencies will need to have more information on how
>the severity level applies to the specific event. For example, the CSEPP
>community has three levels of severities for a chemical release: AEGL-1,
>AEGL-2, and AEGL-3. It would great if the CAP could have a place where "No
>Effects" could be mapped to "AEGL-1", "AEGL-2" to "Moderate", etc.
>Specifically, the Cap:severity element could have a sub element that maps
>the standard category to the specific event severity.

I'm doubtful that any one scheme that will map conveniently to all 
existing priority scales.  E.g, how does one map AEGL-1,2,3 to 
Watch/Warning or Green/Blue/Yellow/Orange/Red?  Not only don't they 
align very well, they aren't even talking about the same things, 
really.

Part of the problem is precisely that most existing schemes conflate 
the three dimensions of Urgency, Severity and Certainty into a single 
vector, with the relative weight given each of the three components 
varying widely (and frequently being inconsistent even within a 
single scheme).

There's also an important distinction between the severity of the 
event and that of its effects.  An earthquake, for example, has an 
absolute magnitude (measured on the Richter scale) but its effects 
will vary from location to location (thus the modified Mercalli 
scale.)  Likewise a Category Three hurricane may be catastrophic at 
one location but merely inconvenient eighty miles away.  What we're 
describing in the <info/> block is the severity of effects... and we 
can use multiple <info/> blocks to represent the different impacts on 
different areas.

Of course the <parameter/> element can be used to insert any type of 
system-specific coding, but relying on that could undermine our goal 
of interoperability.  More frequently, I imagine, system-specific 
conversion tables (or algorithms) will be devised to map between 
"native" schemes and the U/S/C model.  Ultimately, perhaps, once CAP 
wins broad acceptance its nomenclature might be adopted as the 
default.  But that'll take a long, long time if it ever happens at 
all.

>Info Block Mandatory Elements: For jurisdictions that need to provide
>alerting to hundreds of emergency planning zones and/or thousands of
>individual facilities, there could be thousands of Info blocks.

Depends on whether those thousands of zones are getting different 
information or not.  A single <info/> block can contain multiple 
<area/> blocks, so all the zones that got essentially the same 
message could be handled in a single <info/> structure.

In most cases there are only a few distinct information sets 
issued... rarely if ever will both the source information and the 
decision-making process be so granular as to provide thousands of 
different versions.  (But, if it were necessary, the current 
structure could do that, at least in theory... it would be ugly and 
inefficient, but possible.)

As for how the area(s) would be described... how do such schemes 
represent such large and complex areas now?  Whatever they do now 
could be inserted in the <area_code/> element, of course... but with 
an obvious and somewhat self-defeating sacrifice of interoperability.

The better answer, I think, would be to convert the aggregation of 
those local zones into the more portable CAP geospatial form at the 
sending point... in order to achieve interoperability with systems 
that might not know all the details of every local zoning scheme.

>One problem is that the Info blocks have mandatory elements 
>(cap:category, cap:urgency, cap:certainty, cap:severity) that do not 
>provide the information that
>individual facilities need. Ideally, these elements could be made optional.

What information is it that won't fit into the current structure?  As 
you understand, we aren't trying to invent a universal message type 
here, but rather one specifically for alerting.  And we have the 
<parameter/> element as our catch-all.  But if there's something 
germane to the alerting function that we don't provide now, maybe we 
need to add it.

- Art



At 6:17 PM -0500 6/2/03, Weltman, Jerry wrote:
>Art,
>
>Here are some topics that I would like to consider discussing at the meeting
>tomorrow regarding the CAP data dictionary.
>
>Cap:event_cat: What is the purpose of this element? Is it to indicate which
>organizations would be responsible for handling the alert? Is it to
>categorize the event for record-keeping? It seems vague at some times (e.g.
>"Rescue and Recovery" and "Safety"). I am not sure which category to use for
>something like "terrorist chemical event" or civil disorder. I would like to
>talk about a categorization scheme similar to that of the District of
>Columbia's District Response Plan:
>
>	Natural hazards - Severe weather, hurricanes, tornadoes, flooding,
>or earthquakes.
>
>	Infrastructure disruptions - Utility and power failures, water
>supply failures, critical resource shortages, or exploding manhole covers.
>
>	Human-caused events and hazards - Urban fires, special events, civil
>disorder, or transportation accidents.
>
>	Technological hazards - Hazardous materials, radiological,
>biological, or computer-related incidents.
>
>	Terrorist incidents - Bomb threats, sabotage, hijacking, or armed
>insurrection, which threaten life or property. Traditional terrorist events
>cam also be conduits through which biological, chemical, and radiological
>events can be employed. Cyberterrorism poses a less obvious threat to
>District residents and infrastructure.
>
>
>Cap:info_url: It seems too limiting to have only three types of URLs (HTML,
>image, and audio). I would like to consider allowing multiple instances of
>arbitrary types.
>
>Cap:severity: I like the idea of a standard set of severity levels, but one
>problem is that different agencies will need to have more information on how
>the severity level applies to the specific event. For example, the CSEPP
>community has three levels of severities for a chemical release: AEGL-1,
>AEGL-2, and AEGL-3. It would great if the CAP could have a place where "No
>Effects" could be mapped to "AEGL-1", "AEGL-2" to "Moderate", etc.
>Specifically, the Cap:severity element could have a sub element that maps
>the standard category to the specific event severity.
>
>Info Block Mandatory Elements: For jurisdictions that need to provide
>alerting to hundreds of emergency planning zones and/or thousands of
>individual facilities, there could be thousands of Info blocks. One problem
>is that the Info blocks have mandatory elements (cap:category, cap:urgency,
>cap:certainty, cap:severity) that do not provide the information that
>individual facilities need. Ideally, these elements could be made optional.
>Even better, there could be a "InfoGroup" block that would allow
>jurisdictions to summarize information for a large group of Info blocks so
>that the same information is not repeated thousands of times.
>
>
>Thanks,
>Jerry
>-----Original Message-----
>From: Art Botterell [mailto:acb@incident.com]
>Sent: Monday, June 02, 2003 2:37 PM
>To: emergency-msg@lists.oasis-open.org
>Subject: [emergency-msg] SC meeting reminder
>
>Friends -
>
>Just to remind you that the Notification Methods and Messages
>Subcommittee will be teleconferencing tomorrow (Tuesday, June 3rd) at
>12:30 PM Eastern, 9:30 AM Pacific... 1-800-453-7412 # 604776
>
>We'll be discussing the draft CAP data dictionary and how to refine
>it... and any other issues arising... before transitioning into the
>full TC meeting at 1PM / 10AM.
>
>Thanks!
>
>- Art
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org