OWL 1.1 Issue: Behaviour of "Optional"/MIN 0 restrictions and retrieval of fillers of existential restrictions

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


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