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:12:12 -0600
Message-Id: <p06230912bff469dab568@[]>
To: Enrico Franconi <franconi@inf.unibz.it>
Cc: Dan Connolly <connolly@w3.org>, Bijan Parsia <bparsia@isr.umd.edu>, RDF Data Access Working Group <public-rdf-dawg@w3.org>

>On 18 Jan 2006, at 04:58, Pat Hayes wrote:
>>>But, you probably did not pay attention to our text:
>>>"In fact, with the proviso that bnodes are not allowed to appear 
>>>in pattern solutions, SPARQL may be extended to provide a way to 
>>>override the default "simple entailment" with "RDF entailment", 
>>>"RDFS entailment" (as defined in [RDF-MT]), and "OWL entailment" 
>>>(as defined in [OWL-Semantics], where the syntactic restrictions 
>>>in OWL-DL or OWL-Lite should be reflected in suitable syntactic 
>>>restrictions on the form of basic graph patterns)."
>>>So, we suggest an upward compatible extension *without* bnodes in 
>>>the answer, because it is the only one which we know is going to 
>>>work for sure (it is easy to see this). As our latest interactions 
>>>proved, it is an open research problem how to have a query 
>>>language with bnodes in the answer based on entailment which can 
>>>also smoothly work with simple entailment.
>>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 .}
>Look, this is not a legal OWL-DL query.

This query pattern has legal OWL-DL instances, so why is it not a 
legal OWL-DL query?

>We pointed out in our old proposed text (and also in the new one). 
>We allow in OWL-DL only queries that carry similar syntactic 
>restrictions as OWL-DL expressions.

Saying that a thing is in a class, using rdf:type, can be a legal 
OWL-DL expression. Many OWL ontologies consist of little else. -DL 
does not allow restrictions and other definitions to use rdf:type, 
but it does not prohibit simple assertions of membership in an OWL 

>This boils down to allow only for non-high order RDF graphs as BGPs 
>(defined in [1]). So the above query is not of our concern in OWL-DL.

Well, of course you are free to define things your way, but that does 
not seem to alter the OWL DL specs, which do not mention 
"higher-order" graphs.

>As far as OWL-full is concerned, my very personal position is that I 
>don't care, since I don't believe it makes *currently* any sense at 
>all :-)

Maybe you should read some more recent logic texts :-). None of the 
OWLs are higher order. But let us ignore Full for now, I agree.

>So, whatever you say about OWL-full, is fine for me...

I wasn't meaning to go into OWL Full. The entailments I mentioned are 
all OWL-DL valid.

>>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: in fact, one could reasonably 
>>take the position that the *only* non-redundant answer here would 
>>be to bind ?x to a term representing the most restrictive 
>>intersection. But to construct such a term would require the use of 
>>the RDF collection vocabulary when presenting the answer.
>Even if we allow high-order queries like the above in OWL-DL, the 
>scoping set B would be restricted to be URIs in OWL-DL, so the 
>problem doesn't show up in OWL-DL anyway!

We could so restrict things, of course: but my point was that such a 
restriction might not be semantically/pragmatically correct in the 
OWL case. I agree some form, sufficiently restricted, of OWL querying 
can be made to work in the SPARQL framework, but if we try to design 
a querying standard which is really based correctly on actual OWL-DL 
entailment, and not on a narrow restriction of it, then I think we 
will need to reconsider these definitions. But perhaps we all agree 
on that point.

Let us take this discussion off this list, as it seems to be 
peripheral to SPARQL (though interesting), do you agree?

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:12:27 UTC

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