Msg#4 - Software Archetypes - single vs double systems

systems

What I find most frustrating about discussion of archetypes is that it
is so often vague and intuitive in nature, making it rather hard to
decipher.

> Software Archetypes - single vs double systemsHi Lorie,
>
> Archetypes provide a capability that's very familiar to programmers,
> but take it to the next level. At the most basic level, it's about
> decoupling. An RDBMS shields programs from the need to know about
> the underlying structure of the data. A program needs only know
> about the db schema. Views provide another level of abstraction,
> shielding programs from changes in the schema. Archetypes (which I
> believe do not depend on an RDBMS implementation) provide a similar
> capability, but take it to the domain level.

By domain do you mean application domain? Or are you referring to
domains in their technical sense in database theory (as a set of
values)? At any rate, it is clear that you are trying to abstract away
from a particular set of units, treating the quantity itself as a value
(not how it might be represented).

>
> When working with an archetype-enabled system, programs / programmers
> work directly with domain concepts like blood pressure or height or
> weight. The underlying data is stored / accessed through the
> archetype.

But what does this mean? It suggests that an archetype is realizable as
a computational object (much as a schema may be realized as a set of
relations, or a class instantiated to form an object). I suspect that
this is the point at which an important concept is missing: The
integers are a ring, but when I add two numbers, I'm not using the +
operation of the category Ring, but rather of a specific member of that
category, namely Z.

> A trivial example of the benefits would be lbs. vs. kgs..
> In an archetype-enabled system, the program has no knowledge of the
> unit-of-weight measure used to store the data. Programs access the
> data store with statements like (no representation made re: syntax)
> store_weight(220, lbs) and patient_weight =
> retrieve_weight(patient_id, kgs).

Okay, here is some concrete syntax, but what are you really doing? Is
kgs a flag or map (or something else altogether)? From a mathematical
point of view, it's natural to think of it as a scaling transformation
(a map). But that's confusing, too, because it implies the existence
of some reference instance out there (say kilograms) that is somehow
privileged among other possible choices, and that your kgs flag is
simply the scaling factor (isomorphism) you need to apply to get your
chosen representation.
>
> You might want to take a look at
> http://oceaninformatics.biz/archetypes/MindMap/ArchetypeMap.html for
> a better, high-level understanding of the above. This, and a good
> deal of the related stuff, will be migrated shortly to the openEHR
> site.
>
> Be happy to provide / get you more in-depth info if desired.
>
> hth,
>

===
Gregory Woodhouse <gregory.woodhouse@sbcglobal.net>

"It is foolish to answer a question that
you do not understand."
--G. Polya ("How to Solve It")

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting

language

that extends applications into web and mobile media. Attend the live

webcast

and join the prime developer group breaking into this new coding

territory!

Some answers that may or may not be useful for the hardhats.

Bill Walton wrote:

From: "Greg Woodhouse" <gregory.woodhouse@sbcglobal.net>
To: <hardhats-members@lists.sourceforge.net>
Sent: 2006-04-10 10:46 AM
Subject: Re: [Hardhats-members] Software Archetypes - single vs double
systems

What I find most frustrating about discussion of archetypes is that it
is so often vague and intuitive in nature, making it rather hard to
decipher.

Software Archetypes - single vs double systemsHi Lorie,

Archetypes provide a capability that's very familiar to programmers,
but take it to the next level. At the most basic level, it's about
decoupling. An RDBMS shields programs from the need to know about
the underlying structure of the data. A program needs only know
about the db schema. Views provide another level of abstraction,
shielding programs from changes in the schema. Archetypes (which I
believe do not depend on an RDBMS implementation) provide a similar
capability, but take it to the domain level.
      

By domain do you mean application domain? Or are you referring to
domains in their technical sense in database theory (as a set of
values)?

application domain. It means you can consider an archetype as a model of some domain concept, like "microbiology test result", that a health care professional can understand (and define).

At any rate, it is clear that you are trying to abstract away
from a particular set of units, treating the quantity itself as a value
(not how it might be represented).

When working with an archetype-enabled system, programs / programmers
work directly with domain concepts like blood pressure or height or
weight. The underlying data is stored / accessed through the
archetype.
      

But what does this mean? It suggests that an archetype is realizable as
a computational object (much as a schema may be realized as a set of
    

it is. The model of all archetypes is given at http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/aom.pdf
or if you want online UML, see http://www.openehr.org/uml/Browsable/_9_0_76d0249_1108467924943_474004_589Report.html

relations, or a class instantiated to form an object). I suspect that
this is the point at which an important concept is missing: The
integers are a ring, but when I add two numbers, I'm not using the +
operation of the category Ring, but rather of a specific member of that
category, namely Z.

A trivial example of the benefits would be lbs. vs. kgs..
In an archetype-enabled system, the program has no knowledge of the
unit-of-weight measure used to store the data. Programs access the
data store with statements like (no representation made re: syntax)
store_weight(220, lbs) and patient_weight =
retrieve_weight(patient_id, kgs).
      

Okay, here is some concrete syntax, but what are you really doing? Is
kgs a flag or map (or something else altogether)? From a mathematical
point of view, it's natural to think of it as a scaling transformation
(a map). But that's confusing, too, because it implies the existence
of some reference instance out there (say kilograms) that is somehow
privileged among other possible choices, and that your kgs flag is
simply the scaling factor (isomorphism) you need to apply to get your
chosen representation.
    

it is not that complicated. The archetype simply constrains a QUANTITY object which is defined by a QUANTITY class. The openEHR model of this class is here: http://www.openehr.org/uml/Browsable/_9_0_76d0249_1109599337877_94556_1510Report.html

There is a custom C_QUANTITY constrainer class that can be used as well, which is particularly suitable for constraining values in multiple unit systems.
See this test archetype: http://my.openehr.org/wsvn/knowledge/archetypes/dev/adl/test/clinical_types/adl-test-entry.c_quantity.draft.html?op=file&rev=0&sc=0
That's raw ADL of course; in the clinician's archetype editor it is done via a GUI.

- thomas beale