Re: [emergency] Illogical Structure?

[Art Botterell <acb@incident.com>]

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
>
>
> -----Original Message-----
> From: Art Botterell [mailto:acb@incident.com]
> Sent: Friday, July 15, 2005 3:21 PM
> To: Emergency Mgt XML TC
> Subject: [emergency] Illogical Structure?
>
>
> Folks -
>
>
> I'm concerned that we might be constructing next-generation
>
> stovepipes into our subcommittee/working-group structure.
>
>
> Basically, I think, all info systems comprise only five basic types
>
> of nodes:
>
>
> * Sensors, in the broad sense, observe the real world and represents
>
> events and conditions there by outputting data according to some more-
>
> or-less specified model.  (In this sense a human input tool... a
>
> keyboard or a mouse, for example... can be viewed as a class of  
> sensor.)
>
>
> * Actuators ingest data inputs and effect some change in the "real"
>
> environment.  These can include displays, alarms, switches, valves...
>
> anything that transforms data into a physical manifestation.
>
>
> * Gateways perform rule-based transformations between data formats.
>
>
> * Processors are akin to gateways, in that they have data inputs and
>
> data outputs, but the transformations they perform are more complex,
>
> involving additional factors such as other concurrent data inputs,
>
> cumulative calculations of state,  historical/statistical
>
> representations of patterns and trends in various dimensions
>
> (temporal and geospatial being the most common in emergency
>
> applications) as well as simple input-triggered rules.
>
>
> * Registers (aka databases) accumulate and retain data in some
>
> persistent form, either by factoring new data into an ongoing
>
> calculation of system state or by journaling individual data arrivals
>
> in some form of list, or sometimes both.
>
>
> Every application and function involves many if not all of these
>
> components, and most of those components will be either pre-existing
>
> or otherwise invariant.  Our work in data standards has more to do
>
> with the conversations between these nodes than with the nodes
>
> themselves, so organizing ourselves by node-type seems maybe a bit
>
> out of tune with our mission.
>
>
> I'd like to suggest that we define our basic working groups around
>
> particular projects, with additional ad-hoc teams to address
>
> particular technical or operational questions that require in-depth
>
> research or special expertise.  That would leave it up to the TC as a
>
> whole to look after issues of consistency and coherence in our work
>
> products, which seems appropriate to me.
>
>
> Concrete examples of this sort of structure would be an EDXL DE
>
> working group for the project-oriented team, and our existing GIS
>
> group as a particularly durable example of the special-issue type.
>
>
> If there are, in fact, issues specific to sensor systems in some
>
> narrow definition, that could certainly be addressed by a temporary,
>
> goal-oriented workgroup.  But I don't think we want to conflate
>
> sensor issues with workflow issues... lots of applications have their
>
> own inherent workflows and there's no guarantee that a sensor-
>
> oriented team could achieve a global view of that very broad topic.
>
>
> (From a bench in front of SFO, loving the low humidity...)
>
>
> - Art
>
>
>
> On Jul 15, 2005, at 12:47 PM, Elysa Jones wrote:
>
>
> > Most of what we do with our EM standards work involves the movement
>
> > of information in response to a detected event - be that a visual
>
> > or otherwise "sensed" event.  Much of the discussion about
>
> > "systems" was actually more about work flow and dissemination of
>
> > information during an incident.  We may should revisit the terms we
>
> > use so as not to be misunderstood - say sensors and work flow?  We
>
> > deemed it important to designate sensors separately due to the work
>
> > that is developing in the labs and elsewhere that EM standards are
>
> > needed.  These groups are looking to the TC for guidance and having
>
> > a special place they can discuss their specific needs would be
>
> > helpful.  Comments?  Elysa
>
> >
>
> > At 11:06 AM 7/15/2005, Kon Wilms wrote:
>
> >
>
> >> I guess that proves my point.
>
> >>
>
> >> Cheers
>
> >> Kon
>
> >>
>
> >> On Fri, 2005-07-15 at 06:58 -0400, Vandame, Richard wrote:
>
> >> > Non-sensers, perhaps.
>
> >> >
>
> >> > Rich
>
> >> >
>
> >> > -----Original Message-----
>
> >> > From: Kon Wilms [mailto:kon@datacast.biz]
>
> >> > Sent: Thursday, July 14, 2005 5:20 PM
>
> >> > To: Rex Brooks; emergency@lists.oasis-open.org
>
> >> > Subject: [emergency] Illogical Naming was: Re: [emergency]
>
> >> Sensors and
>
> >> > Systems Charter Starting Point
>
> >> >
>
> >> > I have to say that I still do not see the logic behind the
>
> >> naming of
>
> >> > these focus groups.
>
> >> >
>
> >> > A sensor network is a system (and may comprise multiple
>
> >> systems), for
>
> >> > example. What category do systems that do not make use of
>
> >> sensors fall
>
> >> > under?
>
> >>
>
> >>
>
> >>
>
> >>  
> ---------------------------------------------------------------------
>
> >> To unsubscribe from this mail list, you must leave the OASIS TC  
> that
>
> >> generates this mail.  You may a link to this group and all your
>
> >> TCs in OASIS
>
> >> at:
>
> >> https://www.oasis-open.org/apps/org/workgroup/portal/
>
> >> my_workgroups.php
>
> >>
>
> >
>
> >
>
> >
>
> >
>
> >  
> ---------------------------------------------------------------------
>
> > To unsubscribe from this mail list, you must leave the OASIS TC that
>
> > generates this mail.  You may a link to this group and all your TCs
>
> > in OASIS
>
> > at:
>
> > https://www.oasis-open.org/apps/org/workgroup/portal/ 
> my_workgroups.php
>
> >
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe from this mail list, you must leave the OASIS TC that
>
> generates this mail.  You may a link to this group and all your TCs  
> in OASIS
>
> at:
>
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>