Why bring in religion? I want to understand and ask questions. And in the meantime I have an opinion based on my 'GBV'. (see below)
> Can you please give reasons for your statements that archetype nodes must be > unique concepts and must be uniquely identified? > Reasons for my statement? - Each node in an archetype has a meaning - Without an implicit or explicit meaning the archetype node indicates chaos, meaninglessness, nothingness. - Meaning is attached to the given name of the node or code attached to that node - In the case of specialisations of archetypes several things can happen, one of those is renaming the node, changing the meaning - This changing the name and meaning of the archetype node needs to be reflected in a new unique code So far I have not explained the scope, the jurisdiction, the namespace, of the unique codes I'm alluding to. At the minimum it must be uniquely defined inside the archetype, and in the case of a code from an external coding system, it must be unique in that namespace. > I have never been given a scientific reason why every node in an archetype > should be uniquely coded or have unique meaning outside the archetype itself. > I have never found a use case that makes this necessary but would be > interested if anyone can show me one. > It all depends on scope of the archetype. Is it used in an 'open world' or 'closed world' situation? When used in a 'closed system' ( two or more actors that have an agreement of that what is exchanged, IHE with one profile) there is almost no need for external codes attached to archetypes. The explicit or implicit agreement is sufficient. Whatever the name in the archetype node, when the agreement says, the node name means 'Black', but we take to mean 'White' then there is no single problem. In 'Closed world systems' the highest level of semantic interoperability is Level2a/2b at the best. It is the world of messaging with ad-hoc agreements, as we know it. When the archetype is used in an 'open world' system, then we need to be very precise and explicit. Any party that interprets the data using the archetype as source, where it must find the meaning, needs to be informed fully. No single human intervention, human interpretation, must be needed to process fully and safely the data exchanged. Local agreements between actors how to interpret the archetype node name do not exist, the archetype itself is the full agreement. In 'Open world' systems the highest level of semantic interoperability is level 3. In this 'open world' situation there are other rules than in the 'closed world' situation. Finally. Do not create a dichotomic world where things are either science or religion. There are many shades. And in order to surprise you: Do not underestimate something that I call in Dutch: 'het gezonde boeren verstand'. (GBV) Translated: the common sense of the farmer. Many obvious things that happen in life, happen because they happen. I do not have to prove, that water flows, that fire burns, that winds exits, for you and me to accept this is true, with or without a science, with or without any belief system, with or without any dogma. I try to base my own opinions on my 'GBV'. Gerard Freriks +31 620347088 gfrer at luna.nl On 29 aug. 2013, at 00:13, Hugh Leslie <hugh.leslie at oceaninformatics.com> wrote: > Hi Gerard, > > This is science, not religion. Can you please give reasons for your > statements that archetype nodes must be unique concepts and must be uniquely > identified? > > In openEHR and 13606, the archetype is the unique concept which means that > nodes quite rightly can have unique meaning in the context of the archetype. > This is like human language where the same word can have different meanings > depending on the context used. > > I have never been given a scientific reason why every node in an archetype > should be uniquely coded or have unique meaning outside the archetype itself. > I have never found a use case that makes this necessary but would be > interested if anyone can show me one. > > Regards Hugh > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/f83f1222/attachment.html>
