historical-data / schema

Microdata schema for historical data.
historical-data.org
30 stars 4 forks source link

Add "marriage" to HistoricalPerson? #26

Closed davebarney closed 12 years ago

davebarney commented 12 years ago

Tony Ruscoe (newly added to the project) and I were talking and he pointed out it's a bit awkward to have to create a HistoricalFamily in order to add a marriage when spouses need to be defined in HistoricalPerson instead. Also, parents can be defined as properties of both items.

I suggest we add marriage to the HistoricalPerson.

Objections? Suggestions?

ninjudd commented 12 years ago

I'm not sure I understand the suggestion. Are you suggesting we eliminate HistoricalFamily and store the marriage twice (on each parent)?

ninjudd commented 12 years ago

See #7 for further discussion about HistoricalFamily.

davebarney commented 12 years ago

Ah yes, I remember that discussion. It's a difficult one. I hate to again bring up an issue that has been discussed, but we just want to make sure we have this correct before announcing it publicly at RootsTech next week. I hope it's ok to revisit this one.

It seems to be consistent, if we want to keep HistoricalFamily, then we should eliminate spouses, children, and parents from HistoricalPerson. We define who the spouses are, but we don't provide any way to define a marriage. The family object contains children, which can be assumed to be siblings of each other, but the person object also defines children, parents, and siblings.

For the use case of a page with lots of individuals that all belong to a family, it is concise to have each person object just describe that person's details and then a single family object to show how they inter-relate, but perhaps the more common use case is when a page has information about a single individual with limited information about the family.

ninjudd commented 12 years ago

Agreed. Like I said in #7, if the main use case is showing relationships for a page focussed on a single profile, then there would not be duplication by having the relationships go from person to person. If we want a way to describe inter-relationships between multiple people, then always going through a family object means way less duplication.

I do agree that it is confusing to support both direct relationships between people and relationships through family objects.

ninjudd commented 12 years ago

@NatAtGeni what do you think? I believe currently we are only adding metadata for relationships directly to the focus profile. Is that right?

NatAtGeni commented 12 years ago

Yes, we're only adding metadata for relationships to the focus profile, so we don't have to worry about duplication on a person's profile page. The relationships described as direct relationships aren't terribly descriptive - we don't distinguish between sister, half-sister and step-sister, for example. Instead, we're relying on HistoricalFamily to clarify exactly what those relationships are.

I guess the alternative to listing direct relationships on a focus profile would be to list out the multiple HistoricalFamily objects the person belongs to, along with all the profiles included in each of those families.

ninjudd commented 12 years ago

Hmm. We would probably need to add more descriptive direct relationships if we were going to get rid of HistoricalFamily.

NatAtGeni commented 12 years ago

We definitely would. The direct relationships aren't nearly helpful enough.

tonyruscoe commented 12 years ago

Since I originally raised this issue with Dave, I thought I should add my thoughts.

With the data from one of my ancestors, I was trying to build out a page that incorporates all the records that I have for him and it seemed like it should be unnecessary to create a HistoricalFamily item simply to add his marriage when all other data was already available under HistoricalPerson.

Using the current historical-data.org schema, I could presumably add the marriage as an HistoricalEvent item on either the “events” property of the current person, or their spouse. Or I could add an HistoricalRecord item – but that would require an actual source, which might not be available. The question is then how to specify the spouse for the marriage, but that’s only a problem if there are multiple spouses, otherwise it can be inferred.

My proposal would be to just add an explicit “marriage” property of type HistoricalEvent to HistoricalPerson for completeness. Based on the assumption that an individual can have multiple sets of parents (i.e. step or adopted) while the birth property doesn’t define any parents, I don’t think there would be much difference between the treatment of the birth and marriage properties in this respect (i.e. you have no way of knowing which mother was at the birth or which spouse was at the marriage).

For more complex families where the relationships are important, HistoricalFamily would still be the way to go, since that appears to try and restrict the number of parents to two and therefore remove any ambiguity from the births and marriages.

Perhaps adding a “families” property to HistoricalPerson would be helpful, but some confusion might come with using the “parents” property, which has a different meaning in each item.

davebarney commented 12 years ago

I like the idea of adding marriage, but NOT removing HistoricalFamily. It may seem entirely redundant, but as Tony points out, it can be useful for describing complex families.

Also, as was originally noted, for webpages that contains data for entire families, it is more concise to populate the HistoricalPerson objects with those unique to a person and then leave the family relationships to a HistoricalFamily object.

In other words, I suggest we keep HistoricalFamily as is, but add a marriage property (as type Event) to the HistoricalPerson.

NatAtGeni commented 12 years ago

I would be fine with adding a marriage event to HistoricalPerson.

Don't forget that most people will belong to at least two families - one as a child and one as a parent.

stoicflame commented 12 years ago

I'm good with adding a marriage property to HistoricalPerson. I recognize the redundancy, but for this particular project, we've already made a conscious decision to favor usability over conciseness.

davebarney commented 12 years ago

Done

ninjudd commented 12 years ago

I went through an example on my own, and I think the reason it is tedious to use HistoricalFamily is that you cannot nest HistoricalFamily within HistoricalPerson.

So.

A good alternative solution would be to add a way to do that. How about birth_family and marriage_family properties on HistoricalPerson? Then we could even remove direct relationships between HistoricalPerson objects.

tonyruscoe commented 12 years ago

Since it’s possible to have children without being married, I don’t think a “marriage_family” property would be the correct name if these were added. I’m not sure there would be much additional value in adding birth_family and marriage_family properties given the only additional properties being gained would be adoptions and divorce.

Generally speaking, I think you should be using HistoricalFamily instead of HistoricalPerson if your main purpose is to describe entire families or more complex family relationships.