« HTML elements with class attributes | Main | SemanticIntegration 101: something even an AI grad would know »

HTTP dark matter

It would help to have RDF available to us when defining protocol extensions. Mark Baker.

I used to say that about SOAP ;)

Protocols typically work with a predicate(aka header)/value tuple. If you've ever worked with triples though, you quickly realize the problem with a double; it's not everything you need to know. In this case, you don't know the subject; what has a media type, what is of length 342 bytes, what is identified by this URI? Most protocols, therefore, define their subjects not in the message, but in the specification. For example, here are some possible subjects of an HTTP message. This is fine when you're predefining headers in a spec; there's still a self-descriptive path from bits-on-the-wire to what-is-the-subject-of-this-header. But for extension headers, it doesn't cut it; you've got a predicate (the header name) and an object (the header value), but no subject.

I'm curious to see where Mark's going with this. Like Mark I have a related issue that I can't discuss for various reasons.

In the HTTP case, many of the header tuples are metadata about the representations. But, representations are dark matter - they aren't first class objects on the web since they don't have URIs. Ironically, representations are about as real a thing as you can get on the web (they'll come into your computer if you let them, resources never do that). This 'issue' pops up in RDF circles from time to time. Yet RDF in itself is limited in how it can help with the unamed parts of web architecture, or anything that doesn't have a URI moniker.

February 21, 2004 08:52 PM


Trackback Pings

TrackBack URL for this entry: