Understanding Emergency Routing Policies with EDXL Using the Distribution Element and the ValueListURN Tutorial Example Policy Implementation: Sensors.

Understanding Emergency Routing Policies with EDXL

Using the Distribution Element and the ValueListURN Tutorial

Example Policy Implementation:Sensors at Checkpoints

Example Policy Implementation:Sensors at Checkpoints

Overview Intro

Background, Purpose, Ease of Use

Scenario & Sample Policy ValueListURN Examples

ValueListURN, ValueListURL, DE Header

Policy List Implementation Basic, Better, Best “Triples”: Subject, Property, Value Additional Benefits of Web Ontology Language (OWL)

Tools Protege, SPARQL, Joseki, JENA

Conclusion

Background

The Distribution Element (DE) a standard wrapper for flexible and tailorable routing of

emergency management messages

The ValueListURN provides a reference to an externally managed list of terms,

routing policies and rules used for representing sender, receiver and keywords in the

DE header allows for different routing policies to be used by different

jurisdictions for different purposes

Purpose This tutorial is designed for new users

how to understand routing policies using the ValueListURN An example implementation

A simple example policy For educational purposes

Goal How to use the ValueListURN and Distribution Element (DE)

interact with your routing policies Example uses current web-based architecture and freely

available tools More sophisticated and automated DE-aware routers can be

purchased for production level needs

Is this easy? The DE

simple and easy to use

The ValueListURN simple and explained on the next slide

Your Policies Simple or complex depending on your needs

The Web Ontology Language (OWL) The basics of using OWL will be explained simply here Details of OWL are interesting but not required for our

purposes

An Example Checkpoint Scenario A Simplified Scenario for any checkpoint

e.g. entrance portal to event e.g. border crossing e.g. airport

5 steps to manage simplified checkpoint Initial sensor detection alert (message 1) Vetting to eliminate false alarm (message 2) Corroboration & Decision-Making (message 3) Local Response (message 4) Access to remote expert (message 5)

Consider: If real event unfolding, who would want to know what and when

Sample Notification Policy

Initial Detection Notification Policy – Message 1 Sent to: “Repository”: stored for audit/history “VettingAuthority”: local personnel responsible for vetting “PrimaryResponse”: those first in line to respond if event is

real “ResponseSubscribers”: any potential responding or

responsible agency personnel who choose to subscribe One person might subscribe at each responsible agency

“PartnerSubscribers”: Any nearby or partnering jurisdiction personnel if MOU in place who choose to subscribe

ValueListURN Specifies a list of terms by a unique name

e.g. urn:<youragency>:<yourdept>:<listName> Values can then be used from that list

<recipientRole> <valueListUrn>urn:myagency:gov:sensors:recipientRole</valueListUrn> <value>VettingAuthority</value> <value>PrimaryResponse</value></recipientRole>

<recipientRole> <valueListUrn>urn:myagency:gov:sensors:recipientRole</valueListUrn> <value>VettingAuthority</value> <value>PrimaryResponse</value></recipientRole>

ValueListURN Example: Recipient Role

<keyword> <valueListUrn>urn:myagency:gov:sensors:keywords</valueListUrn> <value>Checkpoint_3</value> <value>Raw_Sensor_Alert</value></keyword>

<keyword> <valueListUrn>urn:myagency:gov:sensors:keywords</valueListUrn> <value>Checkpoint_3</value> <value>Raw_Sensor_Alert</value></keyword>

ValueListURN Example: Keywords

ValueListURL? Proposed change for DE

e.g. http://<youragency>/<yourdept>/<listName> Values can then be used from that list without need for

registry lookup

<recipientRole> <valueListUrn>http://myagency/gov/sensors/recipientRole</valueListUrn> <value>VettingAuthority</value> <value>PrimaryResponse</value></recipientRole>

<recipientRole> <valueListUrn>http://myagency/gov/sensors/recipientRole</valueListUrn> <value>VettingAuthority</value> <value>PrimaryResponse</value></recipientRole>

ValueListURL Example: Recipient Role

