Raw

Stumbled on this by Donald Norman in some of Edward Tufte's material about PowerPoint :

Technology is not neutral. Technology has properties--affordances--that make it easier to do some activities, harder to do others: The easier ones get done, the harder ones neglected. Each has its constraints, preconditions, and side effects that impose requirements and changes on the things with which it interacts, be they other technology, people, or human society at large. Finally, each technology poses a mind-set, a way of thinking about it and the activities to which it is relevant, a mind-set that soon pervades those touched by it, often unwittingly, often unwillingly. The more successful and widespread the technology, the greater its impact upon the thought patterns of those who use it, and consequently, the greater its impact upon all of society. Technology is not neutral, it dominates.

- Norman, Donald A., Things that Make Us Smart, Perseus Books, 1993, p. 243

It nicely expresses what I've been trying to say in my periodic rants about the tyranny of the browser. Tufte's application of the above to PowerPoint is lovely, now rather than handwaving I can point to something concrete that also blinkers our way of looking at information.

The Web browser as we currently know it has evolved to interact with the Web in a way that's been influenced by perceptions of what the Web is and can be (for example, that it's largely read-only). There's a feedback loop; it's self-perpetuating. There are clear advantages for Web publishers and users in the convergence in the way browsers behave, but this is at the cost of innovation.

Incidentally, Tufte is now a sculptor.

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.

A wee rant.

Ok, I'm totally with the consensus that the future is Cloud-based, and to be a little more specific Platform-based and to be even more specific primarily HTTP-based. To back that up, cf.

• Michael Hausenblas's new report
• Mike Amundsen's recent blog post -
• Steve Yegge's awesome rant at Google

But to expand something I mentioned in passing here recently :

in one respect the emperor is stark-bollock naked. Browsers are currently a really sucky environment for client development. Sure, the HTML/CSS-based (standard!) rendering is wonderful. As shown with Node.js (and despite what Google are saying around Dart), Javascript is a reasonably pleasant, perfectly capable programming language. The growth of Ajax and JSON have shown inter-system comms is workable. There are some good dev tools and libraries. So why does working with this stuff feel like pulling your own teeth?

Here I could point to the traditional DOM API, blame the W3C for all the world's ills and an awful lot of people would nod and smile knowingly. But although that's arguably valid (heh), I reckon the problem is more systematic and can mostly be blamed on browser developers.

Ok, blame is too strong. The decisions made over the years and the directions taken have generally been perfectly rational in the context of the prevailing conditions. But there have been feedback loops at work. The flashy [sic] chrome [sic] surrounding HTML dev, from the img tag onwards, has pulled Web developers in like moths around a flame. So the browser developers act to improve that experience. Meanwhile server-side tech has developed out of the corporate legacy of silo-based systems. Let me quote Steve Yegge there: "It's a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations.". The way services are offered over the Web, even Web 2.0 services still have a big hangover from this mentality. I'd argue that most Web APIs are only marginally better than SOAPy stubs. Largely because XML and JSON aren't particularly Web-friendly. Ok, don't bite my head off, let me qualify that.

First XML. There have been plenty of arguments over the years around XHML, and back in the day (I wonder how old that phrase is) there were arguments about the XML nature of RSS. Postel's Law, the "Robustness Principle" got cited a lot. Let me give you some deja vu:

Be liberal in what you accept, and conservative in what you send.

What a lot of people misinterpreted was the keyword robust. A robust system is one designed to be able to fail gracefully or continue working acceptably with noisy data. That's exactly what we want for the Web, right? Well not necessarily, if I was ordering a book from Amazon, and there was a partial failure, I'd rather they didn't make a best-guess when it came to taking money of my credit card (I think paraphrasing Tim Bray there). Anyhow, XML is not robust, by design. XML is designed to bail out completely at the first sniff of anything dodgy. As it happens, the way XML is often served on the Web is without proper regard for the media type, i.e. dodgy and hence broken.

Sorry, that was gratuitous deviation, the real reason I'd say XML isn't Web friendly, like JSON, is in the way people use it. Whether data is conveyed as name-value pairs or through more complex structures, the key parts are generally just simple strings. But by itself, a string on the Web is next to useless. You or I can (maybe) read it, or even paste it into Google and get a definition. But what is a poor machine client to do? What makes the Web are links. It's 101 but somehow still manages to be overlooked: the link has two facets: a universally unambiguous name (URI/IRI) and a protocol for following it (HTTP). If a client on the Web encounters a link, it can follow its nose to find out more information about it. That's what we as humans do in browsers all the time, yet when it comes to Web services for some reason a simple string is seen as adequate to identify something.

