Self explanatory. I discovered when trying to explain to my dad how to use this module that there was still no way to manually establish relationships between nodes. The only way to have relationships currently is to establish them somewhere else and to import the data. Yikes! I'll start working on this as my main priority as it seems like a pretty critical feature to me. I'll keep everyone posted as I go.

Comments

pyutaros’s picture

pyutaros commented

Okay, I've taken a look at what I think needs to happen, but I'll post what I'm going to do here first so anyone can raise concerns or give suggestions.

It looks like I just need to add a couple of entries to hook_form and an additional db_query to hook_insert for the relationship. We're not adding any fields to the database, so it should be pretty simple.

As far as the form layout, I think I'll present a checkbox (add relationship), a selectbox (type of relationship), a textbox (Name of related individual - eventually will autocomplete), a textbox (ID of related individual - an alternate way of establishing the relationship)

As for creating the relationship itself, it's a little more complicated than I first thought, though I almost have a full grasp of it. I'll some time charting it out in another comment. Too tired now. It also seems that we're missing opportunities to capture other GEDCOM specs here as well, but I'll elucidate later. Before I sign off, I'll post the data from a test record and data from an import record to better exemplify what needs to be added or changed.

Imported

Edit Delete 2131 138 INDI I1 0 @I1@ INDI
Edit Delete 2132 0 NAME F M /L/ 1 NAME F M /L/
Edit Delete 2133 0 GIVN F M 2 GIVN F M
Edit Delete 2134 0 SURN L 2 SURN L
Edit Delete 2135 0 SEX M 1 SEX M
Edit Delete 2136 0 BIRT 1 BIRT
Edit Delete 2137 0 DATE 26 JUL 1978 2 DATE 26 JUL 1978
Edit Delete 2138 0 PLAC Someplace 2 PLAC Someplace
Edit Delete 2139 0 CHAN 1 CHAN
Edit Delete 2140 0 DATE 07 FEB 2007 2 DATE 07 FEB 2007
Edit Delete 2141 0 TIME 17:37:12 3 TIME 17:37:12
Edit Delete 2142 0 NCHI 1 1 NCHI 1
Edit Delete 2143 0 OBJE @M2@ 1 OBJE @M2@
Edit Delete 2144 0 TITL F 2 TITL F
Edit Delete 2145 0 FAMS @F1@ 1 FAMS @F1@
Edit Delete 2146 0 FAMC @F2@ 1 FAMC @F2@

Test

Edit Delete 4235 276 INDI
Edit Delete 4236 NULL NAME NULL Test /Test/ NULL
Edit Delete 4237 NULL SEX NULL F NULL
Edit Delete 4238 NULL BIRT NULL NULL
Edit Delete 4239 NULL DATE NULL 12/07/2007 NULL
Edit Delete 4240 NULL PLAC NULL Here NULL
Edit Delete 4241 NULL DEAT NULL NULL
Edit Delete 4242 NULL DATE NULL 12/07/2107 NULL
Edit Delete 4243 NULL PLAC NULL There NULL

pfolk’s picture

pfolk commented

> a textbox (Name of related individual - eventually will autocomplete),
> a textbox (ID of related individual - an alternate way of establishing the relationship)

How to choose an individual is a problem I've been wrestling with too. One approach is to have an ID for each individual. There are a couple of gotchas there tho:

