Re: Fragments discussion, continued

I'm not sure why I am confusing people, and if I'm confusing Jeremy  
than I'm definitely not explaining myself well :-)
   Let me try it this way - I think two of the fragments we are  
discussing - an Abox-oriented complete fragment (which could start  
from DL-Lite) and a fragment that is more rule-based (maybe from pd*,  
maybe using natural deduction rules or other such) - could be put into  
a similar relation to that that OWL DL 1.0 and OWL Full 1.0 have -  
that the "vocabulary" of each is nearly identical, but that one  
requires living with certain restrictions in exchange for certain  
guarantees, and the other doesn't.
    I don't think the ideas people are sharing are far apart, and I  
think some of the new features of OWL 1.1 (for example transitivity)  
could be discussed as part of the data fragment very profitably.   My  
comment to Peter, which Ian took offense to for some reason, was that  
we (the WG) had not yet proposed a design, and thus claiming which  
things were in and out was still negotiable - so his entailment about  
disjointness, for example, is dependent on whether we add disjoint to  
the language or not,, and if so how it is defined, and that's not a  
discussion we've had.
  So what would happen with this, if we went this direction: at the  
end we have OWL DL 1.1 and OWL Full 1.1 (not part of the fragments  
discussion) and we have "OWL for data" DL and "OWL for data" Full --  
and we try to keep the sort of mappings we have in DL and Full, i.e.  
roughly corresponding semantic coverage, differently described (I even  
will yield, as I did on 1.0, to having the DL semantics be normative  
and the other be informative).
  This does leave EL++ as a standalone (i.e. not corresponding Full  
equivalent) but that would be easy for the WG to say we leave for  
future work,  and it is clearly well motivated by very large Tbox  
ontologies.  It also leaves OWL (1.0) Lite as we have, I think, agreed  
(i.e. minimally changed for consistency w/the 1.1 design, but  
essentially as is for backwards compatibility with current  
implementations)
  This means OWL would have
    OWL DL 1.1, OWL Full 1.1, "owl for data" DL, "owl for data" Full,  
EL++ and OWL Lite.  While it seems a lot, it's really sort of "three  
tiers"

OWL (DL/Full)
EL ++  //  (and Owl lite)
OWL For Data  (DL/Full)

seems to me presented right it would not be too much harder to explain  
than what we have in OWL 1.0, and I have full faith we could find  
implementations of each - include IBM and Oracle implementations of  
the "bottom" layer, which seems to me would give some faith to the  
outside world that these were motivated by the needs of data- and web-  
apps, which is important to adoption IMO.
  I have looked at the votes in the last phone log, and while this  
specific design was not discussed, I cannot find any place where it is  
incompatible with the straw poll results if I'm correctly  
understanding the questions put.
  Also, the discussion of which of these would be rec track and which  
wouldn't is not addressed here - I have no trouble with any of the  
above being in a REC, but agree that's a separate conversation.
  -JH
p.s. btw, maybe the problem is people think there are no  
interoperable  "OWL for data Full" implementations - I know of  
several, including my own, and believe it would not be hard at all to  
get through CR with a properly defined test set and a finalization of  
the design.



On Feb 22, 2008, at 11:56 AM, 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.
>
> I personally would prefer if Jim could state an opposition to DL- 
> Lite in a constructive tone of - if at the end of CR we have N  
> implementations of DL-Lite that have properties A, B and C then DL- 
> Lite is a worthwhile recommendation, otherwise not.
>
> I think the point has been made that since an OWL DL implementation  
> is a DL-Lite implementation, to be meaningful at least some of the  
> properties A, B and C have to be ones that a non-optimized DL  
> implementation would not meet. e.g. it could be a complexity measure.
>
> 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.
>
> (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 than the DL implementations)
>
> I hope that we can be serious about taking fragments to CR while  
> being neutral about whether they end in Rec or WG Note - either  
> state being satisfactory - the difference being about the level of  
> real interest exhibited during CR
>
> Jeremy
>
>
>

"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

Received on Friday, 22 February 2008 18:22:04 UTC