Proposal: <podcast:channel> (a group of podcasts)

[tomrossi7]

One of Apple's features is the grouping of podcasts into a channel. I kind-of like this idea and wonder if we could incorporate a way to do this within the RSS feed. Perhaps, we provide a podcastChannel tag that uniquely identifies the channel? Or a relatedPodcasts tag that points to a JSON of all the related RSS feeds?

[daveajones]

You beat me to this Tom. This is absolutely a good idea.

[theDanielJLewis]

Isn't this what the recommendation tag is supposed to support?

[tomrossi7]

A channel is not a recommendation, but a collection of related podcasts. A podcast could belong at most to only one channel. The should be grouped together under a name as well.

[vv01f]

a thought on naming …

channel is a name for a dedicated XML element in the feed already. so that naming is not helpful.

a bunch of channels would e. g. be an aggregation. this would also clarify the difference to recommendations.

any better wording or thoughts on that maybe?

[daveajones]

a thought on naming …

channel is a name for a dedicated XML element in the feed already. so that naming is not helpful.

a bunch of channels would e. g. be an aggregation. this would also clarify the difference to recommendations.

any better wording or thoughts on that maybe?

What about <podcast:related> since that was part of Tom’s initial wording?

@tomrossi7 Do you want to write up what a tag structure would look like that you can see implementing? If you don’t have time I can take a crack at it and submit here for comments.

[theDanielJLewis]

"bundle" could be another word to use.

But I'm still having trouble understanding what's different about this compared to recommendations/related.

[chiragnd]

But I'm still having trouble understanding what's different about this compared to recommendations/related.

I’m thinking the difference between these are our shows, ie the same network or producer vs these are things we recommend, which could be anyone’s shows? This is not to say that we can’t have it under one tag and have a field to identify things that are ‘Internal’ vs ‘external’ if that matters.

From an app perspective, I think the difference becomes how it might be shown. It’d be nice to have the option to showcase our Network shows together (similar to the channel idea or a brand page), and our recommendations to be more of a blog roll type list maybe.

[saerdnaer]

@theDanielJLewis recommendations refer to specific episodes, whereas related refers to other shows/podcasts

[douglaskastle]

I am struggling with this too. Is this meant to be a RSS way of showing podcasts that are all part of a podcast network? Or would you use it as an episode level where one might be doing a cross promo? Are there any good existing examples of where this might be used? Is it per podcast or per episode? or both?

[theDanielJLewis]

I’m thinking the difference between these are our shows, ie the same network or producer vs these are things we recommend, which could be anyone’s shows? This is not to say that we can’t have it under one tag and have a field to identify things that are ‘Internal’ vs ‘external’ if that matters.

I like this idea. Whether is a recommended or related tag, let it have some kind of grouping and order. On the channel level, this could replace both "more by this artist" and also provide a more personalized "other shows you might like" list.

Having some control over the labeling and order can help differentiate these things, too. There could be standard tags, like recommended for the related recommended shows, and withhost or something like that for grouping other podcasts hosted or cohosted by the hosts, even if not their own.

For example, my own show would obviously list my other shows (unless I didn't want a show connected in this context), but I could also list Podcasters' Roundtable, of which I'm an official cohost but it's not my own show.

Then on the item level, the recommendations/related could be to other relevant episodes or entire shows as well. For example, if I do an episode about writing, I could link to a couple other "writing for podcasters" kinds of episodes, as well as entire shows all about writing.

[daveajones]

EDIT: Updated with a newer proposal below.

cc: @tomrossi7 @KieranMcKeefery @eteubert @cio-blubrry @PofMagicfingers @dan

[eteubert]

In a perfect world each podcast would have a guid. Then we could use this guid as reference instead of a URL, which may change. But the feed URL seems like a close second choice because the podcaster has a high interest in keeping that stable or at least redirecting to the current URL.

I do like the draft. Simple enough and provides enough data for the usual display of such lists.

[daveajones]

Agreed on the UUID thing. We’re brainstorming possible solutions to that here. It’s a tough one. ☹️

Would having a thumbnail url attribute included next to the feed url attribute in podcast:relatedFeed be wise? To give apps what they need for a nice UI presentation?

cc: @MartinMouritzen @dellagustin @mitchdowney

[MartinMouritzen]

At this part of the user journey, I would most likely just look up the podcasts through the API, so at least for my purposes a thumbnail url is not necessary here.

• If we think that would open up for too many API calls, then yes a thumbnail would make great sense :)

[tomrossi7]

