Property chain conflicts with cardinality constraints

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Property chain conflicts with cardinality constraints

Lu, Cheng
Hi, I have the following problem when testing the property chain feature.

Classes: A, B, C
Object Properties: hasB, hasC
hasB - Domain: A   Range: B
hasC - Domain: A, B   Range: C

Property chain: hasB o hasC ->hasC

Individual: a, b, c1, c2 (a: A, b: B c1, c2: C)
Statement:
    a. hasC(c1)
    a. hasB(b)
b. hasC(c2)

At this point, as expected, there is an inferred statement by property composition in
the knowledgebase:
a. hasC(c2)

The problem occurs when any cardinality constraint is defined on A’s hasC property (e.g.
A. hasC max 3 C; A. hasC exact 2 C; etc.); the inferred statement a.hasC(c2) disappears
form knowledgebase and Pellet query results.

We are using protégé 4.0 alpha to create the ontology and tested this bug in both
integrated Pellet 1.5 in protégé and external Pellet 1.51.


Regards
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: Property chain conflicts with cardinality constraints

Gibson, A.P.
Hi Cheng,

I think that the combination of a cardinality restriction on a property with a role chain makes the inference you expect undecideable. As such I dont think this is a bug, its just one of those things you cant say in OWL.

I'm sure a logician will be able to explain this more cleary (and tell you if I am right!), but I'm pretty sure the overall effect is similar to the undecideablility that comes from putting cardinality constraints on transitive properties. Unlike inconsistencies, undecideable combinations of axioms are not obvious through the interface until you get differences in reasoning output like the one you have here.

You can see the same behaviour yourself if you create a transitive property that links a -> b -> c1 & c2. Without the cardinality constraint you get a --> c1&c2, but when you add one in, like with your initial observation, the inferences disappear.

I seem to remember that I accidentally did this once, and it was picked up through the OWL species checker of Pellet, which was telling us that it was OWL-Full because of the combination of axioms. I dont know if the species checker is supported for OWL2 but it would be worth finding out.

Thanks for building the test model, and I hope this helps.

Dr Andrew Gibson
Universiteit van Amsterdam

-----Original Message-----
From: [hidden email] on behalf of Lu, Cheng
Sent: Tue 7/29/2008 8:02 AM
To: [hidden email]
Subject: [p4-feedback] Property chain conflicts with cardinality constraints
 
Hi, I have the following problem when testing the property chain feature.

Classes: A, B, C
Object Properties: hasB, hasC
hasB - Domain: A   Range: B
hasC - Domain: A, B   Range: C

Property chain: hasB o hasC ->hasC

Individual: a, b, c1, c2 (a: A, b: B c1, c2: C)
Statement:
    a. hasC(c1)
    a. hasB(b)
b. hasC(c2)

At this point, as expected, there is an inferred statement by property composition in
the knowledgebase:
a. hasC(c2)

The problem occurs when any cardinality constraint is defined on A's hasC property (e.g.
A. hasC max 3 C; A. hasC exact 2 C; etc.); the inferred statement a.hasC(c2) disappears
form knowledgebase and Pellet query results.

We are using protégé 4.0 alpha to create the ontology and tested this bug in both
integrated Pellet 1.5 in protégé and external Pellet 1.51.


Regards
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback

winmail.dat (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Property chain conflicts with cardinality constraints

Bijan Parsia-3
On Jul 29, 2008, at 10:01 AM, Gibson, A.P. wrote:

> Hi Cheng,
>
> I think that the combination of a cardinality restriction on a  
> property with a role chain makes the inference you expect  
> undecideable. As such I dont think this is a bug, its just one of  
> those things you cant say in OWL.

Yep. You can only use simple roles in cardinality restriction.

> I'm sure a logician will be able to explain this more cleary (and  
> tell you if I am right!), but I'm pretty sure the overall effect is  
> similar to the undecideablility that comes from putting cardinality  
> constraints on transitive properties.

It's (basically the same) the same.

> Unlike inconsistencies, undecideable combinations of axioms are not  
> obvious through the interface until you get differences in  
> reasoning output like the one you have here.

This will improve. Basically, the current P4 doen't have (and doesn't  
invoke pellet's) species detection. FaCT++ will pretty reliably throw  
and exception.

Matthew tells me he has a validator for the "non structural  
restrictions" in the works in the OWL API. This should show up as a  
service on owl.cs.manchester.ac.uk and in P4 in due course.

[snip]
> The problem occurs when any cardinality constraint is defined on  
> A's hasC property (e.g.
> A. hasC max 3 C; A. hasC exact 2 C; etc.); the inferred statement  
> a.hasC(c2) disappears
> form knowledgebase and Pellet query results.

Pellet has a mode wherein it "repairs" an ontology by ignoring  
certain problematic axioms. Unfortunately, this is on by default in  
P4 at the moment which I think is a bit counterintuitive.

Cheers,
Bijan.
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: Property chain conflicts with cardinality constraints

Nick Drummond
Yes, I've now turned off the option (which is on by default in pellet).
Its rather unintuitively called IGNORE_UNSUPPORTED_AXIOMS.

Nick

On Tue, Jul 29, 2008 at 10:52 AM, Bijan Parsia <[hidden email]> wrote:
On Jul 29, 2008, at 10:01 AM, Gibson, A.P. wrote:

> Hi Cheng,
>
> I think that the combination of a cardinality restriction on a
> property with a role chain makes the inference you expect
> undecideable. As such I dont think this is a bug, its just one of
> those things you cant say in OWL.

Yep. You can only use simple roles in cardinality restriction.

> I'm sure a logician will be able to explain this more cleary (and
> tell you if I am right!), but I'm pretty sure the overall effect is
> similar to the undecideablility that comes from putting cardinality
> constraints on transitive properties.

It's (basically the same) the same.

> Unlike inconsistencies, undecideable combinations of axioms are not
> obvious through the interface until you get differences in
> reasoning output like the one you have here.

This will improve. Basically, the current P4 doen't have (and doesn't
invoke pellet's) species detection. FaCT++ will pretty reliably throw
and exception.

Matthew tells me he has a validator for the "non structural
restrictions" in the works in the OWL API. This should show up as a
service on owl.cs.manchester.ac.uk and in P4 in due course.

[snip]
> The problem occurs when any cardinality constraint is defined on
> A's hasC property (e.g.
> A. hasC max 3 C; A. hasC exact 2 C; etc.); the inferred statement
> a.hasC(c2) disappears
> form knowledgebase and Pellet query results.

Pellet has a mode wherein it "repairs" an ontology by ignoring
certain problematic axioms. Unfortunately, this is on by default in
P4 at the moment which I think is a bit counterintuitive.

Cheers,
Bijan.
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback