W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2006

Re: Not out of the water yet...OWL DL properties

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Mon, 14 Aug 2006 13:54:03 +0100
Message-Id: <921E88B6-C881-4752-BB08-5B67665A422D@isr.umd.edu>
Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, Daniel Gresh <dgresh@lle.rochester.edu>, public-owl-dev@w3.org
To: Jim Hendler <hendler@cs.umd.edu>

On Aug 11, 2006, at 7:18 PM, Jim Hendler wrote:
> I've never hidden the fact, and have said in public on many  
> occasions, that I felt it was a mistake to have multiple OWL profiles,

I agree with that (er...both that you've never hidden the fact, and  
that it was a mistake :)).

> and that the restrictions on DL were such that they add significant  
> complexity for OWL use with little gain.

I disagree with that. Some of the restrictions are easily lifted,  
e.g., by punning. Some are not (putting a cardinality restriction on  
rdfs:subClassOf, though perhaps that's always inconsistent). The  
advantage of having a DLable profile was access to the wealth of  
knowledge and experience on how to implement and optimize reasoners.  
(Now, I have to grant that Jim has a different perspective on the  
significance of reasoning, and the sort of reasoning that was  
standard in the DL world at the time, so this point has, perhaps,  
less purchase against his position. He could count that as little  
gain. It all depends on what you are trying to do.)

> That said, having lost this debate back in the Web Ontology Working  
> Group, my group has gone along with this decision, developing OWL  
> DL tools (such as Pellet), debugging tools for OWL DL (in SWOOP),  
> etc. I should mention that I strongly believe most of these tools  
> would work just fine with some small heuristic changes to relax the  
> restrictions imposed by OWL DL, meaning tools could simply be "OWL  
> Tools" and not Full v. DL.

I think Jim would agree that some parts of OWL Full as they stand are  
a little wacky. E.g., having the syntax available for modification is  
weird and hard both to develop tools for and for users to use (with  
any confidence). That being said, OWL 1.1 includes features from owl  
full, i.e., a certain degree of OWL Full metamodeling, which tools  
like Pellet and Swoop already support (to a certain degree).

Personally, my reading and recollection of history suggests that the  
group basically ran out of time/energy to get OWL Full *really*  
right. At the only WebOnt face2face I attended, we went from having  
*no* properties on classes at all, to having annotation properties on  
classes. The step from that to full punning is not large at all, and  
would give Daniel what he needs right now, I believe.

> What would change is that if one lived outside the restrictions of  
> what is now called OWL DL, you would lose some reasoning guarantees,

Some things definitely lead to undecidability (e.g., OWL Full  
metamodeling applied to even so restricted a DL as ALC is undecidabe,  

The other problem is that there is really no account on how to do OWL  
Full reasoning at all, except by a rather dodgy translation to full  
FOL. So I don't think it's the *in principle* guarantees that were as  
significants as the de facto ones, that is, that we pretty much knew  
what to expect when implementing reasoners. This left our group, for  
example, time and energy to focus on services beyond the standard,  
which I think are crucial to making the whole enterprise work. Core  
reasoning isn't nearly as helpful by itself as when embedded in a  
rich infrastructure.

> but I happen to believe, unlike many in this community, that those  
> guarantees are drastically over-rated, and contribute to people  
> being able to publish papers, not to real systems that real people  
> want to use to solve real problems.

I think that's a bit harsh :) On the one hand, there are at least  
three companies (Cerebra, Racer systems (via Franz), and Ontoprise  
(of KAON2)) selling OWL DL based tools. On the other, I don't think  
they have smashing runaway sales. They do have *some* customers,  
though. And it's not clear that the relatively few sensible things to  
bring over (some form of classes as instances, some form of keys, a  
few others) are the things that *make the difference* between usable  
for real systems (etc.) and not. Surely, if they were, people would  
implement them even without a standard, since they would be a  
competitive advantage. And while OWLED05 did point these and similar  
things as important to the community, none of them were deal breakers  
*per se*.

Perhaps more strikingly, there are no systems that I know of that  
attempt to cover a significant fraction of OWL Full, other than  
pellet, which avoids a lot of the OWL Fullness (i.e., aims at more  
OWL 1.1 functionality). Let me try a SWRL analogy. Putting aside DL  
Safe rules and OWL 1.1 property tricks for a moment, SWRL is the  
union of OWL DL and horn clauses. That union is undecidable. It would  
be weird that either a pure OWL DL system *or* a datalog system  
covered a significant fraction of SWRL. Similarly, it's hard to count  
the various OWL full micros as covering significant franctions of OWL  
Full, mostly because they neglect most of the language.

Now you can well argue that they cover the most useful fragment, but  
that's a different debate, eh? I.e., an argument for exclusion, not  

> Needing workarounds for things like this user's problems (he is  
> trying to do the straight-forward encoding, and now he will need to  
> do extra work if he wants to use the current tools), or even worse  
> to have database keys (i.e. inversefunctional datatypes properties)  
> was a very foolish mistake on our part, and I believe the community  
> will either come to regret it (by seeing OWL use replaced by rule  
> implementations)

I think I disagree on the "very foolish mistake". It was unfortunate  
that the group didn't have time and energy to research and reach  
sensible variants of these and other features....

> or will have to come up with workable solutions (some of which, I'm  
> happy to say, are happening in the OWL 1.1 framework that Bijan  
> mentioned).

as you say, we are trying to address these with a point upgrade :)  
They clearly matter for some users, though needs vary. So it's  
important for people to present their needs clearly and forcefully :)

>   In other words, it would make much more sense for us to fix our  
> tools instead of fixing our users (with the connotation of  
> neutering in the latter case being very much intended).

I don't think it's wrong to point out that the current standard  
requires workarounds, or that using nonstandard extensions will hurt  
portability (or forward compatibility). That's the current situation,  
unfortunately. We can change that, though!

I *strongly* encourage folks to come out for OWLED this year:

Last year was a great time and helped push things forward. So, come  
help push!

Received on Monday, 14 August 2006 12:54:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:14 UTC