Raw

it's a httpRange-14 thing...

About a week ago Simon St.Laurent posted a comment on Facebook in a thread about httpRange-14. Alas I can't find Simon's original comment, but the gist was more or less: it's a bad idea to use HTTP URIs for anything that isn't directly associated with the HTTP protocol, e.g. as names for real-word things, concepts, "non-Information Resources" etc. I've been mulling over this a bit.

I don't disagree with him that it might be conceptually more elegant to have a different namespace for identifiers of things rather than identifiers of Web documents (namespaces in the broad sense, probably talking URI schemes in practice). You can still describe and reason about things in a model like RDF using non-HTTP URNs. But for the identifiers to be useful on a global scale, you need a discovery mechanism. HTTP with hypermedia offers this. But how would you mesh the 'thing' namespace with the 'HTTP' namespace? Ok, you could use HTTP to access RDF documents that link to other documents. Mike Amundsen might disagree a little about the extent of this, but I'd suggest any RDF is inherently a kind of hypermedia simply by supporting HTTP URIs. As soon as you see the http:// prefix, the methods are implicitly available on top (they are made explicit to some extent with RDFa etc).

Ok, so to find about my dog Basil you'd want to try and find statements that match a template like ?doc a:foaf:Document; foaf:primaryTopic <urn:basil> . You're working with an indirection between real-world things and document space. A map of identifiers ThingSpace <-> DocSpace. But this is in effect what we've got when we use HTTP URIs for things, the protocol doesn't support resolving them to things any more than a URN scheme URI over HTTP would resolve to anything. The net result is the same as in what Jeni Tennison recently called the web of data view. But by allowing HTTP URIs to identify things, we can kludge past needing a separate space for thing identifiers and explicit namespace map. Yes, there is a downside - the httpRange-14 permathread - but leaving aside the philosophical niceties the concrete problem is just a matter of choosing an appropriate mechanical convention. This seems is a small price to pay given the way it simplifies the publication of linked data. The linked data cloud is progress! Once again I refer you to Dan Connolly's question: Are there parts of traditional logic and databases that, if we set them aside, will result in viral growth of the Semantic Web? By the same token we might ask, are there parts of Web best practices that it might be worth setting aside, you know, as a bootstrap, like just for a little while... (cf. schema.org vs. distributed vocabularies).

PS. Simon's blogged his thoughts on this : Original sin and the ruin of HTTP URIs, and although much of that sounds critical of semweb efforts (we have been talking at cross-purpose a little) there is significant common ground on the G+ thread, around the notion that Linked Data HTTP URIs should always resolve to something useful over HTTP, i.e. that HTTP URIs for things should make sense on the Web as well as in the triplestore, to the extent that you can put them in a browser's address bar and not expect an error.

Comments to G+ please

Back in 2002, the following issue was put before the TAG:

httpRange-14: What is the range of the HTTP dereference function?

TBL's argument the HTTP URIs (without "#") should be understood as referring to documents, not cars.

By 2005 a resolution was accepted. If a GET is done and the thing being referred to isn't a document, then a 303 redirect should be used to provide something which is a document. As these things go, this is quite an elegant solution. Additionally it's accepted practice to use #-URIs for things which aren't documents. However, both approaches have their problems, many of which are listed in Providing and discovering definitions of URIs.

But I liked the 303 approach, and did my share of grumbling when things like Microformats and OpenID appeared to conflate the notion of a person with their home page, using the same URI for both. Now schema.org conflates lots of different kinds of things with documents. So while I still believe the TAG resolution works well I personally, finally feel we have to take into account that people won't make this kind of distinction. Others have already argued for pragmatism around the issue - e.g. see linking things and common sense and Back to Basics with Linked Data and HTTP. However it's hard not to see a conflict when (e.g.) RDF says "http://example.org/fred is a person" and in effect HTTP says "http://example.org/fred is a HTML page". Not pretty. On the lod list I just had a go at a conceptual model that avoided such a conflict, but I suspect so far I've only managed to persuade Pat Hayes that I'm barmy. So I'll have another go here with these arguments:

1. (solid) : HTTP doesn't have a notion of a "complete" representation of a resource. A photo of a car could reasonably be served as a GIF or lossy-compressed JPG image. The difference here as far as HTTP is concerned is just in the media type expressed by the Content-Type header.

2. (adequate) : a resource may have representations reasonably served with very different media types. Here I'm thinking of, say, a text version of a photo of a car. It may sound clunky, but there are good precedents: an RDF version of My Home Page can vary widely in its information content from a HTML version of My Home Page. In the HTML format, we have img alt="text". In both cases the assertion is made by the publisher that in some sense the different version can act as a useful alternative.

3. (strong enough IMHO) : a description of a resource can be considered a representation of that resource. On list I suggested there was some isomorphism between a description and a thing. Pat didn't accept that at all, but did say "there can indeed be correspondences between the syntactic structure of a description and the aspects of reality it describes". I'd suggest that's near enough. Those correspondences could be said to make the description a representation in the same way a lossy-compressed version of an photo can still share the same URI as an uncompressed version. As long as an appropriate Content-Type is used.

Given these three, a HTTP URI can simultaneously be understood as referring to a document and a car.

I'd better mention the barmy part. If HTTP did support transfer of matter, then as far as the URI referencing is concerned, all you'd be looking at is another media type. The example I used on list was of my dog Sasha, and given the above I'd suggest you could have various different representations of diminishing fidolity: Sasha herself; Sasha's description in DNA; a photographic description of Sasha; an RDF description of Sasha; a HTML description of Sasha... As I put it on list: you can't squeeze a dog over the wire with HTTP, but that's just a limitation of the protocol.