Modeling a specific construct - please help

[Milan Zdravkovic]

I am a beginner in OWL, working on specific process ontology. I have a problem in inferring the concurrency of process activities, for example - on basis of asserted A preeceds B and C preceeds B, I need to infer that: A isConcurrentWith C.

I was trying with modeling domain of isConcurrentWith with (Manchester syntax):

preceeds some (suceeds min 2 ProcessActivity)

, where preceeds properties are asserted and suceeds is inferred inverse property, but without success.

 

Could you please help me on this ?

 

[Uli Sattler]

this is a difficult one:

- I assume that Ab, B, and C are individuals, and that 'preceeds' is  
'directly preceeds' (otherwise, you should *not* conclude that A is  
ConcurrentWith C.

- you can introduce a transitive superproperty 'preceeds-trans' of  
preceeds and find all instances of the class (e.g., via OWL API and  
reasoner or via the DL query tab in Protege 4):

(preceeds-trans value C) or (Inv(preceeds-trans) value C)

if A is *not* in the answer to this query, then you can assume that it  
is ConcurrentWith C.

Cheers, Uli


On 11 Sep 2009, at 12:27, Milan Zdravkovic wrote:

> I am a beginner in OWL, working on specific process ontology. I have  
> a problem in inferring the concurrency of process activities, for  
> example - on basis of asserted A preeceds B and C preceeds B, I need  
> to infer that: A isConcurrentWith C.
> I was trying with modeling domain of isConcurrentWith with  
> (Manchester syntax):
> preceeds some (suceeds min 2 ProcessActivity)
> , where preceeds properties are asserted and suceeds is inferred  
> inverse property, but without success.
>
> Could you please help me on this ?
>
>
>

[Milan Zdravkovic]

Thanks Uli !

2009/9/11 Uli Sattler <sattler@...>

this is a difficult one:

- I assume that Ab, B, and C are individuals, and that 'preceeds' is 'directly preceeds' (otherwise, you should *not* conclude that A is ConcurrentWith C.

 

Yes, "preceeds" is not transitive property

 

- you can introduce a transitive superproperty 'preceeds-trans' of preceeds and find all instances of the class (e.g., via OWL API and reasoner or via the DL query tab in Protege 4):

(preceeds-trans value C) or (Inv(preceeds-trans) value C)

if A is *not* in the answer to this query, then you can assume that it is ConcurrentWith C.

 

Thanks for the effort, but I would like to keep the ontology meaningfull, that is to avoid using "supporting" concepts for inference. Do you possibly know why "preceeds some (succeeds min 2 ProcessActivity)" is not working ? I am confused about this - existential restriction works ("preceeds some (succeeds some ProcessActivity)") but cardinality - obviously not ?!

 

Cheers, Uli

On 11 Sep 2009, at 12:27, Milan Zdravkovic wrote:

I am a beginner in OWL, working on specific process ontology. I have a problem in inferring the concurrency of process activities, for example - on basis of asserted A preeceds B and C preceeds B, I need to infer that: A isConcurrentWith C.
I was trying with modeling domain of isConcurrentWith with (Manchester syntax):
preceeds some (suceeds min 2 ProcessActivity)
, where preceeds properties are asserted and suceeds is inferred inverse property, but without success.

Could you please help me on this ?

--
Milan Zdravkovic,
IT Business Development Consultant
Inovation Center for Information Technologies (ICIT), Faculty of Mechanical Engineering, University of Nis

Phone: [phone]
Email: milan.zdravkovic@...
WWW: http://icit.masfak.ni.ac.yu/milan.zdravkovic
LinkedIn: http://www.linkedin.com/in/milanzdravkovic
Address: ul. Kovanlucka 58, 18000 Nis, Serbia
---------------------------------------------------------
http://www.euraxess.rs
National EURAXESS portal: Facilitating researchers mobility to and from Republic of Serbia

[Uli Sattler]

On 11 Sep 2009, at 15:21, Milan Zdravkovic wrote:

> Thanks Uli !
>
> 2009/9/11 Uli Sattler <sattler@...>
> this is a difficult one:
>
> - I assume that Ab, B, and C are individuals, and that 'preceeds' is  
> 'directly preceeds' (otherwise, you should *not* conclude that A is  
> ConcurrentWith C.
>
>
> Yes, "preceeds" is not transitive property
>
> - you can introduce a transitive superproperty 'preceeds-trans' of  
> preceeds and find all instances of the class (e.g., via OWL API and  
> reasoner or via the DL query tab in Protege 4):
>
> (preceeds-trans value C) or (Inv(preceeds-trans) value C)
>
> if A is *not* in the answer to this query, then you can assume that  
> it is ConcurrentWith C.
>
>
> Thanks for the effort, but I would like to keep the ontology  
> meaningfull, that is to avoid using "supporting" concepts for  
> inference.

I understand - but from  " A preceeds B and C preceeds B,", it does  
not follow that "A isConcurrentWith C" -- unless you mean indeed that  
'preceeds' is 'directly-preceeds'....and then you do need some  
transitive superproperty to talk about precedence in general?!


> Do you possibly know why "preceeds some (succeeds min 2  
> ProcessActivity)" is not working ?

what do you mean by 'not working'? You need to give us more context  
and more detail on what it is that isn't working.

Cheers, Uli

> I am confused about this - existential restriction works ("preceeds  
> some (succeeds some ProcessActivity)") but cardinality - obviously  
> not ?!
>
> Cheers, Uli
>
>
>
> On 11 Sep 2009, at 12:27, Milan Zdravkovic wrote:
>
> I am a beginner in OWL, working on specific process ontology. I have  
> a problem in inferring the concurrency of process activities, for  
> example - on basis of asserted A preeceds B and C preceeds B, I need  
> to infer that: A isConcurrentWith C.
> I was trying with modeling domain of isConcurrentWith with  
> (Manchester syntax):
> preceeds some (suceeds min 2 ProcessActivity)
> , where preceeds properties are asserted and suceeds is inferred  
> inverse property, but without success.
>
> Could you please help me on this ?
>
>
>
>
>
>
>
> --
> Milan Zdravkovic,
> IT Business Development Consultant
> Inovation Center for Information Technologies (ICIT), Faculty of  
> Mechanical Engineering, University of Nis
>
> Phone: [phone]
> Email: milan.zdravkovic@...
> WWW: http://icit.masfak.ni.ac.yu/milan.zdravkovic
> LinkedIn: http://www.linkedin.com/in/milanzdravkovic
> Address: ul. Kovanlucka 58, 18000 Nis, Serbia
> ---------------------------------------------------------
> http://www.euraxess.rs
> National EURAXESS portal: Facilitating researchers mobility to and  
> from Republic of Serbia

[Pat Hayes]

On Sep 11, 2009, at 5:55 AM, Uli Sattler wrote:

> this is a difficult one:
>
> - I assume that Ab, B, and C are individuals, and that 'preceeds' is  
> 'directly preceeds' (otherwise, you should *not* conclude that A is  
> ConcurrentWith C.
>
> - you can introduce a transitive superproperty 'preceeds-trans' of  
> preceeds and find all instances of the class (e.g., via OWL API and  
> reasoner or via the DL query tab in Protege 4):
>
> (preceeds-trans value C) or (Inv(preceeds-trans) value C)
>
> if A is *not* in the answer to this query, then you can assume that  
> it is ConcurrentWith C.

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

>
> Cheers, Uli
>
>
> On 11 Sep 2009, at 12:27, Milan Zdravkovic wrote:
>
>> I am a beginner in OWL, working on specific process ontology. I  
>> have a problem in inferring the concurrency of process activities,  
>> for example - on basis of asserted A preeceds B and C preceeds B, I  
>> need to infer that: A isConcurrentWith C.
>> I was trying with modeling domain of isConcurrentWith with  
>> (Manchester syntax):
>> preceeds some (suceeds min 2 ProcessActivity)
>> , where preceeds properties are asserted and suceeds is inferred  
>> inverse property, but without success.
>>
>> Could you please help me on this ?
>>
>>
>>
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Milan Zdravkovic]

OK, here is demo example at: http://www.masfak.ni.ac.rs/ontologies/2009/8/process_demo.owl

What's bothering me is, without going deeper into semantics of used terms:

1. Why RDQL "suceeds min 2 Activity" do not return Activity_3, and "suceeds some Activity" does ?
2. Why Activity_1 isConcurrentWith Activity_2 (and Activity_1 isConcurrentWith Activity_1, in this case) is not inferred ?
3. Is there another way to axiomatize this relationship (although semantics of used terms is not actually precise, you are right, Uli, but I hope you get what I want to achieve) ?

Thanks for your help,
Milan

2009/9/11 Uli Sattler <sattler@...>

On 11 Sep 2009, at 15:21, Milan Zdravkovic wrote:

Thanks Uli !

2009/9/11 Uli Sattler <sattler@...>
this is a difficult one:

- I assume that Ab, B, and C are individuals, and that 'preceeds' is 'directly preceeds' (otherwise, you should *not* conclude that A is ConcurrentWith C.


Yes, "preceeds" is not transitive property

- you can introduce a transitive superproperty 'preceeds-trans' of preceeds and find all instances of the class (e.g., via OWL API and reasoner or via the DL query tab in Protege 4):

(preceeds-trans value C) or (Inv(preceeds-trans) value C)

if A is *not* in the answer to this query, then you can assume that it is ConcurrentWith C.


Thanks for the effort, but I would like to keep the ontology meaningfull, that is to avoid using "supporting" concepts for inference.

I understand - but from  " A preceeds B and C preceeds B,", it does not follow that "A isConcurrentWith C" -- unless you mean indeed that 'preceeds' is 'directly-preceeds'....and then you do need some transitive superproperty to talk about precedence in general?!

Do you possibly know why "preceeds some (succeeds min 2 ProcessActivity)" is not working ?

what do you mean by 'not working'? You need to give us more context and more detail on what it is that isn't working.

Cheers, Uli

I am confused about this - existential restriction works ("preceeds some (succeeds some ProcessActivity)") but cardinality - obviously not ?!

Cheers, Uli



On 11 Sep 2009, at 12:27, Milan Zdravkovic wrote:

I am a beginner in OWL, working on specific process ontology. I have a problem in inferring the concurrency of process activities, for example - on basis of asserted A preeceds B and C preceeds B, I need to infer that: A isConcurrentWith C.
I was trying with modeling domain of isConcurrentWith with (Manchester syntax):
preceeds some (suceeds min 2 ProcessActivity)
, where preceeds properties are asserted and suceeds is inferred inverse property, but without success.

Could you please help me on this ?







--
Milan Zdravkovic,
IT Business Development Consultant
Inovation Center for Information Technologies (ICIT), Faculty of Mechanical Engineering, University of Nis

Phone: [phone]
Email: milan.zdravkovic@...
WWW: http://icit.masfak.ni.ac.yu/milan.zdravkovic
LinkedIn: http://www.linkedin.com/in/milanzdravkovic
Address: ul. Kovanlucka 58, 18000 Nis, Serbia
---------------------------------------------------------
http://www.euraxess.rs
National EURAXESS portal: Facilitating researchers mobility to and from Republic of Serbia

[Uli Sattler]

On 14 Sep 2009, at 14:28, Milan Zdravkovic wrote:

OK, here is demo example at: http://www.masfak.ni.ac.rs/ontologies/2009/8/process_demo.owl

thanks, that helps

What's bothering me is, without going deeper into semantics of used terms:

1. Why RDQL "suceeds min 2 Activity" do not return Activity_3, and "suceeds some Activity" does ?

because we don't know that Activity_3 (I think you mean Activity_C?) has at least 2 succeeds successor: it may be the case that Activity_A and Activity_B are identical...try adding a Different Individual to Activity_A, Activity_B, and then try again. 

2. Why Activity_1 isConcurrentWith Activity_2 (and Activity_1 isConcurrentWith Activity_1, in this case) is not inferred ?

because you haven't said anything in your ontology that  would entail this. You have stated domain and range restrictions on your 3 properties, and said that preceeds is the inverse of succeeds, but not more. 

I guess you you meant to say that 

the property *chain* (succeeds o preceeds) implies  isConcurrentWith

but you haven't stated this in the ontology,  and it also isn't quite the right thing to say, is it: 

- it would only 'catch' 'sibling' relationships (in contrast to cousins, etc.), and

- it implies, e.g., that   Activity_B isConcurrentWith  Activity_B, and you don't want that. 

3. Is there another way to axiomatize this relationship (although semantics of used terms is not actually precise, you are right, Uli, but I hope you get what I want to achieve) ?

have a look at 

http://www.cs.manchester.ac.uk/~stevensr/menupages/fhkb.php

it should help clarify things

Cheers, Uli

Thanks for your help,
Milan

2009/9/11 Uli Sattler <sattler@...>

On 11 Sep 2009, at 15:21, Milan Zdravkovic wrote:

Thanks Uli !

2009/9/11 Uli Sattler <sattler@...>
this is a difficult one:

- I assume that Ab, B, and C are individuals, and that 'preceeds' is 'directly preceeds' (otherwise, you should *not* conclude that A is ConcurrentWith C.


Yes, "preceeds" is not transitive property

- you can introduce a transitive superproperty 'preceeds-trans' of preceeds and find all instances of the class (e.g., via OWL API and reasoner or via the DL query tab in Protege 4):

(preceeds-trans value C) or (Inv(preceeds-trans) value C)

if A is *not* in the answer to this query, then you can assume that it is ConcurrentWith C.


Thanks for the effort, but I would like to keep the ontology meaningfull, that is to avoid using "supporting" concepts for inference.

I understand - but from  " A preceeds B and C preceeds B,", it does not follow that "A isConcurrentWith C" -- unless you mean indeed that 'preceeds' is 'directly-preceeds'....and then you do need some transitive superproperty to talk about precedence in general?!

Do you possibly know why "preceeds some (succeeds min 2 ProcessActivity)" is not working ?

what do you mean by 'not working'? You need to give us more context and more detail on what it is that isn't working.

Cheers, Uli

I am confused about this - existential restriction works ("preceeds some (succeeds some ProcessActivity)") but cardinality - obviously not ?!

Cheers, Uli



On 11 Sep 2009, at 12:27, Milan Zdravkovic wrote:

I am a beginner in OWL, working on specific process ontology. I have a problem in inferring the concurrency of process activities, for example - on basis of asserted A preeceds B and C preceeds B, I need to infer that: A isConcurrentWith C.
I was trying with modeling domain of isConcurrentWith with (Manchester syntax):
preceeds some (suceeds min 2 ProcessActivity)
, where preceeds properties are asserted and suceeds is inferred inverse property, but without success.

Could you please help me on this ?







--
Milan Zdravkovic,
IT Business Development Consultant
Inovation Center for Information Technologies (ICIT), Faculty of Mechanical Engineering, University of Nis

Phone: [phone]
Email: milan.zdravkovic@...
WWW: http://icit.masfak.ni.ac.yu/milan.zdravkovic
LinkedIn: http://www.linkedin.com/in/milanzdravkovic
Address: ul. Kovanlucka 58, 18000 Nis, Serbia
---------------------------------------------------------
http://www.euraxess.rs
National EURAXESS portal: Facilitating researchers mobility to and from Republic of Serbia

[Alan Rector]

On 13 Sep 2009, at 21:56, Pat Hayes wrote:

On Sep 11, 2009, at 5:55 AM, Uli Sattler wrote:

this is a difficult one:

- I assume that Ab, B, and C are individuals, and that 'preceeds' is 'directly preceeds' (otherwise, you should *not* conclude that A is ConcurrentWith C.

- you can introduce a transitive superproperty 'preceeds-trans' of preceeds and find all instances of the class (e.g., via OWL API and reasoner or via the DL query tab in Protege 4):

(preceeds-trans value C) or (Inv(preceeds-trans) value C)

if A is *not* in the answer to this query, then you can assume that it is ConcurrentWith C.

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

Well really, what I would conclude, in any case, is that "A _may_ be concurrent with B" -

i.e. the OWL model does not rule it out. 

It seems dangerous to conclude that "A is concurrent with B".  And it only holds within whatever scope 

the OWL model (I deliberately do not say "ontology") holds. 

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.

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

Cheers, Uli

On 11 Sep 2009, at 12:27, Milan Zdravkovic wrote:

I am a beginner in OWL, working on specific process ontology. I have a problem in inferring the concurrency of process activities, for example - on basis of asserted A preeceds B and C preceeds B, I need to infer that: A isConcurrentWith C.

I was trying with modeling domain of isConcurrentWith with (Manchester syntax):

preceeds some (suceeds min 2 ProcessActivity)

, where preceeds properties are asserted and suceeds is inferred inverse property, but without success.

Could you please help me on this ?

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

-----------------------

Alan Rector

Professor of Medical Informatics

School of Computer Science

University of Manchester

Manchester M13 9PL, UK

TEL [phone]/6188

FAX [phone]

www.cs.man.ac.uk/mig

www.co-ode.org

http://clahrc-gm.nihr.ac.uk/

[Chimezie Ogbuji]

On Tue, Sep 15, 2009 at 4:24 AM, Alan Rector <rector@...> 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

[Pat Hayes]

On Sep 16, 2009, at 9:50 AM, Chimezie Ogbuji wrote:

> On Tue, Sep 15, 2009 at 4:24 AM, Alan Rector <rector@...>  
> 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)

Well, let me rephrase my point somewhat differently. If you use this  
inference pattern, and come to rely on it, and then in some case you  
find it delivers false conclusions, do not complain to anyone about  
RDF or OWL, or complain to the proprietors of the RDF or OWL reasoner  
you are using. Do not say that your reasoner is broken. Go instead to  
whoever gave you the data you were using and upon whose completeness  
you were relying, to serve the writs, or voice the complaints, or  
whatever.

Pat

>
>> 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
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Alan Rector]

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@...>  
> 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 [phone]/6188
FAX [phone]
www.cs.man.ac.uk/mig
www.co-ode.org
http://clahrc-gm.nihr.ac.uk/