Property talk:P1039

Documentation

kinship to subject
qualifier of "relative" (P1038) to indicate less usual family relationships (ancestor, son-in-law, adoptions, etc). Indicate how the qualificator item is related to the main item.

Description

use together with the property "non-direct relative" (see above) to describe non-direct family relationships between members and when the intermediary family members are unknown or irrelevant. The type of kinship is with respect of the relative (P1038) (relationship) to the person item on the page where added (see example).

Represents

kinship (Q171318)

Data type

Item

Domain

person (note: this should be moved to the property statements)

Example

According to this template: Moulay Ali Cherif (Q3050987) (1589-1659) <relative (P1038)> Al Hassan Addakhil (Q4703997) (fl. 13th century) with the qualifier kinship to subject (P1039) => ancestor (Q402152)

According to statements in the property:
Indira Gandhi (Q1149) → daughter-in-law (Q18489480)
René Descartes (Q9191) → niece (Q3403377)

When possible, data should only be stored as statements

Robot and gadget jobs

DeltaBot does the following jobs:

Move source to qualifier

Which direction? edit

Latest comment: 5 years ago5 comments5 people in discussion

This qualifier property has room for confusion. With relative (P1038) whould kinship to subject (P1039) refer to what the object is to the subject (the item) or the other way round: what the subject is to the object. I have taken it to be the former case, so when it is stated on Hans Jensen (Q22808000) with relative (P1038) and kinship to subject (P1039) set to grandchild (Q3603531) I mean that Emmerik Jensen (Q22810614) is the grandchild of Hans Jensen (Q22808000). — Finn Årup Nielsen (fnielsen) (talk) 10:51, 20 February 2016 (UTC)Reply

@Micru: you created the property. I agree with Fnielsen that the direction of the relationship is ambiguous. Can you please qualify this so their is clarity whether the relative qualifier is from the perspective of the page item, or whether it is the relative themself. For example, add person is the father-in-law, or the item occurs on the page of the father-in-law. Thanks. — billinghurst sDrewth 13:19, 29 October 2016 (UTC)Reply

I added dates to the sample. Should make it clear.
--- Jura 13:28, 29 October 2016 (UTC)Reply

@billinghurst: I would use whatever the person would say of his/her relative. If the person would say "person X is my aunt", then I would translate it as "type of kinship:aunt". Other properties like "brother", "sister", "father", etc. follow the same format.--Micru (talk) 11:21, 5 November 2016 (UTC)Reply

I also do believe that this property is prone to errors; like many Wikidata properties where nothing indicates clearly in a RDF point of view, if the modified item is the subject or the object of the triplet. Would it be possible to display under the property: X is grandfather of Y (where X is the modified item). – The preceding unsigned comment was added by Hopala! (talk • contribs) at 15:25, 18 September 2018 (UTC).Reply

Proposal for simplification: consistency, gender-neutrality and age-neutrality edit

Latest comment: 6 years ago19 comments9 people in discussion

Currently some relations are stored with a gender (brother (Q10861465), half-sister (Q2920422)), some with a relative age (younger sibling (Q28466210), elder sibling (Q28466211)), some with both (younger sister (Q10943095), elder paternal uncle (Q10885666)) and some are stored without gender and age (great-grandparent (Q2500619), ancestor (Q402152), cousin (Q23009870)). I think it would be better if we would make this system consistent. I worked on this before, but I was told it would be a good idea to reach consensus first.

Currently there is also no argument against creating and using items like "younger male cousin", "elder paternal half-brother", "younger step-sister", etc.

I propose to convert all relationships to gender-neutral and age-neutral relationships, because age and gender are already stored in the person items, so storing it twice is unnecessarily, redundant and error-prone. This would be a task for a bot, which should also keep doing this in the future, to keep everything consistent. Before removing gender information, the bot should first check if the subject item has sex or gender (P21), if it doesn't have it it should add it as to not lose data. The bot shouldn't remove "younger" or "elder" relationships if both items don't have date of birth (P569), otherwise data would be lost.

