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

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

Received on Sunday, 24 April 2011 21:57:08 UTC