Re: ISSUE-85 (optional): Behaviour of "Optional"/MIN 0 restrictions and retrieval of fillers of existential restrictions

From: OWL Working Group Issue Tracker <sysbot+tracker@w3.org>
Subject: ISSUE-85 (optional): Behaviour of "Optional"/MIN 0 restrictions and retrieval of fillers of existential restrictions
Date: Thu,  6 Dec 2007 01:44:24 +0000 (GMT)

[...]

> Issue: OWL semantics for "Optional" and queries for fillers for
> existential restrictions.

[...]

> USE CASE 1: Returning fillers for existential restrictions (also
> critical for Part-explosions)
> 
> It is true (at least normatively) that All cars have wheels, but it is
> not true that all wheels are parts of cars.  However, to get back an
> answer in the obvious ways to inv(has_part) car, we have to kluge in
> false axioms of the form "Wheel is_part_of SOME Car" so that "is_part_of
> SOME Car" subsumes Wheel.  Alternatively we have to enumerate and name
> all the parts "Wheel that is part of Car", etc.  Neither is
> satisfactory.
> 
> My current preference is to have a standard query which would return the
> corresponding defined class if there were an axiom either.
> 
> If the ontology contains:
> 	Car has_part SOME Wheel
> then I need a standard query 
> 	Query inv(has_part) SOME Car
> that returns
> 	Wheel THAT inv(has_part) SOME Car
> 
> This use case is essential to get the behaviour expected of "part
> explosions" without kluging the axioms or clogging the ontology by
> explicitly defining and naming all of the implied classes.
> 
> 	Query inv(has_part) SOME Car
> 		Wheel THAT inv(has_part) SOME Car
> 			 Tyre THAT inv(has_part) SOME (Wheel THAT
>                              inv(has_part) SOME Car)
> 				...
> 
> Clever tools could substitute named classes where they had been defined
> (e.g. if "Car Tyre" had been defined, it could be returned instead of
> the third expression above), but the query mechanism should generate the
> implied classes and then look for equivalent classes in the ontology.

Hmm.  This relationship is between a "desription fragment" and a
description.  There are several hard issue here, mostly revolving around
*which* descriptions you want to have returned.   As far as OWL
semantics (DL or Full) is concerned, there are an infinite number of
descriptions, and in most cases an infinite number of descriptions that
could be reasonably returned for this "query".  Another problem in DL is
that descriptions are not domain objects and thus not eligible to be
returned when querying.

All is decidedly not lost, however.  I expect that what you really want
is something like "those named classes that can have wheels as parts".
This could be answered in two ways:
1/ take each named class C and determined whether C ^ ... is satisfiable
2/ take each named class C and find out whether there is information
   in the structural specification that is similar to ...  and is
   associated with C or one of its named generalizations
Both these require iteration over named classes in an ontology.  The
second one is rather vague still, but could be firmed up.

It remains my contention that these sorts of "queries" are *not* part of
OWL.  Instead, UI and API tools for OWL synthesize answers to these
"queries" by examining data-model information (like that specified in
the structural specification) that they retain and possibly also
performing logical queries whose behaviour *is* specified in the OWL
specs. 

Note that the situation in OWL Full is a bit different (but I don't
think that the difference matters here).

> USE CASE 2: Optional Statements
> 
> Users need to be able to say that "Dogs may have owners" and "People may
> own dogs" in a standard way and get back the answer to possible queries
> to "Owned things" to include ("Owned Dogs") and "Owners of things" to be
> "People who own dogs".
> 
> One might either overloadr minCadinality(0) or create a new keyword
> minCardinality(Optional) or similar, in which case minCardinality 0
> would be redundant.
> 
> If the ontology contains whichever of the following syntaxes is agreed.
> 	Dog has_owner min 0 Person
> 	Dog has_owner optional Person
> I need the two there to be two effects.
>  Queries
> 	Query has_owner some Person 
> to return
> 	Dog THAT has_owner SOME Person	
> and	
> 	Query owns SOME Dog
> to return
> 	Person THAT inv(has_owner) SOME Dog

> Satisfiability of optional axioms
> It makes no sense to say that something is "optional" if it is
> impossible.
> 
> 	The restriction 
> 		Dog --> has_owner min 0 Person 
> should, therefore, be treated unsatisfiable or in some other way marked
> as an error if the corresponding existential restriction, "Dog THAT
> has_owner SOME Person" is unsatisfiable].


The problem here is that both of these "statements" are logically
vacuous, and thus not really a part of the meaning of OWL.  (Again OWL
Full is slightly different, but, again, not in a way that I think
matters).

However, there is nothing preventing tool developers from assigning an
annotation property to carry this meaning.  The annotations would be
semantically vacuous (as desired) but could be used to modify the
results obtained in the kind of hybrid queries used in Section 1.

> USE CASE 3: UML and related formalisms multiplicity [0..n], [0..*] and
> related.
> 
> These statements are key to many UML models.  In using OWL for model
> checking, or even just trying to produce a transformation of a UML model
> into OWL, translating [0..*] as minCardinaltiy( 0 ) without checking
> whether the corresponding existential restriction is unsatisfiable does
> not capture faithfully the intention and usage of the UML.

In what way?  If mincardinality(0 ...) is vacous, then it precisely
captures the meaning of the lower bound.

> The came considerations as for USE CASE 2. 
> 
> Note 1: MIN 0 / Optional expressions should not appear in
> equivalentClass statements (complete definitions)

Why not?  One *might* want to make a point that a particular class name
has some particular status with respect to these sort of extra-logical
queries.

> Note 2: MIN 0 / Optional restrictions are not "inherited" unless the
> corresponding existential restriction is satisfiable.  The combination
> of
> 	 C --> p Optional V
> 	 SubC --> NOT (p SOME V)
> should not make SubC unsatisfiable.  It is probably best to leave how
> such information should be displayed to the tools.

I agree that tools are the place where these issues should be decided.

> Regards
> 
> Alan [Rector]

Peter F. Patel-Schneider
Bell Labs Research

Received on Wednesday, 12 December 2007 14:29:26 UTC