Ok, with XML, the HTML DOM and to some extent JSON there's been some justifiable resistance to the use of URIs for names, because namespaces have traditionally been uninuitive at best and agony at worst. Using URIs instead of simple strings certainly adds a burden (it doesn't have to be that great, check Turtle syntax), but its benefits far outweigh the costs.

The thing is, you'll hear talk of snowflake APIs - only one implementation of each exists - but what gets overlooked is that by their very nature, most APIs just aren't Webby. The client must have prior knowledge that the service at endpoint X uses API Y. What you end up with is effectively a series of 1:1 client-server connections. That, while the uniform interface REST may mean it's less brittle than an RPC connection, still means tight coupling.

Ok, you might argue, that for any communication to take place, some prior knowledge is required. Sure, but that can be minimised - just like the way we follow links for more information in a browser, a service client can follow links to get more information. This is only a small conceptual step, but what it enables is hugely powerful. Above everything else, it's what Linked Data and the Semantic Web gets right.

I reckon that browser developers, with their emphasis on doc-oriented HTML have a natural tendency to carry their experience in that domain across and apply it to data. Naturally namespace-less XML and JSON will seem preferable through that lens. But in practice, documents and data are apples and oranges. Browsers have been optimized over the years for the former, incidentally making the latter harder than necessary.

It's funny how you don't hear so much about service mashups these days, despite their undeniable coolness. I'll assert that it's because developing for Web data in the browser is bloody hard work, especially when there are NxN arbitrary API mappings to know.

Overall it's actually something of a miracle that the notion of cloud-based platforms has emerged.

I had planned to say more about Cloud Computing Outside of the Browser - or to put it another way, evolving old-fashioned non-browser Rich Internet Clients (as well as server-server and every other non-browser configuration). But ranting's worn me out. Anyhow, in short, I reckon that for the forseeable future, non-browser clients in many circumstance are probably preferable to browser-based equivalents, primarily because they're easier to develop (as I keep saying, I reckon the agent model of combined client/server units is a good way to go). While I personally welcome HTML5 and the APIs as a clean-up of document markup and processing, when it comes to data it isn't even a Band-Aid.

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+

Not a new idea, but I thought I'd try and find out how far we've got and braindump a little. I'm making the fairly big assumption that a general-purpose data browser would feasibly useful/usefully feasible in addition to application- or task-specific tools (i.e. use X for your contact/social data, Y for your project management data, Z for your shopping list).

Historically Web browsers provide simple display of (linked) HTML documents obtained via a subset of HTTP, and that's still their primary use. Not very promising for use on the Web of Data without a lot of server-side magic.

But, as well as supporting increasingly sophisted UI elements, they have built-in support for a Turing-complete language, Javascript. The HTTP limitations can be worked around. So while there may still be potential for a totally new breed of data-oriented Web browsers built from scratch as Rich Internet Applications, current browsers have the potential do do whatever's needed. Although they're pretty much limited to playing a client role, in effect they can be whatever kind of Intelligent Agent you like. The bonus is that everyone's already got a browser on their desktop/tablet/mobile - it's an easy path to deployment either for a plugin or better style as code-on-demand.

What's needed for a Data-Oriented Web Browser?

I'm not sure if the Tabulator is still actively maintained (if not, why not!?), but that gave a good indication of the kind of thing that is possible. Taking a step back, the Web of Data is really the same thing as the Semantic Web, and what's new about the Semantic Web isn't the "Semantic" but the "Web" (once again I've lost the source of that quote). How did/do people work with data without the Web? Typically SQL databases and spreadsheets. From those we can lift SQL queries and command-line tools, stored procedures and database forms (this is rather a confession, but back in the day when I first encountered MS Access it blew me away). Then of course there's the spreadsheet UI paradigm, a grid of cells which can be filled with pretty much anything, including most significantly on-the-fly calculated values.

So here's an initial shopping list:

