[
https://issues.apache.org/jira/browse/JENA-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187063#comment-17187063
]
Claus Stadler edited comment on JENA-1945 at 8/29/20, 5:16 PM:
---------------------------------------------------------------
Hi Andy,
I see that w.r.t. property paths the whole concept breaks because with SPARQL
1.1 the needed rewrite can no longer be expressed and I agree that under this
consideration Algebra.unionDefaultGraph should be deprecated.
Then again, having some transformation that makes a SPARQL query written for an
RDF graph (i.e. just using triple patterns) run on all named graphs (at least
on a best effort basis) *independently from the RDF DBMS* is still a very
useful one. E.g. for RDF stream processing one typically wraps each event in a
named graph. Ideally the events are modelled in such a way that they can also
be merged into a single graph. So for someone querying such set of events it
should not matter whether they reside in indivdual named graphs or whether they
have been merged into a single graph - the same query should just work if the
appropriate flag is set on the connection. The question would be whether and
where it would fit in Jena.
Btw, AFAIK there is no unionDefaultGraph-like flag in the SPARQL protocol
itself or is there?
was (Author: aklakan):
Hi Andy,
I see that w.r.t. property paths the whole concept breaks because with SPARQL
1.1 the needed rewrite can no longer be expressed and I agree that under this
consideration Algebra.unionDefaultGraph should be deprecated.
Then again, having some transformation that makes a SPARQL query written for an
RDF graph (i.e. just using triple patterns) run on all named graphs (at least
on a best effort basis) *independently from the RDF DBMS* is still a very
useful one. E.g. for RDF stream processing one typically wraps each event in a
named graph. Ideally the events are modelled in such a way that they can also
be merged into a single graph. So for someone querying such set of events it
should not matter whether they reside in indivdual named graphs or whether they
have been merged into a single graph - the same query should just work if the
appropriate flag is set on the e connection. The question would be whether and
where it would fit in Jena.
Btw, AFAIK there is no unionDefaultGraph-like flag in the SPARQL protocol
itself or is there?
> Algebra.unionDefaultGraph: OpPath not handled
> ---------------------------------------------
>
> Key: JENA-1945
> URL: https://issues.apache.org/jira/browse/JENA-1945
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Affects Versions: Jena 3.16.0
> Reporter: Claus Stadler
> Priority: Major
>
>
> {code:java}
> System.out.println(
> Algebra.unionDefaultGraph(
> Algebra.compile(
> QueryFactory.create("SELECT * { ?s <urn:p> ?o }"))));
> /* Yields correct result:
> (distinct
> (graph ??_
> (bgp (triple ?s <urn:p> ?o))))
> */
> System.out.println(
> Algebra.unionDefaultGraph(
> Algebra.compile(
> QueryFactory.create("SELECT * { ?s <urn:p1>/<urn:p2>/<urn:p3> ?o }"))));
> /* Yields incorrect result because wrapping with graph ??_ (and distinct) is
> missing:
> (path ?s (seq (seq <urn:p1> <urn:p2>) <urn:p3>) ?o)
> */
> {code}
>
> It seems
> [TransformUnionQuery.java|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/algebra/TransformUnionQuery.java#L34]
> lacks the handling of (at least) OpPath
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
