OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


Subject: Profiles and Layers


As noted during the June 19 Emergency Management (EM) – Technical Committee (TC) meeting, some Canadian members of the EM-TC would like to contribute to the concept of OASIS managed “layers” for EM standards. I’m writing on their behalf, and hope that I have accurately reflected that which we discussed. 

Please note that while the examples are specific to the Common Alerting Protocol (CAP), this document is written with all EM standards in mind. 

Profiles

As many of you know, the Canadian Profile of the Common Alerting Protocol (CAP-CP) has been adopted and implemented in two Canadian national alerting systems, and one provincial system. 

Our Profile is much more “business of alerting” oriented than it is a technical document. In fact, the concepts and components of CAP-CP are well suited to being implemented with other EDXL standards as well, and many are expected to be. 

To date, CAP-CP has been managed as a “national” profile that is impartial to any one system, distribution channel, stakeholder group, purpose, etc. We emphasize that this has not been without its challenges. 

The introduction of something we called a “layer” has played a very important role in supporting this objective.  The term layer is not new, and seemed to have fit the need.


Layers

“Layers” are being used to document system specific, channel specific, community specific, and purpose specific values (and sometimes rules) associated with CAP alerts in Canada.  They are often viewed as horizontal implementations for specific communities, whereas profiles and the CAP standard tend to be viewed here as vertical implementations. Like the CAP-CP profile, they are just a manifestation of CAP-XML extensions in the CAP specified format.

For the most part, CAP layer formats are limited to <parameter> valuenames and accepted values. The valuenames have a Canadian Profile defined format and include a set of tokens to specify certain information such as who owns/manages them. E.g. layer:CAPAN:eventLocation:point. 

The growing list of CAP Layers in Canada includes the following:

1.	CAPAN CAP Event Location Layer, which specifies <parameter> valuenames for an events location in a CAP alert. E.g. Point, line, polygon, circle. 

2.	The Alberta Alert System CAP Layer, which identifies <parameter> valuenames for broadcast channel specific text. E.g. Television crawler, SMS, Tweets. This adds clarity for distributors, and takes the pressure of placing system specific implementation restrictions on CAP <headline> and <description> fields. 

3.	The Earthquakes Canada CAP Layer, which identifies <parameter> valuenames for the inclusion of scientific data associated with earthquakes. E.g. Magnitude, depth.

4.	The Canadian Space Weather CAP Layer, which identifies <parameter> valuenames for the inclusion of scientific data associated with space weather. E.g. Intensity measurement. 

5.	The Senior Officials Responsible for Emergency Management (SOREM) Broadcast Intrusive Flag, which identifies a <parameter> valuename and values for identifying alerts that meet specific conditions that have been identified for immediate broadcast. The value corresponds with a table of CAP-CP event names/codes and CAP urgency, certainty and severity values. 

6.	The Environment Canada CAP Layer, which specifies additional event and location references found in alerts issued by them. These include SAME codes. 

As noted above, these layers have taken the pressure off the national profile to address every specific use case for CAP in Canada. When faced with a new challenge, we now have multiple options for addressing them. Layers are something that can be implemented quickly and unilaterally. 

Global Layers

Taking the idea of Layers (and or profiles) global requires some oversight as interoperability may be impacted. 

Looking at the first four layer examples above, they each have value to other similar members in the global community. And ideally there would be one globally accepted valuename format for the common values used, rather than one per country. 

In a few cases, such as earthquakes, there might be a global stakeholder or venue to own and manage a simple layer specification. However, we would expect it to be years before most communities would get to the point of being able to manage such specifications. 

Role for OASIS 

We are hopeful that the OASIS EM TC and or Adoption committees give consideration to defining the role of profiles and layers, the format for profile and layer valuenames, managing global lists of profile and layer definitions, and developing profiles and layers as committee specifications for the global community. 


The ideas represented here are not new and have been discussed many times. We are simply sharing some background material before a direction is taken within OASIS on profiles. We look forward to supporting the discussion. 

This submission was created with support from OASIS EM TC members Norm Paulsen, Jacob Westfall, Darrell O’Donnell and CAP-CP WG member Khalil Hayek.

Cheers,
Doug Allport
Executive Director (Volunteer)
Canadian Association for Public Alerting and Notification (www.CAPAN.ca)
Doug.Allport@CAPAN.ca | (613) 271-1040 Office | (613) 294-4425 Mobile


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