[jira] [Created] (JENA-2154) Custom SERVICE executors

["Claus Stadler (Jira)" <ji...@apache.org>]

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)