Seasons and Series
farski opened this issue · comments
This has serious implication in terms of how a client would present a show
Looks like schema.org is saying Episode can belong to either Season or Series http://schema.org/Episode but this CreativeWork > Podcast > PodcastEpisode proposal doesn't accommodate for that hierarchy schemaorg/schemaorg#373
In addition to seasons and series, as containers for episodes, there is also something like a connected theme or arc which is not really a season or series. e.g. the Planet Money 5 episode oil story this summer.
seems related to #8 Playback order
So what are the next steps on this one? I think this is one of the bigger/more visible changes we could make if we can find a workable approach.
How realistic is the approach of using PodcastEpisode - schemaorg/schemaorg#373 ? Seems that's more of a pipe dream than something lots of people are likely to pick up/adopt anytime soon?
If so, is there a simpler, optional approach that we could more easily layer on top of what's already being used? What are the simplest proposals we could do?
A new tag within the tag to include optional season-related info? Are there other alternatives?
As I suggested in #11, I think we should start with a simple proposal for this one, as this is pretty commonly used now in a lot of podcasts.
Questions:
- Should we just define this as a tag on item (like a tag), and treat season as just a string? (This has the benefit of being simple but maybe short-sighted)
- Could we define a season as its own object with its own name and description? More robust, but a lot more complex.
Thoughts?
My preference would be to have a channel level tag with guid references to episodes listed. This allows us to have general named collections, to which episodes may belong to several, and allows ordering.
The discussion of the Podcast/PodcastEpisode issue (#373) has yielded a more simplified approach, way more doable, check this exact comment: schemaorg/schemaorg#373 (comment)
Even followed by some "+1's", and being tagged with "needs review", nothing had changed for a while, I didn't find a contributing guide, I don't know if I just need to send a PR or do some steps before.
@Racum can you explain what this has to do with adding information about which season an episode of a podcast is part of to RSS feeds? I'm probably missing it.
@Racum re-reading, it sounds like the recommendation for the schema.org microformats is to explicitly exclude that possibility.
I think that's the context in which @sandikbarr brought this up, because we actually think it would be great to (optionally) provide this data within RSS feeds.
Well... there is already a standard Thing > CreativeWork > Season type, it's just a matter of add a property season of that type on the PodcastEpisode proposal.
Add this to the schemaorg issue! ...your idea, your credit! 👍
@Racum @chrisrhoden
(Apologizing in advance as I'm about to ask a general question, though this thread isn't about the schema.org microformats specifically)
What is the status of the schema.org microformats? The proposal you linked to about PodcastEpisode, and the other one for https://schema.org/CreativeWorkSeason - are these:
- used anywhere actively right now?
- used in any podcast RSS feeds that you know of?
- can these be adapted as namespaces into existing RSS podcast feeds as referenced in #11? are there any live examples if so?
I'd like more context to understand:
- How do I take an existing RSS feed like http://thebrightsessions.libsyn.com/rss (if I owned it), add the definition of some seasons and assign episodes to these seasons?
- Can we (syndicated-media group) pick up the proposals provided by https://schema.org/CreativeWorkSeason and include in our own namespace once we define it?
- How realistic/supported are the schema.org proposals are in general by real users of RSS?
Thanks
I like @chrisrhoden's point about having a way to put a single episode in multiple ordered groupings (lists, if you will). This also satisfies the need for season, mini-series, themes, or multi-part episodes like @azpeters mentioned.
Just adding a <season> tag satisfies that one very specific need, not this more general case.
I can see two ways I might implement it -
- as @chrisrhoden suggests, all in the channel by defining lists of guids per grouping. This has the benefit of being able to specify order, but I also am not sure how often a season or other grouping has a different order, so it may not be a pivotal advantage. This solution is basically creating an index, and is a tried and true way to access an ordered subset of a larger collection - something like this terrible xml example:
<channel>
<sm:collection name="Season 1">
<sm:collection-item>some-lucky-episode-guid</sm:collection-item>
<sm:collection-item>some-other-episode-guid</sm:collection-item>
</sm:collection>
<sm:collection name="Best of The Year">
<sm:collection-item>some-other-episode-guid</sm:collection-item>
</sm:collection>
<item>
<guid>some-lucky-episode-guid</guid>
</item>
<item>
<guid>some-other-episode-guid</guid>
</item>
</channel>
or
- define a collection (e.g. season) in the channel, and then an episode can reference the collections to which it belongs. This could optionally define a new order via an additional attribute or child element:
<channel>
<sm:collection name="Season 1">season-one-has-a-guid</sm:collection>
<sm:collection name="Best of The Year">best-of-the-year-guid</sm:collection>
<item>
<guid>some-lucky-episode-guid</guid>
<sm:collection-item>season-one-has-a-guid</sm:collection-item>
</item>
<item>
<guid>some-other-episode-guid</guid>
<sm:collection-item position="1">best-of-the-year-guid</sm:collection-item>
<sm:collection-item>season-one-has-a-guid</sm:collection-item>
</item>
</channel>
For (1), you have to parse all the collections in the channel to know what collections an episode is in, but you can immediately tell what episodes belong to a single collection. Adding an episode to a collection only means editing the collection in the channel level, not the episode.
For (2), you can see what collections an episode belongs to, but you still have to look those up in the channel level to have their name or additional attributes. Adding a new episode to a channel only requires changing the episode, unless there is re-ordering, then it requires updating all the re-ordered episodes.
Seems like (1) would be the easiest to manage and maintain, given the ease of re-ordering.
I probably prefer it.
Why not simplify this and think in terms of how podcasters separating seasons today by creating separate feeds? At that point you just need to define a set of tags at the channel level that lists the seasons/series' feeds.
If you do this new tag in a more generic fashion, it can be used to serve a few purposes. For example, providing multiple formats (audio mp3, audio ogg, video mp4, video mp4 HD), providing archives by other means such as by year or span of years, and also solve the feed pagination problem.
<namespace:syndication>
<namespace:syndication-set title="Season 3">
<namespace:feed url="..." title="mp3 Audio" primary="yes" />
<namespace:feed url="..." title="m4a Audio with chapters" self="true" />
<namespace:feed url="..." title="mp3 Video in HD" />
</namespace:syndication-set>
<namespace:syndication-set title="Season 2">
<namespace:feed url="..." title="m4a Audio with chapters" />
<namespace:feed url="..." title="mp3 Audio" />
<namespace:feed url="..." title="mp3 Video in HD" />
</namespace:syndication-set>
...
</namespace:syndication>
or
<namespace:syndication>
<namespace:syndication-set title="My Show">
<namespace:feed url="..." title="Latest Episodes" self="true" />
<namespace:feed url="..." title="Episodes 301-600" />
<namespace:feed url="..." title="Episodes 1-300" />
</namespace:syndication-set>
</namespace:syndication>
or
<namespace:syndication>
<namespace:syndication-set title="2016 Series">
<namespace:feed url="..." title="General Show 2016" self="true" />
<namespace:feed url="..." title="CES 2016 coverage" />
<namespace:feed url="..." title="Live from Las Vegas, 2016" />
...
</namespace:syndication-set>
<namespace:syndication-set title="2015 Series">
<namespace:feed url="..." title="General Show 2015" />
<namespace:feed url="..." title="CES 2015 coverage" />
<namespace:feed url="..." title="Live from New York City, 2015" />
...
</namespace:syndication-set>
...
</namespace:syndication>
The application would then display each set in the order they are presented with their options. The self=true would only happen once so you can indicate that the current feed is that feed in the list. A tag to set which feed is the "default" or "primary" is a good idea as well in case a search engine or feed pulling system looks at the list in any random feed wants to know which it should start with.
This list of syndication sets can then be used for multi-format, archived episodes by year or date ranges, or for series/seasons.
@cio-blubrry thats basically an OPML file, if sm goes with separate feeds I don't think we should reinvent OPML.
@Cj-Malone you are right! Perhaps all we need to do is link to an opml file which includes a new namespace that allows for setting one of the feed items as the primary feed.
I am not sure I love the idea of making producers support multiple feeds in order to have seasons, that also doesn't handle the cases where we want to have even smaller collections that may be just an episode or two.
@kookster producers shouldn't be making the feeds, or have to know anything about the spec, the CMS should be doing this transparently. This spec should be about the best technical solution.
That being said, I currently prefer you're second idea. It keeps item source of the important data, and fits with how I'd define a database. And @cio-blubrry's idea / OPML would provide confusion with unsupporting clients.
@Cj-Malone I didn't mean producers would have to literally support making different feeds, but more imagining as a publisher supporting them, and also how clients of these feeds now have follow all these feeds to get the data about the show and episodes - and maybe confusion from there being many different urls for the same show.
Not that this can't be done, just thinking about what trade-offs to creating multiple feeds per show, and I think this would limit those whose feeds are generated in existing publishing tools - much easier to add tags to a WordPress template than multiple endpoints (yes, a practical concern - I am also interested in a solid technical choice, but considering adoption as well).
Jumping in to say that publishers seem to be moving in the opposite direction - that is, including episodes from multiple programs in a single feed (see The Message / Life After). It's unlikely that they will be comfortable with doing something that will net them a loss of subscribers moving from one season to the next for legacy platforms.
Given that one of our core goals is to maintain a great experience on the existing platforms that may or may not choose to adopt our recommendations, I think anything that hides episodes from less flexible platforms (as with e.g. paged feeds) is going to be a tough pill to swallow.
I don't agree with this move on the part of publishers, but I certainly understand how they would come to the conclusion that it's the best way for them to handle things given the situation today.
If you want to offer pagination, you will have multiple feeds in the form of page 2, page 3, etc... If you want to provide the ability to view an archive that displays different episodes than what you see currently, you would have different feeds.
If you are not concerned about what is viewed/not viewed, you can currently put all your seasons in one feed in the order you want them in with each episode title indicating which episode goes to which season. In this case though you are limited to 300 episodes before you run into the iTunes limit of items in the feed, at which case we are now visiting the pagination problem (multiple feeds).
Today podcasters are using categories on their WordPress sites to organize episodes by year or year range and offering those years as archived feeds. There are other variations but that method seems to be the most popular. To expand on what @kookster said, today you can tag your episodes with a year and create a podcast feed from that tag in PowerPress, it's a few clicks and you're done. The trick though is allowing the podcaster to organize the feeds they created into an opml format that indicates which is the primary podcast (perhaps it's always the top most feed in the list) and which are the archives.
My primary thought is that the characteristics between a series and season is pretty much identical to browsing a podcasts's archives or pagination to older episodes. Series and seasons though seem to indicate that the content producer has complete control of what happens and where. Otherwise it is just a different label to the same problem and could be solved with the same solution.
The syndication platform on the other hand could easily mask all of this is taking place and simply provide menu options to select season, series or to provide a global setting to provide episode 301+ as archive feeds. To the end user this does not have to be difficult at all.
@chrisrhoden per your last reply, usually you never change your main podcast feed, but instead classify your older episodes into a new archive feed.
Again though the magic number is 300. You can put all the series/seasons you want into 300 episodes then there should not be an issue today.
Overcoming this 300+ episode problem may not reap in huge benefits. Statistics wise we do not see meaningful consumption for archives of episodes vs new releases, except in some small cases at which the content is limited to 8-16 episodes a season. For example, it is impractical to assume that someone will subscribe today and then proceed to listen to all 300+ 30 minute episodes for a given show. On the other hand, someone may spend the time to browse through the archive/seasons/series to find a particular episode and play one that stands out to them. In that case the app should be providing some sort of pagination or navigable organization by series, season, or some other factor. This is where this discussion fits in and may provide an opportunity to allow the content producer to decide when this happens and how.
@cio-blubrry is your expectation that if the same episode appears in multiple feeds it would have the same guid? Is there some way to indicate a parent namespace (right now guids are only addressable for a given feed URL, so reconciling this may not be trivial)
My preference would be to have the sequence / series / collection data added directly to the RSS feed but I understand preferring to match behaviors that already exist. I hesitate to ascribe current behaviors to what producers / publishers would ideally prefer, however.
This is getting a bit off topic, but we do have new listeners going back and listening to many if not all the archive, depending on the show. Some like 99% Invisible or The Moth have largely 'evergreen' episodes, and limited dated material and we've seen a significant numbers of fans binging through archives.
It sounds like you're advocating for all shows to move to have to use OPML for their show, and define a kind of API for their feed via OPML for how to navigate, filter and sort through their episodes via different feed urls. I'm not sure that using RSS and OPML to approximate a hypermedia API should be necessary for implementing collections of episodes such as for seasons or multi-part episodes. Seems like if we want to have an API instead of a feed, there are better ways that RSS to do this (like HAL which the new WP API will use).
@chrisrhoden any App that I would be involved with would never use the same guid in two different feeds at the same time. iTunes uses the GUID for reviews, it would really mess things up there if you used the same GUID for 2 or more shows.
On the flip side, imagine an episode you released back in 2007 that was in your primary feed dropped off because it is 301+ episodes ago. But that same guid episode appear now in your archive feed, that is a direct benefit as it would have the same guid thus have the same comments from when it was in your primary feed. This would require Apple to map your current feed to this archive feed, but its completely doable.
For the sake of simplifying our discussion, lets remove the idea of seasons, archives and series and view this problem as a pagination problem.
If you have 600 episodes, and we can only put 300 in any given feed, somehow you have to include these episodes in a 2nd feed that the first feed links to either directly (namespace tags in the feed) or indirectly (reference an opml feed). The only other solution is to propose an API protocol @ookster just mentioned that allows the app to seek more episodes than what is available in the feed. If the API returns results in RSS2 format, then you're just coming up with a new name for an RSS feed. If the API does not return results in RSS2 format, you are now putting an expectation for the applications to learn yet another format in lets say JSON, which would be great, but is asking a lot.
@cio-blubrry I don't know if we're talking about the same thing here - it seems like you may be saying the same thing as me in a different way. GUIDs as defined in the RSS spec are only namespaced to the feed in which they are found. If you treat RSS GUIDs as truly globally unique you will encounter collisions. Apps do not do this (or if they do, they quickly learn of their mistake and change it). So simply using the same GUID in the new feed will not give the app any way to tie the episodes together. That's what I was getting at with the first paragraph of my response when I referenced a parent namespace for the GUIDs.
Changing the conversation to be about pagination only simplifies things if we agree that episode collections should be handled in the same way that pagination is. I don't. I think I largely agree that pagination should work the way you describe (which is to say, using the Podlove spec, which notably already has support in some clients), but I don't agree that episode collections is the same problem.
The most important thing to remember about pagination (and the reason I brought it up in the first place, because your proposal was essentially to use the same system that is already in place for pagination to represent collections) is that it is not something we can assume support for. To my mind, that means that no episode can appear exclusively in a feed that is not the main feed, or you lose any audience that uses an app which hasn't implemented whatever spec we come up with.
Given that, if we decide it's still worth forging ahead with multiple feeds (again, I don't think I agree that that's a good solution to the problem at hand), then you will need to come up with a way to link the episodes across feeds so that something can appear in both the main feed and in one of the collections (or, indeed, in more than one collection, as the other proposals permit).
I proposed viewing them as the same problem rather than asking podcast apps to support 3 different functions. Sorry I come from a development background and I'm always trying to narrow scope. I was just trying to point the goals of this and 2 other objectives into the path of least resistance so they may actually come to fruition.
We're saying the same thing, but I am pointing out that iTunes would need to know that the guid can carry over from your primary feed to your archive feed, or your primary feed to your pagination feed, etc... and by doing so would be a benefit to the podcaster in that they could have episode 350 still maintain the same reviews in iTunes. This is another reason why I am viewing this as the same problem, both archives, pagination, series, and seasons.
Again, I don't mean to sound like a broken record but a need to have something special for series or seasons is only if you have more than 300 episodes. If you have 2 seasons and each season you have 20 episodes, just put them all in the same feed, tweak the titles and we don't have to have this conversation. This is why I keep emphasizing that the problem is still the same, you somehow need to allow for going beyond the 300 episode limit. By proposing a standard that is universal it gives the producers to control exactly that experience (which may be in an organized opml feed or may be via some API).
Proposing an API that has a new protocol (assuming JSON) would be great in a perfect world but would be asking a lot from developers who already have infrastructure setup to deal with RSS feeds. If you create an API that simply returns the results in RSS format, then we're saying the same thing but I am not hiding it within the term of an API.
The natural path of lease resistance knowing the above is to utilize what we already have, RSS feeds.
@cio-blubrry Thanks for clarifying. I won't restate the thing that we have both said twice now :)
I don't mean to sound like a broken record but a need to have something special for series or seasons is only if you have more than 300 episodes. If you have 2 seasons and each season you have 20 episodes, just put them all in the same feed, tweak the titles and we don't have to have this conversation.
So your recommendation in this case is to keep the series / collection data in the titles. I don't think that achieves the goals set forth in this ticket. I'm also in engineering, and I think it sounds terrifying to safely implement the title metadata extraction necessary to e.g. do a season dropdown in an app.
Proposing an API that has a new protocol (assuming JSON)
I think everyone is advocating for extending RSS, in this ticket and nearly all of the other tickets that have to do with feed metadata.
If I'm mischaracterizing your position, then it feels like we're just talking past one-another, and I really want to understand better why.
I'd be curious to hear from a publisher that is interested in adding series / collection data to their feeds so that they can weigh in on what kinds of interactions they're looking to facilitate.
I need to catch up on a lot of this thread, but I would be kind of shocked if we came up with a solution for seasons, and it didn't cover Serial (in a way that makes it easy for an app to handle season 1 and season 2 separately in some way.).
Also I feel a bit uncomfortable trying to design around an arbitrary limitation that iTunes imposes on how it displays things. The 300 episode limit is not a symptom of the feed or RSS or anything we're really talking about here, and has no real direct relationship to seasons.
@chrisrhoden I just joined the group, I am sorry if I come off "past one-another". I believe I am directly answering your thoughts so please do not think I am looking past what you are saying. I felt compelled to repeat what I am trying to say since you did not understand what I meant by the guid following through with the program beyond just the first feed as a benefit to the podcaster. I agree with you guid is unique to the feed otherwise.
As far as seasons/series are concerned "today" my answer is yes. If you want someone to have the same experience on all podcast applications then I would encourage you to utilize the titles to appropriately identify each series / season. If you are not aware, this is what Serial is doing today: https://itunes.apple.com/us/podcast/serial/id917918570?mt=2
As for the goals of this ticket, I am just trying to contribute a solution that may get widespread adoption and a the same time solve other problems. It does no good if Apple finds it too complicated to implement and creates more problems than it solves. If your goal is not to get Apple to adopt these standards then I think we're wasting our time.
Lets consider the situation where Serial has 301 episodes. How does Serial combine the tags proposed in #issuecomment-274173820 and overcome the challenge of pagination when combined with 300 <sm:collection-item> lines but the 301'th not being viewed until the user navigates further.
@farski feed item limits need to exist and I applaud Apple with setting some standard. I am actually surprised they did not set the limit to 100 like they do with other parts of their API. If your opinion is no app should have a limit of items in a feed, then great lets take the conversation in that direction as that solves the pagination problem but then this creates a new problem: data is being syndicated multiple times a day that is, for the most part, not useful for the greater masses.
Item limit and feed size in bytes is a real problem at the podcast directory and podcast app perspective. If you wanted to win the approval of app and directory developers you would also agree on a limit of 100 or 300 or something realistic. Going beyond 300 is not a realistic expectation.
I often reference TiVo (or a generic DVR) when demonstrating how podcasting could work. When you view a show and navigate to the episodes on a TiVo you see the latest season listed with the seasons merely labeled at the top. You have to navigate to the seasons column, select a specific season, then it proceeds to load the information for that season. When you view that via an API level, it is 1 API call to get the primary source for the content, which then has tags to indicate there are additional api calls to get additional seasons. You can achieve the same thing in a primary RSS feed that then links to additional feeds for additional navigational purposes, not just seasons but what ever the creator defines (if you take my suggestion and make this fit not just for seasons but for propagation and archives). This approach means developers do not have to code anything new for parsing feeds and the linking of the additional seasons is relational in design rather than using tags as references within the same feed.
The app developer could see the reference to other seasons and continue to load all of the season data in one view, and the best part is that the latest season could be downloaded and displayed first so the user experience is not disrupted because of a feed that has 500 items and 500 extra references to map each item to a season.
With all of this said, this is my input. Obviously if you have a better solution then please propose it but from what I have read so far the 1 feed with everything in it with season management in the tags would only be a viable solution if there is no feed item limit.
I'll try to keep my answers brief, so there's less to read through for others.
I felt compelled to repeat what I am trying to say since you did not understand what I meant by the guid following through with the program beyond just the first feed as a benefit to the podcaster.
I did understand. In fact, it's exactly what I said. Or, more accurately, I said that such a concession would be required, and there is no such mechanism today.
It does no good if Apple finds it too complicated to implement and creates more problems than it solves. If your goal is not to get Apple to adopt these standards then I think we're wasting our time.
That's where we are with paged feeds today. Apple has not implemented this, to my knowledge.
I applaud Apple with setting some standard.
For display in their store. Episodes past 300 will still appear in the Podcasts app, as far as I understand.
From what I have read so far the 1 feed with everything in it with season management in the tags would only be a viable solution if there is no feed item limit.
That's a fair criticism of the keeping it in a single file solutions proposed, linking things across multiple feeds gets messy. That said, I think there is a similar problem with the proposal you have made, and it's the same problem that you and I have both described repeatedly (though perhaps I have not expressed it clearly enough) that right now feeds are treated as islands within apps.
What do you think about just using category since seasons basically are categories?
<category domain="https://schema.syndicated.media/category-seasons">Season 1</category>
I think we should have a way of defining episodes as well, that way the titles don't have to be prefixed with "Episode x"
I see how they overlap, but I don't think this seasons issue is necessarily the same as the "> 300 problem", and would propose that be broken out into another ticket.
For example, if a season is greater than 300 (e.g. a daily show where a season is a year), then breaking it up by season doesn't solve the "> 300" problem anyway.
Likewise, many feeds are less then 300 items, representable in a single feed listing, have seasons, and I know many app creators I have talked to would like to have those seasons and episode sequences identified in a normalized, machine readable format. I don't know if Apple would use them, but they certainly support season based listings in iTunes and Apple TV, so it's not impossible.
I know many feeds like Serial add season and episode # info in titles, but I could look at 10 feeds and see 10 different ways they are formatted - it isn't enough. I don't want to spend my time creating NLP code to try and figure out the season for every misshapen title hand entered by a world full of podcasters and languages; I think we should have a way for them to put that in the feed as its own fact.
(FWIW - that's what I took to be a point of this ticket and syndicated media in general: to think about additional tags or adoption of existing tags that would allow us to normalize data that podcasters are overloading into other fields like a season or episode identifier in a title.)
Here are some quick examples of how this normalized data could be used:
First off, there are those @cio-blubrry aforementioned TiVo / Netflix / iTunes displays where you can navigate by season, often showing just the current season and allowing a user to navigate to other seasons.
That's very useful, even with just a handful of episodes per season easily listed in a single rss feed.
It doesn't necessarily imply or require multiple requests to implement that kind of UI or the feed server backing it, though that's another one way to do it.
Another example is recommendations for what to play next, or in an app that chooses to never stop playing, how to cleverly pick a next episode to play without user input.
Let's say a listener starts listening to a podcast with the most recent season, season 3 (let's assume a 12 episode season).
She goes straight to the last episode of season 3 (s3e12) - maybe she listened to the rest already, we don't know.
Assuming she finishes listening to that episode, what episode(s) of the show should an app recommend?
An app w/o seasons info could recommend she start from the beginning of the feed, or maybe the most recent episode she has not heard, so either s3e11 or s1e1 are reasonable suggestions that the app has enough info to recommend.
And that s3e11, is a fine recommendation, but if she just heard the finale, presumably it may not be the best suggestion, so maybe an app wants to do something different.
(I know we could argue about what the best behavior is (and that is up to the app), but what I'm talking about is providing enough info so an app can make suggestions knowing about the seasons and their ordering.)
For example, an app might have a heuristic to suggest the start of a different season, since she just finished this one, so it would like to show her s1e1 or s2e1. If the app doesn't know where the season boundaries are and the ordering of the episode within the season, tough luck.
I know how podcatchers are, where getting to those episodes is a matter of opening up the listing, finding an episode that starts a season, and picking it, but I want app makers to be able to go beyond that kind of hunt and peck UI, and enabled by additional data like this. I want to tell Alexa to "Play the first episode of Serial season two" and have some hope of getting what I want, and not a pallet of cereal boxes delivered to my door ;)
sorry for the long comment, started it before several others came in.
I sketched out the idea on a piece of paper using tags that link to other feeds. @Cj-Malone pointed out that is essentially an opml file, so that brings the option to either you have opml like tags within the primary RSS feed or simply link to an OPML file. This then lists all of the other feeds in a specific order (which each feed is a season, series, archive with custom label or simply labeled page 2, page 3, etc..). A label is just that, if you design this not to be specific to seasons it can be used for how ever you want to label a grouping of episodes and better yet, you as the content creator control the item limit in each feed rather than the app deciding that the limit for pagination should be 50 items.
Just as important, the podcaster/content producer makes the decision how this is organized which completely fits into the spirit of podcasting. If I want my season/paging/archive experience to be 10 items per feed then I can do that with an opml file that links to 10 feeds for my 100 episodes, and if I want to label the first feed "latest season" in the opml and the last feed "archive from 2009" then even more control to the podcaster to decide how this additional content is viewed in the app.
I think up to this point the only problem with this idea is that it involves multiple feeds.
I am not saying this is what you should do, I'm only contributing my knowledge and experience. Perhaps tomorrow someone will read this entire thread, have a utopia moment and propose the perfect solution.
@Cj-Malone I agree, that is a possible solution - not sure how <category\>s are currently used, but assuming it's reasonable in most apps, we could add a domain for seasons and do that.
It isn't expressly detailed in the spec, but I think the idea here was to put in category things like the itunes:category, but where that additional tag is one specific iTunes domain with two levels of defined categories, you could make whatever taxonomy you want.
Another thing I might consider here is that category could basically be used as tagging, with a domain that could offer some constraints or not, so arguably, you could put in any data as a category. It's basically a key value pair, so you can denormalize any data into it.
e.g. want a new teaser for the episode?
<category domain="http://teaserdomain.com">You won't believe what happens next!</category>
If a piece of information is demonstrably useful and common, I think it makes sense for it to have its own tag. I am on the fence about if there should be a specific season tag, or some more general collection with a season as a type of collection.
@Cj-Malone the category RSS tag has no limit according to RSS, so you could have a situation where the same episode appears in multiple seasons.