search

Podcastindex-org / podcast-namespace

A wholistic rss namespace for podcasting
Creative Commons Zero v1.0 Universal
372 stars 111 forks source link

Proposal - <podcast:notes> #399

Closed barrowclift closed 1 year ago

barrowclift commented 1 year ago

⚠️ Click here to read the latest proposal in the comments ⚠️

This original proposal remains below for historical preservation purposes only.

What

Two new tags:

  1. <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)
  2. <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/44367

The 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 both

Count

Single for each

Node values

<podcast:summary> would be a free-form String, with a plead similar to the Person node value to not exceed 180 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

<podcast:summary>Tony and friends discuss Netflix's new series, "The Sandman"</podcast:summary>
<podcast:notes><![CDATA[<ul>
<li>Follow-up:
<ul>
<li>Link to the previous show discussed: <a href="#">"Some Great Show"</a></li>
<li>Some correction on an assertion made on a previous episode, it was Foo, not Bar.</li>
</ul>
</li>
<li><a href="#">Click here to read up on some event mentioned off-hand during the show</a>
<li><a href="#">Direct link to some cool quote from someone</a></li>
<li><img src="#" alt="some image referenced during the show"</li>
<li>You get the idea.</li>
</ul>
]]></podcast:nodes>
theDanielJLewis commented 1 year ago

I agree that there we should have a <podcast:notes> tag, but for a different use, and I have issues with the presented premise.

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 <itunes:summary> tag in favor of the RSS standard tag <description>. And we already have a tag that's so common for long-form content that I think many people don't realize it's not a standard RSS tag: <content:encoded>.

I think the description should be for the one-paragraph summary of the episode, <content:encoded> for the full text version (either an article or a well-formatted transcript), and then our new tag <podcast:notes> for the actionable notes (like the outline, links, and citations).

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&#039;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> &#8220;Podcasting 2.0&#8221;?</h2>

    <p>Podcasting was created by Adam Curry and Dave Winer. Now, Adam Curry—the only true &#8220;podfather&#8221;—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 (&#8220;extensible markup language&#8221;). 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 &#8220;iTunes&#8221; namespace Apple created and that most podcast apps use for podcast data, and also the &#8220;content&#8221; namespace from which we get the <code>&lt;content:encoded&gt;</code> tag we use for episode notes.</p>

    [The rest of the full article …]
  ]]>
</content:encoded>

In this example, <description> would be shown as a preview of the content, before playing or opening the episode. <podcast:notes> would be shown when you open/play the episode (possibly with <description> prepended unless a duplicate of the first paragraph, like Apple Podcasts used to handle it), and <content:encoded> would be used only by RSS aggregators built for reading.

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).

theDanielJLewis commented 1 year ago

… like Apple Podcasts used to handle it

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 <podcast:notes> contains plaintext URLs and is the <itunes:summary> tag) and how Apple Podcasts is displaying it. Apple is actually still displaying <content:encoded> for my episode notes, but truncated. I would turn off <content:encoded> for my podcast-only RSS feed from PowerPress, but that's not an option unless I switch WordPress's entire feed mode to excerpts instead of full text. I need to talk to Blubrry support with my ideas for improving PowerPress's feed.

theDanielJLewis commented 1 year ago

Oh, and in the above RSS example, <content:encoded> would actually be omitted from my podcast RSS feed, but visible in my site's regular RSS feed. (This is what PowerPress doesn't let me do, as far as I know.)

barrowclift commented 1 year ago

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).

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.

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.

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 <podcast:summary> bit was ill conceived, but the <podcast:notes> has potential merit. Would you recommend I cancel this and open up a new proposal for just the <podcast:notes> tag? Or would you rather I leave this as-is? And thanks for the detailed feedback!

theDanielJLewis commented 1 year ago

Maybe just edit the title and your original post, or prepend an update.

But I would like to see a <podcast:notes> tag for hosting this kind of content separate from the description and full written content.

theDanielJLewis commented 1 year ago

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, 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).

theDanielJLewis commented 1 year ago

No Agenda's actionable notes (which don't display in podcast apps) would be perfect for <podcast:notes>. Knick Knack News already publishes their notes in the concise, actionable format, and that's what shows in podcast apps because that's as thorough as they get (essentially two levels deep).

barrowclift commented 1 year ago

