[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
This topic will be on the agenda for our meeting on Tues. Thanks for everyone's input. Elysa At 08:58 AM 11/19/2008, Rex Brooks wrote: >Thanks Lee, Gary, > >Gary nailed it. I hope that the message gets forwarded to the >appropriate folks. I agree with Lee that we need to take it up in >the TC and see what we can do to help the Adoption SC develop the >materials to help educate our audience better than we have so far. >We've had some good suggestions in that regard in the course of this >discussion, too, and I'm glad to see that happen. > >Cheers, >Rex > >At 10:26 PM -0500 11/18/08, Lee Tincher wrote: >>I am so happy to hear this response. We have been dealing with this exact >>same issue from a different discipline. I have not had success in getting >>support of the multiple bodies in a DE from that effort - in fact I have >>caused a great deal of delay in the effort by trying to establish that >>approach. >>I suggest that we take this into the next EM-TC level meeting and discuss >>the options we may have in promoting (or discussing the merits of) this >>approach. This is excessively important to multiple large scale efforts >>being currently worked on! >> >>Thanks, >>Lee >> >>Action springs not from thought, but from a readiness for responsibility. - >>Dietrich Bonhoeffer >> >> >>-----Original Message----- >>From: Gary Ham [mailto:hamgva@cox.net] >>Sent: Tuesday, November 18, 2008 9:47 PM >>To: creed@opengeospatial.org; 'Rex Brooks' >>Cc: 'Jacob Westfall'; emergency@lists.oasis-open.org; 'Lee Tincher'; 'Art >>Botterell'; gpercivall@opengeospatial.org; rsingh@opengeospatial.org >>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 >> >> >>--------------------------------------------------------------------- >>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]