Re: CAP Best Practices

[Anthony Mancuso <amancuso@google.com>]

I looked at the Canadian CAP feeds best practices doc that Doug had been working on (which ge attached to an earlier email in this thread). The following best practices from that doc may have application to and find a place in our Example Practices: CAP Feeds doc:

I suggest that we discuss these points at our next EMA Collaboration and Documentation SC meeting:

Feed(s) Content

1. CAP feeds open to public consumption should be limited to CAP <scope> “Public” and

CAP <status> “Actual”.

2. Produce “current” (not expired) message feed(s) in addition to the traditional “log”

(chronological order) or all messages approach.

3. Produce language specific feeds.

Feed Entries per CAP-CP Message

1. When a message has multiple <info> blocks in the same language, which can be used

to provide differing alert content (ex. Same storm, with areas having different severity),

each <info> block should align with separate feed entries).

2. When a message has multiple event references, one feed entry per event reference

should be created.

Feed Title

The feed title should minimally identify the name of the source. Language and CAP scope are

also recommended.

a. Example: NB MASAS Alert Feed: English Public

Feed Item Presentation

1. Item Title

a. Title can be constructed from the CAP <event> and <msgType> elements

i. Examples:

1. Industrial Fire, Update

2. Bridge Closure, Alert

2. Item Content

a. Item content should minimally include the following:

i. “Description: “CAP <description>.

1. If truncated, an indicator should be included. Ex. “…” or “(more).”

ii. “Expires: “CAP <expires>

iii. “Originated from CAP Alert: ”CAP <sender>”, “<sent>”, “<identifier>”

iv. “Location relates to” either “alert area” or “event location”.

b. When the CAP message includes a <web> value, the feed item should include a

link to it.

i. A statement such as, “For more information, click here”, with click here

hyperlinked to the URI value of CAP <web>, is suggested.

c. Example:

“Description: Bow Valley fire perimeter.

“Expires: September 5 2009 10 PM CT

“Originated from CAP Alert: AEMA, 2009-09-01T16:49:00-06:00, B7G456

“Location relates to event location.

On Tue, Jan 22, 2013 at 4:40 PM, Anthony Mancuso <amancuso@google.com> wrote:

Thanks Doug for the comments on both docs. I will incorporate some myself, and pass others on for review by my co-worker at Google, Yu Chen. I am also sharing them with the emergency management adoption docs subcommittee and the emergency management TC lists for others to consider as we converge on final docs for both CAP elements and CAP feeds. We really appreciate your CAP experience and expertise.

Tony

On Tue, Jan 22, 2013 at 2:25 PM, Doug Allport <doug@allport.ca> wrote:

Tony, Tom

Thanks for the efforts here and for pinging me directly Tom. I'm swamped or you'd see more of me. On the plus side, more than 20 years of pushing public alerting, about 15 years of pushing open standards, about 7 years of pushing shared situational awareness using CAP and Atom, and about 7 years of pushing for a national not for profit to own the risk governments will not, are all coming together. It is a very demanding and rewarding time for me and the country.

Comments follow. 

Example Practices: CAP Elements

2.2 A Canadian public/private public alerting technical tiger team just concluded we should aim to deliver all relevant content to be presented by a last mile distributor (LMD) in a single field rather than multiple fields. Further, we concluded we should use <parameter> for channel specific content. E.g. <valueName>televisionContent<valueName>. This is practiced in the Alberta alerting system that received an innovation award from IAEM. It's about to become common in national system. 

2.4 second bullet. Suggest you might add "…while others may assume it could be very urgent; unknown is value with a clear purpose.".

3.3 Canadian Profile of CAP leaves expires optional, as does Alberta, but the National Alert Aggregation Dissemination (NAAD) system makes mandatory. A move to make it optional is under way. The reason is the misunderstanding of what expires pertains to. It is being assumed to be the event and not the message. This leaves too much room for misinterpretation. E.g. Boil water with a message expiry of 6 hours is interpreted as boil water for six hours, when the event will at a minimum go on for days. The loss of public confidence when the message is incorrect is of concern to alert issuers. Ideally we'd identify message duration from hazard duration in CAP 2.0. 

Example Practices: CAP Feeds

- II.a.  Use the URI www.cap-cp.ca as CAP-CP documents are to be moved from the CAPAN website to a new location in next few months. This URI will point to where ever they may land.  

