OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [emergency] Re: [emergency-msg] Groups - EDXL-RM Information Model (EDXL-RM-Info-Model-2006-07-26.pdf) uploaded

Rex and All - please see the below...

Thought you might be interested that ASTM (the American Society for Testing
& Materials, a standards-setting organization on the order of ANSI or
UL) has a committee called E54 Committee on Homeland Security. This
Committee that has a subcommittee working on a standard called Standard
Guide for Developing Model Emergency Operations Plans in Response to
All-Hazard Events Including CBRNE WK5498
<http://myastm.astm.org/SUPPORT_DOCS/E5402000206001.pdf>  (REFERENCE


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Monday, July 31, 2006 9:34 AM
To: Renato Iannella; Patti Aymond; Emergency_Mgt_Msg_SC
Cc: emergency@lists.oasis-open.org
Subject: [emergency] Re: [emergency-msg] Groups - EDXL-RM Information Model
(EDXL-RM-Info-Model-2006-07-26.pdf) uploaded

Hi All,

I'm copying the TC on this because I am afraid that we are taking a 
side trip off into the weeds again.

Having just gotten the first draft of the second of the recent HHS 
RFIs that specifically relates to the White House's Katrina: Lessons 
Learned recommendations for one of three groups I'm working on that, 
I still haven't had sufficient time to absorb the Information Model, 
but I did want to point out two things:

1. we can use such a model to help us write the specification, but;
2.  we do not have any mandate from the TC or anywhere else to create 
it as either part of the spec or as a separate spec.

The confusion between the DOM and the information model for the DE 
caused us no end of chasing out tails in discussions that distracted 
us from the actual task. That doesn't mean that no value came from 
those discussions, just that they distracted and confused us/me.

I say all this because I do believe we need an overarching EDXL 
Information Reference Model. Note, this is entirely different in 
purpose, but neither in methodology nor in intent (to guide) which is 
different from purpose (specific objective)than what Renato has 
produced. Let me explain:

There is no precedent for this, where there is a precedent for 
Reference Models per se. There is also no specific precedent, (as far 
as I know--so this is supposition) in standards work for a 
standard-specific information model, either. The fact I'm not aware 
of something doesn't mean it doesn't exist.

However, the important function of such an Information Reference 
Model would be to serve as a resource, apart from a given 
specification, that informs us about how the general case for 
classes, operations/methods and workflows is envisioned and should be 
a guide for a specification or group of related specifications. The 
problem arises when a particular information model is created for a 
particular specification, as Renato has done twice now.

This is not to say that this does not have value for us, but it is 
easily confused with the DOM or other structural representations of a 
specification. I want to avoid repeating that exercise.

However, we can take these two exercises and look at them as tools 
for understanding what we are doing as long as we don't confuse them 
with the actual specification.

In that sense, what Renato has done is exactly how I would go about 
creating an overall EDXL Information Reference Model, i.e. a model of 
the information classes, operations/methods and workflows for the 
family of EDXL specification. Such an GUIDANCE INSTRUMENT should 
(IMO) be derived from requirements in a bottom-up fashion in order to 
produce a top-down model we can then follow either for a particular 
specification or across a group of specifications.

It was for the latter, providing a model for the remaining the EDXL 
specifications, that I originally proposed that we should develop an 
EDXL Information Reference Model as an ABSTRACT MODEL more like a 
Conceptual Reference Model (CRM), conceived and produced as an RDF 
Schema (.rdfs) and/or and OWL Ontology (.owl).

Just FYI,  I am finishing up an example of the kind of unified XML, 
RDF and OWL specification that an overarching Information Reference 
Model would be capable of providing guidance for, and it aligns with 
the International Council of Museums (CIDOC) Conceptual Reference 
Model (CIDOC CRM if you want to google it). THE CIDOC CRM, btw, is a 
10+ year project and is written in RDF Schema (.rdfs).


At 3:17 PM +1000 7/31/06, Renato Iannella wrote:
>On 28 Jul 2006, at 05:19, Aymond, Patti wrote:
>>Page 1 Paragraph 3
>>Your SimpleResponseMessage concept has me thinking. Maybe we don't need
>>a different response message type for every type of message sent. Maybe
>>we simply need a Message Response message type that has a Response
>>element that can be either "Acknowledge", "Accept", "Decline", or
>>"Conditional". We haven't dealt with a conditional response, but I think
>>we need to give that as an option. If, for example, the Message Response
>>message has a Response value of "Accept" and the OriginalMessageID is
>>for a Request For Information message type, then the message would
>>include the information requested. I think we would need to add an
>>element OriginalMessageType as well to ensure unambiguous interpretation
>>of message responses. Anyway, that's just a thought that can be
>The reason for the "simple" message type was to make it easier to 
>specify simple
>messages - as they don't have much content. The other message types 
>are more complex
>and warranted their own entity/class.
>>I think Update, Cancel, and NotifyAuxiliaryRecipients message types
>>needs to be included to minimize data integrity errors. Keep in mind
>>that we cannot assume that the messages will be within an EDXL-DE
>The original Requirement#1 states that the RM is dependent on a 
>routing mechanism
>(specifically, the DE) - so I think we can assume this??
>We don't want to get into routing/distribution in the RM, so we 
>should leave it to the DE.
>>Page 1 Paragraph 5
>>Keep in mind that there are schedules for more than one entity:
>>Producers Anticipated time/location (when I need it and where I need it)
>>Producers Actual time/location (when I got it and where I got it)
>>Consumers Anticipated time/location (when I can send it and where I can
>>send it from) Consumers Actual time/location (when I sent it and 
>>where I sent it from)
>We think we can support this, and will make it clearer in the next version.
>We do, however, need to define Producer/Consumer more clearer...
>>Page 2 Figure 1
>>The element Contact should be ContactInformation, although I do like the
>>name Contact better. We should discuss changing this. Also, it is
>>optional - not required. The ContactInformation element, when present,
>>must contain the sub-element Role. All of the other sub-elements are
>The association between Contact and Keyword is the "role" - we will 
>add this...
>>In the DOM, we do not have FundingCode and FundingInfo elements within a
>>Funding element, but I like this idea. In the DOM, we have FundCode with
>>a multiplicity of [0..*], and we have FundingInfo [0..1]. Should these
>>be consistent? Again, other areas for SC discussion.
>We haven't shown the cardinalities on the class attributes 
>(elements) yet...next version...
>>The resource element is not consistent with the DOM. We need to keep the
>>structure consistent.
>They probably will never be exact as we are creating an *Information*
>For example, Quantity is more related to the Resource, than ResourceInfo.
>>Page 3 Paragraph 5
>>I like this hierarchy, but I think the CommittedRM/UncommittedRM types
>>need some clarification. I'm not sure from this document exactly 
>>how they work.
>Yes, we will add more...
>Cheers...  Renato Iannella
>National ICT Australia (NICTA)
>This email and any attachments may be confidential. They may contain
>privileged information or copyright material. You should not read, copy,
>use or disclose them without authorisation. If you are not an intended
>recipient, please contact us at once by return email and then delete both
>messages. We do not accept liability in connection with computer virus,
>data corruption, delay, interruption, unauthorised access or unauthorised
>amendment. This notice should not be removed.
>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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]