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

Bijan - just a quick response with a half-baked thought, but I don't  
have time to bake it and don't want to lose it.

If I type the equation
  X = a - b x c
it would be ambiguous, except that math comes with a set of  
precedence rules, so the multiply comes before the subtract -- thmath  
has survived for a pretty long time using this idea and I haven't  
seen a lot of complaints about lack of interoperability between  
calculators

I am wondering if there is not something similar we could do (maybe  
as part of Alan's document on how DL processors should handle non-DL  
inputs).  If we got things mostly right, I suspect we could make it  
so DL reasoners would generate a "warning" but still produce an  
answer (and all produce the same answer) without making these  
declarations mandatory  (i.e. in math I can break the precendence by  
inserting an override like X = (a - b) x c )

so the typing vocabulary would enter the language for when it was  
needed, but most naturally occuring RDF graphs would not cause the  
problem, and there would be a standard way to solve things

I know it would take some work to work this out, but might be worth  
doing as it would meet a need that, strangely, you and I both agree  
on, which is, as you say, to handle more RDF graphs
  -JH



On Jan 9, 2008, at 7:31 PM, Bijan Parsia wrote:

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

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180