Using media rss to syndicate and share media

From Bjoern Hassler's website
Jump to: navigation, search
syndication  |  resource discovery  |  formats  |  Syndication and metadata  |  Using media rss to syndicate and share media  |  Media rss media group element  |  Overview of images in rss  |  Category:Syndication
Using Yahoo media for content aggregation
Working with Yahoo Media
Using media rss to syndicate and share media
Example feeds
short item
full item
The yahoo media content and group elements
Enclosures in yahoo media, rss, and atom
Media rss media group element
Media rss media group alternatives scheme
Atom media extension
Overview of images in rss

Printing and index

1 Using yahoo media for content aggregation[edit]

A quick page about syndication, and in particular about using media rss to syndicate and share media.

Stepping back, the question is two fold:

  • How do you let people know what 'stuff' you have and where your 'stuff' is?
  • Suppose we're looking at a 'piece of stuff' that you wanted to syndicate content across institutions, then what sort of metadata would you need to exchange in order to be able to build a common repository?

The first question is discussed here resource discovery. For the 2nd question read on.

Before we review media:rss in detail, let's have a quick look at what media:rss is!

2 Super fast overview of Yahoo media and relation with Atom[edit]

Some links to media rss.

The current "Yahoo Media" Specification is Version 1.1.2, and yahoo media is an RSS module that supplements the <enclosure> element capabilities of RSS 2.0 to allow for more robust media syndication.

The media namespace can be used in rss:

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:media="">

but it could just as easily be used in atom:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="" xmlns:media="">

There is an argument that it link be better to extend the "link" element of atom. From the perspective of this article, this is a purely semantic argument: We are trying to determine (first and foremost) which metadata needs to be included in the feed. Media rss is a good paradigm for this, but the details could be implemented in atom.

Further details and comparison here: Atom media extension.

The main two elements introduce by yahoo-media are <media:group> and <media:content>. These are sub-elements of <item> (or <atom:entry>):

		<media:content />
		<media:content />
		<media:content />
	<media:content />
	<media:content />
	<media:content />

Also, <media:content> can be a sub-element of <media:group>. "Media objects that are not the same content should not be included in the same <media:group> element. The sequence of these items [media:group or media:content outside media:group] implies the order of presentation."

Besides these two elements, the following elements can be sub-elements of <channel>, <item>, <media:content> and/or <media:group>: <media:rating> <media:title> <media:description> <media:keywords> <media:thumbnail> <media:category> <media:hash> <media:player> <media:credit> <media:copyright> <media:text> <media:restriction>. More information at

3 Why media rss is good![edit]

In my view, media rss is helpful in two ways:

  • Media rss itself makes a good format for media syndication: It's close to rss/podcast rss/iTunes(U) rss. It could be argued that other formats are better (such as atom), but media rss is an existing standard, that's fairly widely uesd for the purpose of media syndication, so it makes sense to use it. Plus there are a lot of parsers out there, that can handle media rss out of the box.
  • If you don't use rss, but use atom instead, you can still use the media namespace in atom.
  • Even if you weren't going to use the media namespace (but used some other standard), looking at the data passed around in media rss is still useful in terms of deciding what data you'd need to pass around.

So let's go through media rss and see what works, and what might need tweaking. Remember the perspective:

If you were to syndicate content across institutions, what sort of metadata would you need to exchange in order to be able to build a common repository?

This page offers some thoughts on this, and suggests some ways in which the available elements in media rss could be used.

4 Credits[edit]

Media rss offers the media:credit element, but there are two issues with this:

  1. To defined a suitable credit scheme to describe people participating in academic events (can use existing media:credit element with suitable scheme), such as the moderator ('anchor person'), and principal lecturers, as well as participants in round table discussions. (People asking questions, 'audience'.) People being asked onto the stage.
  2. Ideally, we have a way of recording the academic title of the person, as well as the affiliation.

Putting forward a new scheme is easy:

<media:credit role="principal lecturer" scheme="some new scheme">Some Name (Perhaps affliation)</media:credit>

At least, this gives us a human-readable version of the credit, and the <media:credit> should be interpreted as human-readable verision. However, ultimately a more complex (and machine readable) name and affiliation requires an extension of media rss:

<extendedmedia:credit role="principal lecturer" scheme="some new scheme">
       <extendedmedia:firstname>Some Name</extendedmedia:firstname>
       <extendedmedia:lastname>Some Name</extendedmedia:lastname>
       <extendedmedia:affiliation>Some University of Something</extendedmedia:affiliation>
       <extendedmedia:extraaffiliation>Some institute at that university</extendedmedia:extraaffiliation>

or an alternative solution based on atom. For now, we should use <media:credit>.

5 (sub)Titles and series[edit]

5.1 Subtitles[edit]

Objective: A suitable way of adding series titles or sub-titles.

The best way to add this might be via extending media rss,

<media:title s:type="subtitle">How to set up an item in an rss feed</media:title>

