search

Podcastindex-org / podcast-namespace

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

Proposal: <podcast:recommendations> tag #205

Open benjaminbellamy opened 3 years ago

benjaminbellamy commented 3 years ago

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 commented 3 years ago

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

bjoreman commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

thebells1111 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

benjaminbellamy commented 3 years ago

I created a MR to replace rss by feed.

benjaminbellamy commented 3 years ago

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 commented 3 years ago

Looks good. Will read through today.

ablekirby commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

daveajones commented 3 years ago

Merged.

jamescridland commented 1 year ago

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

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

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.

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

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

X-Cli commented 1 month ago

Just a quick note that I appreciate that tag (syntax, structure, using an external JSON file, all of it) and I added support for it in my feed generator (using Hugo). I would love to see it more widely adopted.

My use case is that I record episodes about information security and I want to provide links and sources for my listeners to learn more about the topics I discuss. Show notes are unstructured, timecodes are not well integrated, and max length is an issue. My average blog post contains 30 to 50 links. My episodes should contain about the same amount of links.