For Adrian :
[fr] doesn't mean "someone is cross about something" about a "religious
dispute".
but : "message from France ; even if I know that european history has long
been "someone is cross about something in a religious dispute" ; but this is
[ot] ;-)
Now ontologies :
As I already said, genuine table representation uses lots of implicit
meaning, while ontologies are a way to express things with explicit meanings
(kind of "controled langage").
I said that it was possible to export table representation into "ontological
langage" :
field : weight
value : 70
becomes (Odyssee tree representation)
"patient's weight"
+ 70 "kg"
Usually, you cannot reverse it (thats to say import a tree in a table),
since tree has no deterministic structure, and with the simple field = value
approach, it is a nightmare to express :
"patient's weight"
+ "normal"
or
"patient's weight"
+ "before"
| + "regimen"
| + 70 "kg"
+ "after"
+ "regimen"
+ 65 "kg"
or
"patient's weight"
+ 2810 "g"
Andrew seems to manage "normal"
> 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.
but you have to do it by hand, for each value. You need a local
administrator.
And if someone says "Patient's weight" : "average" ?
My point of view is that if you want to enter knowledge management scope,
you will sooner or later use ontologies.
Why ?
Because Odyssee and GEHR fixed the langage (ontologie + tree for Odyssee) ,
and still have lots of work having users express valid documents (GEHR's
archetype, Odyssee's Fils guides) then building automatic interpretation.
If you build the langage "by speaking", I am afraid :
1) You need a whole staff of full time cogniticians
2) Elsewhere you have a very, very long way before you have a genuine
knowledge management system, and not a "locally coherent system of forms".
Important ?
Yes, because if it is possible to computerize the knowledge of a company
with a local system, medicine demands global knowledge systems. And to be
perfectly honnest, this is the prime reason why Odyssee became open source.
Regards,
PS : I am starting 3 open source projects into Odysse :
1) A "real time" epidemyology web server using various classifications
(mail -> SQL -> stat module -> web pages)
2) A piping tool (win32) to capture datas in patient record softwares (using
Windows spying) in order to feed the web server
3) The porting of Odysse on Linux OS
Genuine web pages soon ; you commentaries are welcome.
Philippe AMELINE
Odyssee project
www.nautilus-info.com
----- Original Message -----
From: "Andrew Ho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, May 13, 2001 12:31 PM
Subject: RE: programming (was: Disenfranchised doctors)
> 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/lat
e_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/fle
xible_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
