hello, everyone. i’m not very active here, but i wanted to propose this!
MB currently has a gender field for artists (other/female/male), which can be set for individuals only. since gender and pronouns don’t always align, i think we could use a field for each artist’s primary pronouns.
since the list of neopronouns can be extensive, and for internationalizations we’d have to discuss translations of these, i initially propose this with the following general structure:
plural pronouns limited to groups, i believe?
the next step, if desired, would be to allow specific pronouns (they, it, ze, etc.) — but this would require further discussion, as each language has different neutral pronouns that might not have a direct translation between languages.
i see two appropriate options to implement this:
single fixed value
this is how gender is handled currently.
multiple values with time period
similar to how aliases work, which would allow to set begin and dates.
the date option limited to groups only maybe? use case: when a group lineup changes from a mixed gender/pronoun ensemble to all female.
a third option could be to create pronouns as entities to be used as relationships, the way @paulakreuzer proposes for gender:
this could also be extended to users, and person entities on other MetaBrainz projects.
I’m not against having an attribute for preferred pronouns for artists who do have them (on their Twitter, website or whatnot), once we finally get artist attributes in a similar way as we have work attributes. But I don’t think this should be something expected for every artist, for two reasons: I expect we don’t want people assuming the pronouns just to fill a form, and as @yindesu mentioned some languages don’t even have pronouns at all, and many which do do not have gendered pronouns, so for many artists around the world the concept of “having pronouns” will be completely foreign, in the most direct meaning of that word.
I think the best way would be for the attribute to be tied to a language or locale, but I’m not sure that’s possible currently? E.g., so you could set artist d112e7ac-3811-4773-abe3-f06c5e697ff4 to have “he/him/his” and “they/them/theirs” for English, “han/ham/hans” and “hen/hen/hens” for Danish, and “han/honom/hans” and “hen/hen/hens” for Swedish - where the “hen/hen/hens” would not be the direct translation of “they/them/theirs”.
Well, of course none of the attribute options are possible currently, since we don’t have them for artists yet, but that being said, having a locale might also be an extra step on top, yes. The easiest starting point might be to just have the field be free text - that would allow you to enter “he/him/his (English)”, “they/them/theirs (English)”, “han/honom/hans (Swedish)”, etc, and also avoid the issue where we would otherwise need to put together our own list of pronouns that would then need to be maintained. The only issue I can see with that is possible vandalism, but I can’t see why we wouldn’t just deal with that in the same way as with any other possible vandalism
@briaguya listed pronouns next to biological definitions. Can’t really do that as I know a male friend who uses they\them. Kinda the point of being allowed to make up your own pronouns.
I think the free text field makes more sense. By far the majority of this database will be using the standard definitions, and a blank can be assumed to use that normal match of male\him. When new data is added to a blank field it can then override with the chosen pronoun.
On a side note, when @paulakreuzer brought this discussion up a few years it caused me a few issues as I suddenly didn’t know what to select when adding artists. I stopped assuming a “David” was male. I realise this is a little extreme, but it was hard to find proof of how someone defines themselves as it is usually not that important to them. Trying to find pronouns is going to be even harder.
For sure, current system has to change.
I fear free text doesn’t solve anything.
Imho we need entities, that can be translated through aliases+locales.
We could manage them as we do with genres (musical ones) and areas, create an initial list and make it more complete over the time.
Also it has to support dates.
We need to think about converting current information (male → he/him (en), il/lui (fr)).
The fact certain languages don’t use genres isn’t a problem, as many more do
I don’t think pronouns can be meaningfully translated globally, tbh. E.g., “they/them/theirs” pronouns can be either “de/dem/deres” or “hen/hen/hens” in Danish. “ze/zir/zirs” and “fae/faer/faers” do not have proper translations in Danish that I’m aware of at all. Pronouns are very much per-individual-per-locale.
Also, pronouns are extremely fluid. I think a free text input would work way better than an entity like system.
Well, it depends on what we are trying to solve. Are we trying to have a full set of machine-readable pronouns for all artists in all languages, or are we trying to respect the pronoun choices of the artists and let the users do with that what they will? I think the second is a lot more realistic, and free text seems to work for the artists themselves on Twitter or whatnot
Hmmm, I don’t get something then.
What’s the purpose of genre for artist at the moment?
What will be the use of the free text entry? (which may mean nothing to editors)
Yes, this is why we need to be able to link one person/artist to zero or more entities.
For examples you gave, there will be multiples entities (along their aliases in other languages, if they exist).
Let’s say English uses A, which translates to B in another language, we create entity A, with alias B (set to proper locale, preferred)
Now we have another language which uses C, which has no equivalent in any other languages (at the moment it is created), then that’s an another entity.
But linking an artist to A would then also imply that they go by B pronouns in that other language/locale, which they might not. So we would then need to have A₁ and A₂, one of them with an alias and one without.
Before this gets too deep - can I ask why we would need this kind of personal data in a Music database? Where is MB using a pronoun for an artist? There are no biographies here, just links to external sources to that kind of data. We have gender options as database like putting people into boxes. Similar to Country\Location boxes. Where does MB need to use a pronoun? Isn’t that data better kept in their external biography on their own home pages, wikipedia, etc.
It was a little bit of everything. A joke. Meanness. An actual question that would need solved.
I have said elsewhere, how are we (people, businesses, etc) expected to comply with something that isn’t even settled between those that want us to comply. Let them figure it out amongst themselves, then we can worry about it. Until then, we would need to be in a state of constant change, or we threaten offending someone for not having a 2 day old pronoun available to use.
One group wants 101. Another wants 72. And New York City has accepted 31.
The only way we would be able to truly solve “the problem” (in quotes because it really isn’t a problem) is to allow free form writing. At that point, it becomes pretty useless to a database because you wouldn’t be able to apply the data as needed.
as i mentioned, the list can be exhaustively extensive — and that’s only considering English!
my proposal for now would be to implement only 9 or, depending on how it’s implemented, 5 generic options:
mixed — for groups only
“any” — when an artist doesn’t mind, or accepts all pronouns
if there is a consensus to further specify pronouns, we could implement them under these categories.
i don’t disagree with a free‐text field approach, with locale options (how we do for aliases), but maybe it could be on top of the 9/5 options i’m proposing, similar to how it works for instrument performance relationships — you select “instrument” and then you can set the specific instrument(s).
i think it matters as much as we might care about personal relationships between artists, like romantic involvement, which we do store on MB. and for some artists, this part of their identity is relevant to the work they make. it’s not urgent to store this data, but i think it would be valuable to do so.