We had many positive feedback emails around this - people were planning their weekends around the F1 coverage - and so I did a little digging around to see what other people were up to around the BBC.

Tom Scott and Duncan Robertson wrote about the work that they did over a year ago on schedules. Duncan wrote on the radio labs blog:

"iCalendar is a standard for calendar data exchange. It is most notably used by Apple's iCal application, Microsoft's Outlook and Google Calendar, to import and export calendar information."

The one that caught my eye though was the athletics schedule that has been created - ideal with the world athletics just round the corner.

https://meleleh.pages.dev/programmes/genres/sport/athletics/schedules/upcoming.ics

As Duncan suggested in his post, I had a play around with the URLs to see what I could get specifically for sport.

This is what I managed to get for football:

https://meleleh.pages.dev/programmes/genres/sport/football/schedules/upcoming.ics

Be warned, this is all football on the BBC, TV and radio. It's a lot.

Then (with some advice from my colleague Alex) managed to break the feed down by platform:

https://meleleh.pages.dev/programmes/tv/genres/sport/football/schedules/upcoming.ics

https://meleleh.pages.dev/programmes/radio/genres/sport/football/schedules/upcoming.ics

which is a lot more manageable

Here are few others I found:

https://meleleh.pages.dev/programmes/genres/sport/cricket/schedules/upcoming.ics
https://meleleh.pages.dev/programmes/genres/sport/golf/schedules/upcoming.ics
https://meleleh.pages.dev/programmes/genres/sport/rugbyleague/schedules/upcoming.ics
https://meleleh.pages.dev/programmes/genres/sport/rugbyunion/schedules/upcoming.ics
https://meleleh.pages.dev/programmes/genres/sport/formulaone/schedules/upcoming.ics
https://meleleh.pages.dev/programmes/genres/sport/motorsport/schedules/upcoming.ics

