Raw

I really enjoyed myself making Get Your Data Out! back in 2008 (how time flies) and recently wanted to apply myself to some fun projects to keep the black dog at bay. So I've made another geek-pop advocacy video called:

Can I Hack It?

a little celebration of Open Source

It's a public information broadcast, just under 4 minutes long, briefly describing what open source is, why it should be encouraged and introducing a bunch of open source applications. With a bouncy soundtrack to help stop you getting bored.

All the source and media files I used are here. Please feel free to rebroadcast, remix, etc.

I'm pretty sure I encountered this years ago (if there really was a time before the Web). If I was stuck on a desert island for a week or two I'd quite like a copy, I'm sure I'd learn something. Aside from the direct coding side of it, it looks like it would make a good testbed for evolutionary algorithms. A nice touch is that all the material below is provided as markup copy/paste ready for bloggers, kinda social engineering quasi-virus.

Corewar - An Introduction to Hostile Programming

Corewar is a game from the 1980's, played between computer programs written in Redcode, a language similar to assembly. The programmers design their battle programs to remove opponents from the memory of the MARS virtual computer by any means possible.

Some of the simpler techniques include blindly overwriting memory, searching for the opponent or spawning off new processes. These are commonly known as stone, scissors, paper after the popular playground game. Stone usually wins against scissors, scissors normally defeat paper, and paper mostly beats stone.

Here's an example of a typical Corewar program:

     org   wipe

     step  equ 5
     first equ bomb-10

bomb:mov.i #1,       -1

ptr: sub   #step,    #first
wipe:jmz.f ptr,      @ptr

     mov   bomb,     >ptr
     djn.f wipe,     {ptr-5

     end

This simple example of scissors once held a 20 point lead over it's rivals. The first instruction is never executed, it's the bomb used to overwrite opponents. The next two instructions form a loop which looks through memory for an opponent, and the final two instructions actually overwrite it.

Corewar is still going strong, and celebrated it's 25th anniversary in 2009. If you'd like to discover more about Corewar, here are the top resources:

What are your experiences with Corewar, have you ever had any success?

The memory palace, also known as the Method of loci or memory walk is a technique for remembering things. Basically you start by memorizing the physical layout of a place such as your own home. When you need to remember something, in your mind you put it somewhere in that place. To recall the thing, you look in the place. The trick apparently works well for things like memorizing lists. It was known by the Ancient Romans. It relies on the fact that we have fairly good spatial memory.

Many of the metaphors used around the Web reflect a spatial model: Netscape Navigator, Internet Explorer, the Information Superhighway. We do seem to be predisposed to think in this way: when talking about mathematical structures, the structure is conceptually a kind of map, comparable to the way we make maps of the physical world. With information retrieval on the Web it's quite hard not to think in terms of a library, not far removed from a physical library with books on shelves. Not to mention Files, Folders and Desktops.

So anyhow, the other day I was pondering whether there was something more around the memory palace idea that could be applied on the Web. Instead of putting a piece of information in a place in the mental model, HTTP PUT it in a place on the Web. I didn't get much further with this line of thought, you need the mental model of a familiar place to start. But another metaphor did occur to me.

What have the Romans ever done for us?

Well, the invention of concrete is usually attributed to them. It "...freed Roman construction from the restrictions of stone and brick material and allowed for revolutionary new designs in terms of both structural complexity and dimension.". Concrete clearly has had a role in the development of the modern city. There's a watchable old TED talk from Steve Johnson on the Web as a City. Concrete is made from aggregate, cement and water, not such a bad analogy to HTML marked-up text. You can mould it into whatever form you like. But what's lacking there is something corresponding to links.

So...how about reinforced concrete? Concrete on its own is good under compression but not extension, it needs something to tie it together if you want to make really big structures. The answer is to embed steel bars in it. Links as rebar, ok.

While this metaphor is a bit limited regarding the flexibility of the Web, it isn't bad for explaining the role of links to bind everything together. Given that links are data, the metaphor isn't bad at explaining how Web of Data relates to the Web of Documents. One is made of steel the other, concrete. Together they make a composite or hybrid material with properties that are greater than their sum of parts.

Comments to G+ please

Quantitative Filtering

Filtering is a core feature of information presentation on the Web. As an example, look at blogs. This post will visible for a while on this blog's front page, along with the other most recent posts. Essentially the page is defined by a filter (by date) applied to a large collection of material. Filters can work over many different axes, e.g. date, tag, author etc. They can be combined to provide faceted views of the information. Filters like this are fairly common on the Web, often seen combined with an ordering of the data for example: Sort By Price and Show 10 Items Per Page.

Many filters operate over a continuous variable (or one that can be mapped to a continuum), the date of posts being a good example. If you've got a continuous variable then a UI component that becomes available is the knob or slider. It's pretty straightforward to hook such a UI component up to a filter to apply to a backend store (in fact I rigged up a demo of doing this not long ago).

In the context of a blog there is quite a lot of data available that could be used for a knob-controlled filter. For example, most blogs contain a mix of long and short posts. Why not filter on word count? More nuanced things are possible nearby, say link count. Or something like readabilty. To make knobs or sliders user-friendly you probably wouldn't want to offer the viewer the actual numbers of word or links, rather a e.g. slider that had at its extremes Short ---|- Long.

Quantative Tagging

Sites like Amazon also exploit user-contributed data like rating (in reviews). But there's an awful lot more potential kinds of information available. To pick some at random: utility, creativity, authority, entertainment value (fun!). So someone comes along and sees a post with a set of sliders below it and sets those sliders at 4, 3, 2, 1. That data is passed back to the server. Ideally the server will store that data associated with the user in question, to allow the whole social query dimension. Or the value may simply be aggregated as numbers associated with the post.

When someone else arrives on the site they see, say, a default view of the most recent posts. But below are same controls again. They are interested in reading material that's useful and fun, but are less interested in the other factors. So they set the sliders at 5, 1, 1, 5 and click Search. They are instantly presented with posts that fit that profile. The user may want to save that profile so it's the default next time they visit.

What happens under the hood at view time is again something that could be quick & dirty less-than/greater-than filtering on the parameters, or something more sophisticated that derived the results from the "shape" of the settings, amplifying the descriptions previously given by their friends.

Taking the user-contributed data angle a step further, instead of having a predetermined set of controls, it wouldn't be hard (at least if you're using RDF under the hood :) to allow the users to define new sliders, just ask them for the axis over which the slider varies Foo...Bar. Working title, please change: Wiki Knobs.