Its not that big of a deal, but I do like <podcast:channel> better or possibly <podcast:network>. If an XML parser can't properly parse namespace tags, they are bound to run into collisions even now. Related sounds more loose a definition e.g. I mentioned Joe Rogan in one of my episodes so now I'm going to say I'm related to his RSS feed.

I like the idea of a podcast having the option of belonging to one and only one channel or network. I don't know how we could enforce integrity, but we can at least make it part of the spec and allow aggregators the ability to invalidate feeds.

Just my 2 cents!

[theDanielJLewis]

I think there are multiple uses we can consider and thus might want to have a more inclusive tag name.

Yes, this could be used for an actual network/affiliation. It could also be used for related podcasts, recommended podcasts.

So I keep thinking ally kinds of references to a different podcast should should use the same tag. It could be <podcast:featured> or <podcast:link> an then a rel attribute to indicate its relationship. Potential starting attribute values could be “network” and “recommended.”

[mitchdowney]

I'd vote for "network" since it implies a "group" of some kind, whereas "channel" sounds like just one thing. Also because "channel" is already the name for the top-level RSS feed item. Otherwise maybe "channels"?

[mitchdowney]

Podverse is close to adding support for podcast:medium for music, but before we do that, ideally this tag would be formalized.

I was chatting with @agates about "how do we group music albums under a single artist, if each album or single is its own RSS feed?" and he said he envisioned the channel could support this use case. Since channels seem like basically a group of RSS feeds, I think this makes sense.

What do we need to do to get this namespace over the finish line?

[thomasrynne]

I've been thinking about this since @agates linked to it on podcastindex.social
I'd like to propose an alternative which I believe is simpler. Instead of creating a new channel json spec an rss feed can be used to represent the network/channel.

The child feed would only include the tag:
<podcast:belongsTo url="http://example.org/network.rss" guid="e0eac5f3-209f-4a38-b8a8-3291905c317f" />

And the 'network'/parent feed would list the children:
<podcast:child url="http://example.org/feed1.rss" guid="7bf2aef7-f1ba-4f29-b2a0-d043aefcf325" />
<podcast:child url="http://example.org/feed2.rss" guid="8a3e2ca9-e668-435f-b457-ae25513e7e73" />

Perhaps the network feed could also have a new medium of 'collection'.

When a podcast app sees the belongsTo tag it would lookup the parent feed and see whether this feed does belong to that feed. If the feed is not listed the tag is ignored. If the feed is found the title & image of the network feed could be shown next to the feed. Clicking on the network feed would list the children.

I think the benefits of this approach are:

• I suspect it is less work for hosts and app developers because It's just two new tags
• Subscribing to the network list (to see new shows from the network) is just subscribing to an rss feed
• Notifying apps of changes to the network list can be published with a normal podping
• It doesn't define a new 'top level' entity.
• It's compatible with podcasting 1.0 apps because it's just an rss feed which means there is more value in creating a network rss feed. The feed could include short audio items announcing any changes that users subscribed with an old app can see that there is a new podcast in the network (they would then need to manually search & subscribe)

However this is implemented it needs more feedback, especially from hosts

I would really like to see this to find new shows, but as mentioned above I think it could be used to link Artist's albums too.

[agates]

So, thinking about this more (as mentioned in my other comment), I'm beginning to think channels as RSS feeds with a dedicated medium would be beneficial for two reasons:

1. It would allow us to use the other podcast namespace RSS tags as you mentioned. In particular, I think having a "channel id" with <podcast:guid> would be useful for referencing
2. It would allow us to publish channel updates via podping.