I subscribed (don't use import!) to these feeds using the 'add by URL' function in Google calender

Other calendars are available! Not every format or bowser is suported at the moment but please feel free to have a play.

BBC schedules are published up to 7 days in advance so these don't show the whole football or F1 season. And it is TV and radio information. No additional red button or online only broadcasts.

The version we did for the F1 site has all the races and sessions that were being broadcast in for the season, which judging by the feedback, was what people wanted.

Let me know if you find this a useful feature. We already have feeds of programme and iplayer information on the sport site but having the broadcast information updated into an online version - and then maybe onto your mobile - seems like a good way to help avoid clashes with other commitments. Like holidays or work.

Major events like the Winter Olympics and the World Cup are ideal opportunities, although maybe the information being available a bit further in advance would be useful.

This is BBC broadcast data and not fixture data - I have already had requests in the office for full 6 nations fixtures and individual files for every football club. Not to mention motoGP and all major golf tournaments.

Maybe next season.

James Howard
Executive Product Manager, Sport

When the deal was signed for BBC Sport to have Football League and Carling Cup highlights on the site, we saw it as an excellent opportunity to revisit the club pages and the divisional indexes - as well as revisiting the way we do live coverage of each match.

Lewis Wiltshire on the sport site has explained some of the restrictions (we only have the highlights for 7 days and can only be put up 24 hours after matches).

There will be goals from every match and a round up of action from the Championship, League 1 and League 2 . Highlights will be on the site for 7 days and available to watch 24 hours after matches finish. The SPL pages have also been updated.

We knew that some of our club pages still hadn't been worked on since or last design iteration of teh Sport site and weren't doing a great job of showing off all the content that we had for fans.

The basic rule of thumb that we are using is that club specific information - stories, video, audio, data - goes into the main central column and information that was more generally about football on the site - The Gossip column, blog posts, broadcast information, iplayer details - goes into the right hand column.

All of these pages (over 100) have now been redesigned to accomodate video and more data that is specific to the clubs. We still have a few more modules to roll out once we have that data.

Our live coverage of all matches in the Premier League, Championship, League 1 and League 2 as well as the SPL also needed looking at. In the past we had a few pages where match data appeared and some of it was overwritten on a weekly basis.

The concept we worked to was known as 'one page/URL per match'. A single, permanent 'match page' for every game in the major league and cup competitions. Hopefully something that fans can use a reference to see who really did get that assist in that crucial midweek match.

As a process we start with the preview of the match, maybe written a couple of days previous to the game, and then the live data - the score, live text, team line ups and substitutions, goal scorers, bookings, possession, corners etc - gets added to the page just before kick off. And finally the match report, reaction and video highlights are added.

Live video will be added when relevant and there will be a "live as it happens" table that allows users to see the latest positions of clubs as goals are scored.

Work has also been done to improve the mobile offering so from today we are offering the option of customising your homepage. You can opt for club News, Results and fixtures on a per club basis (as opposed to divisional). Further roll outs will include the live text per match as well. No video on mobile though.

With fixtures coming thick and fast across these divisions - there are 36 in the Championship in the first 11 days and 30 odd Carling Cup matches - there should be a wealth of goals for you to watch.

Next big event for sport: Winter Olympics from Vancouver.

James Howard
Executive Product Manager, Sport

Back in 2008, Journalism embarked on a significant project to deliver a quicker, richer and easier to manage mobile service, to build upon the considerable achievements of the existing news and sport sites.

The project presented a number of challenges for the team, not least because it involved rationalising the systems used to produce the site. It's now managed and produced directly from the same system BBC journalists have been using for years, to publish content to the desktop sites. So it kind of felt like returning mobile to the mothership.

So now that we've re-launched the News and Sport mobile sites, how does this actually benefit the audience?

One of the biggest improvements is not something immediately obvious: Speed. Stories will now update around 60 seconds after journalists hit publish. That's comparable to the desktop site. My guess is that footy fans will be the first to notice the difference... live text commentaries will appear more...well, more 'live'.

Many Sport fans would already accept that the BBC's scores and results service on mobile is pretty quick, but faster publish times across News and Sport stories will also have a positive effect on the provision of breaking news stories. Let's face it, if users can't access the very latest content, they'll go elsewhere.

The new sites also surface more content, which strategically brings us more in line with W3C's One Web approach. So the 'More Top Stories' link has been scrapped, in favour of displaying those additional stories themselves. Headline browsing can be done at homepage level, without waiting to load unknown stories via the Next Story link.

At the bottom of each story page, we've also included related stories, special reports and comment forms in place of the 'Next Story'. So, although the 'Next story' links have gone, the links to a richer experience around the story you're reading should be a more useful replacement.

Navigating this greater depth of content should also be an easier task - such as jumping between the News and Sport homepages - and users will notice the familiar navigation panel from the desktop site. Also, improved access to more buried content now really complements the excellent new customisable BBC mobile homepage.

But it's not just great news for our audience; it's also been designed to streamline editorial workflows, as it means one less system for journalists to learn, making it easier to manage.

Operational support is also simplified and mobile now enjoys equality with the hi-web, in that full 24/7 support is now part of the deal. So dependability is a key feature, which is vital for Journalism. A multi-platform approach using a single system should intrinsically be more resilient, with fewer boxes involved in the publishing chain.

If all of this sounds rather mundane, then fear not, because there's still plenty of scope for innovation around news and sport on mobile. We need to be flexible about how we engage with existing and new audiences - and there are some fantastic initiatives underway which we hope will excite mobile users and deliver value for money.

It now puts us in a much better position to more rapidly iterate in future, so the journey is far from over. Beyond launching the service for international users in a couple of months and retiring the old PDA site, the next features to be added will be contextual audio / video (eg video links within stories), improved pictures, a much more useful sports results service and device-specific optimisation of the browser service. And watch out for greatly improved weather and travel sites on mobile - coming soon...

The project really marks another step in our march to Digital Switch Over (DSO), the government-backed initiative to convert the UK to a digital only TV broadcast infrastructure.  DSO will mean the eventual demise of Ceefax for the whole country by 2012, and one of our long term projects is to manage the transition of millions of Ceefax users to the BBC's Digital Text service.

DSO has meant the introduction of some new content to the Red Button service, including Flight Arrivals.  But it also means migrating some Ceefax functionality to Red Button too, in this case an element of dynamism into the top level that we felt was missing.

Now, on pressing red, a viewer watching any BBC channel can automatically see the latest News, Business, Sport and Entertainment headlines, as well as (where applicable) Weather warnings - without navigating to the individual indexes to find them.  Just as they've been able to do on Ceefax for years.  Sometimes moving into the future involves looking to the past.

Tristram Biggs is Executive Product Manager for TV Platforms in FM&T Journalism.

I've been working at the BBC for the last 2 years where I mainly work on the deep, dark internals of the main content management system used to produce the news and sport websites (as well as many other sites) - but that's another story for another day. Today, I'd like to share something  that I've been working on in my 'spare' time at the BBC.

One of the things that first struck me when I started at the BBC was the sheer scale of the news web site. Whilst I knew the site was popular and I was aware that the BBC produced a lot of content, I have to admit I wasn't aware of just how frequently new content is published on the site and how often existing content is updated. You might also be surprised at how frequently and constantly that we publish new content on the news site: almost literally 'every minute of every day' (although there tends to be slightly less content published in the early hours of the morning in the UK, as we don't force all our journalists to work all night).

