[
https://issues.apache.org/jira/browse/JENA-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16921208#comment-16921208
]
Jan Martin Keil edited comment on JENA-1751 at 9/3/19 10:58 AM:
----------------------------------------------------------------
{quote}Just so we're clear here - {{ElementPathBlock}} is the unit used by
SPARQL 1.1 parsing.
{{ElementTriplesBlock}} (SPARQL 1.0) intentionally throws an exception if
given a path.
{quote}
Thanks for the hint. I think, it would make sense to update both and also other
subclasses of {{Element}} with add* methods:
* {{ElementData}}
* {{ElementGroup}}
* {{ElementUnion}}
{quote}Does module jena-querybuilder meet your needs?
{quote}
Unfortunately not. For example, (NOT) EXISTS requires to use {{Element}}
subclasses.
{quote}Also - general point - if programmatically generating a query, you may
wish to generate SPARQL algebra and not SPARQL syntax. Sometimes, it's easier.
{quote}
Thanks for the hint, again. I will have a look.
{quote}The only issue I see is that changing a method signature to add a return
is binary-incompatible even if it is source-compatible.
{quote}
To avoid this incompatibility one could only add constructors like {{public
ElementPathBlock(Triple... triples)}} that make chains unnecessary. At least
for my use case, this would work. What do you think?
was (Author: jmkeil):
{quote}Just so we're clear here - {{ElementPathBlock}} is the unit used by
SPARQL 1.1 parsing.
{{ElementTriplesBlock}} (SPARQL 1.0) intentionally throws an exception if
given a path.
{quote}
Thanks for the hint. I think, it would make sense to update both and also other
subclasses of {{Element}} with add* methods:
* {{ElementData}}
* {{ElementGroup}}
* {{ElementUnion}}
{quote}Does module jena-querybuilder meet your needs?
{quote}
Unfortunately not yet. For example, it does not provide (NOT) EXISTS support.
This would change by treating this issue and JENA-1752.
{quote}Also - general point - if programmatically generating a query, you may
wish to generate SPARQL algebra and not SPARQL syntax. Sometimes, it's easier.
{quote}
Thanks for the hint, again. I will have a look.
{quote}The only issue I see is that changing a method signature to add a return
is binary-incompatible even if it is source-compatible.
{quote}
To avoid this incompatibility one could only add constructors like {{public
ElementPathBlock(Triple... triples)}} that make chains unnecessary. At least
for my use case, this would work. What do you think?
> Enable inline use of Element Subclasses
> ---------------------------------------
>
> Key: JENA-1751
> URL: https://issues.apache.org/jira/browse/JENA-1751
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Jan Martin Keil
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enable the inline use of
> {{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query
> generation, I propose to:
> * add constructor {{public ElementTriplesBlock(Triple triple)}}
> * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
> * add {{return this}} to
> ** {{addTriple(Triple t)}}
> ** {{addTriple(int index, Triple t)}}
> ** {{addTriplePath(TriplePath path)}}
> ** {{addTriplePath(int index, TriplePath path)}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
