RDF Ontology

Working Draft

This version:

http://uriplay.org/spec/ontology/20090319.html [rdf]

Latest version:

http://uriplay.org/spec/ [rdf]

Previous version:

http://uriplay.org/spec/ontology/20081114.html [rdf]

Last Update:

Date: 19 March 2009

Authors:

Chris Jackson, Meta Broadcast

Contributors:

Ashok Argent-Katwala

Lee Denison, Meta Broadcast

See acknowledgements.

This document is published under the creative commons public domain licence.

Abstract

This specification defines the URIplay ontology. URIplay is a name service and data format for 'playable' media content, giving it URIs and simple descriptions. The service is suitable for describing delivery of TV and radio content, and other audio and video that was produced for non-broadcast delivery (e.g. podcasts and video blogs).

URIplay helps users to immediately find the right version of a video or audio program. This is necessary because media distribution has become too complex to handle through a simple user interface. URIplay summarises distribution information so that user's software and hardware can make the choices for her/ him.

Status of this Document

This is a work in progress! This document is changing on a regular basis. Comments are very welcome, please send them to chris at metabroadcast dot com.

Table of Contents

1. Introduction
2. URIplay ontology at a glance
3. URIplay ontology overview
4. Cross-reference for URIplay classes and properties

Appendices

1. References
2. Changes in this version
3. Acknowledgements

1. Introduction

Radio and TV were designed to be simple, to require minimum involvement. Our grandparents sometimes chose to change channel, but this was strictly optional. Today's technology has brought us more choice, freeing our viewing and listening from set schedules. However, alongside this choice, we users must deal with complexity. Increasingly, we are asked to decide not only what we would like to watch or listen to, but also via what route. PVRs, 'on demand' TV platforms, streaming websites and downloads each add to our technology choices.

Broadcasters have traditionally provided a simpler experience for audiences, but their recent technology and commercial choices are adding to the underlying complexity. Together with rights owners, they attempt to control the consumption of content through DRM, geo blocking, etc. Thus, content distribution via broadcasters' websites, hubs like YouTube, search engines and P2P downloads requires serious efforts on the side of the user—not our grandparents' experience.

See the URIplay home page for more details.

2. URIplay ontology at a glance

An alphabetical index of URIplay terms, by class (concepts) and by property (relationships, attributenames), is given below. All the terms are hyperlinked to their detailed description for quick reference.

3. URIplay ontology overview

URIplay describes the online distribution of 'playable' media such as films, TV programs, and radio programs. It builds on the work of the BBC Program Ontology, which has focused on defining the underlying structure of Episodes, Series (seasons), Brands (shows), as well as broadcast distribution. The main classes of URIplay are Encoding, Location, and Policy.

The Encoding class describes a unique 'bag of bits', which represent a Version of an Episode. It defines characteristics of the audio, video, and file container. For example, audioBitrate, videoBitrate, and videoFramrate are properties of Encoding.

The Location class wraps the URI at which an Encoding is available with a description of its expected behaviour. After the URI, the most important property of Location is transportType. This defines the type of behaviour that can be expected from the URI. Current options are:

download

The data can be retrieved via the URI, at a speed that is faster than needed to watch the content.

stream

The data can be retrieved via the URI, but the speed is limited to that required for live viewing.

embedobject

The URI points to an object that can be embedded in a web page. Distributor-specific restrictions are likely to apply, and may be described an associated Policy.

htmlembedded

The URI points to an HTML page in which the content is embedded.

indirect

The URI points to a further metadata file that describes how the content can be retreved.

Location also describes the dates and times from which content is accessible via this URI, and links to any distribution Policy that is required.

The Policy class allows description of distribution policies. These are typically applied by content distributors, for example by restricting the period during which content is available at the URI, or embedding 'DRM' features in the data. Policy also describes the revenue model that applies to the content, together with specific information such as the price of pay-per-view content or the subscription scheme required to gain access.

The structure of the class hierarchy is illustrated below.

Suggested values for some properties are listed on our vocabulary page

3.1. Example

Here is a very basic document describing an episode of the TV show 'Yes Minister':

<rdf:RDF
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:play="http://uriplay.org/elements/"
xmlns:po="http://purl.org/ontology/po/" 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
xml:base="http://uriplay.org/yes-minister/">

	 <po:Brand>
	  <dc:title>Yes, Minister</dc:title>
	  <dc:description>The wheeling and dealing of life in the British political scene...</dc:description>
	  <po:episode>
	   <po:Episode rdf:about="big-brother/">
	   <dc:title>Big Brother</dc:title>
	   <dc:description>Jim tries to implement a privacy safeguard...</dc:description>
	    <po:version>
	     <po:Version rdf:about="big-brother/main/">
	      <play:publishedDuration>30</po:publishedDuration>
	      <play:audioLanguage>ENG</po:audioLanguage>
	      <play:publishedDuration>300</play:publishedDuration>
	      <po:duration>321</po:duration>

	      <play:manifestedAs>
	       <play:Encoding rdf:about="big-brother/main/h264-500/">
	        <play:audioCoding>audio/mp4</play:audioCoding>
	        <play:dataContainerFormat>video/mp4</play:dataContainerFormat>
	        <play:videoCoding>video/H264</play:videoCoding>
	        <play:videoHorizontalSize>368</play:videoHorizontalSize>
	        <play:videoAspectRatio>16:9</play:videoAspectRatio>
	        <play:videoVerticalSize>208</play:videoVerticalSize>
	        <play:videoBitRate>512</play:videoBitRate>
	        <play:audioBitRate>128</play:audioBitRate>
	        <play:videoFrameRate>12</play:videoFrameRate>
	        <play:bitRate>640</play:bitRate>
	        <play:audioChannels>2</play:audioChannels>

	        <play:availableAt> 
	         <play:Location rdf:about="big-brother/main/mpeg4-mobile/example/">
	          <play:uri>http://example.com/f00678e</play:uri>
	          <play:restrictedBy rdf:resource="http://policy.uriplay.org/example"/>
	          <play:transportSubType>HTTP</play:transportSubType>
	          <play:transportType>download</play:transportType>
	          <play:transportIsLive>false</play:transportIsLive>
	         </play:Location>
	        </play:availableAt>

	       </play:Encoding>
	      </play:manifestedAs>

	     </po:Version>
	    </po:version>

	  </po:Episode>
	 </po:episode>

	</po:Brand>

</rdf:RDF>
				

4. Cross-reference for URIplay classes and properties

A. References

name

long name description...

[need to add links to TV Anytime, video format info, etc.]

B. Changes in this version

• 20080114: First version of spec published.
• 20080203: Minor updates.
• 20080407: Major updates, including integration with BBC Programme Ontology.
• 20080414: Minor updates.
• 20081114: Some new fields.

C. Acknowledgements

This document was produced with much help from:

Ashok Argent-Katwala

Who first suggested that we use RDF for this project, and has been trying to pursue us to uphold his own impressively high standards. Errors in this document are unlikely to come from him.

Lee Denison

Who has been implementing the spec, and identifying practical opportunities for improvement.

Gareth Klose

Who has brought much needed detailed knowledge of data formats.

Yves Raimond

For many helpful suggestions, particularly around opportunities to link with the BBC Programme Ontology.

George Wright

Who has helped us to match the ontology to the needs of a real broadcaster, the BBC.