If we assume people will be importing and reimporting their data somewhat regularly, the node numbers will not be constant (it'll delete node 17 for Fred Fish and replace it with node 7782 for Fred Fish).

I'm not GEDCOM-savvy enough to know whether the individual IDs we use in the database will normally be stable.

The best approach I have thought of so far is "Fred Fish son of George" or some other family-based descriptor (which the system internally maps to a NID or Individual ID, every time you do a new Import).

The interface for doing this was a puzzle for me, that I think you've solved in a nice way. I was concerned about having to find the person you want, then finding the right ID for them, then going back to the place you actually want to enter the ID---very tedious! But if we do autocomplete, and have autocomplete fill in the extra info (like "son of" or whatever), then it becomes a simple matter of typing what you know (their name) and choosing which of the "Fred"s you want from the autocomplete list.

Am I way off base?

seth.e.shaw’s picture

seth.e.shaw commented

I don't think pfolk is off base at all. Although I like pyutaros' plan, I am not sure the individual edit form hook is the most intuitive way to do this. Instead, perhaps the use case should proceed like this:

User (with add/edit permissions) views an individual, which lists the families they are associated with, and display "add child" next to each family (just under child list) and "add spouse" button at the bottom. This opens/displays a new screen (or a previously hidden div) allowing us to search for he individual and click "add this person to family (as child|spouse)." No fuss, no muss.

To reiterate, I want to add an ancestor that wasn't listed before. Ok:

1) Create the individual.
2) In the node view page: Click on "add child" or some meaningful icon
3) On search page/possible hidden div: Find the existing decedent
4) Click on "submit" or "Yes, I really want to add this person as a child" or something to that effect
5) Show/refresh the node view to see the change

I think, in essence, the idea is to start with the relationship (spouse of, child of) and add the individual than starting with the individual and finding the right family relationship. But as it is, I think we (or should I say you, since you are the one implementing it) could do it either way. ;^)

As for reliable identifiers, we don't really have any. The xref pointers are only consistent within a single GEDCOM file and were not intended for public consumption. This actually causes trouble should we try to merge GEDCOMs because they are almost guaranteed to collide. The only globally unique (theoretically anyway) ID provided by the GEDCOM specification is AFN, but that is specific to individuals stored in Ancestral File and won't include everyone. The best identifier within the system is probably the node id, but then we do have that issue of export/reimport. Maybe we ought to work out a merge-import and encourage its usage so we don't run into this problem. I was planning on making extensive use of linking to individuals in stories. That won't work well if node ids keep changing.

In terms of searching for individuals, I think providing birth to death ranges: Seth Shaw, 1900 - 1999 would be the best way to go. While many individuals share names within a GEDCOM they are less likely to share birth and death dates. The only trouble is when you have multiple matches with close dates (if you are unsure) or no dates at all.

pyutaros’s picture

pyutaros commented

Thanks for the input guys. I'm going to layout some more stuff for my own benefit, as I'm still beginning to understand how the relationships are formed. Previously, I had assumed that relationships were formed between individuals, but this is not in fact the case. If you take a look at the record above, you'll notice that t has a relationship established with to family units. (F1 and F2) These family units are described at the end of the database:

Edit Delete 58344 0 FAM F1 0 @F1@ FAM
Edit Delete 58345 0 MARR 1 MARR
Edit Delete 58346 0 DATE 27 MAY 2006 2 DATE 27 MAY 2006
Edit Delete 58347 0 PLAC Someplace 2 PLAC Someplace
Edit Delete 58348 0 OBJE @M4@ 2 OBJE @M4@
Edit Delete 58349 0 CHAN 1 CHAN
Edit Delete 58350 0 DATE 31 JAN 2007 2 DATE 31 JAN 2007
Edit Delete 58351 0 TIME 18:22:52 3 TIME 18:22:52

Edit Delete 58419 0 FAM F2 0 @F2@ FAM
Edit Delete 58420 0 CHAN 1 CHAN
Edit Delete 58421 0 DATE 07 FEB 2007 2 DATE 07 FEB 2007
Edit Delete 58422 0 TIME 16:59:03 3 TIME 16:59:03
Edit Delete 58423 0 MARR 1 MARR
Edit Delete 58424 0 TYPE Religious 2 TYPE Religious
Edit Delete 58425 0 DATE 20 FEB 1971 2 DATE 20 FEB 1971
Edit Delete 58426 0 PLAC Someplace 2 PLAC Someplace
Edit Delete 58427 0 DIV 1 DIV
Edit Delete 58428 0 DATE 1994 2 DATE 1994

Each of these families have an XREF. Also the married date is held here as while. The indiviual record is a spouse to F1 and a child to F2. You should also note that the test individual has no XREF. While our relationship database can do the job (and if fact does) without the XREF, we are definitely placing ourselves further and further away every time we create a record without one. If I were to go ahead and create a new relationship, I would create a new family identity without an XREF. This could get quite confusing when it comes time to export.

