Re: putting entailment into SPARQL

>On Tuesday 20 December 2005 15:48, Pat Hayes wrote:
>>  >On 13 Dec 2005, at 23:27, Pat Hayes wrote:
>>  >>Pattern Solution.
>>  >>A variable substitution is a substitution function on a subset of V
>>  >>to RDF-T. A pattern solution on the pattern V to the dataset G is a
>>  >>variable substitution whose domain includes all the variables in V,
>>  >>whose range is a subset of the set of RDF terms occurring in G, and
>>  >>which matches the dataset DS.
>>  >
>>  >Pat, by restricting the domain in this way you rule out RDF(S)
>>  >entailment, since there are terms which should be in any RDF(S)
>>  >graph, even if not explicitly mentioned (e.g. rdf:type or
>>  >rdf:Property).
>>
>>  We  should discuss this. I intended to restrict in this way for all
>>  entailments. That is, I do not think that tautological queries should
>>  succeed against an empty graph, even when they are entailed. The
>>  point of querying is not primarily to test entailment, but to find
>>  out what is in the actual graph.
>
>Well, this is true for simple entailment anyway. I think that when you use
>RDF(S) entailment, then you expect the following query to succeed:
>
>ASK { rdf:type rdf:type rdf:Property }
>
>otherwise you'd gather that the server is not really doing RDF entailment.

I agree it would be a reasonable expectation. But I think I don't 
draw the same conclusions from this that you do.

>If
>someone's interested in just the actual graph contents, then simple
>entailment is there.
>Note that, even with simple entailment you don't need to explicitly restrict
>the variable bindings to the active domain, because it is implicit in the
>definition of simple entailment. Restricting to the active domain is just
>necessary to prevent arbitrary bnodes from sneaking into the query answer.

True, so the restriction could be, er, restricted to bnodes only and 
have the same SPARQL effect, as you suggest. Still, I will defend the 
restriction.

>
>>  >My understanding is that this restriction should be enforced for bnodes
>>  > only.
>>
>>  IMO that would be too narrow. But if you think the global restriction
>>  is too tight, can you show some examples?
>
>If you accept that
>
>ASK { rdf:type rdf:type rdf:Property }
>
>succeeds, then the fact that 'rdf:type' is not among the results of the query
>
>SELECT * { ?x rdf:type rdf:Property }
>
>would be rather odd.

Why? Consider the even more similar query with a bnode:

ASK {_:x rdf:type rdf:Property}

This might succeed, and still the SELECT should fail. The difference 
between the ASKs and the SELECT is exactly that the latter is asking 
for an explicit binding to a variable, which I take to be a question 
about the actual graph. A Select query in effect says: Does the graph 
mention things which satisfy this pattern? (Where one gets different 
notions of 'satisfy' by tweaking the entailment used.) Surely this is 
implied by the very idea of a query language, that it is designed to 
query a data source? The working group is called 'data access': it's 
not called 'checking entailment'. And what utility would be provided 
by a service which is obliged to answer tautological queries? Suppose 
for example I want to know all properties in an OWL graph for which 
it is known that they have at least three distinct values. This 
requires that I use OWL entailment, since there are many ways that 
restriction might follow from the actual graph assertions. Still, I 
almost certainly do not wish to be told that rdf:type is one of those 
properties.

Pat


>
>--sergio


-- 
---------------------------------------------------------------------
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, 21 December 2005 17:50:16 UTC