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

["Andy Seaborne (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JENA-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Seaborne resolved JENA-2154.
---------------------------------
    Fix Version/s: Jena 4.2.0
         Assignee: Andy Seaborne
       Resolution: Done

> 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
>            Assignee: Andy Seaborne
>            Priority: Major
>             Fix For: Jena 4.2.0
>
>
> 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)