Request for a QueryExecutionFactory interface

[Claus Stadler <cs...@informatik.uni-leipzig.de>]

Hi,

Would it be possible to add a QueryExecutionFactory (QEF) *interface* to 
Jena?
The com.hp.hpl.jena.query.QueryExecutionFacotry has lots of static 
factory methods, but I guess it would be very useful if Jena itself 
provided such an interface (either different package, different name or 
both) because
then implementations based on Jena could rely on such interface (see 
below and [1]) in a (quasi) standard way, and other projects could 
provide fancy implementations.

public interface QueryExecutionFactory
extends QueryExecutionFactoryString, QueryExecutionFactoryQuery
{ /** * Some Id identifying the SPARQL service, such as a name given to 
a jena Model or the URL of a remote service */
String getId(); /** * Some string identifying the state of this 
execution factory, such as the selected graphs, or for query federation 
the configured endpoints and their respective graphs. * Used for caching */
String getState();
}


The reason I ask this, is because I created [2], which uses this 
architecture to transparently add delay, caching and pagination to a QEF 
- i.e. you could just pose a usual SPARQL query to DBpedia, and [2] will 
take care of retrieving the *complete* result, thereby caching each page 
so that one can resume pagination from cache should something go wrong.

But for example, someone might provide a parallel pagination component, 
or some query federation system, such as FedX could be wrapped with such 
interface as well, and application developers would not have to rely on 
a specific implementation.

Cheers,
Claus

[1] 
https://github.com/AKSW/jena-sparql-api/blob/master/jena-sparql-api-core/src/main/java/org/aksw/jena_sparql_api/core/QueryExecutionFactory.java
[2] https://github.com/AKSW/jena-sparql-api

-- 
Dipl. Inf. Claus Stadler
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org/
Workpage & WebID: http://aksw.org/ClausStadler
Phone: +49 341 97-32260

Re: Request for a QueryExecutionFactory interface

[Andy Seaborne <an...@apache.org>]

Hi Claus,

Fancy implementations can be provided - the mechanism is to provide 
QueryEngineFactory (which is an interface).  The system takes a query 
and a daatset and asks each registered QueryEngineFactory if it will 
handle the query.  The first one to say "yes" gets to execute the query. 
  The general purpose query engine is last on the last on that list.

https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src-examples/arq/examples/engine/MyQueryEngine.java

This how TDB and SDB extend ARQ.  They look for datasets of a given type.

(They both also implement Graph and are able to execute queries on 
single graphs so you can have a mixture of graph storage types in one 
dataset.  That isn't required.)

Proving this through a fixed QueryExecutionFactory means that once init 
code runs, there isn't an issue of finding the QueryExecutionFactory.

But if you want to provide something that replaces even QueryExecution 
then maybe we can find a way within the current style of looking for 
factories.  This woudl then not disrupt people's code.

QueryExecutionFactory.make(Query, Dataset, Context) would look for 
QueryExecution creators using one that did the current 
QueryEngineFactory+QueryExecutionBase thing.

If you need more than QueryEngineFactory, please raise a JIRA to discuss 
this ... details matter :-) when avoiding disturbing existing code.

	Andy

PS You may be interested in Stephen's
https://svn.apache.org/repos/asf/jena/Experimental/jena-client/

Not the same but maybe of interest.

On 07/06/13 12:52, Claus Stadler wrote:
> Hi,
>
> Would it be possible to add a QueryExecutionFactory (QEF) *interface* to
> Jena?
> The com.hp.hpl.jena.query.QueryExecutionFacotry has lots of static
> factory methods, but I guess it would be very useful if Jena itself
> provided such an interface (either different package, different name or
> both) because
> then implementations based on Jena could rely on such interface (see
> below and [1]) in a (quasi) standard way, and other projects could
> provide fancy implementations.
>
> public interface QueryExecutionFactory
> extends QueryExecutionFactoryString, QueryExecutionFactoryQuery
> { /** * Some Id identifying the SPARQL service, such as a name given to
> a jena Model or the URL of a remote service */
> String getId(); /** * Some string identifying the state of this
> execution factory, such as the selected graphs, or for query federation
> the configured endpoints and their respective graphs. * Used for caching */
> String getState();
> }
>
>
> The reason I ask this, is because I created [2], which uses this
> architecture to transparently add delay, caching and pagination to a QEF
> - i.e. you could just pose a usual SPARQL query to DBpedia, and [2] will
> take care of retrieving the *complete* result, thereby caching each page
> so that one can resume pagination from cache should something go wrong.
>
> But for example, someone might provide a parallel pagination component,
> or some query federation system, such as FedX could be wrapped with such
> interface as well, and application developers would not have to rely on
> a specific implementation.
>
> Cheers,
> Claus
>
> [1]
> https://github.com/AKSW/jena-sparql-api/blob/master/jena-sparql-api-core/src/main/java/org/aksw/jena_sparql_api/core/QueryExecutionFactory.java
>
> [2] https://github.com/AKSW/jena-sparql-api
>