Hi peter, Thanks for this reply. On Thu, 2008-05-08 at 16:04 +1000, Peter Gummer wrote:
> Although ARCHETYPE - ARCHETYPE_ONTOLOGY isn't exactly a case of the > Composite design pattern, nonetheless this quote from the GoF Design > Patterns book (p.166) seems applicable: > > "Maintaining references from child components to their parent can simplify > the traversal and management of a composite structure. The parent reference > simplifies moving up the structure ... With parent references, it's > essential to maintain the invariant that all children of a composite have as > their parent the composite that in turn has them as children." > > I totally agree that it is applicable. References, being the key word. Hence my suggestion that the type ARCHETYPE_ONTOLOGY.parent_archetype should be ARCHETYPE_ID instead of ARCHETYPE. > > First of all; an ontology instance cannot (should not) exist outside of > > an archetype instance. Therefore it is obvious which archetype it > > belongs with. > > I don't understand how it would be obvious, Tim. You would have to search > through all of the archetypes somehow in order to find the one to which the > ontology belongs. Ahhhh, but I think that this has more to do with your implementation decisions than with the object model. ???? How could your ontology instance lose it's reference to its parent archetype instance while in memory? My guess is that it doesn't. I'll venture that it happens based on how you choose to persist your objects. Correct? This isn't to suggest that implementation issues shouldn't feedback to the specifications. Heck that is one thing that makes this group and the openEHR specifications different. If you can't implement it, it doesn't work. > > Okay, I have to object to the differential approach. > > > > First I like the axiom, "just because we can does not mean we should". > > It was more a case of, "We can't, but we have to!" > > Figuring out how to do it was not easy. Months of work. It wasn't done on a > whim. > I truly did not intend to suggest that it was. Hence my reference to the amount of experience that Ocean Informatics has in this area. > The value is that currently specialisations easily get out of step with the > specialisation parent. Someone might correctly create a specialised > archetype, but it's all too easy for someone to modify the parent and not > update the specialisations to match. This is not a hypothetical problem: it > has been happening. > > Another reason for differential archetypes is to make it easier for multiple > people to work concurrently on the same lineage of specialised archetypes. > > The current flat-form archetype source is basically a crude copy-and-paste > approach. It's not maintainable. Very valid and unsurprising points. Can we agree that this is a development mode issue and that it doesn't apply to released ADL? Since as I described before, released ADL files (should) follow a very rigorous version control process. IF so then I believe that the development issues are really one of management and tools. Since it is completely logical that a specialization of an archetype will reside in the same folder of the development tree (as is the case with the ones I've seen). The tools could scan the directory for specializations of the current archetype. Warn the developer that specializations exist. Prior to committing any changes ask the developer to approve an email to the author(s) of the specialization(s) with the revision_history enclosed. If we were to add a datetime stamp attribute to the specialization section along with the parent archetype id then if the first email was lost, the tools could check the parent and see if it had been modified since the last time the specialization was edited. Thoughts? I appreciate the dialog. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: Displayemail.gif Type: image/gif Size: 4274 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080508/eeebc6c9/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080508/eeebc6c9/attachment.asc>
