RE: [emergency] EDXL/CAP Survey

[Elysa Jones <ejones@warningsystems.com>]

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