-
Notifications
You must be signed in to change notification settings - Fork 116
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:notes> #399
Comments
I agree that there we should have a Most podcasters aren't actually making these choices about the text fields. They either don't know the best way to use the separate fields, or their publishing tools don't actually give all the right guidance and options. Apple has deprecated their own I think the description should be for the one-paragraph summary of the episode, I publish my own feed with PowerPress and not even it gives the full control I wish it did. So here's how I would like my RSS feed to work with these three fields (taken from "What Is Podcasting 2.0 and Why Does It Matter?"): <description>
The podcasting industry has grown a lot since its birth in 2004, but the core of what a podcast could be
and what it could do hasn't changed much. Now, Podcasting 2.0 revolutionizes the industry with highly requested
innovations that will help everyone on all sides of the RSS feeds.
</description>
<podcast:notes>
<![CDATA[
<p>The podcasting industry has grown a lot since its birth in 2004, but the core of what a podcast could be and what it could do hasn't changed much. Now, Podcasting 2.0 revolutionizes the industry with highly requested innovations that will help everyone on all sides of the RSS feeds.</p>
<p>Please share this episode from your podcast app or https://theaudacitytopodcast.com/podcasting20</p>
<p>## What is "Podcasting 2.0"?</p>
<ul>
<li><a href="https://PodcastNamespace.org">Learn more about the Podcast Namespace</a></li>
<li><a href="https://podcastindex.org/podcast/920666">Follow the Podcasting 2.0 podcast</a></li>
</ul>
<p>## Podcasting 2.0 is for audiences</p>
<p>## Podcasting 2.0 is for podcasters</p>
<p>## Podcasting 2.0 is for developers</p>
<p>## Podcasting 2.0 is even for advertisers</p>
<p>## This is the new litmus test for podcasting tools</p>
<p>If your podcast-publishing tools do not already support Podcasting 2.0, switch!</p>
<a href="">Retweet this</a></p>
<p>## How to upgrade your podcast experience with Podcasting 2.0</p>
<ul>
<li><a href="https://github.com/Lehmancreations/Podcast-Namespace-Wordpress-Plugin/releases">WordPress with PowerPress, plus the Podcast Namespace plugin</a></li>
<li><a href="https://theaudacitytopodcast.com/blubrry">Blubrry podcast hosting</a></li>
<li><a href="https://theaudacitytopodcast.com/buzzsprout">Buzzsprout</a></li>
<li><a href="https://theaudacitytopodcast.com/libsyn">Libsyn</a></li>
<li><a href="https://theaudacitytopodcast.com/captivate">Captivate</a></li>
<li><a href="https://podcastindex.org/apps">More options</a></li>
</ul>
<p>## How to get involved in Podcasting 2.0</p>
<ul>
<li><a href="https://podcastindex.org">Main website</a></li>
<li><a href="https://podcastindex.org/podcast/920666">Podcasting 2.0 podcast</a></li>
<li><a href="https://podcastindex.social">Social conversations</a></li>
<li><a href="https://github.com/Podcastindex-org">GitHub</a></li>
<li><a href="https://github.com/Podcastindex-org/podcast-namespace">Podcast Namespace on GitHub</a></li>
</ul>
<p>## Accept no cheap imitations!</p>
<hr />
<p>Start and grow your own podcast for passion and PROFIT! Learn more and follow at https://theaudacitytopodcast.com/</p>
<p>Know, engage, and grow your audience with the power of podcast reviews! https://mypodcastreviews.com/</p>
<p>FEEDBACK</p>
<p>Call (903) 231-2221<br />
Email feedback@theaudacitytopodcast.com<br />
Send a voice message from https://theaudacitytopodcast.com/</p>
<p>MAILING ADDRESS</p>
<p>The Audacity to Podcast<br />
PO Box 739<br />
Burlington, KY 41005</p>
]]>
</podcast:notes>
<content:encoded>
<![CDATA[
<p>The podcasting industry has grown a lot since its birth in 2004, but the core of what a podcast could be and what it could <em>do</em> hasn't changed much. Now, Podcasting 2.0 revolutionizes the industry with highly requested innovations that will help everyone on all sides of the RSS feeds.</p>
<h2>What <em>is</em> “Podcasting 2.0”?</h2>
<p>Podcasting was created by Adam Curry and Dave Winer. Now, Adam Curry—the only true “podfather”—and Dave Jones are leading the way to the next generation of podcasting, and I'm thrilled to be an active contributor!</p>
<p>Podcasting 2.0 is improving the podcast experience for listeners, podcasters, developers, and even advertisers. It's creating the next generation of podcasting by making podcasts more engaging. Podcasting 2.0 introduces new technical standards, new ways to monetize, and an independently maintained podcast catalog free from corporate and government censorship. Whether you're a listener, a podcaster, a podcast-app or podcasting-service developer, and someone who advertises in podcasts, there's something to make podcasts better for you!</p>
<p>RSS is a particular standard of the coding language called XML (“extensible markup language”). And the way to <em>extend</em> XML or RSS is by adding another namespace. You're probably a little familiar with two popular namespaces already: the “iTunes” namespace Apple created and that most podcast apps use for podcast data, and also the “content” namespace from which we get the <code><content:encoded></code> tag we use for episode notes.</p>
[The rest of the full article …]
]]>
</content:encoded> In this example, But this is a perfect-world scenario where podcasters have the resources to represent their content in three ways (summary, actionable notes, and full written content). |
To clarify this. Apple Podcasts used to (or maybe they still do, I always forget which is my test episode) display both the description and content in the episode notes, but only if the description was not a verbatim copy of the first part of the content. If they were different, even by one punctuation (or HTML formatting), Apple would display both. I thought this was smart behavior. I'm looking at my actual RSS feed (which is similar to the above, except |
Oh, and in the above RSS example, |
This is a good point, my feed template was created manually, so I have blinders up to the minimal control most podcasters have to work with in their CMS of choice.
That's wild, I had no idea they were (potentially are?) compositing feed content like that. But back to the proposal, from your feedback it sounds like the |
Maybe just edit the title and your original post, or prepend an update. But I would like to see a |
To clarify this, I mean that some podcasters don't have the time, money, knowledge, or interest to represent their content in three different ways. I think the order of priority would be description > notes > article > transcript. In other words, if the podcast could do only one thing, do an episode description. If two things, then description and the concise actionable notes. If three things, description, notes, and article. And if four things, description, notes, article, and transcript (in the transcript tag). |
No Agenda's actionable notes (which don't display in podcast apps) would be perfect for |
This revision remains below for historical preservation purposes only. Proposal (Rev 1)WhatA new tag WhyToday, there's no great place to expose actionable notes. The
The community would greatly benefit from having a proper means to supply this kind of content while still leaving Parent
CountSingle Node values
Example<!-- Content such as this isn't well served by either <description> or <content:encoded> -->
<podcast:notes>
<![CDATA[
<p>The podcasting industry has grown a lot since its birth in 2004, but the core of what a podcast could be and what it could do hasn't changed much. Now, Podcasting 2.0 revolutionizes the industry with highly requested innovations that will help everyone on all sides of the RSS feeds.</p>
<p>Please share this episode from your podcast app or https://theaudacitytopodcast.com/podcasting20</p>
<p>## What is "Podcasting 2.0"?</p>
<ul>
<li><a href="https://PodcastNamespace.org">Learn more about the Podcast Namespace</a></li>
<li><a href="https://podcastindex.org/podcast/920666">Follow the Podcasting 2.0 podcast</a></li>
</ul>
<p>## Podcasting 2.0 is for audiences</p>
<p>## Podcasting 2.0 is for podcasters</p>
<p>## Podcasting 2.0 is for developers</p>
<p>## Podcasting 2.0 is even for advertisers</p>
<p>## This is the new litmus test for podcasting tools</p>
<p>If your podcast-publishing tools do not already support Podcasting 2.0, switch!</p>
<a href="">Retweet this</a></p>
<p>## How to upgrade your podcast experience with Podcasting 2.0</p>
<ul>
<li><a href="https://github.com/Lehmancreations/Podcast-Namespace-Wordpress-Plugin/releases">WordPress with PowerPress, plus the Podcast Namespace plugin</a></li>
<li><a href="https://theaudacitytopodcast.com/blubrry">Blubrry podcast hosting</a></li>
<li><a href="https://theaudacitytopodcast.com/buzzsprout">Buzzsprout</a></li>
<li><a href="https://theaudacitytopodcast.com/libsyn">Libsyn</a></li>
<li><a href="https://theaudacitytopodcast.com/captivate">Captivate</a></li>
<li><a href="https://podcastindex.org/apps">More options</a></li>
</ul>
<p>## How to get involved in Podcasting 2.0</p>
<ul>
<li><a href="https://podcastindex.org">Main website</a></li>
<li><a href="https://podcastindex.org/podcast/920666">Podcasting 2.0 podcast</a></li>
<li><a href="https://podcastindex.social">Social conversations</a></li>
<li><a href="https://github.com/Podcastindex-org">GitHub</a></li>
<li><a href="https://github.com/Podcastindex-org/podcast-namespace">Podcast Namespace on GitHub</a></li>
</ul>
<p>## Accept no cheap imitations!</p>
<hr />
<p>Start and grow your own podcast for passion and PROFIT! Learn more and follow at https://theaudacitytopodcast.com/</p>
<p>Know, engage, and grow your audience with the power of podcast reviews! https://mypodcastreviews.com/</p>
<p>FEEDBACK</p>
<p>Call (903) 231-2221<br />
Email feedback@theaudacitytopodcast.com<br />
Send a voice message from https://theaudacitytopodcast.com/</p>
<p>MAILING ADDRESS</p>
<p>The Audacity to Podcast<br />
PO Box 739<br />
Burlington, KY 41005</p>
]]>
</podcast:notes> |
Understood 👍🏻 Title updated and original proposal updated to link to the latest proposal below (left the original proposal as-is for a paper trail/historical preservation). |
Bravo! I love it! I'm now thinking this should actually go in the episode data file (#404) instead of in the RSS feed, but in a similar format and for the exact same purpose—only inserted in a different place. Putting it in the episode data file allows podcasters to change the notes anytime without having to refresh the RSS feed. And since I think Podcasting 2.0 apps are supposed to load the episode data file whenever the episode is played, this ensures that the latest version of the notes is always shown to the audience. |
I think that's a great idea! Amending the proposal now with consideration to your most recent thoughts shared here... |
Proposal (Rev 2)WhatA new tag WhyToday, there's no great place to expose actionable notes. The
The community would greatly benefit from having a proper means to supply this kind of content while still leaving This data will be stored in the episode data file so the notes can be changed at any time without requiring a refresh of the RSS feed. Additionally, these notes would only be fetched whenever the given episode is viewed and/or played, so clients would have a means to ensure that the latest version of the notes is always directly fetched and displayed. Parent
CountSingle Attributes
The Episode File Notes FieldThe Example<podcast:notes url="https://example.com/episode1/episode-data.json" type="application/json+episode-data" /> To keep the example simple, this episode file does not contain chapters:
|
Sorry. But... This appears to be a set of unstructured/freeform data that apps can do nothing with other than display. We already have one of these - it's called the
...citation needed, I believe is the phrase. I do not believe that the case has been made as to why another set of unstructured data is helpful - and I would argue that we should avoid encouraging any type of unstructured data. Looking through the example given, I see... A postal address and A telephone number and, indeed, many different portions of what is simply defined as an organization. As it currently is, there's nothing here to help an app display this information, much less make a telephone number callable from the app, or anything similar. It seems a missed opportunity. But - the good news is that you CAN and SHOULD be able to format this stuff so that an app or computer knows what to do with it. JSON LD is already used by Google, Bing and many more people. Here's an organisation... <script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"address": {
"@type": "PostalAddress",
"addressLocality": "Paris, France",
"postalCode": "F-75002",
"streetAddress": "38 avenue de l'Opera"
},
"email": "secretariat(at)google.org",
"faxNumber": "( 33 1) 42 68 53 01",
"member": [
{
"@type": "Organization"
},
{
"@type": "Organization"
}
],
"alumni": [
{
"@type": "Person",
"name": "Jack Dan"
},
{
"@type": "Person",
"name": "John Smith"
}
],
"name": "Google.org (GOOG)",
"telephone": "( 33 1) 42 68 53 00"
}
</script> ...and the person schema is very well formed as well. For "further reading" links, there's probably a good schema for that, too - making it clear which links are related to the organisation and which are related to the content of the podcast. You can even use a 'person' for much of this if it's related to the data. I really don't see why we're building another freeform bit of text here. Sorry again. Can anyone help me understand? |
Apologies, should have linked that. The RSS spec is brief and clear on
So it is indeed intended to represent a summary/description/synopsis of the item in question, not the full text of the article or full show notes. Is https://rssboard.org not the right resource I should be using for this? Perhaps I'm reading the wrong spec? |
The proposed organization node is not sufficient to capture the diverse content the podcasting community puts into what we colloquially refer to as "show notes", it's a bit dismissive of the real value this kind of data provides to creators and their audience. How would that meet No Dumb Questions' show notes needs? Reconcilable Differences? |
Hi, @barrowclift - thanks for the link to the RSS 2.0 specification. Full-text RSS feeds have been encouraged for some time now, so it's interesting to see that the actual specification is as merely a synopsis. Wordpress offers, for publishers, the choice of a full-text RSS feed and a summary one. As an RSS reader user, I'd much prefer full-text, long-form RSS feeds, and that's what I'm suggesting here. As you suggest above, Let me gently question, then - the As to the use of schema - I'm not proposing an organization node replaces the free-form string that you're suggesting: of course, that doesn't work. However, schema definitions certainly should form part of any replacement. I'd be very keen NOT to just link to another useless wodge of text, which is incapable of being parsed and used programmatically. At least, by linking to a website, the publisher is free to use schema definitions where it makes sense. As it currently is, I'm still not understanding the benefit of this proposal. |
I think a few things are getting mixed up and missed here. Yes, @jamescridland, may I ask you to revisit my examples above? I used Here's another way to look at it. This "notes" feature can be like the handouts some speakers give before the sessions. The headouts contain the outline, some very short notes, and some citations. But the "full content" is in what the speaker says, and the "description" was in the session description. By the way, that WordPress feature merely toggles the presence of
That's what we're wrestling with by considering/proposing this to be in the episode data file—along with the chapters. Because these short, actionable notes wouldn't be necessary to access until an episode is opened or played—just like how chapters aren't loaded until then. I know that not every podcaster will use this, just like not every podcaster will use chapters. But I think it's something that could significantly improve the listening experience. Plus, some publishing tools could even automatically generate the notes from the full content (mine could probably be auto-generated). I didn't realize until yesterday that I'd actually proposed something similar to this in a couple or few previous conversations. But I never put the full work into documenting it like @barrowclift did. But I also wonder if maybe this should be merged with #400 so that this actionable text/outline could be put in the chapters and possibly reduce redundant information. (But I think a "notes" field would be much easier to populate than chapters.) |
Hey, @barrowclift, since you and I are the main proponents of this, what do you think about the idea of merging this general idea with my proposal for allowing rich text in chapters (#400)? My main reason for considering this is to prevent duplication. I also think it could also be easier to get more app-developers to support rich chapters than to support an all-new text field. Then again, this means entering the information in a chapter-by-chapter process instead of a straight copy-and-paste. But maybe some chapter-creation tools could be updated to support a "bulk" paste. So what I'm thinking is the exact same kinds of concise, actionable notes, only split into chapters so the notes would display in Podcasting 2.0 apps while that chapter is playing. This would have the added benefit of preventing the listener from having to scroll to find the right section of the notes. I'd be happy to jump on a call sometime to discuss ideas in real time. |
By "prevent duplication," I mean having the same text in two places (notes and rich chapters). |
That's a fantastic idea, I'm into it! The show notes I'm used to interacting with have implied timestamps and/or chapter associations to them, but this information necessarily is dropped when it's dumped unceremoniously into the So yeah, I'd say you're right that's the path forward. 👍🏻 |
Sounds good! I'll focus my further thoughts on #400 then, and I hope for your input to, so we can ensure the needs your foresee are also answered in it. |
This original proposal remains below for historical preservation purposes only.
What
Two new tags:
<podcast:notes>
for what we'd consider "show notes", where long form details from a particular episode like referenced materials, links, images, etc. would reside (e.g. see https://atp.fm/503)<podcast:summary>
for a brief summary or synopsis of the episode in question (e.g.Tony and friends discuss Netflix's new series, "The Sandman"
)Why
Against the RSS spec, the
<description>
element is used by many creators for long form "show notes" and not a short synopsis, leaving no tag appropriate to hold a brief actual description of the episode in question.Since
<description>
is often used in this way, clients don't have a nice, brief synopsis available to display in episode lists. The only appropriate tag they have is<description>
, but since many creators use this for long form show notes, it can result in suboptimal episode lists like this: https://podcastindex.org/podcast/44367The community would greatly benefit from having a proper means to supply both a brief list-friendly episode summary and long form show notes.
How
I propose two new tags instead of just introducing a single new one because there's no community consensus on how to use
<description>
. There are many podcasts out there that use<description>
for that brief summary (e.g. https://podcastindex.org/podcast/961821), but there are many others that instead use<description>
for their detailed episode notes (e.g. https://podcastindex.org/podcast/44367).Perhaps because of this, Podcast clients commonly use
<description>
for both their episode list summary text (trimmed to a certain number of characters) and their notes text when viewing or playing a particular episode. This historical baggage not only leads to a subpar user experience, but also prevents us from making assumptions about what it does or does not contain.The most pragmatic way to solve this is a clean break for the podcast namespace: leave
<description>
as the abused fallback, but provide two new tags in the podcast namespace to prevent this issue from happening again:<podcast:notes>
and<podcast:summary>
.Parent
<item>
for bothCount
Single for each
Node values
<podcast:summary>
would be a free-form String, with a plead similar to thePerson
node value to not exceed180
characters for the node value or risk truncation by aggregators or clients.<podcast:notes>
would also be a free-form String, only this time with no specified character limit, in the same way there's no character limit today on the RSS<description>
field.Examples
The text was updated successfully, but these errors were encountered: