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: Re: [emergency] Proposal for Presentation atOASIS Symposium 2007


Ron,

Thanks for responding.

I know that GML structured data may be used within appropriate
elements, such as location, in the EDXL-RM draft.  I also know that
the CIQ specs also tie-in with GML.

Are you suggesting this as an example of use of already supported
specs? best-practices? ...

I'm confused by what the first word, 'This,' is referencing in your
paragraph and, thus how to utilize the information in the paper or to
fix an error in the paper.

Best regards,

Michelle

On 12/15/06, Ron Lake <rlake@galdosinc.com> wrote:
> This was of course a key use case in the development of GML - since a
> good deal of the information involved is geospatial.  Further GML was
> intended not just as an exchange mechanism but as a transactional
> synchronization mechanism for spatial databases.
>
> Ron
>
> -----Original Message-----
> From: Michelle Raymond [mailto:michellearaymond@gmail.com]
> Sent: December 15, 2006 6:24 PM
> To: emergency@lists.oasis-open.org
> Subject: Re: [emergency] Proposal for Presentation atOASIS Symposium
> 2007
>
> Here is the paper thus far with much use of existing material in the TC.
>
> Is there anyone else out there on a fine Friday night?
>
> The text below is formatted in the Word file attached.
>
> - Michelle
>
>
> Continuing through Emergency: eBiz/eGov Continuity and Contingency
> functioning throughout emergency incidents
>
> Brief Description
>
>
> Emergency Incidents of any size or source have the capacity to disrupt
> business, government and 'life' as usual.
>
> Increasing reliance on electronic information exchange may impact the
> level of disruption. However, well managed information exchange during
> an incident may also provide business, government and other
> organizational structures means for direct involvement in mitigation
> of the incident and its aftershock. In some cases it may even enable
> specialized operational functions that can bring continued
> productivity, alternate revenue and positive publicity for the
> participating entities.
>
> Keys to success include:
>  - data access during an incident,
>  - information sharing expedited by data format and vocabulary
> standards within   organizational silos,
>  - resource registries,
>  - common model and protocol structure for information exchange and
> integration into incident response systems,
>  - and other applicable Service Oriented Architecture (SOA) practices.
>
>
>
>
>
> Position Paper
>
>
>
> Problem Statement
>
>
>
> [Around the world], government agencies, non-governmental
> organizations and private sector emergency management offices use a
> wide array of software platforms for managing data about emergency
> conditions, resources and response activities. Most of these are
> stand-alone systems with limited capability for data sharing with
> other agencies or other levels of government.[1]
>
>
>
> During an emergency it is generally believed that it is desirable to
> keep 'business-as-usual', particularly in regions and
> business/government sectors not directly impacted by the emergency.  A
> lot of the recent and emerging information technologies aid in keeping
> things running.
>
>
>
> We suggest that these information technologies can also play a role in
> emergency incident mitigation by opening up more information to the
> emergency responders from nontraditional sources, make emergency
> alerting available to organizations beyond emergency responders and to
> aid businesses and organizations in the management of just-in-time
> resource provisioning.
>
>
>
> 1. Emergency Management interoperability leveraging and support
>
> of eBiz/eGov practices
>
>
>
> Advances in information technology have paralleled the movement toward
> more integrated approaches to emergency management. In particular, the
> emergence of service-oriented architectures has created new
> opportunities for interoperability among diverse emergency information
> systems utilizing existing industry-standard technologies. At the same
> time, other data communication facilities, such as digital television
> and radio broadcasting, are being brought to bear on the challenges of
> emergency information exchange.1
>
> Application of these technologies to the emergency management domain
> requires the design and refinement of new standards for data
> structures and message-exchange processes. [The Emergency Management]
> Technical Committee [continues to] design, develop, and release
> XML-based standards that provide a framework for interoperability
> among diverse emergency information systems.1
>
>
>
> The standard information format and exchange policies are aligned with
> the information needs for enabling quick, effective emergency
> mitigation. These requirements were expressed by emergency management
> and response professionals and regulatory agencies.  The standards are
> designed to meet the emergency responders' need for interoperability
> and policy enablement.  The results of the standards may be even more
> far reaching, facilitating quick interconnection with non-emergency
> communities both for alerting and for the providing of services and
> resources when the incident suggests the need.
>
>
>
> The standards developers have chosen to follow the best-practices of
> information exchange learned from eBiz/eGov and SOA practices and to
> recommend adoption of external standards within the emergency
> standards for information loads that already have a solid standard.
> One example is the use of portions of the OASIS CIQ (Customer
> Information and Quality) Standard for how to represent people or
> parties location in a non United States restricted representation.
>
>
>
>
> 2. Using Emergency Data Exchange Lanaguage - Distribution Element
> (EDXL-DE) as a common framework for information sharing
>
>
>
> [The] Distribution Element specification describes a standard message
> distribution framework for data sharing among emergency information
> systems using the XML-based Emergency Data Exchange Language (EDXL).
> This format may be used over any data transmission system, including
> but not limited to the SOAP HTTP binding.[2]
>
>
>
> The primary purpose of the Emergency Data Exchange Language and its
> supporting standards is, and should continue to be, structured
> information management for emergency response.  However, this does not
> preclude the use of this structured approach to add value to the
> emergency response system by supplying additional pertinent
> information and services.
>
>
>
> The Distribution Element (DE) may be thought of as a "container". It
> provides the information to route "payload [content]" message sets
> (such as Alerts or Resource Messages), by including key routing
> information such as distribution type, geography, incident, and
> sender/recipient IDs.[3]
>
>
>
> For example, previous to the DE specification, during Hurricane Andrew
> a notification went out over a specialized shared information space
> for emergency response that additional routers were needed for
> computer connectivity at some of the emergency shelters. Management
> from a large, multi-site store was monitoring the notifications. The
> business delivered routers directly to the sites that needed them from
> nearby stores. In this case it was quick thinking on the part of the
> business management that got the shelters the needed equipment.  Due
> to the information system's configuration, no electronic response to
> the notification could be made. As a result, four separate stores
> delivered the requested routers to one shelter. With the upcoming
> Emergency Data Exchange Language - Resource Messaging (EDXL-RM)
> Specification, this resource request / response scenario could play
> out with all involved parties aware of the process as it unfolds.
>
>
>
>
> 3. Using Emergency Data Exchange Lanaguage - Resource Messaging
> (EDXL-RM) as a common format to communicate about resources needed and
> available during an incident
>
>
>
> The primary purpose of the Resource Messaging Specification is to
> provide a set of standard formats for properly formatted XML emergency
> messages that are specifically designed for information payloads
> related to Resources required for all activities associated with
> emergency incidents.
>
>
>
>
> 4. Common data format and vocabulary for sectors
>
>
>
> 4a. Information specifically integrated into Data Exchange Language
>        (example: EDXL-HAVE (Hospital AVailability Exchange)
>
>
>
> 4b. Sector standards specific information exchange via distribution
> wrappers
>        (example: oBIX (Open Business Information eXchange))
>
>
>
>
> 5. The fit of Service Oriented Architecture (SOA) aspect of eBIZ/eGov
> into emergency response
>
> - Show quoted text -
>
>
>
>
> ------------------------------------------------------------------------
> ----------------------------
>
>
>
> Fodder
>
>
>
> 1. EMTC Charter
> Across the nation, government agencies, non-governmental organizations
> and private sector emergency management offices use a wide array of
> software platforms for managing data about emergency conditions,
> resources and response activities. Most of these are stand-alone
> systems with limited capability for data sharing with other agencies
> or other levels of government.
>
> Advances in information technology have paralleled the movement toward
> more integrated approaches to emergency management. In particular, the
> emergence of service-oriented architectures has created new
> opportunities for interoperability among diverse emergency information
> systems utilizing existing industry-standard technologies. At the same
> time, other data communication facilities, such as digital television
> and radio broadcasting, are being brought to bear on the challenges of
> emergency information exchange.
>
> Application of these technologies to the emergency management domain
> requires the design and refinement of new standards for data
> structures and message-exchange processes. The purpose of this
> Technical Committee is to design, develop, and release XML-based
> standards that provide a framework for interoperability among diverse
> emergency information systems.
>
> 2. EDXL-DE spec
> This Distribution Element specification describes a standard message
> distribution framework for data sharing among emergency information
> systems using the XML-based Emergency Data Exchange Language (EDXL).
> This format may be used over any data transmission system, including
> but not limited to the SOAP HTTP binding.
>
> 3. EDXL-RM draft
> The primary purpose of the Resource Messaging Specification is to
> provide a set of standard formats for  properly formatted XML
> emergency messages that are specifically designed for information
> payloads related to Resources required for all activities associated
> with emergency incidents. The Distribution Element may be thought of
> as a "container". It provides the information to route "payload"
> message sets (such as Alerts or Resource Messages), by including key
> routing information such as distribution type, geography, incident,
> and sender/recipient IDs
>
> 4a. EDXL-HAVE draft
> HAVE is a draft XML specification that allows the communication of the
> status of a hospital, its services, and its resources. These include
> bed capacity and availability, emergency department status, available
> service coverage, and the status of a hospital's facility and
> operations.
>
> 4b. oBIX draft
> oBIX is designed to provide access to the embedded software systems
> which sense and control the world around us.  Historically integrating
> to these systems required custom low level protocols, often custom
> physical network interfaces.  But now the rapid increase in ubiquitous
> networking and the availability of powerful microprocessors for low
> cost embedded devices is weaving these systems into the very fabric of
> the Internet.  Generically the term M2M for Machine-to-Machine
> describes the transformation occurring in this space because it opens
> a new chapter in the development of the Web - machines autonomously
> communicating with each other.  The oBIX specification lays the
> groundwork building this M2M Web using standard, enterprise friendly
> technologies like XML, HTTP, and URIs.
>
> The requirements and vertical problem domains for M2M systems are
> immensely broad - too broad to cover in one single specification.
> oBIX is deliberately designed as a fairly low level specification, but
> with a powerful extension mechanism based on contracts.  The goal of
> oBIX is to lay the groundwork for a common object model and XML syntax
> which serves as the foundation for new specifications.  It is hoped
> that a stack of specifications for vertical domains can be built upon
> oBIX as a common foundation.
>
> The following design points illustrate the problem space oBIX attempts
> to solve:
>  * XML: representing M2M information in a standard XML syntax;
>             The principle requirement of oBIX is to develop a common
> XML syntax for representing information from diverse M2M systems.  The
> design philosophy of oBIX is based on a small, but extensible data
> model which maps to a simple fixed XML syntax.  This core object model
> and it's XML syntax is simple enough to capture in it's entirety in
> one illustration provided in Chapter 4.  The object model's
> extensibility allows for the definition of new abstractions through a
> concept called contracts.  The majority of the oBIX specification is
> actually defined in oBIX itself through contracts.
>  * Networking: transferring M2M information in XML over the network;
>             Once we have a way to represent M2M information in XML,
> the next step is to provide standard mechanisms to transfer it over
> networks for publication and consumption.  oBIX breaks networking into
> two pieces: an abstract request/response model and a series of
> protocol bindings which implement that model.  Version 1.0 of oBIX
> defines two protocol bindings designed to leverage existing web
> service infrastructure: a HTTP REST binding and a SOAP binding.
>  * Normalization: standard representations for common M2M features:
> points, histories, and alarms;
>             There are a few concepts which have broad applicability
> in systems which sense and control the physical world.  Version 1.0 of
> oBIX provides a normalized representation for three of these:
>                      * Alarming: modeling, routing, and
> acknowledgment of alarms.  Alarms indicate a condition which requires
> notification of either a user or another application.
>                      * Histories: modeling and querying of time
> sampled point data.  Typically edge devices collect a time stamped
> history of point values which can be feed into higher level
> applications for analysis;
>                     * Points: representing a single scalar value and
> it's status - typically these map to sensors, actuators, or
> configuration variables like a setpoint;
>   * Foundation: providing a common kernel for new standards;
>             The requirements and vertical problem domains for M2M
> systems are immensely broad - too broad to cover in one single
> specification.  oBIX is deliberately designed as a fairly low level
> specification, but with a powerful extension mechanism based on
> contracts.  The goal of oBIX is to lay the groundwork for a common
> object model and XML syntax which serves as the foundation for new
> specifications.  It is hoped that a stack of specifications for
> vertical domains can be built upon oBIX as a common foundation.
>
> 5. OASIS website
> Service Oriented Architecture (SOA) represents a collection of best
> practices principles and patterns related to service-aware,
> enterprise-level, distributed computing. SOA standardization efforts
> at OASIS focus on workflows, translation coordination, orchestration,
> collaboration, loose coupling, business process modeling, and other
> concepts that support agile computing.
>
> - Show quoted text -
>
>
> ------------------------------------------------------------------------
> --------
>
> [1] OASIS EMTC Charter, 2005.
>
> [2] EDXL-DE Specification
>
> [3] EDXL-RM Draft Specification
>


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