Re: Managing Genealogy Relationships in FMP 8.5

On May 10, 8:12 am, Grip <g...@xxxxxxxxxxxxx> wrote:
On May 10, 12:55 am, Sug <adam.suger...@xxxxxxxxx> wrote:



On May 9, 10:44 pm, Grip <g...@xxxxxxxxxxxxx> wrote:

On May 9, 10:35 pm, Sug <adam.suger...@xxxxxxxxx> wrote:

On May 9, 7:46 pm, Greg Dember <g...@xxxxxxxxxxxxxx> wrote:

In article <1178757205.472863.104...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,

Sug <adam.suger...@xxxxxxxxx> wrote:
Hi, G -

Thanks for your input. I do use join tables for certain aspects of
the database (the file has tables for managing photos, documents,
etc., and these can be stored in "albums" that are associated with
particular people, locations and events), but I don't think it's the
right solution for tracking familial relationships.

The problem with genealogy is that people are defined in relation to
other people, and those definitions change from person to person in
the database. What I mean is, if you have a product database with
27,000 items, the product type (aspirin, razor, toothpaste) is the
same no matter where you are in the store. But if you have a man in a
family tree, he's variously a brother, husband, grandfather, son,
first cousin twice removed, etc., depending on whose record you're
viewing him from.

That means that if you've got a hundred people in your family tree,
you'd need to generate a hundred join records for each individual to
specify the nature of the relationship, which means 10,000 new
records. With 27,000 people (all of them related, no matter how
distantly) that's 729,000,000 records. And every time you add a new
person, you have to add 27,000 join records to show how he's related
to everyone and another 27,000 records to show everyone how they're
related to him (note that kin relationships are often asymmetrical,
e.g., uncle/nephew; mother/daughter).

You see why I mentioned the redundancy problem in my first post. A
join table of this sort creates an unmanageable number of records for
each individual. Unless I'm not understanding you correctly.

OK, I've never done this either, but I'm going to jump in. I think
Grip's solution of having a join table where each record represents
either a marriage between two people or a parent-child relationship
between two people is less cumbersome than you realize.

You would not need records to indicate the grandparent relationships, or
the cousin or sibling relationships, or any of the more distant
relationships..... those can all be calculated just from the simple
marriage and parent-child pairings.

Think of an actual family tree diagram. You have people, and you have
lines connecting Husbands and Wives and Parents and Children. You don't
have lines connecting Uncles and Nephews. The Avuncular relationship is
inferred. The database can do the same thing.

Right?

Greg

Grip and Greg -

Truly appreciate your putting your heads to this. You are right that
all you need are marriage and birth records to trace all other
relationships in a family tree and that it doesn't require the
proliferation of records I mentioned last time. But it also doesn't
give you a graphical or textual representation of how person A is
related to person X. What it does give you is a way to get there --
but only if you want to move from record to record manually tracing
births and marriages till you arrive at the end of the maze.

Your suggestion is actually how the database is organized now: I have
a join table between People and Families in which each record notes
the person, the family and their role (husband, wife or child --
though it could just as easily be reduced to adult and child). This
is also, using a completely different file structure, how GEDCOM-based
applications track kinship -- so you're right about the fact that you
don't need anything more than that to plot the other relationships.

But in a sense that's the same as saying all you need to get from one
part of town to another is a list of each intersection: it's doable,
but a complete map is hella more efficient. And if you want the
complete map, you have to draw it, which is the problem we face here:
how to represent a family chart (even a limited one that shows direct
ancestors and descendants without brothers and cousins et al) without
making the solution unmanageable? And how to do this for every
record, so that the "self" at the center of the tree is different for
each record?

Does that make sense? I think Ursus is right that it's a crippling
problem from a Filemaker perspective. But perhaps there are some
geniuses out there who have tried it and come up with a solution?

You're not really asking for a map, you're asking for a map creation
program and that's what Greg and I have started you on. It's often
helpful to solve problems modularly. We got you past the data
structure part. You now understand how a genealogy tree can be
modeled on Filemaker.

You're also asking how to extract that information in a way that's
meaningful to you. I'd say scripts are the best way to do that here,
but exactly how and how well depends on what result you want. You
haven't given many details about that. Let's say a standard family
tree of just ancestors and descendents. (How big a page? How many
generations back? Connecting lines? Curling leaves?) I bet can get
'exploding' generations to line up reasonably well on a printed page
in a couple hours work.

Exactly how? Hmm. I'd start from the subject record and Go To
Related Record to grab the parents. Replace a Sort field to 1. GTRR
up again, Replace sort to 2 and so on. Then GTRR down from the
primary record, Replace Sort field to -1, etc etc. Find all records
with a value in the Sort field and sort descending. Filemaker isn't
great at graphical presentations, but I could rig up a layout showing
a tab delimited list of each generation in a Sub Summary part
(breaking on the Sort/Generation field with no body), the spacing of
the tabs determined by the generation. With some tweaking I think
that would be reasonably close to lining up properly in an 'exploding'
format. Print, clear all the Sort fields and repeat.

Again, I'm not saying Filemaker is the best way to do this. Genealogy
is a pretty fleshed out field, I'm sure there's several off-the-shelf
programs that can meet your needs, but you seem to have gotten hung up
on the idea of static modeling versus on-the-fly calculations. Google
Maps doesn't have a list of the directions from every point to every
other point and it just looks them up, rather it creates the
directions as necessary.

