MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sia-pilot6] [emergency] EDXL-DE routing and valueListUrn
I do believe we need to develop some use cases with representative
distribution that can be published in an implementation guide. This
concept will take a bit to catch on and examples seem to be the best
approach. I would favor the start of an SC specifically focused on
implementation. This would give a home for new members of the TC that will
need a bit of guidance as they learn the process. I plan to put this on the
agenda for our meeting tomorrow.
Regards,
Elysa
At 06:33 PM 3/20/2006, Rex Brooks wrote:
>I don't think Carl misunderstood that different valueListUrns are
>possible. Of course, I could be wrong, but I doubt it. I think Carl's
>concern is that some people may think that Dave's proposal was for a
>single valueListUrn. I do not think Dave is doing that. I think Dave
>is responding to the call for various groups to start producing,
>publishing and maintaining these necessary valueListUrns so that we
>can start using them in EDXL_DE routed messages.
>
>All of the international groups and constituencies mentioned need to
>be informed that it is now incumbent upon them to provide these
>semantic resources so that their systems, be they SensorNets or
>weatherAlerts, can be properly connected through our Emergency
>Response Networks.
>
>Ciao,
>Rex
>
>At 5:00 PM -0700 3/20/06, Ellis, David wrote:
> >Content-class: urn:content-classes:message
> >Content-Type: multipart/alternative;
> > boundary="----_=_NextPart_001_01C64C7A.707355BB"
> >
> >Carl
> >
> >All of scenarios you have proposed could use seperate
> >valueListUrn to control distribution of data within defined Area of
> >Responsiblities. If transfer of data is needed between these AORs,
> >methods for exchanging messages are avaiable. When can we talk
> >about this. I believe all of your domain issues are potential
> >misunderstandings how routing is accomplished.
> >
> >David E. Ellis
> >Information Management Architect
> >(505) 844-6697
> >
> >
> >From: Carl Reed OGC Account [mailto:creed@opengeospatial.org]
> >Sent: Mon 3/20/2006 4:20 PM
> >To: Ellis, David; SIA Pilot-6; emergency@lists.oasis-open.org
> >Cc: Harry Haury; Haleftiras, Pericles; Glaser, Ronald
> >Subject: Re: [emergency] EDXL-DE routing and valueListUrn
> >
> >David -
> >
> >While I understand the urgency and while I do not necessarily disagree with
> >the contents of your slides on a National Effort for Emergency Data
> >Distribution, I would like to add a few words of caution.
> >
> >First, what you have outlined are uses cases and requirements for one domain
> >of use - alerts as related to secure US DoD sensor nets. I deal with folks
> >doing sensor systems and networks in a number of other countries - all
> >civilian. Any of these applications using sensors can create alerts. For
> >example, a new water portal in Canada that will send alerts based on stream
> >flow gauges, traffic alerts being generated by the new generation of ITS
> >capabilities, weather alerts, and systems function alerts being generated by
> >transducers, and so forth. We cannot loose sight of all the other potential
> >use cases that drives the requirements for EDXL - now and in the future.
> >
> >Second, and related to the first, is the fact that OASIS is an international
> >standards organization. As such, we cannot ignore requirements for using
> >EDXL that may be extremely viable in other countries. It is unfortunate that
> >we have had little input from organizations in other countries that have
> >requirements similar to the US DoD. That is why I am very pleased with the
> >progress of the Sensor Standards Harmonization work that NIST is
> >spearheading.
> >
> >Third, we would be remiss in ignoring the potential for alerts coming from
> >the emerging sensor nets being designed, built, and fairly recently deployed
> >for home systems and office buildings (office sensor networks are much more
> >mature). See
> ><http://www.usipv6.com/CES_Presentations/CES_Itaru_Mimura.pdf>http://www.
> usipv6.com/CES_Presentations/CES_Itaru_Mimura.pdf
> >as
> >well as all the work being done at UCLA (SOS) and Sun (SUN SPOT). These
> >systems are envisioned as being able to automatically generate alerts (fire,
> >carbon monoxide, health, etc).
> >
> >Finally, and anyone (someone) correct me if I am wrong, but perhaps the
> >COMCARE EPAD system would be a repository/registry solution.
> >
> >So, I agree that current DHS and DoD requirements are very valid and those
> >requirements must be answered by EDXL. But let's make sure we remain
> >balanced in our approach so that other communities outside DoD and DHS are
> >also fairly represented at that CAP and EDXL have used well beyond.
> >
> >Cheers
> >
> >Carl
> >
> >