Re: OWL1.1 APis

On 14 Dec 2006, at 15:48, Dave Reynolds wrote:

>
> Bijan Parsia wrote:
>
>>> Up till now the semantic web stack has nested nicely. If I apply  
>>> an RDFS reasoner to an OWL document (whether DL or full) all the  
>>> deductions are sound.
>> Ok, now I'm getting into the second bit :) I don't think this is  
>> true, and not a sensible wish anyway. It certainly isn't the case  
>> for Simple Interpretations vs. RDFS Interpretations (i.e., some  
>> graphs are consistent on simple interpretations and inconsistent  
>> on RDFS ones...through in D-entailment and you get more such; by  
>> the time you hit OWL Lite, well, you see where it's going :))
>
> Good point, I was implicitly assuming graphs that were consistent  
> at each level.

Remember that consistency and entailment are closely related, e.g., P  
is entailed by O if O & ~P is inconsistent.

> [Merging two messages for ease of reply ...]
>
> > [snip]
> >> Ok, now I'm getting into the second bit :) I don't think this is  
> true,
> >> and not a sensible wish anyway. I
> > [snip]
> >
> > When I wrote that, I didn't intend to sound snarky, but  
> rereading, I see
> > that it sounds that way.
>
> Perhaps a touch, but perhaps justified :-)
>
> > I just meant that I thought we all wanted there to be more  
> entailments
> > with an OWL Full reasoner, so I'm confused as to the requirement  
> that,
> > well, there not be any. OWL Full has "more" semantics, so an OWL  
> Full
> > reasoners *should* find more entailments.
>
> Sure it should find more entailments on an OWL/DL document but  
> those entailments are [fuzzy imprecise language warning-] not  
> inconsistent with OWL/DL entailments.

Yeah, I don't know what that means :)

> It seemed to me that punning is different and (unless the RDF  
> translation has different URIs for each pun) this introduces a  
> divergence in the modelling. However, it is clear to both of us  
> that I haven't articulated that divergence, and its implications  
> for how OWL/full tools should treat OWLDL/1.1 documents, in a clear  
> and precise way.

My belief is that the entailments of OWL Full will be a superset of  
the entailments of OWL DL/1.1 with punning. You won't *lose*  
entailments, I'm pretty sure. So I don't think there is any  
difference in the sort of nestings we get.

> Let me turn this round the other way. In your OWLED paper [1] you  
> said:
>
> "However, punning is not compatible with the meta-modelling  
> possibilites inherent in the semantics of RDF [6] (and thus  
> inherent in OWL Full), precisely because it makes the two uses of a  
> name semantically independent."

This is unfortunately strong. Punning is not the *same* as OWL Full   
metamodeling, precisely because we prevent axioms about puns from  
"leaking" between, e.g., the class and the individual versions. So

	Class A sameAs Class B

Does not mean that
	a rdf:type A.
is also
	a rdf: type B.

which you might expect. However, you can "add" that later via a  
semantic extensions (see <http://www.cs.man.ac.uk/~bmotik/ 
publications/papers/motik05metamodeling.pdf>; contextual semantics is  
just punning; hilog semantics is closer to OWL Full, though OWL Full  
adds more, e.g., reflection on the syntax).

> What do you think the implication of that incompatibility is for  
> existing OWL/full tools?

Not a lot, frankly. OWL Full reasoners, complete ones, will always do  
*more* than punning. So it's incompatible *in that sense*. So too,  
OWL Full reasoners *reason about annotations*, so if you wanted, as  
was requested, *semantics free* comments/annotations, then OWL Full  
is incompatible *with that specific requirement*. But this is an  
"incompatibility" that won't matter to OWL Full users, I don't think,  
unless they want those annotations to not affect the semantics of the  
document. But then, er, why did they use an OWL Full reasoner :)

There are details, but at least the intent was to define a level of  
OWL Full behavior that was useful and amenable to implementation on  
existing tools, esp. reasoners. That's what punning is (at least, in  
intent). As has been pointed out, replicating *exactly* the semantics  
of OWL Full (in every detail) can lead to problems. Even just the  
syntactic reflection can cause ALC to go undecidable (see Boris's  
paper; and I'm not sure about many of the tractable fragments), and  
FOL to go paradoxical (not just you can express them, but *every*  
ontology contains them! (see Peter's paper: <http://www- 
db.research.bell-labs.com/user/pfps/publications/fol.pdf>)

Now, there are a number of ways to do a large chunk of OWL Fullness  
without *too* many issues. Hilog is well understood. There are  
issues, however. In Boris's paper, he shows how SHOIN with Hilog  
semantics is undecidable without the Unique Role Assumption. (This is  
because you lose the ability to determine what's a simple role, and  
thus could have hidden non-simple roles in number restrictions.) But  
Hilog for FOL is well defined, well understood, and semantically  
fine. The proof theory is straightforward enough, but I don't know if  
there are any "practical" HilogFOL reasoners out there. Hilog +  
syntax reflection...not so much.

> [I'm going to be out of email contact for the rest of the year :-)  
> so substantially delayed response does not necessarily indicate  
> lack of interest.]

I hope this helps clarify what's going on. I don't *think* we're  
breaking anything. We tried to be upfront where there are gaps, but,  
contrary to some people's insinuations, we're not *out* to pillage  
and destroy :) But I think we should be honest and precise and err on  
the side of caution.

It's my belief that some restrictions are necessary on OWL Full if we  
are to continue to add expressivity. I don't think these are huge or  
unreasonable. Not being able to write "rdf:type rdf:type rdf:type"  
will  not keep me up at night. Even, "rdf:type rdf:type rdf:Property"  
seems harmless to give up. YMMV, but I would like these use cases to  
be well and clearly justified.

Cheers,
Bijan.

Received on Thursday, 14 December 2006 18:13:23 UTC