Category Web 2.0

Media companies should embrace the generative nature of the web

Generativity, the ability to remix different pieces of the web or deploy new code without gatekeepers (so that anyone can repurpose, remix or reuse the original content or service for a different purpose) is going to be at the heart of successful media companies.

Depth of field (Per Foreby)

As Jonathan Zittrain points out in The Future of the Internet (and how to stop it) the web’s success is largely because it is a generative platform.

The Internet is also a generative system to its very core as is each and every layer built upon this core. This means that anyone can build upon the work of those that went before them – this is why the Internet architecture, to this day, is still delivering decentralized innovation.

This is true at a technological level, for example, XMPP, OAuth and OpenID are all technologies that have been invented because the technology layers upon which they are built are open, adaptable and easy for others to reuse and master. It is also true at the content level – Wikipedia is only possible because it is built as a true web citizen, likewise blogging platforms and services such as MusicBrainz – these services allow anyone to create or modify content without the need for strict rules and controls.

But what has this got to do with the success or otherwise of any media company or any content publisher? After all just because the underlying technology stack is generative doesn’t mean that what you build must be generative. There are, after all, plenty of successful walled gardens and tethered appliances out there. The answer, in part, depends on what you believe the future of the Web will look like.

Tim Berners-Lee presents a pretty compelling view in his article on The Giant Global Graph. In it he explains how the evolution of the Internet has seen a move from a network of computers, through the Internet, to a  web of documents and we are now seeing a migration to a ‘web of concepts’.

[The Internet] made life simpler and more powerful. It made it simpler because of having to navigate phone lines from one computer to the next, you could write programs as though the net were just one big cloud, where messages went in at your computer and came out at the destination one. The realization was, “It isn’t the cables, it is the computers which are interesting”. The Net was designed to allow the computers to be seen without having
to see the cables. [...]

The WWW increases the power we have as users again. The realization was “It isn’t the computers, but the documents which are interesting”. Now you could browse around a sea of documents without having to worry about which computer they were stored on. Simpler, more powerful. Obvious, really. [...]

Now, people are making another mental move. There is realization now, “It’s not the documents, it is the things they are about which are important”. Obvious, really.

If you believe this, if you believe that there is a move from a web of documents to concepts, then you can start to see why media companies will need to start to publish data the right way. Publishing it so that they, and others, can help people find the things they are interested in. How does this happen then? For starters we need a mechanism by which we can identify things and identify the relationship between them – at a level above that of the document. And that’s just what the semantic web technologies are for – they allow different organisations a common way of describing the relationship between things. For example, the Programmes Ontology allows any media company to describe the nature of a programme; the music ontology any artist, release or label.

This implies a couple of different, but related things, firstly it highlights the importance of links. Links are an expression of a person’s interests. I choose what to link to from this blog – which words, which subjects to link from and where to – my choice of links provide you with a view onto how I view the subject beyond what I write here. The links give you insight into who I trust and what I read. And of course it allows others to aggregate my content around those subjects.

It also implies that we need a common way of doing things. A way of doing things that allows others to build with, on top of, the original publishers content. This isn’t about giving up your rights over your content, rather it is about letting it be connected to content from peer sites. It is about joining contextually relevant information from other sites, other applications. As Tim Berners-Lee points out this is similar to the transition we had to make in going from interconnected computers to the Web.

People running Internet systems had to let their computer be used for forwarding other people’s packets, and connecting new applications they had no control over. People making web sites sometimes tried to legally prevent others from linking into the site, as they wanted complete control of the user experience, and they would not link out as they did not want people to escape. Until after a few months they realized how the web works. And the re-use kicked in. And the payoff started blowing people’s minds.

Because the Internet is a generative system it means it has a different philosophy from most other data discovery systems and APIs (including some that are built with Internet technologies), as Ed Summers explains:

…which all differ in their implementation details and require you to digest their API documentation before you can do anything useful. Contrast this with the Web of Data which uses the ubiquitous technologies of URIs and HTTP plus the secret sauce of the RDF triple.

They also often require the owner of the service or API to give permission for third parties to use those services, often mediated via API keys. This is bad, had the Web or the Internet before that adopted a similar approach, rather than the generative approach it did take, we would not have seen the level of innovation we have; and as a result we would not have had the financial, social and political benefits we have derived from it.

