URIplay for Google Tech Talk (2008)


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

URIplay for Google Tech Talk (2008)

  1. 1. Who? a growing working group
  2. 2. …hmm
  3. 3. One show, numerous locations Hundreds of broadcast places/times Tens of web locations Numerous versions Countless copies
  4. 4. Hoop jumping What time is it? Photo from: http://www.flickr.com/photos/mikeandanna/89727979/
  5. 5. Hoop jumping Where are you? Photo from: http://www.flickr.com/photos/jasoneppink/386297223/
  6. 6. Hoop jumping What device do you use? Photo from: http://www.flickr.com/photos/kevinsteele/566664400/
  7. 7. Hoop jumping How are you paying? Photo from: http://www.flickr.com/photos/tjt195/53998619/
  8. 8. Picture from: http://flickr.com/photos/dhammza/88644497/
  9. 9. Some simple requirements Vital Permanent URIs Vital Deterministic behavior – A file is available – It contains the right version – The file plays – The quality is high enough Really Nice Reliable titles, descriptions and links between episodes
  10. 10. Why can’t we just blame the broadcasters? they don’t own all the rights they care about context Photo from: Photo from: http://www.flickr.com/photos/hereinvannuys/1879221392/ http://www.flickr.com/photos/yakanama/276195587/
  11. 11. Why can’t we just blame the broadcasters? Or, information friction Photo from: http://www.flickr.com/photos/philandpam/1622589139/
  12. 12. Good news #1: software grease
  13. 13. Good news #2: data exists Wikipedia Title, synopsis, cast etc Link Broadcaster Content URL websites TX time Schedule Transmission times TX time Off air data Series linkage
  14. 14. What we are doing 1 simple design • XML Data Format (also RDF) • API 2 first implementation 3 some crawlers
  15. 15. What we are not doing http://www.flickr.com/photos/mattlogelin/360329081/
  16. 16. Starting points TV Anytime XML TV View of (an) industry Simple Too complex No ‘on demand’
  17. 17. a little more detail po URIplay “show” Brand “episode” Episode “bag of frames” Version Broadcast “bag of bits” Encoding “uri” Location Policy
  18. 18. The API: Main types of URI http://uriplay.org/$brand(/$episode(/$version(/$encoding)))/ e.g., http://uriplay.org/holby-city/s10e16/ http://broadcast.uriplay.org/$broadcaster/$w3_datetime/ e.g., http://broadcast.uriplay.org/five.tv/2007-02-16T20:00/ http://policy.uriplay.org/$distributor/$identifier/ e.g., http://policy.uriplay.org/bbc.co.uk/iplayer-streaming/ http://api.uriplay.org/lookup/?uri=$uri
  19. 19. We’re a service describing resources Reinvent nothing means: Big design choice: should we use RDF?
  20. 20. In plain old XML <Brand> <title>Yes Minister</title> <Episode> http://uriplay.org/yesminister/s01e01/ </Episode> <Episode> http://uriplay.org/yesminister/s01e02/ </Episode> </Brand>
  21. 21. In XML+namespaces <play:URIplay xmlns:play="http://uriplay.org/elements/” xmlns:dc=“http://purl.org/dc/elements/1.1/”> <play:Brand> <dc:title>Yes Minister</dc:title> <play:Episode> http://uriplay.org/yesminister/s01e01/ </play:Episode> <play:Episode> http://uriplay.org/yesminister/s01e02/ </play:Episode> </play:Brand> </play:URIplay>
  22. 22. In RDF/XML <rdf:RDF xmlns:play="http://uriplay.org/elements/” xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns:dc=“http://purl.org/dc/elements/1.1/”> <play:Brand rdf:about=“http://uriplay.org/yesminister/”> <dc:title>Yes Minister</dc:title> <play:episode rdf:about=“http://uriplay.org/yesminister/s01e01/”/> <play:episode rdf:about=“http://uriplay.org/yesminister/s01e02/”/> </play:Brand> </rdf:RDF>
  23. 23. the interesting bit <play:Encoding rdf:about=“http://uriplay.org/yes- minister/s02e03/main-version/mpeg4-512/”> <play:videoBitRate>512</play:videoBitRate> <play:videoCodec>video/h264</play:videoCodec> <play:audioBitRate>128</play:videoBitRate> <play:audioCodec>audio/aac</play:audioCodec> <play:Location rdf:about=“http://uriplay.org/…/iplayer> <play:uri>http://www.bbc.co.uk/iplayer/…</play:uri> <play:restrictedBy>http://policy.uriplay.org/iplayer- iphone</play:restrictedBy> </play:Location> <play:Location rdf:about=“http://uriplay.org/…/iplayer> <play:uri>http://other.com/…/s02e03</play:uri> </play:Location> <play:Encoding>
  24. 24. RDF: travels of a data source provider What we like: What we don’t like: It’s Flexible Flexible = Complex Inference built in Must Compute Deductive Extension Statements must be It’s Declarative Interpreted
  25. 25. What we learned There is abig difference between an aggregator and a data source For a data source: 1 Encode the ontology as application logic and data model 2 Use views to separate definitive truths from application details 3 Keep it simple
  26. 26. where we’re heading bbc.co.uk apps link discovery.com maker aggregator TV nav uriplay.org tagging wikipedia.com ? apple.com
  27. 27. Why is the BBC doing this? Morecambe and Wise Xmas Special 1977 Most watched show ever 3 channels We knew this because it was simple then The Prime Minister made us delay a (different) TV show because it would © BBC Picture Publicity affect election result ! Not like that now...
  28. 28. What do the public and you get out of us doing this? Easier to choose what you want Don't have to care about codecs, etc. Devices and web services interop well We benefit too – you get to play, get your hands dirty, make stuff with this that we couldn't We help a free software project – we hope it'll help us. CC licence http://flickr.com/photos/hddod/865542747/
  29. 29. Getting involved Right now we’re finalizing the first version and design In two weeks prime time data time End of May see it, use it
  30. 30. Lets talk more http://uriplay.org/ http://groups.google.com/group/uriplay/ chris@metabroadcast.com lee@metabroadcast.com george.wright@bbc.co.uk