Hello all, I am a relatively new Wikidata user, and have run across some inconsistency with regard to given names, sex/gender, and the intersections of the two concepts. I'm not sure what conversations have already happened, or what the best solutions are.
Given names: Given names can be classed as given name<https://www.wikidata.org/wiki/Q202444>, or any of 42 subclasses of given name<https://w.wiki/3Kwj>, which include "female given name<Q11879590>", "male given name<Q12308941>", and "unisex given name<Q3409032>" (among others). The real-world application of these gender-specific classes to items for given names is problematic for a number of reasons. Names associated with one gender in one culture and/or time period are frequently associated with another or all genders in other cultures and/or time periods. This is not well adjusted for in practice in Wikidata. Some names include "instance of<https://www.wikidata.org/wiki/Property:P31>" statements for multiple classes on the same name item, and others proliferate items for the same name string for usage by various genders. It seems like a burdensome, if not impossible, endeavor for little return to try to straighten it out. Assigning gendered given names can lead to incorrect assumptions about a living person's sex or gender. Bots use labels to assign values for given names, regardless of whether the person's gender identity is known and asserted on Wikidata. This can lead to unreferenced statements being made about the sex or gender of a living person, based solely on the label, as discussed here<https://www.wikidata.org/wiki/Wikidata:Project_chat#Bots_using_Labels_to_Potentially_Misgender_Humans>. This is understandable-the concept of gender differs widely across cultures, as does the usage of many given names. Someone in Russia, where given names are more closely tied to gender, may see an item for a person with a "male given name" and assume that the person identifies as male. Which is by no means always the case in every culture. Since there is a very widely used property for sex or gender, it would be easy to determine which gender groups are represented in a group of people/items sharing the same given name with a simple query<https://w.wiki/3Kwm>, without a need for all the different gender-dependent subclasses of names. Sex or gender: A related problem is the assignment of sex or gender values to living persons based on weak assumptions. I'm sure my example above is not an isolated incident. There are many constraints in Wikidata that prod users to assign sex or gender values to items for humans. For example, values of the property "student of<https://www.wikidata.org/wiki/Property:P1066>" have an item-requires-statement constraint of property "sex or gender<https://www.wikidata.org/wiki/Property:P21>". Flagging the absence of this statement and suggesting it be added, when the sex or gender of many people represented in Wikidata is not known, creates a situation ripe for unintentional misgendering<https://en.wikipedia.org/wiki/Transphobia#Misgendering>. Many living people may not want their gender identities made public, for many valid reasons ranging from a simple desire for personal privacy to a fear for personal safety. This seems to fall under the Wikidata policy for living people section on statements that may violate privacy<https://www.wikidata.org/wiki/Wikidata:Living_people#Statements_that_may_violate_privacy>. A number of properties for attributes of living persons include both a "living person protection class<https://www.wikidata.org/wiki/Property:P8274>" of "property that may violate privacy<https://www.wikidata.org/wiki/Q44601380>" and a "property constraint<https://www.wikidata.org/wiki/Property:P2302>" of "citation needed constraint<https://www.wikidata.org/wiki/Q54554025>" with a constraint status of either mandatory<https://www.wikidata.org/wiki/Q21502408> constraint or suggested<https://www.wikidata.org/wiki/Q62026391> constraint. Given the fact that people with many gender identities face persecution and may not want to make their gender identity public, and given the fact that harm can be done by wrongly assuming someone's gender identity on Wikidata, I think both a protection class and citation needed constraint are overdue for P21. I also see that the Wikidata protection policy<https://www.wikidata.org/wiki/Wikidata:Protection_policy> includes Create-protection, which can prevent a page from being created except by certain users. I see that it cannot be applied to deleted items or properties. It seems possible, and perhaps very useful, to add specific properties used with specific items to the Create-protection policy in order to protect the privacy of living persons. For instance, if a person didn't want their sex or gender, their political party, their sexual orientation, or some other piece of personal information disclosed on Wikidata, it would be useful to protect that item from having those corresponding properties created at all. What do members of this list think of: -Separating the concepts of sex/gender and given name in Wikidata? -Separating given names from other attributes of persons, such as nationality or ethnic group? -Removing property constraints that require sex or gender to be identified in items for persons? -Adding the living person protection class of "property that may violate privacy" to "sex or gender" (P21)? -Adding a property constraint of "citation needed constraint" with a constraint status of either mandatory constraint or suggested constraint? -Adding protections against the creation of specific property statements being added to specific items for living persons? Where could such changes be discussed, voted on, or proposed to the community? I also don't know where to look for past conversations surrounding these issues, which almost certainly exist and would be useful to review. Thanks, Crystal Clements, MLIS Science Cataloger Cataloging and Metadata Services University of Washington Libraries Box 352900 Seattle, Washington 98195 [email protected]
_______________________________________________ Wikidata mailing list -- [email protected] To unsubscribe send an email to [email protected]
