Open main menu

Wikidata:Requests for comment/Make family member properties gender neutral

An editor has requested the community to provide input on "Make family member properties gender neutral" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!

ExplanationEdit

Currently some family member properties (mainly sub-properties of relative (P1038)) are gender-neutral (spouse (P26), child (P40), partner (P451)) and some properties exist for males (P7 (P7), father (P22), P43 (P43)) and females (P9 (P9), mother (P25), P44 (P44)). This is unnecessary and causes problems:

  • All people should already have a sex or gender (P21) property, so saving it like this is pointless.
  • Some people are non-binary, see for example Andrea Gibson (Q4755100). Andrea Gibson has the gender non-binary (Q48270) and has a sister Laura Gibson (Q26880311). However, the sister doesn't have any brothers or sisters, she only has one sibling, but this sibling cannot be added to her item because of the forced gender binary. There are more examples of non-binary people with siblings.

ProposalEdit

These problems can be solved by adding non-binary properties or by merging the existing gendered properties. I propose the second solution and to merge the following properties:

Proposer: Robin van der Vliet (talk) (contribs) 14:36, 14 September 2016 (UTC)

DiscussionEdit

There are cases where someone legally changes their gender from being a woman to a man. I don't think that turns a mother into a father. A mother is the person who provides the egg and/or carries the baby to term regardless of their gender.
We can have an additional property for parent if there are cases where someone is a parent for a legal reason in a way that doesn't make them either a mother or father.
As far as P7 (P7), P9 (P9) go in most cases Resonator can already deduce this information based on the parents. I don't think we need to separate properties at that point.
P43 (P43) and P44 (P44) can also be merged. ChristianKl (talk) 18:17, 15 September 2016 (UTC)
About your first point. That depends on your definition of "father" and "mother", do those properties mean "biological father/mother" or "legal father/mother". If it means biological then you are right, but then we also can't have people with two fathers or two mothers.
About your second point. So you propose deleting both properties altogether? That could also be an option, because we indeed can already deduce this information from the parents.
And I agree about your third point. Robin van der Vliet (talk) (contribs) 13:56, 16 September 2016 (UTC)
It's possible to have two biological mothers. One ovo-mother and one birth-mother. Those two people don't have to be the same.
I think both legal and biological mother/fathers qualify for the properties that we have. In practice distinguishing biological from legal fathers also isn't easy without DNA evidence. ChristianKl (talk) 21:17, 17 September 2016 (UTC)
If both legal and biological parents qualify then I would propose merging them as to recognize non-binary parents. Robin van der Vliet (talk) (contribs) 16:48, 19 September 2016 (UTC)
There no reason not to have an addition "parent" whereby both "father" and "mother" are subclasses, if the goal is simply to be able to recognize non-binary parents. In the current state you can also model that with relative (P1038) and type of kinship (P1039). relative (P1038) and type of kinship (P1039) works whenever you have non-standard family relations that you want to enter into Wikidata. ChristianKl (talk) 14:58, 20 September 2016 (UTC)
I think "father"/"mother"/"child" were designed for biological relationships only. That's what was stated in "child" description last year. Also there are the Single Value constraints of "father" and "mother". --Melderick (talk) 19:00, 22 September 2016 (UTC)
I   Support the merge of P7 (P7) and P9 (P9) as it is the only was to recognize non-binary gender. The last time we discussed this, people were opposing the merge because it makes querying harder. If one wants to request either brothers or sisters of a person this is slightly true (it adds 1 line to a SPARQL query). However, in most of the cases I think people want to know all siblings, so querying gets easier with a merged property. For father (P22) and mother (P25) I think we should first agree if these properties are about the biological father/mother or legal father/mother. --Pasleim (talk) 15:42, 16 September 2016 (UTC)
Note that there has already been withdrawn a similar RfC. Matěj Suchánek (talk) 17:39, 16 September 2016 (UTC)
I believe this topic has been brough up before and one argument against was that in many languages there simply is no equivalent word for "sibling". /ℇsquilo 16:10, 19 September 2016 (UTC)
Many languages (Bulgarian, Esperanto, Hebrew, Kannada, Russian, etc...) also don't have a word for spouse (P26), but that shouldn't be a reason to split it up. My native language Dutch doesn't have a common word for sibling, but we could still call this property in Dutch "broer / zus" ("brother / sister") and give it the aliases "broer" ("brother") and "zus" ("sister"). Robin van der Vliet (talk) (contribs) 16:48, 19 September 2016 (UTC)
The same is true for brother and sister. Father and mother on the other hand are shared between all languages.
  Support merging, especially P7 (P7) and P9 (P9). I also support merging of the other properties but this may need some discussion. We need additional sub-properties for refining biological and legal parents and maybe more (legal guardian (Q157509), foster parent (Q2427941)...) -- JakobVoss (talk) 17:36, 19 September 2016 (UTC)
