The Labs are basically a way to involve the new media "indie" community in developing new ideas that meet various strategic goals of the BBC (eg how to reach an under-served audience, or how to exploit a particular type of content we own, etc), giving them a bit of cash to sit with us for five days and work through an idea, to which we get first rights but non-exclusive access.

Along with Mark, Ian and Matt, I've been asked to come along to the intro sessions to talk about the BBC's web infrastructure. The idea is that agencies will have an idea of how their pitches will run on our architecture and what they will have to integrate with. Going by some of the demos we've seen recently, a lot of agencies don't seem to think they would have to integrate with anything, so getting the word out has to be a good thing.

It also helps that we can talk about what will be coming in the next year or so as the "BBC 2.0" project kicks off... we will have a nice scalable service-oriented architecture for people to build upon. Well, that's the plan anyway.

It raises a few interesting points:

• Where are the techy agencies?
  It seems that most of the people pitching to us have been "new meedja" agencies in the sense that they are used to building corporate web sites for corporates, with minimal technical input. But if we want some solid recommendation software either built or integrated, or a message queuing system integrated and supported, where do we go? We've got the money to spend... (well, we will have soon, if all goes to plan..!)


• How to make it worth an agency's while to build for our architecture?
  We want people to build tools that will integrate with our single sign-on, ratings systems, file stores, social networking / friends systems, etc etc... but if they build exclusively for our needs, they won't be able to re-sell their products to others. So either (a) that's fine but we have to pay more for the work, or (b) we have to come up with a compelling offer to these guys. One way might be to create open source implementations of each of our components, and make them all freely available to be integrated into other products (under, say, the Apache license). But as at least part-funders of these products, wouldn't licence fee payers expect to see a share in any future proceeds of products built on our shared infrastructure?
  
  Another way would be to exclusively use shared standards and make sure an open source product already exists for every component we use. That might be fine for SSO (using, say, JAAS) but I can't see it working for some of our more obscure components.

I feel humble and proud ;-)

Although more on the humble side when I look at the code and realise what a rudimentary state I left it in...!

Weird.

If anyone else out there is using it, please let me know... who knows, I may actually put out another version one day!

I worry when I hear people say that simplicity is the way to go in the future, with the not-very-subtly-hidden subtext that all we have to do is get rid of layers of technology and complexity, and a simple interface will magically present itself. The set of articles uses examples of cars and telephone networks to show that making things simple to use is actually very difficult, and could well require *more* layers of complexity to provide the interoperability and intuitive interface that we need if we are going to make sense of the changing world of technology in the next decade or so.

Somehow I feel the combined smarts of the W3C should be able to come up with more exciting use cases than finding the top 10 movies which also had soundtracks that came top 10 in the charts..? How is that supposed to energise a new industry to make its data available in RDF?

The use cases don't come from the real world that I live in... random quotes:

"José sends a query to the Census Bureau's new RDF storage server and requests that his client pass the query results to an XSLT transformation service so that he can print the resulting XHTML."

"Zoe wrote an IRC bot that they use to make assertions -- which the bot stores as RDF."

I hope someone out there is thinking about this stuff in a bit more end-user-friendly manner!

A few of us have some ideas around publishing out this metadata, we just have to run it past search to check what format we should use. I’m hoping we can just do

etc. That would be very useful, in the sense that people could pick it up and do amazing things with it... maybe we can do that stuff ourselves, but even if we don’t, the data is there ready for someone else to play with.

As well as the text-based names, we have the lat/long data for those locations in an XML file somewhere, I might be able to get that extracted and put into the HTML as well. We aren't allowed to publish the complete location CV due to licensing restrictions, but we can extract pieces of it for certain purposes.

We haven’t really decided on the format yet, it might be worth making it RDF or something from the start -- although I’m not sure how useful that would be unless our content is all well-formed XML, and while we’re pretty close, I don’t think we’ve sorted out all the issues of & in URLs etc.

Basically, Google provides a bunch of web services (via SOAP and REST) and exposes their core functionality to developers around the world. They provide the engine, developers can build their own interface, as long as they follow a few rules. Amazon does the same thing, although of course they're not being nearly as nice as Google because they're really just opening up their shopping cart to others, they still get the money from any sales.

So if Google can provide the definitive search API that everyone can use, and Amazon can provide a book buying API, what could the BBC offer? The list is endless...

- GIS services: postocde<->location name<->lat/long mapping
- TV/radio listings services: what's on today, what's on this week, in a particular genre, on a paricular network, what's on right now
- Search services: BBC search via API
- metadata services: classification engine??, list of terms, integrate with BBC Search to show stories/pages that match metadata terms
- information services: weather, traffic info, financial data...

A simple application of this would be something that takes a person's postcode, uses the postcoder API to translate it to a lat/long, then uses the BBC search to find all content marked with locations within 10 miles, and presents a custom page for that user. Of course that's just the beginning!

We hope it to be a place where the sort of people who make content management actually work can gather and share information. Vendors are not allowed to join as an organisation (although people who work for vendors are welcome to join as an individual), and we don't really care too much about the technology. We know that the problems of content modelling, change management, business process modelling and actually getting reasonable requirements for a CM project are much harder than merely building some software to manage content.

If that sounds interesting to you, please check out the site and maybe even sign up. We're having our first official meeting, the CM Pros Summit at Boston in November, co-located with this year's Gilbane Conference. You're welcome to join us!

