Raw

it's a httpRange-14 thing...

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.