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.

Received on Friday, 22 February 2008 17:33:54 UTC