Tuesday 31 July 2012, 12:00
The Olympic Data Services Team at the Broadcast Centre in White City
Hi, I'm Oli Bartlett and for the last 15 months or so I've been the Product Manager for the BBC's Olympic Data services.
We provide three main functions:
DSP has allowed us to dynamically publish a page per athlete as soon as we receive the information from the BDF. This page is linked in to the BBC sport website - it will link to pages on their events, their discipline and their country team. DSP also then allows us to aggregate relevant stories from BBC News and Sport onto each page on the Olympics website. Journalists simply have to tag the story with the people, sports or events it's about, and a link to that story will be pulled onto the relevant pages. Jem Rayfield has written an in-depth piece on DSP if you're interested in finding out more.
The BBC, like other broadcasters around the world, gets all of its Olympics data via a feed delivered over the internet and the majority of its Olympics video from the host broadcaster, Olympic Broadcasting Services (OBS). The London 2012 Olympics are the first where a combined video and results data feed (the BDF) has been made available. If you'll excuse the abbreviations: The BDF provides Olympic Data Feed (ODF) results and statistics from Locog, plus video data from OBS. In practical terms, this means that not only do we know the live results for every moment of every event, but we also know which video streams were showing the action at that time.
The BBC subscribes to the BDF and we receive it via our data provider Deltatre Media Ltd. The raw BDF is huge and contains a load more data than the BBC needs. Additionally the feed is stateful, so requires a relatively complex receiving system which knows how to apply updates as they arrive. Deltatre transforms the complex and stateful feed into a simpler, stateless feed which provides the BBC with just the data needed to power the online products. For example, a BDF update for a football match may say that Team GB have scored a goal. If you want to display a scoreboard, this information is of little use without knowing the previous state (score) in the match. The updates we get from Deltatre don't require the BBC to hold state for each unit, so the football update would instead give the current score: GBR 1 - ITA 0. This has allowed the BBC to simplify its processing of the data as we are not required to build the complex business logic required to manage stateful updates of statistics across the 10,000 units of competition. Instead, we can focus on getting the data out to the audience as quickly and reliably as possible.
So what does this mean for you?
Well, if you've used the interactive video player you'll probably have seen the Extras button in the bottom right of the player. One of the options here is the athletes panel. This shows you a list of the athletes competing in the event(s) you're watching. Additionally you'll see a picture of the athlete, a link to their page on BBC Sport, and their vital statistics - height, weight, date of birth. If you drill down further you'll see statistics from the event in which they're currently competing. This all works off our Olympic Data API which can serve up the latest results and statistics from any time during any of the 2,500 hours of video during the games. This means that when you rewind a live diving event, or watch a football match from yesterday, the athlete data and match stats stay relevant to what you're watching. Alex talks more about the interactive video player in his blog post.
In addition to the sports data, the Olympic Data API provides chapter markers and the Olympics Live data to the interactive video player. These features are primarily driven by the video logging messages we receive from OBS. Each time something interesting happens on one of the multitude of video feeds, the event will be logged by a team of people in the International Broadcast Centre, in Media City and at venues around the country. Whether it be a record being broken, the start of a new quarter in a basketball match, or a foul in a football match, we will get a notification. We take these notifications and, according to a set of business rules, create chapter points or Olympics Live alerts. As the games get underway we can monitor the frequency and accuracy of the chapter points and live alerts, and can change these rules dynamically if required. Additionally we have ways to manually add chapter points or live alerts for those moments the logging hasn't captured.
That pretty much summarises the Olympic Data services. Dave Rogers, the technical lead on this project, will be writing a follow-up post which will go into more detail around the architectural and testing challenges we've come up against, and the team's development approach.
Until then, enjoy the games!
Oliver Bartlett is Product Manager, Olympic Data, 2012
Join the discussion...
Monday 30 July 2012, 14:30
Wednesday 1 August 2012, 18:00