While reading about how SPARQL computes its solutions I considered that we can get much better efficiency by choosing when and how to do joins based on our own needs rather than letting RDFLib's sparql plugin handle it. I think it took me so long to make this change in thinking since I'm used to doing things in relational databases using static queries with a set number of joins. I've started writing some demo programs that build paths in the RDF graph to query. The solution uses generators, so porting to other languages will require a slightly different approach that breaks up the code in the generators for other languages, like Java, that do not support them. Happily, other facilities, like being able to iterate over an RDF graph given a triple pattern is available in Java through Jena with list_statements and in C through Redland with librdf_model_find_statements.

Reading

I am currently doing some reading on how SPARQL queries are evaluated in order to improve the inefficiency of complicated queries created by PyOpenWorm.

PyOpenWorm R1

We (myself, Stephen Larson, Anton Shekhov, Travis Jacobs) have continued working on PyOpenWorm in order to get it release-ready. The work that has been done has focused on documentation of previously existing work, addition of data-integrity tests, and inclusion of data in the PyOpenWorm database from existing spreadsheets and the sqlite3 database contributed by Timothy Busbice.