Property talk:P26

From Wikidata
Jump to: navigation, search

Documentation

spouse
the subject has the object as their spouse (husband, wife, partner, etc.). Use "partner" (P451) for non-married companions
Description The spouse (husband/wife) of a person. For people not married, rather use unmarried partner (P451) ("partner").
Represents spouse (Q1196129)
Has quality description for novalue (Q28343326)
Data type Item
Template parameter "spouse(s)" in w:Template:Infobox person
Domain
According to this template: person
According to statements in the property:
fictional character (Q95074), person (Q215627), human (Q5) and mythical character (Q4271324)
When possible, data should only be stored as statements
Allowed values person (note: this should be moved to the property statements)
Example Pierre Curie (Q37463)Marie Curie (Q7186)
Marie Antoinette (Q47365)Louis XVI of France (Q7732)
Louis XVI of France (Q7732)Marie Antoinette (Q47365)
Jacqueline, Countess of Hainaut (Q467007)John, Dauphin of France, Duke of Touraine (Q1685961), John IV, Duke of Brabant (Q1335790), Humphrey of Lancaster, 1st Duke of Gloucester (Q447541) and Frank van Borssele (Q351161)
Galileo Galilei (Q307) → not applicable
Peter (Q33923)wife of St. Peter (Q22340337)
Robot and gadget jobs DeltaBot does the following jobs: The consistency check gadget (see code) checks if the linked objects are linking back to the analyzed page (mutual/reciprocal relations), but does currently not discover if links are missing from the analyzed page to objects that are linking to it.
Tracking: same no label (Q42533263)
Tracking: usage Category:Pages using Wikidata property P26 (Q21037839)
See also unmarried partner (P451), sidekick of (P2546)
Lists
Proposal discussion Property proposal/Archive/1#P26
Current uses 78,986
[create] Create a translatable help page (preferably in English) for this property to be included here
Conflicts with “instance of (P31): Wikimedia disambiguation page (Q4167410), family name (Q101352), Déjame given name (Q12308941), female given name (Q11879590), unisex given name (Q3409032), given name (Q202444), year (Q577): this property must not be used with listed properties and values.
List of this constraint violations: Database reports/Constraint violations/P26#Conflicts with P31, hourly updated report, SPARQL
Symmetric property: if [item A] has this property linked to [item B], then [item B] should also have this property linked to [item A].
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P26#Symmetric, SPARQL
Type “fictional character (Q95074), person (Q215627), human (Q5), mythical character (Q4271324): element must contain property “instance of (P31)” with classes “fictional character (Q95074), person (Q215627), human (Q5), mythical character (Q4271324)” or their subclasses (defined using subclass of (P279)).
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P26#Type Q95074, Q215627, Q5, Q4271324, SPARQL
Item “sex or gender (P21): Items with this property should also have “sex or gender (P21)”.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P26#Item P21, SPARQL
Qualifiers “start time (P580), end time (P582), end cause (P1534), place of marriage (P2842), series ordinal (P1545): this property should be used only with listed qualifiers.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P26#Allowed qualifiers, SPARQL
Value only: this property can only be used in value (not qualifier or source).
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P26#Value only, SPARQL
Contemporaries:
if [item A] has this property (P26) linked to [item B],
then [item A] and [item B] have to coincide or coexist at some point of history.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P26#Contemporary, SPARQL
Pictogram voting comment.svg Spouse dies before person is born

Violations query: SELECT ?item ?spouse WHERE { ?item wdt:P26 ?spouse . ?item p:P569/psv:P569/wikibase:timeValue ?birth . ?spouse p:P570/psv:P570/wikibase:timeValue ?death_of_spouse . FILTER (?birth > ?death_of_spouse) }
List of this constraint violations: Database reports/Complex constraint violations/P26#Spouse dies before person is born
Pictogram voting comment.svg Person dies before spouse is born

Violations query: SELECT ?item ?spouse WHERE { ?item wdt:P26 ?spouse . ?item p:P570/psv:P570/wikibase:timeValue ?death . ?spouse p:P569/psv:P569/wikibase:timeValue ?birth_of_spouse . FILTER (?death < ?birth_of_spouse) }
List of this constraint violations: Database reports/Complex constraint violations/P26#Person dies before spouse is born
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Former spouses[edit]

How can we handle former spouses? -- Faux (talk) 23:01, 17 February 2013 (UTC)

See: Wikidata talk:Property proposal#Tracking historic data. --Kolja21 (talk) 01:10, 18 February 2013 (UTC)

Deutsche Übersetzung (German Translation)[edit]

Ich würde als Übersetzung Partner oder Gatte vorschlagen, da es ja rein theoretisch auch eine (eingetragene) Partnerschaft betreffen kann. --Faux (talk) 22:03, 18 February 2013 (UTC)

