Move chapters and such into "deepData"

[theDanielJLewis]

I still disagree over moving the minuscule chapter data to external files for each episode. But if we're going to do that, I think we need to anticipate needs beyond chapters. For now, I'll call this "deep episode data" or "deep data."

As I understand the current consensus on chapters, there would be an additional JSON file for every episode—potentially even every alternate enclosure. But whatever the case, the chapters could be simply one section of this deep-data file, and it could support more in the future.

So if it's one file per episode, then <podcast:deepData>URL</podcast:deepData>. If it's one file per enclosure—heaven help us!—then it would seem to make sense to include the deepData URL in each alternate enclosure tag.

[daveajones]

We can target revisions of the JSON chapters format to include these things. Are you proposing that the JSON chapter format be refactored as a more general purpose rich content file, as mentioned in #55 ?

[theDanielJLewis]

Not reformatting the chapter format itself, but that chapters could be simply one section in an episode deep data file.

Aside from transcripts (which I think are best to have their own in-RSS tags), I can't think of anything else to put in the deep data right now. I still don't like it's being moved externally. But if that's what we're going to do, I think we need to make it even more forward-thinking.

[daveajones]

The hosters have expressed that it’s just too much complexity/bandwidth for in-feed, so I think we’re stuck with an external file.

I’m not sure it matters too much what we name it. The HTML list tags are used for all kinds of crazy things that have nothing to do stylistically with what anyone considers a “list”. So, I think we can call it anything and people will adapt it to their needs.

On the file format itself do you have another possible use that you can think of? We could drop in some language in the documentation giving some pointers to forward looking uses that would make it more clear that the intent is fuller rich data. I’ll try to brainstorm some stuff to since I’m all jazzed about this tag.

[theDanielJLewis]

I thought of something else that would be good to put in this deep data: in-depth show notes.

I write an article for each of my episodes. This is far better than "summary" show notes, both for usability and for SEO. But this also hugely inflates the RSS feed when it might not have to.

I think this would be a good thing to consider moving from <content:encoded> into these episodic "deep data" files. Then, the apps that read the "show notes" from deep data (if present) can benefit from a slimmer RSS feed. And for those apps that don't read the deeper data, we could encourage podcasters to write a summary that links to their full show notes.

[daveajones]

What about just <podcast:shownotes> then? Something roughly like this?

<podcast:shownotes url="[link to shownotes file]" type="text/html">

[douglaskastle]

Please consider GPS track as deepData as a possibility. I think it is a simple as another JSON file in addition to the chapter or show notes.

Discussed in more detail here #114

[theDanielJLewis]

“Content” or “notes,” IMO.

…

On Nov 15, 2020, 4:32 PM -0500, Douglas Kastle ***@***.***>, wrote: Please consider GPS track as deepData as a possibility. I think it is a simple as another JSON file in addition to the chapter or show notes. #114 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.