[
https://issues.apache.org/jira/browse/JENA-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409154#comment-17409154
]
Claus Stadler commented on JENA-2154:
-------------------------------------
In my PR I added the context lookups to QueryIterService (which as a fallback
delegates to Service).
In some cases having access to the query before the substitution may be
relevant - especially when the content of the SERVICE clause is interpreted in
fancy ways.
Some years ago I [created a
prototype|https://github.com/dice-group/LIMES/issues/116] where link
specifications (such as for limes) could be (partly) expressed in a service
clause which contains 2 nested service clauses for the source and target
endpoints and a filter statement for the linking expression. In such cases one
wouldn't want substitution to have taken place.
> 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
> Priority: Major
>
> 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)
