Hi Philippe,
Thanks for a very informative response that succinctly covers many
critical issues. I hope you don't mind me responding in public since this
is a highly relevant topic for the openhealth list and it is my fault that
the "reply-to" field in my original message was incorrectly set.
For those who are interested in semantics, automated decision support
and portable medical records, Philippe's response to my proposal is a
must-read.
Reply below.
On Sun, 13 May 2001 11:04:49 philippe Ameline wrote:
>> >1) Data management : tables are enough,
>> ...
>> >2) Knowledge management : obviously you have to use ontologies to
>"describe"
>> >the datas you are using in a way others can benefit of it.
>> ...
>> Hi Philippe and Trevor,
>> How about a comprimise solution?
>> Consider this: "tables" linked together by ontologies.
>> This is kind of what Odyssee offers, I think. In essence, the Odyssee
>stores its "tables" as trees. Please tell me if I am wrong.
>
>I think your are wrong, the key point is in the way you understand the
term
>"semantic" (thats to say "meaning").
>
>1) Implicit "meaning" (tables)
>When storing your datas in a table, you typically use the "field : value"
>approach.
>Lets take an example "weight : 70"
>The word "weight" belongs to table definition, and is out of datas scope
(in
>another dimension). It represents patient's weight only because your
program
>is built to assume thats it is patient's weight (and its unit is "kg")
>
>2) Explicit "meaning" (ontologies)
>An ontologie can be described as "terms of a langage, with semantic".
>For exemple terms "patient's weight", "kg", "patient", "weight"...
>Linked by :
>"patient's weight" -belongs to->"patient"
>"patient's weight" -unit->"kg"
>"patient's weight" -kind of->"weight"
>And you can express "weight : 70" with the tiny tree :
>
>"patient's weight"
> +-- 70 "kg"
Philippe, I understand you so far. My proposal is not to do away with
ontologies - but to 1) define them post-hoc or what I call "late-binding"
[see
http://www.txoutcome.org/scripts/zope/readings/OIO_talk/data_interchange/late_binding]
and 2) limit their scope to an intermediate collection of terms which I
call "flexible semantic scope"
(="form"-level scoping) [see
http://www.txoutcome.org/scripts/zope/readings/OIO_talk/data_interchange/flexible_scope].
I will try to explain in more detail below.
>Of course, you can store that tree in a database, but when you work on
it,
>you have to get it as a genuine tree.
Agreed. How the ontologies are stored is irrelevant.
>Of course, you could express datas in a table as a tree : you just have
to
>transform "implicit" meaning into "explicit" meaning, but (it is easy to
>understand), it is a LOCAL transformation, for EXPORT only.
>Local : because you have to express "implicit" meaning hidden in YOUR
table
>Export only : because of tables limitations
This part I don't understand.
Using your example, do you mean something like this:
"patient"
+-- "patient's height"
+-- 150 "cm"
+-- "patient's weight"
+-- 70 "kg"
So, this tree is specific to this instance of "patient" - and does not
necessarily apply to another instance of a "patient" tree. (For example,
"patient"-"address"). Is that what you mean by "Local"?
I don't have any guess about the "Export only" statement. Could you please
explain?
>If your field is a numerical one, how could you import ? :
>"patient's weight"
> +-- "normal"
I classify this as a "data merging" problem and the OIO system handles
this "import" as follows:
1) rename - weight:x "kg" + weight:{normal,abnormal} -> weight:x "kg",
weight_in_range:{normal,abnormal}
2) recode - weight:x "kg" + weight:{normal,abnormal} -> weight:x "kg"
where weight=70 if weight=normal.
>And even if you can manage it, what will you do with ? :
>"patient's weight"
> +-- "before"
> | +-- 70 "kg"
> +-- "after"
> +-- 65 "kg"
Same as above. You can either rename (create new field) or recode (decide
how values from one field should be transformed into another field).
This is not rocket science and is actually what takes place everyday
(mostly manually) by data managers. The idea is to provide tools that make
these "semantic" inter-conversion tasks easier and allow re-use of the
"rules" as well as the metadata "forms" themselves. We may be able to
build some intelligence into the system down-the-road but that is entirely
a different task.
>> This is also basically what the OIO system offers, where the metadata
>that describe the "tables" are called "forms". The ontologies are
maintained
>in the relationships between forms - which are currently defined
post-hoc,
>during data aggregation/reporting.
>
>How can you manage coherency between 2 OIO systems, if you "elaborate the
>langage while talking" ?
Exactly. Coherency between 2 OIO systems will be "elaborated while
talking" :-). Isn't this also how two people come to understand each
other? "Translators" that embody the "rules" for merging data across forms
are define as needed and shared between installations and data
merging sessions.
>Of course "US langage" is "World langage", but don't forget computers are
>stupid enough not to understand it ;-)
Right. Computers cannot be expected to come up with the "translation"
rules without human input. However, computers may be able to retrieve
previous used "translators" to permit re-use of certain "translation"
rules.
I hope this helps you understand my proposal and I look forward to your
further suggestions,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
TxOutcome.Org (hosting OIO Library #1)
Assistant Clinical Professor
Department of Psychiatry, Harbor-UCLA Medical Center
University of California, Los Angeles