How do you tell whether if a source reports that Joe is the father of John that means it's biological or legal? Joe might not even know himself whether he's the biological father. ChristianKl (talk) 14:54, 20 September 2016 (UTC)
  Support all of these. P7 (P7) and P9 (P9) are still important if parents are unknown or not notable enough to be in wikidata (this was brought up the last time around) but merging to "sibling" would be perfectly adequate and cover the problem cases better. ArthurPSmith (talk) 20:02, 19 September 2016 (UTC)

How about simply creating superclasses for the three categories and not merging anything. That way people can express the specific relationship if they want to do so but they can also make the more general statement if they don't know the gender. ChristianKl (talk) 15:19, 20 September 2016 (UTC)

  Support That will also make requests easier to write. Syced (talk) 06:51, 21 September 2016 (UTC)
  Support I remarked on this early on, as having multiple properties seemed wasteful, but at the time, few people hat gender data. --Magnus Manske (talk) 18:35, 23 September 2016 (UTC)
  Oppose,   Support superclass - this solution is also much better for Infobox users of WD. Above mentioned properties are used in tens of projects and 100+ templates, so any property merger at WD will result in "fixing" all of these templates.--Jklamo (talk) 10:05, 27 September 2016 (UTC)
It would be better if we would do it totally right now, then to postpone the problem. Currently only a few projects use those properties, so fixing it now will be easier than doing it later when literally every project uses it. Robin van der Vliet (talk) (contribs) 15:10, 30 September 2016 (UTC)
Any source and statistic for that? Note that use of Template:ExternalUse is just voluntary. --Jklamo (talk) 21:05, 2 October 2016 (UTC)
I did not know that it was voluntary. But it is still better to fix it now, than to wait and let even more projects use it. Robin van der Vliet (talk) (contribs) 22:51, 2 October 2016 (UTC)
  •   Support brother (P7) + sister (P9) → "sibling": it's just annoying ..
    --- Jura 12:33, 27 September 2016 (UTC)
  •   Oppose father (P22) + mother (P25) → "parent", makes completeness checks much more complicated. Probably also   Oppose stepfather (P43) + stepmother (P44) → "stepparent" for the same reasons, but I don't use them that much.
    --- Jura 12:33, 27 September 2016 (UTC)
    I understand your reasoning behind father+mother→parent, as generally people have one biological parent and one biological mother (with some rare exceptions), but those properties are not necessarily only for biological parents, they can also be used for legal parents, who might have changed gender of are of non-binary gender. But that is another discussion maybe, but this reasoning does not apply for stepfather+stepmother→stepparent, because this isn't about biology anymore, because you don't have biological stepparents, you only have legal stepparents. A stepparent is biologically more like a spouse than a parent.  – The preceding unsigned comment was added by Robin van der Vliet (talk • contribs).
    • Currently the exceptions on single value constraints for mother (P25) are at 3 per 1000 and at least some are due multiple possible mythological mothers.
      --- Jura 04:59, 28 September 2016 (UTC)

I agree with Jura, we should at least keep father (P22) + mother (P25). So:

  •   Support for brother (P7) + sister (P9) and
  •   Oppose for father (P22) + mother (P25). — Ayack (talk) 18:29, 27 September 2016 (UTC)
  • @Robin van der Vliet: Do you have any objections to having superclasses instead of merging? ChristianKl (talk) 19:39, 28 September 2016 (UTC)
    •   Oppose superclasses. This just complicates maintenance.
      --- Jura 19:49, 28 September 2016 (UTC)
Why do you think they complicated maintenance? start time (P580) is a superclass of inception (P571) and that doesn't seem to complicate maintenance. ChristianKl (talk) 22:05, 28 September 2016 (UTC)
  Oppose This seem to my like a temporarily fix. Why superclasses for those properties and not for all the other properties that could have an assigned gender? Storing binary gender information in the properties when all items accept non-binary gender doesn't seem like a good idea to me. Keeping gendered properties is only redundant and unnecessary. Robin van der Vliet (talk) (contribs) 15:10, 30 September 2016 (UTC)
