<podcast:categories> - a suggestion for a different approach

[jamescridland]

I'm seeing some people asking for "tabletop games" as a category, and doubtless we're likely to have more arguments about categories in the future.

Could I humbly suggest we're doing this all wrong?

We shouldn't be setting categories. That's not our job. We should be allowing podcasters to set them for us.

Here's an alternative:

podcast:categories

Specification:

<podcast:categories>
   (a comma separated list of freeform categories ...
   ... most important first ...
   ... to a maximum of 128 characters)
</podcast:categories>

Fallback: If this field is empty or not present, the podcast client may use the three categories in the iTunes tag as default values.

Example:

<podcast:categories>
   daily news,business news,podcasting news,aloof british accents,snarky remarks
</podcast:categories>

This is a free-form list of categories. It's expressed as tags, like Flickr does photo tagging, or Twitter does hashtagging, or Medium does with subjects, or Unsplash does in searching.

It has a maximum of 128 characters, just like Medium has a maximum of five subjects per post, or Twitter has a limited space. This cuts down on spamming, and makes it impossible to be in every bloody category on the planet.

It also suggests that the 'most important' category is first in the list. This might be used by search algorithms to give more weight, in my example, to "daily news" than to "snarky remarks".

It means that if you want a category called cooking with cheese, then you can go right ahead and make one. If enough other people like the idea of the category, then it'll be a popular category.

Categories can also be in the native language of the podcast, too. A search for saucissons will find me French-language podcasts about sausages. (You could use that in conjunction with the lang tag, too).

These categories, more properly called 'tags', are well-understood by many creators on the internet, and show clear blue water between Apple's intransigent categories where you need to run a campaign to get them to add just one of them, and where we want to be, which is a podcast service to everyone.

These are self-policing, fluid and reactive. Want a BLM category? Go for it. Want a Trump category? Be my guest. Want a category for impeachment? For snowstorm? For power outages? It's a super-simple way to tie podcasts together on a common subject.

And, most importantly, "if you don't support them, Mr Podcaster, then we'll just use your iTunes categories as your categories here, too". Simple and easy, and already has 100% support since everyone has set up to three categories as a starting point.

[swschilke]

I like this idea. Some academic publisher work the same way. They have their fixed, controlled vocabulary, to put order into chaos ;-) done by their reference librarians, but allow the author to add a low number of own keywords (creativity galore ;-).
So we would not be off the tracks regarding the Pomme standard.

[Majester]

Using tabletop role-playing games as an example, this opens up the ability to dynamically add genre tabs like osr or dreamsword or actual play or interviews etc.

But it does also open up the problem of alternate spellings diluting finding content. In our example; ttrpg, tabletop rpg, tabletop role-playing games, table-top roleplaying games and table-top roleplaying games are all valid spellings and get their own tags. There needs to be an easy way to check existing popular categories to prevent proliferation of multiple spellings.

[swschilke]

I am always a fan of controlled vocabularies. Doesn't fit the idea of @jamescridland ,but the itunes categories would be fixed (at least).

[daveajones]

This feels more like topics than categories. Maybe we abandon categories and go with topics?

My first thought was also the mis-spellings and variants issue. I wonder if we could provide a “master list” of current topics that is searchable by podcast creators from host UI’s to make their choices less likely to be “wrong” in that way.

I’m sure that various aggregators and directories would be willing to contribute to such a list in an automated fashion. I know we would, and I’m sure you would too @jamescridland . We could cook up some code to coalesce the various input lists coming from the different contributors.

Just brainstorming here.

[theDanielJLewis]

I think having a "master list" would be good, and maybe it's something that should be maintained in a repo devs could pull for easily updating to new additions.

The app could read these tags—or whatever we call them—and properly organize into any pre-supported categories, or they could optionally support one of their own choosing.

So, for example, our master list could contain the full representation of the consensus of necessary tags, while app developers could use unofficial categories to raise awareness. (After all, categories in Apple Podcasts are not about raising awareness, but about organizing content.) So the app developer could, if they want, make an easy "US Election 2024" category to automatically highlight such podcasts, but the organizational category would fall back to "politics" or "government."

We would need a repo not only for developers, but also for podcasters. It'd be great if Podcast Index could syndicate that, like "Here are popular unofficial tags." This could naturally help reduce the alternate spellings or formats. And developers could easily get a glimpse of what they might want to support of their own initiative, and Podcast Index could also see the actual demand—by usage—for categories to be added to the master list.

