1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. ValueListURN Specifies a list of terms by a unique name  e.g. urn: : :  Values can then be used from that list urn:myagency:gov:sensors:recipientRole VettingAuthority PrimaryResponse urn:myagency:gov:sensors:recipientRole VettingAuthority PrimaryResponse ValueListURN Example: Recipient Role urn:myagency:gov:sensors:keywords Checkpoint_3 Raw_Sensor_Alert urn:myagency:gov:sensors:keywords Checkpoint_3 Raw_Sensor_Alert ValueListURN Example: Keywords

9. ValueListURL? Proposed change for DE  e.g. http:// / /  Values can then be used from that list without need for registry lookup http://myagency/gov/sensors/recipientRole VettingAuthority PrimaryResponse http://myagency/gov/sensors/recipientRole VettingAuthority PrimaryResponse ValueListURL Example: Recipient Role http://myagency/gov/sensors/keywords CheckPoint_3 Raw_Sensor_Alert http://myagency/gov/sensors/keywords CheckPoint_3 Raw_Sensor_Alert ValueListURL Example: Keywords

10. Sample DE Header for Message 1 http://myhost.com/packages/17 mary.thompson@myagency.gov 2009-11-15T16:53:00-05:00 Exercise Report unclassified EN urn:myagency:gov:sensors:recipientRole Repository VettingAuthority PrimaryResponse ResponseSubscribers PartnerSubscribers urn:myagency:gov:sensors:keywords Checkpoint_3 Raw_Sensor_Alert Sensor_Hazard_Level_2 33.4745,-112.1174 33.4745,-112.0238 33.4238,-112.0238 33.4238,-112.1174 33.4745,-112.1174 [... INSERT YOUR XML PAYLOAD HERE, e.g. Common Alert Protocol (CAP) message...] http://myhost.com/packages/17 mary.thompson@myagency.gov 2009-11-15T16:53:00-05:00 Exercise Report unclassified EN urn:myagency:gov:sensors:recipientRole Repository VettingAuthority PrimaryResponse ResponseSubscribers PartnerSubscribers urn:myagency:gov:sensors:keywords Checkpoint_3 Raw_Sensor_Alert Sensor_Hazard_Level_2 33.4745,-112.1174 33.4745,-112.0238 33.4238,-112.0238 33.4238,-112.1174 33.4745,-112.1174 [... INSERT YOUR XML PAYLOAD HERE, e.g. Common Alert Protocol (CAP) message...]

11. The DE Header uses the ValueListURN to reference policy lists....What do these policy lists look like?

12. Message 1: Policy List Simple List of Email Addresses  Simple, but brittle, difficult to maintain, no flexibility Sensor_Hazard_Level_2 emailAddress1 emailAddress2 emailAddress3 emailAddress4 emailAddress5 Sensor_Hazard_Level_2 emailAddress1 emailAddress2 emailAddress3 emailAddress4 emailAddress5

13. Message 1: Better Policy List Sensor_Hazard_Level_2 emailAddress3 emailAddress4 emailAddress5 Sensor_Hazard_Level_2 emailAddress3 emailAddress4 emailAddress5 Sensor_Hazard_Level_1 emailAddress1 emailAddress2 Sensor_Hazard_Level_1 emailAddress1 emailAddress2 ResponseSubscribers_Level_2 emailAddress6 emailAddress7 ResponseSubscribers_Level_2 emailAddress6 emailAddress7 PartnerSubscribers_Level_2 emailAddress8 emailAddress9 PartnerSubscribers_Level_2 emailAddress8 emailAddress9 Labeled Email Lists  A little more complex, but also more responsive, easier to maintain, but we still can do better