<keyword> <valueListUrn>http://myagency/gov/sensors/keywords</valueListUrn> <value>CheckPoint_3</value> <value>Raw_Sensor_Alert</value></keyword>

<keyword> <valueListUrn>http://myagency/gov/sensors/keywords</valueListUrn> <value>CheckPoint_3</value> <value>Raw_Sensor_Alert</value></keyword>

ValueListURL Example: Keywords

Sample DE Header for Message 1<EDXLDistribution xmlns="urn:oasis:names:tc:emergency:EDXL:DE:1.0"> <distributionID>http://myhost.com/packages/17</distributionID> <senderID>[email protected]</senderID> <dateTimeSent>2009-11-15T16:53:00-05:00</dateTimeSent> <distributionStatus>Exercise</distributionStatus> <distributionType>Report</distributionType> <combinedConfidentiality>unclassified</combinedConfidentiality> <language>EN</language> <recipientRole> <valueListUrn>urn:myagency:gov:sensors:recipientRole</valueListUrn> <value>Repository</value> <value>VettingAuthority</value> <value>PrimaryResponse</value> <value>ResponseSubscribers</value> <value>PartnerSubscribers</value> </recipientRole> <keyword> <valueListUrn>urn:myagency:gov:sensors:keywords</valueListUrn> <value>Checkpoint_3</value> <value>Raw_Sensor_Alert</value> <value>Sensor_Hazard_Level_2</value> </keyword> <targetArea> <polygon>33.4745,-112.1174 33.4745,-112.0238 33.4238,-112.0238 33.4238,-112.1174 33.4745,-112.1174</polygon> </targetArea> <contentObject> <xmlContent> <embeddedXMLContent> [... INSERT YOUR XML PAYLOAD HERE, e.g. Common Alert Protocol (CAP) message ...] </embeddedXMLContent> </xmlContent> </contentObject></EDXLDistribution>

<EDXLDistribution xmlns="urn:oasis:names:tc:emergency:EDXL:DE:1.0"> <distributionID>http://myhost.com/packages/17</distributionID> <senderID>[email protected]</senderID> <dateTimeSent>2009-11-15T16:53:00-05:00</dateTimeSent> <distributionStatus>Exercise</distributionStatus> <distributionType>Report</distributionType> <combinedConfidentiality>unclassified</combinedConfidentiality> <language>EN</language> <recipientRole> <valueListUrn>urn:myagency:gov:sensors:recipientRole</valueListUrn> <value>Repository</value> <value>VettingAuthority</value> <value>PrimaryResponse</value> <value>ResponseSubscribers</value> <value>PartnerSubscribers</value> </recipientRole> <keyword> <valueListUrn>urn:myagency:gov:sensors:keywords</valueListUrn> <value>Checkpoint_3</value> <value>Raw_Sensor_Alert</value> <value>Sensor_Hazard_Level_2</value> </keyword> <targetArea> <polygon>33.4745,-112.1174 33.4745,-112.0238 33.4238,-112.0238 33.4238,-112.1174 33.4745,-112.1174</polygon> </targetArea> <contentObject> <xmlContent> <embeddedXMLContent> [... INSERT YOUR XML PAYLOAD HERE, e.g. Common Alert Protocol (CAP) message ...] </embeddedXMLContent> </xmlContent> </contentObject></EDXLDistribution>

The DE Header uses the ValueListURN to reference policy lists ....What do these policy

lists look like?

Message 1: Policy List Simple List of Email Addresses

Simple, but brittle, difficult to maintain, no flexibility

Sensor_Hazard_Level_2emailAddress1emailAddress2emailAddress3emailAddress4emailAddress5

Sensor_Hazard_Level_2emailAddress1emailAddress2emailAddress3emailAddress4emailAddress5

Message 1: Better Policy List

Sensor_Hazard_Level_2emailAddress3emailAddress4emailAddress5

Sensor_Hazard_Level_2emailAddress3emailAddress4emailAddress5

Sensor_Hazard_Level_1emailAddress1emailAddress2

Sensor_Hazard_Level_1emailAddress1emailAddress2

