datamythology
commented
3 years ago I am also interested in 3rd party data that connects to a feed. However, I assumed that would be something you or I or they would host themselves. You'd download/get access to the main podcast newsfeed so that you'd have the correct podcastID to point to, but you would host the "child" database yourself. Reviews, Ratings, etc.
Example would be how PodVerse hosts clips. https://podverse.fm/
While I like the idea of your dynamic namespace idea, wouldn't Dave ALSO have to somehow dynamically host this metadata you're talking about? Which doesn't seem possible. Perhaps I'm reading your idea wrong -- would love to hear more.
Update: Looks like Episode #06 talks about the namespaces that ARE being added.
perelin
To define 3rd party metadata: any data not created by a podcast owner (through rss feed) or by podcastindex itself (craw dates, update dates) that has information on the main data, namely the podcast feed and it's episodes.
@daveajones I'm sure you have had ideas and working on how to handle incoming metadata like:
And perhaps you're already heading in a different direction. But what were your thoughts about just an extra key/value table with namespaces? So a unique index could be namespace:feedId:key. You could by request connect API keys to a (single) namespace to give them write access. If any party needs access to multiple namespaces, they can use multiple API keys.
I'm not too sure though how to present the data in the API in a efficient way. It seems a good idea not to show any of this data by default, but only if a connecting service is aware that a certain namespace exists.
For popular searches and request on the metadata I'm sure @daveajones will whip up custom endpoints in no time.
My main concert, could the database handle it this way? I think it could provide a lot of flexibility.