Of course there are plenty of examples of where people have been able to work with the web of documents – everything from 800lb gorilla’s like Google through to sites like After Our Time and Speechification – both provide users with a new and distinctive service while also helping to drive traffic and raise brand awareness to the BBC. Just think what would also be possible if transcripts, permanent audio, and research notes where also made available not only as HTML but also as RDF joining content inside and outside the BBC to create a system which, in Zittrain words, provides “a system’s capacity to produce unanticipated change through unfiltered contributions from broad and varied audiences.”

Its been a long time coming – but finally we’re out of beta

Providing online Programme support has a long history at the BBC. Tom Coates (now with Yahoo! Brickhouse) announced the launch of the Radio 3 website in 2004. Then Gavin Bell (now with Nature), Matt Biddulph (Dopplr‘s peripatetic CTO) and Tom spoke [pdf] about Programme Information Pages (or PIPs) back in 2005 at ETech. At the time it was hoped that PIPs would be rolled out to all BBC programmes so that every programme the BBC broadcast had a permanent web presence. Things didn’t quite work out that way.

BBC 2 Schedule

BBC 2 Schedule

For a bunch of reasons this early version of PIPs wasn’t going to scale across the entire BBC programming output. At the time the only solution available to the team was a static web publishing solution and trying to collapse the entire graph down to a series of static webpages was, frankly, a nightmare. But this work did show the way forward and put in place much of the intellectual framework for what followed.

What followed was a new version of PIPs. This new version had, from certain perspectives, a much simpler brief: to provide a repository of programme metadata for all BBC programmes. Of course from other perspectives it was a more complex brief, but that’s another story. What this left however was a public representation of this data.

iPlayer of course is one representation, but iPlayer is trying to solve a different problem. iPlayer is incredible successful at delivering BBC’s Radio and TV content over IP. What it doesn’t solve is a permanent, persistent, web presence for all BBC programmes one that could support the archive and the existing BBC broadcast brands.

Last October we launched BBC programmes with the aspiration to build a true web citizen. One that would enhance the BBC’s web presence, making it a more useful place for people using bbc.co.uk and, at the same time, provide a useful service for external developers.

BBC Programmes at launch

BBC Programmes at launch

The last year has seen the service grow and develop at quite a rate (we’ve tried to release updates every couple of weeks), which especially given the modest size of the team is very impressive. I have tried to chart the major functional changes here on this blog. But what I’ve not tried to report on is the work of other teams who have styled and integrated the service into the existing broadcast brands, such as Springwatch, Last Choir Standing and now the TV Channel and Radio stations. This most recent piece of work – integrating the service into the relaunched TV sites – has also seen the service come out of beta which is truly fantastic.

An episode page for Maestro

An episode page for Maestro

As I mentioned the team is small, however, it is also incredibly talented. I have learnt more from them, and enjoyed working with them, more than I suspect they will every truly know. Consider that 6 people have, in addition to designing and building the service, also designed and built a light weight MVC framework and laid the foundation for a highly interlinked, modern web offering. The credit for the site lies with:

Paul Clifford [Lead Software Engineer]
Duncan Robertson [Software Engineer]
Dave Evans [Software Engineer]
Michael Smethurst [Information Architect]
Jamie Tetlow [Designer]
Stephen Butler [Project Manager]

Should you find yourself in a similar position, needing to design and develop a complex modern web service, then if I were you I would make sure your team is small and full of really smart, T-shaped people who understand the domain and care deeply about the quality of the product they are developing.

So where next? Since although we’re now out of Beta there is still much to be done. At a high level we will be working on two fronts:

Firstly we will be making the pages at /programmes richer and the navigation between them more coherent and consistent. So for example making schedules by format in addition to schedules by genre and generally linking everything up. We’re also going to be adding the missing views – those where we have a view in one format but not others.

We are also working to link between, and transclude data from, other domains. For example, tracklistings on episode pages, aggregation of programmes by artist and more programme information on artist pages.

More sweet, sweet programme data

One for the Linked Data community this one – you can now get your BBC programme data as RDF and the current and next three programmes, per service, as plain text, XML, JSON or YAML.

The web" by danbri. Used under license.

"How it works: The web" by danbri. Used under license.