ResponseSubscribers_Level_2emailAddress6emailAddress7

ResponseSubscribers_Level_2emailAddress6emailAddress7

PartnerSubscribers_Level_2emailAddress8emailAddress9

PartnerSubscribers_Level_2emailAddress8emailAddress9

Labeled Email Lists A little more complex, but also more responsive, easier to

maintain, but we still can do better

Agencyid, name, rolerole priority- primary- secondary


Message 1: Even Better Policy List Dynamic Classification of Notification Receivers

Based on Agency, Job and/or Skills and Training More complex, but more flexible, smarter, less brittle, more

responsive to emergency changes

Sensor Alert PropertiesHazard Level- 1, 2, 3


Employeeid*NameAddressEmailPhoneCell


Subscriber PropertiesPreferred Notification Method - email, phone, text, cellType of Alerts


PartnerSubscribers_Level_2http://.../.../employee/Jack_Joneshttp://../.../employee/Mary_Jones


ResponderEM PropertiesAgency* - D, E, FJob* - X, Y, ZSkills* - A, B, CTraining Levels* - 1, 2, 3


Notify ResponseSubscribers via preferred methodAny person who subscribed fromlocal or remote with MOU in place


Main Notification- “PrimaryResponse” Class - Any Responder with Agencyhaving primary role for thistype of incident- “SpecialResponse” Class - Any Employee on duty withSkills and Training to handle this level and type of alert


*= URL



Policy Statements: Subjects A policy can be flexibly created out of

subject/property/value statements, i.e. “triples” Here we've highlighted some Subjects













*= URL



Agencyid*, name, rolerole priority- primary- secondary


Policy Statements: Properties A policy can be flexibly created out of

subject/property/value statements, i.e. “triples” Here are highlighted Properties









ResponderEM PropertieshasAgency* - D, E, FhasJob* - X, Y, ZhasSkills* - A, B, CTraining Levels* - 1, 2, 3




*= URL





Policy Statements: Values A policy can be flexibly created out of

subject/property/value statements, i.e. “triples” And here are the highlighted Values













*= URL



Additional Benefits of defining Policies with “triples” in OWL

One term can be defined to be equivalent to another

e.g. a Job called “X” in jurisdiction A may be called “Y” in jurisdiction B

Impact: if we search for responders with Job X, we can find both A and B

One term can be defined as a type of another (i.e. a subclass)

e.g. X is a ChemicalSensor which is a type of Sensor

Impact: if we check the status of “sensors” in region 2, our query will find X

One term can be defined to imply other terms

e.g. a Responder with Job X can be assumed to have skills A and B, as well as training Level 2, since those are defined requirements for that job

Impact: if we search for responders with skills A and B, we will find this responder even if the database knows nothing more than that the responder has Job X

A term can be defined to imply the reverse (i.e. be symmetric)

e.g. if Responder A “hasPartner” B, then the reverse is also true, namely Responder B “hasPartner” A

Impact: If we're trying to find the partner of B, we'll find A, even if all the database says is that the opposite, that A “hasPartner” B

Additional Benefits of defining Policies with “triples” in OWL

A term can be defined to imply a chain relationship (i.e. be transitive)

e.g. if Chemical A “causes” watery eyes and blurred vision, and if watery eyes and blurred vision “causes” evacuation to be difficult, then we can infer that Chemical A “causes” evacuation to be difficult

Impact: When we are reviewing our evacuation plan, our system can suggest that evacuation will be difficult from location 7 if Chemical A has been spilled there

A term may be a property with a defined domain of subjects and range of values

e.g. a property “rawHazardLevel” may be defined as only a property of sensors and may have only values of 1, 2, 3 or 4

Impact: if X has a “rawHazardLevel”, then we know X is a sensor

What's the point?

These may seem like simple relationships, but when our systems can put many of these together they can make important and surprisingly successful connections. The Web Ontology Language (OWL) is based on a form of logic which allows us to define these relationships so that our computer systems can make mathematically sound inferences.

In short, we can save lives by having smarter, more flexible systems to help us find the informationwe need, because we won't have time in an emergency to make all these connections ourselves.

