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

On Nov 28, 2007, at 8:32 PM, Bernardo Cuenca Grau wrote:

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

to me the question is whether the identification of these things in a  
specification/recommendation is important - I don't disagree they are  
worth knowing and noting, and I'd love to see you publish this in a  
higher visibility forum - I just have some trouble believing that I'm  
going to see a major company's product that brags about supporting  
DL_Lite_R - however, an IBM or Oracle product that could claim to  
cover "OWL Lite" seems like something they would like (or a Web 3.0  
provider who can say "we can import RDFS 3.0 ontologies"

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

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...
but, what is the motivator is that several studies of ontologies  
including the one we did at Maryland a couple years back [1], a  
recent study by Guus and Frank van Harmelen (I don't have a  
reference, was told about it by Guus and Frank), and a study by UMBC  
of Swoogle results (blogged in eBiquity last year) all showed that  
most of the currently most used ontologies (including FOAF) pretty  
much fall into this class.  I've also met with several companies  
involved in OWL startups, and this is the expressivity that most of  
them say is most useful.

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

2 is that a lot of DBs have rules built in, or companies in the data  
space have rule-based engines, and they've said that being able to  
represent the Owl terminology directly in rules is useful (i.e.  
owl:inverse(P1, P2) is defined as X P1 Y => Y P2 X) - the original  
DAML had such an axiomization (although in KIF) and we heard from a  
number of implementors that they felt it easier to work from that  
than from the model theory

3 is badly stated - what I meant is that many of the formal results  
about DL are done with respect to a particular set of reasoning  
services (mainly focused on inconsistency checking) but that there  
are other things that some people need (for example fast computation  
of transitive closures) that are less obviously related to the  
tractability results for inconsistency checking -- I'd wager that  
most of the real world web apps that are using RDF/RDFS are using  
procedural reasoners (what you neats call "ad hoc code") that are  
quite fast, many parallelizable, and some only care about particular  
reasoning  -- so I don't see why we should say that writing a piece  
of code to process "owl:sameAs" relations against a large RDF-DB is  
somehow less interesting than proving a polynomial result for Tbox  
reasoning in some DL subset.

In short, the people using RDF and RDFS, who many of us would like to  
get to start using more OWL, have motivations that are answered by  
other fragments than the ones chosen to be listed in the tractable  
fragments (some of which depend on particular definitions of  
tractibility, but you and Carsten have a better discussion of that  
going than I need to)


> Any clarifications will be welcome!
>

hope that helped -- FWIW, I wouldn't mind seeing some particular  
subset of OWL with a really nice mapping to datalog being tagged as  
"OWL DB", for example, but I would hope that the definition would be  
made in such a way that someone wouldn't need a PhD in AI to decide  
if they were using it or not

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

"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