MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: 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).
Cheers,
Rex
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
>>discussed.
>
>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
>>message.
>
>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
>>optional.
>
>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* Model.
>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 legally
>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 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]