Upcoming SlideShare
Loading in...5

URIplay for Google Tech Talk (2008)






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

URIplay for Google Tech Talk (2008) URIplay for Google Tech Talk (2008) Presentation Transcript

  • Who? a growing working group
  • …hmm
  • One show, numerous locations Hundreds of broadcast places/times Tens of web locations Numerous versions Countless copies
  • Hoop jumping What time is it? Photo from: http://www.flickr.com/photos/mikeandanna/89727979/
  • Hoop jumping Where are you? Photo from: http://www.flickr.com/photos/jasoneppink/386297223/
  • Hoop jumping What device do you use? Photo from: http://www.flickr.com/photos/kevinsteele/566664400/
  • Hoop jumping How are you paying? Photo from: http://www.flickr.com/photos/tjt195/53998619/
  • Picture from: http://flickr.com/photos/dhammza/88644497/
  • 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
  • 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/
  • Why can’t we just blame the broadcasters? Or, information friction Photo from: http://www.flickr.com/photos/philandpam/1622589139/
  • Good news #1: software grease
  • 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
  • What we are doing 1 simple design • XML Data Format (also RDF) • API 2 first implementation 3 some crawlers
  • What we are not doing http://www.flickr.com/photos/mattlogelin/360329081/
  • Starting points TV Anytime XML TV View of (an) industry Simple Too complex No ‘on demand’
  • a little more detail po URIplay “show” Brand “episode” Episode “bag of frames” Version Broadcast “bag of bits” Encoding “uri” Location Policy
  • 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
  • We’re a service describing resources Reinvent nothing means: Big design choice: should we use RDF?
  • In plain old XML <Brand> <title>Yes Minister</title> <Episode> http://uriplay.org/yesminister/s01e01/ </Episode> <Episode> http://uriplay.org/yesminister/s01e02/ </Episode> </Brand>
  • 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>
  • 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>
  • 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>
  • 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
  • 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
  • where we’re heading bbc.co.uk apps link discovery.com maker aggregator TV nav uriplay.org tagging wikipedia.com ? apple.com
  • 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...
  • 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/
  • 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
  • Lets talk more http://uriplay.org/ http://groups.google.com/group/uriplay/ chris@metabroadcast.com lee@metabroadcast.com george.wright@bbc.co.uk