Finalising metadata standard

From Transmission
Jump to: navigation, search

video metadata & distribution

for: re:transmission by: Jamie King (jamie at jamie.com), Jan Gerber (j at thing.net) October 2006

Overview

Context

A current concern for many video producers is how to better share and distribute materials, both to reach wider audiences and to facilitate better cooperation and learning. Huge increases in the speed of consumer-grade bandwidth and disk storage space, as well as innovations in distribution software, mean that distributing video online is now a viable option.

As the success of proprietary services like YouTube Revver and Vimeo show, there is now a strong online demand for video content so that it can be easily accessed and exchanged online (see Recommendations, below).

In producing these recommendations, we took into account certain guiding principles. Our framework has to be:

• as easy as possible to understand and implement for video producers and distributors,

• applicable to as many different kinds of content as possible without being unwieldy, and

• workable in the real world.

We were aware of a few other initiatives in this area, and took pains to review their work and not to duplicate it unnecessarily.

Our recommendations attempt to choose from what we see as the best of others’ systems. We do not offer them as a fait accompli but as an object for further discussion.


Recommendations

RSS or Atom?

‘RSS’ has become a catch-all term for a variety of ways of marking-up content in a semi-standardized format that can be viewed and organised through client software. Programs called feed readers or aggregators can check a list of feeds and display updated items that they find. Such readers are available for various operating systems, typically as stand-alone programs or extensions to existing programs such as web browsers. Many browsers have integrated support for RSS feeds.

However, RSS is not as unified a standard as its single name would suggest. In fact, as Mark Pilgrim explains:

there are actually nine incompatible versions of RSS, all of which are incompatible with various other versions. RSS 0.90 is incompatible with Netscape’s RSS 0.91, Netscape’s RSS 0.91 is incompatible with Userland’s RSS 0.91, Netscape’s RSS 0.91 is incompatible with RSS 1.0, Userland’s RSS 0.91 is incompatible with RSS 0.92, RSS 0.92 is incompatible with RSS 0.93, RSS 0.93 is incompatible with RSS 0.94, RSS 0.94 is incompatible with RSS 2.0, and RSS 2.0 is incompatible with itself. See 'The Myth of RSS Compatibility'

The potential for confusion caused by different versions — none of which has a standardised schema — is obvious. There are a profusion of attributes and elements available across RSS versions. Given the necessity of producing a simple, comprehensible schema for marking up video metadata, this is a serious issue for us.

What is more, RSS 2.0 is copyright its creators and may not, according to this license, be modified. We know that the sort of communities developing and working with this standard will see this as a key detractor, since many of us hold with Free/Libre and Open processes. Ethical qualms aside, it also raises a substantial pragmatic concern. Since this process is precisely involved in developing an open standard for video metadata, working with a closed standard is illogical.3


The Atom syndication format was specifically designed to address the general incoherence of RSS. As Robert Sayre writes:

early syndication and publishing protocols faced various problems related to interoperability, scalability, and extensibility. The Atom format and protocol builds on earlier efforts to establish an open, extensible, interoperable, and clearly specified framework for Web-logging applications. Atom has already been deployed on a wide variety of platforms. By closely examining previous syndication formats and protocols, the Atompub working group has been able to ‘pave the footpaths’, and design a standard built around well-known and proven usage patterns. Robert Sayre, ‘Atom: The Standard in Syndication’, IEEE Internet Computing, vol. 9, no. 2, 2005, pp. 71-78.

In our considerations, we have to weigh on the one hand the fact that RSS is confusing and unstandardised. If RSS is chosen, then which version of RSS should you use? RSS 0.9x, RSS 1.x, or RSS 2.0? Which RSS extensions and non-RSS namespaces should you use, if any? On the other hand, if Atom is selected, are there sufficient tools available that support it? Despite the emergence of Atom as an IETF Proposed Standard and the decision by major companies such as Google to embrace it, use of the older and more widely known RSS 1.0 and RSS 2.0 formats has continued. Many sites choose to publish their feeds in only a single format. For example CNN, the New York Times, and the BBC offer their web feeds only in RSS 2.0 format.

Because the Atom standard looks toward a future in which it will be adopted by a community of video producers, we suggest that the community seriously consider adopting it for encoding its metadata. This may seem controversial, especially bearing in mind our ‘real world’ principle. However, on balance, the case for adopting Atom over RSS is fairly strong. While recognise the shortcomings of Atom: while each of the various web syndication feed formats has attracted enthusiastic advocates convinced of the capabilities of their respective formats, no one would dispute that RSS predominates. But in mitigation, given most video producers do not currently mark up their content in any coherent fashion, if Atom is the best way to create a rigorous, clear and consistent framework for marking up video metadata, we think it should be used.

