W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2009

Re: Modeling a specific construct - please help

From: Alan Rector <rector@cs.man.ac.uk>
Date: Tue, 29 Sep 2009 10:45:51 +0100
Cc: Pat Hayes <phayes@ihmc.us>, Uli Sattler <sattler@cs.man.ac.uk>, Milan Zdravkovic <milan.zdravkovic@gmail.com>, public-owl-dev@w3.org
Message-Id: <D85683F5-3BB8-4A96-86B5-2BD2EE5FE6AF@cs.man.ac.uk>
To: Chimezie Ogbuji <chimezie@gmail.com>
Chimezie, All

The question of how best to handle reasoning with clinical data  
remains an open one,
as far as I know.  In general, we make do with approximations designed  
to fit specific
circumstances.

We still do not have a good theoretical description of the relation  
between the "data" in the record, the
clinicians' beliefs at any given time (which may conflict both over  
time and between clinicians),
some sort of consensus "best model" of the patient, (and ultimately  
"reality").
We still do not have a good account of how to handle "not known",  
"known not", "unsure", "missing",
"invalid", etc.  We still don't have a good handle on when we should  
regard the clinical
data as "open" and when as "closed".  I don't think we have a good  
practical account of how to
mix different sorts of data even in the knowledge based once we get  
beyond the
"ontological" reasoning about terminologies etc, which are clearly   
"open world" and things like
the FDA licensing database which is clearly "closed world".

The one thing I am confident of is that there is unlikely to be a  
simple, single layer, first order theory
to deal with all these issues.

The one practical bit of advice on this, is that it is often possible  
to close small, localisable problem spaces.
It is much harder to close large problem spaces.

Regards

Alan


On 16 Sep 2009, at 15:50, Chimezie Ogbuji wrote:

> On Tue, Sep 15, 2009 at 4:24 AM, Alan Rector <rector@cs.man.ac.uk>  
> wrote:
>> Well, no, you cannot (validly) conclude this. This is a non-monotonic
>> inference, which is not supported by the OWL semantics. While it  
>> may work in
>> particular cases where you know that your data is complete in the  
>> required
>> sense, it is not good practice to use such inference patterns in  
>> OWL, as
>> they will (not may, but WILL) break in some cases. Think building a  
>> glass
>> building over a known seismic fault.
>>
>> Pat Hayes
>
>> The difficulty with such reasoning patterns is that they only work  
>> when you
>> can
>> complete the knowledge base so that it is fully constrained.
>> In most of our biomedical models, we can rarely be certain enough
>> that all possibilities have been covered to reason that the only
>> possibilities left over are true, only that they might be and may
>> ]be worth further investigation.
>
> True, but I've found (in practice) that non-monotonic reasoning
> matches well with the intuition behind clinical medicine and the way
> electronic patient data can be recorded as RDF (mostly using strict
> data entry controls where it is important to assume at least a portion
> of the data is complete in order to make reasonable inferences from
> it)
>
>> Although we have sometimes used this kind of reasoning on very  
>> restricted
>> data entry problems with multiple constraints where we can be sure  
>> that they
>> can all be covered.  In those cases the non-monotonicity is an  
>> advantage,
>> although I would try to confine it to increasingly large queries  
>> rather than
>> the KB itself. As we learn more, we add it to the query, so that  
>> query gets
>> larger and the number of
>> possible answers to the remaining questions gets fewer.
>> This sort of reasoning used to be supported in the Protege Query  
>> tab, but is
>> no longer.
>> Regards
>> Alan
>
> -- Chimezie
>

-----------------------
Alan Rector
Professor of Medical Informatics
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
www.cs.man.ac.uk/mig
www.co-ode.org
http://clahrc-gm.nihr.ac.uk/
Received on Tuesday, 29 September 2009 09:46:29 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:57 GMT