[agates]

Would this accept characters like emoji? Standard UTF-8?

Is this a valid topic?

🚁🏞️📱🤛🏼🦁🤚🏾👨🏻‍🤝‍👨🏿🌌🈚🤼🏾‍♀️🌹🇲🇭⚒️🦊🏴󠁧󠁢󠁥󠁮󠁧󠁿🇸🇾🦞🧚‍♂️👷🏼‍♀️👳🏼‍♀️🇮🇸🖊️🤟🏿👨🏽‍🍳👩🏾‍❤️‍💋‍👨🏾🕵️‍♂️🧑🏿‍🦳🏃🏿‍♀️🆕🇬🇧❌🧑‍🔬😡🐂👨🏿‍🎓🧑🏻‍⚕️🐩🤹🏽☚🏿👨🏾‍🤝‍👨🏽🙋🏼‍♂️🀊👳🏾‍♂️🧠🤟🏻🎏👨🏾‍❤️‍💋‍👩🟫👨‍⚕️🦗👨🏽‍🦰🇲🇶🤾🏾🥍🤦🏾‍♂️🕵🏼‍♀️🧗‍♀️🇳🇦🧑‍🌾🇧🇭🤹‍♀️🥚🧑🏾‍⚕️🥿🥑🇺🇾👩‍👨‍👧👐📪⛹🏽🤵🏻‍♀️🏦🎍☔💈👊🏼🌁🧑🏻‍✈️🇮🇩🗝️🔥🤵🏾‍♀️🔉🧑🏾‍🦽🕵️🧏🏾🗳️🧝🏾‍♀️☜🏾👨🏻‍🔧👩🏿‍💼🧑‍🤝‍🧑🧑🏽‍🚒🇳🇮🏭💁🏿🧓🏿🇹🇻🕶️💇‍♀️🙏👧🏻🐮💏🏿🏋🏼‍♂️⏭️👷🏿‍♂️🧙👩‍👩‍👧‍👶👱🏾‍♀️👨🏽‍❤️‍👨🏿🀕👩🏻‍❤️‍👨🏿🧍🏻🇱🇸😑👨🏼‍⚕️🎊📛👩🏾‍🏫💿🦋🚶🏾‍♀️🧍🏼👯👋🏾👠🥑🆕🧗‍♀️

[PofMagicfingers]

Just adding my two cents here, but we also have the standard rss category tag for free form topics : https://validator.w3.org/feed/docs/rss2.html#ltcategorygtSubelementOfLtitemgt

[jamescridland]

we also have the standard rss category tag

Great point. Why not use this?

controlled vocabularies

I'm a fan of those too. In this case, vocabularies like this appear to self-control themselves quite well. If you get the UX right, a podcaster would choose the categories that are most popular. It's certainly how I set categories for my Medium posts. ("Podcasts or Podcasting? One has 22,000 followers, one only 5,000. I'll choose the more popular.")

No reason why someone couldn't provide a list of synonyms or misspellings to assist this, but that's something that would need to be humanly curated.

[jamescridland]

PS: @agates I guess anything accepts emojis. Remember: the point of this is to make sure you appear in categories which people are using to discover new shows. Emojis are unlikely to be the right choice.

[agates]

@jamescridland I understand that, but developers should be prepared to handle cases like that for UX.

[thebells1111]

I would also like to see this where search results can result in long tail hits, such as 'Science' 'History' 'Octopus' would result in the one podcast about the History of Octopus Science. This might also be good for something on the item level, so an episode about the History of Octopus Science would show up in a search.

[ablekirby]

I’ve been thinking on this since dinner. Here’s what I’ve come up with. Sorry if I'm rambling, it's been a day :)

From a computer science perspective, free-form categories are more satisfying because they don't tie the namespace to any current trends or culture. With no boundaries, new categories can wax and wane with public interest and use. In theory, anyway.

In practice, categories of unlimited form and detail are a big mess. At the logical extreme, the categories of a podcast might be so niche that the tag effectively just another <podcast:guid>. Anyway, if you want to use a free-form list, you don’t need a new tag to do it. The vanilla <category> element already provides that... Sort of. In my quick survey, the <category> element was uncommon in podcast feeds, and when it does appear, it’s usually a mirror of the ubiquitous <itunes:category> element. Yes, the free-form list tag, as far as I can tell, is only used to echo the Apple-curated menu of categories.