However, we could also go the route of creating an additional node type of Family: Unit. This node would be generated when a relationship is created. The Family unit would then have it's own NID that could be referred to when trying to match up individuals. (Something like John and Jane Doe - 12/09/2007) Don't have much more time to flesh this out now. A quick reply to comments.

Peter, I fully intend to implement autocomplete somehow done the line if it's appropriate. But I'm thinking Seth's idea of a search may be easier (having looked at how the audio module implements autocomplete) to start with. I agree with Seth that dates are likely more reliable when trying to identify a particular person used in conjunction with a name. Considering my new take with the node types, I'm going to rethink the way to implement this. I like the idea of buttons directly on the view page, but I might also have it on the node add/edit form to cover all bases.

One more not on XREF's. It seems if we don't implement a new node type for families, that it is essential that we start generating them with new records. However, if we switch to having nodes for all XREF's (swapping one Index for another) that we could regenerate them anew with an export, thus also circumventing any conflicts from duplicate XREF's with merging GED files. Gotta run. Much more to say but no time. Let me know what you think.
Thanks,
Jonathan

seth.e.shaw’s picture

seth.e.shaw commented

I try to explain the Family relationship and how we implement it in some documentation I have been keeping. (If either of you would like to edit/contribute to my documentation let me know and I can give you rights.)

