This slide jgives you the name of this open source SourceForge Project and the URL for the project. The project name begins with the word integrated because the Emergency Data Exchange Language Resource Message is integrated with the EDXL Distribution Element. In fact, the user or developer is directed to the EDXL-DE page after login to reinforce the notion that the DE is used to construct the header information for every RM message payload. The idea of integration is built into the EDXL Family of specifications that is now comprised of the DE, RM and HAVE, the Hospital Availablity Exchange.
This slide presents the goals for developing the open source project as an aid to developers and as a means to promote the adoption of the specification. These goals guide development toward a program of regular, measured and scored exercises that support Continuous Improvement within the Emergency Response Framework. This sample implementation provides developers a basis for building atop a structure that already implements all of the required elements of both EDXL-DE and EDXL-RM with most of the optional elements as well. That structure is supplied with a working MySQL Database managed by a plain Java application that maintains the Java Persistence Unit for the database, comprising a fairly typical 3-tier architecture. In addition, the Geospatial Info Page is left empty to enforce the requirement of teaming with a third party, hopefully map-based geospatial location specifier application similar to what you will see shortly.. This reinforces the strategy of integrating services in a way that makes the 3-tier architecture compatible with both SOAP-based and RESTful Web Services in a Service Oriented Architecture. Lastly, the intention is to encourage developers to build a more user-friendly, and, hopefully, map and icon-base graphical interface over the sample implmentation so that EOC users are not required to spend time keyboarding during emergency incidents.
This presentation wraps up our set with a review of current standards work in the Emergency Management Community and in the domains related to the National Response Framework
This slide is a quick reference for the Acronyms we'll be mentioning.
The title of this slide was chosen to remind us all that there is a specific role that emerging standards play in the whole Emergency Response Management Community. That role is to stimulate and provide important tools for improvement. As noted, Emerging means Becoming Manifest or Becoming Known. The word Emerging itself often sounds somewhat challenging in the sense of creating a need for sudden change. Often, it is the perception of suddenness rather than the need for change that causes undue concern. As we’ll show momentarily, the process involved in the kind of change we represent is anything but sudden. In fact, we’ve been criticized for being slower than desired by many in the recent past. However, we’re pleased to say that after a lot of work, OASIS will be conducting a final Approval Ballot for both EDXL-HAVE and EDXL-RM during the second half of this month, October 2008. Considering that these specifications were first submitted to the OASIS Emergency Management Technical Committee in August of 2005, there should be little concern that we rushed this work through our processes. So as we develop Standards, Emerging should be not thought Disruptive, but Well-Timed with sufficient advance notice for the vendors who implement these Standards and the Agencies who ultimately use these Standards to prepare for using them
This slide illustrates the processes our OASIS EM TC standards go through using the example of EDXL-RM. While this experience is not completely representative of the field, and we have learned important lessons in the course of the timelines shown here, and we think this is fairly typical. The timeline for the Subject Matter Experts Group is only 5 months for the development of the candidate specification that was initially handed off to the EM TC. This timeline does not reflect the time spent gathering input and writing the first version of the specification. Likewise, the timeline for the EM TC’s work does not reflect the time spent by both groups translating the candidate specification into a formal Requirements Document from which the EM TC’s work began. However, given those caveats, these timelines are still fairly typical, since these group processes almost always encounter interruptions of one sort or another. So we can safely say that if the industry and government agencies monitor these processes, Emerging Standards need not be Disruptive, but Well Timed, and gives vendors who engage the Standards Process a distinct advantage.
As this slide notes, there are other considerations which need to be included in this kind of work. Using other standards is very helpful for increasing the overall level of interoperability of standards and the applications which adhere to them. In this case we used the Customer Information Quality (CIQ) specifications, even though they have not yet been advanced for an OASIS-wide Approval Vote. It is also important to note that the uptake of specfications and standards are mutually reinforcing practices which we would like to encourage as much as we can. This particular set of individual, organizational and legal specifications is very important for eliminating any possible confusion over the identities and provenance of authority for jurisdictions in a given emergency incident. In the case of EDXL-RM which deals with resource logistics, this is also important for establishing accountability and providing an audit trail for equipment, supplies and staff, and also for documenting the communications about this information.
This slide states in explicit terms how EDXL-RM and EDXL-HAVE provide support for the National Response Framework. These specifications support both Web 2.0 and Semantic Web requirements as noted. We think this is particularly important as the time nears for the transition to the next federal executive administration. It has taken the combined, accumulated effort of many individuals over more than five years to reach the point we find ourselves at today The adoption of standards like EDXL-RM and EDXL-HAVE are extremely important for improving National Preparedness. In addition, the work ahead on the Reference Information Model for the EDXL family, promises to seriously reduce the time needed to build new specifications or future versions of existing specifications.
This slide outlines a set of next steps in the arena of standards for the Emergency Response Management domain. We should emphasize that these steps are mostly what we have on our plate now or may have soon. This does not attempt to address what else might be advisable, helpful or desirable.
After a user logs in, the application opens to the EDXL-DE page. From here the user can either navigate to any other page of the application or choose to begin working on a new EDXL-RM Message. The EDXL-RM application opens onto the EDXL-DE page because every RM message, including messages that the user creates from scratch that are not one of the 16 pre-defined message types, need to be wrapped in the EDXL-Distribution Element for routing. Please notice that the larger, top row of tabs navigate to the major information category pages. EDXL-RM naturally falls into this sort of structure because all messages contain elements from these major categories: Contact Information, Resource Information, Response Information, Schedule Information and Geospatial Information. This page also shows the dropdown list of those 16 pre-defined messages. A user can fill in the information or select it from dropdown lists as the developer chooses. If the form is filled and a pre-defined message is selected, the user navigates to that message type page when the submit button is clicked..
This page is intended to show the depth of the individual message pages. It is fairly self-explanatory, and shows the basis for the decision to develop a sample implementation that can lead to a largely or totally graphical interface that takes the need for users to work with such details out of the user’s experience entirely, but retains it for audit trail purposes and for management review. Because any message may refer to multiple resources and each resource can have multiple schedule types associated with it, the decision was made to include three resources with three schedule types each to hit the best guess of what will constitute a happy medium. Buttons to add more resources and schedule types are provided. However, that does make each message rather long, and this decision is also intended to stimulate developers to build interfaces to graphical tools which will automatically fill out the information contained in these forms, which can then be maintained without cluttering the user’s interface.
This slide shows a typical major information category page, Contact information ,which is included in every message type and which contains a table from which individual records can be selected from the common datebase that serves the application. These records will populate the form below for editing, or a new record can be created in these information category pages and automatically inserted into the corresponding database table. In addition the lower row of smaller tabs direct the user to a similar page which only allows the user to select records from the database which are then entered into the form of the message being constructed. Once a message type is selected, or a whole message is selected from the View Resource Messages page or the EDXL-RM Resource Messages Page, work continues on that message until it is saved, cancelled or saved and sent.
The slide gives you a taste of the database this application uses. It contains 70 tables at present. When passed through one of the automated database generators, using the XML Schema for the specification, more than 120 tables were created, and the decision was taken to manually configure the database to cut down on redundancy. This database was designed using the knowledge I had from having co-chaired the subcommittee which was responsible for the specification and from having to track all comments and resolutions and to edit the final product. One motivation for creating an open source sample implementation was to take the kind of intimate knowledge I had from working on the specification and apply it to this task.
Open Source EDXL-Resource Management Project in Context
Integrated Open Source Application of the Emergency Data Exchange Language Resource Messaging 1.0 Specification (IOSA-EDXL-RM) http://sourceforge.net/projects/iosa-edxl-rm / Presented by Rex Brooks
Open Source EDXL-RM Goals <ul><li>Sample Implementation Aimed at Developers for Adaptation to Customized Installations </li></ul><ul><li>Provide all Required and Most Optional Elements </li></ul><ul><li>Provide Minimum Database with Companion DB Management Application </li></ul><ul><li>Provide Basis for Jurisdictions to Understand Basic EDXL Concepts of Distribution Element (EDXL-DE) with Content Payloads such as EDXL-RM and EDXL-HAVE </li></ul><ul><li>Provide Basis for Combining Geospatial Applications with EDXL-RM </li></ul><ul><li>Provide Basis for Developing Graphical Interface that doesn’t Require Operators to Spend Time Keyboarding Inputs During Exercises and Actual Incidents </li></ul>
The Role of Emerging Open Standards in the National Response Framework:
Standards Acronym List <ul><li>OASIS: Organization for the Advancement of Structured Information Standards </li></ul><ul><ul><li>CAP: Common Alerting Protocol </li></ul></ul><ul><ul><li>EDXL-DE: Emergency Data Exchange Language Distribution Element </li></ul></ul><ul><ul><li>EDXL-RM: Emergency Data Exchange Language Resource Messaging </li></ul></ul><ul><ul><li>EDXL-HAVE: Emergency Data Exchange Language Hospital Availability Exchange </li></ul></ul><ul><ul><li>SOA-RM: Reference Model for Service Oriented Architecture </li></ul></ul><ul><ul><li>SOA-RA: Reference Architecture nfor Service Oriented Architecture </li></ul></ul><ul><ul><li>ebXML Registry-Repository: Electronic Business using eXtensible Markup Language </li></ul></ul><ul><ul><li>CIQ: Customer Information Quality </li></ul></ul><ul><ul><li>oBIX: Open Building Information Xchange </li></ul></ul><ul><li>Open Geospatial Consortium </li></ul><ul><ul><li>GML: Geography Markup Language </li></ul></ul><ul><ul><li>‘ geo-oasis’: Profile of GML for use with OASIS Specifications </li></ul></ul><ul><ul><li>SensorML: Sensor Markup Language </li></ul></ul><ul><ul><li>CityGML: City Geography Markup Language </li></ul></ul><ul><li>Web 3D Consortium </li></ul><ul><ul><li>X3D: ISO standard XML-based file format for representing 3D computer graphics </li></ul></ul><ul><ul><li>GeoX3D: GeoPositionInterpolator Node of X3D </li></ul></ul><ul><li>Miscellaneous </li></ul><ul><ul><li>BIM: Building Information Modeling </li></ul></ul><ul><ul><li>NBIMS: National Building Information Modeling Standard </li></ul></ul>
What are Emerging Standards? <ul><li>‘ Emerging’ Means ‘Becoming Manifest’ or ‘Becoming Known’ Sounds ‘Sudden’ </li></ul><ul><li>OASIS Conducts Approval Ballot October 16-31, 2008 for EDXL-RM 1.0 and EDXL-HAVE 1.0 </li></ul><ul><li>First Submissions to OASIS Emergency Mangement Technical Committee (OASIS EM TC) in August, 2005 </li></ul><ul><li>‘ Emerging’ Not Necessarily ‘Disruptive,’ can be ‘Well-Timed’ When Business & Public Prepared for ‘Emerging’ Technology </li></ul>
Standards From Outside Emergency Management TC Also Required <ul><li>OASIS Customer Information Quality (CIQ) Specifications Used in EDXL-RM & EDXL-HAVE </li></ul><ul><ul><li>Name (extensible Name Language - xNL), </li></ul></ul><ul><ul><li>Address (extensible Address Language - xAL), </li></ul></ul><ul><ul><li>Name and Address (extensible Name and Address Language - xNAL) & </li></ul></ul><ul><ul><li>Party (extensible Party Information Language - xPIL) </li></ul></ul>
Emergency Management Standards Support National Response Framework <ul><li>EDXL-RM & EDXL-HAVE Provide Measurable Resource Parameters for Readiness, Preparedness Web 2.0 Analytics </li></ul><ul><li>EDXL-Reference Information Model (EDXL-RIM) to Add Ontology of EDXL-Family for Semantic Web Support </li></ul><ul><li>EDXL-RIM to Provide ‘Blueprint’ Level of Abstraction, to Implement SOA Reference Architecture </li></ul><ul><ul><li>SOA Reference Architecture Subcommittee Working 1 st Public Review Issues Now </li></ul></ul><ul><li>EDXL-RIM Provides Explanation of EDXL Methods such as Keyword-Identified ‘ValueListURN-Value’ Pairs </li></ul><ul><ul><li>Aid for New Specifications and New Versions in EDXL-Family </li></ul></ul>
Next Steps in Standards <ul><li>OASIS EM TC: </li></ul><ul><ul><li>Profiles such as the Emergency Alert System (EAS)-CAP Profile Under Development </li></ul></ul><ul><ul><li>Extensions </li></ul></ul><ul><ul><li>EDXL-Situation Reporting in the Practitioner Steering Group Now </li></ul></ul><ul><ul><li>EDXL-Asset Tracking Under Consideration </li></ul></ul><ul><ul><li>Next Versions: CAP 1.2 or 2.0 (Undecided); EDXL-DE 2.0 </li></ul></ul><ul><li>Open Geospatial Consortium </li></ul><ul><ul><li>‘ Geo-OASIS’ Profile of GML for use with OASIS Standards </li></ul></ul>
Start Page of EDXL-RM Sample Implementation: EDXL-DE
EDXL-RM RequestInformation Message Page Messages May Contain Multiple Resource Units & Resource May Contain Multiple ScheduleTypes Sample Implementation: 3 Resource Units per Form 3 ScheduleTypes per Resource (Example Images Show only 2 Resources in Example Form Page)
EDXL-RM Contact Information Page Individual Records in Contact, Resource, Response, Schedule Info Categories can be Created, Edited and Deleted from Their Category Pages, (Contact Info Shown as Example.) Individual Records can be Selected through their respective Add-Info Page for including in the EDXL-RM Message that is Being Created