Where we go from there with how to reference stuff is TBD in my mind still (haven't thought about it much) but I like this idea more as I think about it.

cc @daveajones since we talked about this privately

[agates]

@thomasrynne I think that could work by just using OPML instead of a sort of "collection" oriented RSS feed, which would keep the implementation even simpler. I'll mull over the idea and see if I can think of any major drawbacks.

[genebean]

FWIW, I like the idea of this but dislike the idea of calling it channel. Podcasters talk about their podcast network already so I think podcast:network makes sense as a name and more clearly conveys the intent.

[agates]

FWIW, I like the idea of this but dislike the idea of calling it channel. Podcasters talk about their podcast network already so I think podcast:network makes sense as a name and more clearly conveys the intent.

I would agree with you if it were meant for only podcasting, but I could make the same argument and call it something like podcast:artist for music too. If anything, something like podcast:group would cover the most ground.

[genebean]

I would agree with you if it were meant for only podcasting, but I could make the same argument and call it something like podcast:artist for music too. If anything, something like podcast:group would cover the most ground.

I kinda like podcast:group. My intent was simply to encourage unambiguous naming.

[samsethi]

I had planned to create a dedicated page of podcasts based on the producer. The podcast:author tag is confusing and would be better labelled as podcast: producer. Then when you aggregate podcasts based on the producer e.g Wondery they would be on a dedicated page. I agree calling it would be confusing. But I do agree that import/export to this group via OPML would be a good idea.

[theDanielJLewis]

I like "group" or "family."

We just need to ensure this wouldn't be confused with something like <podcast:recommended> as a way to merely indicate similar or recommended podcasts. Instead, it needs to indicate podcasts in the same "family," as if it's a network.

[ryan-lp]

This discussion reminds me of the difference between normalisation and denormalisation in database design.

Whichever way we design it, there is going to be some duplication of redundant data, but I think the goal should be to reduce the maintenance burden. If a new file is created to give a list of feeds by the same author (which in any podcast directory could have been queried anyway from the list of feeds that share the same author tag), it represents an additional maintenance burden, whether that be for the podcast creator or the podcast host who now needs to write additional software to handle the authoring of a new type of file.

Examples of directories that show you a catalogue of works by the same author, without the additional maintenance of a separate catalogue file:

• Apple's podcast directory
• Google's Play Store directory
• Apple's App Store
• Etc. etc.
• (If you could find an exception to this practice, it would be the exception rather than the norm.)

So I would be in favour of just querying based on the shared author key, either the existing itunes:author key, or the newly proposed podcast:author key: #453

[theDanielJLewis]

Or the <podcast:person> tag.

[kevinjbae]

I just listened to the last episode of Podcasting 2.0 and read through this thread. It seems it's agreed channel is a bad name for the tag. It's limited and sounds too much like changing frequencies.

In describing what the tag is and what it should do, a few used "collection" and "catalog" in their description. One of those two should be the name of the tag as they are better descriptors. A musician can provide a link to their catalog or collection of albums. A company producing multiple podcasts can show their catalog or collection of podcasts under their umbrella.

[bryanmoffett]

From a publisher POV, it would be very helpful to have a tag that allowed for publisher control of listing their catalog/collection. I’m also assuming this would allow co-productions to be listed under separate catalogs by separate publishers? Which would be important, I think, to publishers who collaborate on shows. But that also raises the potential for bad actors to claim a podcast made by someone else as part of their catalog, which is something publishers would have to watch for.

[ryan-lp]

But that also raises the potential for bad actors to claim a podcast made by someone else as part of their catalog, which is something publishers would have to watch for.

If we do what Apple and Google do, then the catalogue is automatically generated by querying the list of podcasts that have the same owner identification. That approach works because that same owner identification is also used for authentication.

[theDanielJLewis]

Thinking through this a bit more, using a large network as an example, I think it makes more sense for the tag to link to an external file. This would allow a large network to update the list of their podcasts by updating a single file, instead of updating all their RSS feeds whenever they add or remove a show on their network.

[ryan-lp]

But you have at least 3 different approaches to compare, not just the 2 you are considering. And the very one that you're not considering is the one that actually performs best on your own criterion.

• Approach A. Each feed in the catalogue embeds a duplicate list of all podcast guids in the catalogue.
• Approach B. Each feed in the catalogue links to a separate file which lists all podcast guids in the catalogue.
• Approach C. Each feed has an owner tag, and you get the catalogue for free by using it as a search key.

Your basis for comparison was to look at the administrative burden of updating files which is reasonable. But let's compare all 3 approaches.

Adding a new podcast to the catalogue

• Approach A has to update the list of podcasts N times (for a catalogue size of N)
• Approach B has to update the list of podcasts only once
• Approach C doesn't need any extra step

Winner: C.

But there are other scenarios to consider too.

Moving hosts

• Approach A doesn't require any change.
• Approach B requires that you update the link in every feed because the old URL was invalidated.
• Approach C doesn't require any change.

Winners: C and A.

Changing ownership

• Approach A must update the owner tag, and edit the catalogue in every feed
• Approach B must update the owner tag, and edit the catalogue in just one external file
• Approach C must update the owner tag

Winner: C

Be all means someone could propose an additional file to store additional publisher/owner metadata that goes beyond what is found in the owner tag, but nobody is proposing that. It seems the reason you want this extra file is in order to store a list that in fact we are already capable of producing on-the-fly, rendering that file unnecessary.