Re: [emergency] RE: Recent CBRN Interoperability for Situational Awareness Workshop

["Carl Reed" <creed@opengeospatial.org>]

Thanks for the clarification.  Apologies for the delay in responding. Been 
hopping from one conference to the next. This week it was Ocean Sensor 
System Semantic Interoperability. Quite interesting.

Cheers

Carl

----- Original Message ----- 
From: "Gary Ham" <hamgva@cox.net>
To: <creed@opengeospatial.org>; "'Rex Brooks'" <rexb@starbourne.com>
Cc: "'Jacob Westfall'" <jake@jpw.biz>; <emergency@lists.oasis-open.org>; 
"'Lee Tincher'" <ltincher@evotecinc.com>; "'Art Botterell'" 
<abott@so.cccounty.us>; <gpercivall@opengeospatial.org>; 
<rsingh@opengeospatial.org>
Sent: Tuesday, November 18, 2008 7:46 PM
Subject: RE: [emergency] RE: Recent CBRN Interoperability for Situational 
Awareness Workshop


> Carl,
>
> The DE has the ability to contain SensorML as a payload and has the
> appropriate structures that allow it to be intelligently routed as
> necessary.  The SensorML itself would stay undisturbed.  No sense
> reinventing the wheel.  My thought is that sensor readings are generally 
> not
> public alerts in the more conventional CAP sense.  They are sensor reading
> that might trigger CAP alerts.  The DE is designed to provide a wrapper 
> for
> any emergency information. The wrapper it provide for a geographic target
> "area of interest", characterization of the content in a variety of ways,
> and identification of the content.  The content itself stays pure inside 
> the
> distribution wrapper.   That content can be pure SensorML, pure CAP, pure
> Resource, pure HAVE, pure HL7, or even proprietary.  In fact multiple
> contents of different kinds can be put into the same wrapper and send
> together if desired.
>
> The DE target area does, in a future release, need to become a
> geo-oasis:where.  It is currently the same structure as CAP, but it can
> contain any standard GML as content quite easily. Even without change.
>
> R/s
>
> Gary A. Ham
> http://grandpaham.com
> 703-899-6241
> Grandpa can do IT!
>
>
> -----Original Message-----
> From: creed@opengeospatial.org [mailto:creed@opengeospatial.org]
> Sent: Tuesday, November 18, 2008 6:48 PM
> To: Rex Brooks
> Cc: Jacob Westfall; emergency@lists.oasis-open.org; Lee Tincher; 'Art
> Botterell'; creed@opengeospatial.org; gpercivall@opengeospatial.org;
> rsingh@opengeospatial.org
> Subject: Re: [emergency] RE: Recent CBRN Interoperability for Situational
> Awareness Workshop
>
> Apologies - but being a bit of a slacker WRT EDXL-DE, I was wondering if
> the DE elements for sensors have been aligned (harmonized) with the OGC
> SWE standards baseline concepts, taggage, etc. Reason I ask is that there
> will soon be a registry of sensor descriptions (metadata, processes, etc)
> using SensorML. These SensorML files have been or are being defined for
> all NASA satellites, a number of UAV's, many classified sensor systems,
> most aerial digital cameras, just about all of the ocean sensors, and
> already a number of weather sensor types. I would hate to duplicate work
> or have competing methods for describing a sensor.
>
> Carl
>
>> Hi Jacob,
>>
>> These are the questions we need to discuss. My personal opinion is
>> that we should start with the issues surfaced in the CAP-NextGen
>> Comments, and include the specific concern from Carl Reed's earlier
>> message this morning "... CAP implementations in this community are
>> doing a variety of interesting additions (such as embedding sensor
>> metadata) that will make the implementations non-interoperable. ..."
>>
>> We gave EDXL-DE the capability to handle 4 kinds of sensor
>> information as distributionTypes:
>> Sensor Configuration;
>> SensorControl;
>> SensorStatus; and
>> SensorDetection.
>>
>> So, I think we need to create guidance-education-usage notes for
>> EDXL-DE and CAP simultaneously for this particular issue. Developing
>> clear examples for this issue and the others we address in these
>> notes is, in my opinion, key to helping our audience understand how
>> to apply the specifications.
>>
>> Cheers,
>> Rex
>>
>> At 10:49 AM -0500 11/18/08, Jacob Westfall wrote:
>>>  > mechanisms focused on particular issues would be helpful. As Art
>>>>  notes, we may eventually see patterns develop that we can incorporate
>>>>  in a more comprehensive document if we think that's best.
>>>
>>>So instead of a sensor profile, or single best practices guide,
>>>create a number of "application notes" or "usage guides"?  What
>>>would these guides be called and the topics be?  Is this something
>>>Adoption might want to ask for comments/feedback on from the CAP
>>>community in order to develop a list?
>>>
>>>--
>>>jake@jpw.biz
>>>--
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>>generates this mail.  Follow this link to all your TCs in OASIS at:
>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> --
>> Rex Brooks
>> President, CEO
>> Starbourne Communications Design
>> GeoAddress: 1361-A Addison
>> Berkeley, CA 94702
>> Tel: 510-898-0670
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to 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.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>