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.

Short version : An RDF Affordance is a resource description which gives a client all the information it needs to perform an action.

see RdfAffordances and AffordanceVocabulary.

My last post about what a Data Web Browser might look like led to some fertile discussion on G+. Essentially Mike Amundsen neatly reframed the question to being one about affordances, pointing to a bit of related prior work by him on Hypermedia Types.

We hold this truth to be self-evident, that presented with a simple application scenario a Web Architect will abstract it into a form that will take decades to implement.

Only joking...

Web Intents and Actions

I was initially thinking only in terms of an RDF-oriented browser (plugin/service) but it does make sense to stand back and look at the bigger picture. For starters, while RDF is ideal for describing stuff like service characteristics, there's no compelling reason to limit the data that's being manipulated to RDF. With that door open, there's an immediate tie-in with Web Intents, a JSON/Javascript way of describing/implementing generic interactions like share, edit, view, pick etc. (As it happens I added a Web Intents repository to my todo list a few weeks ago, the idea being to store the descriptions as RDF, providing a minimal API for using them in browsers as others have described - nice bit of serendipitous tie-in).

Tantek has spotted the potential around intents and in Web Actions: Identifying A New Building Block For The Web looks at common features across existing systems like Blog this, Digg, Read later, Follow, Like, Share, Tweet, +1 (he uses "Actions" instead of "Intents" for essentially the same idea).

We hold this truth to be self-evident, that presented with the potential for open-ended innovation a Microformats Geek will start paving cowpaths.

Again, joking...

On the Wiki - RdfAffordances - Mike has brought the abstraction back down to ground with some more detail of RDF-oriented actions, and with a view to hacking an implementation (on my virgin node.js installation) I've started a vocabulary - AffordanceVocabulary - this may change fairly soon, apparently Michael Hausenblas has done a vocab in this area, that'll get precedence if there's overlap/conflict.

We hold this truth to be self-evident, that offered a simple application scenario a Semantic Web Geek will always create a vocabulary that obscures the purpose of the application and that no-one will ever use.

Not entirely joking...

There is one high-level abstraction I've noted on that vocab page that is probably useful. There's a natural boundary between affordances that are essentially just HTTP (e.g. click through link, replace a page) and those which require more complex interations. For now at least I'm calling the former Actions (let me know if there's a better word that doesn't clash with Tantek's usage) - they are around the scope of Mike's Hypermedia Types and the latter Intents - around the scope of Web Intents.

Comments on G+

Some interesting survey results have just been published about APIs: the good, the bad and the pains. I commented about this on G+ and the discussion there got on to Atom. Some interesting points made, including the likelihood that we're stuck with snowflake APIs (every one is different) for the foreseeable future. I think it was Bill de hÓra who had a post years ago (can't find it now) about the N x N problem of diverse APIs (/models/formats). Essentially if you've got N different APIs then to connect them all you need N x N different translators. But it's also worth noting that this can be reduced to 2 x N if you have mappings to a common format/model. I reckon recent history has shown that formats are secondary, assuming certain boxes are ticked (see below). Regarding the model - there is a well-known, Web-friendly one. So here I'll simply point to ConverterToRDF and ConverterFromRDF.

In the G+ discussion Bill referred to an old blog post of his, Magnificent Seven - the value of Atom. In it he highlights the 7 'primitives' that Atom (format and protocol) uses and that he suggests should be used in any carrier format. I'm inclined to agree, if you are creating an API, tick these boxes, repeated here without Atom-specificity:

1. ID - a globally unique identifier for the chunk of data, ideally this should be a HTTP URL
2. Link - as above, it's rare that a separate ID and URL are needed
3. Updated - the most recent change, invaluable for keeping things in sync
4. Extension rules (mustIgnore, foreign markup) - anything the parser doesn't understand, it simply ignores. This allows other people to reuse and extend the format in a compatible fashion.
5. Date construct rules - using a standard date format is basic politeness
6. Content encoding rules - generally follow the rules for the media type you're using, and if there's textual content use an existing standard format (XHTML is good). Rule of thumb: UTF-8.
7. Unordered elements - insisting on order in the structure is (or at least should be) unnecessary, accessing things by name is more reliable