RE: RE: Evidence

Hi Aldo, Welcome to HCLSIG!

 

Dear Vipul, I can understand you here: unusual names are not a good service for
the case for reusable ontologies. In order to overcome this problem, we have
produced a totally renamed, lightly axiomatized version of the DOLCE library,
called DOLCE-Ultralite: http://www.loa-cnr.it/ontologies/DUL.owl. Another
approach we are following is creating a lattice of small ontologies, called
"content ontology design patterns".

 

[VK] What I am actually trying to get at in this discussion is the lack of
methodological guidelines and examples that can "guide" someone to learn by
"doing"

Besides as you point out above, notions of continuants and occurrents are not
exactly intuitive and understandable easily.

 

A computational process can be an occurrent, if conceptualized as something
occurring in a computing machine. If you conceptualize it as a process type, to
be implemented in a programming language, you are probably thinking to something
else, which I would represent as an EventStructure, or a Workflow. 

See also the Core Ontology of Software by Daniel Oberle
(http://cos.ontoware.org), designed by reusing an older version of the
DOLCE-Lite-Plus library.

[VK] This is exactly where methodological guidelines are needed.... Why is the
process occurring in a computing machine categorized as an occurrent, while a
process type (sounds like a functional specification)

be categorized as continuant? This is not immediately obvious ...

Some guidelines on how to make this choice and whether making this choice leads
to something useful is what I would like to develop.

It is my sense that these usage guidelines though inspired by examples from
computer science are likely to be applicable in biology and clinical areas as
well!

 

Of course, there are other types of confusions:  what happens when a process is
in a "sleep state" and then "wakes up" ... Is it a continuant or an occurrent?

We have started a wiki for this discussion at
http://esw.w3.org/topic/HCLS/OntologyTaskForce/BFOProcessDefinitionDiscussion
Feel free to contribute

 

I have to disagree with you here. The distinction BFO (and also DOLCE) makes
between continuants and occurents, and especially the distinction between
processes and objects, is relatively easy to understand, you just need to look
at the documentation and the examples for each a bit more. I also think that the
distinction between processes and objects is quite practical. 

[VK] I think the distinction between objects and processes is easily understood.
It's the distinction between continuants and occurrents and the categorization
of processes under one and not the other which

is confusing... And going back to Pat's point, if a process may be both, then
this distinction loses it's value at least in the context of the process.

 

I also think that you put too much emphasis on the definitions of terms like
'process' in computer science. I have the impression that many people with a
strong background in computer science easily mix up such terms from computer
science with the general meaning of these terms. Sometimes it appears that it
would be better if they would temporarily forget their education in computer
science while creating ontologies, because it does more harm than good.

 

[VK] I think this is a flawed position. Who is to say that definitions in
biology are better/worse than definitions in computer science? So one suggestion
is of course that you could forget your education

in biology while creating ontologies as it does more harm than good, because
biologists are very bad at understanding and using abstractions :-)

 

Seriously, I think it is of tremendous value to take use cases from computer
science to challenge existing conceptualizations in biological world. If the
conceptualizations hold, then they are validated,

If they don't then either a flaw is identified or a new distinction is
identified, which for all you know may be of value in the biological context!
This is Epistemology 101!

 

Agreed. And this is true of any domain: lawyers will tend to force the meaning
of "Norm" on the legal side, physicists will tend to engage everyone with
physical forces, etc. Howeve, very reusable ontologies should be careful in
looking for readability and extended documentation, examples, etc.

[VK] The point I was trying to make is that using conceptualizations from
law/physics/computer science to challenge conceptualizations in biology (and
vice versa) is a useful exercise and will help

create a robust set of constructs and also help develop guidelines on when to
use something or not..

 

'Process' in the context of software systems has a very special meaning that
does not have much to do with what people in general are thinking of as a
process. The 'processes' in BFO are much closer to the intuitive understanding
of most people. In other words, it is more likely that the diction of software
developers fails the acceptance test of understandability, and *not* BFO!

[VK] What I see above is dogma and has not been established scientifically or
logically. For instance I can make a counter claim that the notion of "process"
in software engineering is closer to intuitive understanding.

This is sort of a "I am better than you" kind of a position which will lead us
nowhere.

 

Probably so, if the domain is everyday life; but still, we need to be clear and
assist domain experts to find their own way and utility in using reference
ontologies.

[VK] Yes! At least looking at computer science use cases will at least tell
biologists what not to do! :-)

 

By the way, this discussion was triggered by my statement that things like
'binding assay result' are not subclasses of something called 'evidence', but
instead 'evidence' is more of a role they play in certain contexts. My emphasis
actually was that we should NOT make a bogus subclass statement. I don't think
we have to deal with 'evidence roles' at the moment, so we can just omit them.
Of course, the discussion we are having right now is still valuable, but I did
not intend to trigger this discussion when I made that statement.

[VK] Ah! The joys of serendipity!

 

> [VK] I guess then the acceptance test would be: Are the entailments that

> are

> inferred as a result of having these distinctions useful? Hope that makes

> it

> clearer ... :)

 

This is a very good acceptance test, best known as "competency fitness". I
support the idea that only competency-fit parts of a reference ontology should
be bought, and this is idea we are pursuing with the patterns project.

[VK] Actually, it may not be a bad idea to come up with a list of acceptability
tests targeted to the HCLS domain.


> > > Acceptance Test 3: Ability to align with other "standards"

> > not necessarily interesting. Depends on what you think of the other

> > standards.

> 

> [VK] What I meant here is that there are existing standards within

> Healthcare,

> e.g., HL7 - RIM, Snomed, LOINC, etc. So alignment would be good.

> Also, mis-alignment would be good if it exposes gaps and weaknesses in

> these

> existing standards, in that they do not support some use cases.

> 

 

Standards are not so different from ontologies, at least from the assessment
viewpoint: they need to pass the same competency tests :)

[VK] Yes, To the extent they are aligned they both pass the (in)competency test.
To the extent they are mis-aligned, they

expose each other's strengths and weaknesses.

 

Assessment and evidence-based medicine need a quite sophisticated modelling,
because you need to decouple the observations from the way you frame them into a
context, and you can have different contexts, rationales for the assessments,
etc. And you may want to reason over all those entities together, not just on
observations. Having just roles, objects, and events is not enough, you also
need some expressivity for contexts of observations (e.g. a notion of
"Situation"), as well as for contexts of interpreting those observations. 

[VK] it is interesting you come up with the above Aldo, this is exactly what I
am doing. Actually, in the healthcare context, observations are the basic
foundation on which every thing is built. Assessments,

Clinical Documentation, Clinical Decision Support logic all depend on
observations! The challenge is to methodically identify relationships between
observations and each of the other things...

You may be interested in another task we are looking at: the ability to cross
map clinical observations in the context of clinical practice to clinical
observations in clinical trials:

http://esw.w3.org/topic/HCLS/OntologyTaskForce/BIONTDSEDCM 

 

A design pattern that I'm using since several years for cases like these (e.g.
in clinical trials) is D&S, and is embedded e.g. in DOLCE-Ultralite (see above).
Logically speaking, it is a more complex variety of the N-ary relations pattern
published by SWBPD working group, but has an explicit axiomatization, and
features the two-layers required to decouple observations from interpretations.

 

[VK] Yup! This is the realization we are heading towards... to effectively
decouple observations from assessments/interpretations, and also to effectively
deal with complex observations, e.g., cardiac murmur, blood

pressure we need polyadic relations... Of course we make do with reifying these
polyadic relations into classes, but am not sure whether we lose some
expressiveness as a result.

 

Cheers,

 

---Vipul






The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.