⚠️ Click here to read the latest proposal in the comments ⚠️

This revision remains below for historical preservation purposes only.

Proposal (Rev 1)

What

A new tag <podcast:notes> is suggested to expose actionable notes for a given episode, such as an outline, links, and citations. See examples such as No Agenda's episode notes and ATP's "show notes" for kind the content this tag would expose.

Why

Today, there's no great place to expose actionable notes. The <description> tag is typically used for this as a crutch, but that tag is meant for a concise synopsis or description of the episode in question, not long lists of links, citations, etc.

<content:encoded> could in theory serve this purpose, but it's more appropriately reserved to express a full-text version of the episode, such as an article or transcript. This leaves no suitable home for actionable notes.

The community would greatly benefit from having a proper means to supply this kind of content while still leaving <description> available for the episode synopsis and <content:encoded> available for a full-length equivalent article or episode transcript.

Parent

<item>

Count

Single

Node values

<podcast:notes> would be a free-form String with no specified character limit.

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>
barrowclift commented 1 year ago

Maybe just edit the title and your original post, or prepend an update.

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).

theDanielJLewis commented 1 year ago

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.

barrowclift commented 1 year ago

I'm now thinking this should actually go in the episode data file (https://github.com/Podcastindex-org/podcast-namespace/issues/404) instead of in the RSS feed, but in a similar format and for the exact same purpose—only inserted in a different place.

I think that's a great idea! Amending the proposal now with consideration to your most recent thoughts shared here...

barrowclift commented 1 year ago

Proposal (Rev 2)

What

A new tag <podcast:notes> is suggested to link to the external episode data file, which could additionally contain the actionable notes for a given episode, such as an outline, links, and citations. See No Agenda's episode notes and ATP's "show notes" for examples of what this tag would expose.

Why

Today, there's no great place to expose actionable notes. The <description> tag is typically used for this as a crutch, but that tag is meant for a concise synopsis or description of the episode in question, not long lists of links, citations, etc.

<content:encoded> could in theory serve this purpose, but it's more appropriately reserved to express a full-text version of the episode, such as an article or transcript. Additionally, that requires regenerating the entire RSS feed whenever any changes to the notes are required. This leaves no suitable home for actionable notes.

The community would greatly benefit from having a proper means to supply this kind of content while still leaving <description> available for the episode synopsis and <content:encoded> available for a full-length equivalent article or episode transcript.

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

<item>

Count

Single

Attributes

The Episode File Notes Field

The notes field is an optional string property that resides at the root of the episode data file (alongside version and chapters).

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:

{
    "version": 1.3,
    "notes": "<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>\n    <p>Please share this episode from your podcast app or https://theaudacitytopodcast.com/podcasting20</p>\n    <p>## What is \"Podcasting 2.0\"?</p>\n    <ul>\n      <li><a href=\"https://PodcastNamespace.org\">Learn more about the Podcast Namespace</a></li>\n      <li><a href=\"https://podcastindex.org/podcast/920666\">Follow the Podcasting 2.0 podcast</a></li>\n    </ul>\n    <p>## Podcasting 2.0 is for audiences</p>\n    <p>## Podcasting 2.0 is for podcasters</p>\n    <p>## Podcasting 2.0 is for developers</p>\n    <p>## Podcasting 2.0 is even for advertisers</p>\n    <p>## This is the new litmus test for podcasting tools</p>\n    <p>If your podcast-publishing tools do not already support Podcasting 2.0, switch!</p>\n    <a href=\"\">Retweet this</a></p>\n    <p>## How to upgrade your podcast experience with Podcasting 2.0</p>\n    <ul>\n      <li><a href=\"https://github.com/Lehmancreations/Podcast-Namespace-Wordpress-Plugin/releases\">WordPress with PowerPress, plus the Podcast Namespace plugin</a></li>\n      <li><a href=\"https://theaudacitytopodcast.com/blubrry\">Blubrry podcast hosting</a></li>\n      <li><a href=\"https://theaudacitytopodcast.com/buzzsprout\">Buzzsprout</a></li>\n      <li><a href=\"https://theaudacitytopodcast.com/libsyn\">Libsyn</a></li>\n      <li><a href=\"https://theaudacitytopodcast.com/captivate\">Captivate</a></li>\n      <li><a href=\"https://podcastindex.org/apps\">More options</a></li>\n    </ul>\n    <p>## How to get involved in Podcasting 2.0</p>\n    <ul>\n      <li><a href=\"https://podcastindex.org\">Main website</a></li>\n      <li><a href=\"https://podcastindex.org/podcast/920666\">Podcasting 2.0 podcast</a></li>\n      <li><a href=\"https://podcastindex.social\">Social conversations</a></li>\n      <li><a href=\"https://github.com/Podcastindex-org\">GitHub</a></li>\n      <li><a href=\"https://github.com/Podcastindex-org/podcast-namespace\">Podcast Namespace on GitHub</a></li>\n    </ul>\n    <p>## Accept no cheap imitations!</p>\n    <hr />\n    <p>Start and grow your own podcast for passion and PROFIT! Learn more and follow at https://theaudacitytopodcast.com/</p>\n    <p>Know, engage, and grow your audience with the power of podcast reviews! https://mypodcastreviews.com/</p>\n    <p>FEEDBACK</p>\n    <p>Call (903) 231-2221<br />\n    Email feedback@theaudacitytopodcast.com<br />\n    Send a voice message from https://theaudacitytopodcast.com/</p>\n    <p>MAILING ADDRESS</p>\n    <p>The Audacity to Podcast<br />\n    PO Box 739<br />\n    Burlington, KY 41005</p>"
}
jamescridland commented 1 year ago

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 description field (or, if you like, the content:encoded field). I fail to see the usecase for this. The description field can (and SHOULD!) contain the full text of an article, for example, or the full show notes.