The following properties are already gender-neutral and age-neutral for this reason: stepparent (P3448), godparent (P1290), spouse (P26), unmarried partner (P451) and child (P40).

If we use gender-neutral items, we make the system easier for Wikipedias that want to use Wikidata. Wikipedias can theirself decide what kind of information (gender, age, etc.) they want to show. For example, take a look at this item Kim Kardashian (Q186304) and the linked French article. The Wikidata item only contains 4 half-siblings, but the French Wikipedia shows the gender for all 4 half-siblings. It uses male form of label (P3321) and female form of label (P2521) in half-sibling (Q27965041) to do this. Robin van der Vliet (talk) (contribs) 14:57, 12 February 2017 (UTC)Reply

Discussion edit

Strong support For the reasons mentioned above. Robin van der Vliet (talk) (contribs) 14:57, 12 February 2017 (UTC)Reply
Support. Sounds good to me. ~★ nmaia ^d 15:47, 12 February 2017 (UTC)Reply
Oppose I have no issue with age neutral. I do have issues with gender neutral. To note that there was already a similar conversation in a proposal in a RFD, and I do not believe that there was the consensus for the change. — billinghurst sDrewth 23:45, 19 February 2017 (UTC)Reply
- @billinghurst: Why do you have a problem with gender-neutrality and not with age-neutrality? Wikidata is a project for everybody, not just Europeans. Do you think we also need "male cousin" and "female cousin"? Can you send me the link to the previous RFD, I don't remember seeing it. Robin van der Vliet (talk) (contribs) 00:28, 20 February 2017 (UTC)Reply
  Trying to remember where it is, it was indirect discussion, so I cannot remember whether it was a property creation request to replace something in the relative or kinship component; or whether it was a broader conversation in project chat. I have been looking but time is against me at the moment. — billinghurst sDrewth 00:50, 20 February 2017 (UTC)Reply
  
  Re commentary. For the male cousin and female cousin, I have no issue; whereas maternal cousin or paternal cousin are different; both are gender-related, whereas your proposal was about degendering 'full stop'. In many numbers of historical works there is mention of relationships of people, be that maternal step-father, paternal grandmother, or maternal grandmother, etc. This sourced accuracy should be recorded rather than blandly washed away due to some convenience that a superquery may be generated by one of the wikipedias. [I will note that not all the wikis have that skill-set to generate those queries and distinctions]. Sometimes works will specify that Person A had four brothers, with no mention of sisters (as deemed unimportant in that male hierarchical system) so to record something as 4 siblings is inaccurate. By the way have you consulted with local projects like the genealogy project about what is required with their data? I could see that you are proposing to remove that ability to link.
  I have no issue with consistency, where there are errors or misuse should be more looking to fix the issues around the data entry; we should be given greater guidance; put in measures to stop unuseful relationships; removing gender-related is whitewashing data, and whitewashing sources; that is not our role, our role is to reflect the sources. Where they are stored with missing information, that is the nature of WD, many items are lacking full information, and it is our role to populate that information, not look to move down to the lower/lowest common denominator. We can only do what the sources give us. — billinghurst sDrewth 01:46, 20 February 2017 (UTC)Reply
  
  @billinghurst:
  
  "whereas maternal cousin or paternal cousin are different"
  
  I meant "male cousin" and "female cousin", the actual genders of the cousins. I didn't propose to remove "paternal" and "maternal" relationships and removing that information, since that is information not stored in the target item. I proposed to remove the gender of the relationship, since it is already stored there.
  
  "so to record something as 4 siblings is inaccurate"
  
  Storing it like that isn't inaccurate, because all the items would still contain the following statement to store the gender:
  ⟨ subject ⟩ sex or gender (P21) ⟨ male (Q6581097)    ⟩
  
  "This sourced accuracy should be recorded rather than blandly washed away"
  
  If a news source uses the sentence "his German cousin" (11,600 results), should we then create an item called "German cousin", which would be a subclass of Germans (Q42884) and cousin (Q23009870)? What about "his older cousin" (90,300 results), it is even more popular on Google? I suppose we should then, instead of blandly washing away a sourced accuracy... Why is gender so important, when nationality and age are not?
  
  Gender, nationality and age are all things that should only be stored in the property. This property should only record the kind of relationship, not some random properties about the subject.
  
  Robin van der Vliet (talk) (contribs) 02:08, 20 February 2017 (UTC)Reply
  Be wary with examples as a german-cousin has nothing to do with a German cousin. Such a relationship is often mentioned in biographical works and I would expect that to be mentioned.
  With regard to gender-less relationships, direct relationships should always have gender. Maternal grandmother and maternal grandfather should be explicit, as was determined for father and mother. It is simply too much work to have to dig for gender when the explicit and clear relationship exists. — billinghurst sDrewth 03:48, 21 February 2017 (UTC)Reply
  
  addendum. No where have I said that nationality was pertinent; I believe that in my first statement that I said that age neutrality was okay. So please don't foist those arguments to present your case. The genealogical information is important, and the more that it is neutered, or harder to reference, the harder it becomes to withdraw, or check when visiting items. The loss of "brother/sister" converted to sibling means that on one example where family member names had non-overt gender, I had to open some of the names to do the count and gender matching. Sure that was unusual, but it is a consequence of these "simplification" measures. — billinghurst sDrewth 04:08, 21 February 2017 (UTC)Reply
