uriplay for google tech talk (2008)

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/

chris@metabroadcast.comlee@metabroadcast.comgeorge.wright@bbc.co.uk