Ironick

The Battle Between the Two Gods of Hypermedia: The Reader and The Writer

[This is a continuation of a discussion of the “shape of the web” that started in Twitter and then moved to Richard Veryard’s blog: What shape is the Internet.]

Glad we agree on the 1st point. On the 2nd point, I'm not sure Tim's vision of hypermedia was all that "innocent".

I think both Tim Berners-Lee, and Ted Nelson before him, understood that "hypermedia" implied not only following links to go from media to media, but also that such media would be (mis)interpreted, copied, rearranged, (mis)used, mashed up, etc.

In a speech from 2005, Tim presents a slide entitled "The two gods of literature", which goes as follows:

[begin slide]

according to Ted Nelson

* The Writer

* The Reader

A common benefit, overlap of need.--but a battle.

[end slide]

A bit cryptic, so I searched(!) for any discussion of the two gods by Ted. The only discussion that I could find is in this BBC interview: “I think of it as a form of writing - and writing is essentially what I would call a two-God system, because God the author proposes and God the reader disposes. The author is completely free to do anything on the page that he likes.” (I would have said “to the page”.)

I can’t be sure, but I think Ted (and Tim perhaps to a lesser degree) WERE plugged into the more general concept of intertextuality: “the shaping of texts' meanings by other texts. It can refer to an author’s borrowing and transformation of a prior text or to a reader’s referencing of one text in reading another.” ( ). For a good discussion of intertextuality (if you like semiotics and literary theory), see this article.

What I think both are alluding to with the metaphor of “two gods”, the reader and the writer, is the idea that “hypertextuality increases intertextuality”: hypertext increases the (mis)use of text (really all media) by users (readers) in ways unforeseen (and often unapproved) by producers (authors). So I think both Tim and Ted are completely unsurprised (but not unconcerned) with how the web of hypermedia is (mis)used in ever more sophisticated ways. It is not just any battle, it is a Red Queen arms race among readers and writers!

The web of linked media enables easier exploration and exploitation of that media.

[The very movement of this discussion from twitter to blog to blog is a perfect example of the intertextual battle. As is my use of a link shortening service…]

Epiphany: Replace HATEOAS With "Hypermedia Describes Protocols"

As a few of my friends know, I live for epiphanies. I love to connect concepts. So I'm really happy to be having one now (it's been a while as regular readers of my blog -- if any remain -- can tell).

For a LONG time, I've been talking about how all interfaces can be defined in terms of IFaPs (Identifiers, Formats, and Protocols). My canonical example of an interface composed of IFaPs is of course the Web: URL (I), HTML (F), and HTTP (P). All three intersect in a particular instance of HTML, say my blog's home page. The HTML for my blog's home page is filled with URLs, HTML tags, and even HTTP "verbs" (though these are quite rare, mostly in an HTML form or embedded JavaScript).

Then along came REST and with it the concept of HATEOAS: Hypermedia As The Engine of Application State. And everyone, myself included, spent a lot of time trying to grok it and explain it to others. We're still trying. One way I try to explain it is by highlighting that HATEOAS requires that each server response must contain not only the requested data -- but also control information (in the forms of specially tagged URLs) describing the next set of permitted interactions with the server. It is this additional control information (at a bare minimum just some links to more data) that turns mere media into hypermedia.

Now along comes Jim Webber with a much better (dare I say brilliant) way of explaining HATEOAS and hypermedia: "Hypermedia Describes Protocols!" (See slide 26.) At first this might seem counterintuitive, since I said that HTTP is the Protocol and HTML is the Format in the WWW. But URLs, HTML, and HTTP are just generic description languages for describing domain-specific identifiers, formats, and protocols. Thus, think of a web of specific HTML pages as a domain-specific protocol. Jim Webber uses the example of ordering a Starbuck's coffee. (What's important is that each hypermedia DSL is composed using the generic languages of URL, HTML, and HTTP.)

This notion of bringing together identifiers, formats and verbs to describe a protocol is not new. One of the best descriptions of this was in the WS-BPEL 1.1 spec:

In thinking about the data handling aspects of business protocols it is instructive to consider the analogy with network communication protocols. Network protocols define the shape and content of the protocol envelopes that flow on the wire, and the protocol behavior they describe is driven solely by the data in these envelopes. In other words, there is a clear physical separation between protocol-relevant data and "payload" data. The separation is far less clear cut in business protocols because the protocol-relevant data tends to be embedded in other application data.

