MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] Illogical Structure?
On Jul 19, 2005, at 12:52 PM, Ellis, David wrote:
> It was my hope the sensor and systems charter subcommittee would
> look at the process and roles of converting raw data into
> actionable information and the required informational elements
> which must be exchanged to manage an incident response... Tom
> Merkle and I thought this was a natural progress of the
> infrastructure charter.
I hope neither you nor Tom are taking my comments personally. My
concern was sparked in no small part by looking at the difficulties
the infrastructure SC has faced since its inception... what, three
years ago?
It isn't that these aren't important questions... I'm just not sure
our TC has a broad enough membership to do these architectural tasks
justice. Where we've made headway in the past we've obtained our
initial marching orders, in the forms of requirements and even first-
draft implementations, from larger constituencies.
I'm not even sure it's prudent for our TC to try to set policy
directions. Our charter and expertise has to do with crafting
neutral implementations. If we start trying to do architecture I'm
afraid we might even impair our acceptability with folks who have
their own dogs in the hunt.
Just by way of illustration, I'm attaching two whitepapers by folks
doing innovative work in the "infrastructure" space. These aren't
sensor-oriented, but I suspect they have equivalents in that domain.
(Those who know me know this, but just for the record, my forwarding
these items in no way constitutes an endorsement on my part.)
- Art
Semandex_Content_Based_Routing_101.pdf
event_architectures.pdf
On Jul 19, 2005, at 12:52 PM, Ellis, David wrote:
> TC
>
> In the hardware definitions below Art used the term data in one
> form or another in every definition. As I have mentioned before
> incidents have a natural information flow and sensors (OGC
> definition, an entity capable of observing a phenomenon and
> returning an observed value. A sensor can be an instrument or a
> living organism (e.g. a person), but herein we concern ourselves
> primarily with modeling instruments, not people) usually are the
> first observation of the incident. CAP messages are for warning
> people and are sent to devices which facilitate this warning
> process. This is one of the six roles for information from sensing
> systems (warning, reporting, situational awareness/decision
> support, hazard prediction, consequence management, and if
> instrument sensor management and control.
>
>
> Since Incident Management is much more than just “Warning via CAP
> messages” other type of information flows (Workflows) are
> required. Unfortunately CAP messages are being used for this and
> because the other messaging roles of sensors requires machine to
> machine data exchange CAP messages are not the best way of doing
> this function.
>
>
> It was my hope the sensor and systems charter subcommittee would
> look at the process and roles of converting raw data into
> actionable information and the required informational elements
> which must be exchanged to manage an incident response. This would
> be one level higher than “use cases” since these “systems” would
> support a wide variety of incidents. This would complement the
> work Chip is funding to understand the resource message
> requirements needed by responders to support the consequence
> management action directed by the Incident Manager, who is
> directing the response effort.
>
>
> Tom Merkle and I thought this was a natural progress of the
> infrastructure charter.
>
>
> David E. Ellis
>
> Information Management Architect
>
> (505) 844-6697
>
>
>