Jena has multiple parsers, on per SPARQL version and also one with local
extensions ("ARQ").
The ARQ syntax is SPARQL1.2 + a few extensions, mostly legacy now, but
it does include LATERAL. It is the default syntax (API and Fuseki).
I wouldn't be keen on experimental syntax, because it creates on-going
support, but if this form of named subqueries is getting some traction,
then we could add it to ARQ syntax.
Looking at https://docs.qlever.dev/named-subqueries/, it could even be
done entire during parsing as a substitution in the parser phase. But it
would not then print as such later. No need to add a new Element (Java
objects in the the syntax tree).
If added a new Element, the substitution could be done during algebra
generation. Then the syntax tree prints using WITH, and the execution
isn't extended.
Increasingly deeper integration is possible later. It does all have to
happen at once.
Andy
On 13/10/2026 16:01, Sebastian Trueg via users wrote:
Hi Rob,
thank you for the quick reply. Tbh, I was a bit afraid of creating my
own parser, thought it required forking Jena. But if you say that it
is perfectly feasible, then I will give that a try.
Regards,
Sebastian
On Tue, 13 Oct 2026 at 15:48, Rob Vesse <[email protected]> wrote:
AFAICT Jena does not provide a way to extend the SPARQL parser. Is there
any way this could be added? Or can you think of another way to do this
without the need to fork Jena itself?
Actually it does, and has done so for a very long time. I was using this in
production SPARQL database systems at a previous day job over a decade ago
now.
The key APIs/interfaces you want to investigate are as follows:
- SPARQLParserRegistry which maps Syntax to SPARQLParser instances, register
a custom parser via SPARQLParserRegistry.add()
- SPARQLParser which implements the actual parser. What I did previously
was to use the SPARQL JavaCC grammars from Jena as a base, add the relevant
syntax extensions with their productions and then generate a parser class in
my code base that I can register per the above.
- You may need to extend the Query class in order to capture the syntax
extensions. If you're purely using Jena for validation and then passing the
original query string as-is you can likely skip this.
- When calling QueryFactory.create() pass in your custom Syntax (which maps to
your custom SPARQLParser) directly OR set the Syntax.defaultQuerySyntax to
your
custom syntax
Unfortunately the code I worked on was all for proprietary product so I can't
share it (and I haven't worked there in nearly 5 years now anyway) but hopefully
this is enough to get you started.
Happy to answer any further questions as you dig into this.
Best Regards,
Rob Vesse
On 2026-10-13 08:56 UTC Sebastian Trueg via users wrote:
Hi Andy (and others),
we are currently in the process of replacing Blazegraph as the backend for
the Wikidata query service with Qlever. The current version of WDQS
supports a bunch of non-standard SPARQL features and syntax via
Blazegraph-plugins. For WDQSv2 we are mostly targetting SPARQL 1.1.
However, a few additional features will make it into the new version, to
make the transition easier for users of WDQSv1. One of these features is
named sub-queries. Qlever recently added support for them (see
https://docs.qlever.dev/named-subqueries/), which is nice. However, we
parse each query via Jena for some validation, prefix injection, and custom
service resolving.
This works fine for most cases, but when it comes to named sub-queries,
Jena will fail to parse additional syntax like "WITH %something AS { ...
}". This is expected of course, since it is not valid SPARQL.
AFAICT Jena does not provide a way to extend the SPARQL parser. Is there
any way this could be added? Or can you think of another way to do this
without the need to fork Jena itself?
Have a nice day.
Cheers,
Sebastian
