I’ve been doing some work with extensible protocol envelopes recently, with a very strong emphasis on size, processing efficiency, extensibility, and evolvability. On a lark, since I’ve been thinking about it for a few years, I thought I’d try to toss in the use of RDF, just to see how far I could go with it. As it turns out, pretty far.
I’d like to be able to talk more about this now, but can’t; it’ll have to wait, because I’m being paid to do it by somebody with competitors 8-). But I can certainly pass along one rather enlightening observation that I made …
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.
It would help to have RDF available to us when defining protocol extensions.
no comment until now