MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] EDXL/CAP Survey
Hey Mike, On our EM-TC call today, the topic of NIEM (as well as the DRM)
was discussed. Now that the 6/13 meeting is over, do you think you would
have time to address our TC on the status and plans for NIEM? It would be
great if you could send us a couple of possible dates/times. Thanks! Elysa
At 12:37 PM 6/14/2005, Daconta, Michael wrote:
>Here are some clarifications for the group's benefit...
>
>1. The FEA DRM is distinct from NIEM and GJXDM.
>2. We agree that simplicity is important which is why NIEM (of which
>GJXDM forms the initial baseline) is taking a modular approach. NIEM
>0.1 will include a key subset called "universal core". We are
>internally vetting the universal core now. After internal vetting, we
>will release it for public vetting (same as we are doing with the DRM).
>3. We are piloting NIEM concepts before we release to insure that the
>approach is solid.
>
>Regards,
>
>Michael C. Daconta
>Metadata Program Manager
>Department of Homeland Security
>tel: (202)692-4340
>email: michael.daconta@dhs.gov
>
>-----Original Message-----
>From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
>Sent: Tuesday, June 14, 2005 10:51 AM
>To: 'Rex Brooks'; Emergency_Mgt_TC
>Subject: RE: [emergency] EDXL/CAP Survey
>
>Ok. Here is the other view:
>
>As I sit here looking through the DRM, I am lightly convinced
>that the chances the public safety industry will be implementing
>this soon are functionally zero.
>
>The problem of any top down design is the bottom up legacy that ensures
>that
>
>no clean break can ever be made given an active procurement cycle.
>No one starts from scratch and the active legacy is much more
>important to the agency than Federal mandates. Changing a tire
>on a moving car in an intersection is dangerous work.
>
>GJXDM as a big honking piece of middleware for bits on the
>wire is possible. It isn't likely that the relational system
>schemas will be changed to match the unwieldy and verbose
>GJ elements:
>
>1. Not a good design for relational systems. Performance
> requirements for queries typically range from one to
> four seconds for a query of medium complexity. These
> designs favor too much standalone context.
>2. It is too disruptive to unhorse all of the
> current systems to convert their data.
>3. RDF is a non-starter. Show us the commercial
> frameworks (say operating systems and programming
> frameworks with more than 10% of the market) that
> support it today because even if supported today,
> there is about a three to five year gap to fielding of
> robust, secure, reliable products.
>4. IEPs are a good idea but every agency we
> deal with has its own reports, some State mandated,
> some agency mandated, some JIT ad hoc. How many
> years are given for any local agency to convert to
> the IEPs (keep in mind how many states are still UCR
> despite NIBRS)?
>
>At some point, DHS and DoJ are going to realize that
>there isn't enough funding to get this done and they
>will vastly simplify the requirements. The Federal
>budget is strained and there is no end in sight to the
>Executive-initiated events that are draining resources.
>
>A roll-out plan that confronts the reality of the
>procurement and legacy issues is needed. It will
>have to be much simpler because submarining these
>languages in by reference to GJXDM means that the
>vendors and procurement officials will waive the
>bulk of GJXDM in favor of the 'most useful' subset
>as determined by the local agency.
>
>len
>
>
>From: Rex Brooks [mailto:rexb@starbourne.com]
>
>Hi Len,
>
>CAP is now included in GJXDM, so RFPs contingent on the GJXDM are
>also axiomatically contingent on CAP compliance within GJXDM, if
>required.
>
>DHS will likely stipulate CAP in its applicable RFPs. the Public
>Forum for the Data Reference Model yesterday included CAP because it
>was part of the pilot we (Starbourne) will be doing for the Semantic
>Interoperability Architecture effort for September. I will keep this
>group apprised of that work as it proceeds.
>
>EDXL is likely to be a key piece of NIMS as it gets built out. We are
>hammering on the Distribution Element again today.
>
>Ciao,
>Rex
>
>At 8:39 AM -0500 6/14/05, Bullard, Claude L (Len) wrote:
> >Something to chew on. This week I received
> >a COMCARE survey for information on EDXL/CAP
> >implementations, customers, populations served, etc.
> >I have to reply that as of this time, we have
> >no information about that to be released.
> >
> >As mentioned previously, public safety is an
> >RFP-driven business. Requirements that don't
> >show up in at least three separate RFPs aren't
> >likely to be implemented soon if ever. How
> >is this group and its supporters in government
> >working to see to it that these specifications
> >and standards are introduced commercially to
> >the public safety industry through procurement
> >processes?
> >
> >Are there papers that explicitly illustrate where
> >these standards fit into the product mix that an
> >agency would be acquiring when purchasing say
> >Dispatch, police, fire and EMT records systems?
> >
> >Who declares a situation that would result in
> >an EDXL/CAP message being broadcast? Who receives
> >it and under what jurisdiction?
> >
> >We've discussed some of these topics briefly in the
> >past, but I think that before we will see these
> >standards in more than one or two very large
> >procurements, the procurement officials need help
> >with the requirements language. I see mentions of
> >GJXDM but little of EDXL/CAP.
> >
> >len
> >
> >---------------------------------------------------------------------
> >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
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309
>
>---------------------------------------------------------------------
>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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]