Rex,
The deadline for submission is today - tonight. I don't know how
lenient they are about late submissions. I'll send an update of my
work thus far in the next message.
Your ideas are right on track as a far as I am concerned and really
want that tie-in.
Maybe I could send in a placeholder submission and we could "resubmit"
by the end of the weekend.
- Michellle
On 12/15/06, Rex Brooks <> wrote:
> Hi Michelle,
>
> Sorry I couldn't get back to this earlier today,
> but I will definitely be able to compose some
> pointed discussions on the paper's potential. My
> primary object will be to connect these positions
> to the need for an Emergency Mgt AND Health
> Informatics Information Sharing and Analysis
> Center (an ISAC).
>
> If you can spare some time early Sunday morning,
> I will call you then, or you can attempt to get a
> conference call together. The kind of ISAC I am
> exploring would embody the SOA2eGov(& eBIZ)
> connection, having appropriate levels of
> accessibility (access control). The initiation of
> work toward a "Situational Awareness"
> specification, as well as or in addition to the
> "Cursor On Target" work currently being sounded
> out in various circles. Their are a lot of
> aspects to the discussion you have initiated
> below that fit into many areas of the work I, and
> the collaboratory we have built over the last
> year and half, have in progress.
>
> Cheers,
> Rex
>
> At 1:36 PM -0600 12/15/06, Michelle Raymond wrote:
> >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,
> ><> 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
> >>
> >>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.
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
>