Q12702170 : Q2257644[edit]

Не могли быть мужем и женой. Или годы жизни неверны. (???)--Пробегающий (talk) 10:28, 18 May 2013 (UTC)

Qualifier for type of spouse?[edit]

The property is also used on items for Chinese emperors. Should there be some qualifier to differentiate among the various "wifes"? Should some use Property:P451? --  Docu  at 07:10, 19 May 2013 (UTC)

Change to "Spouse or Partner"[edit]

Since spouse implies marriage in english should this property be Spouse or Partner rather than just spouse or should a new property of Partner (in a non-business sense) be created, since Partner by itself maybe confused with business partner it might make more sense to include it as part of this property. Jared Zimmerman (talk) 08:16, 6 January 2014 (UTC)

No need to label this as "spouse or partner", spouse is enough. The definition of spouse can be found here: Spouse. We can't practically include all words in property labels. Alternative words and labels should be in the description and alias. Danrok (talk) 13:30, 11 January 2014 (UTC)
@Danrok, I think the problem might be that spouse (P26) ≠ Partner and "cohabitant" ≠ Partner maybe we just need to change the property description on spouse (P26) to be clearer or more inclusive?
Jared Zimmerman (talk) 23:45, 11 January 2014 (UTC)
This situation is always going to be problematic. Relationships and family aren't easily nailed-down as hard data. These things are subjective concepts which change over history, and differ around the world. Danrok (talk) 00:59, 12 January 2014 (UTC)
Danrok is your suggestion "its difficult so we aren't going to try to improve it?" I'm not sure I follow.
Jared Zimmerman (talk) 01:27, 12 January 2014 (UTC)
Well, there's certainly room for improvement. To me, a "cohabitant" is exactly that, someone who lives in the same home as you, your housemates. So, not necessarily a live-in lover. Danrok (talk) 02:34, 12 January 2014 (UTC)
Danrok ok so do you think a new property is in order? If you're opposed to spouse (P26) being repurposed to include an unmarried significant others "partner" then I think we'll need a new property since unmarried partner (P451) isn't correct for this use case.
Jared Zimmerman (talk) 02:48, 12 January 2014 (UTC)
My thoughts are that there should be a single property for spouse which includes all types of spouse (married or not). But, I have no idea on how this works across all cultures. This is probably one for Wikidata:Requests_for_comment. Danrok (talk) 03:08, 12 January 2014 (UTC)
✓ Done https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Scope_of_spouse_(P26)_and_cohabitant_(P451)


List of people with 3 spouses and more[edit]

Based on Wikidata items: List of people with 3 spouses and more. --- Jura 10:23, 31 May 2015 (UTC)

Is w:Domestic partnership in the range of this property?[edit]

Are people being in domestic partnership in the range of this property? There are quite a lot of people in this case in Freebase. Tpt (talk) 22:02, 14 July 2015 (UTC)

@tpt: - I think that would be a subclass of ("would be in the range of") Property:P451, as the English article explicitly states that the partners aren't married. - cycŋ - (talkcontribslogs) 10:13, 27 August 2015 (UTC)

no value[edit]

Is "no value" a valid value? Does it mean that the person was never married?--Strainu (talk) 21:08, 26 August 2015 (UTC)

Yes.
--- Jura 15:01, 17 January 2016 (UTC)

Use in polygamous context[edit]

In pre-contemporary spouses would be classified as "first spouse", etc., with some form of internal hierarchy. How about using type of kinship (P1039), and using the preferred rank for those who have a higher, uh, rank. Example here. --Zolo (talk) 17:33, 20 September 2015 (UTC)


Divorced couples[edit]

Statements for former spouses will generally have a qualifier "end time" (P582, with the actual date or "somevalue") and possibly "end cause" (P1534). Rank of the statement should be "normal", not "preferred" or "deprecated".
--- Jura 17:36, 7 February 2016 (UTC)


Preferred rank for current spouses?[edit]

If there are a series of population numbers, generally preferred rank is used to indicate the most recent ones. This greatly faciliates retrieval from possibly dozens or hundreds of numbers from Wikidata.

If a start date for a spouse (P26) is set without an end date, sometimes preferred rank is used to do the same. The result is that in SPARQL, wdt:P26 wont retrieve spouses that have normal rank. Currently about 1% use this (about 600 of 61300 statements). This can lead to the surprising results discussed at Wikidata_talk:SPARQL_query_service/queries#Spouses_of_Madonna.

Most infoboxes at Wikidata display all spouses, not just the current one.

Given the above, I'd suggest not to use "preferred rank" for current spouses. @Jobu0101, Laboramus, Jheald:
--- Jura 07:07, 8 February 2016 (UTC)