So why is this the <itunes:category> element the de-facto standard in podcast tagging instead of <category>? I don’t think this is because <category> was forgotten, or some slick move by Apple tricked people into not using it. It’s because there’s a natural appeal to limited choice. It’s like how people prefer to order from a menu. In other words, we know that the nature of <itunes:category> is to pigeonhole podcasts. It’s successful because on some level, a fixed vocabulary is just necessary to make sense of things.

That said, the itunes categories aren’t actually static. They’ve had to edit the menu to keep up with the times (most recently in 2019) and it’s doubtless that given enough time, Apple will have to edit them again. See: https://podnews.net/update/podcast-categories-changed for a refresher. We should not be relying on a single authority to tell us what is important, or what phrasing is cannon, or what terms we describe ourselves by.

Still, I think we can learn something from Apple’s category design: Categories aren’t flat lists, they are hierarchies. Each is rooted by an enduring category (fiction, health, kids) and branches to more timely ones (drama, nutrition, stories for kids). Each higher branch is just finer specificity. If the podcaster wanted, they could extend the “health -> nutrition” chain to “health -> nutrition -> keto diet”. This makes each category into a prioritized list, not unlike how font-families work.

As a reminder font families define a hierarchy of fall-backs to common fonts when the specialized one isn’t available. For example { font-family: Helvetica, Arial, sans-serif} will render text in Arial if the browser doesn’t know what Helvetica is. I think this is a good mechanic to copy, because even podcasts with hyper-specific categories would be guaranteed to fall-back to something “normal” eventually.

With this in mind, here are my proposed modifications:

1. The name should be <podcast:category>, to keep convention with <category> and <itunes:category>
2. Multiple <podcast:category> elements may exist per <channel>. The ordering is emphatic, with the most significant element first.
3. Each element has a text attribute which lists the category hierarchy, root first, comma separated. It’s understood that the true category is the rightmost and the rest are fallbacks in case the host/app/whatever doesn’t understand (or care).
4. All root level categories will be defined in the specification. Some 2nd level categories will be defined (the ones in common use today). Podcast hosts may append new 2nd (or higher) categories as desired, but they must all be traceable to a root category.

Examples:

	<podcast:category text=health, nutrition, keto diet />
	<podcast:category text=leisure, table top games, old school renaissance />
	<podcast:category text=music, metal, thrash metal/>

In this case, a parser which doesn’t understand “old school renaissance” would at least know we’re talking about table top games, or -worst case- the general category of leisure, and could try its best to put us in the right place. Compatibility with all <itunes:category> is there, so long as their base categories are a sub-set of ours. But it also gives free and open podcasting room to grow as it chooses.

So basically tl;dr what @jamescridland said, except different.

[daveajones]

That’s an interesting idea @ablekirby. I like the concept of splitting the concern in two and having a fixed list for sanity and then a free form for user control. That’s essentially what iTunes:category + iTunes:keywords is supposed to be. But this would be in a single tag.

I also keep coming back to the notion that limited choice is attractive to people. The “menu” as you call it. But I’m also sympathetic to the idea of not formalizing it out of use.

🧐…

[thebells1111]

@ablekirby Good write up, and makes a lot of sense. I like the idea of the first category needing to be one of the predefined major categories, but the subsequent categories can be user defined for fine tuning. This allows for backwards compatibility, which is important.

Rather than the rightmost category being the true category, I'd prefer all three categories to be the true category.

<podcast:category text=leisure, table top games, old school renaissance />
<podcast:category text=leisure, cosplay, old school renaissance />

If I'm understanding you correctly, in your implementation, both of these categories would bring up 'old school renaissance' podcasts, but what I'm actually interested in is the table top games and not the cosplay. If there's 100 'old school renaissance' podcasts, and 100 'table top games' podcasts, but only one of those is both 'old school renaissance' & 'table top games' it may never come up in a category search. Something that takes all the categories into account would make sure finetuning of category searches would be possible.

[jamescridland]

This is a nice idea.

The reality is that iTunes categories will remain in RSS feeds for many years to come. I don't believe that we need to look at this in isolation, then - we have the formalised categories (thank you Tim Apple), and we can have fluid, unformalised categories with this specification.

