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

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

http://www.w3.org/2007/OWL/tracker/issues/

Raised by: Alan Ruttenberg
On product: 

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

Here is an issue that is not currently issue list and a major barrier to acceptance and practical use of OWL. ( I'll give it here quickly in Manchester syntax because there isn't time before the face-to-face to put it in a standard XML/RDF syntax. )

In my experience this is the amongst the top two problems for those coming to OWL from a UMLand database environment and a reason for several groups rejecting OWL as an option.  For us, it has been and remains a constant issue in building practical systems, and solved differently every time.  We have implemented various work-arounds for clients in tools, but none is standard or satisfactory

This is also an important area in which OWL does not capture the semantics of UML properly, at least as UML used in practice and taught.

It is very important that there be a standard solution integrated with the semantics of OWL DL.  Otherwise, we have a standard that will be used in different ways. It is not sufficient to leave these as "tools issues".  If we want a standard, they need to be in the standard. 

These changes require no changes to reasoners, only to the interpretation of the language.  (They require only testing of existential expressions and the formalisation of a minimal query mechanism.)

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.
    

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

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. 

The came considerations as for USE CASE 2. 

Note 1: MIN 0 / Optional expressions should not appear in equivalentClass statements (complete definitions) 

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. 

 
Regards

Alan




-----------------------
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.clinical-esciences.org
www.co-ode.org

[Submitted by alanr for alanr]

Received on Thursday, 6 December 2007 01:44:35 UTC