The following table may help in any considerations on this topic.


Factor RSS 2.0 Atom 1.0
Specification Copyrighted by Harvard University. Intentionally frozen. Is a recognised, open and evolvable IETF Standard (RFC 4287) standard that has undergone the IETF standardization process
Standards Connection to existing XML standards and RFCs is not well-defined has clearly defined relationships to other XML standards (Namespaces in XML, XML Base, XML Encryption, XML Digital Signatures, and XML 1.0 itself) and several RFCs
Deployment Numerous feeds Limited but growing number of feeds
Client Software Prevalent Less prevalent but growing rapidly, with other supporters announced
Publishing Protocols MetaWeblog and Blogger; frequent reports of interoperability problems and feature shortcomings. Atom Publishing Protocol leverages HTTP and REST; authentication may be required for any or all operations; implementation free so available for all platforms; IETF standardization process
Schema specification includes no standard schema so elements and attributes vary considerably across different RSS versions. specification includes a (non-normative) ISOStandard RelaxNG schema
Required Content requires feed-level (channel) title, link, and description, but does not require that any of the fields of individual items in a feed be present. requires that both feeds and entries include a title (which may be empty), a unique identifier, and a last-updated timestamp; more reliable for distinguishing duplicate feeds
HTML or XML ‘Payload’ may contain either plain text or escaped HTML, but with no way to indicate which;

cannot contain actual well-formed XML markup that we need here.

may either directly contain or link to a payload consisting of: plain text, with no markup (the default) escaped HTML, as is commonly used with RSS 2.0, well-formed, displayable XML
Full or Partial Content Description element may be complete text, summary, or absent clear distinction between summary and content
Autodiscovery of Feed non-standard implementation optional self pointer, so a newsreader can autosubscribe given only the contents of the feed
Namespaces and Extensibility no RSS namespace; numerous extensions, but no central place to discover extensions from various XML namespaces Atom is in an XML namespace and may contain elements or attributes from other XML

namespaces. If in future we wish to experiment with further taxonomic classification (e.g. Dublin Core) this is useful.

Security No specific provision. RSS 2.0 can be encrypted or signed like any other web

content.

Atom 1.0 specification includes rules for applying standard XML Encryption and XML Digital Signature to entries; alternatively, the feed can be encrypted or signed, like RSS 2.0, as a bag of bits
Other Security Considerations No specific provision. Specifically addressed by RFC 4287 in Section 8 (HTML and XHTML content, spoofing,URI/IRI, etc.)
Creator Identification used inconsistently in practice, so not reliable; provides the ability to specify email

addresses for a feeds <managingEditor> and <webMaster>, and for items <author>; some publishers prefer not to share email addresses, and use <dc:creator> from the Dublin Core extension instead.

Provides <author> and <contributor> elements at both the feed and entry level (to describe a person, corporation, or similar entity) with one required child element, <name>, and two optional elements: <uri> and <email>.


Video Metadata Fields

What follows is the ‘core’ of this report, which is a list of the fields that we consider useful or necessary in marking up video files so that they can be easily shared and discovered. We express these fields in plain language, offer a description, and our assessment of whether it is ‘required’ or not. (‘Required’ here is merely technically normative, in that it indicates specifically fields without which the schema will ‘break’, that is, will not have the core functionality we need.)

Videos are published in a ‘feed’, which is a collection of video items. Each feed carries metadata, which are data (information) about the videos themselves.

Feed Metadata

Video Metadata The metadata for each Video is composed of the following fields. FIELD DESCRIPTION REQUIRED Title Title of video YES Description A short plain- language description of the video. YES Link Link to a web page about this video YES Video Link A direct link to the downloadable file, via HTTP, BitTorrent or other, as new protocols emerge. There can be more than one video link per entry YES Publication Date Date on which the item was first published YES Author Author of the video YES License e.g. Creative Commons Share-alike. NO Length Hours, minutes, seconds NO Video Format Technical information about video, e.g., codec, bitrate, framerate, width, height NO Audio Format Technical information about audio, e.g., codec. bitrate, samplerate, channels NO Date of Creation year/date the video was made NO Country country or countries of production NO Thumbnail a still or animated image from the video NO. Subtitles link to subtitle, includes language attribute There can be more than one subtitle link per entry NO Keywords A set of keywords that provide a pithy description of the item. NO Genre NO Credits Roles like producer, director, etc. NO Documentary, Fiction, Cartoon, etc. if possible base it on http://imdb.com/Sections/ Genres/

How This Would Look