Alternatively, we use keywords to achieve what I think I'm trying to do; and retain the Apple categories in the feed as well.

I'm unconvinced of the need to build an alternative formalised master list of categories. The Apple one isn't perfect, but there's a degree of wheel-reinvention that I'd be eager to avoid.

[theDanielJLewis]

If we're going to indicate hierarchy within a single tag, I think we should use colons, not commas. For example, <podcast:category text="health:nutrition:keto diet" />Commas usually denote a list, not a hierarchy.

[Agorise]

people will use similar words, synonyms or different spellings/singular/plural to describe their podcast. It will be to open and the structure will be bad or even worse than now. Controlled vocabulary is the way to go. It brings order into chaos. Think about the user experience and discoverability.

Exactly, the world will end up with 30 categories/topics/hashtags describing the same thing. Or categories that are actually just a brand name for some company trying to sneak in some exposure. Here's a decent list:
https://en.wikipedia.org/wiki/Wikipedia:Contents/Categories

I like standards, it makes our stuff more interoperable.

[RichardJActon]

What I think you need here is an ontology gives you a bit more than just a controlled vocabulary, see this for music for example: http://musicontology.com/specification/

[agates]

This website is broken for me. Getting a certificate error and forbidden.

[RichardJActon]

Looks like they don't have HTTPS on - project dates back to 2006 active until 2013, semantic web stuff was in vogue between then and the early 2010s, making a bit of a comeback now but still a lot of projects not getting maintenance.

see their github: https://github.com/motools, wikidata would be a better bet for more update date stuff it seems: https://www.wikidata.org/wiki/Wikidata:WikiProject_Music/Lists/Music_genres_by_external_identifiers

[nathangathright]

Since this proposal has been revived for Phase 7, I wanted re-suggest Wikidata identifiers as a middle ground between totally freeform keywords and maintaining a list.

• Hypothetically, music podcast hosts could provide a typeahead field of just music genres. Wikidata has 5,751 of them.
• Topic-modeling a transcript could produce suggested categories.

[daveajones]

This is cool. Need to spend some more time getting familiar with it and get my bearings straight. But, it seems like a good way to generate bootstrap lists.

[daveajones]

I think I'll take a crack at putting together a proposal doc based on the current thinking and then we can hash that out. We discussed today calling it <podcast:tag> just to get some distance from current "category" type thinking.

[jamescridland]

I'm liking this. A tag, like a hashtag - as discussed in the podcast last week.

Being freeform seems to make sense to me - we already have a category list in the form of the itunes list, which is unlikely to go away (and, to be fair to Apple, had considerable thought put into it). Nothing to stop the UX for a podcast host to be suggesting tags based on popularity (as Mastodon or Twitter does in some UIs).

We might want to think: is this on a CHANNEL level, or also on an ITEM level? And how different is it, really, from the now deprecated itunes:keywords tag?

[brianoflondon]

Why don't we call it a <podcast:podtag> I know Adam loves it when we put "pod" in front of anything

[daveajones]

@jamescridland You ok with me updating the title of this proposal to <podcast:tag> ?

[jamescridland]

Sure!

[ablekirby]

Brian, Great idea. I podagree!

…

-Able

On Monday, January 29th, 2024 at 1:58 AM, Brian of London ***@***.***> wrote: Why don't we call it a <podcast:podtag> I know Adam loves it when we put "pod" in front of anything — Reply to this email directly, [view it on GitHub](#590 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AE6ZEMCENNKGP5UE3I23VFTYQ5CBJAVCNFSM6AAAAABCM74VRKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DENZXGYZTK). You are receiving this because you were mentioned.Message ID: ***@***.***>

[jmazzahacks]

I loved this idea at first glance because we already allow users to create custom tags and assign them to help organize their library in Podcast Guru, but then I realized that if we didn't have some kind of constrained set like itunes:category it could potentially ruin our UX.

If you have 50 podcasts each with 3 custom tags and you want to use your podcast app to filter through these, now instead of the usual dozen or so that show up in an app, you've got potentially a hundred tags to sift through and filter.

So I don't see these working in a filtering mechanism, but I do see other use cases, particularly for search and discoverability.

For example it would be awesome to search by tag, and we could show a list of these tags in a podcast description / info screen, that hyperlinks / deeplinks to your search engine, etc.

[jamescridland]

This doesn’t replace itunes:category

[jmazzahacks]

