You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Mario Ds Briggs <ma...@in.ibm.com> on 2012/05/22 10:26:50 UTC
Fuseki - support for custom processors like JOSEKI
Hi,
i had used JOSEKI in the past and made use of the
http://joseki.org/2005/06/configuration#processor and
http://joseki.org/2003/06/module#implementation/className config setting to
register a custom processor for either query/update. Can't find anything
similar in Fuseki.... wondering if something like this is supported.
thanks in advance
Mario
Re: Fuseki - support for custom processors like JOSEKI
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
>>
Would I be right in guessing that you create a different query object
for some reason?
<<
yes basically we have our own parser. Looking to see if can avoid the
double parsing (When used with jena API's, we have a wrapper that extends
the JENA query object.)
thanks
Mario
From: Andy Seaborne <an...@apache.org>
To: Mario Ds Briggs/India/IBM@IBMIN
Cc: dev@jena.apache.org
Date: 06/12/2012 05:22 PM
Subject: Re: Fuseki - support for custom processors like JOSEKI
Sent by: Andy Seaborne <an...@gmail.com>
On 11/06/12 09:57, Mario Ds Briggs wrote:
> Andy,
>
> I am going back to your older reply since now i understood some more
>
>>>
> Extending Fuseki with different SPARQL processors can be done via ARQ
> where ARQ dispatches a query to an execution engine [4].
>
> In fact, adding a new language to Fuseki isn't that difficulty because
> ARQ itself has the ability, now little used externally, for different
> query languages. ARQ's extended SPARQL and standard SPARQL dispatch via
> this mechanism.
> <<
>
>
> So i looked and found the ParserRegistry and ParseFactory and figured out
> that route to get it our custom parser integrated. However stuck at 2
> points
>
> 1 - com.hp.hpl.jena.query.QueryFactory.create(String queryString,
String
> baseURI, Syntax syntax) has the below
> Query query = new Query() ;
> parse(query, queryString, baseURI, syntax) ;
> return query ;
>
> shouldnt it instead be
> Query query = new Query() ;
> return parse(query, queryString, baseURI, syntax) ;
>
> With the above change, it works just right. Is the above an
unintentional
> bug ?
Checking all the parsers, they return the query object passed in.
While not used, the passed in query object might be part initialized
(e.g. prefixes set).
Would I be right in guessing that you create a different query object
for some reason?
> 2 - The ParserRegistry depends on the syntax definition to pick out the
> parserFactory that will handle the query,. However Fuseki hardcodes the
> syntax argument
>
> org.apache.jena.fuseki.servlets.SPARQL_Query.execute(String
queryString,
> HttpActionQuery action)
> query = QueryFactory.create(queryString, Syntax.syntaxARQ) ;
>
> Picking it from the action is a possibility. But then since it is a
> 'Syntax' object, would need some factory to instantiate 'Syntax' object
> from string... unless the ParserRegistry can work off plain URI's/Symbols
> object.
("Syntax" is an open enum - you can create your own).
The action does reference the dataset description which could have a
syntax. As the rest of the system does rather depend on object of class
Query, could you say how are you using the Query object? Do you make
your own?
(Hacky)
You can remove the syntaxARQ binding in the ParserRegistry and replace
it with your own parser.
Andy
>
> thanks
> Mario
>
Re: Fuseki - support for custom processors like JOSEKI
Posted by Andy Seaborne <an...@apache.org>.
On 11/06/12 09:57, Mario Ds Briggs wrote:
> Andy,
>
> I am going back to your older reply since now i understood some more
>
>>>
> Extending Fuseki with different SPARQL processors can be done via ARQ
> where ARQ dispatches a query to an execution engine [4].
>
> In fact, adding a new language to Fuseki isn't that difficulty because
> ARQ itself has the ability, now little used externally, for different
> query languages. ARQ's extended SPARQL and standard SPARQL dispatch via
> this mechanism.
> <<
>
>
> So i looked and found the ParserRegistry and ParseFactory and figured out
> that route to get it our custom parser integrated. However stuck at 2
> points
>
> 1 - com.hp.hpl.jena.query.QueryFactory.create(String queryString, String
> baseURI, Syntax syntax) has the below
> Query query = new Query() ;
> parse(query, queryString, baseURI, syntax) ;
> return query ;
>
> shouldnt it instead be
> Query query = new Query() ;
> return parse(query, queryString, baseURI, syntax) ;
>
> With the above change, it works just right. Is the above an unintentional
> bug ?
Checking all the parsers, they return the query object passed in.
While not used, the passed in query object might be part initialized
(e.g. prefixes set).
Would I be right in guessing that you create a different query object
for some reason?
> 2 - The ParserRegistry depends on the syntax definition to pick out the
> parserFactory that will handle the query,. However Fuseki hardcodes the
> syntax argument
>
> org.apache.jena.fuseki.servlets.SPARQL_Query.execute(String queryString,
> HttpActionQuery action)
> query = QueryFactory.create(queryString, Syntax.syntaxARQ) ;
>
> Picking it from the action is a possibility. But then since it is a
> 'Syntax' object, would need some factory to instantiate 'Syntax' object
> from string... unless the ParserRegistry can work off plain URI's/Symbols
> object.
("Syntax" is an open enum - you can create your own).
The action does reference the dataset description which could have a
syntax. As the rest of the system does rather depend on object of class
Query, could you say how are you using the Query object? Do you make
your own?
(Hacky)
You can remove the syntaxARQ binding in the ParserRegistry and replace
it with your own parser.
Andy
>
> thanks
> Mario
>
Re: Fuseki - support for custom processors like JOSEKI
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
Andy,
I am going back to your older reply since now i understood some more
>>
Extending Fuseki with different SPARQL processors can be done via ARQ
where ARQ dispatches a query to an execution engine [4].
In fact, adding a new language to Fuseki isn't that difficulty because
ARQ itself has the ability, now little used externally, for different
query languages. ARQ's extended SPARQL and standard SPARQL dispatch via
this mechanism.
<<
So i looked and found the ParserRegistry and ParseFactory and figured out
that route to get it our custom parser integrated. However stuck at 2
points
1 - com.hp.hpl.jena.query.QueryFactory.create(String queryString, String
baseURI, Syntax syntax) has the below
Query query = new Query() ;
parse(query, queryString, baseURI, syntax) ;
return query ;
shouldnt it instead be
Query query = new Query() ;
return parse(query, queryString, baseURI, syntax) ;
With the above change, it works just right. Is the above an unintentional
bug ?
2 - The ParserRegistry depends on the syntax definition to pick out the
parserFactory that will handle the query,. However Fuseki hardcodes the
syntax argument
org.apache.jena.fuseki.servlets.SPARQL_Query.execute(String queryString,
HttpActionQuery action)
query = QueryFactory.create(queryString, Syntax.syntaxARQ) ;
Picking it from the action is a possibility. But then since it is a
'Syntax' object, would need some factory to instantiate 'Syntax' object
from string... unless the ParserRegistry can work off plain URI's/Symbols
object.
thanks
Mario
Re: Fuseki - support for custom processors like JOSEKI
Posted by Andy Seaborne <an...@apache.org>.
On 23/05/12 08:48, Mario Ds Briggs wrote:
> thanks Andy for the elaborate response. Yes i was looking at Fuseki for the
> SPARQL Graph Store Protocol support.
>
> I am also aware of ARQ's Query extension points, but we dont implement the
> QueryEngineFactory interface and thats why my question.
>
> [4] [1] does have this 'While it is possible to replace the entire process
> of query evaluation, this is a substantial endeavour. ', which is assume is
> not supported.
If you can return a A QueryExecution via your your own means then that's
fine. The QueryEngineFactory route means you can reuse, say CONSTRUCT
processing yet stil implement a general execution of the graph pattern
which I guess is what you are doing.
> Also is there some docs i can read up on about - 'The graph store protocol
> implementation is extensible via implementing
> DatasetGraph'
The source code is probably the place to look. SPARQL_REST_R and
SPARQL_REST_RW (not very large).
The implementation executes and performs various API calls -- everything
turns into add/remove/find of quads on DatasetGraph in some way even if
via model operations.
Andy
>
> thanks in advance
> Mario
>
>
Re: Fuseki - support for custom processors like JOSEKI
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
thanks Andy for the elaborate response. Yes i was looking at Fuseki for the
SPARQL Graph Store Protocol support.
I am also aware of ARQ's Query extension points, but we dont implement the
QueryEngineFactory interface and thats why my question.
[4] [1] does have this 'While it is possible to replace the entire process
of query evaluation, this is a substantial endeavour. ', which is assume is
not supported.
Also is there some docs i can read up on about - 'The graph store protocol
implementation is extensible via implementing
DatasetGraph'
thanks in advance
Mario
Re: Fuseki - support for custom processors like JOSEKI
Posted by Andy Seaborne <an...@apache.org>.
On 22/05/12 09:26, Mario Ds Briggs wrote:
>
> Hi,
>
> i had used JOSEKI in the past and made use of the
> http://joseki.org/2005/06/configuration#processor and
> http://joseki.org/2003/06/module#implementation/className config setting to
> register a custom processor for either query/update. Can't find anything
> similar in Fuseki.... wondering if something like this is supported.
>
> thanks in advance
> Mario
>
(links and context mainly for the general reader of this reply).
Mario,
There are several ways to extends Fuseki but it's via a different route
to Joseki.
Fuseki is dataset (and SPARQL) centric. A dataset has a number of
services associated with it. Fuseki provides the SPARQL graph store
protocol [1] which is a RESTful way to manage and access the data in an
RDF dataset. In protocol terms, this is similar to the protocol part of
the Linked Data Basic Profile IBM submitted [2] to W3C and which forms
the basis of the Linked Data Platform Working Group [3].
Joseki is a more general framework for services with less emphasis on
the dataset as the unit. It does not provide the SPARQL graph store
protocol - there is no reason why it can't but the amount of help the
framework would give is limited. Joseki could be used to provide
different query and update languages
Fuseki, or Joseki4 as it might have been called, is a chance to rework
the code into a SPARQL-centric, dataset-centric design.
In fact, adding a new language to Fuseki isn't that difficulty because
ARQ itself has the ability, now little used, for different query languages.
Extending Fuseki with different SPARQL processors can be done via ARQ
where ARQ dispatches a query to an execution engine [4].
TDB itself uses this mechanism - TDB is neither hardwired into Fuseki
(or ARQ) nor does it make use makes use of private access. It gets
integrated when the assembler file via:
[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
The command line abbreviates for publishing from TDB do know about TDB
but only to imitate the actions as assembler would perform.
In fact, adding a new language to Fuseki isn't that difficulty because
ARQ itself has the ability, now little used externally, for different
query languages. ARQ's extended SPARQL and standard SPARQL dispatch via
this mechanism.
The graph store protocol implementation is extensible via implementing
DatasetGraph. A level of indirection to have an implementation
registry, like the ones found for query and update, is also possible but
has not (yet?) been done.
Together, these provide the equivalent to Joskei's custom query
processor facility and is more SPARQL centric.
Andy
[1] SPARQL 1.1 Graph Store HTTP Protocol
http://www.w3.org/TR/sparql11-http-rdf-update/
[2] Linked Data Basic Profile 1.0
http://www.w3.org/Submission/2012/02/
[3] Linked Data Platform (LDP) Working Group Charter
http://www.w3.org/2012/ldp/charter
[4] ARQ - Extending Query Execution
http://jena.apache.org/documentation/query/arq-query-eval.html
and
http://jena.apache.org/documentation/query/arq-query-eval.html#custom-query-engines