Support seems a very good idea. Lotje (talk) 05:11, 20 February 2017 (UTC)Reply
Mild Oppose. The proposer assumes that "age and gender are already stored in the person items", but for data about historical people, we cannot assume we know their date of birth. All we may know may be the relative order of the siblings. Jheald (talk) 09:15, 20 February 2017 (UTC)Reply
- @Jheald: It is of course not my intention to lose data. Before removing gender information, it should add sex or gender (P21) to the subject if it is not already there. And it should also only remove "younger"/"older" if both items have date of birth (P569). I expanded on this part in the proposal. What do you now think of it? Robin van der Vliet (talk) (contribs) 15:28, 20 February 2017 (UTC)Reply
  I can see that without dates of birth that we can use "serial ordinal" thought that presumes that one of the parents is within the system. So how would you be looking to describe little Johnnie, the youngest of five brothers, and his eldest brother Edward, and brother of William (otherwise noted)?
  If this proposal is to be clear then there will need to be examples and a described mapping of what is expected. It is a bit of an open book proposal at this time. It will also be needed to have a reproducible continuance of the schema. — billinghurst sDrewth 03:57, 21 February 2017 (UTC)Reply
  - Yeah, a use case would be good to see.
    I tend to agree with billinghurst/sDrewth about the "German" cousin question: if a reference mentions one as such, a corresponding statement should reflect this with relative (P1038). As already noticed on Property talk:P3373, there may be some language barrier involved: What might be para-phrased in English with (e.g.) "his older cousin" might match a precise term in some other language source.
    If the family tree is available on Wikidata (and it doesn't involve much uncertainty), I don't see a point in adding relative (P1038).
    --- Jura 12:56, 25 February 2017 (UTC)Reply
Support age neutral, but Oppose gender neutral. I dislike "or" labels (like "grandmother or grandfather"). English language has haks like "grandparent", but another languages have no gender-free terms. Also using more specific classes is preferred. — Ivan A. Krestinin (talk) 14:03, 2 April 2017 (UTC)Reply
- That is biased to certain languages, certain languages have gender-free terms, but no age-free terms. Why should we favor certain kinds of languages? Robin van der Vliet (talk) (contribs) 20:11, 21 May 2017 (UTC)Reply
  - I agree to the bias argument! --Marsupium (talk) 11:52, 29 August 2017 (UTC)Reply
Strong support. This proposal would simplify the current system and make it more consistent. Mushroom (talk) 15:11, 1 July 2017 (UTC)Reply

nephew/niece in Chinese/Japanese edit

Latest comment: 6 years ago4 comments2 people in discussion

I noticed that nephew (Q15224724) has the same labels in Chinese and Japanese (甥), as well as niece (Q3403377) (姪). Although both languages use the same sinograms (Q8201)/kanji (Q82772), the meanings are actually different. In Japanese, 甥 (おい) means a son of one's sibling. However, in Chinese 甥 means a child of one's sister, or more specifically a son of one's sister (in such case 甥女 means a daughter of one's sister). Similarly, in Japanese 姪 (めい) means a daughter of one's sibling, but in Chinese 姪 means a child of one's brother or more specifically a son of one's brother (in such case 姪女 means a daughter of one's brother).