So if WS-BPEL was already thinking about mixing protocol data with "payload" data, what's so new about HATEOAS? The fundamental difference is that WS-BPEL is based on the concept of providing an entire static protocol description up front once and for all -- and providing it out of band. But HATEOAS is based on the notion of progressive description (don't bother Googling the term, I coined it; and not to be confused with progressive disclosure). More and more of the description of the protocol is provided to the client (in band in the protocol itself) as the client executes its part of the protocol. I guess another good term might be JIT Protocol Description (Just In Time). Another good term might be "self-describing protocol". So now when explaining HATEOAS, instead of saying "each server response must contain control information" (huh?), I can say "each server response progressively self-describes the current protocol."

Now there are pros and cons to static/complete vs dynamic/progressive protocol descriptions. How can I program a client to execute its part of a protocol if I don't have a full description of it up front? But if I encode the complete static description of the protocol into my client up front, how can I change the protocol dynamically?

Love to hear others' thoughts. I'm going to think about this some more. That's why I love epiphanies -- they make you think about things in new ways.

The Importance of Play in Web 2.0

I LOVED the New York Times OpEd piece " The Fakebook Generation "! Why? Not because it signaled a "backlash", but because it highlighted an essential element driving the popularity of the most successful Web 2.0 sites: entertainment! Here's what Alice Mathias nailed about Facebook:

Facebook did not become popular because it was a functional tool — after all, most college students live in close quarters with the majority of their Facebook friends and have no need for social networking. Instead, we log into the Web site because it’s entertaining to watch a constantly evolving narrative starring the other people in the library. [emphasis added]

All the most successful Web 2.0 sites are fun! Whether its Wikipedia having entries about your favorite hobbies and TV shows or its Facebook feeding you trivia about your friends' activities, there is a healthy entertainment factor in what can also be used for a specific productive purpose.

So the root challenge is not how to keep social networks separate so the oldsters don't harsh the mellow of the youngsters (although that may be a derivative challenge), it's how to make sure that both new and experienced users of Facebook of any age (or any social networking site or any Web 2.0 site for that matter) continue to find Facebook entertaining as well as useful . When a Web 2.0 site feels like "work" to someone, she will at worst stop using it entirely, or at best will minimize her use of it -- to just do the work she needs it to do. Either way, this will kill or at least dramatically limit the "network effect" of the site.

Most people, especially those trying to harness Web 2.0 for enterprise use, forget that "play" was highlighted by Tim O'Reilly as one of the essential elements of Web 2.0:




So just as the web itself is based of the strength of weak ties , social networking sites specifically and Web 2.0 generally are based on the productivity of fun ties . Lose too much of the fun or entertainment value of these sites by trying to make them too productive, and you'll kill the goose that lays the golden eggs.

I don't have time to go into it here and now, but I think all our talk about "consumerization of IT", "mass amateurization", and "democratizing innovation", we miss the unifying theme of all these trends: the advantages of blurring of the line between play (entertainment) and work.

Pipes: A Tool For Remixing the Web

                 

Good presentation about Yahoo Pipes by the Pipes Team -- speaking at Google no less. Talks about new features and future features. Below is the blurb about the video: Google Tech Talks April 2, 2007 ABSTRACT Pipes is a service platform for processing well-structured data such as RSS, Atom and RDF feeds in a Web-based visual programming environment. Developers can use Pipes to combine data sources and user input into mashups without having to write code. These mashups, analogous in some ways to Unix pipes, can power badges on personal publishing sites, provide core functionality for Web applications, or serve as reusable components within the Pipes platform itself. Here's what Tim O'Reilly says about pipes: "Yahoo!'s new Pipes service is a milestone in the history of the internet. It's a service that generalizes the idea of the mashup, providing a drag and drop editor that allows you to connect internet data sources, process them, and redirect the output." Speakers: Pasha Sadri & Jonathan Trevor of Yahoo!

Use URIs in Representations: A So-Called Principle

There are two reasons I'm not going to get into the dogma debate that Jonathan Marsh recently started ("Does your dogma fit on the side of a bus?"): (1) one person's dogma is another person's self-evident truths (as in "we hold these truths to be self-evident"); and (2) there's always dogma on both sides of the argument.

What I am going to get into is whether people who design representations to be returned by web resources should emphasize the use of URIs within those representations. Here is what I said, and what Jonathan said in response:

Nowhere in the vast multitude of WS-* specifications or the articles or papers describing them is there any imperative or even any emphasis that a Web Service should return an XML document that is populated references to other Web resources, ie URIs.  But it is a fundamental principle of the Web that good Web resources don't "dead end" the Web; instead, they return representations filled with URIs that link to other Web resources.

