- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Mon, 14 Aug 2006 13:54:03 +0100
- To: Jim Hendler <hendler@cs.umd.edu>
- Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, Daniel Gresh <dgresh@lle.rochester.edu>, public-owl-dev@w3.org
On Aug 11, 2006, at 7:18 PM, Jim Hendler wrote: [snip] > 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, see: <http://dip.semanticweb.org/documents/Boris-Motik-On-the-Properties- of-Metamodeling-in-OWL.pdf>) 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 inclusion. > 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: <http://owl-workshop.man.ac.uk/OWLWorkshop06.html> Last year was a great time and helped push things forward. So, come help push! Cheers, Bijan.
Received on Monday, 14 August 2006 12:54:26 UTC