Similarly, we can add a shortened version of the title:

<media:title s:type="short">The title</media:title>

5.2 Series titles[edit]

Similarly we can add a series title, or a course title

<media:title s:type="series">An item in our demo series</media:title>
<media:title s:type="course">The title</media:title>

You may wish to add a category to reflect a series or a course as well:

<category domain="my domain/courses">Courses/Spring2009/Economics 101</category>

6 Categories[edit]

6.1 Subjects[edit]

Generally speaking, categorisation can be taken care of via the category/domain mechanism, where the domain attribute is used to indicate the relevant scheme

<category domain="">100100</category>

Generally, catom:category or media:category is preferable, because it allows both for a term, and a label:

 <atom:category scheme="...british library..." term="..." label="..." />

 <!-- additional classification into iTunes subjects -->
 <atom:category scheme="" term="101" label="General Science" />
 <atom:category scheme="" term="104101" label="..." />
 <atom:category scheme="" term="108" label="..." />

 <!-- local classifications can also be added -->
 <atom:category scheme="" term="..." label="..." />

Similarly, one may want to categorise content by institution. One could opt for a hierachical set of categories

<category domain="worldwide HE insts">url of institution/faculty/department</category>
<category domain="worldwide HE insts"> for Applied Research in Educational Technologies</category>

where it would be up to the institution to standardise on names and hierarchies within the institution (most institutions will have this, and will have some kind of institutional directory, LDAP or otherwise, that holds this information).

Overall, it would make more sense to adopt this instead:

 <atom:category scheme="" term="" label="Oxford University" />
 <atom:category scheme="" term="<e.g. via LDAP>" label="Section of Physical Sciences" />
 <atom:category scheme="" term="<e.g. via LDAP>" label="Physics Department" />
 <atom:category scheme="" term="" label="" />

where for 'term' e.g. can use LDAP identifier. Terms needs to be identified at

"Organisation" is mandatory (if not given at feed level), others are not mandatory. Institutional or departmental classification: not needed here if included in the feed head

7 Links[edit]

Links back to contextual pages at the institutions are needed.

8 The media:content element[edit]

The media:content element is reasonably complete, and allows the specification of media alternatives. It basically looks like this:

              lang="en" />

There are some issues with <media:content> that we will explore on the following pages. This is for instance to do with the fact that codec information is missing, which for playback of content in flash 9 is crucial, and hence we propose an extension, see Media_RSS_Extension:

The <media:content> element is enclosed in a <media:group>, that allows us to specify alternatives. An issue to do with media group is that we want to to distinguish different sets of media, such as

  • The main content (say video)
  • A signed version (provided for access)
  • An audio-only version (provided for access)
  • Supplementary materials (such as a pdf with the slides)

Those different sets can be put together via media groups to group different types of media, but there is no scheme that distinguishes what the <media:content> items with a group do. However, the <media:category> element (with a suitable scheme) can help. It can be a sub-element of channel, item, media:group and media:content.

  <media:category scheme="" label="supplementary materials">supplementary</media:category>
  <media:content url="" fileSize="522163" type="application/pdf" medium="document" isDefault="false" expression="full" lang="en">
    <media:category scheme="" label="slides">slides</media:category>

We will discuss this in the following sections, and further details on media rss media group element and Media rss media group alternatives scheme, and the actual scheme.

9 Alternatives to web-based delivery[edit]

The above presumes direct internet access to the resources, such as a streamable or downloadable move. However, in various circumstances (such as low bandwidth situations, or in schools, where access to certain site may be blocked) it is equally important to have alternative sources. We discussion two cases.

9.1 Case 1: The content is available in a content repository[edit]

The media:rss needs to know the id within that repository, so that if the repository is available locally, the content can be retrieved.

9.2 Case 2: Alternatives to "http"[edit]

There may be other protocols over which the content can be retrieved, the most likely candidate being bit-torrent. In that case, it is important to know how to locate the torrent, quite possibly without recourse to the web (as the web may not be available). If the resources shared through the rss feed know about their primary location, and the torrents can be discovered based on that primary location, then this would work. Otherwise a torrent-id would need to be included in the media:rss feed.

9.3 Caching?[edit]

Of course content may also be available in a local cache (either by accident, or persistently), but in that case we don't need to do anything, as the content is cached transparently.

10 Images[edit]

Having a look at Overview of images in rss, we see that the <media:thumbnail> tag is more flexible. ("Allows particular images to be used as representative images for the media object.")

We assume that a <media:thumbnail> without timing, as sub-element of <item> is a "representative images for the media object" and should thus be displayed alongside e.g. the description.

  <media:thumbnail url="" width="320" height="240"/>

Be sure the width and height are included.

11 Additional issues to discuss[edit]

  • Use of <media:player>, chapters, and transcripts. For lack of time not discussed above, will hopefully follow ...
  • Relation with atom. (e.g. atom:link)