Proposal: Podcast and PodcastEpisode #373

Racum · 2015-03-06T05:21:36Z

Introduction

New schema types: Podcast and PodcastEpisode.

Podcasts are part of the common Internet slang for more than 10 years, they are everywhere, they are slowly becoming very popular, but they are not quite well represented by the Semantic Web.

So far, if anyone wanted to classify a podcast page, it suppose to use a generic “CreativeWork” type for the list of content and an “Episode” type for each instance. Expanding CreativeWork into “Podcast” type gives it the proper meaning, plus a few useful properties, and, specifying Episode into “PodcastEpisode” makes clear the difference between it and other episodes (RadioEpisode/TVEpisode).

Podcast

Definition:

A podcast, referring to a main theme containing a series of related sequential episodes.

Inheritance

Thing > CreativeWork > Podcast

Properties

Property	Expected Type	Description
`network`	Organization	An Organization specialized in provide or host a group of Podcasts, not only this one. “Directories” (like iTunes) does not qualify.
`category`	Text	The category of the Podcast. It is a good practice to follow the taxonomy from iTunes.
`rssFeed`	URL	RSS Feed URL.

Mapping from RSS "channel" sub-tags:

Just for reference:

RSS Tag	Property	from
`<title>`	name	Thing
`<description>`	description	Thing
`<link>`	url	Thing
`<language>`	inLanguage	CreativeWork
`<copyright>`	copyrightHolder	CreativeWork
`<managingEditor>`	editor	CreativeWork
`<lastBuildDate>`	dateModified	CreativeWork
`<image>`	image	Thing
`<category>`	category	Podcast
`<itunes:author>`	author	CreativeWork
`<itunes:category>`	category	Podcast
`<itunes:image>`	image	Thing
`<itunes:explicit>`	[not] isFamilyFriendly	CreativeWork
`<itunes:owner>`	accountablePerson	CreativeWork
`<itunes:subtitle>`	alternativeHeadline	CreativeWork
`<itunes:summary>`	text	CreativeWork
N/A	rssFeed	Podcast
N/A	network	Podcast

Notes

The following <channel> sub-tags aren't mapped because they are implementation details:
- <webMaster>
- <generator>
- <docs>
- <ttl>
- <itunes:block>
- <itunes:complete>
- <itunes:new-feed-url>

PodcastEpisode

Definition:

A podcast episode, referring to a single instance of multimedia content (audio or video).

Inheritance

Thing > CreativeWork > Episode > PodcastEpisode

Properties

