Proposal: <podcast:recommendations> tag

[benjaminbellamy]

Hello everyone!

I wrote a specification for a recommendation tag:
https://github.com/Podcastindex-org/podcast-namespace/blob/main/proposal-docs/recommendations/recommendations.md

The basic idea is to allow podcasters to tell what other content they recommend.
The tag contains a URL to a JSON file that contains the actual recommendations.

<podcast:recommendations url="[url to json file]" type="application/json" language="[language code]" />[Optionnal comments]</podcast:recommendations>

Any comment or feedback is welcome. I'll update the specification accordingly.

[adamc199]

I really like this idea. A reverse recommendation algo.
I would use it.

[bjoreman]

As a lover and creator of extensive show notes, this really appeals to me 😃. Coming from this angle, I feel like there should be an optional comment on each recommendation object, as I often want to add some context. ”This was the project X worked on during the time we discussed.” ”We were totally wrong when we said Y in the episode, X (the recommended page) is the actual right answer”, or ”Listener Z suggested this as additional listening, a great deep-dive on the topic we touched on.”

[daveajones]

This is a big structure. We need more eyes on this if people can take some time and look through it:

Proposal

Ben, how much of this has been put into Castopod so far?

[benjaminbellamy]

The podcast:recommendation tag has not been implemented into Castopod yet, but we plan to insert it into the next sprint.

[thebells1111]

Would this be a feed level tag, an episode level tag, or both? I can see a strong argument for both. Feed for recommendations that are constant for the podcast, but episode for links to guest podcasts, amazon link to product recommendations, or anything else mentioned in that episode. It would remove the need to clutter the description with a bunch of links.

[PofMagicfingers]

I'm wondering if it does not overlap a bit with the topics "topics" introduced in #180 and which would probably be moved to a separate file rather than tags (discussed in #184). Maybe we can merge theses ideas together ?

I guess we could make one big optional metadata file, one for the feed, and one per item as well, containing all topics, recommendations, soundbites of the podcast/episode. We could update it and change its url or hash like discussed in #184 to trigger updates in the podcast clients

[theDanielJLewis]

I noticed the proposal has an rss attribute. I suggest we use feed instead of rss in this spec and wherever possible.

[benjaminbellamy]

I created a MR to replace rss by feed.

[benjaminbellamy]

AbleKirby, cottongin and I had a fruitful talk together about the podcast:recommendation tag.
In a nutshell we added:

non-podcast feeds
the motive for the recommendation (acknowledgment, ad, similar content, audience exchange…)
As usual all comments are welcome.

Updated version (1.1) is here: https://github.com/Podcastindex-org/podcast-namespace/blob/main/proposal-docs/recommendations/recommendations.md

[daveajones]

Looks good. Will read through today.

[ablekirby]

GJ Benjamin!

I'm endorsing this tag for phase 4 because I think it's necessary to make the podcast namespace viable to use in a decentralized music back end. Sound data (mp3) is only one part of what a modern music app needs. Relational data about artists (influences, contemporaries, associated acts...) cluster them into scenes (ex: portland folk scene) is also needed to get good (or even plausible) UX.

Basically, If we decentralize the sound data then the metadata must be decentralized with it, and that is what this proposal does.

[daveajones]

I’ll be writing up phase 4 at the end of this month. I’m down with this. I’ll put it in the readme and we can hammer it out.

[benjaminbellamy]

I just added some final corrections:
https://github.com/benjaminbellamy/podcast-namespace/blob/patch-13/proposal-docs/recommendations/recommendations.md

[daveajones]

Merged.

[jamescridland]

The proposal at #447 seems more elegant: just a comma-separated list of GUIDs. I don't quite understand the benefit of an external JSON file here.

[theDanielJLewis]

I agree that podcast GUIDs would be better. However, I'm thinking having multiple instances of this would allow for more flexibility, like being able to say something about the recommendation. For example:

<podcast:recommendation label="My clean-comedy podcast">guid…</podcast:recommendation>
<podcast:recommendation label="Hear me regularly on Podcasters' Roundtable" website="https://podcastersroundtable.com">guid…</podcast:recommendation>

[benjaminbellamy]

The proposal at #447 seems more elegant: just a comma-separated list of GUIDs. I don't quite understand the benefit of an external JSON file here.

• Having an external file allows the use of external recommendation service providers
• It's easier when you want to update recommendations (for instance when a new episode is recommended on an old one, you would not have to update the rss for the old one, nor would you have to parse it again. On the other hand, you can just launch a HEAD http query on the external json to see if it was updated)

[adamc199]

• Having an external file allows the use of external recommendation service providers
• It's easier when you want to update recommendations (for instance when a new episode is recommended on an old one, you would not have to update the rss for the old one, nor would you have to parse it again. On the other hand, you can just launch a HEAD http query on the external json to see if it was updated)

I agree with external file being important for external services or audience produced recommendations.

Just as important as external chapters and transcripts.

[theDanielJLewis]

I can see that, too. If recommending on the episode level, this would be perfect to include in the episode metadata file (item incorrectly called a “chapters file”).

But speaking of chapters, would you still think this best to be an episode-level option instead of being inside richer chapters (#400)?