My comment is based on my experience in trying to uravel and then integrate
data using multivariate statistical tools when I was doing research to
improve envrironmental impact assessments....too many moons ago. My vote
would be to maintain separate definitions because it sounds like you might
be loosing valuable information if discrete and continuous are lumped into
one definition. The only way around this I can think of is if the nature of
the variable being measured unambiguously tells you whether it is discrete
or continuous in every case. In any case the reality test is would any of
this make any difference in practice to researchers, practioners etc.
Cheers,
Joseph
-------
Joseph Dal Molin
e-cology corporation
www.e-cology.ca
1.416.232.1206
----- Original Message -----
From: "Thomas Beale" <[EMAIL PROTECTED]>
To: "OSHCA List" <[EMAIL PROTECTED]>;
"gehr-architecture" <[EMAIL PROTECTED]>
Sent: Sunday, September 23, 2001 9:28 PM
Subject: openEHR/GEHR modelling question
>
> Another modelling question, as part of our development of the openEHR
> "convergence model" for EHRs:
>
> In GEHR there is a DATA_VALUE subtype called QUANTITY, which models
> physical quantities. See bottom for abstract semantics.
>
> HL7 has a type called QTY also, with similar semantics.
>
> The question is: do we really need two types, to model discrete and
> continuous quantities? For example, DISCRETE_QUANTITY and
> CONTINUOUS_QUANTITY. Currently, the type of value in QUANTITY is REAL,
> which theoretically accommodates INTEGER, i.e.
> the possible values of discrete measurements, but it hides the true
> nature of discrete v continuous thing being measured; in particular, we
> have to add semantics to the class to allow it to be specified as
> discrete or continuous.
>
> Are there circumstances where discrete quantities could become
> continuous, or is it better to have disjoint types? I am favouring
> disjoint types, since it both discrete and continuous quantitative data
> are extremely common in medicine, and it seems better to model that
> explicitly. In modellig terms, one type will have value:INTEGER, the
> other value:REAL.
>
> As an aside, consider another differentiator in quantities - dimensioned
> v dimensionless. Typically, discrete measurements are also dimensionless
> (in the strict sense of the term); is this always true? I don't believe
> we really want to have more subtyping on the basis of being dimensioned
> or not, however.
>
> Another thought: some discrete quantities may be recorded as REAL
> anyway, typically in E format, if the numbers are so large that the
> precision is larger than 1.
>
> Thoughts?
>
>
> --------------------------------------------------------------------------
---------------
> indexing
> component: "openEHR Reference Object Model"
> description: "[
> Models a quantity with value and optional units. Units
> are represented as a string,
> whose format is based the Unified Code for Units of
> Measure (UCUM) proposal,
> developed by Gunther Schadow and Clement J. McDonald of
> The Regenstrief Institute
> For Health Care, Indianapolis. Published at
> http://aurora.rg.iupui.edu/UCUM.
> ]"
> keywords: "quantity, data"
> requirements:"clin:data-qty-num"
>
> cen_ref: ""
> hl7_ref: "QTY (Quantity)"
>
> author: "Thomas Beale <[EMAIL PROTECTED]>"
> support: "GEHR support <[EMAIL PROTECTED]>"
> copyright: "Copyright (c) 2000 The openEHR Foundation, Australasia"
> licence: "The openEHR Open Source Licence"
>
> -- file: "%M%"
> -- version: "%I%"
> -- last_change: "%E% %U%"
>
> deferred class QUANTITY
>
> inherit
> DATA_VALUE
>
> COMPARABLE
> undefine
> is_equal
> end
>
> feature -- Content
>
> value: REAL is
> -- FIXME: need to accommodate discrete and continuous
> quantities;
> -- do we need two subtypes?
> deferred
> end
>
> precision: INTEGER is
> -- Precision to which the value of the quantity is
> -- expressed, in terms of number of significant figures.
> -- 0 implies no precision.
> deferred
> end
>
> property: STRING is
> -- property being measured, e.g. "pressure", "flow rate"
> deferred
> end
>
> units: STRING is
> -- stringified units, following the HL7 UCUM proposal.
> Examples:
> -- "kg/m^2", "mm[Hg]", "ms^-1", "km/h"
> deferred
> end
>
> feature -- Status
>
> is_dimensionless:BOOLEAN is
> -- True if no units or property
> deferred
> end
>
> feature -- Comparison
>
> infix "<" (other: like Current): BOOLEAN is
> do
> Result := other.value < value
> end
>
> end
>
> --
> ..............................................................
> Deep Thought Informatics Pty Ltd
> Information and Knowledge Systems Engineering
> phone: +61 7 5439 9405
> mailto:[EMAIL PROTECTED]
> Electronic Health Record - http://www.gehr.org/
> Knowledge Methodology - http://www.deepthought.com.au/it/archetypes.html
> Community Informatics -
http://www.deepthought.com.au/ci/rii/Output/mainTOC.html
> ..............................................................
>
>
>
