Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
190 lines (134 sloc) 7.98 KB

Title: Podlove Podcast Description Author: Tim Pritlove
Version: 0.2
Tags: podlove, podcast, description Status: Under developement

Podlove Podcast Description

Podlove Podcast Description is a general specification listing essential metadata items that are necessary to describe a podcast on the Internet. The specification also defines specific file formats based on the same nomenclature for practical use.

Change Log

2013-04-09: 0.1 - Initial Draft
2013-06-07: 0.2 - Removed mnemonic element

Motivation and Scope

Podcasts were created on top of the technical grounds of blogs but have since developed into an independent media type on the Internet that adheres to different rules and needs different treatment.

This specification is meant to support auto-detection and self-description of podcast in a general manner. The metadata can be used by podcast clients, podcast directories, internet radio devices, search engines, social networks and any other system that has a notion of metadata and is capable and willing to detect podcast as separate entities.

Elements

The following elements define a single podcast.

Title

Identifier: title
Type: text
Properties: n/a
Mandatory: yes

title is the title of the podcast that is the primary field to be used to represent the podcast in directories, lists and other uses. A title SHOULD not be too long. If you want to augment the core title with an explanatory extension, use the subtitle element.

The title is made up of plain text only and MUST NOT contain any HTML or other markup.

Subtitle

Identifier: subtitle
Type: text
Properties: n/a
Mandatory: no

The subtitle is an extension to the title element. The subtitle is meant to clarify what the podcast is about. While a title can be anything, a subtitle should be more descriptive in what the content actually wants to convey and what the most important information is, you want everybody want to know about the offering.

Subtitles are very useful for podcast directories and extended lists in podcast clients as they can explain a lot more detail to the user without any additional user interaction necessary.

Subtitles should be slightly more verbose than titles but SHOULD still try to keep it short in order to support compact presentation forms like Internet radio devices, mobile screens etc. Subtitles MUST NOT be longer than 256 characters.

The subtitle is made up of plain text only and MUST NOT contain any HTML or other markup.

Summary

Identifier: summary
Type: text
Properties: n/a
Mandatory: no

A summary is a much more precise and elaborate description of the podcast's content. While title and subtitle are rather concise, a summary is meant to consist of one or more sentences that form a paragraph or more.

However, the summary should still be a rather compact explanation of the podcast that is not yet conveyed by title and subtitle alone. And while technically a summary can be provided without also listing a subtitle, it would be bad practice to do so. The cascade of Title > Subtitle > Summary is an ideal source for software and devices that dynamically want to unfold more information about a podcast in its user interface.

The summary is made up of plain text only and MUST NOT contain any HTML or other markup.

Language

Identifier: language
Type: text
Properties: n/a
Mandatory: no

The language denotes the language that is usually spoken in the given podcast. Episodes may feature other languages but usually don't. If the podcast usually features different languages in each episodes, no general language should be specified. The value must be an IETF language tag as defined by RFC5646 [^RFC5646].

Link

Identifier: link
Type: text
Properties: n/a
Mandatory: no

While a podcast can technically exist on the Internet without a home page, it is very rare and definitely not recommended not to have a human readable presence on the web. link represents the URL under which this web page can be reached.

Image

Identifier: image
Type: text
Properties: n/a
Mandatory: no

A podcast SHOULD be represented by an image that acts a logo and visual identifier for the production. This is a very useful resource for all kinds of media devices and directories.

The image pointed to by the stated URL SHOULD be square (1:1 aspect ratio) and provide enough resolution in order to be useful for a variety of applications. However, huge images might also impose restrictions on less capable devices so the size should be chosen wisely. A common practice is to choose a pixel resolution between 600x600 and 1400x1400 pixels (the latter being the 2013 recommendation of the iTunes Podcast Directory).

An image SHOULD be provided in a commonly used media file format such as JPEG or PNG as these can be considered sufficiently supported by all software and devices.

Feeds

Identifier: feeds
Type: object
Properties: feed
Mandatory: yes

Identifier: feed
Type: object
Properties: feed-title, feed-url, enclosure-mime-type
Mandatory: yes

The content podcast of the podcast is accessed by means of a podcast feed. A podcast might have just one or even more feeds. The description lists all available feeds within a feeds object which contains one or more feed objects. Each feed object itself contains the properties feed-title, feed-url and enclosure-mime-type that describe the feed in detail.

XML Representation

<?xml version="1.0" encoding="utf-8"?>
<podcast xmlns="http://podlove.org/dtd/podcast-description">
	<title>Podlove Podcast</title>
	<subtitle>
		Insights and outlooks by the Podlove project
	</subtitle>
	<summary>
		The Podlove team updates creators and developers
		on the latest thinking behind the Podlove project,
		it's software projects and standards.
		
		The podcast is delivered bi-weekly and welcomes
		feedback on any level. Join as we try to shape the
		future of podcasting for the greater good.
	</summary>
	<link>http://podlove.org/example/podcast</link>
	<image>http://podlove.org/example/podcast-image.jpg</image>
	<feeds>
		<feed>
			<feed-title>MP3 Audio</feed-title>
			<feed-url>
				http://podlove.org/example/podlove-feed-mp3.rss
			</feed-url>
			<enclosure-mime-type>audio/mpeg</enclosure-mime-type>
		</feed>
		
		<feed>
			<feed-title>MP4 Audio</feed-title>
			<feed-url>
				http://podlove.org/example/podlove-feed-m4a.rss
			</feed-url>
			<enclosure-mime-type>audio/mp4</enclosure-mime-type>
		</feed>
	</feeds>
</podcast>

JSON Representation

The JSON representation is a general specification on how to map the above elements in JSON structures that can be used in many applications (like App.net Annotations).

In comparison to the XML representation described above, the JSON representation does not support namespaces and therefore it can't be mixed in easily.

{
	"title": "Podlove Podcast",
	"subtitle": "Insights and outlooks by the Podlove project",
	"summary": "The Podlove team updates creators and developers on the latest thinking behind the Podlove project, it's software projects and standards.\nThe podcast is delivered bi-weekly and welcomes feedback on any level. Join as we try to shape the future of podcasting for the greater good.",
	"link": "http://podlove.org/example/podcast",
	"feeds": [
		{
			"feed-title": "MP3 Audio",
			"feed-url": "http://podlove.org/example/podlove-feed-mp3.rss",
			"enclosure-mime-type": "audio/mpeg"
		},
		{
			"feed-title": "MP4 Audio",
			"feed-url": "http://podlove.org/example/podlove-feed-m4a.rss",
			"enclosure-mime-type": "audio/mp4"
		}
		]
	
}

In the case of an App.net annotation, the JSON representation should be wrapped into a value field with a type value of org.podlove.podcast-description.

{
	"type": "org.podlove.podcast-description",
	"value": 
	{
		"title": "Podlove Podcast",
		...
	}
}

[^RFC5646]: RFC5646: Tags for Identifying Languages