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