First of all, I'm wary of even dignifying this so-called "principle" with that label.

I'm not going to argue whether the principle is a good one, because I'd probably end up being called dogmatic again. [joke] Instead, I just want to clearly establish that use URIs in representations is a core principle of the web. To do so, I'll simply cite a few passages from the Architecture of the World Wide Web, Volume One.

A defining characteristic of the Web is that it allows embedded references to other resources via URIs.

I suppose I could stop there. But just to be sure I get the point across, I'll continue.

Formats that allow content authors to use URIs instead of local identifiers promote the network effect: the value of these formats grows with the size of the deployed Web.

Data formats that do not allow content authors to create hypertext links lead to the creation of "terminal nodes" on the Web.

A specification SHOULD allow Web-wide linking, not just internal document linking.

For resources that are generated on demand, machine generation of URIs is common. For resources that might usefully be bookmarked for later perusal, or shared with others, server managers should avoid needlessly restricting the reusability of such URIs.

I don't mind having a healthy debate about the pros and cons of weakening or strengthening the key architectural principles of the Web in order to better support A2A interaction, but I do feel dismayed when someone of Jonathan's caliber is wary of even dignifying this so-called "principle" with that label. Given the above quotes, how can anyone question whether use URIs in representations is a core principle of the Web?

I think our daily use of the term "Web" has caused many of us to forget that it is a web of something. Just as a spider's web is a web of spider-silk strands, the World Wide Web is a web of URIs (a defining characteristic of the Web is that it allows embedded references to other resources via URIs). How can it continue to grow as a web of URIs unless new representations are filled with them?

Web 2.0 ... The Machine is Us/ing Us

Via David McCoy. A beautifully evocative and moving video about the evolution of the Web:

I read the title as "The Machine is Us Using Us" or as I like to think of it: "The Web Mediates Us Using Us". "We'll need to rethink a few things..." Indeed.

IE is in the minority

Just noticed that my Sitemeter browser share report shows that less than 50% of the browsers that accessed my blog were some verison of IE. Notice the 2% IE 7, which means my "readership" is among the bleeding edge. I wonder if IE 7 will tip the balance back in favor of IE. I doubt it.

Berners-Lee's Web Is Quine's Web of Beliefs

Nancy White recently commented on my Ideas Do Have URIs posting:

...I do think ideas are also network like. A url may grab on to the edge of that idea, but it the network of thought that is expressed by the collection of urls that gets closer to capturing the "idea" itself as it evolves from a conception coming from one person, to an idea that has been shaped by a collection of people.

I thought my response to her insightful observation was important enough to post as a follow up entry instead of a comment.

This concept of an idea as being a network of thought that is shaped by a collection of people was popularized by WV Quine in Two Dogmas of Empiricism. He called it, presciently, the web of beliefs:

The totality of our so-called knowledge or beliefs, from the most casual matters of geography and history to the profoundest laws of atomic physics or even of pure mathematics and logic, is a man-made fabric which impinges on experience only along the edges. Or, to change the figure, total science is like a field of force whose boundary conditions are experience. A conflict with experience at the periphery occasions readjustments in the interior of the field. Truth values have to be redistributed over some of our statements. Re-evaluation of some statements entails re-evaluation of others, because of their logical interconnections -- the logical laws being in turn simply certain further statements of the system, certain further elements of the field. Having re-evaluated one statement we must re-evaluate some others, whether they be statements logically connected with the first or whether they be the statements of logical connections themselves. But the total field is so undetermined by its boundary conditions, experience, that there is much latitude of choice as to what statements to re-evaluate in the light of any single contrary experience. No particular experiences are linked with any particular statements in the interior of the field, except indirectly through considerations of equilibrium affecting the field as a whole.

The World Wide Web is a web of beliefs connected by URIs.

Ideas DO Have URIs

Saw this interesting post recently (while searching for ["doesn't have a URL"]):

I was attracted by an idea that emerged... "The idea doesn't have a URL." In other words, a tag can somewhat represent and [sic] idea. A URL can point to one slice or view of an idea. But it cannot be captured with either a tag or idea [sic? I think URL was meant here].

An idea is no more or less nameable via URIs and describable via representations than it is nameable by words and describable by sentences.

Technorati Tags     www,URI

The Core Design Components of the Web: IFaPs

From the Architecture of the World Wide Web, Volume One:

In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web. They are identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space.

Every time I reread the AWWW, I glean new insight. What this passage says to me is that the core design components of the Web are identifiers, formats, and protocols: IFaPs.

Technorati Tags     IFaPs,www,w3c