Re: Fragments discussion, continued

+1 for all Bijian's points: 1) the need for a RDBMS-friendly fragment that 
would capture the basic ER diagram constructs, and 2) the lessons learnt 
from SHER[1].

Best regards,
Achille.

[1] 
http://domino.research.ibm.com/comm/research_projects.nsf/pages/iaa.index.html




Bijan Parsia <bparsia@cs.man.ac.uk> 
Sent by: public-owl-wg-request@w3.org
02/22/2008 12:35 PM

To
"Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>
cc

Subject
Re: Fragments discussion, continued







On 22 Feb 2008, at 16:56, Jeremy Carroll wrote:

> On DL-Lite
>
> Jim Hendler wrote:
>> telecon) - so those have both been motivated.  You've suggested 
>> another fragment move Rec track, and all I'm asking is whether you 
>> can motivate it on the same dimensions that the others were.
>
> I think on the telecon we had a view that the fewer rec-track 
> fragments the better, but we need to rec-track those fragments 
> where we expect there to be a genuine need for interoperability 
> between commercial systems. I think Bijan characterized this as a 
> CR exit criteria to do with two 'production quality' 
> implementations targetting that fragment.
[snip]

> In a sense, the DL-Lite advocates should be outlining such 
> properties, which would help articulate why the fragment is useful. 
> The bumper sticker seems to be "scalable A-Box reasoning" so turn 
> that into an objective measure that can be checked at CR.

I don't know that I'm an advocate, but I've listened to such often :) 
The key implementation property is that DL Lite is "database like" in 
the sense that the data complexity is the same as the data complexity 
of relational databases (unlike DLP which has recursive rules; so DL 
Lite is a "database" like fragment whereas DLP is a "rule" like 
fragment). So you can implement it by compiling to SQL without rules.

On the usability side, DL Lite is expressive enough to represent a 
large fragment of UML diagrams (including, for some flavors, 
functional cardinality constraints). My personal sense, playing with 
it, is that its "surface appeal" is much like what OWL Lite was 
aiming at.  It seems good for conceptual modeling and enhancing (or 
aligning) relational db schema. (This is what I understand IBM 
Italia's interest in it is based on, but that's hearsay and 
speculation on my part.)

> (We could have tests with substantial A-Box and the CR exit 
> criteria for DL-Lite is that the DL-Lite implementations should be 
> significantly faster

Well, scalability ~= performance, remember. A tableau in memory 
reasoner might, for variously sized ontologies, easily beat a DL Lite 
implementation based on MySQL just because of load time. But we'd 
hope that the DL Lite implementation could scale beyond memory and to 
many users.

> than the DL implementations)
[snip]

This is a bit tricky as e.g., SHER has shown that you can be quite 
scalable on the ABox side even with non-polynomial fragments of OWL. 
Of course, the implementation effort for DL Lite would be much less 
(since SHER requires a SHIQ reasoner as a component). I would also 
expect a DL Lite implementation to be more robustly scalable. That 
is, it would be less sensitive to differences in ontologies or data 
patterns. Whereas with SHER, if the OWL reasoner can't process the 
proxy's TBox, it can't reason at all.

Cheers,
Bijan.