« Python development: UserDict as object scaffolding | Main | RDF hacking for fun and profit »

Representing HTTPLR exchanges in RDF

In the HTTPLR protocol, there are a few resources of interest that let us reason about a message exchange:

  • The URL of the message to be downloaded or uploaded
  • The URL of the exchange
  • the current state of the exchange
  • The authentication mechanism (digest, basic)

Outside the protocol proper, we'll also be interested in the following:

  • A pointer to the 'local location' of the message
  • The media type of the message

So here's the data in RDF/XML format:

    <rdf:RDF
        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:httplr="http://purl.oclc.org/httplr/"
        xmlns:dc="http://purl.org/dc/elements/1.1/">
      <httplr:message rdf:about="http://www.dehora.net/test/httplr/sub1/msg1.xml" >
        <httplr:exchange rdf:resource="http://www.dehora.net/test/httplr/sub1/msg1.xml?exchange"/>
        <httplr:state rdf:resource="http://purl.oclc.org/httplr/state/created/"/>
        <httplr:location>file://c:/temp/msg1.xml</httplr:location>
        <httplr:auth>digest</httplr:auth>
        <dc:format>application/atom+xml</dc:format>
      </httplr:message>
    </rdf:RDF>


And as a graph:

httplr_rdf_1.png


It turned out to be simpler than I thought to represent. As ever the XML isn't pretty, but the arrangement of information is clean. It does raise some questions that I don't have answers for:

  • Should this use a different property for media types? Actually, is there a vocabulary for media types? [update: Morten Frederiksen points out that DC is typically used to spec media types. Example changed.]
  • What about authentication vocabularies?
  • Should the current state be a property of the message URL or the exchange URL? Both?


Why is this useful? Well there are a few reasons:

  • State Engines: that RDF graph has enough information so it can used by a crashed agent after a restart to continue an exchange. Notably, it could be passed amongst HTTPLR-aware nodes and they could pick up the exchange with no fuss*. Dare I say it, but that's pretty cool.
  • Administration, administration, administration; We can build management tools around HTTPLR message exchanges without requiring the equivalent of WSDM or JMX. It's a no-brainer to stuff this data into an Atom feed.
  • Extensbility: I can keep adding properties to this graph without breaking existing code ** or worrying about defining yet another extension mechanism. This is real extensiblity folks, not the modular seperation of concerns stuff you get in RSS and Atom.

Probably, an example like this will go into the next HTTPLR draft as a non-normative appendix.


* This is the kind of thing that REST people are banging on about with regard to self-description, statelessness, and also why uniform interfaces matter. A WS approach would have to expose specific methods to support this. In REST we can carry on with uniform methods.

** And This is the kind of thing that RDF people are banging on about with regard to partial understanding and extensiblity. It's also why RDF doesn't need mU or mI.


April 2, 2005 05:06 PM

Comments

Morten Frederiksen
(April 2, 2005 07:50 PM #)

Bill,

For media types, the Dublin Core is most often used. There are, as always, more than one way to do it, the most popular way is the simple property dc:format, that could replace your httplr:mime (which should have application/atom+xml, not application/xml+atom, methinks).

As for the state of a message, it seems it might be useful to consider that as a type of message, thus using rdf:type instead. In any case, I think it's a "property" of the message.

Robert Sayre
(April 2, 2005 11:19 PM #)

I was just thinking about this yesterday, I swear. I was thinking that silly service description document in APP could be something like this. What would a negotiated resource look like?

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1525