Grip

Whoa, Grip -- Ego-check at the door. As I said at the outset, the
question is how to generate ancestor and descendant charts. The
structure you've invented is the one genealogists have been using
since Noah (cf. Genesis 10) and which I use myself (cf. previous
post), though I appreciate your enthusiasm about it.

What I need, however, is a way to generate charts without requiring
users to sit through the process of dynamic calculations. Those are
okay for small record sets, but not for a family with tens of
thousands of members. Indeed, one of the biggest problems with off-
the-shelf programs is the endless amount of time they spend chewing
data whenever you want to move to a different record -- which is why
I'm looking for other methods. I prefer not to think of it as "hung
up on the idea of static modeling," but if that's how you want to
think of it, I can deal.

The problem in genealogy is the exponential growth of individuals as
you move through generations. So while your scripting may seem like a
good solution for four or five generations, all these breadcrumbs and
GTRRs keep doubling until your average G5 is chewing sand.

On the other hand, it seems like if you set up the right relationships
you save your end-user a lot of frustration. Such relationships might
be mathematically based, like an ystem,
so that familial connections are indexed in an identifier in the
record itself and parse easily into relationships regardless of what
record you start from. This would avoid the back-and-forth scripting
of GTRR, set fields, GTRR, set fields, loop loop loop -- which seems
to me not the best use of processing power. But, unfortunately, I
have not yet figured out what that equation should be.

-S.

Why do your expressed design specs keep changing? But more
importantly, why are you being an ass to someone who's trying to help
you?

*plonk*

Hi, Grip -

The problem is that you didn't pay attention to the initial post or
the ones that followed, instead jumping in to offer advice based on
your own ideas of what I needed rather than what I was asking for.

I specifically requested two things at the outset: a way to generate
certain charts and input from people who have tackled the genealogy
problem. The reason for the latter is that genealogy has hurdles you
don't see in standard database structures and I wanted to talk with
developers (like Ursus) who were familiar with these challenges. What
I wanted to avoid was having to educate neophytes on the complexities
of genealogy or rehash solutions I'd attempted and found wanting.

Ignoring the parameters of my request, you jumped in with basic advice
that made it obvious you weren't familiar with the problem. I
explained this to you, but instead of actually trying to understand
what I was saying, you insisted on the appriopriateness of your
solution, expanding on your initial advice with additional tutorials
in basic database design. This meant I had to start explaining
genealogy considerations to you -- something I was trying to avoid --
at which point you began insisting that the parameters keep changing
and that I didn't appear to know what I needed, when in fact nothing
had changed from the first post if only you'd taken time to read it.

Instead of recognizing this, you began beating a dead horse, insisting
that "you're not really asking for a map, you're asking for a map
creation program," then later saying I "seem to have gotten hung up on
the idea of static modeling versus on-the-fly calculations" (in other
words, apparently I _was_ asking for a map, rather than a map creation
program -- you need to be able to differentiate between what someone
is asking for and what you want to tell them). You also offered the
rather bizarre observation that "we got you past the data structure
part... you now understand how a genealogy tree can be modeled on
Filemaker." I mean, if it helps you sleep at night to think that,
cool, but you clearly missed the post in which I explained standard
genealogical structure, though I appreciate how, not being familiar
with it, you'd be delighted at your own innovation.

The thing is, sometimes ignorance of a problem leads to fresh ideas
and sometimes it leads to tired old solutions. By ignoring what I was
asking for -- including to talk with someone who was familiar with the
territory -- you went down the latter road. If at any point you'd
taken the moment to pay attention to the posts -- even in successive
emails where I clarified the challenges of genealogy for you -- you
might have been able to help. Instead you decided what you wanted to
say, didn't take time to assess the problem, then laid it on with
claims of originality.

So you see the problem. The difference between helping and getting in
the way is whether you pay attention to what someone is actually
asking for. If you look back at the thread, you'll see I was pretty
specific all the way through. Your own ideas of what you wanted to
say may have kept changing, but what I was asking for never did.

-S.

.

Relevant Pages

  • Re: Managing Genealogy Relationships in FMP 8.5
    ... the database (the file has tables for managing photos, documents, ... but a complete map is hella more efficient. ... Replace a Sort field to 1. ... Then GTRR down from the ...
    (comp.databases.filemaker)
  • Re: Managing Genealogy Relationships in FMP 8.5
    ... the database (the file has tables for managing photos, documents, ... family tree, he's variously a brother, husband, grandfather, son, ... but a complete map is hella more efficient. ... Replace a Sort field to 1. ...
    (comp.databases.filemaker)
  • Re: Specificities of French Medieval genealogy
    ... A genealogical database for medieval Breton nobility exists: ... Liste de diffusion sur la noblesse Bretonne ... indicates by itself some lack of interest for popular genealogy. ...
    (soc.genealogy.medieval)
  • Re: Managing Genealogy Relationships in FMP 8.5
    ... the database (the file has tables for managing photos, documents, ... family tree, he's variously a brother, husband, grandfather, son, ... Replace a Sort field to 1. ... Then GTRR down from the ...
    (comp.databases.filemaker)
  • Re: Wiki software for genealogy (long)
    ... and the source data so that, for example, a person's birth date can be ... This current deficiency of genealogy ... - It seems like overkill to have to install Mediawiki plus a database ... With regards to the use of the wiki as a "genealogy filing system", ...
    (soc.genealogy.britain)