• an in-memory* graph data structure support (rdfstore-js looks the most advanced right now)
• a spreadsheet-like view (I bet David Huynh has got stuff like this, if not, how hard could it be with a and jQuery? :)
  a little language for concisely expressing Web operations, e.g. running SPARQL queries, that could be used inside the spreadsheet (the RDF path-following DSL in Apache Clerezza could be useful here too - link please Henry)
  tools for building app-specific forms (quite a few tools support custom views of particular classes, e.g. foaf:Person, Fresnel might help here)
  the ability to write as well as read data (this shouldn't need saying)

  * persistence would be provided by the Web

  I doubt it's possible to say up front what would be a good user-friendly way of setting this stuff up. But given a bunch of scripts that supported these elements, I reckon with a bit of trial and error dogfood use, within a few iterations something really useful could be possible.

  Thoughts? Volunteers? Startups? :)

  I've still not got commenting set up here so please post any feedback to this Google Plus entry.

  
  danja
  2011-08-26T10:49:28+01:00
  gui browser ui spreadsheet semweb rdf data linked
  Related
  Comments
  

  Mosaic Web Browser on Ubuntu

  In short: Mosaic is fairly easy to build on Ubuntu using standard tools, and all the necessary libraries are available through Synaptics Package Manager.

  
  
  Aside for being a bit of fun, I reckon there's a good reason to play with it. Santayana said "Those who cannot remember the past are condemned to repeat it". Well, ok, but not everything about the past is negative. There's a corollary with something more positive than 'condemmed'. We can look to the past for things which worked well, and use what we find to inform decisions about the future.
  
  NCSA Mosaic is often cited as a reason the Web went viral. So I thought I'd have another look. I'm pretty sure trying to download DSP utilities using Mosaic at Sheffield Poly was my first exposure to the Web (also memorable because it gave Caroline her first migraine). It was a few years before I encountered the Web again, and I think by then Netscape Navigator had come along.
  
  Anyhow, the source for Mosaic is available from github, so I gave it a shot. Presumably I had most of the necessary dev tools and libs installed from previous forays into building, if I remember correctly things like make and gcc become available when you install package build-essentials (it's in Synaptics). So after downloading and unzipping Mosaic source, I cd'd into the dir and tried:
  
  make linux
  
  This didn't get far. There are quite a few dependencies, notably Motif. When the compiler gave up it said what was missing. Googling I found a systematic way of finding missing bits, by installing apt-file and doing things like:
  
  $ apt-file search X11/extensions/Print.h
  x11proto-print-dev: usr/include/X11/extensions/Print.h
  
  which says X11/extensions/Print.h is in the x11proto-print-dev package. But not knowing ahead of time whether things were available through apt, I googled the filenames instead...
  
  The libs I had to install were:
  
  libmotif-dev
  libmotif3
  x11proto-print-dev
  libxmu-dev
  libpng12-dev
  libjpeg8-dev
  libxpm-dev
  
  Chances are a clean system will need other libs.
  After installing the above, the build then gave up with:
  
  gui-dialogs.o: In function `mo_edit_source':
  /home/danny/mosaic-src/src/gui-dialogs.c:2751: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
  
  With gcc, using -w gets rid of warnings, so I tried make -w linux. It ran without errors and said "Welcome to Mosaic", but at first I couldn't see the compiled app, so I tried make linux again, which ran without stopping this time. I'm not sure the -w was actually necessary.
  
  To run:
  
  cd src
  ./Mosaic

  [apologies for using italics a lot - this WYSIWYG HTML editor is buggy with code etc]

  
  danja
  2011-01-25T14:22:44+01:00
  browser build history ncsa web www mosaic
  Related
  Comments
  
  Tweet

  

  Contact

  • Danny Ayers
  • (danja)
  • email
  • FOAF Profile

  Nearby

  • About
  • Feed
  • planet danja (me aggregated)
  • danny.ayers.name (resume etc)
  • Raw (blog)
  • Hyperdata (tech/projects)
  • Vocabs
  • Spike and Wave (music)

  Archives

  • pre-2004(dates messed up!)
  • 2004
  • 2005
  • 2006
  • 2007
  • 2008
  • 2009
  • 2010
  • 2011
  • 2012

  Elsewhere

  • Google Plus
  • Twitter
  • Facebook
  • LinkedIn
  • Flickr (photos)
  • YouTube (videos)
  • slideshare (presentations)
  • del.icio.us (links)
  • GoodReads (books)
  • github (code)
  • W3C Wiki (bits)

  Search (figure it out - and please only do lightweight queries for now, big ones will kill the server)

  Powered by Gradino

  Danny Ayers on G+