SPARQL will be formalized as an algebra

Andy Seaborne announced yesterday that he is working on a SPARQL algebra for inclusion in the spec. His current draft is here: SPARQL Algebra.

I have criticized SPARQL’s lack of a formal semantics before, and I’m glad to see the working group addressing this.

Andy’s draft is based on the “compositional semantics” introduced by Pérez et al., with some tweaks to better account for FILTERs inside OPTIONALs. I think that’s an excellent choice, a good compromise between meeting user expectations and straightforward implementation on relational stores.

The downside is that the semantics of some queries change. This is bad news for early adopters. The changes will affect implementers because they have to tweak their code. Users will not be strongly affected as far as I can tell, the semantics of all the most typical kinds of queries remain identical. No need to worry, unless you have nested OPTIONALs or FILTERs inside OPTIONALs.

The second downside is that SPARQL, which already was in the Candidate Recommendation stage, will remain a moving target for some time.

This entry was posted in General, Semantic Web. Bookmark the permalink.

3 Responses to SPARQL will be formalized as an algebra

  1. Bijan Parsia says:

    The rolling back from CR was for *many* reasons, so, in a sense, it’s not the algebra’s fault :)

    On the other hand, the group is not intending *another* CR phase, last I checked. Thus it can go straight to PR after another last call. Having an ubercleaner spec and language is worth it, IMHO.

    As for early adopters, one argument I *really* dislike in current groups is the worry about invalidating existing queries. Sorry, bzzt, it’s not a spec until it is a spec. One of the prices for earlier adoption is that things *may change*. I’ve suffered through this several times, but it seems quite wrong to tie a WGs work that way.

    Of course you *want* early experimental adoption, but those folks need to realize that they do so at some risk!

  2. Jeen Broekstra says:

    What Bijan said. I do not think catering to early adopters is worth settling for a crippled spec. It’s not fixed until it is out of “alpha-stage” (as I have to keep telling early adopters of some our own software ;)).

  3. It’s better than that: FILTERs inside OPTIONALs do not change!

Comments are closed.