Right, just exploring alternate use cases for it specifically since it doesn't. I think it could really help with discoverability.

[swschilke]

Hallo, I would prefer to use some controlled vocabulary (some call it ontologies) like in the Linked Open Data world. Subjects / topics from wikidata or others (e.g. Google Knowledge Graph ID). See Adam Curry for example: https://www.wikidata.org/wiki/Q349039 and he is a podcaster https://www.wikidata.org/wiki/Q15077007 If you're doing a podcast about literature the tag could be https://www.wikidata.org/wiki/Q8242 Doing so this would allow to build a knowledge Graph and link the Subject via a "link" (Property) to an Object (this would work in multiple languages, and really could solve discoverability) Here ist an example for a podcast https://www.wikidata.org/wiki/Q110568172 (not mine ;-) ) genre <https://www.wikidata.org/wiki/Property:P136> it's linked to news commentary podcast <https://www.wikidata.org/wiki/Q106704934> and technology podcast <https://www.wikidata.org/wiki/Q105012442> https://angryloki.github.io/wikidata-graph-builder/?item=Q109248984&property=P136 This graph allows you to really easily browse and find similarities regards sws

…

On Sat, Feb 10, 2024 at 5:43 PM Jason Byteforgia ***@***.***> wrote: Right, just exploring alternate use cases for it specifically since it doesn't. I think it could really help with discoverability. — Reply to this email directly, view it on GitHub <#590 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE66ARCKQZNK3RIQUAJAUDYS6PUVAVCNFSM6AAAAABCM74VRKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DIMRYGQZTG> . You are receiving this because you commented.Message ID: <Podcastindex-org/podcast-namespace/repo-discussions/590/comments/8428433@ github.com>

[jamescridland]

I like the concept of wikidata categories. That helps with "do you mean Reading, the town in England, or reading, like reading a book".

I worry that it adds significant complication to podcast hosting companies and others.

[swschilke]

They even started a Podcast Project (some time ago ;-) ) https://www.wikidata.org/wiki/Wikidata:WikiProject_Podcasts

…

On Tue, Feb 13, 2024 at 9:30 AM James Cridland ***@***.***> wrote: I like the concept of wikidata categories. That helps with "do you mean Reading, the town in England, or reading, like reading a book". I worry that it adds significant complication to podcast hosting companies and others. — Reply to this email directly, view it on GitHub <#590 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE66AXBI2CW66GY5NZBPLDYTMQAVAVCNFSM6AAAAABCM74VRKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINJQG42DO> . You are receiving this because you commented.Message ID: <Podcastindex-org/podcast-namespace/repo-discussions/590/comments/8450747@ github.com>

[swschilke]

If you have a controlled vocabulary you can build rather easy interfaces which allow you to point and click via a "display name" and the property and Subject / Object is created on the backend.

…

On Tue, Feb 13, 2024 at 9:30 AM James Cridland ***@***.***> wrote: I like the concept of wikidata categories. That helps with "do you mean Reading, the town in England, or reading, like reading a book". I worry that it adds significant complication to podcast hosting companies and others. — Reply to this email directly, view it on GitHub <#590 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE66AXBI2CW66GY5NZBPLDYTMQAVAVCNFSM6AAAAABCM74VRKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINJQG42DO> . You are receiving this because you commented.Message ID: <Podcastindex-org/podcast-namespace/repo-discussions/590/comments/8450747@ github.com>

[Dwev]

If we are going to use controlled vocabulary, I think we need a vocab for every medium.

Podcast is well covered, and music has been mentioned above, but then we will also likely need a vocabulary for other mediums like audiobook, film, course, newsletter, and blog.

It might not be the right place, but maybe the curator for these lists should be the Podcast Standards Project. The tag definition belongs in the namespace spec, but the list of possible values seems appropriate as a standard. (Maybe not part of PSP certification, but as a PSP recommendation?)

[RichardJActon]

The nice thing about ontologies over just controlled vocabularies is they represent relationships so you can have sub-genres etc. You can just specify what ontology you are using and then the term in that ontology. Though I think ideally you use a triple not a key value pair where you specify the relationship too. So you have an RDF triple of the form: "podcast x" -> "features music from" -> "Genre Y". You'd use a global ID, ideally one with a resolver, for the podcast. Each element is of the form "ontologyX#TermY" so you know where to find the term, its definition and relationships. This is more overhead but it has big benefits for search-ability and consistency down the road. Wikidata is probably a good choice for the sources of ontologies as maintence is better than some of the random individual projects so it should be possible to get any new terms etc up-streamed into the project, rather than independently maintaining lists.

