First stab at data structures for a Drupal 7 based Genealogy site

Thanks for your comments.

I started out with the intention of defining custom entities for the content types, then realized that it would take a tremendous effort to make those entities available to the standard Drupal search, not to mention the fact that defining fieldable, exportable custom entities is alot of work and ongoing maintenance. So, I opted to utilize node based content types for some of the entities. I'm not sure what you mean by "reliance on additional modules to link them together" refers to.

For the input forms -- patience. Gotta have data structures in place before you can write custom forms, as the forms have to have somewhere to put their data, and the easiest way to create custom forms in Drupal is to leverage the Forms and Fields APIs and start with the canned Drupal node based edit forms. The entity references will wind up getting populated through some custom programming, so users won't necessarily have to make decisions on what they need to put in those entity reference fields.

I agree that the Event entity should have a "type" field, which I've got outlined as a taxonomy term reference where users can add event types as they see fit. I would like to use the date of birth and date of death of a person in creating the "title" field programmatically for each "Person" content instance to aid in identifying the correct person entity when you're using search, and having that as a separate event type tied to a unique entity reference field on the "Person" content type simply makes that process easier from a programmatic standpoint.

I'm not against GEDcom importing, but I personally don't use it, and like the forms before you can successfully write a GEDcom parsing routine you have to have somewhere to put the GEDcom data when you get it parsed, so the data structures have to be there first.

You don't need dual references between Person and Family in order to retrieve the "Family" tied to a person. A "Person" record belongs to one or more "Family" records, and while a "Family" record can't really exist without a "Person' record, a "Person" record can exist without a "Family" record. Views can work perfectly well to build any relationships using an entity reference on one content type to pull records from another content type, and from a programmatic standpoint having circular dependencies between content types is not considered a best practice.

On the "middle" name, I'm on the fence about separating given and middle names, and understand that, although it is an exception rather than the rule" people may have three or four given names. Again, this was more to make building name indices easier. I have no problem combining the "given" and "middle" name fields to just have one field that holds all names except the surname.

Thanks for the reminder...
The difficulty in getting entities included in searches was one of several serious 'gotchas' that have left me discouraged and looking elsewhere.
There are so many hurdles to get over and hoops to jump through in order to accomplish anything with Drupal -- and generally requires a plethora of additional modules, which need to be constantly monitored for compatibility - take a gander at the issue queue for jQuery Update module. Of course the need for such a module is an issue in itself.

"I'm not sure what you mean by "reliance on additional modules to link them together" refers to." Referring to the Entity Reference module or, as others suggest, the Relation module.

But, don't let me put you off -- I'm a rank amateur at this interwebby thing.

Am I the only person interrested in your proposal??

Mike

Thanks for chiming in. Glad to see your participation.

My primary reason for posting the data chart was to solicit feedback on the data, looking for holes in my data structures -- am I missing or overlooking key pieces of information needed to compile accurate information on a family tree. Without good data, everything else is impossible to construct effectively. I don't want to get 6 months into this project only to find I have to go back to square one because critical data points were overlooked or omitted.

Eventually, I plan to put up a dev site that has data structures, modules, forms, views, etc. when enough information has been assimilated and constructed that can be used by this group to review and provide input, as well as contribute to the development of this module(s) / package / distribution.

Other software

I have looked at (installed, played with or actually used at some point) several genealogy based website software applications and websites, the way they structure data, and the way they collect data through the user interface, including but not limited to:

WeRelate
phpgedview
TNG
WikiTree

as well as some desktop applications like:

Legacy Family Tree
MacFamilyTree

Some of the databases could be examined, and some could not so review was limited to what was available through the UI.

Data Structures

Drupal database layout is fairly unique, and incorporating data from a third party software into a Drupal site is fairly labor intensive, both to write and maintain, so I fairly quickly ruled out merging a third party application with a drupal website. My goal is to have a website where family members can not only visit and view the family tree information that has been assimilated, but can also participate in researching and adding information to the family tree.

The data chart I created and attached to this thread is an amalgamation of data structures I gleaned from all of the sources I reviewed, pulling what I thought was the best of all worlds into this data chart. The one area I pretty much built from scratch, which based on other websites I've seen is of little or no interest to some, but is of great interest to me is the sources and source citations. None of the software did a good job providing the ability to accurately document your sources and attach them to facts in your family tree, so I used Evidence! Citation and Analysis for the Family Historian by Elizabeth Shown Mills for my guide there. The challenge is coming up with a data structure that is flexible enough to accurately document a wide variety of source data and store those sources in a structured data format.

Person Name

I'm well aware of the issue with duplicate records as far as Person Name goes; I have several names that show repeatedly in my family tree as well. What the data structure chart does not show are some indexing tables that I'm considering building, that will create an index of individuals using name elements, and assign an index number to a persons' record based on some combination of given and surname to provide a level of uniqueness, primarily because I don't have those solidified yet. WeRelate does this with the first name and last name to accomplish a couple of different things:

