W3C home > Mailing lists > Public > public-owl-wg@w3.org > December 2007

Re: proposal - Fragments redux (unifying the threads under Issues 75-80)

From: Deborah L. McGuinness <dlm@ksl.stanford.edu>
Date: Wed, 05 Dec 2007 08:12:58 -1100
Message-ID: <4756F83A.8020306@ksl.stanford.edu>
To: Jim Hendler <hendler@cs.rpi.edu>
CC: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>, Carsten Lutz <clu@tcs.inf.tu-dresden.de>, Bernardo Cuenca Grau <bcg@cs.man.ac.uk>, OWL Working Group WG <public-owl-wg@w3.org>

Jim Hendler wrote:
> On Nov 30, 2007, at 5:28 PM, Ian Horrocks wrote:
>> On 29 Nov 2007, at 17:06, Jim Hendler wrote:
>>> On Nov 29, 2007, at 2:44, Carsten Lutz <clu@tcs.inf.tu-dresden.de> 
>>> wrote:
>>>> On Wed, 28 Nov 2007, Jim Hendler wrote:
>>>>> well, it's not so much motivated by computational properties, see 
>>>>> out in the real world there's people who just implement fast 
>>>>> engines and don't worry so much about the details...
>>>> Sorry to object, but IHMO this approach is precisely why the original
>>>> OWL Lite was broken. And I understood we wanted to fix this?! We 
>>>> should
>>>> at least understand the computational properties of the fragments we
>>>> are selecting.
>>> IMO, its because we worried too much about theory that lite is broken
>> I can't let this go by without a correction. OWL Lite is broken 
>> because it was designed without *any* consideration of theory -- the 
>> design "methodology" was to haggle over what features to throw out 
>> and what to leave in, without any (rigorous) analysis of the 
>> (computational) consequences. There was even a last minute push to 
>> have oneOf be included on the grounds that it is a "must have" 
>> feature for many users; this was only given up when it was pointed 
>> out that the resulting language would have exactly the same worst 
>> case complexity as OWL DL.
> but Ian, this is just the point - nominals by themselves are no 
> problem (I think even EL++ allows the equivalent of hasValue - i.e. 
> OneOf with a single value) and many DB and Rule languages have them.  
> We added too many things and then cut back based on DL reasoning 
> issues (what I meant by the theoretical in the above).  So we never 
> really looked at starting from scratch with language design issues 
> involved and people who have, like HP and  Oracle (I use these because 
> they are in the WG, there are others as well) have developed other 
> subsets.  In a number of papers, as unnamed fragment centered 
> somewhere near the thing I called RDFS 3.0 has been identified as the 
> most used, and it has been implemented by a much larger number of 
> implementors than have implemented full OWL DL tools - i.e. all the 
> various FOAF tool providers, several of the Web 3.0 folks, several 
> open source triple stores, and various of the academic systems demoed 
> at ISWC.
>  btw, this subset is not designed without consideration of theoretical 
> concerns, this subset can be supported by datalog with some fairly 
> simple restrictions
>  -JH
As one of the supporters of OWL Lite initially and a continued OWL Lite, 
i think it is important to have some simpler OWL language that people 
can start with.  I am actually most concerned about having some OWL Lite 
- so that both implementors have something to start with and new users 
have some useful subset to do simple applications with.

I am not sure from this thread if people think
- OWL Lite is "broken".  if there is consensus on this, is there one 
description of broken that we can use to "fx" it?  (it looks to me like 
different people might want to fix different things.
(If someone thinks they have a good handle on how to define broken that 
either might lead to consensus or might be operational enough to work 
from to fix it, we might float those definitions and see if we get 
consensus on them.)
- there is value in having different OWL subsets that this working group 
might bless

I think it is important to retain having one OWL Lite (and updating the 
current OWL Lite if we need to).
I could live with us defining  a few subsets (aimed at different target 

Received on Wednesday, 5 December 2007 19:13:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:41 UTC