Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BBC Programmes Ontology XTech2008

An overview of of the BBC's work on exposing an API for programme metadata as presented at XTech08. More information on the Radio Labs blog:

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

BBC Programmes Ontology XTech2008

  1. The Programmes ontology Tom Scott & Nick Humfrey BBC FM&T for Audio & Music Clearly the BBC broadcasts a lot of programmes both on TV and Radio - but until recently we haven’t done a wonderful job of supporting these programmes on the web. What we would like to talk to you about today is a recent project - to provide all BBC programmes a permanent web presence and to formally describe and model this information through an ontology.
  2. Historically The BBC has been providing programme support for sometime The BBC has been building programme support websites for a while now - all the radio networks have websites and the major TV shows also have sites. So the BBC does have a legacy of providing programme support - unfortunately there are problems. For starters it’s not complete - most programmes don’t have webpages and the support sites that do exist aren’t comprehensive, they don’t provide a complete record of a programme... for example generally we haven’t published episode pages. So there are gaps. Also...
  3. Historically But the data has been siloed... The data has been siloed - it’s not easily accessible to the rest of the web. The data is trapped within a bunch of web pages - with little or no thought for machine consumption. Historically our focus has been on building microsites for end users - hand crafted html pages, without a consideration for their semantic mark-up. Let alone exposing the data in a structured fashion via an API.
  4. Historically ...and ephemeral And unfortunately we also have a tendency to delete our web pages or reuse our URLs. So the data we do make available doesn’t hang around on the web.
  5. Historically ...which is a shame because we broadcast between 1,000 and 1,500 programmes a day During the week and excluding local radio programme the BBC broadcasts about 1,500 programmes a day. So if we can solve these problems then we can make a lot of useful metadata and media available to the web. And this is where BBC Programmes comes in.
  6. /programmes BBC Programmes launched in October aims to solve these problems We launched BBC Programmes last October with the aim of providing every programme a permanent, findable place on the web. We also wanted to make a fully fledged web 2.0 citizen; exposing BBC Programmes using the principles of Linked Data. We wanted to make a RESTful API exposing the data in a variety of formats for people and machines.
  7. One page per programme At the heart of this service is the idea of one URL per programme. Or more accurately a page for every Episodes, Series and Programme Brand. All with unique IDs - and persistent URLs
  8. Useful aggregations Date (schedule) Genre Format A-Z Topic (coming soon) We’ve also publishing a bunch of aggregations for example genre, format, schedules. And in the very near future by subject or topic and music artist.
  9. Design approach Identify your resources Make them addressable Combine resources to make a page I wanted to touch on our design approach because it has made our lives very much easier when developing the ontology and in creating alternate views. How we’ve gone about this is to first identify our resources - those things that we want to reuse or let people consume. Once we’ve done that we need to make them addressable at persistent URLs. So that each resource, each concept has it’s own URL And then combine those resources into public facing web pages. In other words each of our web pages are made up of reusable resources.
  10. Resources So for example if you take an episode page it’s made up of...
  11. Resources Embedded Media Player (iPlayer) The embedded iPlayer
  12. Resources A list of cast and crew. Addressable at /programmes/:id/credits
  13. Resources And a list of broadcasts at /programmes/:id/broadcasts (not currently linked in)
  14. Mobile representations Different set of resources Different view This means that we creating alternate representations relatively straightforward. We’re working on a mobile view. But rather than creating an entirely separate parallel site or applying a mobile css to the existing site we adopted a third option. Instead we can pick and choose from a common set of resources but combine them in a different fashion to create a mobile site optimised for that platform. And the same logic applies when creating the RSS, RDF or any other machine views.
  15. Linked data JSON YAML XML RDF Microformats All we need to do is decide what resources need to be made available and a set of specific views to create different representation of this data for machines to consume. We’re in the process of making RDF, JSON, RSS, ATOM, iCal views. Oh and by the way all the html pages are marked up with microformats. We are doing all this with the objective of make it as easy as possible for people to integrate with our content. And this resource centric approach has made this job easier - it also made designing the ontology very straight forward - because in essence the resources were the classes within the ontology. We designed the site to be a web of data from the outset.
  16. The ontology Brands Series Programme Episodes Content Publishing Service (Creative Commons license) Version Event Broadcast This then is the ontology. Its released under a creative commons license so anyone is free to use it or modify it It provides web identifiers for the concepts that make up a tv or radio programme such as brand, series, and episode. It’s divided into two main parts. First, it captures categorical information about programmes, and the relations between such categories.
  17. The ontology Brands Series Programme Episodes Content Service So the content. A programme must have at least one episode but multiple episode can be grouped into one or more series or a brand. You can think of series and brands as a decorator pattern to the episode. In any case an episode or set of episodes grouped into series and brands constitutes a programme which in turn is then owned by a service, such as Radio 1 or BBC 2.
  18. Brand So for example Waking the Dead programme brand.
  19. Series Which is currently in it’s 7th series.
  20. Sub series Each weekly story is divided into...
  21. Episode Two individual episodes. All these are independent of the broadcast - and it is these content objects that are the primary, addressable resources within BBC Programmes. Not the individually broadcasts.
  22. Episode It’s worth noting at this point that the idea is not for Programmes to become a new brand nor portal. Rather all the major brands - those with existing sites - will incorporate these pages into their sites.
  23. The ontology Service Publishing Version Event Broadcast The other half of the ontology addresses the publishing of that content. An episode can have multiple versions - for example Torchwood has an adults and a children’s version. A service broadcasts a version.
  24. URL design{/:service}/programmes/genres/:genre Our primary focus when it came to designing the URLs for BBC Programmes was to ensure that they remain persistent – with each URL representing a single concept. What we’ve ended up with are two classes of page: aggregations and objects. The aggregations are human readable, easily hackable and return a list of objects. They include schedule views, aggregation by genre, format and a to z. For example, here is the url for a list of music programmes on BBC 1
  25. URL design The objects however follow a simpler pattern: Where :id is an eight digit alphanumeric code. We’ve been asked before why the urls are opaque Our decision to use opaque URLs was driven by the need to provide persist identifiers. If we had included information about the programme brand (e.g. the Today Programme) or service (e.g. Radio 3) then there would have been a high risk that the URLs would have either changed or no longer reflected the ‘owning’ brand since programmes are often rebroadcast on different services. By stripping the URL back to a unique identifier we removed any future (or current) ownership issues.
  26. Show me the data Each representation is addressed by appending the name of the appropriate serialization to the end of the URL Currently we have XML, YAML and JSON representations for the various schedules. These can be accessed by added the name of the appropriate serilisation to the end of the URL.
  27. Show me the YAML london/today.yaml This is BBC 1’s london schedule for today as YAML.
  28. YAML This is what you get
  29. Show me the XML Or Radio 4’s FM schedule as XML
  30. XML Returns this
  31. RDF Not quite live yet (sorry) Try it out at:
  32. RDF
  33. RDF
  34. RDF
  35. The near future radio POP More representations SPARQL interface APML XMPP Music and more Sky Captain and the World of Tomorrow In the very near future we’ll be launching with more representations: for example iCal, Atom, RSS and all of the view - not just the current limited set.
  36. SPARQL D2R Server Maps relational database to RDF Around 5 million RDF triples By using D2R to map the relational database to RDF we can expose the data via a SPARQL end point. Through the use of SPARQL, we can query the data using a variety of constraints that cannot be easily expressed through the Programmes web interface. We are also able to semantically connect to external data sources such as DBpedia to provide extra information that is not present in our dataset, such as date and place of birth of cast members.
  37. APML Programmes pay attention to artists and topics Programmes can be thought of as paying attention to music artists and topic. For a while now we’ve been feeding the artist data into The plan is to expose this and data about topics (people, places, time periods and subjects) as APML.
  38. XMPP Pubsub Allows a person or application to publish information so that an event notification (with or without payload) is broadcast to all authorized subscribers We’re also investigating the use of XMPP - as a way of pushing epg data to interested devices, both programme metadata and 'on now' notifications Of course this does mean that you need a pub-sub client i.e. one that can handle the XML output. Of which there aren’t very many!
  39. XMPP Publish Message If you do get your hands on a client this is what you get. At the start of every radio broadcast XMPP publishes metadata about that show to its station's node, wrapped in an Atom Entry. For your Linked Data entertainment it's also serialised as Turtle RDF conforming to the Programmes Ontology. If you would like to find out more have a look at the BBC’s Radio Labs blog.
  40. XMPP Pubsub Extra bonus demo... [last minute hacking from Patrick] Programmes ontology over XMPP notifications via Growl
  41. More of the graph Music, events, people, topics and more What I’ve been talking about today is the work on Programmes - we are also working on exposing music information in a similar fashion. One page for every artist the BBC plays. And Ben Smith, who is also talking at XTech, is working on the user end of the graph. That leaves Topics - which will be connected to Programmes next month. And events - live events - which is a little way off. And - we’re in the process of adding: - World Service - The back catalogue (75 years of data) - Local Radio
  42. Thanks to Michael Smethurst Patrick Sinclair Yves Raimond Matt Wood Paul Clifford Duncan Robertson Jamie Tetlow Rija Menage Steve Butler Finally we would like to thank those that have done most of the work. And if you are interested in joining us there we’re currently hiring software engineers.
  43. Questions?