Wikidata:Property proposal/Number of spouses
Jump to navigation
Jump to search
Number of spouses
[edit]Originally proposed at Wikidata:Property proposal/Person
Not done
Description | specify the number of spouses a person has/had |
---|---|
Data type | Number (not available yet) |
Domain | humans |
Allowed values | Number |
Allowed units | none |
Example | 27 (for Fela Kuti (Q313868)) |
- Motivation
Fela Anikulapo Kuti is a notable Nigerian with 27 wives. I think this is an important piece of information that should be attached to a personality Kayusyussuf (talk) 12:31, 22 January 2017 (UTC)
- Discussion
- @Kayusyussuf: I've attempted to add this information to Fela Kuti (Q313868) using the property spouse, and giving it qualifiers for quantity and gender. Hopefully this may be sufficient, others would know better.--Pharos (talk) 03:59, 23 January 2017 (UTC)
- That would be better with "unknown value" (there isa spouse(s), but we don't know who). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:04, 1 February 2017 (UTC)i
- Oppose The solution that Pharos proposes works. ChristianKl (talk) 16:12, 23 January 2017 (UTC)
- Support Even though I appreciate the workaround provided by @Pharros, I consider it a hack rather than a natural way of storing an Integer. The number of spouses, which in my humble opinion is relevant property, should be added. --African Hope (talk) 01:10, 25 January 2017 (UTC)
- Oppose why not just count the number of spouse (P26) statements that have a value (i.e. not "novalue")? ArthurPSmith (talk) 16:32, 23 January 2017 (UTC)
- @ArthurPSmith, your idea is smart as it provides a dynamic way to display the number of spouses. Yet, in the current situation it would be inconvenient as, if I am not wrong, it would take us to create the 27 spouses items before being able to feature that detail, knowing that some of these spouses might neither be named, nor referenced. We might end up being unable to either show that number or reference it. African Hope (talk) 01:19, 25 January 2017 (UTC)
- Thank you Pharos, I however agree with ArthurPSmith. It is better to have the property 'number of spouses', it qualifies the statement much more that using 'quantity'. I also agree with the gender of spouses. That was very good. Thank you. Kayusyussuf (talk) 20:41, 23 January 2017 (UTC)
- Comment I've also experimented with applying my somewhat hack-y method to Solomon (Q37085), who according to legend had 700 spouses and 300 partners.--Pharos (talk) 03:47, 25 January 2017 (UTC)
- Support A simple, first-order property recording the number makes sense, just like number of children (P1971) does, as distinct from "just counting the number of child (P40) statements." The fact that it can be expressed using a quantity qualifier to a statement without a value doesn't mean that's the most straightforward, intuitive (for query builders), or elegant way to do it. Is there any substantive reason not to add it? Ijon (talk) 07:18, 26 January 2017 (UTC)
- What if we generalize number of children (P1971) to 'number of relations'? Then it could be used for spouses, children, siblings and partners.--Pharos (talk) 17:44, 26 January 2017 (UTC)
- I think that would be inferior to just adding a simple first-order property to express this datum. Requiring people to understand qualifiers every time they want to express number of children seems not as useful a result as just adding this property. I don't see a downside to adding it. Ijon (talk) 03:47, 27 January 2017 (UTC)
- The downside to adding this property is that it's likely to create doublicate data. ChristianKl (talk) 11:10, 27 January 2017 (UTC)
- Support I agree with Ijon. In some culture, it makes much more sense to have this simple first-order data, so if we aim to be inclusive and diverse, this property should be added. Especially so as it does not stand in contradiction to what Pharos suggested; After adding a straight forward "number of spouses", more statements with a property spouse and qualifiers of quantity and gender could then be added to expand and enrich the item. Shani Evenstein (talk) 10:27, 27 January 2017 (UTC)
- @Ijon: What's exactly the claim that you are making? Is it that in some cultures women aren't important enough to have their own items and therefore are getter simply counted? And that out of a respect to those cultures Wikidata should have a Number of Spouses item for them? What cultures are you talking about? ChristianKl (talk) 11:10, 27 January 2017 (UTC)
- @ChristianKl: No, that is most certainly not the claim I was making. I was making a claim that this datum (number of spouses) is every bit as useful as the datum (number of children), quite apart from the (different) data about each individual spouse, just like the data about each individual child. I was further arguing, in response to @Pharos:, that the fact it can be achieved via qualifiers is not a good argument against having it available as a first-order property, again drawing the analogy with number of children (P1971). And I did not bring up culture at all. Your eagerness to assume some cultural agenda is unjustified in this case. Ijon (talk) 21:07, 27 January 2017 (UTC)
- Pharos make the cultural argument, I'm sorry that I pinged you for it. In Wikidata we generally try to avoid having properties that record data that can be automatically calculated. If an individual Wikipedia wants to have a template that lists number of spouses they can easily get that data without Wikidata having a property in which the data is stored. It's worth noting that we also don't have a direct property for a family relationship like grandfather because that's often possible to be calculated. ChristianKl (talk) 21:36, 28 January 2017 (UTC)
- The general principle of preferring calculation to duplication is well and good. However, this property can't be calculated unless, as @African Hope: pointed out, people embrace the (highly-unintuitive) practice of creating 27 spouse (P26) properties with unknown values, to express the simple fact Fela Kuti had 27 spouses. Again, the same logic you are employing to reject this proposed property is applicable against number of children (P1971). We do tolerate that property even though it is in principle just as calculable as this proposed property. I contend there is no serious downside to creating this property, and it would enrich Wikidata much more than waiting for people to figure out they can express this datum by creating unknown-value spouse statements. Ijon (talk) 18:39, 31 January 2017 (UTC)
- Pharos make the cultural argument, I'm sorry that I pinged you for it. In Wikidata we generally try to avoid having properties that record data that can be automatically calculated. If an individual Wikipedia wants to have a template that lists number of spouses they can easily get that data without Wikidata having a property in which the data is stored. It's worth noting that we also don't have a direct property for a family relationship like grandfather because that's often possible to be calculated. ChristianKl (talk) 21:36, 28 January 2017 (UTC)
- @ChristianKl: No, that is most certainly not the claim I was making. I was making a claim that this datum (number of spouses) is every bit as useful as the datum (number of children), quite apart from the (different) data about each individual spouse, just like the data about each individual child. I was further arguing, in response to @Pharos:, that the fact it can be achieved via qualifiers is not a good argument against having it available as a first-order property, again drawing the analogy with number of children (P1971). And I did not bring up culture at all. Your eagerness to assume some cultural agenda is unjustified in this case. Ijon (talk) 21:07, 27 January 2017 (UTC)
- @Ijon: What's exactly the claim that you are making? Is it that in some cultures women aren't important enough to have their own items and therefore are getter simply counted? And that out of a respect to those cultures Wikidata should have a Number of Spouses item for them? What cultures are you talking about? ChristianKl (talk) 11:10, 27 January 2017 (UTC)
- Comment I have an additional concern here - how is this intended to include divorced (or deceased) previous spouses? Would Elizabeth Taylor (Q34851) have this property as 8 (count of number of spouse records) or 7 (two of her marriages were to the same person) or 0 (she was unmarried at the time of her death)? What about common-law "spouses"? What about spouses recognized in one legal jurisdiction but not in another (some gay marriages for instance)? I am not sure this property can be unambiguously defined in a worldwide-suitable fashion. ArthurPSmith (talk) 15:49, 27 January 2017 (UTC)
- All good questions, @ArthurPSmith:. I will again argue by analogy: I am not sure number of children (P1971) can be "unambiguously defined in a worldwide-suitable fashion". Does it include adopted children? How about children of one's spouse but not of one's own who were not legally adopted? These questions are not answered, or even discussed, on the property talk page, and yet it is available and used (presumably applying common sense and one's own judgment) in many items. The same can apply for this proposed property too.
- Substantively, to your questions, I can offer my own suggested answers, but I maintain it the property can be created even before or in the absence of settling those questions, just as number of children (P1971) was.
- My suggested answers are: 1. Yes, it is to include all previous spouses, i.e. to be interpreted as "total number of different people who are/were a spouse to this person", just like occupation (P106) includes all occupations past and present, etc. So Elizabeth Taylor would have 7 spouses (though, in the fully-described case, with 8 spouse (P26) statements, with start/end times, of course). 2. Common-law spouses are spouses, so yes, they are to be included. 3. a spouse recognized in even one (relevant to either of these two persons) jurisdiction should count for this purpose. Ijon (talk) 21:18, 27 January 2017 (UTC)
splitting the following comment for convenience
- There's no number of occuptions property so comparing to occupation (P106) makes little sense. ChristianKl (talk) 10:06, 30 January 2017 (UTC)
- I was comparing to occupation (P106) specifically for the "both past and present" semantics, not because it is a number. Ijon (talk) 18:33, 31 January 2017 (UTC)
- Given that properties can be qualified with start and stop time I would expect some people to interpret this property as being about the number of spouses at a particular time. ChristianKl (talk) 10:06, 30 January 2017 (UTC)
- And yet you are not similarly concerned about how "some people" would interpret number of children (P1971). So I contend we can create this property, too, and trust it would be used as I described in the vast majority of cases (just like most properties are used without qualifiers), and occasionally people would choose to, and be able to, express a person's number of spouses at given stretches of time, using qualifiers, and that would be okay too. Ijon (talk) 18:33, 31 January 2017 (UTC)
- There's no number of occuptions property so comparing to occupation (P106) makes little sense. ChristianKl (talk) 10:06, 30 January 2017 (UTC)
- Oppose From one particular example a specific property is created leading to an uncontrolled properties generation. First it would be good to generalized a little the properties and extend the current property number of children (P1971). I don't want to see all properties doubled with "number of" properties: address, number of address, occupation, number of occupation, citizenship, number of citizenships,... My solution ? Add 27 times the property spouse (P26) with unknown as value and each time put the reference in order to avoid deletion later. Snipre (talk) 21:52, 31 January 2017 (UTC)
- Oppose « simple » properties almost always cause more problems than they solve. spouse (P26) seems more than enough here to store the data. BTW is seems that Fela Kuti hadn't 27 wives, he *married* 27 women in 1978 but he was already married since 1960 so - if I understand correctly - he had 28 wives (and here, spouse (P26) seems easier and more clear to use). Cdlt, VIGNERON (talk) 23:17, 31 January 2017 (UTC)
- Oppose Use Pharos' model, but with "unknown" not "no value". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:04, 1 February 2017 (UTC)
- Oppose This is what qualifiers and "unknown" value are for. -- JakobVoss (talk) 08:45, 2 February 2017 (UTC)
- Oppose We don't have "number of jobs held" "number of government posts held", nor "number of countries lived in" as a property. In fact, if we had those properties we would potentially be storing the data twice: as both a property in its own right and as a count of nodes having the relevant relation. "Number of spouses" is another property of this kind, and unneeded for the same reason. I agree that "unknown" is the appropriate way to code it: "spouse: no value" implies the person never married. MartinPoulter (talk) 15:46, 7 February 2017 (UTC)
- Not done No consensus for creation.--GZWDer (talk) 17:18, 7 February 2017 (UTC)