Claus Stadler created JENA-2154:
-----------------------------------
Summary: Custom SERVICE executors
Key: JENA-2154
URL: https://issues.apache.org/jira/browse/JENA-2154
Project: Apache Jena
Issue Type: New Feature
Components: ARQ
Affects Versions: Jena 4.1.0
Reporter: Claus Stadler
While Jena features many extension points for SPARQL query processing, such as
for custom functions and property functions, there is no dedicated extension
point for custom SERVICE executors.
The relevant classes are OpExecutor and QueryIterService:
While it is possible to configure a custom OpExecutor's in a Context which
provides SERVICE extensions, it is not possible to combine the functionality of
two different OpExecutors.
Concrete use case: The following two projects use their own OpExecutor
implementation for providing service extensions:
* [RDF Processing
Toolkit|https://github.com/SmartDataAnalytics/RdfProcessingToolkit/tree/develop/doc#federating-to-sorted-bzip2-encoded-n-triples]
supports a service executor for doing binary search over remote sorted (bzip2
encoded) ntriples files
* [SPARQL Anything|https://github.com/SPARQL-Anything/sparql.anything] provides
service extensions for ingesting non-RDF data as RDF
Proposed solution:
* Introduce a ServiceExecutorFactory that serves as the extension point for
supplying custom QueryIterators if the request can be handled
{code:java}
public interface ServiceExecutorFactory {
Supplier<QueryIterator> createExecutor(OpService op, Binding binding,
ExecutionContext context);
}
{code}
* Introduce a Symbol for referring to a List<ServiceExecutorFactory> in the
Context
* Extend QueryIterService such that it consults the Context for custom
ServiceExecutorFactories - and invokes the first match from the list before
falling back to the standard implementation.
* Example usage:
{code:java}
try (QueryExecution qe = QueryExecutionFactory.create(...)) {
qe.getContext().put(ARQ.customServiceExecutors,
Arrays.asList(/* ServiceExecutorFactories */));
}
{code}
This way, SERVICE extensions do not require custom OpExecutor implementations
(because it would be handled by QueryIterService) - and conversely, such
extensions would also work with any custom OpExecutor that yields the original
QueryIterService implementation.
I could provide my
[implementation|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-arq-parent/jena-sparql-api-arq-core/src/main/java/org/aksw/jena_sparql_api/arq/core/service]
as a PR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