Against the RSS spec

...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?

barrowclift commented 1 year ago

The description field can (and SHOULD!) contain the full text of an article, for example, or the full show notes.

Against the RSS spec

...citation needed, I believe is the phrase.

Apologies, should have linked that. The RSS spec is brief and clear on <description>'s intended use in the <item> element:

description    The item synopsis.

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?

barrowclift commented 1 year ago

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?

jamescridland commented 1 year ago

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, <content:encoded> (which isn't in the spec) has been used for full text posts.

Let me gently question, then - the <link> in the <item> is a link to the item. Why would this not be sufficient to link to the long-form notes that a publisher wishes to make available? That means it comes with full HTML, and can embed video, images and other data. What is the benefit of a half-way house with some formatting but presumably not others?

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.

theDanielJLewis commented 1 year ago

I think a few things are getting mixed up and missed here.

Yes, <description> is supposed to be only a synopsis of the content, and I think we should honor that. There are plenty of use cases to display only a small paragraph about an episode instead of the full article/transcript or full outline/notes.

@jamescridland, may I ask you to revisit my examples above? I used <description> for only a synopsis of the content, <content:encoded> for the full article (albeit truncated in my example), and <podcast:notes> for the quick and actionable notes/outline. Where the notes or full content might contain stuff like phone numbers, email addresses, or physical addresses, that's only within a much larger context and is secondary to the main portion of the content: the content.

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 <content:encoded> in the RSS feed, it doesn't restructure any of the other data or change anything. If WordPress-users don't write an excerpt for their post, then WordPress automatically grabs the first portion of the full content and truncates it with a "…"—usually mid-sentence. That truncation happens for <descriptions> whether the feed is "full text" or "summary." The only thing that replaces the truncated <description> is the Excerpt field, or maybe some other plugins do something different.

@jamescridland: Let me gently question, then - the in the is a link to the item. Why would this not be sufficient to link to the long-form notes that a publisher wishes to make available? That means it comes with full HTML, and can embed video, images and other data. What is the benefit of a half-way house with some formatting but presumably not others?

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.)

theDanielJLewis commented 1 year ago

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.

theDanielJLewis commented 1 year ago

By "prevent duplication," I mean having the same text in two places (notes and rich chapters).

barrowclift commented 1 year ago

what do you think about the idea of merging this general idea with my proposal for allowing rich text in chapters (https://github.com/Podcastindex-org/podcast-namespace/issues/400)?

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 <description> element. Having those actionable links & notes properly associated to their relevant chapter allows this information that's lost today to be properly captured, and also opens the door for players to do really interesting UI with those notes that they can't today (and for that matter would continue to be unable to with this proposal as written.)

So yeah, I'd say you're right that's the path forward. 👍🏻

theDanielJLewis commented 1 year ago

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.