Last May, at XTech, Nick and I gave a paper outlining our work to make data available for other development teams, outside the BBC, to use. At the time we didn’t have the RDF views launched – since then we’ve launched RDF for the new artist pages and today for programmes.

As usual all you need to do is add .rdf to the end of a URL for a brand, series, episode or version. For example:

http://www.bbc.co.uk/programmes/b00d8xyx.rdf

http://www.bbc.co.uk/programmes/b00d8ywd.rdf

http://www.bbc.co.uk/programmes/b0063cbg.rdf

There are also XML, JSON, YAML, and text views for schedule “upcoming” URLs:

http://www.bbc.co.uk/bbcthree/programmes/schedules/upcoming.txt

http://www.bbc.co.uk/bbcone/programmes/schedules/london/upcoming.xml

http://www.bbc.co.uk/radio1/programmes/schedules/upcoming.json

http://www.bbc.co.uk/bbc7/programmes/schedules/upcoming.yaml

Of course that’s still not as many triples as Yves published (congratulations!) but I hope you enjoy it none the less.

Formally modelling a trust network – a sign of hubris?

“Interactivity. Many-to-many communications. Pervasive networking. These are cumbersome new terms for elements in our lives so fundamental that, before we lost them, we didn’t even know to have names for them.” Clever man Douglas Adams. You see he wrote this in 1999 and clearly understood, even then, the nature of the web so much better than most of us do even today.

"Camp fire on the beach" by joaquimb. Used under license.

Camp fire on the beach, by joaquimb. Used under license.

As Douglas Adams points out the Internet is still novel – it’s very easy to forget that despite it’s incredible uptake the world has only had the Web since 1991. That’s really not very long. We are still getting use to it, still working out how to use it. But back in 1999 Douglas Adams clearly understood that one thing you shouldn’t be trying to do is model human trust and that’s because our brains do the job so much better.

Working out the social politics of who you can trust and why is, quite literally, what a very large part of our brain has evolved to do.

Although the Internet is a new technology, it is in many ways a return to a more traditional form of entertainment. The sit back and consume world of 20th century entertainment is the abnormality. TV, radio and the cinema are the aberrations because they aren’t interactive – all other forms of entertainment up until the early 20th century (and an increasing amount of entertainment since) are ‘interactive’ its just that we didn’t call them interactive entertainment because that would be silly – “a game of interactive cricket anyone?”

Unfortunately we currently looking at the Internet from the perspective of the non-interactive entertainment world of TV and radio. And that perspective isn’t helpful, as Adams puts it:

Newsreaders still feel it is worth a special and rather worrying mention if, for instance, a crime was planned by people ‘over the Internet’. They don’t bother to mention when criminals use the telephone or the M4, or discuss their dastardly plans ‘over a cup of tea,’ though each of these was new and controversial in their day.

Possibly because people see interactive entertainment as new and different they believe that they therefore need to build policies and models to express human trust into their web apps. The trouble is it just isn’t necessary – worse it doesn’t work. Our brains are great at working out who and what to trust – you just need to expose enough information so we can make the decisions. On the other hand it seems to me that attempts to formally model a trust network is a sign of hubris.

Of course you can’t trust what people tell you on the web anymore than you can trust what people tell you on megaphones, postcards or in restaurants… For some batty reason we turn off this natural scepticism when we see things in any medium which require a lot of work or resources to work in, or in which we can’t easily answer back like newspapers, television or granite. Hence “carved in stone.” What should concern us is not that we can’t take what we read on the internet on trust of course you can’t, it’s just people talking but that we ever got into the dangerous habit of believing what we read in the newspapers or saw on the TV – a mistake that no one who has met an actual journalist would ever make. One of the most important things you learn from the internet is that there is no “them” out there. It’s just an awful lot of “us”.

What you need then is not a model of trust instead you need a mechanism to answer back. You actually need a bit more than that – you need a mechanism to identify a person online – ideally wherever they appear on the web – via OpenID and FOAF for example. You also want to know who their friends are, or more specifically who claims to be friends with them. So for example, if I can see that someone is a friend of a friend I’m more likely to trust them than if neither I, nor my friends, have a connection with that person.

I also want to be able to read what they say and do online. If I can read their blog, look at their comments, check out their del.icio.us feed or twitter stream etc. then all the better. And since we are talking about online social networks this shouldn’t be too unreasonable.

