W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: Final text for Basic Graph Patterns

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 18 Jan 2006 16:35:06 -0600
Message-Id: <p06230913bff46dcea280@[]>
To: Bijan Parsia <bparsia@isr.umd.edu>
Cc: Dan Connolly <connolly@w3.org>, franconi@inf.unibz.it, RDF Data Access Working Group <public-rdf-dawg@w3.org>

>On Jan 18, 2006, at 5:55 AM, Enrico Franconi wrote:
>>On 18 Jan 2006, at 04:58, Pat Hayes wrote:
>>>I am still bothered by the possibilities of OWL-specific notions 
>>>of redundancy in answer sets. Consider an OWL/RDF KB that asserts
>>>:a rdf:type :A
>>>:a rdf:type :B
>>>:a rdf:type :C
>>>:A rdf:type owl:Class
>>>:B rdf:type owl:Class
>>>:C rdf:type owl:Class
>>>and an OWL query
>>>SELECT ?x WHERE {:a rdf:type ?x .}
>>>Now, this dataset OWL-entails the *existence* of a triple 
>>>intersection and three double intersections, all with :a in them. 
>>>So are these reasonable answer bindings for such a query? I see no 
>>>good reason why they should not be:
>How about all the disjunctions involving them? (Or all disjunctions 
>rooted in them?) Or all min 0 restricitons?

Quite, you made my point for me. I'm not suggesting that it makes 
sense to deliver all of these. My point is that they are all equally 
justified as OWL answers if we think solely in terms of entailment: 
and so to arrive at a sensible notion of 'answer set', we need to 
think about kinds of redundancy - such as that between intersection(A 
B C) and intersection(A intersection(B C)) - and how to specify that 
answer sets don't exhibit them. And that these kinds of redundancy go 
way beyond the simple kind of extra-bnode-instances that we have 
considered so far.

>It's very very very tricky.

Indeed, though to be fair logicians have been thinking about this 
stuff for years and have some useful ideas, such as logical normal 
forms of one kind and another, and for example Sowa's ideas on what 
counts as 'same proposition' when comparing sentences, and how to 
compute it quickly.

>I've been thinking about such queries and the obvious (first step) 
>restrictions to the binding of ?x are URIs and explicit/told bnodes 
>(for cases where someone has made an type assertion to an anonymous 
>class). I tend to think that fishing expeditions of this sort are 
>just going to die hard.
>(Syntactically there's a fairly sever problem, IMHO, in that you 
>can't current return an expression as a binding. So you'd have to 
>rely on bnode stability in more contexts.)

Agreed, there is a problem of specifying the implied 'context' of the 
bnode. One problem seems to arise from the fact that OWL abstract 
syntax has to be encoded as a collection described by a graph in 
OWL/RDF. If one were to transcribe OWL into some FOL-style notation, 
as in http://www.ihmc.us/users/phayes/CL/SW2SCL.html an answer 
binding could be a single term composed from functional operations 
like AND, OR and ONEOF, but this would require an entire constructed 
answer graph to represent it (with an answer binding to a bnode in 
that answer graph) in order to deliver similar functionality.

>Retrieving the named types + forcing the user to speculate about 
>complex expressions, or maybe adding asserted complex expressions 
>seems to be at the limit of what we know how to do reasonably well 
>(from an interface standpoint) and the former is all I've seen 
>implemented or proposed.

I'm pretty sure that some LP systems could do better than this using 
term unification, although they might have other limitations which 
would be problematic.

But my main point was only that we shouldn't do something in SPARQL 
which sets out to legislate what will be correct in this unexplored 
jungle, is all. And I think we all agree on this general point.



IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Wednesday, 18 January 2006 22:35:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC