Re: [emergency] Proposal for Presentation atOASIS Symposium 2007

["Michelle Raymond" <michellearaymond@gmail.com>]

Below is fodder for a position paper (1000 - 2000 words.   If folks
feel I'm heading in a misguided direction, chime in.  Actually, chime
in anyway.  Any other perspectives would likely be a positive
influence and better direct the resulting paper and presentation.  The
paper must go in today.  Then we'll have some time to iron out the
presentation (if the paper is accepted.)

I've attached snippets from existing documents. Obviously, they don't
tell a cohesive story as is.  I'll begin working it together now.
Send comments via email and/or call my cell #: 612 703 9825.

Best Regards,

Michelle Raymond
--------------------------------------------------------------------------
Title

Existing through Emergency: Continuity and Contingency functioning
during 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 in 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 / Presentation Outline

1. Emergency Management viewed as eBIZ/eGov interoperability
leveraging and support
2.Common protocol for information exchange
3. Common format to communicate about resources needed / available
during an incident
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  the Service Oriented Architecture (SOA) aspect of eBIZ/eGov


Text grabbed from existing documents as a basis point

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.

On 14 Dec 2006 20:50:26 -0000, michellearaymond@gmail.com
<michellearaymond@gmail.com> wrote:
> A very quick discussion must ensue if we are to put in something jointly through the TC members.  The due date for submission is tomorrow.
>
> I shall be fleshing out the following and beginning to write a 1000 - 2000 brief on the subject matter.
>
> It seems ideal to draw from past and planned interop demos as well as our individual experiences and anticdotes regarding involvement of eBiz/eGov in incident response. Data would needed to be supplied quickly.
>
> Below is a first pass at an introductory statement, showing applicability of the presentation to the OASIS Symposium theme of eBiz/eGov.
>
> Best regards,
>
> Michelle Raymond
> michellearaymond@gmail.com
> cell: 612 703-9825
>
>
>
> 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 in 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.
>
>
>
>
>
>