uriplay for google tech talk (2008)
DESCRIPTION
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 areyou?
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 areyou 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, descriptionsand links between episodes
Why can’t we just blame the broadcasters?
Photo from:http://www.flickr.com/photos/hereinvannuys/1879221392/
they don’t own all the rights
Photo from:http://www.flickr.com/photos/yakanama/276195587/
they care about context
Why can’t we just blame the broadcasters?
Photo from:
http://www.flickr.com/photos/philandpam/1622589139/
Or,informationfriction
Good news #1: software grease
Good news #2: data exists
Wikipedia
Broadcasterwebsites
Schedule
Off air data
Title, synopsis, cast etc
Transmission times
Series linkage
Content URL
Link
TX time
TX time
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
View of (an) industry
Too complex
XML TV
Simple
No ‘on demand’
Encoding
Location“uri”
“bag of bits”
Policy
URIplay
a little more detail
Brand
Episode
Version
“show”
“episode”
“bag of frames” Broadcast
po
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:URIplayxmlns: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:RDFxmlns: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:
It’s Flexible
Inference built in
It’s Declarative
What we don’t like:
Flexible = Complex
Must ComputeDeductive Extension
Statements must be
Interpreted
What we learned
There is a big difference between an aggregatorand a data source
For a data source:
1 Encode the ontology as application logic and datamodel
2 Use views to separate definitive truths fromapplication details
3 Keep it simple
where we’re heading
linkmaker
TVnav
tagging
apps
uriplay.orgaggregator
?
apple.com
wikipedia.com
discovery.com
bbc.co.uk
Why is the BBC doing this?
Morecambe andWise Xmas Special 1977
Most watched show ever
3 channelsWe knew this because it was
simple then
The Prime Minister made us delay a(different) TV show because it would
affect electionresult !
Not like that now...
© BBC Picture Publicity
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 interopwell
We benefit too – you get to play, getyour hands dirty, make stuff with thisthat 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 thefirst version and design
In two weeks prime timedata time
End of May see it, use it
Lets talk more
http://uriplay.org/
http://groups.google.com/group/uriplay/