Symbol oppose vote.svg Oppose: We have a concept in Wikidata how to store data. I don't think it is a good idea to store data in a different way because of query issues. In such cases we have to adapt the query language and not the data itself. But in your case no adaption is necessary. Fortunately, SPARQL can already handle different ranks: German chancellors with spouses --Jobu0101 (talk) 08:13, 8 February 2016 (UTC)
Good to hear that our advice worked out for you and you got the query to work. I took the liberty to condense the formatting of the query as it somehow obscured the subject of the discussion with chancellors.
What do you refer to with "a concept in Wikidata how to store data"? Is there a specific support you have in mind? I don't think there is anything related to spouses otherwise we wouldn't have had the misleading query on the samples page and I wouldn't have had to fix that many "deprecated rank" used for former spouses.
--- Jura 09:39, 8 February 2016 (UTC)
Symbol oppose vote.svg Oppose Preferred rank AFAIK means current situation, actual data. So it only makes sense that current actual spouse (the person that the other person is married to) is preferred. If you ask somebody "who is your spouse" that's what they'd answer. That's why it is preferred. Of course, this question theoretically could also mean "who are all your spouses you have ever had" - and then you'd use all ranks. wdt:P26 has nothing to do with it, you can use p:P26/ps:P26 anytime you like. --Laboramus (talk) 08:47, 10 February 2016 (UTC)
Symbol oppose vote.svg Oppose changed my mind. ;)
--- Jura 07:58, 9 September 2017 (UTC)
Pictogram voting comment.svg Comment working on kinship equivalent in SPARQL at Wikidata (P4316), I'm less convinced that preferred rank is that useful. It complicates a lot of definitions.
--- Jura 21:21, 18 October 2017 (UTC)

Place of marriage[edit]

Some statements use, in addition to "start date" and "end date", the "location" as a qualifier. This isn't meant to indicate where the spouses lived, but to the place of the marriage ceremony. I don't think this is ideal as "location" is meant to apply to the entire statement, not just the start date. I'm not quite sure which alternate solution to suggest.
--- Jura 07:23, 8 February 2016 (UTC)

I'm not sure this is the right thing, as "marriage" as a state of being married and "marriage" as a ceremony are two different things. If it's really important to have marriage ceremony location, maybe have a property that explicitly says "marriage ceremony location" and add it to spouse as a qualifier? Or, if the marriage is so notable, have an item for it with date, location, etc.? --Laboramus (talk) 08:50, 10 February 2016 (UTC)
@Laboramus: Proposal at Wikidata:Property_proposal/Person#Place_of_marriage.
--- Jura 11:27, 17 April 2016 (UTC)

Values for end cause (P1534) qualifier[edit]

I created death of spouse (Q24037741).
--- Jura 21:10, 8 May 2016 (UTC)


Preferred rank and dead people[edit]

#current result: 13 items, e.g. [[Q2518]]
SELECT  ?item ?itemLabel
{
  	?item p:P26 ?statement .  
 	?statement wikibase:rank wikibase:PreferredRank .
	?item wdt:P570 []
}
LIMIT 100

Try it!

Once a person dies, I think the "preferred rank" for the current spouse should be set back to Normal, even if there is no end date. @Laboramus:.
--- Jura 18:23, 18 September 2016 (UTC)

I think my bot (PreferentialBot) does not touch ranks for dead people, but it also doesn't reset them. If there's consensus on doing it this way, the bot can be made to reset ranks for dead people, but of course decision has to be made per-property. --Laboramus (talk) 20:21, 23 September 2016 (UTC)
Also, if there is only one spouse, wdt: would return it no matter the rank, and you will have to check end time (P582) in any case. Not sure there's a way around it. Laboramus (talk) 21:56, 8 September 2017 (UTC)
@Laboramus: I don't see how this one could be problematic, would you add it?
--- Jura 21:23, 18 October 2017 (UTC)

Known to have been married, identity of spouse unknown[edit]

How do we deal with this situation?--Pharos (talk) 20:06, 14 January 2017 (UTC)

  • By adding a statement with unknown value? In the property documentation template there is a link "Items with unknown value claims" that lists some.
    --- Jura 23:53, 14 January 2017 (UTC)

Constraint on dates[edit]

Hoi, in my opinion this constraint is problematic particular in historic cases where we are happy to know a spouse but where dates are extremely unreliable. Having this constraint is too much. The notion that it is rare is based on what? Thanks, GerardM (talk) 10:09, 24 November 2017 (UTC)

Constraint violation where "no value" added[edit]

This property is showing a constraint violation of "start date needed" where a 'no value' is used. Is there a means to correct this statement from being a violation?  — billinghurst sDrewth 01:11, 29 November 2017 (UTC)

@99of9: you added the mandatory constraint, and I don't see that discussion here.  — billinghurst sDrewth 01:15, 29 November 2017 (UTC)