Our brains are very good at processing this kind of social relationship information so we can assess whether or not we should trust a person, or more importantly to assess when and in which context to trust a person. I would trust Nick’s advice on say how to build my own home brew radio (in a lunch box) but not which pet to buy.

I remember Dan talking about the social graph and saying how he felt uncomfortable about the way XFN encouraged you to assert the nature of the relationship: “nope you’re not my ‘friend’ you’re an ‘acquaintance’ or ‘co-worker’ etc.” Which is why FOAF just has ‘friends’. This might be just because Dan is a nice bloke but I have to agree it is just a bit weird categorising the nature of your relationships the XFN way. But more pragmatically it’s also just not that helpful to model this information. All you really need is a mechanism to assert that there is a relationship and a URI to identify the person; you can then go and dereference the resource to work out whether you should trust that person or not for a given context.

Google Chrome why?

The Internet is all a buzz with Google’s open source web browser Chrome. But you have to ask why and even if it’s a big deal. Not why there’s all the interest but why Google bothered to build their own browser? After all they could have worked with Mozilla to add these features to Firefox – instead Google went and built their own browser.

Introducing Google Chrome

Introducing Google Chrome

So clearly I don’t know, but I wonder whether Google just got a bit fed up of waiting for the features they wanted and went ahead and built their own browser, while leaving the door open to merge these features back into Firefox at a later date. Google are a big supporter of Firefox and the idea of a Google browser has been associated with Firefox in the past; and Sergey Brin has said he is keen to see Firefox and Chrome become more unified in the future.

It is probably worth noting that they (Mozilla Corp) are across the street and they come over here for lunch,” Brin said of Mozzilla employees visits to cafeterias at the Googleplex headquarters. “I hope we will have more and more unity over time”.

But what features are important to Google? After all, as Jon Hicks points out, from an interface point of view, Chrome brings nothing new – all the features are already available in existing browsers. But I don’t think that’s the point and I don’t think that’s why it’s important. Google want to offer much richer and, more importantly, faster web applications.

The current browsers, including Firefox, just can’t cut it. JavaScript isn’t fast enough (thereby limiting the UX), browsers are single threaded and they aren’t stable enough. If Google want to challenge Microsoft (or anyone else for that matter) in the desktop space they needed a better platform. Of course others have sought to solve the same problem – notably Adobe with Air and Microsoft with Silverlight. Google’s solution is I think much neater – build an open source browser that supports multithreading, fast JavaScript execution and stuff Google Gears into the back end so it works offline. Joel Spolsky suggested something similar a while back:

So if history repeats itself, we can expect some standardization of Ajax user interfaces to happen in the same way we got Microsoft Windows. Somebody is going to write a compelling SDK that you can use to make powerful Ajax applications with common user interface elements that work together. And whichever SDK wins the most developer mindshare will have the same kind of competitive stronghold as Microsoft had with their Windows API

Imagine, for example, that you’re Google with GMail, and you’re feeling rather smug. But then somebody you’ve never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features. Not just cut ‘n’ paste: cool mashup features like synchronization and single-point identity management (so you don’t have to tell Facebook and Twitter what you’re doing, you can just enter it in one place). And you laugh at them, for their NewSDK is a honking 232 megabytes … 232 megabytes! … of JavaScript, and it takes 76 seconds to load a page. And your app, GMail, doesn’t lose any customers.

But then, while you’re sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug, new versions of the browsers come out that support cached, compiled JavaScript. And suddenly NewSDK is really fast. And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things.

Of course the big difference is that it’s Google that have gone and launched the new browser that supports cached, compiled JavaScript.

With the release of Chrome, Google can now release versions of their apps that are richer and more responsive. Chrome then isn’t targeted at Firefox I think that Chrome is more of a threat to Silverlight and Air. After all if you can write a web app in JavaScript that’s just as rich and responsive as anything you can write in Silver-Air why would you bother with the proprietary approach?

Chrome is in effect a way to deliver a Google OS to your desktop, one that lets you run fast JavaScript applications. And if you believe Sergey Brin Firefox will, in time, adopt the same technologies as Chrome; which is of course just what Google want – maximum market penetration of those browsers that support their new rich web apps.

Follow

Get every new post delivered to your Inbox.

Join 819 other followers