One reason you may not be aware of how frequently we publish new content is that until now there has been no one place you can go to see all of the stories we publish on the news site. You can always monitor the front page or subscribe to RSS feeds of each of the various indexes you might be interested in - but you'll only see a small sub-set of all of the stories we publish.

The BBC News Radar displays a list of recently published stories from any section of the BBC News web site. It displays both stories that have just been published for the first time and stories that have been recently updated. We've had an internal application of the same name within the BBC for some time - so I can not claim any credit for the idea of displaying all of our new content in one place. This prototype has been developed to explore the idea of providing a publicly available version of this application. We look forward to hearing your feedback.

Historically FM&T Journalism has focused primarily on web development.  The reasons for this are many and none of them are any of my business but it is odd, because the first experiments that BBC News made with 'On Demand' started in the early 1970s and they were on television sets.  The experiment still exists today and it is called Ceefax.

The principle is relatively simple, take some text Journalists with access to agency feeds and ask them to write short news stories.  Then ask them to keep them updated, all the time.  And so On Demand Journalism was born - no printing presses or Six O'Clock bulletin to meet, just up-to-date information when the viewer wanted it.

Fast-forward thirty five years and those principles remain, albeit in a vastly improved, richer environment on the internet.  Now it's the Journalists writing the BBC News website that feed Ceefax and its digital progeny the BBC Red Button service.  And as we know from audience research, it's the Ceefax and Red Button services that are now seen as clunky and slow, particularly when compared to their online competitors.  So why do we persist with switching off analogue TV? Well the Red Button service is actually far richer than Ceefax could ever hope to be, but both services are at a disadvantage because of the underlying technology shared by analogue and digital, whether it be terrestrial, satellite or cable: Broadcast.

Television has always been about communities, the sports audience in the pub, the 'watercooler moment'  in the office or at school the next day, and now an increasing community around the iPlayer, DVRs, Twitter etc.  But if you free the device from the one-to-many model used for it's first 70 years the communities can be reached from within the TV itself, and the possibilities for programming are immense.

This is our motivation for exploring partnerships with companies involved with IPTV, and why we co-developed a prototype-application with Microsoft that was on show at IBC  earlier this year.  Microsoft Mediaroom  is set-top box software that (among other things) allows IP based assets to be overlaid on top of a broadcast signal on a TV set.  

Immediately this allowed us to replicate a number of things we offer on the web, on a home TV set.   A quick list would include:

• On demand video content
• Live video content (unlimited by bandwidth constraints we could offer one of as many streams as was navigationally prudent)
• On demand text and data content

•  Feeds of user generated content

• Simple personalisation (local News, Sport and Weather based on postcode)

Features that would be useful to Journalism were included, regardless of whether we have the back-end systems to support them at the moment:

• Simple linking from one video asset to another ("You've watched this - and this is related/background/might make you laugh")
  

• Deeper linking from one part of one video asset to another asset ("If you need a bit of help getting your head around watching this, then watch this first and then come back here")

• Send (a link to) the video to a friend's mobile or TV

Features not included (yet)

• Social networking ("Enjoyed Question Time this week?  Link to it on Facebook straight from your TV.")
  

• Alerts ("Your friend Jenny says - Stop watching Eastenders, look at this giant squid they've caught in Australia")

The demo continues to be shown by Microsoft at trade shows worldwide, as an advertisement for the flexibility of their platform, and I continue to show it off within the BBC as a device to get people talking about what IPTV can offer Journalism in the future.

What's been most exciting about the project has been seeing how Journalists react when they understand how they could allow their viewers to lead their own way through a story. 

