Re: [rdf4j-dev] Google Summer of Code ideas

[Rick Moynihan <rick.m@xxxxxxxxxx>]

On 26 January 2017 at 00:38, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:

On 25 Jan 2017, at 20:47, Rick Moynihan <rick.m@xxxxxxxxxx> wrote:

On 24 January 2017 at 22:09, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:

Hi folks,

Eclipse is participating in the Google Summer of Code  and have invited all projects to think about participating as well. There’s two ways in which we can become involved: :

1. Extending the QueryRenderer for SPARQL 1.1 (#71);

I'd certainly like to see the above implemented; though it's worth mentioning you can work around this by using JENA's ARQ.

You’re thinking of the QueryBuilder rather than the renderer, here. I’m pretty sure ARQ can’t process an RDF4J ParsedQuery object to produce a SPARQL string :) 

Actually I do specifically mean the QueryRenderer, but yes they're two sides of the same coin.  Basically we had to switch some SPARQL rewriting code from sesame/RDF4j to JENA because ARQ supports round tripping SPARQL 1.1, where as sesame only supports round tripping SPARQL 1.0.  We basically have to rewrite some queries with ARQ round trip them back into a SPARQL string and then fire them into RDF4j.  I'm pretty sure this original issue with the renderer was actually raised by us.

 

But extending the QueryBuilder is another one on my list, indeed. Perhaps a feature that would make it useful beyond what ARQ can do is that it creates and RDF4J algebra model directly, rather than producing a SPARQL string to feed into the parser. 

I think it's definitely useful to be able to produce a SPARQL string too though.  The reason is that supporting the algebra model directly probably isn't portable across other stores, and from my experience dealing with alternate backends (e.g. bigdata, graphdb and stardog) also probably not even across stores that use the sesame interfaces.

Regarding ARQ I could be wrong but I think it does already support creating the algebra model directly.  I thought their SSE (sparql s-expressions) were a representation of the algebra.  We actually rewrite our queries via the SSE's and then convert them back into a SPARQL query string.  FWIW the SSE approach seems to work quite well.

Another issue I've been meaning to raise is that the current parsers for all the RDF formats are all eager and even though they emit parse events they can't be aborted early from the outside. This means that if you want to read an RDF file it's an all or nothing affair, or you have to resort to hacks like parsing it on another thread and passing events over a queue.  I'm not sure if this is a big enough change to warrant a GSOC project, but it's something I've been meaning to discuss.

Happy to open a ticket on the issue if you think it's worth while, rather than derailing this thread.

Are you talking about a pull-based parser? By all means open a ticket describing the issue and the use case, and then we can think about whether it’s doable and whether it’s suitable for GSoC.

Yes, a pull-based parser is exactly what I want.  I should've probably said that, but thought there are probably also less intrusive ways to make the current push-based approach work, by e.g. providing a method for the parser events to control the execution flow by letting them e.g. call some kind of stopParsing method to allow early termination in both successful and failure cases (failure might already be supported by raising an exception).  Anyway will write up an issue for it.

R.

 

Jeen

_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rdf4j-dev