1. Unique identifier for a person using their name
2. Unique URL for each person's page based on their name

(1) addressed minimizing duplicates, while (2) addressed both SEO friendliness and permalink issues. Most other family tree software I looked at uses some sort of indexing number to minimize duplicates as well.

The problem with both of these is: what do you do with the URL for a person's page when you find that their last name was incorrect, and therefore your URL schema generates a different URL for them. This both affects SEO and breaks external links as you mentioned. Drupal standard node URLs (http://www.example.com/node/123) are absolutely the most SEO unfriendly URLs around, which is why most folks use pathauto to generate URLs for drupal sites to begin with. I haven't tackled this issue yet because I'm starting from the ground up -- data first. But, page URLs are on my radar screen.

Pedigree Charts

Again, haven't tackled this one because before you can build a pedigree chart, you have to have data to use to create it. I would like pedigree charts on my site as well, so this is something I've got on my radar screen.

GEDcom files

Once again, not a first step because the data has to go somewhere when you import it so that it can be used, which is ultimately....tables in the database. Eventually I would like to have GEDcom data imports, but want some way to manage merging that information, which is frequently of suspect quality, into existing family tree information without compromising the integrity of what may be carefully researched and documented data.

That's not a task I'm willing to take on. If someone else on the list wants to take that as a project, please volunteer.

Gramps is written in Python, a language with which I'm not familiar. It is not designed to be "collaborative" software -- it is single user only. I'm not seeing the benefit of building on it -- it would actually be less work, IMO, to build from scratch rather than attempting to integrate the two.

What does the (M) in the attachment mean?

Does Biblio have any value to this project? It is built to be used as a source and citation type of module. Maybe Cite can be updated to Drupal 7 and have some value.

I could be off-base but it seemed related.

Short Answer: Yes.

I have used the "node" as the base data structure for most of the content types on my chart, and I have assumed that revisions to information will be tracked. While revisions are optional, I am assuming tracking revisions is something that is desirable because:
* it lets you see who changed a data record, when it was changed, and what specifically changed on the underlying record;
* tracking revisions gives you the capability to "roll back" a revision (similar to the way you can "roll back" changes on Wikipedia) to a previous state in the event that someone screws up the data record.

By default, on "node" based content types, Drupal stores both the user id of the user that originally created the content record along with a timestamp of when the record was created, and the user id of the person that made the latest change to the content record along with a timestamp of when the change was made. Drupal also tracks changes by revision, so if you have three people that edit a record in sequence, you can specifically see who created the original record and when, and what change was made each time the record was edited and when. If you are using a custom content type this logic has to be programmed.

Organic Groups could potentially be used to track multiple genealogical records, and allow a person (who would be the "owner" of the group and as such could "invite" others to collaborate with them, or they could simply be a group of one) to set up their own permissions structure to limit access to their data records.

There are a number of challenges that using this approach presents, that would necessitate changes to the data structure that I have proposed. I am not opposed to making those changes, and have in fact been contemplating those as I have studies my proposed data structures and have been pseudocoding the implementation of the business logic to support editing the data through a user interface, including validation rules and forms presentation to the user in a more user friendly manner than the "out of the box" drupal forms.

As I reviewed the pdf, I found myself asking myself whether the proposed methods would meet a few things I am looking for in a genealogy CMS. Maybe it would be better to start with a higher level requirements document and discuss that first. Then, as coding methods are considered, comments can be made relative to a set of top level requirements. It probably should be a new post, perhaps in a table, but I'll start here with the things I think are necessary features.

1) Person based comments.
2) Person based subscriptions. (follow). (Any information or field that changes should trigger a notification on a person basis).
3) Person based information additions - such as links to stories, articles, news clips, biographies, journals. Collaborative editing of new articles, biographies, etc.
4) GEDCOM import (I don't see GEDCOM EXPORT as essential, as long as notifications of changes are complete and reliable, so that an external database could be kept up to date if desired).
5) Citations.
6) Photo additions to persons.
7) Role based editing and permissions ( I realize this is generally built into almost anything we can imagine on drupal, but why not write it down in the list of essentials). Admin, editor, commenter, reviewer.
8) Graphical tree.
9) Date export considerations (PDF Book output would be ideal, but maybe not practical. At least, if a coding action is taken that makes this impractical, we can be aware.)
10) Others?

Thanks for all your work to get the ball rolling.

Sorry I haven't been contributing to this in the past three months...had to get a daughter married while keeping this pesky full time job. But I have my life back now.

