 | |
Managing Genealogy Relationships in FMP 8.5
comp.databases.filemaker comp.databases.filemaker
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Managing Genealogy Relationships in FMP 8.5 -
05-10-2007
, 01:55 AM
|
On May 9, 10:35 pm, Sug <adam.suger... (AT) gmail (DOT) com> wrote: On May 9, 7:46 pm, Greg Dember <g... (AT) artocratic (DOT) com> wrote: In article <1178757205.472863.104... (AT) p77g2000hsh (DOT) googlegroups.com>, Sug <adam.suger... (AT) gmail (DOT) com> 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 |
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 Ahnentafel list or Register system,
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.
#12
| |||
| |||
|
|
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 Ahnentafel list or Register system, 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. |
Just to make sure.... I could send you my old fm5 (or fm7, only converted)
version. It is fairly complete in itself, but it is totaly in Dutch. I have
build it many years back for a friend. It only has the ancestrors charts.
But this works pretty fast and you would be able to see one way of setting
it up. . Just let me know if you are interested on my at.
ursus DOT kirk AT wanadoo DOT nl
#13
| |||
| |||
|
|
On May 9, 10:44 pm, Grip <g... (AT) cybermesa (DOT) com> wrote: On May 9, 10:35 pm, Sug <adam.suger... (AT) gmail (DOT) com> wrote: On May 9, 7:46 pm, Greg Dember <g... (AT) artocratic (DOT) com> wrote: In article <1178757205.472863.104... (AT) p77g2000hsh (DOT) googlegroups.com>, Sug <adam.suger... (AT) gmail (DOT) com> 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. |
importantly, why are you being an ass to someone who's trying to help
you?
*plonk*
#14
| |||
| |||
|
|
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 Ahnentafel list or Register system, 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. Sug, Just to make sure.... I could send you my old fm5 (or fm7, only converted) version. It is fairly complete in itself, but it is totaly in Dutch. I have build it many years back for a friend. It only has the ancestrors charts. But this works pretty fast and you would be able to see one way of setting it up. . Just let me know if you are interested on my at. ursus DOT kirk AT wanadoo DOT nl |
address off group. Thanks for your help.
-S.
#15
| |||
| |||
|
|
On May 10, 12:55 am, Sug <adam.suger... (AT) gmail (DOT) com> wrote: On May 9, 10:44 pm, Grip <g... (AT) cybermesa (DOT) com> wrote: On May 9, 10:35 pm, Sug <adam.suger... (AT) gmail (DOT) com> wrote: On May 9, 7:46 pm, Greg Dember <g... (AT) artocratic (DOT) com> wrote: In article <1178757205.472863.104... (AT) p77g2000hsh (DOT) googlegroups.com>, Sug <adam.suger... (AT) gmail (DOT) com> 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* |
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.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.