So what does it have to say about content management at the BBC? Some interesting points...

(Just notes-to-self for now, I'll come back and write about individual points later)

Page 20 of the main review: "The BBC has also employed a number of technical solutions to enable them to deliver news and information content quickly and effectively, over a number of platforms. The development of the News and Sport Content Production System (CPS) represents a significant investment in such technical solutions, with total costs amounting to £3.8m in 2003"

A constant theme is value for money, which resonate's well with Mark Thompson's recent prouncements to make all BBC services pass a "public value test". The term "cost per unique user", "CPUU" is referred throughout, obviously meaning the cost of content production divided by number of unique users. It will be interesting to see this statistic for a lot of our content. According to page 21, CPUU for weather is 1.8 pence and Nations and Regions (excluding Northern Ireland) is 20.5 pence. It will be interesting to see if this figure changes after our CMS has finished rolling out to the English Regions sites...

Page 21 again, "the BBC is currently developing the technology to track traffic exclusively to external sites." Well I thought the /go/ system would do that, but if you say so... anyway in the CMS, adapting our external weblinks to use a system like this (or to move from one such system to another) will take about 20 seconds of XSLT coding.

And more on page 21, "links from sites or pages are not... measured across the site." Another easy peasy thing for us to do with the CMS...

Page 22, "The total costs of the launch of the
search engine (worldwide and BBC site) were £414,268, and the current running costs of the
BBC Online search tool are £476,00022."

Documentum specifically gets a mention on page 24!

Page 27, "Applications developed by the BBC, such as DNA have also enabled user-generated content to
be more stimulating for the user and more efficiently managed. The current growth in web log usage also allows users to contribute richer content (e.g. to news stories) in the form of text, pictures, and audio and video clips."

Page 32: "BBC Online’s ambition to syndicate online content to other providers (for example, free and non-exclusive arrangements for commercial websites such as www.streetmap.co.uk to carry BBC news headlines), and to other devices (for example, free and non-exclusive arrangements with mobile providers to ensure position of BBC Online on WAP versions), is again, a means to drive towards 100% reach. Reach is a key means to ensure that increasing numbers of licence fee payers can derive some value from the BBC’s online services. This strategic goal does, however, risk the BBC being perceived by commercial operators as an aggressive, and unfairly advantaged competitive force. Submitters to the review also argued that the BBC’s current
inconsistent approach to linking, the prominence of BBC Online results in its search engine, and the low level of joint venture or externally commissioned projects have compounded this
impression."

Page 35 has a graph of BBC Online Expenditure, charted over the years... the division with the most expenditure is of course News with 15.5m in 2003/04, second is Nations & Regions with 11.6m and third is Factual and Learning with 10.1m.

That'll do for now, more on the technology assessment appendix tomorrow :-)

Basically I figured after more than ten years on the web, it was about time I got myself a blog.

Hopefully this one will be updated more frequently than my horrendous efforts on Advogato (wow! over three years of inactivity, is that a record?) and one on livejournal I think I created once but can't remember for the life of me... and for that matter my own website which is lucky to see an update every six months.

So why did I never update my blog/s before? I know exactly why. It's simple really. I never thought I had anything interesting enough to say.

I'm not like a lot of bloggers out there who seem to have the web equivalent of verbal diahrroea, enjoying the sound of their own voice (or is it the glow of their own pixels? or something like that).

I suffer from indecision -- or is it insecurity? From the paralysing thought that what I am now writing might be proven wrong tomorrow, derided in other blogs, laughed at by posterity. No matter what I write, I know that unless I believe in it unequivocally I will never be happy with it. And being a scientifically-minded sceptic, it takes a *lot* for me to believe in something unequivocally.

The other reason, which in a way is the same reason I guess, is that I am far too much of a perfectionist. I will spend way too long going back and editing everything I said, trying to make it read more fluently, grimacing at my woeful use of what is after all the only language I speak, trying to cram way too many ideas into way too few lines, and becoming even more obsessed with spelling and punctuation. I know blogs are supposed to be free form, conversational, and mostly unedited, but that's just not my way. I like structure, I like correctness, and I take the time to make sure things are right. Already I've lost count of the number of times I've deleted chunks of this post and re-typed them (including this very sentence).

So it's really taken me ten years to realise that these qualities can be seen as virtues, and if nothing else they make me different from most other bloggers out there. Hopefully it will at least end up that I say things with meaning, things worth reading. (Not so far, I'll admit.)

It's taken me ten years to realise that I actually have things to say, but they are still swishing around my brain, waiting to be released in a more permanent, more structured way. And the only way to get them out is to start writing about them. And a blog is as good a way to do that as any.

In a way I've been forced into doing this, because my job is now requiring me to think some more, and write some more, about what content management means and where it will be in a few years' time... Where will the world of web services, rich metadata, and peer-to-peer applications leave the still fairly push-centric world of digital publishing? What lessons can the relatively established practice of web content management teach the "serious" media and broadcasting companies that are finally waking up to truly converged, truly digital audio and video production? What new standards will emerge to guide us through this difficult process of making so many different systems, processes and people work together?

Of course you would think that being a full-time, self-employed content management consultant for a year during all of 2001 and part of 2002 would have forced me into thinking about what I stood for, and what content management really meant, but at the time it was revolutionary enough just to be someone who asked the right questions.

Now I want to start thinking about some answers.