Date: 2 August 2006 00:32:02 GMT+10:00
Subject: Re: [emergency-msg] Groups - EDXL-RM Information Model (EDXL-RM-Info-Model-2006-07-26.pdf) uploaded
I did say that I wasn't aware of using an information model as such in a specification, not that it hadn't been done. So, I stand corrected on that. As for using it in the EDXL RM, this is, as always, a committee decision, and I am certainly not taking a position against it, especially not since I agree with it and prefer it over the DOM. I'm just against the process we suffered through with the EDXL DE.
I agree with you on the "schedule" semantics, and I am not opposed to using IM. Could you refer me to specific urls for other information models? I am almost certainly going to have a stab at working up an EDXL Information Reference Model (using IRM to differentiate it from RIMs). Since we are using it, I want to be sure we understand where it fits in the specification process, and I believe we should include it in an appendix, with a clear explanation of how it is used, so that we avoid those months of confusion we had last year.
Thanks for the reference to when the SC accepted the Information Model as an "informative activity." I missed that for the reason I am about to discuss. My initial confusion here is falling into exactly the same time frame, e.g. the combined final late-spring and early summer US and International Conference Seasons merging into the summer vacation season in the Northern Hemisphere.
It shows my own absent-mindedness that I praised this development and then promptly forgot about it in the welter of my late June work schedule. I was in the final preparations for a combined National Health Information Network (NHIN) Forum and Medical Banking Project Leadership Forum, at that point, followed immediately by the trip to DC, with those two events Wednesday-Thursday, back to back. I mention this less as an excuse for my own absent-mindedness than as an example of what happens at this time of year.
We have those normal difficulties with getting consistent participation in our activities, so we need to be very careful and clear about how we arrive at the decisions we take so that those who miss a session here and there, as we all do on occasion, don't raise objections to what may erroneously be perceived as sudden changes which are in fact reasoned changes done in our absence, and may derive from the DOM, the Data Dictionary or the Information Model since we agreed to use it, and thus be reflected in the eventual XML Schema.
I have now had a chance to look over the Information Model, and it is exactly what I originally thought it would be, and now that I am looking it over, my reasons for wanting an EDXL IRM are stronger than ever.
As long as we don't fall into syndrome of confusing discussions of the info model with discussions of the DOM as we did last year, I think we can move ahead with it as a, dare I say, informative resource?
This year is particularly brutal because there are seveeral major federal level healthcare projects moving forward at breakneck pace. One, the American Health Information Community (AHIC) is proceeding with a year long series of work groups building a set of recommendations to bring the healthcare system into the 21st century in terms of IT, (including the NHIN Forum I attended) and we are on the verge of making some of the same mistakes the UK did in attempting to revamp the IT architecture of its National Healthcare System (NHS).
That particular exercise resulted in going from a four-year 4 Billion pound project to 10 years at 40 Billion pounds and counting, and it STILL sports a glaring SINGLE POINT OF FAILURE (Central Records) which the UK's county level districts are rightly refusing to support, even though they are breaking UK law by duplicating records at sites other than that central point of failure trainwreck waiting to happen. Needless to say, I am a bit caught up in trying to prevent our own leadership from falling right into that same trap.
Sorry for the confusion,
At 3:44 PM +1000 8/1/06, Renato Iannella wrote:
Rex (et al)
I am surprised by this view. We have found that the process of creating (and documenting) an information model aids tremendously in the understanding of the problem domain. In fact, the concept of the "schedule" with various semantics (like anticipated, actual, notBefore, notAfter) was highlighted in today's teleconference as a better way to approach all the dateTimes that are sprinkled throughout the data model elements. To support this in the DOM now would truly be the "weeds" you mention.
It took us over an hour to go thru and understand the elements just for the RequisitionResource message.
(How long will it take for a new reader of the final spec, and all 22 messages?)
My experiences in standards (W3C, IETF, OGC, etc) have always been driven by getting the requirements, then information model correct. Following this, the encodings (XML or RDF) fall out easier. There is wide accepted precedent for this across a number of standards bodies, including OASIS.
It would be useful to have an overarching EDXL Information Model, but it would not work with the way this TC operates currently. That is, a number of vertical specs, CAP, EDXL-DE, EDXL-RM, EDXL-HAVE that seem to get pushed thru as quickly as possible to meet an external need/agenda. This is fine, as long as you understand the consequences. Already there is confusion in the sector over CAP and EDXL-DE. Both of these should be revisited and a strategy planned (and made public) on their future paths.
As you can see in the Information Model document, there is no indication that it is a formal OASIS spec/document. (It even has a NICTA logo on it ;-) BTW, the information model was discussed at a teleconf and accepted as valid informative activity .
Note, historically, the "confusion" between the DOM and IM during the EDXL-DE days was primarily because the starting point of the the spec ignored the IM work, and went back to the DOM version. This was an operational error, but we did end up with a clearer data model at the end with some impact from the informational model. The big difference here was that the EDXL-DE was a simpler problem domain than the EDXL-RM.
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.
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702