The traditional News package about Karen Matthews (for instance) tells the story from the Journalist's point of view.  There are different treatments of this depending on whether you are watching The One, Newsround, Newsnight, ITN or Sky News. 

Or, you can split some of the different sections out in a linear way, on a website, like we did recently.

But if you allow the user to navigate the story themselves, from within the video, you allow them to create new versions of the story, all built from the same constituent elements and equally valid, but different in terms of tone or emphasis.

This comes down to the difference between On Demand media on the web and on TV, we're really in the dark here at the moment, as TV Platforms have some way to go to catch up with the web in terms of complexity of content offering and of audience behavior.  My hunch is that the two are very different, and eventually the preferred methods that the audience uses for "telling themselves the story" will be quite divergent.

Initial user testing on the model has been positive.  Not surprising, and we get this from all interactive TV research, is the tension between the linear TV programme the viewer was watching to start with and the interactive area they enter.  If this transition is too jarring then people feel like their 'focus' is being changed for them and they reject that. 

The TV is a device that people have a peculiar relationship with, they are normally in complete control of its functionality, but they can quickly become mesmerized under its spell.  We upset this relationship at our peril.

Tristram Biggs is Executive Product Manager for TV Platforms at BBC Future Media & Technology (Journalism)

When a journalist refers to someone in a news story they usually give the person's full name and enough information so the reader can understand who they are talking about. If the full name is ambiguous they may have to add a title or give an explanation about who the person is. But sometimes, especially for household names, the reader is expected to infer the identity of the person from the context of the story and by applying a reasonable level of background knowledge.

Whilst a human reader takes for granted their abilities to pick up journalists' cues and understand context, a computer has to be programmed explicitly. It is difficult to design a system that can identify people from text and disambiguate them. It is even harder to build a system that meets editorial standards of accuracy. However, in theory, it should be possible. So we've been experimenting to develop an approach that could lead to a system that reliably identifies people (and organisations) in stories and marks up their textual names with semantic information. There are four key challenges:

• Build working prototypes
• Write tests for the prototypes that express editorial standards
• Refine the prototypes to reach defined levels of reliability
• Express the information usefully through semantic mark-up

Prototypes

The prototypes are ready to share with you. They have been built for us by a company called Rattle Research based in Sheffield. They were a successful participant in the BBC Innovation Labs.

There are two systems available. They are both based on DBpedia (the structured version of Wikipedia) which provides the controlled vocabulary of people and organisations. Therefore, in these prototypes each person in a news story is described by their Wikipedia entry. Potentially, Wikipedia is a good controlled vocabulary source for news because it has wide scope, is open and dynamic. It is certainly useful for prototyping.

• The first method is called "Muddy". It works by extracting proper names from the story text and then matches them to entries in DBpedia. If a term is ambiguous, the system uses various strategies based on Wikipedia's disambiguation pages and the structure of DBpedia to resolve the conflict. More information can be found on Rattle's website here
• The second method is called "conText". It was initially proposed by Chris Sizemore and is described in detail in his blog post here. This method uses search technology (Google and Lucene) to enhance the results further.

The good news for anyone who is not an expert in term or knowledge extraction is that Rattle implemented both methods behind a common abstract API. In effect we can treat both methods like black boxes. We don't need to know how they work to use them and evaluate their ability to identify people.

In addition, Rattle implemented some visualisations so that we can get a feel for how the systems work. Below are some sample stories that have had people and organisations identified. You can also submit additional stories by following the final link.

• Blears attacks political bloggers
• Obituary: Sir Bill Cotton
• Obama's uphill task on US economy
• Branagh comeback up for top award
• Submit a new Story

Testing

It doesn't take long to see that neither prototype is perfect. Sometimes they miss people and sometimes they get them wrong. But that is the point of the research. How good are they really and can they be improved? Our next step is to measure them against our editorial standards.

So currently we are working with another Innovation Labs entrant ThinkTankMaths to develop some tests. We're going to compare the performance of both systems (and any system that implements Rattle's API) to the performance of human beings. We will also be proposing measures that evaluate the systems from an editorial point of view. For example, is it editorially more acceptable for the system to fail to spot the name of cat owner whose cat gets stuck in a tree than the Prime Minister? And what should the system do when the name of that cat owner is Gordon Brown?

We will post more about this and our initial findings in the New Year, but in the meantime we'd like to hear your thoughts and feel free to have a look at the API and the prototypes.