- I was expecting to see something about style sheets for presentation of CAP to the public, and a note that presenting raw XML is not appropriate. Better yet, link the alert to consumer friendly webpage. 

- When we looked at feeds from CAP-CP we proposed inclusion of event and location reference codes that could be filtered on by apps. Perhaps a note that relates to specific country examples like Canada where each alert will have an event code and at least one location code. They can be presented as symbols, polygons, etc. 

- In an earlier email I noted that some Canadian weather alerts have multiple <info> blocks in the same language, as well as a second language. As an example, a major storm may have an area equivalent to a watch, warning and advisory, or more than one of each. Environment Canada will package them all in one alert. How will they be presented to the public? I had concluded we needed one feed item per each <info> block, as they are viewed as individual alerts to the public, but one alert within a system. 

- Note on previous point. Initially last mile distributors like radio stations did not like the multiple <info> blocks, but it appears they and their broadcast intrusion device vendors have warmed up to them. This practice can significantly reduces the number of alerts issued per event, and can significantly reduce the number of times a radio station is interrupted. One event (e.g. weather) has one alert associated with it, rather than one per location. The broadcaster looks at the alert, and updates, and determines if for them. If by location, they might then have to issue the same alert content multiple times, once for each alert for each of the areas their signal reaches. We looked at how we might break the multiple <info> block alerts up and re-originate the <info> blocks as individual alerts, and updates got very messy, especially as the evolving event splits, merges, etc.  

I hope this helps.

Cheers,

Doug

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

From: Anthony Mancuso <amancuso@google.com>
Date: Tuesday, 22 January, 2013 3:18 PM
To: Doug Allport <doug@allport.ca>

Subject: Re: CAP Best Practices

Hi Doug,

The primary focus of the doc is to disseminate CAP alerts directly to the public, so using it as a trigger for further processing/encapsulating in an EDXL message by originators is a bit off topic for this doc (IMO). Makes sense though to use feeds for this purpose.

Tony

On Tue, Jan 22, 2013 at 12:00 PM, Doug Allport <doug@allport.ca> wrote:

Is it consistent with where you are, are going, …? Do you agree with the need for the separation of purposes?

Doug

From: Anthony Mancuso <amancuso@google.com>
Date: Tuesday, 22 January, 2013 2:57 PM
To: Doug Allport <doug@allport.ca>
Cc: Tom Ferrentino <tferrentino@verizon.net>

Subject: Re: CAP Best Practices

Thanks Doug. this is good information.

Tony

On Tue, Jan 22, 2013 at 11:41 AM, Doug Allport <doug@allport.ca> wrote:

Tom, Tony

Sorry for neglecting this document, but you will be pleased to know it's been open on my desktop all day for review before I shut down tonight. I'm currently engaged in a national discussion on the role of alert feeds and wanted to see if you have covered the two primary roles we are using them for:

1. We are using them as an indicator of a CAP alert is available for processing, and in some cases an envelope similar to the role of EDXL-DE. I.e. System role

2. As a consumer product, which typically links back to content formatted for public consumption.

In example one it's really just an indicator and a one to one relationship between CAP and feed items. In the second example, we'd propose it's a many to one relationship, with one feed entry per each <info> block. Our weather alerts, as an example, are English and French, and many include more than one <info> block per language.  

Cheers,

Doug

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 

A/General Manager 

Multi-Agency Situational Awareness Systems - National Information Exchanges (MASAS-X)
Under contract to the Centre for Security Science, DRDC, Government of Canada
Doug.Allport@MASAS-X.ca

From: Tom Ferrentino <tferrentino@verizon.net>
Date: Tuesday, 22 January, 2013 2:26 PM
To: Doug Allport <doug@allport.ca>, Anthony Mancuso <amancuso@google.com>
Subject: CAP Best Practices

Doug,

 

I would like to introduce to Anthony Mancuso. Anthony is from Google and has been working with the collateral and documents subcommittee along with Google staff on a CAP Feed example practices document. CAP-CP is also referenced in the document. Please feel free to participate in our discussions. The most recent document is attached to this email.

 

Take Care

 

Tom Ferrentino

716 913 4453

 

P.S.

Have box tickets to tonight’s Caps vs. Sens game at the Verizon Center…