Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Podcast and PodcastEpisode #373

Open
Racum opened this issue Mar 6, 2015 · 44 comments

Comments

@Racum
Copy link

commented Mar 6, 2015

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>
@chaals

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2015

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

This comment has been minimized.

Copy link

commented Mar 20, 2015

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

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

@Dataliberate

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2015

On 20 Mar 2015, at 11:59, chaals <notifications@github.commailto: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

This comment has been minimized.

Copy link
Author

commented Mar 20, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Mar 23, 2015

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

This comment has been minimized.

Copy link
Author

commented Mar 25, 2015

@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:

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

This comment has been minimized.

Copy link

commented Oct 2, 2015

Any progress on this?

@Racum

This comment has been minimized.

Copy link
Author

commented Oct 2, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2015

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

This comment has been minimized.

Copy link
Author

commented Oct 7, 2015

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

@rvguha

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Author

commented Oct 7, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Author

commented Oct 8, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2015

+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

This comment has been minimized.

Copy link
Author

commented Oct 19, 2015

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
@danbri danbri removed the type:enhancement label Mar 7, 2016
@srimola

This comment has been minimized.

Copy link

commented Jul 27, 2016

+1

1 similar comment
@collinwu

This comment has been minimized.

Copy link

commented Jul 27, 2016

+1

@iluxan

This comment has been minimized.

Copy link

commented Jan 18, 2017

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

@Racum

This comment has been minimized.

Copy link
Author

commented Jan 18, 2017

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

@hipsterjazzbo

This comment has been minimized.

Copy link

commented Mar 29, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 29, 2017

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

This comment has been minimized.

Copy link

commented Mar 30, 2017

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

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 30, 2017

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

@UmamiDearest

This comment has been minimized.

Copy link

commented Sep 12, 2017

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

@vholland

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2017

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

This comment has been minimized.

Copy link

commented Sep 15, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2017

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

@vholland

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2017

@RichardWallis Those names sound good to me

@dougblackjr

This comment has been minimized.

Copy link

commented Jan 8, 2018

Has there been any movement on this?

@JeffreyBurns

This comment has been minimized.

Copy link

commented Feb 13, 2018

+1 for including PodcastSeries and PodcastEpisode

@machito

This comment has been minimized.

Copy link

commented Mar 14, 2018

+1

@baq

This comment has been minimized.

Copy link

commented Jun 7, 2018

What's the status on this? +1

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

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2018

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

This comment has been minimized.

Copy link

commented Feb 25, 2019

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

This comment has been minimized.

Copy link

commented Mar 4, 2019

@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

This comment has been minimized.

Copy link

commented Jun 24, 2019

+1

@Abir-H

This comment has been minimized.

Copy link

commented Jul 29, 2019

+1

Any progress with this?

danbri added a commit that referenced this issue Sep 23, 2019
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.