Hi Andy, I have follow up question for #2 after looking at DatasetGraph class, and Jena's code sample for the update operation. Which interface I can implement, so that I can do something like below: * if the statement in SPARQL query is INSERT, then convert it to specific custom logic (i.e. add new row to our custom data storage) * if the statement in SPARQL query is DELETE, then convert it to specific custom logic (i.e. remove the row from our custom data storage)
I see there is a UpdateExecutionFactory class, and not sure where to put my own implementation. Thanks, Z ________________________________________ From: Andy Seaborne <[email protected]> Sent: Thursday, September 10, 2015 10:39 AM To: [email protected] Subject: Re: jena technical doc 1. SPARQL Query and SPARQL Update are different languages (in the spec) and have different APIs in Jena. You can't (by design in the spec) pass a update where a query is expected. It is always a parse error. 2. DatasetGraph.add(Quad) and .delete(Quad) Andy On 10/09/15 13:52, Zen 98052 wrote: > Thanks Andy. Let me look at the code and some examples pointed by you. > In the meantime, I have another question. > > I have following code where I validate if the SPARQL query string is SELECT > statement or not. > > Query q = QueryFactory.create(queryString); > QueryExecution qe = null; > try { > qe = QueryExecutionFactory.create(q, graphModel); > } catch (QueryParseException e) { > throw new RuntimeException(e); > } > > if (q.getQueryType() != Query.QueryTypeSelect) { > throw new UnsupportedOperationException("Only SELECT > query is supported."); > } > > This code works fine, but I want to support INSERT and DELETE operations too. > If queryString is INSERT/DELETE, then this code > QueryFactory.create(queryString); will throw exception. > 1. Does Jena have a way for me to check the operation, and handle it > accordingly? > > 2. Also, where is the integration point where I can convert SPARQL's > INSERT/DELETE statement into my own implementation? > > > Thanks, > Z > > ________________________________________ > From: Andy Seaborne <[email protected]> > Sent: Thursday, September 10, 2015 1:44 AM > To: [email protected] > Subject: Re: jena technical doc > > On 10/09/15 00:20, Zen 98052 wrote: >> Hi, >> >> I am new to Jena programming. >> >> I am using Jena's SPARQL API to process the query and translate the >> query into accessing our custom back-end storage. I am now familiar >> with basic code like subclassing the GraphBase and QueryIter with my >> own implementation. But I need to learn more on extending the query >> optimization. >> >> >> I found this doc >> (http://jena.apache.org/documentation/query/arq-query-eval.html) is a >> good start, but it's not comprehensive enough for beginner like me. >> Even the Java API doc also doesn't have much info, for example I was >> looking at OpExecutorFactory class at >> https://jena.apache.org/documentation/javadoc/arq/org/apache/jena/sparql/engine/main/OpExecutorFactory.html >> >> >> >> <https://jena.apache.org/documentation/javadoc/arq/org/apache/jena/sparql/engine/main/OpExecutorFactory.html>One >> option is to read the Jena source code and try to understand what it >> does, but it'd be nice if there are some documentation which I can >> read first before I have to look at the source code. >> >> >> >> Thanks, Z >> > > Hi, > > Without knowing more about your custom layer, it's hard to be very > definite. You are probably better off looking at the code because when > you come to integrate your work, you'll want to debug it and that means > seeing how the internals work. > > For SPARQL processing, you don't (normally) need to implement Graph. > Graph is for the RDF API. > > For SPARQL, it's based on DatasetGraph; there is a class hierarchy of > classes covering many cases so usually you only need to plug into one of > those. DatasetGraphTriplesQuads for example even if you have a > triples-only storage system. > > SPARQL processing goes via OpExecutor. OpExecutor itself is a general > execution of SPARQL algebra. See OpExecutorTDB1 for an example of an > OpExecutor extended for a specific storage layer. > > OpExecutorTDB1 is the TDB specialization of OpExecutor to provide access > to TDB-stored RDF; it only needs to provide the points where a SPARQL > query actually touches the data: OpQuadPattern. > > Theer are few other there - OpBGP, OpGraph for the case of a TDB graph > in a general mixed dataset (i.e a mix of storage layers). > > OpFilter is implemented by TDB to place filters within basic patterns > because at that point, it is working with internal identifiers for RDF > terms. > > Hope that helps, > Andy >
