Proposal: <podcast:author>, <podcast:domain> tag to indicate machine-friendly organizational authorship

[jefforulez]

Proposal

Add the following tags to allow for machine-friendly grouping of podcasts by author organization:

<podcast:author>
  <podcast:domain>com.example</podcast:domain>
</podcast:author>

or

<podcast:author>
  <podcast:domain>com.example</podcast:domain>
  <podcast:domain>com.rulez</podcast:domain>
</podcast:author>

Existing Tags

Podcast authorship is currently indicated by the <itunes:author> tag from the itunes namespace.

Apple's description of this tag is:

The group responsible for creating the show.

Show author most often refers to the parent company or network of a podcast, but it can also be used to identify the host(s) if none exists.

Author information is especially useful if a company or organization publishes multiple podcasts.

from https://help.apple.com/itc/podcasts_connect/#/itcb54353390

This prescribed usage allows for flexibility and human-friendly presentation in podcast apps, but this flexibility and overloaded meaning creates complexity for machines indexing podcasts and podcast apps wishing to surface podcasts by publishing organization.

Co-Authored Podcast Example

The following podcast was co-authored by Serial Productions and The New York Times:

• "The Coldest Case In Laramie"
• https://podcastindex.org/podcast/6039489

To indicate co-authorship, the podcasts RSS ( https://feeds.simplecast.com/wHqls8d1 ) has this tag:

<itunes:author>Serial Productions &amp; The New York Times</itunes:author>

This tag is human friendly, but confusing to machines.

A search engine or index would have difficulty grouping podcasts with the following author tags:

<itunes:author>Serial Productions &amp; The New York Times</itunes:author>
<itunes:author>Serial Productions</itunes:author>
<itunes:author>The New York Times</itunes:author>

Under the current proposal, the new RSS could be:

<podcast:author>
  <podcast:domain>org.serialpodcast</podcast:domain>
  <podcast:domain>com.nytimes</podcast:domain>
</podcast:author>

Podcast Author Verification

As an extension to this proposal, a DNS-based mechanism for verifying the <podcast:domain> values for a podcast could be implemented.

For example, TXT records could added to serialpodcast.org and nytimes.com which verify association with a podcast feed:

$ host -t txt serialpodcast.org | grep podcast
serialpodcast.org descriptive text "podcast=https://feeds.simplecast.com/wHqls8d1"

and

$ host -t txt nytimes.com | grep podcast
nytimes.com descriptive text "podcast=https://feeds.simplecast.com/wHqls8d1"

[daveajones]

Very interesting proposal. Generally when there are name collisions with the itunes namespace we aim to keep perfect fallback compatibility with itunes and just add our new ideas on top. See the <podcast:block> tag as an example. So, in this case we would need to maintain the ability to just have a simple text description in the node, but add the expanded child nodes.

Like:

<podcast:author>
  Serial Productions &amp; The New York Times
  <podcast:domain>org.serialpodcast</podcast:domain>
  <podcast:domain>com.nytimes</podcast:domain>
</podcast:author>

[thomasrynne]

I think this is similar to #240 but instead of referencing a list of shows/feeds it references a domain name.
Or perhaps this is achieving something quite different?
This did prompt me to think about #240 and I have just added a comment to that suggestion.

[jefforulez]

@daveajones thank you for recommending this change. i didn't know mixing text with child tags is valid xml – i guess you do learn something new every day!

<podcast:author>
  Serial Productions &amp; The New York Times
  <podcast:domain>org.serialpodcast</podcast:domain>
  <podcast:domain>com.nytimes</podcast:domain>
</podcast:author>

@thomasrynne thanks for mentioning #240 – i hadn't seen that proposal before. i do think that is solving for a different use case, with some overlap.

i like the <podcast:related> variant in #240 since that allows for a content-centric grouping of podcasts – regardless of content author.

this proposal, on the other hand, is looking to address a different use case: conveying a stricter author / content owner-centric association between podcasts.

@jamescridland thank you for mentioning this proposal on podnews yesterday! i actually lol'd when i heard it. 😄

[theDanielJLewis]

I'm having trouble seeing why we need this when we already have the (albeit badly named) "person" tag, which can be used for credits like this.

Consider, for example, why would someone need a different search for podcasts from The New York Times versus from John Doe? Both names can be put in the "person" tag as credits for the podcast, and thus both be equally searchable.

[samsethi]

Hi

Instead of two author fields could this be named producer and why is the domain name showing as back to front? com.domain???

[genebean]

It seems to me this would be a natural extension of the person tag, or at least that naming wise they have some overlap. Assuming it shouldn’t be part of person, where is the dividing line between the two?

[samsethi]

It seems to me this would be a natural extension of the person tag, or at least that naming wise they have some overlap. Assuming it shouldn’t be part of person, where is the dividing line between the two?

The person tag is for people and this tag called Author/Producer is about the company not the individual. I equally want a host tag. Some people like Captivate are using the Generator Tag to populate their RSS feed to indicate they are the host.

[theDanielJLewis]

The "person" tag should really always have been a "credit" tag for listing credits. But since "tag names don't matter," we can still put a company in the person tag anyway.

I hate to create redundancy, but if we want the Podcast Namespace to be a drop-in replacement for the Apple Podcasts namespace, then we have to have a drop-in replacement for <itunes:author>. Maybe it can support the same data as Apple's namespace, but an attribute can tie the author to one or more of the credits in the person tags.

[samsethi]

I really like this proposal. Podfans had a similar idea of creating producer pages in our app before this proposal. So if you listened to a podcast you could click on the producer link e.g Wondery and go to a page in Podfans like an Apple Channel to see other podcasts from that producer.

This is another great way to discover other podcasts to follow. We were in the process of implementing this as a client app solution. However, I would prefer if this was an open RSS solution. This means hosts have to implement this so that apps like Podfans can just injest the RSS feed and the new podcast:author field.

Below was our initial stab. We have added a producer field which is the podcast:author field and the domain. So if the RSS field was like the XML below we would fill in the required fields.

podcast:author
Serial Productions & The New York Times
podcast:domainorg.serialpodcast</podcast:domain>
podcast:domaincom.nytimes</podcast:domain>
</podcast:author>

This is a great solution if we want to have a producer link in our app for every podcast page and if clicked it would link out to the related domain. This is not what we need in Podfans. We need to offer an internal link to a producer page. So now I am trying to think why any app developer would support this as it drives users out of our apps to another website?

[theDanielJLewis]

But again, why not be able to click the person/company from the "person" tag for this behavior? Look at Podchaser for an example.