Currently we use a mixture of rdflib and sparqlwrapper in all sparql implementations (recall we also use sparql for local rdf files as well).
These provide extremely low-level interfaces and assume string construction of SPARQL queries, and leave it to the caller to avoid bobby tables style injections. Additionally, string manipulation of queries is an antipattern. E.g. this kind of thing:'SELECT {" ".join(select_vars)}' + where_clause
To circumvent this we have various helper classes and a simple SPARQL query object dataclasses, e.g
However, query construction is still fairly low level.
We should use modern query builder patterns here. Options are:
reuse an existing library
generalize the existing helper classes into a separate standalone library that could be used by others
When I last looked into 1, I was disappointed by the current state of python sparql query builders, lots of abandonware. This seems surprising given the maturity of SPARQL. However, we should do another review before deciding on a course of action.
Note that the requirements here are for a query builder library. We have existing template libraries like sparqlfun, but we want to be able to do things like programmatically compose queries.
Currently we use a mixture of rdflib and sparqlwrapper in all sparql implementations (recall we also use sparql for local rdf files as well).
These provide extremely low-level interfaces and assume string construction of SPARQL queries, and leave it to the caller to avoid bobby tables style injections. Additionally, string manipulation of queries is an antipattern. E.g. this kind of thing:
'SELECT {" ".join(select_vars)}' + where_clause
To circumvent this we have various helper classes and a simple SPARQL query object dataclasses, e.g
https://github.com/INCATools/ontology-access-kit/blob/56859dd247becea27cc4f469c28288daea0744f7/src/oaklib/implementations/sparql/sparql_query.py#L14-L23
However, query construction is still fairly low level.
We should use modern query builder patterns here. Options are:
When I last looked into 1, I was disappointed by the current state of python sparql query builders, lots of abandonware. This seems surprising given the maturity of SPARQL. However, we should do another review before deciding on a course of action.
Note that the requirements here are for a query builder library. We have existing template libraries like sparqlfun, but we want to be able to do things like programmatically compose queries.