I'm wondering how should we deal with this? I find that the definitions in Japanese are in line with other languages. So should we create new items for the Chinese definitions? --Stevenliuyi (talk) 09:45, 10 January 2018 (UTC)Reply

There are a series of different relationship terms at Wikidata:WikiProject Parenthood/lists/kinship types. If you set the interface language to Chinese or Japanese, the yellow column will show the terms/definitions in these languages. The column before is the same in English. Please help correct them if needed. If there are relationships terms that are missing, don't hesitate to create new items for these. We can then try to complete the other info.
--- Jura 09:56, 10 January 2018 (UTC)Reply

Thanks. I found that the definitions in Chinese are actually sororal niece or nephew (Q28017470) and fraternal niece or nephew (Q28017469). So I moved the pages from Chinese wikipedia to those items, and updated corresponding labels (as well as the labels in sororal nephew (Q23045234), sororal niece (Q23045293), fraternal nephew (Q23045211) and fraternal niece (Q23045278)). Please let me know if there is any issue.--Stevenliuyi (talk) 11:11, 10 January 2018 (UTC)Reply
- It looks like we are moving ahead in a complicated field. The discussion on User_talk:Yejianfei helped sort out some of the other issues we had with Chinese terms.
  --- Jura 11:41, 10 January 2018 (UTC)Reply

Großvater / Großmutter väterlicherseits/mütterlicherseits edit

Latest comment: 3 years ago8 comments4 people in discussion

Solange es keine entsprechenden Properties gibt, kann das hier nicht als Fehler angemerkt werden. --Bahnmoeller (talk) 06:36, 9 July 2019 (UTC)Reply

Grandfather is not the same as father. --Bahnmoeller (talk) 09:47, 9 July 2019 (UTC)Reply

The idea is that you add the the value for the father and then, on the item for the father his father.
Why would you want to start adding grandparents on people's items? If you re-read the proposal discussion, you will notice that this property wasn't meant for that. As the constraint is a "suggestion contraint", there can occasionally be exceptions (i.e. parents aren't known). --- Jura 09:50, 9 July 2019 (UTC)Reply

So the father / mother are not notable and they are to be included because of what? Thanks, GerardM (talk) 09:50, 29 September 2019 (UTC)Reply

I had to remove that constraint because of the afore-mentioned problem: more often that not, parents are not notable, so no items to be linked to. And it was triggering a constraint violation warning even though it was only a "suggested" one. Andreasm ^{háblame / just talk to me} 03:07, 6 February 2020 (UTC)Reply

It doesn't really matter if they are notable or not. The question is if they are known. --- Jura 04:56, 6 February 2020 (UTC)Reply

The items for the parents should be created so they can be linked from both their children and the grandparents. →structural need --- Jura 05:01, 6 February 2020 (UTC)Reply

I strongly oppose. Wikidata should keep records of all person ever borne. At least some standards of notibility should be kept. --Bahnmoeller (talk) 07:57, 31 May 2020 (UTC)Reply

Grandson - Granddaughter - in German both are Enkel edit

Latest comment: 3 years ago1 comment1 person in discussion

Same argument as above - further problem Q42302425 ist not recognized as counterpart of Q4994791 --Bahnmoeller (talk) 08:06, 31 May 2020 (UTC)Reply

Sister edit

Latest comment: 4 years ago1 comment1 person in discussion

Hoi, why have a brother and not a sister.. Not obvious at all why. Thanks, GerardM (talk) 15:03, 27 September 2019 (UTC)Reply

Add topic