Punning, typed vocabulary, and handling RDF graphs (and ISSUE-65)

I'm following up from the discussion on tonight's telecon.

There's a chain of reasoning that closed for me tonight. I mentioned  
it in the telecon but I'll though it be helpful to document it.

ONE MOTIVATION FOR PUNNING

We had punning in Pellet before OWL 1.1. The motivation for punning  
there was to handle more RDF graphs that we were pretty sure we could  
handle. Before that, we handled some graphs with untyped entities  
which we were pretty sure were only *used* in one one. Here is a  
concrete example:

G1
	:C rdf:type owl:Class.
	:D rdf:subClassOf [a Restriction;
		onProperty :p;
		someValuesFrom :C]

This is not in OWL DL because :D and :p don't have a type triple. But  
it's pretty obvious what the fix should be:
F1
	:D rdf:type owl:Class.
	:p rdf:type owl:ObjectProperty.

This is the only way to make this OWL DL. But now consider:

G2
	:C rdf:type owl:Class.
	:p rdf:type owl:DatatypeProperty.
	:q rdf:type owl:ObjectProperty.
	:D rdf:subClassOf [a Restriction;
		onProperty :p;
		someValuesFrom :C]
	:E rdf:subClassOf [a Restriction;
		onProperty :q;
		someValuesFrom :C]

This is not in OWL DL and cannot be repaired to be. The reason is  
that in the axiom about :E, :C needs to be a datatype. It's not. But  
if we add the corresponding type triple, the vocabulary is no longer  
separated (i.e., :C is both a class and a datatype). Punning allows  
us to accept this graph by treating :C as a class in the first axiom  
and a datatype in the second.

(If you are concerned about "uri's denote only one thing", you can  
think of :C being one class that has two disjoint subclasses, one  
which is restricted to elements of owl:Thing and one to data values.  
As long as owl:Thing and literals are disjoint there's no trouble.)

Note that there's another choice! We could pun on :q (treat it *in  
that expressions* as an object property).

PROBLEMS

Well, the fact that we have a choice on what to pun is a problem.  
This happens in other examples., e.g., if we get rid of the first  
type triple of G1:

G1'
	:D rdf:subClassOf [a Restriction;
		onProperty :p;
		someValuesFrom :C]

Then we have two possible fixes. F1 and

F2
	:D rdf:type owl:Class.
	:p rdf:type owl:DatatypeProperty.
	:C rdf:type rdfs:Datatype.

Which should we pick? (They are mutally exclusive.) With punning, we  
can have *both*:

G1''
	:D rdf:subClassOf [a Restriction;
		onProperty :p;
		someValuesFrom :C]
	:D rdf:type owl:Class.
	:p rdf:type owl:DatatypeProperty.
	:p rdf:type owl:ObjectProperty.
	:C rdf:type rdfs:Datatype.
	:C rdf:type owl:Class.

The question is, then, what is :D a subclassof? and what do we do  
with it?

One hope is that the user *meant* for it only to be G1' + f2 *or* G1  
+ F1. We can guess which it is. (Up to now, we've had a known set of  
datatypes so thing are pretty easy). The typed vocabulary let's use  
*express* which one we meant:

D rdf:subClassOf [a owl11:ObjectRestriction;
		onProperty :p;
		SomeValuesFrom :C]
	:D rdf:type owl:Class.
	:p rdf:type owl:DatatypeProperty.
	:p rdf:type owl:ObjectProperty.
	:C rdf:type rdfs:Datatype.
	:C rdf:type owl:Class.

Thus we disambiguate. The mapping only requires the  
owl11:ObjectRestriction if there's the multiple type triples (and  
thus we've signaled ambiguity).

It's a pretty minimal disambiguation. We just change the type of the  
restriction. Presumably we forbid having both an object and a data  
restriction on the same bnode. It could also have an optional  
owl:Restriction.

Note that the RDF mapping is *already doing some fix up of old owl  
graphs. We could extend this to the cases where there are *no* type  
triples for :p.

Note that problems can arise with punning on classes or on properties.

WHAT'S GOING ON?

There are two cases of not-correctly-DL typed owl graphs (three if we  
count extending the builtin vocab....):
	1) We are *missing* type triples.
	There are three possibilities here:
		a) there is a single fix (do it!)
		b) there are multiple alternative fixes (what to do?!)
		c) there is no fix (without at least punning or triple deletion)
NOTE: Notice that this issue is *orthogonal* to whether we have  
punning or hilog semantics. The only important thing is whether we  
allow a non-separated vocabulary. OWL DL doesn't, so *can't* repair  
some graphs without deleting triples.
	
	2) We have too many type triples
	These are always not-OWL DL and can't be repaired without deletions  
(case c) above). Punning solves them being in OWL 1.1 (yay) but then  
leaves ambiguity problems with how to interpret restrictions (for  
example).

	I think it's clear that we don't want EVERY restriction to be  
"doubled" I.e., we interpret *EVERY* restriction as being an implicit  
disjunction of the restriction in its objectproperty form and in its  
dataproperty form. That brutally sucks. This is not far from what OWL  
Full requires, and if your ontology makes owl:Thing and rdfs:Literal  
disjoint, I suspect it's equivalent.
	But I feel very very confident in saying that no user expects this.  
No one expects this. I'll be shocked if anyone has *thought* of this  
before I have right now. Not because I'm particularly smart, but  
because it's...well...not something that occurs to anyone. Because  
it's freaky and useless.
	We then need a way of telling *which* restriction we meant (in cases  
when we have "active" punning between data and object properties or  
between classes and datatypes).

	This is why we have owl:11ObjectRestriction and  
owl11:DataRestriction. Note that this a *syntax* flaw because we  
cannot make the value of an onProperty (or somevaluesfrom) "locally"  
typed. Well, we could with reification:

	onProperty [a DatatypeProperty; rdf:value :p]

Uhm...did I just invent an alternative serialization that doesn't  
require vocabulary extension?!? Damn. I think I just did.

But it's after midnight so maybe I'm wrong :)

You'll still have ambiguous  (e.g., onProperty [:p]) and  
overdetermined (e.g., onProperty[a ObjectProperty; a  
DatatypeProperty; :p]) graphs, but they will be *MUCH* harder to  
write, esp by hand.

Those graphs already exist. It might make owl full semantics for  
onProperty change a bit. Who knows.

May I observe that this is *waaaaay* too much work for what is,  
essentially, a syntax issue. OWL made it much more, but that seems to  
be a really broken "feature" of OWL. I think when we are thinking  
about backwards compatibility, we should think hard about future  
extensibility and specification. If we can break things a little to  
make working *on* the language more robust, that would be a good thing.

Cheers,
Bijan.

Received on Thursday, 10 January 2008 00:29:19 UTC