Predicate Proposal - Spouse

Value statement: allowing multiple entries for predicate “Spouse” is necessary for a “Person” (at the moment they are not allowed) because he or she (“Person”) might have different spouses during their life. Probably it would be best to allow “string” type of entries because it is not guaranteed that by the moment of editing will be available URL-type of entry at Golden for this “spouse” predicate.

Definition: Significant other in a marriage (husband, wife, partner). Can be URL leading to Golden page of the person or a “string”-type if no Golden page for the person exists.

Tooltip definition of the predicate : “Significant other in a marriage (husband, wife, partner)”

Type of value : Entity

Number of values accepted: multiple

Usage in other schemas :

Examples of proper use :

Citation Required? : Yes

2 Likes

Looks good!

I know that @leeds may want to comment on this specifically on how we would both provide multiple values for ‘spouse’ but also be able to indicate ‘current spouse.’

Also I am thinking it might be good to provide an Example of improper use with an unmarried partner to emphasize that this is for partners in marriage. For example:

Oprah Winfrey → Spouse → Stedman Graham
would be improper use as Stedman Graham is an unmarried partner.

1 Like

Agree with @jen’s suggestion to further clarify that a spousal relationship is based off marital status in this definition.

how we would both provide multiple values for ‘spouse’ but also be able to indicate ‘current spouse

This is a case for a qualifier that we should think about - I would think just using valid time to show what spousal relationships have ended/are still continuing would work well here.

1 Like

@DontYouWorry I would propose we require the type of value to be entity - while it’s true there may be some friction in requiring a spouse to be an entity,

  1. marking a spouse as an entity allows the value to be dynamic (what if the spouse changes their name?)
  2. this further links the graph, ie it forms a relation between person A and person B that may be generally valuable
  3. if ‘person A’ → ‘spouse’ → ‘person B’, we can’t mark the inverse (that ‘person B’ → ‘spouse’ → ‘person A’)

Citation Required? : No

@DontYouWorry do you think it would be difficult to provide a citation? I think providing a citation here will make validation significantly easier, enhance the quality of the data, and generally be valuable.

@leeds Yes, I think it could be difficult to provide a valid citation, because apart from providing the certificate of marriage (which would be just impossible) we don’t have a lot of options. Maybe we could consider some interviews or newspaper articles about marriage as a valid source of citations. I’m not sure about that.

I agree that providing a citation would be much easier for validation, and was almost going to suggest this yesterday as well. It would be a bit of a burden on the validator to confirm especially recent spouses.

But I agree with @DontYouWorry that it might be hard to track down a valid source both for marriage as well as divorce.

I took a further look, though, it seems like it may be possible but we would want to indicate for citation either:

  1. official account of person.
    ex. for Lance Armstrong, official Instagram post:

https://www.instagram.com/p/ChClqO4uCps/?utm_source=ig_web_copy_link

  1. Trusted news source (may need further definition) rather than gossip site
    ex, Jennifer Lopez and Ben Affleck
    Jennifer Lopez and Ben Affleck are officially married - CNN
    ex. Bill and Melinda Gates (divorce)
    https://www.cnbc.com/2021/08/02/bill-and-melinda-french-gates-are-officially-divorced.html
1 Like

@leeds Yes, I agree that entity type would be more useful in terms of links in graph, I actually meant Golden “entity” when said ‘url’. But what if a spouse is not a public person at all ? Should we create an entity for her/him just for the purpose of marking her/him as a “spouse” for someone ?
Considering changing the name - what is the best practice we should abide here ?

@jen ye, I think it’s a good idea

Any person that is canonically known to be the spouse of someone who exists in the graph is appropriate to create a ‘person’ entity for. We want to grow the number of people we support in the graph to be far larger than it is today.

Considering changing the name - what is the best practice we should abide here ?

If we change the type of value to be just ‘entity’ in the proposed definition, the name changes will populate to the object of the ‘spouse’ predicate automatically.

I would strongly recommend we change the type of value to be just ‘entity’ in the proposed definition - would you agree with the arguments above on why that’s beneficial? If so, it’d be great if you could change that part of the proposal.

1 Like

@DontYouWorry - thanks for submitting this! I particularly appreciate identifying the relevant Wikidata property that aligns with this, too.

I just want to echo my support for the points above:

  • Data type = Entity, so that it can be incorporated into the larger knowledge graph
  • Citation = required. But those citations can come from news reports, government documents, a person’s own announcements, etc.
  • Number of values = This is a case where when we can have qualifiers on a given statement, this can be limited to one (instead of multiple). But frankly, there may be cases where an individual has (or has historically had) more than one legal spouse… so I think multiple may be okay to start off with here.
1 Like

for some reason I don’t see an option to edit my initial post, so I just type the edited proposal here

Value statement: allowing multiple entries for predicate “Spouse” is necessary for a “Person” (at the moment they are not allowed) because he or she (“Person”) might have different spouses during their life. Probably it would be best to allow “string” type of entries because it is not guaranteed that by the moment of editing will be available URL-type of entry at Golden for this “spouse” predicate.

Definition: Significant other in a marriage (husband, wife, partner). Can be URL leading to Golden page of the person or a “string”-type if no Golden page for the person exists.

Tooltip definition of the predicate : “Significant other in a marriage (husband, wife, partner)”

Type of value : Entity

Number of values accepted: multiple

Usage in other schemas :

Examples of proper use :

Citation Required? : Yes

1 Like

@leeds, @jed, @jen Thank you guys for important improvement suggestions !

thanks - edited the initial proposal

1 Like

We should have a sub-category for different types of relationships for Spouses.

Citation would be easy if we make certain rules on how we will consider such things, here are some example:

Domestic partnership - Any source that confirms that the two persons are living together
Married - Any source that confirms church or civil wedding.

There should also be a “start” and “End” date for these relationships.

Lastly, girlfriends and boyfriends should not be allowed to be entered here.

If the event where we can’t find any citation, then we can’t add the information to our system.

There should also be a “start” and “End” date for these relationships.

Yes - a broader ‘valid time’ qualifier will serve to capture the start and end time.

Lastly, girlfriends and boyfriends should not be allowed to be entered here.

@DontYouWorry could we specify in the ‘Definition’ what a marriage means briefly? An example of improper usage with a couple that isn’t married would also be helpful.

I believe there’s an opportunity here to include a separate predicate (like “Domestic Partner”) to indicate committed relationships of people that aren’t married.

Certainly on Wikipedia pages you’ll often see both “Spouse” and “Partner”…

Then isn’t it easier to take this data from social networks? Friends and Friends of friends?? what is the speed of changing this data and updating in Golden?

Very good point - something like a Domestic Partner might change frequently enough (and without public data) that it might not make sense to include.