RE: [emergency] HAVE comments - explicitly identifying thenormative parts in the data dictionary

[Rex Brooks <rexb@starbourne.com>]

Title: RE: [emergency] HAVE comments - explicitly identifying the

Hi Lee,

Understood and agreed. I would suggest we adopt whatever is finally decided in EDXL-HAVE for EDXL-RM, as we discussed in the EM-Msg meeting Thursday.

Cheers,

Rex

At 12:33 PM -0400 9/28/07, Lee Tincher wrote:

> Rex,
>  
> I am not aware of any standard Data Dictionary in our
> processŠ.as a matter of fact we have elements with the same names -
> but different definitions - within the EDXL standards now.  I
> agree with all of your statements, but I think it is a stretch to call
> our element descriptions in each of the differing standards a data
> dictionaryŠ.my hope is to standardize on one for all of our
> standards to remove confusionŠ.
>  
> Just a clarification noteŠ..
>  
> Thanks,
> Lee
> 'We the unwilling, led by the unknowing have been
> doing the difficult with little for so long that we are now ready to
> tackle the impossible with nothing.' -- Local Fire communications
> reserve volunteer motto

---

> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Friday, September 28, 2007 11:48 AM
> To: Lee Tincher; 'Rex Brooks'; 'Renato Iannella';
> emergency@lists.oasis-open.org
> Subject: RE: [emergency] HAVE comments - explicitly identifying
> the normative parts in the data dictionary
>  
> Hi
> Lee,
>  
> I think that
> including NIEM as a resource and an example in the RIM a very good
> idea. It can give us a credible example of the development of absract
> principles that guide the creation of concrete classes (elements) in
> specifications. We can then show how the elements can be used in
> applications as instances. Of course that requires some practitioners
> who are willing to share their processes.
>  
> Hopefully we
> will be able to clearly elucidate the chain from real world scenarios
> drawn from Subject Matter Experts to clearly drawn Use-Cases from
> which exacting requirements are derived. We should be able provide
> examples of how such requirements allow us to produce explicit
> elements in specifications that address and reference these
> requirements (which we do now in our data
> dictionary).
>  
> I think that
> providing this kind of traceable clarity is one of most significant
> contributions we can make both to the practice of Emergency Response
> Management and to the process of writing standards. We have learned a
> boatload of lessons which we can continue to use. I would love to see
> your experiences distilled as a set of lessons learned and
> recommendations for improving these processes.
>  
> As painful
> as these lessons can sometimes be, there are usually nuggets of
> practical wisdom in our experiences which might help make future work
> a tad easier, quicker, etc.
>  
> Cheers,
> Rex
>

At 10:25 AM -0400 9/28/07, Lee Tincher wrote:

I need to stress that this submission was supposed to be in complete relational xml structure as a message - the NIEM people selected to rip it apart to the element/attribute level.  It was never supposed to be made public and it was presented as an exercise to see if external standards could be utilized in NIEM - it failed miserably and we fought very hard to have it removed.  We lost the initial battle and it went out public - the good news is that they are putting in change management and governance that will allow a community of interest (OASIS TC?) to add/delete/modify these elements and attributes - so this can be fixed if the TC chooses to be involved·..

 

Should the TC elect to use NIEM as part of the RIM we can make the changes necessary to the NIEM Emergency Management Domain as necessary to support the EDXL standards - one of the key points we have discussed with NIEM is that the name  "National" in the name does not meet our needs internationally.  They are excited about the international concept and are willing to put up the governance to allow for international involvement·..

 

Thanks,

Lee

'We the unwilling, led by the unknowing have been doing the difficult with little for so long that we are now ready to tackle the impossible with nothing.' -- Local Fire communications reserve volunteer motto

---

From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Friday, September 28, 2007 9:37 AM
To: Renato Iannella; emergency@lists.oasis-open.org
Subject: Re: [emergency] HAVE comments - explicitly identifying the normative parts in the data dictionary

 

Hi Renato,

 

I wish this were an isolated instance, but NIEM is not the first or only place that unfinished OASIS TC specification work has turned up before a TC or working group (OASIS-wide, not just our EM TC) have approved a final document as a standard. One of the problems we are all working through is that the process of standard-writing and the requirements of the end-products are both still moving targets, and the recent addition of a Conformance Section requirement in OASIS is a case in point.

 

Sigh,

Rex

 

 

 

At 1:18 PM +1000 9/28/07, Renato Iannella wrote:

On 28 Sep 2007, at 11:59, Lee Tincher wrote:

 

NIEM is based on the Dublin-Core metadata descriptions (which specify normative definitions) and it has a well defined set of Naming and Design Rules (NDR).   Why do we need to continually re-invent the wheel? 

 

 

NIEM 2.0 is a bit confusing!

 

I looked at the XSD for Emergency Management [1] Domain Schema and can see a lot of the HAVE and RM

elements/attributes already in there.

 

How did they get in there "so quick" when we have not finished?

 

 

Cheers...  Renato Iannella

NICTA

 

[1] <http://www.niem.gov/niem-2/niem/domains/emergencyManagement/2.0/emergencyManagement.xsd>

 

 

--

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670

>  
>  
> --
> Rex
> Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670

--

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670