Tag Archives: sparql

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 del.icio.us 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.

SPARQL; useful, but not a game-changer

23 Replies

Not that anyone would ever mistake me for a query language guru, but that’s really part of the problem; I’m not a query language guru, because I’m a Web guru, and to a certain extent those two roles are incompatible.

The Web doesn’t do generic query, and it’s a better large scale distributed computing platform as a result. The cost of satisfying an arbitrary query is too large for most publishers to absorb, as they do when they internalize the cost of operating a public Web server and answer GET requests for free.

The Web does per-resource query, which is a far more tightly constrained form of query, if you can even call it that. It makes use of hypermedia to drive an application to the results of a query without the client needing to perform an explicit query. Think of a Facade in front of an actual query processor, where the user provides the arguments for the query, but has no visibility into the actual query being performed. FWIW, this isn’t an unfamiliar way of doing things, as it’s how millions of developers use SQL when authoring Web apps; a user enters “30000” in a form field, hits submit, and then some back-end CGI invokes “select name, salary from emp_sal where salary > 30000”.

I’m confident that SPARQL will be used primarily the same way SQL is used today, and that you won’t see many public SPARQL endpoints on the Web, just as you don’t see many SQL endpoints on the Web. There’s nothing wrong with that of course, but I think it’s important to keep our expectations in check; SPARQL is likely not going to enable new kinds of applications, nor help much with multi-agency data integration, nor do much else that doesn’t involve helping us with our triples behind the scenes.

Groove gets a REST based Web services interface?

Leave a reply

Jon Udell writes that Groove has a REST interface, which peaked my interest. We’re discussing it over on rest-discuss.

I’m very encouraged to hear about REST being considered a cool and useful thing, and thank Jon for pushing that position. But (you knew this was coming, didn’t you? 8-) it doesn’t sound like Groove has it quite right. The bit of Jon’s article that suggested this to me was this;

It’s all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete.

It is true that a pre-defined set of small methods will help the system immensely, because coordination costs are lowered, and visibility is increased to firewall administrators (at least when the specification of its semantics are specified in the open, or just standardized). But not every set of fixed methods means you have a RESTful interface. As I described on rest-discuss, the uniform interface constraint also has something to say about which methods you use. Specifically, it says that any method you use must be usable on all resources/objects/services/whatever. Like GET, PUT, POST, DELETE, LOCK, MOVE, COPY, etc..

It doesn’t sound like this would be that big a change for Groove if they’ve already got a CRUD interface, but the benefit is that you get all of HTTP’s other features and deployed support (e.g. Akamai) for free, plus any future extensions. RFC 2616 isn’t 420K in size for nothing, and you’re not going to ever be able to adequately replace it with a 5K WSDL file.

So this is quite encouraging, but let’s try to nip the “REST interface = any limited set of methods” misconception in the bud before it gets too wide spread.