[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]