Episode Description missing

[klaustopher]

A podcast episode should have a description field. It should be used for the same content as the description-Tag in the RSS feed. So i.e. Show Notes, etc...

There should be an additional field to tell the podcast client how the text should be rendered, like a mime type (text/html, text/x-markdown).

[duerig]

I am confused by the absence of a description as well. Without one, it seems like you cannot generate an RSS item from a podlove specification.

[Kambfhase]

A podcast episode has a summary field. That can be used with arbitrary text.

[klaustopher]

IMHO there should be two fields. I don't really care about the naming, but one should be a short excerpt (that is displayed under the title in your podcatcher, summary in the screenshots) and the other should be a full text with shownotes, a transcript or something else ( description in the screenshots)...

Instacast:

Auphonic:

[timpritlove]

The field in RSS is a very ambiguous and underdefined beast. It is rather unclear what kind of "description" this field should get. Is it a short sentence or paragraph or a very long text? Also, the field is used very differently in various feeds - some use plain text, some use HTML. It's a mess.

Our approach follows the idea of a three-level-cascade of descriptions. The title is the shortest, followed by a subtitle. The summary is the longest, probably spanning a paragraph or two.

The question how this triade should map to RSS is an important one and it probably needs further explanation in this document. I think it should go along these lines: if there is a summary, use that in the field. If there is no summary, use the subtitle. The subtitle is also usually put in the itunes:subtitle field. If you do not want to use iTunes Extensions (which I find very helpful and which are a de-facto standard in the podcast world anyway), you can place the subtitle in the description field and ignore the summary altogether. So it is in fact easy to create RSS from this specification. I think I will add this thought to the document soon.

Regarding extended "shownotes" that come in HTML and with links and all: one should not put these in the RSS description field at all. This stuff is better placed in an content:encoded field which is generally treated as the "shownotes" field by podcast clients anyway.

[klaustopher]

As I said, I do not really care how the field (content:encoded) is called in the specification, but it is still missing :)

[martinhering]

Here is what I think the fields should have.

Title: Short, 2-5 words Subtitle: Short sentence. Summary: Couple of sentences describing the content of the episode. (1 paragraph only). Description: Plain-text description of the content of the episode. (multiple paragraphs). Content:Encoded: Inline Show Notes encoded as HTML (potentially long)

I think the description serves the purpose of being a fallback of the show notes if a client is not able to read the HTML content or in case of linked show notes to display something as long as the html content is not yet loaded.

I would suggest to add a field that links to html show notes by means of a URL.

[timpritlove]

Please understand that this specification is trying to define the core of what you need to properly describe a podcast episode. It neither try to map everything you could put in a RSS feed or a podcast CMS. The first version wants to describe the absolute basics, the minimum you need to know and the stuff that sort of everybody can agree on.

Fields like content:encoded are beyond any definition. People anything in there, no specification would ever be able to define that. And we shouldn't. content:encoded is a hack and should be treated as such.

Our approach is to come up with a clear and well defined spec for detailed show notes in the future. These can be mapped to content:encoded or xhtml:body or whatever makes you happy. But this spec is about carefully choosing the basic building blocks of an easy to integrate description framework.

[timpritlove]

Let me be clear: I really do not intend to have a "description" field in this spec at all. "description" is just too generic and even the RSS spec totally fails to describe what should be in there. Furthermore, this was designed to be used for blogs, not podcasts.

The information cascade "title, subtitle, summary" is much clearer in that respect. It's also the model that is used by both @auphonic and the @podlove publisher for a reason. It's an abstraction that wants to make it very clear what goes where.

Again, what will be used to fill an RSS feed, media file metadata, microblogging announcements, web radio displays etc. is another story and beyond the scope of this document. We want to define a reliable core from which you can take what you want - but at least it is very clear what these fields mean, what they try to describe, what format they are in (in this case: plain text everywhere!) and what size they can be expected to have.

[martinhering]

A reliable core without proper metadata like show notes and chapters (at least linked) is of limited value if you ask me. The people want information, not specification.

[klaustopher]

I agree with that. From a listeners point, I don't really care if the show notes or other metadata are included in the media file, in the RSS feed, in a podlove spec'd document included in an ADN post, or where ever... I want my podcatcher to show me what I need to know about the podcast/episode.

From an authors point of view, I hate that I have to think about all the different hacks I have to use in an RSS feed. When creating a new podcast or a tool for podcast publishing, there is a lot of trial and error when checking with all the clients out there. I would love to see the podlove specs as a "fresh start" to describing podcasts. But, if it doesn't include the features that RSS provides (even if it uses a hack, but that is generally accepted by publishing tools and pod catchers) it's (in my eyes) not complete.

I really like Martin's idea of having a show notes URL field that points to an HTML document. I think this would not blow up the spec, not blow up the episode document (considering the 8k limit on ADN annotations) and still provide the feature.

[duerig]

There is some additional discussion here: https://alpha.app.net/sylar_5/post/5722879

I think @sylar_5's comment is particularly important. We need a spec for show notes, individual content associated with timestamps similar to the chapter spec. Until then, the best thing to do is to provide an escape hatch (at least in an ADN context) by using a second annotation that is more free-form.

When I use the podlove episode specification I will also be using the longposts annotation in app.net to allow users to embed a short markdown-formatted shownotes if they want. This can be transitioned out when the podlove show note spec is created which will allow much more flexibility and machine-introspection. The nice thing about a timestamped show note is that it could also be used by third parties for commentary on a podcast and not just for the author themselves.

[timpritlove]

I think you are missing the intended function of this specification. It is primarily meant to enable autodiscovery. The primary use should be to annotate any other information to point to something that "is a podcast episode". That's why the focus is on the basics here.

This does not mean, this can't be enhanced with other things like a detailed timeline. But that would be another specification ("podlove-timeline").