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

> * 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
>

The document tries to give an overview of the different (families of)
different choices. In fact, it is not that exhaustive since there are much
more creatures in the jungle than the ones I mentioned. I had to make a
selection :) I agree with Jim in that we may need to be even pickier.

I do think, however, that identifying fragments with nice computational
properties  *is* important. Most of the fragments in the document  have
been carefully designed and have involved years of intensive research. In
fact, most existing ontologies comply with  them, so
these fragments are something more than a mere academic exercise. Moreover, efficient
reasoners exist for them (at least for the ones I selected). I think it
would be a bad idea for the OWL community not to take advantage of such a
research effort.


> * 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 agree on fixing OWL Lite. That was one of the goals of this document,
namely to present sensible possible fixes.

> * 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 don't think I understand the motivations of that fragment, the
ontologies one could express using it,  and its
computational properties. Is there any relevant literature about this
fragment that I could take a look at? Any reasoning system I could try?

I am afraid I also don't quite understand some of the
requirements, namely 2) ``can have a clean operational semantics defined
via rule-based axiomatization'', 3) ``does not assume a specific reasoning
model'';

Any clarifications will be welcome!

Bernardo


>
>   -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
>
>
>
>
>


***********************************
Dr. Bernardo Cuenca Grau
Research Fellow
Information Management Group
School Of Computer Science
University of Manchester, UK
http://www.cs.man.ac.uk/~bcg
************************************

Received on Thursday, 29 November 2007 01:32:42 UTC