[samsethi]

@Dwev 100% Agree. The Person Tag Taxonomy was not done by this group it was done by https://podcasttaxonomy.com/

About 12 months ago I was talking to Julie Costello (Ainsley Costello mum/mgr) about the need for a music genre because the Apple category list was limited and only had 'music' plus a few sub-categories. Julie sent me this short 'music category' list as a good starting point which is similar to the Apple Music categories.

I shared this with RSSblue, Podhome, Wavlake. I had hoped that these hosts would adopt/adapt this list to categorise their new music tracks which they host. Sadly nothing happened but recently I have noticed Wavlake have started to add Music Genres to their hosted music tracks but I have no idea what list they are working from???

So months ago TrueFans built the music category list into our admin dashboard for music creators in order to show how it might work between hosts and apps. We simply look for medium=music. We then define the primary tag as 'music' from the Apple podcast category or a music sub-category which is in their RSS feed. We then auto-switch the category list from the Apple podcast category list to a music category list to allow music artists to pick additional music category tags from Julie's pre-defined music list.

I appreciate this list could/should be extended but it's a good starting point. Julie sent me a much longer more extensive list if we think this is the way to proceed? We also have a free-form keyword field below for artists or podcasters to add other self-describing categories which might fulfil what James mentioned above?

TrueFans also allows podcasters to export an updated RSS feed and to deal with the option where a music artist has added additional music categories we have already adopted the format <podcast: category> which seems logical. However this may not work and we may need to be more descriptive with <podcast: music-category> because as we extend the RSS medium tag to include audiobooks, films, courses etc we will need a pre-defined list for each of these genres.

There is a lot of related work going on such as ISRC classification, recoup, podcast license and publisher feeds. I think if we can crack this category list issue then we can accelerate music discovery and other genres in the future.

[daveajones]

Here is the list Wavlake is using for music genre:

https://github.com/wavlake/genre-list

[swschilke]

Maybe you could have a look at Schema dot org and I assume there are usable controlled vocabularies in the linked open data space. Guy Martin ***@***.***> schrieb am Mo., 8. Apr. 2024, 23:03:

…

If we are going to use controlled vocabulary, I think we need a vocab for every medium. Podcast is well covered, and music has been mentioned above, but then we will also likely need a vocabulary for other mediums like audiobook, film, course, newsletter, and blog. It might not be the right place, but maybe the curator for these lists should be the Podcast Standards Project. The tag definition belongs in the namespace spec, but the list of possible values seems appropriate as a standard. (Maybe not part of PSP *certification*, but as a PSP *recommendation*?) — Reply to this email directly, view it on GitHub <#590 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE66AUV7LGFDTJ7TRQKEZ3Y4MAY3AVCNFSM6AAAAABCM74VRKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANJRGE4DS> . You are receiving this because you commented.Message ID: <Podcastindex-org/podcast-namespace/repo-discussions/590/comments/9051189@ github.com>

[Dwev]

I can't see any enumerated lists (what schema.org seem to call vocabularies) for genre there.

I also don't know how to use WikiData well enough to pull the other vocabs from there.

As mentioned by @nathangathright, there are over 5000 genres for Music in WD, which I think is a lot of noise. Audiobooks (which could parallel "book" genres but also include audiobook-specific ones like dramatisations) would likely have several hundred genres on WD.

IMO, a curated subset of these genres would be preferable as a baseline, with the option to add additional freeform tags. Type-aheads would be great for this, as if the curated list has "science-fiction" as an audiobook genre, that would be preferred to a freeform "sci-fi".

As a standard, the curated lists could be a minimum to comply with PSP, and anything additional is up to the host / player. A specialist music player might want to enumerate many more music genres than a general podcast player, and the same for a specialist audiobook player.

[swschilke]

