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/06/11 10:57:29 UTC

Re: Fuseki - support for custom processors like JOSEKI

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 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
>