OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]