I have briefly looked at your data definition/structures and would like to comment. Unless I missed something I did not see the definition of the entity "Notes". Also I would like to add "Repository" as an entity reference in "Photos/Images". Thought here is to provide information on where the original is, or if it is a picture of Great-Grandpa's shaving kit...who has it?

My vision is for this site to be used by an extended family to share photos, memorabilia, anecdotes, etc. It would be organized as a typical family tree site, but would be more community (family in this case) oriented than most genealogy sites that are out there. For this reason I really agree with Bokkie that there should be a user orientation with the "Person" and a very transparent display of the contributor (user) of every record creation and revision.

Perhaps then "Person" needs a user field? And perhaps a picture field?

Only other comment is in the "Family" definition. I am not sure if you were going to be more flexible in the Male and Female Partner definitions. My living extended family is getting a bit more complicated than traditional forms.

Thanks again for getting this rolling and taking the time to answer so many posts. I look forward to when you can open a sandbox on this and we can start playing to see what happens. Count me in to help, just let me know where you want me to focus.

Curious where this left off. I recently started doing Drupal module development and have 13 years of PHP development experience. I would be interested in seeing a Genealogy module in Drupal 8.

I've built a site, smithancestry.org with drupal 7 and have imported (individuals only) from my external gedcom format. It was a bit of trial and error, but I finally got it, thanks to the "Feeds" module. Learnings were that the Individuals import went fairly smooth. I STRONGLY suggest anyone to study closely the gedcom format first, especially if they plan on exports later from their site. e.g. I initially set mine up with First, Middle and Last names but with gedcom, what you get is Given Name and Last name. Thus I later had to create a "Join" field to combine my first and mid names for export.
Families format was nearly indecipherable (gedcom format) and I decided it was easier to create my "Families" manually. Since I'd imported all individuals, it was just a matter of selecting husband, wife and children; then manually entering date and place of marriage.
It remains a work in progress, but if interested, register as a guest and look around. You can PM me if you have any questions or suggestions.

Not sure, if this topic is still of interest, but I'm in the process of creating a family website whose main objective is to provide an intra family community sort of thing. Since one family member does lots of genealogy research, there is already a database containing some 1300-1400 people that exists as a GEDCOM file. So it was obvious to (1st) include this data and (2nd) having some means to import the GEDCOM file.
Actually I started 2 year ago with setting up a D7 based site using custom node types adding fields using views and so on. The project stalled due to time constraints amongst other reasons so a few weeks ago I started over again, this time using D8.
I want to note, that integrating the GEDCOM data is only part of what I want to achieve on this site. I am neither a genealogy researcher of any kind nor can I afford to spend the time to develop a full blown genealogy research kind of module. In short: I'm willing to cut out some of the data that a GEDCOM file may transport.
I started with some coding (finally digging into Drupal module dev after only using it for a couple of years now) and was about to set up a Drupal sandbox project as a repository for sharing what I've come up with so far, when I revisited this group and found this proposal for data structures using Drupal.

This data structure proposal looks as if it is modelled closely on what is specified in the GEDCOM 5.5.1 file format, which I think is rather good since GEDCOM is the de-facto standard of exchange. This would also mean that exporting data from such a structure to a GEDCOM file would be rather easy.

However what puzzles me is the fact that major "events" as 'birth', 'death' and so on are modelled as entity references to some common event entity/node type structure. I'm not sure if I really like this idea for various reasons: Birth, death, baptism, burial are events that may not exist, but if they do, exist only once. One might as well add the corresponding fields to the Person record and just leave them empty if the data does not exist.
Ok, all events share common structures so one motivation of putting them into an event entity is to not have to repeat similar definitions. I can even think of sharing visuals for all these events.

Although this looks tempting it comes at the cost of having to deal with lots of references which I find adds unnecessary complexity. Also these events can't live without their parent (= person) records at all. Next: Events as entities / node types would come with some infrastructure fields of their own like ID, Author, Title, UUID and so on. But these fields are not needed at all. It just doesn't make sense for me feels like overkill.
An approach for reusing the common structures of all these events is adding some kind of "Event" field compound, similar to what is done in the address module, however...

...in the code I'm about to place in a sandbox project I do provide custom entities for 'person' and 'familiy' (so far) by code. To add common event structures for the 1:1 events like birth and so on, is like calling some function with some key like 'birt' and let the function add all the fields.

There is still room for some event entity type especially when there is need for multiple events (1:n) with rather unspecified type but for 1:1 events I prefer inline.

As promised, I've put the code that I've written so far in a sandbox module called gedcom for everybody who's interested.

Note that at the time of writing this is merely a proof of concept type of thing -- which of course satisfies some of my personal goals -- and should not be used in a real project (yet) as I may change some of the underlying architecture.
Also note: since I'm german based, the field names are mostly german. I'll fix that at some point...

Lisa,
What is the progression on your genealogy project?