[New-ITS] Name for a flattened, association-collapsed model derived from an RMIM
Lloyd McKenzie
lloyd at lmckenzie.com
Wed Aug 16 15:07:19 BST 2006
There's nothing XML about the model. It could be used in a Java
interface or anything else . . .
(Though I do love the abbreviation :>)
Grahame Grieve wrote:
> oh, btw, how about XUM? pronounced "zoom" in west country
> english ;-)
>
> XUM = XML UML Model
>
> Grahame
>
>
> Tim Benson wrote:
>> Grahame,
>>
>> It really does not matter what it is called as long as it is not easily
>> confused with another TLA. For this reason I would not suggest MMM
>> which
>> will inevitably be referred to as 3M, which is a well-known
>> trademark, with
>> large healthcare interests. I would also prefer not to see the word
>> model,
>> unless it is a model in the UML sense of the word.
>>
>> CEN CR 12587 defined an IMS as an Implementable Message
>> Specification, which
>> might be revived.
>> It is always good to reuse existing terms and meanings and avoid the
>> temptation of neologism, otherwise known as humpty-dumptyism.
>>
>> Tim
>>
>> On 16/8/06 09:06 Grahame Grieve wrote:
>>
>>> how about MMM for Mere Mortals Model
>>>
>>> The rationale for replacing the existing XML ITS
>>> with a new UML ITS:
>>> * the xml its is broken in a couple of small places. fixing it
>>> won't be backwards compatible
>>> * the uml its will be easier to implement (we hope)
>>> * though it's easy to say that you can convert between the models,
>>> this takes time and resources, both at development and run time,
>>> and this will force people to choose. But there will be no choice.
>>> Offering 3rd party conversion tools, whether free or commercial,
>>> will not be a solution (might be a problem in it's own right)
>>> * it will be extra work to maintain 2 ITS specifications
>>>
>>> Rationale for not replacing it
>>> * people are already implementing XML ITS
>>> * we explicitly allowed for multiple ITS's. Indeed, they both
>>> already exist.
>>>
>>> I am not at sure which is a better approach. I believe that further
>>> investigation will be required, including actual implementation,
>>> before we get a feel for the answer.
>>>
>>> Grahame
>>>
>>>
>>> Charlie McCay wrote:
>>>> Lloyd
>>>>
>>>> I understood that IM was rejected because we already have lots of
>>>> Information Models.
>>>>
>>>> It is yet to be established whether the collapsed model approach, if
>>>> endorsed, would be an alternative to or replacement for, the current
>>>> ITS. There was a view expressed in INM that maintaining both may
>>>> not be
>>>> the best way to go forwards.
>>>>
>>>> Every model is platform independent to some degree. One take on the
>>>> collapsing process would be to say that it was intended to generate
>>>> models that were appropriate for implementation using XML, and as such
>>>> would be platform specific. Another would be that it was to produce
>>>> models that were appropriate for any generic implementation technology
>>>> (ie an Abstract Implementation Model), in this case I would agree that
>>>> it would be inappropriate to say that the models were platform
>>>> specific.
>>>> One of the issues that we need to explore is whether targeting just
>>>> XML
>>>> for the implementation models makes a significant difference.
>>>> There are
>>>> differing expectations as to what the outcome of that will be.
>>>>
>>>> All the best
>>>>
>>>> Charlie
>>>>
>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D
>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES
>>>> tel 01743 232278 / 07808 570172 skype: charliemccay
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com]
>>>>> Sent: 11 August 2006 17:17
>>>>> To: Sato Laura
>>>>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk
>>>>> Subject: Re: [New-ITS] Name for a
>>>>> flattened,association-collapsed model derived from an RMIM
>>>>>
>>>>> Hi Laura,
>>>>>
>>>>> The issue is that HL7 can be implemented in both collapsed
>>>>> and non-collapsed manners. The model is also platform-independent.
>>>>>
>>>>>
>>>>> Lloyd
>>>>>
>>>>> Sato Laura wrote:
>>>>>> I realise that I'm a little late into this conversation,
>>>>> but... what
>>>>>> was wrong with Implementable Model - is it the acronym, IM,
>>>>> that's too
>>>>>> like something else? What I liked about 'implementable' was that it
>>>>>> gave the sense of the view for which the model was designed
>>>>> for (i.e.
>>>>>> implementers). It gave a focus for what it was supposed to
>>>>> accomplish.
>>>>>> Scanning through the other terms, I don't mind
>>>>> Platform-Specific Model,
>>>>>> if that's truly what it is (is it?). Transmission Model
>>>>> might be okay.
>>>>>> Semantically Equivalent Model doesn't say anything to me
>>>>> about what it's
>>>>>> for, so I'm not crazy about this one.
>>>>>>
>>>>>> Just my 2p...
>>>>>>
>>>>>> Regards,
>>>>>> Laura
>>>>>> _________________________
>>>>>> Laura Sato
>>>>>> Informatics Standards Lead
>>>>>>
>>>>>> Communications & Messaging
>>>>>> NHS Connecting for Health
>>>>>> Mobile: (44) (0)7733 324 338
>>>>>> Email: laura.sato at cfh.nhs.uk
>>>>>> www.connectingforhealth.nhs.uk
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: new-its-bounces at lists.hl7.org.uk
>>>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden
>>>>>> Sent: 10 August 2006 18:18
>>>>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie
>>>>>> Cc: new-its at lists.hl7.org.uk
>>>>>> Subject: [New-ITS] Name for a flattened,association-collapsed model
>>>>>> derived from an RMIM
>>>>>>
>>>>>> Not sure about 'optimised' because:
>>>>>>
>>>>>> - Optimised implies the best in some sense; but it may not
>>>>> yet be the
>>>>>> best, just better
>>>>>> - The acronym 'OM' somehow is not very snappy - hard to
>>>>> read as a word
>>>>>> (or a bit Buddhist?).
>>>>>>
>>>>>> I have two other suggestions:
>>>>>>
>>>>>> - Transmission Model, or TM (still a bit Buddhist?)
>>>>>> - Semantically Equivalent Model, or SEM
>>>>>>
>>>>>> I like the last because it tells people we are not messing with RIM
>>>>>> semantics.
>>>>>>
>>>>>> Anyway, the acronym is now a variable in the tools, and I
>>>>> can change it
>>>>>> daily. We could put it to a vote at the WGM.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London
>>>>>> EC1A 7JN
>>>>>>
>>>>>> phone: 44 1353 777668; Fax 44 1353 777394;
>>>>> mobile: 44 7970
>>>>>> 197968
>>>>>>
>>>>>> *************************** E-mail confidentiality notice
>>>>>> *******************************
>>>>>>
>>>>>> This message is intended for the addressee only. It is private,
>>>>>> confidential and may contain
>>>>>> information of a proprietary nature. If you have received
>>>>> this message
>>>>>> in error, please notify
>>>>>> us and remove it from your system.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk]
>>>>>> Sent: 09 August 2006 17:44
>>>>>> To: Lloyd McKenzie
>>>>>> Cc: grahame at jivamedical.com; Robert Worden
>>>>>> Subject: RE: Steering RMIM reshaping
>>>>>>
>>>>>> Well -- we were trying to avoid C words -- so "optimized"
>>>>> seems the best
>>>>>> offering so far
>>>>>> All the best
>>>>>> Charlie
>>>>>>
>>>>>>
>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D
>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES
>>>>>>
>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com]
>>>>>>> Sent: 09 August 2006 17:08
>>>>>>> To: Charlie McCay
>>>>>>> Cc: grahame at jivamedical.com; Robert Worden
>>>>>>> Subject: Re: Steering RMIM reshaping
>>>>>>>
>>>>>>> Hi Charlie,
>>>>>>>
>>>>>>> Calling it a "practical" model sends the wrong message about
>>>>>>> the existing structure. Executable model suggests that it's
>>>>>>> an internal object model, which it isn't.
>>>>>>>
>>>>>>> What this is is a "collapsed" or "compressed" or "optimized"
>>>>>>> or some other transformation type word.
>>>>>>>
>>>>>>>
>>>>>>> Lloyd
>>>>>>>
>>>>>>> Charlie McCay wrote:
>>>>>>>
>>>>>>>> So how about practical model or exchange model or executable model
>>>>>>>>
>>>>>>>>
>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D
>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES
>>>>>>>>
>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com]
>>>>>>>>> Sent: 09 August 2006 16:22
>>>>>>>>> To: Charlie McCay
>>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden
>>>>>>>>> Subject: Re: Steering RMIM reshaping
>>>>>>>>>
>>>>>>>>> Hi Charlie,
>>>>>>>>>
>>>>>>>>> The challenge is that many will read "physical model" in its
>>>>>>>>> usual sense, which is persistence model, which we definitely
>>>>>>>>> shouldn't be suggesting, let alone imposing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Lloyd
>>>>>>>>>
>>>>>>>>> Charlie McCay wrote:
>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Why not? -- the intent is to provide the model for the physical
>>>>>>>>>> exchange (subject to ITS realisation, but that is the
>>>>>>>>>>
>>>>>>>>> model-reality
>>>>>>>>>
>>>>>>>>>> mapping) -- it is this practical model that is exactly what
>>>>>>>>>>
>>>>>>>>> we do want
>>>>>>>>>> from HL7, and that we have been using the logical
>>>>>>>>>>
>>>>>>>>> information model
>>>>>>>>>
>>>>>>>>>> as a proxy for until now
>>>>>>>>>>
>>>>>>>>>> Alternative that I do not like as much:
>>>>>>>>>>
>>>>>>>>>> EM exchange model / executable model
>>>>>>>>>>
>>>>>>>>>> charlie
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems
>>>>>>>>>>
>>>>>>> Ltd, 23D
>>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES
>>>>>>>>>>
>>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com]
>>>>>>>>>>> Sent: 09 August 2006 16:02
>>>>>>>>>>> To: Charlie McCay
>>>>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden
>>>>>>>>>>> Subject: Re: Steering RMIM reshaping
>>>>>>>>>>>
>>>>>>>>>>> Hi Charlie,
>>>>>>>>>>>
>>>>>>>>>>> I don't want to imply that HL7 defines actual physical
>>>>>>>>>>>
>>>>>>> models . . .
>>>>>>>
>>>>>>>>>>> Lloyd
>>>>>>>>>>>
>>>>>>>>>>> Charlie McCay wrote:
>>>>>>>>>>>
>>>>>>>>>>>> How about
>>>>>>>>>>>>
>>>>>>>>>>>> PM -- Physical/(?Practical?) Model ?
>>>>>>>>>>>> PM / PSM (Platform model (Platform Specific Model)
>>>>>>>>>>>>
>>>>>>>>>>>> All the best
>>>>>>>>>>>>
>>>>>>>>>>>> Charlie
>>>>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems
>>>>>>>>>>>>
>>>>>>>>> Ltd, 23D
>>>>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES
>>>>>>>>>>>>
>>>>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com]
>>>>>>>>>>>>> Sent: 08 August 2006 05:45
>>>>>>>>>>>>> To: grahame at jivamedical.com
>>>>>>>>>>>>> Cc: Robert Worden; Charlie McCay
>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except CM is used for CMET. Not sure we need a different
>>>>>>>>>>>>>
>>>>>>>>>>> id if the
>>>>>>>>>>>
>>>>>>>>>>>>> models are just transforms of each other.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Grahame Grieve wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> CM = collapsed model or computable model
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> we could go with that
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Grahame
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lloyd McKenzie wrote:
>>>>>>>>>>>>>> We can't use the word "Message"
>>>>>>>>>>>>>> because we'll presumably
>>>>>>>>>>>>>>
>>>>>>>>>>> be using
>>>>>>>>>>>
>>>>>>>>>>>>>> this stuff for documents too. How about just
>>>>>>>>>>>>>>
>>>>>>>>> "collapsed model",
>>>>>>>>>
>>>>>>>>>>>>>> seeing as that's what it is . . .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Grahame Grieve wrote:
>>>>>>>>>>>>>> we've been using the term
>>>>>>>>>>>>>> implementable model. IM,
>>>>>>>>>>>>>>
>>>>>>> I know....
>>>>>>>
>>>>>>>>>>>>>> maybe you could go for "message design"? it's not
>>>>>>>>>>>>>>
>>>>>>>>>>>>> strictly a model,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> cc: Charlie for an opinion
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Grahame
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert Worden wrote:
>>>>>>>>>>>>>> Grahame -
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend
>>>>>>>>>>>>>>
>>>>>>>>>>> to confuse
>>>>>>>>>>>
>>>>>>>>>>>>>> people; we are making something strictly derived from
>>>>>>>>>>>>>>
>>>>>>>>>>>>> the RMIM and
>>>>>>>>>>>>>
>>>>>>>>>>>>>> suitable for implementation, which may have DAM-like
>>>>>>>>>>>>>>
>>>>>>>>> names and
>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop
>>>>>>>>>>>>>>
>>>>>>>>>>> calling it a
>>>>>>>>>>>
>>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped
>>>>>>>>>>>>>>
>>>>>>>>>>>>> RMIM'. Any suggestions?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped
>>>>>>>>>>>>>>
>>>>>>>>>>> Implementation
>>>>>>>>>>>
>>>>>>>>>>>>>> Model?
>>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Give me an acronym and I will do a global edit...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Close, London
>>>>>>>>>>>>>
>>>>>>>>>>>>>> EC1A 7JN
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394;
>>>>>>>>>>>>>>
>>>>>>>>>>>>> mobile: 44 7970
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 197968
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *************************** E-mail confidentiality notice
>>>>>>>>>>>>>> *******************************
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message is intended for the addressee only. It is
>>>>>>>>>>>>>>
>>>>>>>>>>> private,
>>>>>>>>>>>
>>>>>>>>>>>>>> confidential and may contain information of a
>>>>>>>>>>>>>>
>>>>>>>>>>>>> proprietary nature.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you have received this message in error, please
>>>>>>>>>>>>>>
>>>>>>>>>>> notify us and
>>>>>>>>>>>
>>>>>>>>>>>>>> remove it from your system.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On
>>>>>>>>>>>>>>
>>>>>>>>> Behalf Of
>>>>>>>>>>>>>> Grahame Grieve
>>>>>>>>>>>>>> Sent: 07 August 2006 22:18
>>>>>>>>>>>>>> To: Robert Worden
>>>>>>>>>>>>>> Cc: Lloyd McKenzie
>>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm way behind on email. but spotted this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no
>>>>>>>>>>>>>>
>>>>>>>>>>>>> correlation
>>>>>>>>>>>>>
>>>>>>>>>>>>>> between what we are trying to achieve and a real DAM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What we want is to do implementation modelling on
>>>>>>>>>>>>>>
>>>>>>>>> the RMIM. We
>>>>>>>>>
>>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey
>>>>>>>>>>>>>>
>>>>>>>>>>>>> last week -
>>>>>>>>>>>>>
>>>>>>>>>>>>>> that this has nothing to do with the DAM process,
>>>>>>>>>>>>>>
>>>>>>>>>>> except for the
>>>>>>>>>>>
>>>>>>>>>>>>>> naming question.
>>>>>>>>>>>>>> (Where by names in the instance should allow
>>>>>>>>>>>>>>
>>>>>>>>>>> identification back
>>>>>>>>>>>
>>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except
>>>>>>>>>>>>>>
>>>>>>>>>>>>> unless you are
>>>>>>>>>>>>>
>>>>>>>>>>>>>> concerned about naming stability, but that's a much
>>>>>>>>>>>>>>
>>>>>>>>>>>>> harder question
>>>>>>>>>>>>>
>>>>>>>>>>>>>> indeed)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> will come back to this thread later when I catch up
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Grahame
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert Worden wrote:
>>>>>>>>>>>>>> Hi Lloyd -
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was thinking that since people should really
>>>>>>>>>>>>>>
>>>>>>>>>>> produce a DAM on
>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> way
>>>>>>>>>>>>>> to their RMIM, rather than the
>>>>>>>>>>>>>> other way round, in some
>>>>>>>>>>>>>>
>>>>>>>>>>>>> sense the
>>>>>>>>>>>>>
>>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not
>>>>>>>>>>>>>>
>>>>>>>>>>> a formal
>>>>>>>>>>>
>>>>>>>>>>>>>> derivation,
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> may be that the
>>>>>>>>>>>>>> <derivationSupplier> route is not
>>>>>>>>>>>>>>
>>>>>>>>> appropriate.
>>>>>>>>>
>>>>>>>>>>>>>> What then is the approved mechanism for adding
>>>>>>>>>>>>>>
>>>>>>>>>>>>> annotations to a MIF?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>> sure I could find it in the
>>>>>>>>>>>>>> schemas, but it's easier to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ask you...
>>>>>>>>>>>>>
>>>>>>>>>>>>>> :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Close, London
>>>>>>>>>>>>>
>>>>>>>>>>>>>> EC1A 7JN
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394;
>>>>>>>>>>>>>>
>>>>>>>>>>>>> mobile: 44 7970
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 197968
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *************************** E-mail
>>>>> confidentiality notice
>>>>>>>>>>>>>> *******************************
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message is intended for the addressee only. It
>>>>>>>>>>>>>>
>>>>>>>>>>> is private,
>>>>>>>>>>>
>>>>>>>>>>>>>> confidential and may contain information of a
>>>>>>>>>>>>>>
>>>>>>>>>>>>> proprietary nature.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you have received this message in error, please
>>>>>>>>>>>>>>
>>>>>>>>>>>>> notify us and
>>>>>>>>>>>>>
>>>>>>>>>>>>>> remove it from your system.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent:
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 07 August
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2006 19:43
>>>>>>>>>>>>>> To: Robert Worden
>>>>>>>>>>>>>> Cc: grahame at kestral.com.au
>>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Relationships between a static model and a DAM would be
>>>>>>>>>>>>>>
>>>>>>>>>>>>> mappings,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a
>>>>>>>>>>>>>>
>>>>>>>>>>> spare. In the
>>>>>>>>>>>
>>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM
>>>>>>>>>>>>>>
>>>>>>>>>>>>> and HMD but
>>>>>>>>>>>>>
>>>>>>>>>>>>>> in theory we could derive from 20 different models.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (And there's
>>>>>>>>>>>>>
>>>>>>>>>>>>>> no ordering
>>>>>>>>>>>>>> either,
>>>>>>>>>>>>>> the RIM could be the first one
>>>>>>>>>>>>>> listed or the seventh.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The basic question is whether you construct your
>>>>>>>>>>>>>>
>>>>>>> DAM from a
>>>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether
>>>>>>>>>>>>>>
>>>>>>>>>>>>> you want
>>>>>>>>>>>>>
>>>>>>>>>>>>>> to create your DAMs and DIMs separately and map
>>>>>>>>>>>>>>
>>>>>>>>> them. If the
>>>>>>>>>
>>>>>>>>>>>>>> latter, I don't think
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> could do this in an automated way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lloyd
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert Worden wrote:
>>>>>>>>>>>>>> Grahame -
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You asked the other day for suggestions as to how
>>>>>>>>>>>>>>
>>>>>>>>>>> the current
>>>>>>>>>>>
>>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be
>>>>> steered by
>>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user
>>>>>>>>>>>>>>
>>>>>>>>>>>>> input. Here is a
>>>>>>>>>>>>>
>>>>>>>>>>>>>> first punt to get thinking going.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The simplest suggestion I can make is to add to the
>>>>>>>>>>>>>> <derivationSupplier> elements another one which says
>>>>>>>>>>>>>>
>>>>>>>>>>> how this
>>>>>>>>>>>
>>>>>>>>>>>>>> RMIM
>>>>>>>>>>>>>> was
>>>>>>>>>>>>>> derived (or might have been
>>>>>>>>>>>>>> derived) from a DAM. These
>>>>>>>>>>>>>>
>>>>>>>>>>>>> would look
>>>>>>>>>>>>>
>>>>>>>>>>>>>> like:
>>>>>>>>>>>>>> <derivationSupplier
>>>>>>>>>>>>>> staticModelDerivationId="4"
>>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare;
>>>>>>>>>>>>>>
>>>>>>>>>>>>> but choose
>>>>>>>>>>>>>
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>> that is). These can go on elements for classes,
>>>>>>>>>>>>>>
>>>>>>>>>>>>> associations, and
>>>>>>>>>>>>>
>>>>>>>>>>>>>> properties to say in effect
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Rename this class to a DAM class name
>>>>>>>>>>>>>> * Rename this association (with perhaps other
>>>>>>>>>>>>>>
>>>>>>>>>>>>> attributes saying
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 'collapse it' or 'leave it out')
>>>>>>>>>>>>>> * Rename this property to a DAM property name (or
>>>>>>>>>>>>>>
>>>>>>>>>>>>> some value
>>>>>>>>>>>>>
>>>>>>>>>>>>>> meaning 'leave it out')
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you wanted, you would not even have to say
>>>>> explicitly
>>>>>>>>>>>>>> 'collapse an
>>>>>>>>>>>>>> association' - because if the DAM class names are
>>>>>>>>>>>>>>
>>>>>>>>>>> the same on
>>>>>>>>>>>
>>>>>>>>>>>>>> either side of it, that means collapse it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This proposal would not yet address a combination of
>>>>>>>>>>>>>>
>>>>>>>>>>>>> restricting
>>>>>>>>>>>>>
>>>>>>>>>>>>>> and reshaping an RMIM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It would imply you cannot collapse across a CMET
>>>>>>>>>>>>>>
>>>>>>>>>>>>> boundary, which
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I gather from our discussion the other day you would
>>>>>>>>>>>>>>
>>>>>>>>>>>>> like to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or maybe you can, by telling the association to
>>>>>>>>>>>>>>
>>>>>>>>> the CMET to
>>>>>>>>>
>>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I
>>>>>>>>>>>>>>
>>>>>>>>>>> know there
>>>>>>>>>>>
>>>>>>>>>>>>>> are issues
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>> CMETs with a choice at the top -
>>>>>>>>>>>>>> any chance you
>>>>>>>>>>>>>>
>>>>>>>>> could send a
>>>>>>>>>
>>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above,
>>>>>>>>>>>>>>
>>>>>>>>>>>>> it should
>>>>>>>>>>>>>
>>>>>>>>>>>>>> be straightforward to implement in the tool.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Close, London
>>>>>>>>>>>>>
>>>>>>>>>>>>>> EC1A
>>>>>>>>>>>>>> 7JN
>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44
>>>>>>>>>>>>>> 1353 777394; mobile: 44
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 7970 197968
>>>>>>>>>>>>>
>>>>>>>>>>>>>> *************************** E-mail
>>>>> confidentiality notice
>>>>>>>>>>>>>> *******************************
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message is intended for the addressee only. It is
>>>>>>>>>>>>>>
>>>>>>>>>>>>> private,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> confidential and may contain information of a
>>>>>>>>>>>>>>
>>>>>>>>>>>>> proprietary nature.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you have received this
>>>>>>>>>>>>>> message
>>>>>>>>>>>>>> in error, please notify
>>>>>>>>>>>>>> us and remove it from your system.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>> _________________________________________________________________
>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message from Charteris plc has been checked
>>>>>>>>>>>>>>
>>>>>>>>> for viruses
>>>>>>>>>
>>>>>>>>>>>>>> http://www.charteris.com/
>>>>>>>>>>>>>>
>>>>>>> _________________________________________________________________
>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message to Charteris plc has been checked
>>>>>>>>>>>>>>
>>>>>>> for viruses
>>>>>>>>>>>>>> http://www.charteris.com/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>> _________________________________________________________________
>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message from Charteris plc has been checked
>>>>>>>>>>>>>>
>>>>>>>>> for viruses
>>>>>>>>>
>>>>>>>>>>>>>> http://www.charteris.com/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>> _________________________________________________________________
>>>>>> This message to Charteris plc has been checked for viruses
>>>>>> http://www.charteris.com/
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> This message from Charteris plc has been checked for viruses
>>>>>> http://www.charteris.com/
>>>>>> _______________________________________________
>>>>>> New-ITS mailing list
>>>>>> New-ITS at lists.hl7.org.uk
>>>>>> http://lists.hl7.org.uk/mailman/listinfo/new-its
>>>>>>
>>>>>> This e-mail is confidential and privileged. If you are not
>>>>> the intended recipient please accept our apologies; please do not
>>>>> disclose, copy or distribute information in this e-mail or take
>>>>> any action in reliance on its contents: to do so is strictly
>>>>> prohibited and may be unlawful. Please inform us that this message
>>>>> has gone astray before deleting it. Thank you for your co-operation.
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> New-ITS mailing list
>>>> New-ITS at lists.hl7.org.uk
>>>> http://lists.hl7.org.uk/mailman/listinfo/new-its
>>>>
>>
>>
>>
>
More information about the New-ITS
mailing list