Interstices

The applications for knobs like these are pretty open-ended. What I describe above is a typical-Web-site-oriented view of an idea my late wife Caroline suggested years ago, effectively an idea generation machine, working title Interstices. I'm not sure she was a big fan of the Surrealist movement per se, but she loved seeing surprising, apparently contradictory concepts combined in art. I vaguely remember (or have imagined :) her talking about it the context of a magazine advert for PCs, where the tower cases had Friesian cattle's black and white markings (anyone remember that?).

With Interstices you'd tag images with sliders as described above, arbitrary scales, say Hard...Soft, Natural...Artificial etc. But then rather than looking for matches, the system would offer you opposites, so the PC is Hard...Soft:1, Natural...Artificial:5 whereas the cow is maybe Hard...Soft:4, Natural...Artificial:1.

I said at the time it would be easy to build - still haven't got around to it. But I'm pretty sure at the time we were only thinking in terms of a little app one or two people might use. Imagine something like this supporting proper crowdsourcing, e.g. sliders attached to Flickr. That'd be cool.

Comments to G+ please

[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.

Bear with me, as usual I've not thought this through thoroughly (but I will quote myself a few times :)

There's been a flurry of commentary recently about the threat to the "Common Web" from things like Facebook, Google+ (e.g. see posts from John Battelle, Robert Scoble). There's also some fragmentation of the Web going on around "Apps" in Apple's mobile device sense. The main antidote proposed for this kind of thing in recent years has generally been to use non-silo'd, non-walled garden services.

But I'd argue that it's a more systematic problem, that switching service won't necessarily solve. Remember we already have an open distributed social network in the form of the blogosphere. Where is the advantage in Facebook, G+?

I'd argue that one of the main causes of this fragmentation is the tyranny of the browser. Sure, from a glass-half-full perspective the Web browser has evolved into a seriously versatile client-oriented Agent platform, with integrated processing (Javascript and/or plugins), UI facilities (HTML/DOM, tabs etc) and protocol support (the HTTP bits). But from a glass-half-empty perspective, look at how it gets used. Typically the Application is a given back-end system with some minimal, quasi-proprietary HTTP exposure with a proprietary front-end built from browser facilities. Can you use the Google Plus front-end you see in the browser and point it at Facebook?. Hell no. What integration is possible is generally done through (typically site-specific) APIs. From the company's point of view, it makes sense to do what they can to make their site as good as possible. From the user's point of view, the experience of a really sophisticated, tightly-integrated site (as Google's pushing for across its subsystems) can be much more satisfying. The cost is that the server and client components are tightly-coupled.

