Having gone and written the RFC (https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Merging_relationship_properties) I've just discovered that we *did* have this discussion in 2013:
https://www.wikidata.org/w/index.php?title=Wikidata%3AProperties_for_deletion&diff=44470851&oldid=44465708 - and it was suggested we come back to it "after Phase III". I think the existing state of arbitrary access should be able to solve this problem, so I've added some notes about this. Comments welcome; I'll circulate notifications onwiki tonight. Andrew. On 24 August 2015 at 14:02, Lukas Benedix <[email protected]> wrote: > +1 for genderless family relationship properties. > > Lukas > >> Hi all, >> >> Thanks again for your comments. It looks like: >> >> a) there's interest in simplifying this; >> >> b) creating automatic inferences is possibly desirable but will need a >> lot of work and thought. >> >> I'll put together an RFC onwiki about merging the "gendered" >> relationship properties, which will address the first part of the >> issue, and we can continue to think about how best to approach the >> second. >> >> Andrew. >> >> On 17 August 2015 at 12:29, Andrew Gray <[email protected]> wrote: >>> Hi all, >>> >>> I've recently been thinking about how we handle family/genealogical >>> relationships in Wikidata - this is, potentially, a really valuable >>> source of information for researchers to have available in a >>> structured form, especially now we're bringing together so many >>> biographical databases. >>> >>> We currently have the following properties to link people together: >>> >>> * spouses (P26) and cohabitants (P451) - not gendered >>> * parents (P22/P25) and step-parents (P43/P44) - gendered >>> * siblings (P7/P9) - gendered >>> * children (P40) - not gendered (and oddly no step-children?) >>> * a generic "related to" (P1038) for more distant relationships >>> >>> There's two big things that jump out here. >>> >>> ** First, gender. Parents are split by gender while children are not >>> (we have mother/father not son/daughter). Siblings are likewise >>> gendered, and spouses are not. These are all very early properties - >>> does anyone remember how we got this way? >>> >>> This makes for some odd results. For example, if we want to using our >>> data to identify all the male-line *descendants* of a person, we have >>> to do some complicated inference from [P40 + target is male]. However, >>> to identify all the male-line *ancestors*, we can just run back up the >>> P22 chain. It feels quite strange to have this difference, and I >>> wonder if we should standardise one way or the other - split P40 or >>> merge the others. >>> >>> In some ways, merging seems more elegant. We do have fairly good >>> gender metadata (and getting better all the time!), so we can still do >>> gender-specific relationship searches where needed. It also avoids >>> having to force a binary gender approach - we are in the odd position >>> of being able to give a nuanced entry in P21 but can only say if >>> someone is a "sister" or "brother". >>> >>> ** Secondly, symmetry. Siblings, spouses, and parent-child pairs are >>> by definition symmetric. If A has P26:B, then B should also have >>> P26:A. The gendered cases are a little more complicated, as if A has >>> P40:B, then B has P22:A or P25:A, but there is still a degree of >>> symmetry - one of those must be true. >>> >>> However, Wikidata doesn't really help us make use of this symmetry. If >>> I list A as spouse of B, I need to add (separately) that B is spouse >>> of A. If they have four children C, D, E, and F, this gets very >>> complicated - we have six articles with *30* links between them, all >>> of which need to be made manually. It feels like automatically making >>> symmetric links for these properties would save a lot of work, and >>> produce a much more reliable dataset. >>> >>> I believe we decided early on not to do symmetric links because it >>> would swamp commonly linked articles (imagine what Q5 would look like >>> by now!). On the other hand, these are properties with a very narrowly >>> defined scope, and we actively *want* them to be comprehensively >>> symmetric - every parent article should list all their children on >>> Wikidata, and every child article should list their parent and all >>> their siblings. >>> >>> Perhaps it's worth reconsidering whether to allow symmetry for a >>> specifically defined class of properties - would an automatically >>> symmetric P26 really swamp the system? It would be great if the system >>> could match up relationships and fill in missing parent/child, >>> sibling, and spouse links. I can't be the only one who regularly adds >>> one half of the relationship and forgets to include the other! >>> >>> A bot looking at all of these and filling in the gaps might be a >>> useful approach... but it would break down if someone tries to remove >>> one of the symmetric entries without also removing the other, as the >>> bot would probably (eventually) fill it back in. Ultimately, an >>> automatic symmetry would seem best. >>> >>> Thoughts on either of these? If there is interest I will write up a >>> formal proposal on-wiki. >>> >>> -- >>> - Andrew Gray >>> [email protected] >> >> >> >> -- >> - Andrew Gray >> [email protected] >> >> _______________________________________________ >> Wikidata mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> > > > > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata -- - Andrew Gray [email protected] _______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
