<podcast:person> does not support multiple roles #498
Replies: 10 comments 19 replies
-
|
Interesting. @bslinger , do you have any initial thoughts on this? I can see the benefit of adding textual codes to the tag, but also it’s nice to simply parse the role out directly and not have to do a lookup. So I lean towards a comma separation. |
Beta Was this translation helpful? Give feedback.
-
|
Personally I'm in favour of role-codes just for my own sanity with how our database ingests these as "slugs". But I'd be happy to see either way move forward on this if it gets it closer to adoption. |
Beta Was this translation helpful? Give feedback.
-
|
Are we any closer to improving this tag? |
Beta Was this translation helpful? Give feedback.
-
|
We had a similar issue. As we had people who had multiple roles. So James Cridlands is Host and Editor and I am Host and Producer. So we added a second person field. This is local to TrueFans. We also made these roles searchable so I might want to find other people tagged producer or songwriter. So I think each role needs to be a distinct entry in the person tag. 
|
Beta Was this translation helpful? Give feedback.
-
|
I don't quite see why ...isn't valid. It's the same person, and that can be de-duped on the app's end if they want to. As it currently stands, it's easy for an app to find and display "Editor" without having to do additional work. Are you able to clarify the issue, Pierre? (A "secondary role" doesn't work if you want to specify that someone is the Host, Writer and Editor.) Are you also able to clarify the requirement for a role code? Those of us using this external list for roles can relatively easily programmatically build them (strtolower(str_replace(" ","-",$code)) - but I don't see the issue that it causes. |
Beta Was this translation helpful? Give feedback.
-
|
Greetings All! The bigger problem is the source of truth. Who is responsible for that source? The Podcaster's RSS Feed, The Player App, The Podcast Host, or a whole new thing -- some kind of Podcast Person Index? Here are a few of the Person Tag Use Cases as I see it: Use Case #1 - Podcaster Person Tag Input: If the Podcaster wants to control the Persons Tag information in their show, they can provide their own rationale for ambiguity, give each person the role they decide to give -- true or false -- and give each person an ID that only makes sense to that Podcaster. This works for the Podcaster but does not work for anyone else trying to aggregate all Persons into a single interface. Dups, validity, typos -- it would be a mess. It would also be what we currently have today. This is the Wild, Wild West because a Podcaster can put whatever they want into a Person Tag. Use Case #2 - Podcast Host Person Tag Input: A Podcast Host could easily give a new Person a unique ID, allow it to have nested roles, and solve all dups and data validation for all of their customers. But what about the customers of other Podcast Hosts? If only a few of the Podcast Hosts support the Person Tag (like today) you would have yet another situation where you have multiple IDs and conflicting data mixed with business competition. Good luck getting that to work! Use Case #3 - Player Apps with Person Tag Search: The Player App only needs to display what the Podcaster has provided them via their RSS file. However, I do not see the Player App as the source of truth for Persons because it can only work with what it has been given. Player Apps should probably stay out of the Person aggregating game except for one important exception: Search. Player App search is where this all breaks down. If each Podcaster can put whatever they want into the Person Tag, Player App search breaks unless it can solve dups and correct data before showing it to the user. Not an easy job when the data is garbage in, garbage out. Here are some observations I had that might help define the big picture Person Tag issues: Observation #1 - What problem does changing the Person Tag solve? Are we trying to fix data input issues caused by Podcasters and Podcast Hosts? I see this as an education and behavior problem. If we have bad data going into Person Tags then maybe we've done a poor job explaining to Podcasters how it's supposed to work. Observation #2 - Do we need a Person Tag ID? This would clear up dups and help Player App Search. I see the benefit of having Search find me every podcast appearance of a Person. However, does the listener care as much about what role a person has? Observation #3 - Are we overthinking Person Tag roles? I believe the listener only cares about 2 roles: Host/Co-Host and Guest. These are the only voices on an episode. I don't think the listener cares about who the Producer, Writer, or Director is unless it's an Audio Drama or a Band/Musical Act. All these extra roles seem like vanity roles that try to recreate IMDB in the podcasting space. Is that is that actual goal? And if it is, maybe we need to separate the Person Tag into Observation #4 - Are we all leaning toward a Podcast Person Index that acts as the single source of truth for all Person Tags? I see the benefit of having something like Gravatar run by Automattic -- A global Podcast Person Tag aggregator. Who would finance it, build it, and manage it? It could be another data monster! Currently, we're left with trusting the Podcaster (and the supporting Podcast Hosting Companies) to enter Person Tag data correctly using whatever ID, name, image, link, and roles they decide to use. Maybe that's okay. Maybe that's how it has to be. The Podcast Player App folks will just have to accept what the Podcaster gives them and decide if their Search feature is worth the aggravation it will take to deconflict dups themselves. Personally? I like this concept modeled after the It could look something like this: Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
My use case for this tag as an aggregator is to have a proper set of credits for each podcast. I'll trust the podcasts to enter this information correctly until I see it's being abused. Voices are as important as those in non voice roles. My use case for this as a podcast host is to properly credit everyone working on the show, in all of their roles. As a listener, being able to search for a specific person in an app would be great, variations in spelling and duplication doesn't necessarily deter me or make the search less valuable. Adding 218 characters to add 16 seems like a disproportionate use of the space available, IMO. I don't think this really needs to be any more complex than having roles be comma separated added to the spec, or a new attribute of "roles" added to indicate secondary roles. Splitting it into cast and crew is already solved by the role taxonomy. If someone steps up to create an IMDB with unique people ID's (Podchaser?) then that's something to consider down the road by adding an ID attribute easily enough. I don't think this tag will solve an issue of being a single authority of truth no matter what changes are made. |
Beta Was this translation helpful? Give feedback.
-
|
Okay. I see your point. Maybe I can clear my original post up. I think there are three stakeholders involved here: Listeners using the app, Player App Developers building a UI, and Podcasters trying to get their Person Tags correct. Listeners want to see who is talking. They care about voices. I care -- as a podcaster -- who did the writing, directing, or producing but I think you would be hard-pressed to find any Listeners (i.e. users) that care about all the extra info. My proof is movie and TV credits. Netflix has already taught a generation of people how to skip all that attribution with UI features like "Play Next Episode" or "Skip Intro". That is my opinion but I would put money on it that I'm right. People come for the voices and skip the credits. App Devs just want the data to be correct and not have to show 15 different copies of "Tom Black". In that case, having a CSV list seems appropriate. I agree with you there. It is the Podcasters that are the wild cards in this scenario. Can they be trusted? Sure. Their show, their rules. However, now we enter into that realm where we have not done a good job of educating podcasters about the Person Tag. At Podfest just a few weeks ago, I talked to several podcasters who didn't even know there was a Person Tag. Their first response was "Oh! Is that a replacement for the Author Tag, right?" Should it be a replacement for the Author Tag? Maybe it should. That's a fight for another day. Those who did know there was a Person Tag were caught up in misunderstanding the difference between groups and roles. Both attributes are optional. Heck, all the attributes are optional! Only a name is required. But these podcasters didn't know that. And when you start to talk to them about PC 2.0 specs their eyes glaze over. Nuff said. I propose we simplify the Person Tag even more beyond the plural of roles. Example Which will lead to all sorts of roles: Director, Assistant Director, Executive Producer, Senior Producer, Producer, Associate Producer, Development Producer, Creative Director, Voice Actor, Narrator, Author, Writer, Co-Writer, Guest Writer, Story Editor, Managing Editor, Script Editor, Script Coordinator, Researcher, Editor, Translator, Logger, Studio Coordinator, Technical Director, Technical Manager, Audio Engineer, Remote Recording Engineer, Post Production Engineer, Audio Editor, Sound Designer, Foley Artist, Composer, Theme Music, Music Production, Music Contributor, Production Coordinator, Booking Coordinator, Production Assistant, Content Manager, Marketing Manager, Sales Representative, Sales Manager, Graphic Designer, Cover Art Designer, Social Media Manager, Consultant, and Intern. Holy Cow that is a lot of groups, roles, and roles within groups! They are all optional? Yup! And an Audio Drama could have them ALL! Let's pretend that Tom Black has created an Audio Drama with his friends. Using only our fictional podcaster Tom Black's groups and roles we find that he not only produced, directed, wrote, marketed, edited, and managed this podcast, but he also stars in it. Tom is a Renaissance Man! To that end, Tom's current Person Tag looks like this: And that's just Tom! Now add all the other 10 cast and 10 crew to that audio drama and you have a list far more than 218 characters per episode! However, if you separated the concerns between what Listeners want (Voices in the audio) and Proper Attribution (Creators of the audio) you could get this: Although optional, by eliminating the need for "group" in the first place by simplifying group to only two types: cast and credits. This makes it much easier for normy podcasters to understand. Unfortunately, if this is done every episode with the other 20 folks in this Audio Drama, then the resulting RSS file will still have several lines of extra information that we just don't need. So, let's take the concept one step further by changing role to roles (plural attribute). The final version could be this: If you add in the 10 other cast members with the 10 other crew members, this makes the groupings tight, clean, and easy to read. It also accomplishes three important things:
Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
But by using the Podcast Taxonomy role or code as the "roles", we already know what "group" they are in with the groupName field. Applications can group them into the "cast" group defined in that spec, and other for the rest if they want to be less granular about the backend credits. So I agree, the group attribute should be depreciated to enable pluralization of roles. As an aside, anytime I talk to podcasters about 2.0 they either freak or glaze over as well. I think it's going to be on hosts and aggregators to really make this work as a whole, not just specifically the person tag. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think taxonomies are only understood by App Devs. I'm with you on simplifying the Person Tag. I believe that if we make it understandable to normy podcasters, we have a very good shot at getting them to care about it! Meanwhile, the Author Tag is the 500-pound gorilla in the room... 🤠☕ |
Beta Was this translation helpful? Give feedback.
-
I think this (plural attribute) would be the ideal path forward to fixing this tag. Would be much simpler to parse, and take up less space in the feed. You could set the primary role to role, and have additional roles in the roles tag. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
What's the use case here? To indicate the person is you? |
Beta Was this translation helpful? Give feedback.
-
|
Its a simple way to verify yourself |
Beta Was this translation helpful? Give feedback.
-
|
Not sure I understand, to whom? |
Beta Was this translation helpful? Give feedback.
-
|
Resurrecting this! I think the idea of putting comma-separated roles into a new I always thought it should have supported multiple roles from the beginning. |
Beta Was this translation helpful? Give feedback.
-
|
Hi I think it is vital that this group gets control of the Podcast Taxonomy. It has not been updated for at least 3 years. We have already added a secondary role. So James is host and editor and I am host and editor. 
TrueFans has added the Host=AI as a new role. 
We have also added a user setting to hide/disable any podcast/episode if Host=AI.
|
Beta Was this translation helpful? Give feedback.
-
|
Purely if the host is AI. If AI used for cover art or |
Beta Was this translation helpful? Give feedback.
-
|
I think I'd prefer a flag separate from the person tag to indicate ai. As it's not really a person. Like in #669 |
Beta Was this translation helpful? Give feedback.
-
|
I get your point but the person or voice speaking is AI. So the idea is the let listeners know the voice they can hear is AI generated and not human. So host=AI seems logical to me. The person tag is now badly named but we can’t change that. If the tag was called Voice then voice=AI seems logical. |
Beta Was this translation helpful? Give feedback.
-
|
You guys should check out my proposal for |
Beta Was this translation helpful? Give feedback.
-
|
BTW, I think "control" of the Podcast Taxonomy would be best under Podcast Standards Project. |
Beta Was this translation helpful? Give feedback.
-
|
Buzzsprout the host of Podnews Weekly recently added item level support for GUESTS in the Person Tag. This is great and has worked really well. - see image below. 
However they only support one role per person. So James is the host and also the editor and I am the host and producer. Sadly we cannot add/show a secondary role in Buzzsrpout. That is primarily because the Person Tag only supports one role. We need to extend this 
TrueFans has supported two roles in the Person Tag for sometime. We have made these roles hyperlinked so you can find other people who might be an editor or producer and in music maybe a singer as well as a songwriter. 
|
Beta Was this translation helpful? Give feedback.
-
Hi, I'm a developer at Captivate, working on features relating to this.
At the moment, there is no way to signify that a person has multiple roles in a way that is unambiguous from two people with the same name and different roles.
For example:
could mean
John Smith is both a Guest and an Editor
or
John Smith (A) is a Guest
John Smith (B) is an Editor
Ideally I think we'd want to separate roles by spaces. However, the roles contain spaces themselves, which seems like it might be a mistake. Given this, another delimiter would need to be used to clarify multiple roles. Perhaps comma?
e.g.
It might also be worth making official codes for each role/group for this page: https://github.com/Podcastindex-org/podcast-namespace/blob/main/taxonomy.json
e.g.
{ "group": "Creative Direction", "group-code": "creative-direction", "role": "Development Producer", "role-code": "development-producer", "description": "The Development Producer coordinates and executes the pre-production create direction of a podcast. Their responsibilities include finding new episode and series ideas and working with writers and researchers to prepare the concept for production.", "example": "" }role-code and group-code could both be case-sensitive, removing the requirement to lowercase the role and group.
This would allow the more natural space separation:
Further, if you want to retain backwards compatibility with earlier parsers, something like this could work:
Originally posted by @picard102 in #96 (comment)
Beta Was this translation helpful? Give feedback.
All reactions