We really don't need to retain the individual's xref for system sanity. We preform all the needed functionality of displaying links between families without them. Of course, if we DO use them for searching and creating new links then we will need to generate a new xref for each individual (which won't be difficult or very complicated). One of the reasons I suggested starting with the family relationship and adding the individual from there is to avoid this sticky problem.

Although, I must confess that the Citation-Source-Repository code I wrote does currently rely on the xref. Perhaps that was a poor design choice in light of this discussion. I had done it because it is more efficient than using our relationships table. (Well, it at least made sense as I was coding it.) It should probably be considered a bug. I will go back and fix it.

I see no problem with creating "Family: Unit" nodes although calling them "Family: Group" nodes would be more consistent with the vocabulary of Family Historians and Genealogists. I think one of the reasons we haven't done this already is because we display this information in the individual view. That being stated, it shouldn't be difficult to move that functionality into the family group node view.

pyutaros’s picture

pyutaros commented

Okay, so here's the review of what I'm going to do. My apologies in advance for the length:

  1. I am going to create a new node type called "Family: Group". I will have to update the database, which means I'll have to figure out how to write a one time update into the code. If you guys know of a drupal node that explains this, or of somewhere else that this happens in the code, let me know.
  2. I am going to try and replicate creation of this "Family: Group" from how phpGedView created these relationships - From an individual record, you could either: add a parent, add a spouse, or add a child.
    • Adding a spouse or child creates the same type of relationship to the "Family: Group" from the originating indivual. Either way the individual would be related to "Family 1" as FAMS.
    • Adding a parent creates a relationship type of FAMC between the originating individual and the "Family: Group" or "Family 2"
    • All adding options would allow you to choose between an existing individual or creating another new individual on the fly.
  3. I would also like to alter the current add/edit form to include relationship options. I will have to determine in the form whether we're adding or editing. Adds would only be able to choose existing individuals. (Though I could create the individual and then present the same form again to create the related individual. I think that would be messier to code though.) Edits would allow both options. (I'm going to have to think about this point further. It might actually be easier to just have one form for either edits or adds. I'll post an update when I decide.)
  4. When choosing an existing individual, you will be able to search by name with a date range, or associate directly to an NID of an individual or group. You will also have to choose the relationship type of parent or child.
  5. I will have to create a "Family: Group" view. This view will pull all the relationships of a group and display them. From the "Family: Group" view, you should be able to add individuals. It should also display the marriage date of the family.
  6. I will have to create a "Family: Group" add/edit form. Here is what I can tell was in the GED file:
    • Header - FID - NID - FAM(Fact Code) - (We will not create XREF's) - (No GEDCOM Source)
    • Some info with Fact Code CHAN. Probably refers to the last time it was changed. We are not inserting this information for INDI records. I see no need to do that here.
    • There is fact code MARR to identify the marriage section.
    • Next is the type. I will need to include all available options from GED specs.
    • Next two lines are DATE and PLAC.
    • Fact code DIV for divorce.
    • DATE of divorce.
    • the form will also include the same association options as the individual add/edit forms, except that you will be unable to specify another "Family: Group". You will only be able to associate to individuals.
  7. Before I even start coding, I'm going to take a snapshot of the 5.x-1.x-dev branch and make the first non-beta release. If you guys have any changes you'd like to get in before then, let me know.
  8. I feel like these changes warrant a MAJOR version change, so I will be applying my changes to 5.x-2.x-dev (for that reason, and so I don't break a working version.) If either of you are directly updating CVS, let me know so I can DIFF my 5.x-1.0 snapshot and the latest 5.x-1.x-dev.

Thanks for reading my rambling. Please let me know if I forgot anything. I'm going to attack this in small chunks, so I will keep you update as the pieces start to roll in. Also check my post on GHOP out if you haven't already.
Thanks again,
Jonathan

pyutaros’s picture

pyutaros commented

I have completed items 1, 7, and 8. I edited family.module and family.install to include the new node type - Family: Group. I also included code in the .install to delete all group modules. I didn't have to update the database as the portions of the database referring to content types are auto-generated. I also took a snapshot of the existing code before I started - 5.x-1.0. The changes I am making are being committed to the 5.x-2.x-dev branch. Once I have completed all these tasks I will diff 5.x-1.0 and 5.x-1.x-dev and patch my 5.x-2.x-dev with any updates you both have made in the meantime.
One thing to note. Most of the code referring to family_individual is contained in individual.inc. There is some in import.inc. I'm thinking I should create a group.inc and mimic the forms in the individual.inc. I will also be editing the existing forms in individual.inc for associating individuals with groups. Let me know if you have any thoughts on this.
Thanks,
Jonathan

pyutaros’s picture

pyutaros commented

Group.inc has been added but is not totally complete. Most forms have been replicated but have not added the relationship ability yet. Also group.inc has not been added as an include in all the right places yet. Happy for the progress nonetheless. I'm hoping to have this portion done by the end of next week. We shall see. The relationship creation is going to be primitive at first, but I will try and include the fancier suggestions after the general framework is in place.
Thanks,
Jonathan

pyutaros’s picture

pyutaros commented

Finished include statements and code for viewing groups. All that remains is adding the actual code to drive the relationship.

On a side note, sifting through all this code has got me convinced that we are going about this in a much too complicated manner. For example, I think the majority of what we're trying to do with this module could be done with CCK and Views. The main things I see right now that add value that Drupal does not offer, are the import, and the future export feature.

Once I finish this feature add, and finish the port to 6.x, I'm going to begin experimenting to see if I can create a basic family tree with Views and CCK. If I'm successful, I'll open a new issue to debate how to transition from what we have to a new direction. It just seems silly to replicate work that other modules seem to be able to do quite well. Maybe I just need to go to sleep however. More later.

pyutaros’s picture

pyutaros commented

I've tested this on my test site, and none of the new form is showing up. I'm going to go run my head over with my car now. <- that's a joke

vanderlip’s picture

vanderlip commented

I am a genealogist more than I am a Drupalist, but have been building a personal site with heavy reliance on CCK, Views, and Panels 2. As I was going through the Fafmily demo site, I was thinking the exact same thing as mentioned in #9. Using CCK, Views, and Panels 2, may not only make sense for module development, it also makes sense for site builders, as it would give incredible flexibility and the ability to customize. I am sorry to say that I possess neither developer skills nor a deep knowledge of GEDCOM to be much help to this project. I would be more than happy to test, and when Family becomes more feature rich, to also right some documentation.

pyutaros’s picture

pyutaros commented

Thanks for the input vanderlip. Like I said, I'll be considering all of this with the Drupal 6 upgrade. I just got the form to display correctly for the Group content type. Now I've found that I'm missing a function, so this must be added. Finally I will be creating code for the actual relationship assign feature. Stay tuned, almost there. Appreciate the offer for testing. I will keep you in mind when I have a stable release.

pyutaros’s picture

pyutaros commented
Status: Active » Closed (won't fix)

Abandoned with a complete redesign in version 5.x-3.x.