It actually would be a permanent fix of the problem. A general idea of Wikidata at the beginning was that it should allow users freedom to conceptualize the world as they want and not force everybody into same conceptualization. You could ask "why does every language on earth have a word for father and mother" but not for every other concept that can be conceptualized in a gendered way? It's generally because the relationships are defined by the gender.
There's also value in it being easy to query for fathers and mothers. ChristianKl (talk) 17:14, 30 September 2016 (UTC)
My proposal would actually give users more freedom to conceptualize the world as they want. The new properties would function the same way, we can even give the new properties gendered aliases, that way it doesn't even cause confusion for users. The current properties only limits this freedom, because they contain unnecessary and redundant gender information and they disallow non-binary gender identities, which causes problems. Robin van der Vliet (talk) (contribs) 14:24, 2 October 2016 (UTC)
It seems again like you are not engaging with what I'm writing. The approach I'm proposing also has a P:Parent, P:Sibling and P:stepparent that users who want to use those properties can use. On the other hand the current choices would still exist. ChristianKl (talk) 20:27, 3 October 2016 (UTC)
This still seems like a messy solution to me. It will only cause confusion. Should we also add properties for "male spouse", "female spouse", "genderqueer sibling" then? Why only binary and neutral properties for parents, stepparents and siblings? The gender should not be marked twice, especially not if there are so many different family relation types and gender options. Robin van der Vliet (talk) (contribs) 15:19, 23 October 2016 (UTC)
  •   Support but modify proposal on parents and step-parents. In addition to the issues of current properties with non-binary genders, we should also note that not only humans use parent properties. There are lifeforms that are hermaphrodite and an individual can produce male and female gametes. It gets even more complicated when relational properties can be used for fictional character (Q95074). But I suggest that P:parent be restricted to biological parents (i.e. entities who provided the gametes to produce the subject lifeform). The proposed stepparent property should be renamed into legal parents. This means that an item can have both P:biological parent and P:legal parent at the same time. I also   Oppose superclass as it will create inconsistency with so many different types of relations, which makes it more difficult to use the data. —Wylve (talk) 12:00, 17 October 2016 (UTC)
  •   Support Having multiple properties for various genders is an unnecessary complexity. The gender property can easily do the talk about it. Better have merge father and mother, brother and sister,... In regards to the legal or biological parents, that could be solved as a qualifier or, if it's really necessary, by creating two different properties, but, I believe, this doesn't invalidate the initial point that states that those properties should be merged. - Sarilho1 (talk) 09:44, 22 October 2016 (UTC)
  •   Strong oppose this discussion again? Messing up a whole system for a couple of exceptions? No, that's ridiculous. Multichill (talk) 13:36, 22 October 2016 (UTC)
    • The proposal is not quite clear, it could also be about extending a whole system to support exceptions that cannot be expressed with the existing properties -- JakobVoss (talk) 18:47, 22 October 2016 (UTC)
      • How does this mess up the whole system?! It repairs the current messy system, you did not give a single good argument. The arguments for this binary gender system don't weigh up against the arguments for a system without genders. Robin van der Vliet (talk) (contribs) 15:19, 23 October 2016 (UTC)
    • I think the counterarguments in the previous RfC has been mitigated now that WDQ is available. On the non-existence of "siblings" in some languages, it would be acceptable if they name the merged property as "brother/sister", "sister/brother", or even "other children of parent". The current system is flawed because people of non-binary genders cannot be accounted for under the current schema. —Wylve (talk) 17:45, 23 October 2016 (UTC)
      • Also on the wording: some languages don't really have a word for brother and sister. Like Hungarian has words for sibling, elder brother, younger brother, elder sister and younger sister, but the word for brother is quite archaic, and the word for sister is frankly only made up to accommodate the current properties (lit. female sibling). So lack of words cannot be an argument. – Máté (talk) 18:42, 23 October 2016 (UTC)
        • So that means that the current system is not only inconvenient, but it also has a bias for Indo-European languages. Robin van der Vliet (talk) (contribs) 21:48, 2 November 2016 (UTC)
  •   Support All three mergers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:14, 27 October 2016 (UTC)
  •   Strong support gender-neutral everywhere. Mushroom (talk) 12:19, 29 October 2016 (UTC)
  •   Strong support Logical. – Algentem (talk) 15:45, 1 November 2016 (UTC)
  •   Oppose merging parent properties, which would make things more difficult and would remove some information (P22/P25 are not identical with male/female parent). P7, P9, P43, and P44 are redundant, but there doesn't seem to be support for deleting them. --Yair rand (talk) 02:53, 2 November 2016 (UTC)
    • No information gets lost when we merge the parent properties. P22/P25 are identical with male/female parent. The other properties are indeed redundant, but I didn't propose deleting them, I proposed merging them so they are gender-neutral. Robin van der Vliet (talk) (contribs) 21:48, 2 November 2016 (UTC)
  • Why not merge them all with relative (P1038)/type of kinship (P1039)? -- Innocent bystander (talk) 16:39, 14 November 2016 (UTC)
    • I feel like this would be too general and would defeat the point of having properties. If we use relative (P1038)/type of kinship (P1039), then there is no reason why we shouldn't put 1000+ ancestors in an item on a member of a royal family. By using specific properties we are defining the scope of the relationship between items. Ancillary relations such as ancestors and great grandfathers can be discovered through WDQ. The definition of "relative" is also very culture dependent. For example would the father of a stepmother be the step-grandfather of the subject person? The answer would depend on the culture. So not using relative (P1038)/type of kinship (P1039) would allow the schema to be more precise. —Wylve (talk) 10:37, 16 November 2016 (UTC)
      Regarding if "a father of a stepmother" is a relative or not, probably also depends on if they have a personal relation or not. It is to me the same thing with in-law-relatives. My mothers sisters husband is my "uncle" if I know him personally. If I only have heard of him or only meet him in funerals, I only regard him as "the husband of my aunt". Even divorced in-law relatives are regarded as relatives if we stay in touch after the divorce. My mother have a very large family, she has two brothers (one now dead) I have never met. -- Innocent bystander (talk) 16:41, 16 November 2016 (UTC)
  •   Oppose merging but   Support adding gender-neutral properties for persons whose gender is unknown or who are non-binary. Thryduulf (talk) 20:57, 16 November 2016 (UTC)
  •   Support merging per author's reasoning. ~nmaia d 14:12, 20 November 2016 (UTC)
  •   Comment shouldn't we go further ? Do we really need P7 (P7) or P9 (P9) (or a merged sibling property), couldn't we just get rid of it ? (like uncle/aunt P29/P139 properties we're deleted in 2013). BTW, there is not really a word for sibling in French :( VIGNERON (talk) 14:51, 24 November 2016 (UTC)
  •   Comment (1) if the specific relationship is removed how does represent the relationship of a person where one of the parents has undergone gender reassignment? The relationship as father or mother is important to identify the genetic inheritance. Please look to keep it simpler.  — billinghurst sDrewth 11:30, 20 December 2016 (UTC)
  •   Comment (2) If I want to run a query based on a family with multiple marriages it is easier to state father, then group by mother; you make such a query harder if you are making us then group by other parent which is not the first parent.  — billinghurst sDrewth 11:32, 20 December 2016 (UTC)
  •   Oppose.--Arbnos (talk) 21:50, 23 December 2016 (UTC)

Voting (1)Edit


Voting (2)Edit


Voting (3)Edit


Discussion (more)Edit

Moved from #Voting (3)

  Comment@Jura1: Why do they need to be in sync with those properties? Why don't we keep it in sync with the other non-biological godparent (P1290)? Robin van der Vliet (talk) (contribs) 16:14, 13 December 2016 (UTC)
I think you missed the discussion section. We discussed this above and at Wikidata:Property_proposal/stepparent. Too bad you didn't comment there and opened yet another "voting" section.
--- Jura 16:33, 13 December 2016 (UTC)
I didn't open the new voting sections, Pasleim did. I replied at the other discussion. Robin van der Vliet (talk) (contribs) 17:55, 13 December 2016 (UTC)

The brother-sister gender neutralization has removed all brothers and sisters from the biographical infoboxes of the Norwegian wikipedia. Please have this in mind if the gender of parents will be neutralized as well. Orf3us (talk) 12:21, 12 January 2017 (UTC)

@Robin van der Vliet: Asking "why" is not makig your proofs more solid, please, try to recognize what Wiki loses with your proposal. No responce to my request could have brought one less vote in favor of your proposal. Regards - Kareyac (talk) 05:27, 13 January 2017 (UTC)