Re: comment on the fragment document: (inverse) functional and DL-Lite

Hi,

Another rationale for giving up property functionality in favor of 
property inclusion is that some of the E/R constructs missing in DL-LiteR 
(e.g. key and uniqueness constraints) are generally used in the database 
world to express constraints rather than enabling inferencing.  So, adding 
them to DL-LiteR will not only affect performance, it might also not 
correspond to the user's intuition or expectation (i.e. a constraint that 
has to be checked, and if  it is not violated, then query answering can be 
performed ignoring it). 

Best regards,
Achille.




Bijan Parsia <bparsia@cs.man.ac.uk> 
Sent by: public-owl-wg-request@w3.org
03/06/2008 07:34 PM

To
Jim Hendler <hendler@cs.rpi.edu>
cc
Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>, "Web Ontology Language 
((OWL)) Working Group WG" <public-owl-wg@w3.org>
Subject
Re: comment on the fragment document: (inverse) functional and DL-Lite







On Mar 7, 2008, at 12:27 AM, Jim Hendler wrote:

>
> Ahh, I misunderstood - I think we need to be very clear on this - I 
> think some of us were assuming that the idea of the DB fragment was 
> to be able to represent something close to a DB schema and use it 
> in processing data from the DB (a la datalog/SQL type stuff) - sort 
> of like expressing an E/R model and then using it to make simple 
> inferences over the data.  Anyway, a lot of the project will be 
> correctly describing these fragments and their features.

Actaully, DL Lite does that as well. The main issue is that there is 
a trade off between having subproperty heirarchies and having keys. 
Putting both together means you lose the logspace data complexity. 
Giving up the first means you lose some fairly popular RDFSness. 
Giving up the second means you lose some dbness.

I'm hoping we can keep subobjectproperites and have inversefunctional 
data properties (and give up inversefunctional object properties and 
subdataproperites) while keeping the logspace data complexity. If we 
can do that, then I think we've hit a very sweet spot of expressivity 
and scalability.

Cheers,
Bijan.