In an earlier post, Evren talks about our implementation of integrity constraints using SPARQL queries where we are turning the constraints into queries which we then post to the KB in order to determine if there was a violation of the constraint.
I’ve been working on an internal project lately, and while we were having a code review the other day, we decided that adding some validation via integrity constraints would be useful. The catch was that I’m using Sesame, in particular, Sesame 1.2.7 since that offers the best query performance of their whole line of software (at least it did the last time I checked). And since I am using the older Sesame API, I’m without SPARQL support. This makes it difficult for me to repurpose our IC prototype since it’s based on Jena and SPARQL.
So I worked on an implementation of our IC interface that was based on the Sesame API and used SeRQL. This turned out to be vastly easier than I expected. One of the workaround’s we used for the SPARQL-based implementation was the OPTIONAL/FILTER/!BOUND pattern because SPARQL does not provide a NOT keyword for encoding Negation as Failure. As it turned out, I didn’t need to implement a workaround like this using SERQL. I was able to get by using the NOT & IN keywords with a subquery to get the same behavior. The resulting queries are very clear. So with some code to translate the constraints into SERQL queries, and a Sail implementation backed by a Pellet KnowledgeBase, we get the same IC joy in Sesame projects as we do with Jena and SPARQL.
This is good fodder for the new SPARQL working group that we’re participating in (nominally, so far); I believe subqueries and negation are both being considered. They would make great additions to the revised SPARQL.