Sam Hughes wrote a most disturbing yet entertaining exposition of how to deal with same-sex marriages in designing a database schema. It definitely has a bearing on the schema I’ve been thinking about.
To some, genealogy means pedigrees, meaning the strict biological definition of father-mother-child relationships. In large part, I’m inclined to agree. I am a strong proponent of traditional definitions of marriage and family. However, I recognize that many do not agree, and that there is a strong desire / need to represent relationships that do not fit that pattern. Adoption, step-parents and step-children, etc — all the influential relationships in a person’s circle should be able to be described and viewed.
In thinking about the database design, I do want the family relationship to play a central role: a father, a mother, and their natural-born children. That may or may not involve a marriage. That family structure is the fundamental unit of human society — many do not fit neatly into that definition, but it is the core.
At the same time, both the database and presentation layers will need to support other (arbitrary) relationships. Adoption and mixed families are two of the most common I am thinking of. What are others? How should these relationships be treated — ie. are they navigable in pedigree views?
Coming back to the question of same-sex marriages. Doesn’t much apply in a historical context, but it will likely be an important question to consider for coming generations. I don’t plan to compromise the definition of the family, but I hope yology will be flexible enough to show those relationships that are most important to the users.
So quickly some specific thoughts on the schema: a Relation will be a key entity of the data model. A relation will be defined as:
- any two people
- a relation type (parent/child, spouse, other)
- some associated events (birth, adoption, marriage, divorce, other)
Some relation types will have special meaning, such as the parent/child and spouse relations — and those will be constrained to follow traditional definitions. Other relation types will be user-definable (as well as some other ‘standard’ relation types). Views such as the pedigree or descendants will rely on those standard relations, but also (optionally) include the non-standard relations. Not sure how that will work yet…