14. Agency id, name, role role priority - primary - secondary Agency id, name, role role 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 Properties Hazard Level - 1, 2, 3 Sensor Alert Properties Hazard Level - 1, 2, 3 Employee id* Name Address Email Phone Cell Employee id* Name Address Email Phone Cell Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones Responder EM Properties Agency* - D, E, F Job* - X, Y, Z Skills* - A, B, C Training Levels* - 1, 2, 3 Responder EM Properties Agency* - D, E, F Job* - X, Y, Z Skills* - A, B, C Training Levels* - 1, 2, 3 Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert *= URL

15. Agency id, name, role role priority - primary - secondary Agency id, name, role role priority - primary - secondary Policy Statements: Subjects A policy can be flexibly created out of subject/property/value statements, i.e. “triples”  Here we've highlighted some Subjects Sensor Alert Properties Hazard Level - 1, 2, 3 Sensor Alert Properties Hazard Level - 1, 2, 3 Employee id* Name Address Email Phone Cell Employee id* Name Address Email Phone Cell Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones Responder EM Properties Agency* - D, E, F Job* - X, Y, Z Skills* - A, B, C Training Levels* - 1, 2, 3 Responder EM Properties Agency* - D, E, F Job* - X, Y, Z Skills* - A, B, C Training Levels* - 1, 2, 3 Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place *= URL Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert

16. Agency id*, name, role role priority - primary - secondary Agency id*, name, role role 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 Sensor Alert Properties Hazard Level - 1, 2, 3 Sensor Alert Properties Hazard Level - 1, 2, 3 Employee id* Name Address Email Phone Cell Employee id* Name Address Email Phone Cell Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones Responder EM Properties hasAgency* - D, E, F hasJob* - X, Y, Z hasSkills* - A, B, C Training Levels* - 1, 2, 3 Responder EM Properties hasAgency* - D, E, F hasJob* - X, Y, Z hasSkills* - A, B, C Training Levels* - 1, 2, 3 Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place *= URL Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert

17. Agency id*, name, role role priority - primary - secondary Agency id*, name, role role priority - primary - secondary Policy Statements: Values A policy can be flexibly created out of subject/property/value statements, i.e. “triples”  And here are the highlighted Values Sensor Alert Properties Hazard Level - 1, 2, 3 Sensor Alert Properties Hazard Level - 1, 2, 3 Employee id* Name Address Email Phone Cell Employee id* Name Address Email Phone Cell Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts Subscriber Properties Preferred Notification Method - email, phone, text, cell Type of Alerts PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones PartnerSubscribers_Level_2 http://.../.../employee/Jack_Jones http://../.../employee/Mary_Jones Responder EM Properties hasAgency* - D, E, F hasJob* - X, Y, Z hasSkills* - A, B, C Training Levels* - 1, 2, 3 Responder EM Properties hasAgency* - D, E, F hasJob* - X, Y, Z hasSkills* - A, B, C Training Levels* - 1, 2, 3 Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place Notify ResponseSubscribers via preferred method Any person who subscribed from local or remote with MOU in place *= URL Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert Main Notification - “PrimaryResponse” Class - Any Responder with Agency having primary role for this type of incident - “SpecialResponse” Class - Any Employee on duty with Skills and Training to handle this level and type of alert

18. 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

19. 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 ther e 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 information we 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 information we need, because we won't have time in an emergency to make all these connections ourselves.

20. 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....) What's this look like in OWL format? (...fill in example OWL statements here....) Objects = BOLD Property = Italicized Value = underlined Objects = BOLD Property = Italicized Value = underlined

21. Protege 4.0 Free tool to help build your policy statements Outputs in OWL format Easy to Use with Some Training What's this look like in OWL format? (.... 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.pdf To download: See http://protege.stanford.edu/download/protege/4.0/installanywhere/

22. 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 http://www.joseki.org/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; ?Stance} and click “Run Query” and you'll see a list of newspapers from wikipedia and the political stance of each http://dbpedia.org/sparql 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; ; ?Name; ?Email; ?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://myorg/emergency/property/rolehttp://myorg/emergency/property/emailhttp://myorg/emergency/property/phone

23. 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