More generally, so much current technology is geared towards that one page you have open in the browser right now, it's like looking through a narrow pipe at the Web. Web Intents and the Firefox work on push are likely to alleviate the symptoms somewhat, but still the underlying problem isn't being directly addressed. The browser has become a bottleneck.

One approach to counter the walled gardens and silos (and associated issues like privacy) is to host all your own stuff (check Steve Pemberton's Why you should have a web site for starters). Depending on your ISP setup, it may be possible to serve direct to the Web from a home host. So why not manage all your data locally? That makes it easier to manage how much control of your own stuff that's handed over to other services.

Ok, you might argue that's something we're (more or less) all already doing. Maybe. But where is the Web? I suspect most people consider it conceptually (as I usually do) as out there. Why should it be here too? Ok again, there's been loads of work done over the years on P2P systems. We've seen things like Microsoft's Personal Web Server. But note: "PWS was useful in developing web applications on the localhost before deploying to a production web server.". The approach here, and with many other comparable systems (certain blog editing software, for example) is that the local material is offline and copied to a remote server (via ftp or whatever) to make it live.

I think the time might be right to look again, and consider making the localhost the live host. Where the wiring doesn't support direct serving, what's needed is a transparent, real-time connection to a remote endpoint to simulate a local/global connection to the internet. Not trivial, but then again there aren't any hurdles that haven't been leaped in other contexts. There are several ways this could be achieved, maybe the most straightforward based on standards would be using an XMPP-based bridge between the local and remote machines, with a fair bit of caching on the remote machine for performance. Should be commoditizable.

Of course this would demand a full stack locally - if you were using, say, a MySQL store behind your CMS, that'd need to be running locally, along with all the interpreters for PHP etc, together with whatever message dispatch switching you'd ordinarily use on the remote host. But I think it would be advantageous to manage information locally using Web-oriented technologies - in particular linked data. Let the Web in.

Why am I suggesting this kind of a setup, just as everything appears to be moving to the Cloud? Well this isn't anti-Cloud, quite the opposite. It's bringing the Cloud right back home, to encourage greater participation. Avoid the bottleneck of the browser (and a handful of lower-level protocols like ssh) to connect with the Web, open the floodgates with other local agents interacting with your own data and through the HTTP bridge, and allow as many parallel channels as you wnat, in addition to the browser. It is the 21st century, after all.

Comments to G+ please.

PS. within seconds of me posting the link to G+, Melvin Carvalho responded:

Already doing it. Dyndns and apache let you run a pretty decent web server. Then I have a linked data space on my desktop https://github.com/linkeddata/data.fm . I also have a little script which links my personal data space to my online presence when I'm logged on. I wonder why in 2012 more people dont run a personal server.

I'd just like to plant a little flag in the sand. Big Data seems to be the flavour of the month (and is undeniably extremely useful and interesting), but I've a gut feeling that might be symptomatic of not seeing the wood for the trees (or maybe vice versa).

I've not thought this through much, but surely any trends/correlations/relationships that are important enough to be of interest should be detectable without having to build a terabyte+ store? Rather that trying to capture as much raw data as possible up front, I suspect a more productive approach long-term will be to work with (maybe federated) crawler farms, with lots and lots of algorithms running in parallel over what they see. If there are appropriate training feedback loops in place, the shape of algorithms themselves could be treated as the results of the analysis.

It could be argued that once you have accumulated a corpus of raw data you can subsequently throw whatever you like at it without having to get the raw data again. But that corpus will never be complete or truly fresh - as new data appears on the Web all the time. More critically, under normal circustances you can never be sure you've got a dataset that contains a good sample representation covering whatever unknowns you're exploring. But crawlers can be directed to favour slices of the Web that contain information relevant to your hypotheses.

So, in the context of the Web, the Web itself should be the only big data needed. Which gives a neat parallel in the other sciences: reality itself is the only database you'll ever need :)

Ok, in the same way that Big Sites (like Wikipedia/dbPedia) adds big value to the Web alongside lots of small pieces, loosely joined, the same no doubt goes for Big Data. But let's not forget the vice versa, a complementary Small Data approach.

Somewhat orthogonal to this, one way in which the Web is a game changer for data is that here the relationship between pieces of data (/documents) is at least as significant as those pieces of data stacked on top of each other. Link Rank is a special case, an aggregated, flattened view of link value. If topics and entities (i.e. thing in general, people, places, concepts etc) and their interrelationships are inferred and/or explicitly named, it should expose some interesting facets of how human knowledge works.

Comment to G+ please.

For quite a while I've held the view that most current approaches to Web search are fundamentally flawed, because the best way to find something is not to lose it in the first place. But as the companies invested in search gradually get smarter in their use of person- and (to a lesser extent) thing-oriented data, rather than just word association (football) search results seem increasingly more focused. Google's approach in particular has grown increasingly like the model put forward in the Semantic Web initiative. Recently with G+ we see a big push to capture and exploit data associated with personal profiles (the FOAF domain) and brands (the GoodRelations domain, although maybe there's a role for an additional brand- rather than product-oriented vocab). With Rich Snippets and Schema.org there's a direct use of semweb technology (in a slightly mangled form - One True Ontology is a well-known antipattern to anyone that bothers to look at the literature).

In fact the "Your World" part of Search plus Your World (SPYW) can be seen as a reinvention of the most important part of Semantic Web technology, that of giving everything of significance a URL: people, places, things, concepts. Given that, you can start describing and leveraging relationships between those resources. To use a phrase I think originated around microformats, it's lower-case semantic web. Ok, behind the quality glitz of G+ profiles and pages this seems to have been done in a rather sloppy, ad hoc fashion, but that in itself is fine - whatever it takes. But where Google get it very wrong is by putting themselves at the heart of their system. Not only is semantic in lower-case, so is web. If you do a search with SPYW enabled, you're pointed straight back into the Google Empire. They are making themselves gatekeepers of the Web. Although there aren't any concrete entry barriers to this walled garden, by only signposting Google's footpaths in search results it's creating a system with the same characteristics as say AOL around 2000. From Google search being a vital accessory on the open Web, it's increasingly becoming a portal.

There is already a visible cost in practice to Google's echo chamber - if you want to re-find something one of your colleagues said the other day, sure SPYW is helpful. But if you're trying to do some original research, you don't want to be searching with Your World blinkers on - an engine without those preconceptions such as DuckDuckGo will be more useful

This strategy I'd assert is doomed to failure for the same reason AOL's walled garden collapsed, to use another phrase I like to repeat, because no matter how big any single entity becomes, the rest of the Web will always be bigger. The focus on the user/Don't Be Evil thing is absolutely right to highlight the value of non-Google resources, although it does fall short by suggesting that the rest of the Web is just a handful of other companies [G+ link] i.e. Twitter, Facebook etc. Google's own long-term survival as a market leader is absolutely dependent on their respect of the Web at large.

So what should Google do? Re-read Steve Yegge's awesome rant [G+ link] for starters. Especially the bits about Platforms. G+ and Your World should be considered in this context - as a semantic (any case) Web (upper case) Platform. For example, while Google's pages appear to be aimed at providing the canonical URLs for concepts (...lower-case). But there's already an excellent source of such URLs : Wikipedia. In itself Wikipedia only provides URLs of documents who's primary topic is the thing in question, but dbPedia is a well-established mapping based on best practices from thing identifiers to Wikipedia pages (e.g. <<a href="http://dbpedia.org/resource/Berlin">http://dbpedia.org/resource/Berlin> foaf:isPrimaryTopicOf <<a href="http://en.wikipedia.org/wiki/Berlin">http://en.wikipedia.org/wiki/Berlin> . ). If a handful of students from obscure north-European universities (heh, sorry, just for the sake of contrast), with a little community support can create and maintain - give the world - a service supporting all the concepts/things covered by Wikipedia, imagine what the mighty Google could achieve...

To give a little example in the context of Personal Profiles, if I publish my definitive personal profile on my own domain (note Google already understands all the elements of this) then for queries for which "me" is the appropriate response, that page should be the first hit, not my G+ profile.

Another factor in the walled nature of G+ is the limited API. I'm sure features will be added to this in the near future, but I hope (probably unrealistically) they will use proper standards and follow known best practices. Going further into over-optimistic territory, I'll quote Tom Gruber (in an interview talking about how Siri works) :

A site that exposes RDF usually has an API that is easy to deal with, which makes our life easier. For instance, we use geonames.org as one of our geospatial information sources. It is a full-on Semantic Web endpoint, and that makes it easy to deal with. The more the API declares its data model, the more automated we can make our coupling to it.

What should we (as users and components of the Web) do? Well, basically what we're already doing...but trying not to be distracted by shiny things and keeping an eye on the long term - standards are good. When we publish data on the Web we need to consider the quality of the data first (i.e. make it 5 Star), seeing it as purely Google-fodder is missing the point.

Comments please [Google+ link, the irony is not lost on me :)]

Here's true and false

[http://purl.org/stuff/true and http://purl.org/stuff/false]

I'm sure they already had URIs somewhere before (http://dbpedia.org/resource/True is nearly there...) but it seemed a nice idea to give them some solid (?) semantics too, fortunately there's at least one media type available - so it's "true as in Javascript". Took a few minutes to set up to give that media type. Tried PHP first but it doesn't seem properly configured on this server (which is weird, I'm sure I've got PHP stuff live). Anyhow, Apache2 config for hyperdata included mod_python from who-knows-when, so I used that.

true.py is:

from mod_python import apache

def index(req):

req.content_type = "application/javascript"

return "true"

with .htaccess (same dir) as:

RewriteRule ^true$ true.py

- plus corresponding stuff for false.py.

I don't like the way the PURL redirects, can that be done transparently I wonder, keeping the same URI in the address bar?

Browsers have certainly evolved since the WorldWideWeb browser in 1990 into pretty sophisticated pieces of kit, supporting rich views of HTML and many other media types, along with a powerful version of code-on-demand through Javascript. But in certain respects they're still very primitive. It was probably unavoidable, but there's a significant conceptual gap between what the browser can do as a general-purpose tool and what it can do as a container for site-localized Web Applications. Take Gmail as an example of the latter - very much the same ballpark as desktop mail applications. But move away from that domain and all gmail's functionality becomes inaccessible. We're still a way off a genuine Web of Applications.

One obstacle to maximizing the Webiness of Web Applications is found around the way buttons are used, directly mimicking the behaviour of desktop applications. But on the Web, the best affordances are associated with links (i.e. URIs + HTTP). In this context we should expect more of Web Applications - that the application should be built primarily as a Web API, i.e. a regular Web Site, so that the affordances are available to other applications. It should be trivial for me to check the contents of my gmail inbox from the comfort of my own Home Page. However I'd hazard that the business models of the big Web brands are likely to hinder development in these directions - Google, Facebook, Amazon etc. run somewhat counter to the open Web, in that they are motivated in keeping you in their domain (or in extreme cases like Apple and MS, in their own devices). Web Intents seem to me to be a good start towards enabling more flexible yet uniformly accessible interactions.

Over the years the read/write nature, or rather lack of it, has been discussed an awful lot. Even though the first browser included an in-place page editor, the current model still doesn't really support this. One big reason for this is that HTML - even HTML5 - falls short of supporting the full range of HTTP methods. The predominant approach to writing to the Web is through major intermediation by Content Management Systems. While CMSs are generally a very good idea, the fact that they're built on an effectively hobbled client means they aren't as Webby as they should be. There are genuine technical obstacles to generic writeability, notably those related to authentication and authorization, though hopefully WebID will help there.

The metaphor of the browser is itself quite limiting. Generally we only have one Web document open - visible on the screen - at a time because we can only read one thing at a time. Even with the development of tabs, the browser still essentially reflects this modal model of Web resources. I think I read about work on accessing data across tabs, but as far as I can see it doesn't exist yet. Ok, desktop applications are also under the restriction that we can only look at one thing at a time. But it's a lot more common to interact with multiple independent data sources/sinks and processing components there.

A browser can pretty much support a general-purpose HTTP client (through script), but because we're so used to thinking in terms of the Web of Documents and requirements there, the one page at a time modality is deep in the mindset. Service mashups, be they client or server-side, all really aim towards focusing down on a (primarily read-only) single-document view. A critical aspect is that traditionally the link has basically just one meaning - navigate to another page (do a GET and display the results). But while a link on a Web of Data could correspond to the same thing, it could also mean 'GET the data and merge it into the local store' or 'use this URI to filter the current view' or any number of pivot-like operations.

Ok, this is in danger of turning into another rant...let me sidestep by highlighting one specific browser affordance.

The Turn-Around Button?

One link-oriented metaphor for the browser Back Button could be walking down a footpath, junctions in the footpath corresponding to the available links presented to us on a Web page. Clicking the back button has the effect of walking backwards to the previous junction. We are still facing in the same direction. But what if we metaphorically turn around? Ok, the outlinks on the page will look just the same, but other data is available, our whole history. Why not present the current page alongside a recent history page (like chrome://history/) so we can hop back further - a turn around button. Yes, the Back Button may drop down a list showing the history, but richer information could be provided in the main window such as the links followed as a tree.

From a data perspective, variations on a Back Button might mean 'remove this data from the local store' or simply 'Undo'.

Dunno. Work needed on RDFAffordances.

See also: Identifying Applications State