I'm no longer with the organisation which worked with LoD so I have to search (at the moment I have only https://lov.linkeddata.es/dataset/lov/vocabs or https://lov.linkeddata.es/dataset/lov/terms and https://music-encoding.org/ handy). Mayber https://nfdi4culture.de/resources.html can help or https://pitt.libguides.com/metadatadiscovery/controlledvocabularies One paper is this https://zenodo.org/records/1492441 Wikidata (dbpedia) link to the conntrolled vocabulary the use. Metadata in MP3 / ID3 has a list of https://en.wikipedia.org/wiki/ID3 see List of genres in ID3v1 <http://www.multimediasoft.com/amp3dj/help/amp3dj_00003e.htm#ss13.3> or https://www.multimediasoft.com/amp3dj/help/index.html?amp3dj_00003e.htm there should be other linked or mentioned

…

On Tue, Apr 9, 2024 at 11:08 AM Guy Martin ***@***.***> wrote: I can't see any enumerated lists (what schema.org seem to call vocabularies) for genre there. I also don't know how to use WikiData well enough to pull the other vocabs from there. As mentioned by @nathangathright <https://github.com/nathangathright>, there are over 5000 genres for Music in WD, which I think is a *lot* of noise. Audiobooks (which could parallel "book" genres but also include audiobook-specific ones like dramatisations) would likely have several hundred genres on WD. IMO, a curated subset of these genres would be preferable as a baseline, with the option to add additional freeform tags. Type-aheads would be great for this, as if the curated list has "science-fiction" as an audiobook genre, that would be preferred to a freeform "sci-fi". As a *standard*, the curated lists could be a minimum to comply with PSP, and anything additional is up to the host / player. A specialist music player might want to enumerate many more music genres than a general podcast player, and the same for a specialist audiobook player. — Reply to this email directly, view it on GitHub <#590 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE66AU72PFEY3YWRBG2OUDY4OV2HAVCNFSM6AAAAABCM74VRKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANJWGU2DI> . You are receiving this because you commented.Message ID: <Podcastindex-org/podcast-namespace/repo-discussions/590/comments/9056544@ github.com>

[swschilke]

Semantic stuff is becomming again en vouge (NFDI Projects in Germany and other countries, mainly in the culture area)

…

On Tue, Apr 9, 2024 at 11:28 AM Richard James Acton < ***@***.***> wrote: Looks like they don't have HTTPS on - project dates back to 2006 active until 2013, semantic web stuff was in vogue between then and the early 2010s, making a bit of a comeback now but still a lot of projects not getting maintenance. see their github: https://github.com/motools, wikidata would be a better bet for more update date stuff it seems: https://www.wikidata.org/wiki/Wikidata:WikiProject_Music/Lists/Music_genres_by_external_identifiers — Reply to this email directly, view it on GitHub <#590 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE66AUHKYVOGNJ2GIOBHX3Y4OYD7AVCNFSM6AAAAABCM74VRKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANJWG43TG> . You are receiving this because you commented.Message ID: <Podcastindex-org/podcast-namespace/repo-discussions/590/comments/9056773@ github.com>

[daveajones]

Just a reminder to all in this thread that this tag name is 100% going to change. <podcast:category> would conflict with <itunes:category> in the sense that when we create a tag with the same name as an itunes namespace tag we strive to keep the default syntax compatible. That won't work in this case. So, the naming will be something like <podcast:tags> or something. At this point I'd rather just avoid anything similar to category/categories to minimize confusion.

[samsethi]

The WavLake list in the CSV is comprehensive. If we all agree I can change the list on TF's using the CSV. Of course it requires hosts to add this to the RSS feeds to test if it works. One thing to consider for the future. We will needs lists for audiobooks, films, courses etc. Can the Podcast:tags be named in such a way to take into account the different category lists.

Also the podcast:publisher tag works for both podcast publishers like Wondery. https://truefans.fm/publishers/wondery but also music artists. The way we are differentiating is via the medium=genre i.e podcast or music to know what type of list it is and where to show it in our UI. So having publisher pages for audiobooks in the future is simple enough.

So my point with podcast:tags is how will we tell in the future if this is a music category list or a audiobook category list or a film category list. do we just need to add medium=audiobooks inside this tag to clarify its an audiobooks category list?

[daveajones]

Since any lists being used are just seed values to resolve to trending values (i.e. typing "newage" gives you "New Age" as a suggested resolve), I would think that the medium chosen for the feed would be the signal for what list to use. So, if someone creates a music podcast on RSS Blue, Dovydas's code is going to give them the current music bootstrap list, and likewise if they choose audiobook medium.

We can collect these bootstrap lists here in the namespace repository and keep them public if hosts will contribute back to the repo with periodic PR's.