Property	Expected Type	Description
`podcast`	Podcast	The Podcast that contains this PodcastEpisode.
`guid`	Text	Permanent, case-sensitive "Globally Unique Identifier".
`category`	Text	The category of the PodcastEpisode (in case it differs from Podcast's category). It is a good practice to follow the taxonomy from iTunes.

Mapping from RSS "item" sub-tags:

Just for reference:

RSS Tag	Property	from
`<title>`	name	Thing
`<description>`	description	Thing
`<link>`	url	Thing
`<guid>`	guid	PodcastEpisode
`<author>`	author	CreativeWork
`<pubDate>`	datePublished	CreativeWork
`<comments>`	discussionUrl	CreativeWork
`<enclosure>`	associatedMedia	CreativeWork
`<category>`	category	PodcastEpisode
`<itunes:author>`	author	CreativeWork
`<itunes:image>`	image	Thing
`<itunes:duration>`	timeRequired	CreativeWork
`<itunes:explicit>`	[not] isFamilyFriendly	CreativeWork
`<itunes:order>`	episodeNumber	Episode
`<itunes:subtitle>`	alternativeHeadline	CreativeWork
`<itunes:summary>`	text	CreativeWork
N/A	podcast	PodcastEpisode

Notes

The following <item> sub-tags aren't mapped because they are implementation details:
- <itunes:block>
- <itunes:isClosedCaptioned>

Example

Adapted from http://www.relay.fm/inquisitive/27.

Without Markup

<div class="show__description">
  <img src="https://.../inquisitive_artwork.png">
  <h2><a href="http://www.relay.fm/inquisitive"><span>Inquisitive</span></a></h2>
  <h3>
    <p>
      Inquisitive is a show for the naturally curious.
      Each week, Myke Hurley takes a look at what makes creative
      people successful and what steps they have taken to get there.
    </p>
  </h3>
  <h5>Subscribe</h5>
  <ul>
    <li><a href="http://www.relay.fm//inquisitive/feed">RSS</a></li>
    <li><a href="https://itunes.apple.com/us/podcast/id909109678">iTunes</a></li>
  </ul>
  <h5>Hosted By<spam>Myke Hurley</span></h5>
</div>

<div class="episode__entry">
  <h2>
    <a href="http://www.relay.fm/inquisitive/27">
      <span>#27: Behind the App #1: History</span>
    </a>
  </h2>
  <small>February 18th, 2015</small>
  <small>37 minutes</small>
  <p>
    In the first episode of “Behind the App”, a special series of
    Inquisitive, we take a look at the beginnings of iOS app development,
    by focusing on the introduction of the iPhone and the App Store.
  </p>
  <p>
    Download:
    <a href="http://.../Inquisitive_027.mp3">MP3 (25.75 MB)</a>
  </p>
</div>

Microdata

<div itemscope itemtype="http://schema.org/Podcast" class="show__description">
  <img itemprop="image" src="https://.../inquisitive_artwork.png">
  <h2>
    <a itemprop="url" href="http://www.relay.fm/inquisitive">
      <span itemprop="name">Inquisitive</span>
    </a>
  </h2>
  <h3>
    <p itemprop="description">
      Inquisitive is a show for the naturally curious.
      Each week, Myke Hurley takes a look at what makes creative
      people successful and what steps they have taken to get there.
    </p>
  </h3>
  <h5>Subscribe</h5>
  <ul>
    <li><a itemprop="rssFeed"
        href="http://www.relay.fm//inquisitive/feed">RSS</a></li>
    <li><a href="https://itunes.apple.com/us/podcast/id909109678">iTunes</a></li>
  </ul>
  <h5>Hosted By<spam itemprop="author" >Myke Hurley</span></h5>
</div>

<div itemscope itemtype="http://schema.org/PodcastEpisode"  class="episode__entry">
  <h2>
    <a itemprop="url" href="http://www.relay.fm/inquisitive/27">
      <span itemprop="name">#27: Behind the App #1: History</span>
    </a>
  </h2>
  <small itemprop="datePublished" datetime="2015-02-18">February 18th, 2015</small>
  <small itemprop="duration" datetime="PT27M">37 minutes</small>
  <p itemprop="description">
    In the first episode of “Behind the App”, a special series of
    Inquisitive, we take a look at the beginnings of iOS app development,
    by focusing on the introduction of the iPhone and the App Store.
  </p>
  <p itemprop="associatedMedia" itemscope itemtype="http://schema.org/MediaObject">
    Download:
    <a itemprop="contentUrl" href="http://.../Inquisitive_027.mp3">
      MP3 (<span itemprop="contentSize">25.75 MB</span>)
    </a>
  </p>
</div>

The text was updated successfully, but these errors were encountered:

chaals · 2015-03-20T11:58:57Z

I'm not convinced by the category property. Being able to link to a popular online store is handy, but baking a particular one into schema.org doesn't feel right - there are a lot of subject classification schemes, and apart from anything else I don't find Apple's terribly good, so I would suggest using about for now (while letting people add the itunes category or their own equivalent, if they are using RDFa or JSON-LD to mix vocabs.

Same for network - I am not sure what it does beyond publisher.

And for guid I am just sceptical we need it. I note it isn't in the examples, and I am not sure what we would use as a best practice value. I suspect we can rely on existing identification instead.

Beyond that, the proposal itself seems rational. The other approach would be to explicitly state that we think podcasts are the same as radio (which is how I think of them - I also listen to as much radio streamed over the net as I do AM or FM broadcasts of audio signals), and just say "use the radio properties".

Thoughts?

vholland · 2015-03-20T12:26:47Z

I agree with @chaals re: network and category. CreativeWork already has a "genre" property. You could use that.

If you change your hierarchy a bit to Thing > CreativeWork > Series > Podcast, you could use the existing properties to link up the Episodes to the Series, so you would not need the "podcast" property.

jvandriel · 2015-03-20T12:39:45Z

In regards to: guid : Text : Permanent, case-sensitive "Globally Unique Identifier".

Wouldn't that be the same as using @itemid, @resource or @id?

Dataliberate · 2015-03-20T12:42:28Z

On 20 Mar 2015, at 11:59, chaals <notifications@github.com mailto:notifications@github.com> wrote:

I'm not convinced by the category property. Being able to link to a popular online store is handy, but baking a particular one into schema.orghttp://schema.org doesn't feel right - there are a lot of subject classification schemes, and apart from anything else I don't find Apple's terribly good, so I would suggest using about for now

Agree - don’t see the special case here that is made just for Podcasts. Using about to reference a value in a classification scheme(s) seems to be OK for most other CreativeWorks

(while letting people add the itunes category or their own equivalent, if they are using RDFa or JSON-LD to mix vocabs.

Same for network - I am not sure what it does beyond publisher.

Neither do I - its just the publishing organisation.

And for guid I am just sceptical we need it. I note it isn't in the examples, and I am not sure what we would use as a best practice value. I suspect we can rely on existing identification instead.

Yes surely the URI of the of the description is the globally unique ID.

Beyond that, the proposal itself seems rational. The other approach would be to explicitly state that we think podcasts are the same as radio (which is how I think of them - I also listen to as much radio streamed over the net as I do AM or FM broadcasts of audio signals), and just say "use the radio properties".

I have some sympathy with this approach - it feels a bit like needing an AudioSeries Type to be a super type for RadioSeries and a new PodcastSeries - then Episode would work for both.

~Richard

Thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/373#issuecomment-83993359.

Racum · 2015-03-20T14:30:50Z

@chaals

About category: I agree about not recommend the Apple’s list, but lets keep it a open field and assume the Apple-based ones as legal values, since it is a “de-facto” standard in the podcast world.

About network: it IS a publisher, I didn’t notice when I was writing the proposal, I agree about omit this field.

@chaals / @jvandriel / @Dataliberate

About guid: must podcasts just use the episode page URL as am identifier, in this case it is the same as the url field. Some documentation recommend the use of UUIDs, but nobody actually uses it, I could not find an example different from url. I’m ok about omitting it as well

@vholland / @Dataliberate

The only extra fields Series give to CreativeWork are startDateand endDate, and podcasts usually don’t have these concepts, there are cases of podcasts paused by years that just restart. Also the other children of Series (BookSeries, MovieSeries…) don’t behave like a Podcast. I think it makes more sense to keep a child of CreativeWork.

TL:DR:

No formal Apple recommendation for category, but keep as a open field;
Out with network in Podcast, prefer publisher;
Out with guid in PodcastEpisode, url does the trick;
Keep Podcast as a child of CreativeWork.

Thoughts?

chaals · 2015-03-20T15:43:03Z

I think, as Richard suggested, that about would work instead of category - but there is no reason not to use the apple scheme in that, and it would make a reasonable example.

rvguha · 2015-03-23T22:26:18Z

We should collect some data.

If indeed podcasts are described using a certain categorization scheme,
given that describing podcasts is right in the middle of our charter, we
should create a relation for that categorization scheme.

guha

On Fri, Mar 20, 2015 at 8:43 AM, chaals notifications@github.com wrote:

I think, as Richard suggested, that about would work instead of category

but there is no reason not to use the apple scheme in that, and it would
make a reasonable example.

—
Reply to this email directly or view it on GitHub
#373 (comment).

Racum · 2015-03-25T00:49:38Z

@chaals / @rvguha

Personally, I don't care too much about what categories to use, I'm way more concern about simply have the Podcast/PodcastEpisode schemes. But, putting personal opinions aside, I made some research about the categories, I hope it helps the discussion:

The podcast sites themselves usually don’t use categorization other than the internal categories of the site or blog, but podcast directories tend to follow the Apple convention, sometimes even down to the sub-categories, a quick googling got me these examples:

podcastdirectory.com
- List of categories and sub-categories
- Podcast page: category breadcrumb on the left sidebar
learnoutloud.com
- List of categories
- Podcast page: category breadcrumb on the top
ipodder.org
- List of categories
- Podcast page: category breadcrumb on the top

For reference, Apple's list is here (at the end of the page).

I can say that Apple's categorization "it's a thing"! Apple was the first to try to put some other in the podcast chaos about 10 years ago; their patterns stuck and were copied by many other directories after that.

dhilowitz · 2015-10-02T14:09:49Z

Any progress on this?

Racum · 2015-10-02T16:23:37Z

@dhilowitz, the maintainers of the project commented on my initial proposal, I am waiting on their opinion about the Apple's category list (see above), but they are deliberating on this for months... I think I could just try my luck with a pull request!

rvguha · 2015-10-02T18:07:32Z

Just as an FYI, all deliberations, if any, take place on this list. So, if
you don't see any, there hasn't been any.

guha

On Fri, Oct 2, 2015 at 9:23 AM, Ronaldo Ferreira notifications@github.com
wrote:

@dhilowitz https://github.com/dhilowitz, the maintainers of the project
commented on my initial proposal, I am waiting on their opinion about the
Apple's category list (see above), but they are deliberating on this for
months... I think I could just try my luck with a pull request!

—
Reply to this email directly or view it on GitHub
#373 (comment)
.

unor · 2015-10-06T04:09:35Z

I think rssFeed should be renamed to feed (or webFeed, if feed would be too ambiguous); making it technology-neutral (ref. Atom, Web feed).

Racum · 2015-10-07T01:46:42Z

@unor, I agree! ...just feed is more elegant and doesn't look to collide with any other schema.

rvguha · 2015-10-07T20:46:01Z

feed is too ambiguous.

I prefer rssFeed, but may be biased.

guha

On Tue, Oct 6, 2015 at 6:46 PM, Ronaldo Ferreira notifications@github.com
wrote:

@unor https://github.com/unor, I agree! ...just feed is more elegant
and doesn't look to collide with any other schema.

—
Reply to this email directly or view it on GitHub
#373 (comment)
.

Racum · 2015-10-07T21:10:01Z

@unor, @rvguha: in podcast lingo, "feed" and "rss" are used interchangeably. Both rssFeed and feed make sense, it just a matter of choose between implicit vs explicit; is there any similar case solved in other schemas to use as reference?

chaals · 2015-10-08T00:08:33Z

Agree that feed is way too ambiguous for schema.

Why doesn't isPartOf cover this use case?
(sleepy, so the answer might be obvious…)

Racum · 2015-10-08T17:08:01Z

@chaals

From the definition: "isPartOf" - Indicates a CreativeWork that this CreativeWork is (in some sense) part of.

https://schema.org/isPartOf

I don't thing the feed itself is another "CreativeWork", it is just an already machine-readable alternative representation.

chaals · 2015-10-09T10:01:31Z

I'm not sure isPartOf is right, but I don't think "feed" is either. Not just because the name is too generic for the concept we are using here as specific to podcasts - the concept is more general... Perhaps we shuld look at the stuff for serial publication including TV series etc.

A feed is a creative work, in the same way an exhibition, blog (as distinct from blogpost) or an album is.

Schema should not get all FRBR in describing the intricate relationships between different manifestations of works and collections (inter alia, because FRBR already does it ;) ). But we should handle basics in a rational way instead of having parallel silos, if we can.

vholland · 2015-10-19T15:08:01Z

+1 for rssFeed to future proof against other types of feeds.

Why do we need guid? It seems "@id" or itemid as appropriate in the markup?

If Podcast is a subtype of http://schema.org/CreativeWorkSeries, we already have the link from Podcast to PodcastEpisode without introducing new properties. We could also reuse http://schema.org/publisher to avoid adding "network".

Racum · 2015-10-19T15:38:17Z

Putting all the comments together, I think we got a simpler specification:

No longer Podcast.network (use CreativeWork.publisher instead).
No longer PodcastEpisode.guid (omitted).
Attribute category is open-ended, there is no formal recommendation to use Apple's taxonomy, although probably the podcasts tend to use it anyway.

What do you all think?

Podcast:

Thing > CreativeWork > Podcast

rssFeed: URL
category: Text

PodcastEpisode

Thing > CreativeWork > Episode > PodcastEpisode

podcast: Podcast
category: Text

srimola · 2016-07-27T21:44:57Z

+1

collinwu · 2016-07-27T21:47:17Z

+1

iluxan · 2017-01-18T17:19:01Z

What are the next steps here? Is this proposal still planned or abandoned?

Racum · 2017-01-18T18:09:54Z

I didn't find a contributing guide, I don't know if just need to send a PR or do anything else before.

hipsterjazzbo · 2017-03-29T05:09:49Z

Hi, I'm pretty interested in this. Is there some procedure to move this on? I'm happy to do some legwork if someone can point me in the right direction.

Racum · 2017-03-29T08:47:40Z

It is probably just a matter of editing the /data/schema.rdfa file, but I'm not familiar with this format, so I have no way properly test it before create a PR.

hipsterjazzbo · 2017-03-30T05:39:11Z

Is there like, no one who runs this repo who can answer this question?

RichardWallis · 2017-03-30T08:42:26Z

In principle - submit a Pull Request, of vocab changes accompanied by examples, for consideration in an upcoming release. You may want to do this in files named issue-373.rdfa and issue-373-examples.txt instead of submitting edits to the main schema.rdfa and examples.txt. This also helps if the proposal is initially placed in the pending area.

In practice - you may find the following "schema.org in practice" articles: part 1, 2, and 3, a help in how you can try/test things locally, and the HowWeWork document for general background.

~Richard

Racum · 2017-03-30T08:51:17Z

@RichardWallis you just wrote a perfect draft for a CONTRIBUTING.md file! :)

UmamiDearest · 2017-09-12T20:06:32Z

@Racum Echoing all those expressing more and more interest in this becoming part of the schema landscape. Any update on your submission @Racum?

vholland · 2017-09-15T18:51:46Z

I still think a Podcast should be a subclass of schema.org/CreativeWorkSeries so you can link individual episodes to the podcast as a whole.

Aaranged · 2017-09-15T21:45:54Z

@vholland Did you mean something like PostcastSeries for that CreativeWorkSeries subclass, or are you thinking that Postcast itself is a CreativeWorkSeries? And if the latter, what would the type be for an individual podcast?

vholland · 2017-09-15T22:30:12Z

I was thinking the type schema.org/Podcast would be a subclass of schema.org/CreativeWorkSeries. This keeps it consistent so This American Life is a series whether you are discussing the radio series or the modern podcast version.

An individual "podcast" would be a PodcastEpisode as described above. As an example This American Life 625: Essay B is an episode.

I am aware that some podcast series will have only a single episode.

RichardWallis · 2017-09-16T23:22:39Z

To avoid confusion would they not be better as PodcastSeries and PodcastEpisode?

vholland · 2017-09-18T13:36:55Z

@RichardWallis Those names sound good to me

dougblackjr · 2018-01-08T14:52:23Z

Has there been any movement on this?

JeffreyBurns · 2018-02-13T15:01:48Z

+1 for including PodcastSeries and PodcastEpisode

machito · 2018-03-14T17:29:02Z

+1

baq · 2018-06-07T21:59:11Z

What's the status on this? +1

vholland · 2018-07-13T18:37:55Z

I was talking to someone about podcasts and schema.org and was embarrassed to realize we have been discussing for 3 years. In an effort to move this along, I created PR #2007

mariotoledo · 2019-02-25T17:06:12Z

While this is still an open issue, which is the best option for markup my podcast website? I'm thinking of using CreativeSeries. Does anyone have a better idea?

inetbiz · 2019-03-04T15:35:34Z

@vholland Did you mean something like PostcastSeries for that CreativeWorkSeries subclass, or are you thinking that Postcast itself is a CreativeWorkSeries? And if the latter, what would the type be for an individual podcast?
@Aaranged Any news on this proposal that you know of?

gr0g · 2019-06-24T19:35:31Z

+1

abirhoss · 2019-07-29T06:24:35Z

+1

Any progress with this?

* Issue #373: Added PodcastSeries and PodcastEpisode. * Changed rssFeed to webFeed. * Removed webFeed as a property of PodcastEpisode. * Fixed typo. * Empty commit to trigger post_receive hooks * Added PodcastSeason.

RichardWallis · 2019-10-23T09:52:14Z

Implemented in Release 4.0

DamonHD · 2020-06-06T13:12:36Z

Should 'trailer' not be allowed to be an AudioObject or even a WebPage or Article or any other CreativeWork also? Especially when promoting an audio podcast, a video trailer seems overblown (and doesn't fit what I want to do right now)!

DamonHD · 2024-05-25T10:17:28Z

From my use of webFeed, I think that it should be allowed in CreativeWorkSeries (for a series which gets a RSS/Atom feed, but isn't a podcast) and PodcastEpisode (to link to the podcast's feed) and indeed WebPage and Article and maybe all CreativeWork items to allow them to refer to a RSS/Atom feed associated with or that has that item as an entry/episode...

danbri added type:enhancement schema.org vocab General top level tag for issues on the vocabulary labels Mar 16, 2015

danbri removed the type:enhancement label Mar 7, 2016

danbri removed the status:needs review label Aug 10, 2016

sandikbarr mentioned this issue Oct 1, 2016

Seasons and Series syndicated-media/sn-spec#1

Open

vholland pushed a commit to vholland/schemaorg that referenced this issue Jul 13, 2018

Issue schemaorg#373: Added PodcastSeries and PodcastEpisode.

2a70ae0

RichardWallis closed this as completed Oct 23, 2019

Proposal: Podcast and PodcastEpisode #373

Proposal: Podcast and PodcastEpisode #373

Comments

Racum commented Mar 6, 2015

Introduction

Podcast

Definition:

Inheritance

Properties

Mapping from RSS "channel" sub-tags:

Notes

PodcastEpisode

Definition:

Inheritance

Properties

Mapping from RSS "item" sub-tags:

Notes

Example

Without Markup

Microdata

chaals commented Mar 20, 2015

vholland commented Mar 20, 2015

jvandriel commented Mar 20, 2015

Dataliberate commented Mar 20, 2015

Racum commented Mar 20, 2015

chaals commented Mar 20, 2015

rvguha commented Mar 23, 2015

Racum commented Mar 25, 2015

dhilowitz commented Oct 2, 2015

Racum commented Oct 2, 2015

rvguha commented Oct 2, 2015

unor commented Oct 6, 2015

Racum commented Oct 7, 2015

rvguha commented Oct 7, 2015

Racum commented Oct 7, 2015

chaals commented Oct 8, 2015

Racum commented Oct 8, 2015

chaals commented Oct 9, 2015

vholland commented Oct 19, 2015

Racum commented Oct 19, 2015

Podcast:

PodcastEpisode

srimola commented Jul 27, 2016

collinwu commented Jul 27, 2016

iluxan commented Jan 18, 2017

Racum commented Jan 18, 2017

hipsterjazzbo commented Mar 29, 2017

Racum commented Mar 29, 2017

hipsterjazzbo commented Mar 30, 2017

RichardWallis commented Mar 30, 2017 • edited Loading

Racum commented Mar 30, 2017

UmamiDearest commented Sep 12, 2017

vholland commented Sep 15, 2017

Aaranged commented Sep 15, 2017

vholland commented Sep 15, 2017

RichardWallis commented Sep 16, 2017

vholland commented Sep 18, 2017

dougblackjr commented Jan 8, 2018

JeffreyBurns commented Feb 13, 2018

machito commented Mar 14, 2018

baq commented Jun 7, 2018

vholland commented Jul 13, 2018

mariotoledo commented Feb 25, 2019 • edited Loading

inetbiz commented Mar 4, 2019

gr0g commented Jun 24, 2019

abirhoss commented Jul 29, 2019

RichardWallis commented Oct 23, 2019

DamonHD commented Jun 6, 2020

DamonHD commented May 25, 2024

RichardWallis commented Mar 30, 2017 •

edited

Loading

mariotoledo commented Feb 25, 2019 •

edited

Loading