What's the point?

These may seem like simple relationships, but when our systems can put many of these together they can make important and surprisingly successful connections. The Web Ontology Language (OWL) is based on a form of logic which allows us to define these relationships so that our computer systems can make mathematically sound inferences.

In short, we can save lives by having smarter, more flexible systems to help us find the informationwe need, because we won't have time in an emergency to make all these connections ourselves.

Sample Statements (“triples”):(Subject - Property - Value)

Employee isA Class ; Responder isASubClassOf Employee

Responder isAffiliatedWithAn Agency

Agency hasAProperty Role ;

Role hasValue PrimaryResponse

PrimaryResponse isASubClassOf “The class of responders that have agencies with Role equalTo PrimaryResponse”

etc.

What's this look like in OWL format?

(...fill in example OWL statements here....)


(...fill in example OWL statements here....)

Objects = BOLDProperty = ItalicizedValue = underlined

Objects = BOLDProperty = ItalicizedValue = underlined

Protege 4.0 Free tool to help build your policy statements

Outputs in OWL format

Easy to Use with Some Training


(.... more sample OWL statements ...)

?What's this look like in OWL format

(... more sample OWL statements ....)

Protege 4.0

Tutorial: See http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/resources/ProtegeOWLTutorialP4_v1_2.pdfTo download: See http://protege.stanford.edu/download/protege/4.0/installanywhere/

Accessing Policies via a SPARQL Endpoint A SPARQL endpoint is a web front-end to your “triples” store, see for example

Joseki and JENA, an open-source framework for programming with OWL, See http://www.joseki.org/ and a JENA tutorial is here: http://jena.sourceforge.net/tutorial/RDF_API/index.html

For example, http://dbpedia.org/sparql is a live sparql endpoint serving as a front-end to dbpedia. To try it, paste into the “Query Text” box the SPARQL query

SELECT ?Newspaper ?Stance WHERE { ?Newspaper rdf:type dbpedia-owl:Newspaper; <http://dbpedia.org/property/political> ?Stance}

and click “Run Query” and you'll see a list of newspapers from wikipedia and the political stance of each

Imagine a query which could return the contact info for each responder to whom a message should be routed based on a policy term (e.g. “primaryResponse”) specified in the ValueListURN query utilizing a sophisticated set of policy rules enabling inferencing. The query might be as simple as:

SELECT ?Id ?Name ?Email ?Phone WHERE { ?Id rdf:type Responder; <http://myorg/emergency/property/role> <http://myorg/emergency/role/primaryResponse>; <http://myorg/emergency/property/name> ?Name; <http://myorg/emergency/property/email> ?Email; <http://myorg/emergency/property/phone> ?Phone}

In this query, “Id” is the responder and the rest of the lines are properties and values of that responder . The query says “Fill in and return the variables “Id”, “Name”, “Email” and “Phone” for every id which is a type of “Responder” and whose “role” is “primaryResponse”.

http://www.joseki.org/

http://jena.sourceforge.net/tutorial/RDF_API/index.html

http://dbpedia.org/sparql

http://myorg/emergency/property/role

http://myorg/emergency/property/email

http://myorg/emergency/property/phone

Conclusion:Steps to Build, Access, and Utilize

Your Own Policy On paper, brainstorm key subjects, properties and values for your organization

and mission

You can also extract some of this from user documentation

Do rough relationships (class/subclass, symmetric, transitive, ...)

Fire up Protege and start constructing your ontology version 1

Expose your ontology via a web SPARQL interface

Reference your terms as needed in the DE header

Tailor your system to use the policies

When a DE comes in, do the following:

Grab the list name and terms from the header

Access the lists to get name and primary notification method and value via SPARQL query

Perform the notification

Understanding Emergency Routing Policies with EDXL Using the Distribution Element and the ValueListURN Tutorial Example Policy Implementation: Sensors.

Documents

different routing policies

alertvaluelisturn example

alertvaluelisturl example

example checkpoint scenario

emergency routing policies

list urn

routing policiesexample

local response message