Another post about the BBC! I’m not apologizing, but the reason I like to post on them is that in a number of past projects I’ve had the pleasure of working with several BBC teams. I always enjoy working with their teams because they are a very smart group and are always trying lots of cool cutting edge things.
This month I have been following the semantic technology work done by the /programmes team, the /music team (see previous post) and the Radio Labs team.
There’s nothing extremely groundbreaking with the concepts that they are employing. However, it is the combination of those concepts and their use in the domain space that is most interesting to me. My team has been pushing for many of these same concepts within our own solution offerings for the Media & Entertainment sector as well.
The core concepts of the Linked Data initiative seem to be fundamental to a lot of the new media work being done by the BBC. The rules of “linked data” in respect to Media assets and Digital Asset Management make a lot of sense. It not only makes it easier to discover metadata about media, it also makes it easier to aggregate metadata from multiple sources, and easily discover such things as rights, copyright, and usage information.
The four rules of Linked data are the following:
- Use URIS as names for things.
- Use HTTP URIs so that people can look up those names.
- When someone looks up a resource through its URI, provide them some useful information.
- Include links to other URIs, so that they can discover more things.
Seems very simple, and in fact using these rules in designing a next generation Digital Asset Management solution is not very difficult (although there are some design issues that you should be aware of).
Exposing the assets or “entities” via a well known URI is fundamental to the ability to link stuff together that was not originally designed or intended to be linked. Following these simple principles allows for easy “mesh-ups” for consumer and B2B oriented media metadata exchange. By building asset management systems in such a fashion, it becomes much simpler to build out program guides, EPGs, content aggregation portals like Hulu, Joost, and the BBC iPlayer.
Another aspect of the BBC’s work that I am interested in is their use of OWL ontologies to define their domain model. The Programmes ontology defines the vocabulary for how to describe a brand, series or episode on the BBC’s web properties. Their ontology follows similar ones in the Semantic Web in that it reuses or imports vocabulary from existing well known ontologies such as Dublin Core and Friend of a Friend (Foaf). This is the approach that I took with the development of the IMM Core ontology in the Interactive Media Manager (IMM) solution for Digital Asset Management. Our domain model was based on the abstract model for MPEG-21 Digital Item Declaration language which I will cover in a future posting.
In the case of IMM, a lot of our URI designs followed rule #1, however we failed to provide the ability to effectively implement rules 2 and 3. Our URIs all begin with http://, but due to the nature of SharePoint being the underlying platform, we did not provide a simple way to make our resource URIs land on a page that showed meaningful data or links to related URIs. This is something that should be simple to address in a future release.
I really appreciate the way the BBC service is offering persistent URIs with the ability to adjust the serialization by adding a simple extension such as .xml, .yaml, .rdf, or .json to the end of the URI. The BBC team’s underlying development should serve as a best practice for the media industry and will lead to the growth of the Semantic Web through linked data. I’d love to see all M&E companies begin to embrace these patterns.

2 comments
Comments feed for this article
January 31, 2009 at 12:04 pm
Eric
http://blogs.talis.com/nodalities/2009/01/building-coherence-at-bbccouk.php
January 31, 2009 at 12:04 pm
Eric
If you haven’t seen the above article you should check it out. It’s a great read from someone on the BBC programmes team outlining their approach and some of the reasons behind why they made the decisions they made.