Those horrified by code should look away now. This example is a modified version of one that appears in RFC 4287.

<?xml version="1.0" ?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
  <title>Example Feed</title>
  <subtitle>A subtitle.</subtitle>
  <link href="http://example.org/"/>
  <link href="http://example.org/atom.xml" rel="self"/>
  <updated>2003-12-13T18:30:02Z</updated>
  <author>
    <name>John Doe</name>
    <email>johndoe@example.com</email>
  </author>
  <id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>
  <entry>
    <title>Atom-Powered Robots Run Amok</title>
    <link href="http://example.org/2003/12/13/atom03" rel="alternate"/>
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
    <updated>2003-12-13T18:30:02Z</updated>
    <summary>
            Some text.
    </summary>
    <link href="http://example.org/video/ph34r_my_podcast.ogg" length="1337" rel="enclosure" type="application/ogg"/>
    <media:thumbnail height="54" url="http://example.org/video/newscast-2006-10-11.fr.jpg" width="72"/>
    <link href="http://example.org/video/newscast-2006-10-11.fr.srt" hreflang="fr" length="1337" rel="enclosure" type="text/plain"/>
    <link href="http://example.org/video/newscast-2006-10-11.de.srt" hreflang="de" length="1337" rel="enclosure" type="text/plain"/>
    <author>
      <name>John Doe</name>
      <email>johndoe@example.com</email>
    </author>
  </entry>
</feed>

Possible Entry Elements Described in Detail

ID

Identifies the entry using a universally unique and permanent URI. Two entries in a feed can have the same value for ID if they

represent the same entry at different points in time.

<id>http://example.com/blog/1234</id>

Title

Contains a human readable title for the entry. This value should not be blank.

<title>Atom-Powered Robots Run Amok</title>

Video Link

Videos are linked to with a special relation called an ‘enclosure’, and a type that for video material.

<link rel="enclosure" type="application/ogg" length="1337" href="http://example.org/video/newscast-2006-10-11.ogg"/>

Updated

Indicates the last time the entry was modified in a significant way. This value need not change after a typo is fixed, only after

a substantial modification. Generally, different entries in a feed will have different updated timestamps.

<updated>2003-12-13T18:30:02-05:00</updated>

Author

Names one author of the entry. An entry may have multiple authors. An entry must contain at least one author element unless there is an author element in the enclosing feed, or there is an author element in the enclosed source element.

<author>
  <name>John Doe</name>
</author>

Link

Identifies a related Web page.

<link rel=”alternate” href="http://example.com/blog/1234"/>

Summary

Conveys a short summary, abstract, or excerpt of the entry. Summary should be provided if there either is no content provided for the entry

<summary>Some text.</summary>

Subtitles

Subtitles are actually another enclosure link, the language of the subtitle should be specified with the hreflang attribute.

<link rel="enclosure" type="text/plain" length="1337" hreflang="fr" href="http://example.org/video/newscast-2006-10-11.fr.srt"/>

Thumbnail

This is a still of the video.

<media:thumbnail url="http://example.org/video/newscast-2006-10-11.fr.jpg" width="72" height="54" />

Keywords

Highly relevant keywords describing the media object with typically a maximum of ten words. The keywords and phrases should be comma delimited

<media:keywords>kitty, cat, big dog, yarn, fluffy</media:keywords>

Credits

Notable entity and the contribution to the creation of the media object. Current entities can include people, companies, locations, etc. Specific entities can have multiple roles, and several entities can have the same role. These should appear as distinct <media:credit> elements. It has 2 optional attributes.

<media:credit role="producer" scheme="urn:ebu">entity name</media:credit>

License

Conveys information about rights, e.g. copyrights, held in and over the entry. This consists of two parts, a link to the license used and a text field with a short form.

<link rel="license" type="application/rdf+xml" href="http://creativecommons.org/licenses/by-sa/2.5/rdf" />
<rights>
  Copyright (c) 2005. Some rights reserved. This feed is licensed under a Creative Commons Attribution-ShareAlike 2.5
  Use License. It contains material originally published by Jane Smith at http://www.example.com/entries/1 under the Creative Commons Attribute License.
</rights>

Links with further details

More information about the Atom: http://atomenabled.org/developers/syndication/

All elements with media prefix are described in more detail at http://search.yahoo.com/mrss

More on Item Keywords

In our discussions we considered in some detail schemas like that broadly fall under the term ‘Semantic Web’. We do not think that it is worth attempting to engage the ongoing attempts to create a stringent taxonomy for content. We think this is better left to academic groups that have no immediate necessity to make their schema work in the real world. Adopting Atom we would later be able to inter-operate with such a content schema if that later became something we wanted.

