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

(for those who don't like long messages, I've put short headers (the  
one's with *s) that summarize the message content - so you can just  
read those and get the gist:

* Let's not move the current fragments document to Rec or even Note

So here's my radical suggestion with apologies to Bernardo and the  
others who created the current fragments document.  I think we could  
resolve a lot of issues, and also add much clarity to our work, by  
leaving the current document where it is (part of the OWL 1.1  
submission) and NOT moving it forward within the WG. I think it is  
overly academic and too inclusive to be of use as guidance to  
implementors/businesses (which is usually what specifications are  
about).

* Let's be much more picky with what we name

    Instead, I believe we should move much more cautiously on  
fragments, as these can have a lot of impact on developers and  
adoption of OWL.  Thus, I would suggest instead of a document like  
this which tries to identify all sorts of fragments (and notice, our  
charter does not specify tractability as a design req, so we must  
consider lots of other fragments as well) we try to pick a small  
number of them that are widely endorsed or used and attempt to  
highlight these.  I

* Let's fix OWL Lite which IS broken

In doing this, I would also suggest that we "fix" the problem that  
OWL Lite and OWL DL are much too close together, either by redefining  
OWL Lite (which in my experience almost no one uses on purpose -  
mostly it is people using DL who don't end up crossing the  
expressivity boundary) and in doing so we could consider answering  
the user request for a lighter lite -  by defining one (or at most a  
couple) of named fragments less than Lite, which have both DL and  
Full versions, and which tool vendors, implementors and others can  
then use as useful vocabularies.


*I know this is hard

  I would propose that the key to choosing such fragments, based on  
the experience of having defined the failing OWL Lite, is to think  
about the 1-2 paragraph description for each that explains why this  
particular fragment is named and what its features are.  This would  
be harder than simply publishing a document like the current one with  
lots and lots of things in it (and Bernardo below suggests making it  
moreso, and we also see EL++ and some others being mentioned as  
having more variants) -- again, with due respect, I think the current  
fragments document was mainly designed to show the world that  
tractable fragments of OWL exist, but I think having a rec track  
document that names lots and lots serves no real purpose.   Deciding  
it is too hard to choose, so instead trying to list everything,  
strikes me as a bad solution (how will we ever prove we have  
identified all possible fragments with any particular set of properties)
  I've often been asked by people in the "real world" why the hell we  
came up with three OWLs - imagine the fun if we come up with dozens!

* but here's a way forward

  Here's an idea - on the new fragments Wiki page - http://www.w3.org/ 
2007/OWL/wiki/Fragments - I listed one particular fragment I like -  
but I included a description, the requirements by which it was  
defined, and the particular language features it would include.  If  
people who have a particular fragment they would like to see  
included, and named, the I suggest you add one, and give these same  
pieces of information -- then we can at least see what people are  
suggesting in more detail, and discuss as a group how many of them  
people would really want to use

* I'll put my money where my mouth is

In my original intro to the group I said I was willing to help edit  
such a document.  I continue to be willing

  -Jim Hendler



On Nov 28, 2007, at 12:57 PM, Bernardo Cuenca Grau wrote:

>
>
> Ok. I see quite a lot of discussion concerning the tractable  
> fragments document, and I will try to reply to all the issues.
>
> The selected version of DL-Lite is DL-Lite_R. As Carsten points  
> out, there are other variants of DL-Lite for which reasoning is  
> tractable. These variants share a common core, but provide  
> different extensions to this core corresponding to different  
> choices that one has to make in order to keep tractability. For  
> example, DL-Lite_R extendes the ``core'' of the language with role  
> inclusion axioms. DL-Lite_F extends it with role functionality of  
> roles and their inverses. If both role functionality and role  
> inclusion axioms were to be included, the nice computational  
> properties of the DL-Lite family of languages would be compromised.
>
> The selection of DL-Lite_R was motivated by the fact that it is a  
> proper extension of the DL subset of RDF-Schema, which provides  
> role-inclusion axioms but not functionality, and therefore DL- 
> Lite_R is a language that lies in between such DL subset of RDF- 
> Schema and OWL Lite.
>
> In any case, I agree that these choices should be discussed and  
> that we could do a better job in presenting all (or most of) the  
> variants. Also, as Carsten points out, there is also a distinction  
> between tractability of reasoning and the fact that query answering  
> can be handled using RDBMS, and this should probably be made  
> explicit if we are to present other variants of DL-Lite.
>
> I think we should discuss the alternatives within the WG
>
> Bernardo
>
>
>
>
>
> OWL Working Group Issue Tracker wrote:
>> ISSUE-80 (DL-Lite): REPORTED: DL-Lite
>>
>> http://www.w3.org/2007/OWL/tracker/issues/
>>
>> Raised by: Bijan Parsia
>> On product:
>> (On behalf of Carsten Lutz.)
>>
>> There are many versions of DL-Lite around, all of them tractable,
>> and many (but not all) of them reducible to query answering in
>> RDBMS. I wonder how the fragment of DL-Lite was selected that is
>> currently in the document and what are the alternatives? Maybe
>> Bernardo can comment on this.
>>
>>
>>
>>
>>
>

"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