The trouble with “binding”

Danny notes that I chimed in with some Web architectural advice for those considering SPARQL updates.

On that page, he asks;

I’d like to hear more from Mark about what he sees as problematic about the current notion of binding. Although the spec seems unusual, the end result does seem to respect WebArch

It does respect Web architecture, but only because it’s read-only. As soon as you need to add mutation support, or indeed any other operation on the same resource, the process fails and what results is not Web-friendly. This is because “operation on the same resource” doesn’t work if the operation is part of the resource name; if the operation changes, the name changes, and therefore the resource-identified changes.

This is the same problem that APIs such as Flickr and suffer from; Web-friendly for read-only, horribly broken for updates.

Making something Web-friendly means mapping your data and services into a set of inter-linked resources. Application-specific APIs works directly against that.

And FWIW, from a REST POV the constraint that’s being disregarded in these scenarios is commonly resource identification.

9 thoughts on “The trouble with “binding”

  1. Richard Cyganiak

    REST’s notion of resource identity is barely compatible with RDF. Most of the things we call resources in RDF don’t have representations. REST provides no account at all of how to deal with this.

    Also, SPARQL is a language not an API. The distinction is relevant to this discussion.

    An account of what actually breaks with the current proposal and how to fix it would be helpful. “It violates The Roy Commandments” and “it is not web-friendly” do not help.

  2. Mark Baker

    “Most of the things we call resources in RDF don’t have representations”. I disagree. I’ll even go out on a limb and suggest that *all* of the things called resources on the Semantic Web have representations. REST is very much relevant.

    Regarding language vs. API, it’s six of one and a half-dozen of the other. I think we can all agree that SPARQL defines operations for performing queries, which is what is incompatible with Web architecture. See also;

    I thought I did describe the problems; if you put the operation name in the URI, as SPARQL does, then you’ll have problems evolving your system. And I also thought I described how to fix it; by “mapping your data and services into a set of inter-linked resources”. The other blog entry linked to above also makes some suggestions.

  3. Richard Cyganiak


    Only information resources have representations, and people and cars are not information resources. The TAG is very clear on this. The point of the httpRange-14 ruling was to make this clear and explicit. The ruling has been made, with support from Roy. Move on.

    I agree with the general sentiments expressed in the “SPARQL not a game changer” post. I was not able to glean any suggestions relevant to SPARQL update from it (except maybe “don’t do it”).

    In what way will we have “have problems evolving our system”? How do you know? In what way should we “map it into a set of inter-linked resources”? If you have specific suggestions on how to improve the proposal, then we would greatly appreciate them.

  4. Mark Baker

    The resolution of httpRange-14 doesn’t say that “only information resources have representations”. I don’t recall anybody making that claim during the discussion either, not even Timbl. The issue was whether resources could be named (with http URIs), not whether or not their state could be represented.

    The evolution problems I was talking about were about evolving SPARQL to add update support. Following the “binding” precedent set in SPARQL 1.0 for updates would result in something quite different than a Web based solution. Worst case you’d have URIs with embedded “update” operations that would do the update when GET was invoked on them. Best case you’d have two identifiers for the same resource; one that you GET from, and another that you PUT/PATCH/POST to, which would, amoungst other problems, break caches because representations of the former URI wouldn’t be invalidated by state-changing messages sent to the latter URI.

    For a way forward, I would like to see the scope of SPARQL acknowledged to be akin to the scope of SQL use on the Web today; as a back-end query language not intended for widespread use over the Web/Internet. I would then like to see the Semantic Web activity develop an RDF based forms language which could be used for exchanging query *parameters*, rather than full blown queries. I would also like to see SPARQL *not* bound to HTTP.

  5. Alex James


    I too wonder about SPARQL. What we really need is for the behaviour of RESTful resources to be better understood (defined) so people know when to use PUT and POST appropriately. If people conformed to this understanding of REST I don’t think it would be too hard to come up with a standard language and engine for processing distributed information exposed RESTfully, the language could perhaps be called RESTQL?

    SQL is all about functionally declaring what you want to do, and leaving the how to the SQL engine, which takes care of the plumbing for you, wiring the output of one query into the input of another

    For example

    UPDATE Products SET Price = Price*1.1 WHERE ID IN SELECT ….

    is an example of the chainabilty of SQL

    Now in theory you could do the same with REST?

    PUT /database/products/*/Price
    where: {GET /database/products/*/ID
    where: ID ….

    Obviously a standard would be required… but because the VERBs, are basically equivalent to SQL verbs i.e. INSERT/POST, UPDATE/PUT, DELETE/DELETE, SELECT/GET you must be able to do it in theory.

  6. Mark Baker

    Alex – with REST you might address that scenario by exchanging a catalogue document that included all the products and the prices. Then the client would transform the document locally and PUT it back to the server. One URI, one GET, one PUT. Doing fine-grained tweaking of the state of multiple resources (as that UPDATE does) over a network is going to be cumbersome.

    I don’t think “RESTQL” is needed, as I understand you to explain it. I think the catalogue solution is a reasonable one, but architecturally very very different since the client does all the hard work of calculating the 10% price raise, etc..

  7. Richard Cyganiak

    Mark, you said: “I would then like to see the Semantic Web activity develop an RDF based forms language which could be used for exchanging query *parameters*, rather than full blown queries.”

    I fully agree with you here, this is an important missing piece in the puzzle, and for the open web such a language could have greater long-term impact than SPARQL.

    That said, HTTP bindings for SPARQL (both query and update) are still useful (even though not game changers). They are not the answer to everything, but that’s no reason for not doing them.

    I take it you would say that if I *need* to do “fine-grained tweaking of the state of multiple resources”, then I better keep it off port 80, right?

    I will not push the httpRange-14 point — I still disagree strongly with your position, especially given TimBL’s long-standing insistence that when you GET back a representation from a URI, then the URI identifies a document not a person. But as we all know that’s a thorny issue. I’ll try to argue it properly in a later blog post.

  8. Mark Baker

    Great, I’m glad we agree on the need for forms in RDF, Richard. I agree about the relative importance too.

    “Fine-grained tweaking of resources” *could* definitely be done over port 80. It would just be very chatty, and so the performance wouldn’t be great, but it would be Web-friendly because it’s using HTTP semantics. What wouldn’t be would be to do the equivalent of sending the SQL UPDATE command over port 80; the performance would be much better, but it would be a violation of HTTP semantics; the same way that SOAP (commonly) tunnels over HTTP.

    I’m content to drop the httpRange-14 issue; the less time I spend thinking about that, the happier I am 8-)

Leave a Reply

Your email address will not be published. Required fields are marked *