The approach we take to classification is ‘folksonomic’. Roughly put, this involves producers selecting their own descriptive keywords (‘tags’)according a methodology they themselves define. In many systems (e.g. Flickr, Del.icio.us), users are able to see what kinds of tags other users have adopted as they enter their own, or to select from lists of popular tags. This creates some casual normativity without being overbearingly stringent. Of course there is a danger of users mis-classifying their content, but adhering to a more stringent framework doesn’t prevent this and only increases the onerousness of marking up video. We think onerousness is to be avoided. It will scare off potential collaborators.

We also think that given the fields above, a short description and these tags, most of our needs – in terms of discovering and sharing video – will be well met. Imagining that we have 20 groups that are consistently marking and publishing their video content with the fields outlined above in the Atom format, we could then bring together these feeds into new resources. We can sort by tag, creator, date, genre and so forth. We can imagine third party re-aggregating applications working rather well with these data.

Examples & Projects

Democracy and ‘Broadcast Machine’

The Democracy video platform already makes use of RSS feeds, which it terms 'Channels', to bring videos from publishers to users. Democracy offers a channel publishing tool called Broadcast Machine which generates feeds in a format that uses RSS 2.0 with the Yahoo Media extension and the Universal Subscription Mechanism.

According to the project managers, the decision to use RSS 2.0 was made because it allows the presentation of ‘rich metadata’ along with the associated video file. (We think it was also made because RSS is so popular.) RSS items corresponds to a single video item. Fig 1, A ‘channel’ produced by Broadcast Machine viewed through Democracy Player.

Here, viewed through Democracy Player, we see how a feed that has been marked up with Broadcast Machine looks. There is a channel name (‘Reality Hacks’), item name (e.g., ‘No House! No Land! No Vote!’), item description (e.g., ‘Voices from the housing struggle’), thumbnail, date of publication, video format (e.g. MSVIDEO), file size, and a link to the file. While the specification we describe here contains more information and will have greater utility, we can see the advantage here of marking up metadata about video in a consistent way. The Democracy project achieves a consistent ‘channel’ without levying any control over its contributors’ feeds. Equally, contributors benefit from having their video discoverable away from their sites in modes and context that they may not even have considered.

What Next?

In composing this document, we looked at some of the sites of groups we were told to consider stakeholders in this process. This brief review indicated that there are still some considerable hurdles to jump before this community would be as a whole in a position to implement a standard such as the one discussed here.

For example, some sites use proprietary Windows Media streams, or other streams that does not actually allows users to download the video they want to see. This effectively prevents them from being used for syndication. Many sites do not currently produce any kind of feed at all about the videos they offer. What this indicates to us is that, as well as considering formal metadata requirements, we also need to discuss together ‘information culture’ within video producing and distributing groups -- from the formats used to encode video for consumption by users, to practices of openness, to basic modes of internet distribution such as HTTP and Bittorrent. Such requirements were ‘beneath the scope’ of the document here but we believe they are essential if we are to meet our aims going forward.

The recommendations here were created for discussion purposes. If we can agree ultimately on the best route to take, we can collaborate with or produce extensions for video content management systems enabling co-operating parties to markup their video according to our specifications easily and simply.

The benefits of this to all of us are immense. We will be able to create, subscribe to, and recombine feeds of each others’ video material and display the results on our own pages or wherever we like. Viewers will be able to find their way to our content much more easily, from unexpected constituencies.

It is important, above all, that a system be designed that is useable for all concerned, since what breeds success (adoption) in this area is usage. Many schemas have withered after lack of adoption due to being too esoteric, and hence not building grassroots support. We would like to begin at the grassroots and that is is why we seek your input and support at this stage.

Links

Atom RFC

Format Overview

Yahoo Media Extension

Feed Validation

Universal Feed Parser


Further Reading

https://dnidata.org/education/xnotes/RSS_and_Atom_Considerations.xml#Section3

http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-04.html#create_coll_member_model

FIELD DESCRIPTION REQUIRED
Title The name of the channel, e.g., ‘Activist Central’ YES
Description A short description of the channel, e.g., ‘For everything

that’s new and hip in the world of the activist.’

NO
Link To Site The URL to the website on which the channel is based

(e.g., ‘http://www.activistcentral.org’)

YES
Publication Date The date this feed was last updated YES
Publisher Who (which group or person) published this feed YES
Link to self The feed knows at which internet location it lives. YES
Icon A representative icon for the channel. NO
Language Language or dialect of the item. NO
License e.g. Creative Commons Share-alike. Brief human readable summary and a link to the longer license. NO