Raw

[there's loads of background before I get to what I mean by the title :) ]

An interesting mailing list thread on Web API design (found via twitter) led me to open the Linked Data API material in another browser tab. Mike Amundsen's points re. hypermedia-oriented APIs vs. URI-structured APIs are interesting in this light, and led me to open his hypermedia book again.

Now the RDF Affordances stuff has a really un-catchy name. I've been using "affordances" partly because it's accurate (thanks Mike), but also to be clear that while there is significant overlap with the Web Intents material, it's not quite the same. I've been thinking about RDF Affordances in a sense that (done right) they should be a superset of Web Intents, primarily because RDF is 1. a description language (so an Intent can be described) and 2. seriously linky (has potential to do the wiring of Web intents).

In Mike's book I happened to notice a quote from Roy T. Fielding I'd missed before (being a preface skipper) which has set me re-evaluating things :

"Hypermedia is defined by the presence of application control information embedded within, or as a layer above, the presentation of information."

Ok, so what does RDF look like from this pov? Well, before you get anywhere near presentation there's the representation syntax to consider. RDFa is definitely a hypermedia format, being HTML. The linked data is hooked to the application controls of (clickable) links. But what of RDF/XML and sweet little Turtle? Yes, this is the idea of RDF Affordances, but assuming a blank slate locally...I Google "RDF Hypermedia". Top hit is a blog post from Mike: API for RDF? don't do it! Heh. [A little aside - note that in itself JSON is not a hypermedia format]

While I disagree with the don't, because things on the Web are rarely exclusive-or (and if pressed I bet Mike would concede this :) the point is valid. The post is short and worth reading, the conclusion being, for a variety of reasons: [RDF should] ...explicitly support hypermedia within the message itself.

I'm quite amused at the little path I've just followed - it's a certainty Mike's expressed this to me before. But I'm often rather slow...

This all flips right back to RDF Affordances, but (more clearly in my mind) begging the question of through what mechanism RDF should support hypermedia. Taking Roy's statement in this context there are a few layers to consider: the "raw" message; the presentation layer; a control layer above presentation. Some things do come for free: named graphs provide an association between a message and a resource (the name is its URL), this is effectively what you get out of the box even if you treat e.g. a Turtle message as text/plain. But the notion of an RDF graph is tied in.

The thing is, d ocuments have a real-world counterpart, the printed page. Unlike documents, data - especially graph-shaped data - doesn't really have a "default" presentation. Documents can be realised on a machine pretty easily as the metaphor is embedded deep in our approach to computers (the Desktop metaphor being a consequence of this). But there isn't really a real-world counterpart to hypertext. (Wikipedia dates the history of hypertext back to the annotation style of the Talmud, with a more modern example being Borges' 1941 hypertext novel " The Garden of Forking Paths").

However, while there aren't many concrete pre-computer precedents for hypertext, in use it seems very natural. Which shouldn't be a surpise, if you step back from the printed text of documents, conceptually they regularly hop out to annotation and frequently leap out of serial narrative flow to total tangents. Any remotely interesting conversation could be seen as seriously twisty network (graph) of concepts, changing over time. In this light what we're looking at isn't just vocalizations, text or data, it's information/knowledge. On the Web it's hypertext (HTML) and increasingly hyperdata (RDF). While data as an expression of information/knowledge doesn't really have a default presentation on machines, it too can certainly be flattened to text-based documents with the added dimension of hyperlinks.

Whether you take the perspective of binary digits or interlinked concepts the phrase "Web of Data" does describe a superset of the "Web of of Documents" with which we are more familiar. The text in documents is a representation of real-world concepts, and Web-based data is another kind of knowledge representation. Where the parts of speech (nouns, verbs etc) with grammar provide the first, the parts of the Web (resources, typed representations) with grammar (RDF) provide the latter. For a document-hardened Web developer there is a conceptual shift required (as I called it in my latest little Introduction to RDF) to use URLs as names of things (people, places, products, concepts) not just documents.

So I've waffled on for a few more paragraphs without really addressing what's actually needed for RDF Hypermedia (or explaining this post's title). From a technical standpoint we do already have the makings of a hypermedia interpretation of RDF. For example, wherever a resource appears it can be treated as a link, and like HTML in a browser the default affordance is to "follow your nose" (i.e. do a HTTP GET and render what comes back). This is already a de facto convention for dealing with RDF in HTML, see for example what happens with a link to http://dbpedia.org/resource/Berlin . This has a nice parallel in SPARQL's DESCRIBE, and more generally SPARQL seems a good route to decribing [sic] the affordances RDF should support. So instead of (/as well as) using conventions for encoding the SPARQL constructs [lower case] in URIs as the linked data API does (with appropriate associations for the various HTTP methods) it seems reasonable to explore what you get if you wrap these constructs into User Agent actions.

I've personally got a couple of projects on the go into which I want to insert some of this exploration ( Scute, which is mostly an RDF/SPARQL editor and Manuel, a semweb DSL - neither of which are usable yet, btw). I think they'll offer reasonable testbed environments for a fairly rich (editing) GUI and command-line UI. Ultimately the RDF Hypermedia sort of thing should (/will) become integrated with exisiting Web tools, i.e. the browser. But for me at least it makes sense to approach them away from the browser, thinking in terms of the abstraction I came up with for a generalized Web Agent. (If you've seen any of my periodic rants about the tyranny of the browser you'll know why). I'm delighted to see Mike is also planning on exploring the same general area - spending a year or so on afforded agents . Heh, I reckon now's probably a good time to get moving with this stuff, before it becomes another Hot Topic for PhDs...

Oh yeah, " RDF Hypermedia is Art"? Right, well I've already suggested hypertext/hypermedia has a real-world counterpart in our representation of knowledge in speech and text. Where else do we see representation of twisty graphs of concepts? Taking Wikipedia's definition: Art is the product or process of deliberately arranging items (often with symbolic significance) in a way that influences and affects one or more of the senses, emotions, and intellect. Whatever the medium, the influence it has depends on its ability to communicate, and what it's communicating is relationships between symbols. If that's not knowledge representation I don't know what is. Arty folks often talk about a person's individual experience or interaction with a work of art. Another example of interlinked symbols and interaction? RDF Hypermedia. Quod erat demonstrandum and sieze the goldfish. For the benefit of folks who might point out the non-real, make believe aspects of art, I'll assert the fact "the Mona Lisa is an assertion of a set of facts". You don't have to believe that assertion.

Comments to G+ please.