Re: ACTION-418: review property paths section in Entailment

Axel,
I have now added your example, which hopefully makes the
counter-intuitive behaviour that can occur when mixing PPs with
entailment clearer.
Birte

On 24 April 2011 22:56, Birte Glimm <birte.glimm@comlab.ox.ac.uk> wrote:
> On 20 April 2011 00:40, Axel Polleres <axel.polleres@deri.org> wrote:
>> 1) Editorial:
>>
>> "In the presence of entailment path expressions are sometimes redundant as their semantics is already captured by the entailment relation."
>> -->
>> "In the presence of a particular entailment regime, path expressions are sometimes redundant as their semantics is already captured by the entailment relation."
>
> done
>
>> 2) Editorial. THe simplified version of the query:
>>
>>  "SELECT ?type ?c WHERE { ex:a rdf:type ?x . { ?x rdfs:subClassOf{0} ?type } UNION { ?x rdfs:subClassOf+ ?type } ex:a ex:p1 ?tmp1 . ?tmp1 ex:p2 ?c }"
>>
>> should be:
>>
>>  "SELECT ?type ?c WHERE { ex:a rdf:type ?x . { ?x rdfs:subClassOf{0} ?type } UNION { ?x rdfs:subClassOf+ ?type } ex:a ex:p1 ?tmp1 . ?tmp1 ex:p3 ?c }"
>
> done
>
>> likewise
>>  "bgp2 = ex:a ex:p1 ?tmp1 . ?tmp1 ex:p2 ?c"
>>
>> should be
>>  bgp2 = ex:a ex:p1 ?tmp1 . ?tmp1 ex:p3 ?c"
>
> done
>
>>  likewise
>>  "Evaluating Bgp(ex:a ex:p1 ?tmp1 . ?tmp1 ex:p2 ?c) would yield [...]"
>> should be
>>  Evaluating Bgp(ex:a ex:p1 ?tmp1 . ?tmp1 ex:p3 ?c) would yield [...]"
>
> done
>
>> shouldn't it? i.e. s/ex:p2/ex:p3/
>
> yes, my mistake
>
>> 3) Question (potentially problematic):  On your example data which includes the triples
>>
>>     ex:b ex:p2 ex:c .
>>     ex:p2 rdfs:subPropertyOf ex:p3 .
>>
>>   Would the query
>>      Q  =  SELECT * WHERE { ?X (ex:p3+) ?Y }
>>   yield any results?
>>
>> It seems no: If I read it correctly, since ArbitraryPathLength is checked without taking entailments into account, so it wouldn't "catch" that p3 is a
>> superproperty of p2 in this form, would it? However, a result might be expected for that query under RDFS.
>
> Yes, the query would have no answer since entailment does not apply to
> triples such as s p+ o since entailment is only defined for RDF
> triples, but the triple is not an RDF triple. That's what I mean when
> I find it problematic to introduce another extension point next to BGP
> matching. Entailment and PPs together is just confusing.
>
>> An implementation the implememnts RDFS by materialising all inferences and then running normal SPARQL evaluation would yield a different result,
>> as far as I can tell, and that should be pointed out. Ideally we don't lock-in into that, i.e. we should at least keep a path open that
>> future entailment regimes can  address path expressions in a more intuitive way, but I'm not sure at the moment how that could be done.
>
> I am also not sure. For a long time I was under the assumption that
> PPs are optional since they were initially a seperate document and
> they mess with the BGP extension point, basically making the existing
> BGP extension point no longer sufficient. Now extensions of BGP
> matching in fact have to deal with the issue of PPs and the query doc
> is silent on this although that's where the extension point is defined
> I pointed that out several times and in my last review, but without
> much success. IMO SPARQL had an extension point, the entailment work
> is based on that, but now the BGP matching extension point has in fact
> been changed without mentioning it. Now you have to also match PPs and
> not just BGPs and ideally you would also say how PPs are matched in an
> extension, but since PPs are not RDF, no entailment relation is
> defined from them or could be resued.
>
>> If the observation is right, then I am also unsure about the last sentence "Combining the other entailment regimes with property path expressions is, however, relatively straightforward." since people might not find the result of Q very straightforward.
>
> Well, I mean that you can evaluate PPs with simple entailment and BGPs
> with whatever other entailment you use. That's unintuitive and I am
> not happy about it, but the whole entailment regimes work was done
> under the assumption that SPARQL has one BGP matching extension point.
> If you introduce orthogonal ones besides that and ones that don't go
> well with entailment, then combining both will always be a mess. I can
> add a counter intuitive example as well, but I also think that the
> query doc ought to point out that there no longr is just one extension
> point and that the existing extension point is now only half the
> story. Its use now leaves you in a messy situation with some parts
> non-extendable (PPs) and while others are.
>
> Birte
>
>>
>> best,
>> Axel
>>
>>
>>
>>
>>
>
>
>
> --
> Dr. Birte Glimm, Room 309
> Computing Laboratory
> Parks Road
> Oxford
> OX1 3QD
> United Kingdom
> +44 (0)1865 283520
>



-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520

Received on Wednesday, 27 April 2011 09:41:17 UTC