From: Lars Kr.L. <gr...@lk...> - 2004-07-28 07:56:33
|
On Mon, Jul 26, 2004 at 08:40:06PM -0500, Alex Roitman wrote: > Finnish relationship calculator plugin has been added to the STABLE CVS branch > today, thanks to the input from Eero Tamminen. Is this a correct command for checking out the source cvs -z3 -d:ext:<myusername>@cvs.sourceforge.net:/cvsroot/gramps co gramps2 ? - I cannot see a rel_fi.py in the resulting source. :-( > Shortly, the Finnish relationships can be expressed in a series of genitive > nouns: father's mother's mother's father's sister, or son's daughter's > daughter's son's second cousin. This is very similar, if not the same, > to what Lars has described. > > It seems to me that it would be very easy to create similar calculators > based on the rel_fi.py for the languages with a similar relationship > structure. I suspect (although not certain) that Swedish and Norwegian > are similar, please correct me if this is wrong. The described structure of Finnish relationships is similar to the Danish. (I find this similarity between a non Indo-European (Finno-Ugric) language and a North Germanic language surprising). I don't know how literal the above explanation should be taken, but most of the Danish kinship terms actually consist of (contractions of) pairs of the basic terms, i.e. "farmors faster" instead of father's mother's father's sister and "sønnedatters dattersøns næstsøskendebarn" rather than son's daughter's daughter's son's second cousin (the last word here is not just such a contraction). In Danish many nouns are simply a concatenation between two nouns, but sometimes also between an adjective and a noun. Would a future rel_da.py have the necessary information available to correctly generate a relationship like "lillesøster" (little sister) ? (relevant for the concatenation of big/little with brother/sister). > So, if somebody steps up (Lars? Jens? Frode?) and provides the input > we can add another few plugins with almost no development effort. OK, we need support for this exciting functionality - and I can do some translation (including strings in a .py file). My Finnish is however only at the beer-ordering level, so hopefully rel_fi.py can be understood by English readers. Swedish readers with interest in kinship terms can check out "Kusin, Vetter or tvímenning - an etymological excursion in european kinship terms" at http://www.fortunecity.se/studentstaden/schem/3/hd99.htm (the tables include translations into German, English, French and Latin). Wouldn't it be a good idea to try an identify similarities between the various rel_*.py and handle these similarities with common functions and translated strings ? > If I were a salesman, I would say "Imagine if GRAMPS could say 'third > cousing twice removed' or '4th great grandson' in your native language" > but I'll just finish here instead :-) The ease with which such capability can be added demonstrates the strength of the underlying design of GRAMPS. -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Lars Kr.L. <gr...@lk...> - 2004-07-28 16:58:06
|
On Wed, Jul 28, 2004 at 08:51:49AM -0500, Alex Roitman wrote: > Lars, > > On Wed, Jul 28, 2004 at 07:49:12AM -0000, Lars Kr.Lundin wrote: > > > > Is this a correct command for checking out the source > > cvs -z3 -d:ext:<myusername>@cvs.sourceforge.net:/cvsroot/gramps co gramps2 ? > > - I cannot see a rel_fi.py in the resulting source. :-( > > Add '-r STABLE' between co and gramps2. If you have just checked > the unstable tree with the above command, you may instead say > $ cvs update -r STABLE > in the top-level dir of the tree (gramps2) to switch the whole tree > to the STABLE branch. Sorry about the cvs blunder. (I actually thought the idea of a head and stable branch was that code was supposed to be subjected to some testing in the head branch before it made it to the stable branch.) > What the re-written version does is to append the person's gender to the > string as we traverse the ancestor line(s), instead of just adding 1 to > the count. Then the number of generations will be equal to the length of the > resulting string ('ffmfm'== father father mother father mother), > and the gender sequence can be easily unrolled. Sounds good. I wonder if this has any real value, but in addition to words like "datterdatter" (daughters daughter) Danish also has the commonly used "barnebarn" (childs child). This word could be used if the gender of the descendant is unknown. I do not know how often that happens, but it would not require much to support it. I guess it would just require that the function that generates the above string would be able to insert a 3rd character to indicate a person with unknown gender (f.ex. "p" for parent). > But IMHO we can optimize the code later, once it works and works correctly. > As Donald Knuth teaches us about programming, the premature optimization > is evil :-) Agreed. > What I would like to do is to write rel_da.py (based on rel_fi.py) and > then, if a lot of similarities will exist, maybe create a prototype > from which both plugins will use the parts. Definitely so if more than two > plugins will share a lot, like Swedish and Norwegian. Good idea. > So, cutting to the bottom, I would be glad to help writing rel_da.py > but I need you to fill me in on the details. Lars, please feel > free to email me privately with the rules for forming the kinship > terms. I have a sample diagram Eero sent me, so I can send it to you > if you'd like and you can convert it to Danish terms. Very good. Please send me the diagram, and I will get back to you. > If you'd like to write the plugin yourself, please feel free to ask about > the details. No, actually I would appreciate if you would write it. Sorry to again bother the list with a technical problem: I am not able to compile the source from the STABLE branch on a Red Hat 9 box. It would be great if someone could please tell me how to do that (both ./autogen.sh --prefix=$HOME and ./configure --prefix=$HOME && make fail with a Permission denied). -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Lars Kr.L. <gr...@lk...> - 2004-07-29 17:36:51
|
> Absolutely! As a matter of fact, I just asked Eero about the same thing > in Finnish, because currently the gender is assumed to be female if it is > not male. So the unknowns are interpolated to be females, which can > be avoided if there's a gender-less term. OK. In Danish it is a bit awkward to construct terms for all cases where one or more persons in the relationship chain have an unknown gender. I think that interpolating to female could mislead the user. Perhaps it would worth to consider to let the relationship calculation fail with a message that the two individuals do have a known common ancestor, but that the relationship cannot be described because person(s) in relationship-chain have an unknown gender. > > > So, cutting to the bottom, I would be glad to help writing rel_da.py > > > but I need you to fill me in on the details. Lars, please feel > > > free to email me privately with the rules for forming the kinship > > > terms. I have a sample diagram Eero sent me, so I can send it to you > > > if you'd like and you can convert it to Danish terms. I made a new diagram: http://www.lklundin.dk/gramps/bloodrelatives.dia http://www.lklundin.dk/gramps/bloodrelatives.png The diagram got kind of big because in addition to the couple of dozens systematic terms I added a number of not-so-systematic terms that describe some genderless relationships. But to start with it would be great with a rel_da.py that just translates an [mf]-string (or is it two strings for one common ancestor?). In relation to rel_fi.py, rel_da.py requires one or more functions that gobble up two of those letters at a time. The result of a call to such a function should be one of the 16 words mentioned at the bottom of the diagram. If I understand things correctly, Swedish and Norwegian can translate the [mf]-string with the exact same functions (just with slight spelling differences in the output), so we can get a useful rel_sv.py and rel_no.sv practically for free. In addition they, especially Norwegian, seem to have a number of more special relationship terms that are not present in Danish. > So far we're only dealing with the blood based relationships, so > nothing like "father's mother's brother's wife" is in the picture. > We may add those in the future though. It sounds like a good idea to get the blood based relationships on track first. Couldn't more general relationships be described if in addition to [mf] (and p for parent) in the string there was also [sd] (for son and daughter) ? Then one could easily represent relations like my 3. cousins great-great- grandmothers grandchild. The [ds] would add information about the up/down- direction the various persons have in the relationship chain. Or could this already be easily represented (it seems that several [mf]-strings would need to be handled for that) ? > The diagram may not quite fit the Danish structure, so please > add whatever you see necessary and otherwise explain as much > as needed about the kinship terms. E.g. cousins in Finnish do not > have gender. Do they in Danish? Any rules on concatenation of > the genitive terms? The diagram itself would be too extensive if all possible combinations of just two genitive terms were to be used. But the diagram along with the explanation boxes should give the idea. Otherwise, ask and I will try to clarify. Please note that I also use the comment field in some boxes to give an idea about the terms not actually shown. > Beware: I'm likely to follow up with a lot of questions, so please > be patient with me :-) Sure. > Could you please send me the output of > the ./autogen.sh --prefix=$HOME run? Actually, I managed to get it to work like this: % ./autogen.sh --prefix=$HOME processing . Running aclocal ... aclocal: cannot open > aclocal.m4: Permission denied **Error**: aclocal failed. This may mean that you have not installed all of the packages you need, or you may need to set ACLOCAL_FLAGS to include "-I $prefix/share/aclocal" for the prefix where you installed the packages whose macros were not found % chmod 644 aclocal.m4 % ./autogen.sh --prefix=$HOME processing . Running aclocal ... Running automake --gnu ... configure.in: installing `./missing' Running autoconf ... autom4te: cannot open configure: Permission denied **Error**: autoconf failed. % chmod 755 configure % ./autogen.sh --prefix=$HOME .. lots of non-error messages Now type `make' to compile gramps % make .. lots of non-error messages % make install .. lots of non-error messages Btw, repeating the last command causes an error: % make install .. lots of non-error messages cp: cannot create regular file `/home/llundin/share/gramps/gnome/help/gramps/C/gramps-manual.xml': Permission denied - since the file is already there with mode 444. So apparently the problem is that a number of files have read-only mode at the time when they are to be overwritten. -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Frode J. <fro...@sk...> - 2004-07-30 09:10:48
|
Thursday 29 July 2004 19:36, wrote Lars Kr.Lundin: > > > > So, cutting to the bottom, I would be glad to help writing rel_da.py > > > > but I need you to fill me in on the details. Lars, please feel > > > > free to email me privately with the rules for forming the kinship > > > > terms. I have a sample diagram Eero sent me, so I can send it to you > > > > if you'd like and you can convert it to Danish terms. > > I made a new diagram: > http://www.lklundin.dk/gramps/bloodrelatives.dia > http://www.lklundin.dk/gramps/bloodrelatives.png Norwegian version: http://www.jemtland.com/bloodrelatives_no.dia http://www.jemtland.com/bloodrelatives_no.png I have not changed the comments.... so I list any diff's/questions here: I find the terms "moster" and "faster" strange to use in Norwegian (I alway= s=20 use onkel(uncle)), but the Clue book[1][2] finds them, so they must be=20 Norwegian words..... I have never heard these terms being used by anyone el= se=20 than my cuisine, and she is danish. :) I'm not familiar with the farbror/morbror ether... That sounds a little bit= =20 Swedish to me, but they are in Clue to [3][4] [1]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dfaster [2]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dmoster [3]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dfarbror [4]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dmorbror I personally think that=20 =2D"kusine" is a bether word for "mosters datter", "fasters datter", "morbr= ors=20 datter" "farbrors datter" =2D"fetter" is a better word for "farbrors s=F8nn", "morbrors s=F8nn", "mos= ters=20 s=F8nn"and "fasters s=F8nn" (and the same for s=F8nnes=F8nn/datters=F8nn and datterdatter/s=F8nnedatter= of the=20 above....) As a side note, in my part of the contry it is more common to use s=F8skenb= arn=20 for cousin, also on persons you know the gender on. But it's more correct t= o=20 use kusine for females and fetter for males. Any other Norwegians on the list, please proof read, and comment ... > The diagram got kind of big=20 You don't say :) > But to start with it would be great with a rel_da.py that just translates > an [mf]-string (or is it two strings for one common ancestor?). In relati= on > to rel_fi.py, rel_da.py requires one or more functions that gobble up two > of those letters at a time. The result of a call to such a function should > be one of the 16 words mentioned at the bottom of the diagram. > > If I understand things correctly, Swedish and Norwegian can translate > the [mf]-string with the exact same functions (just with slight spelling > differences in the output), so we can get a useful rel_sv.py and rel_no.sv > practically for free. > > In addition they, especially Norwegian, seem to have a number of more > special relationship terms that are not present in Danish. What do you have in mind ? I have just translated the form, not thought of any additions.... > Please note that I also use the comment field in some boxes to give an > idea about the terms not actually shown. I have not done any changes to the comment.... For the most part, they appl= y=20 to Norwegian to, but see my comment above about the foster/moster and=20 farbror/morbror part.=20 > > Beware: I'm likely to follow up with a lot of questions, so please > > be patient with me :-) > > Sure. No problem. =2D-=20 =2DFrode Real programmers don't write in BASIC. Actually, no programmers write in BASIC after reaching puberty. |
From: Frode J. <fro...@sk...> - 2004-07-30 10:09:07
|
=46riday 30 July 2004 11:08, wrote Frode Jemtland: > I find the terms "moster" and "faster" strange to use in Norwegian (I > always use onkel(uncle)), but the Clue book[1][2] finds them, so they must > be Norwegian words..... I have never heard these terms being used by anyo= ne > else than my cuisine, and she is danish. :) > I'm not familiar with the farbror/morbror ether... That sounds a little b= it > Swedish to me, but they are in Clue to [3][4] > > [1]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dfaster > [2]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dmoster > [3]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dfarbror > [4]http://66.70.46.80:5555/?lang=3Dno&dict=3DNONO&word=3Dmorbror > > I personally think that > -"kusine" is a bether word for "mosters datter", "fasters datter", > "morbrors datter" "farbrors datter" > -"fetter" is a better word for "farbrors s=F8nn", "morbrors s=F8nn", "mos= ters > s=F8nn"and "fasters s=F8nn" > > (and the same for s=F8nnes=F8nn/datters=F8nn and datterdatter/s=F8nnedatt= er of the > above....) Talked with a person at work, that is closer to retirement age, and he tels= me=20 that moster/faster/farbror/morbror is bether to use to know witch gender/si= de=20 of family we are talking about, but these terms have disappeared in Norwegi= an=20 in the last 30-40 year. To get the right gender/side of family it is more=20 correct to use them, but this can lead to confusion to what the connection= =20 actually means. A possible solution to this could be to use both, if for=20 example the calculator respons with "mosters datterdatter", it should also= =20 include in parentheses "kusines datter". If this is technically possible, = I=20 don't know ... =2D-=20 =2DFrode Your fault -- core dumped |
From: Alex R. <sh...@al...> - 2004-07-30 13:54:41
|
Frode, On 07/30/2004 04:08:42 AM, Frode Jemtland wrote: > Thursday 29 July 2004 19:36, wrote Lars Kr.Lundin: > > > > I made a new diagram: > > http://www.lklundin.dk/gramps/bloodrelatives.dia > > http://www.lklundin.dk/gramps/bloodrelatives.png >=20 > Norwegian version: > http://www.jemtland.com/bloodrelatives_no.dia > http://www.jemtland.com/bloodrelatives_no.png Thanks! I'll take a look and get back to you after I've digested that and all the following discussion. Most likely it will be after the weekend, since I want to sort out the Danish plugin first.=20 Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Jens A. <je...@sv...> - 2004-07-30 19:16:33
|
Frode Jemtland <fro...@sk...> writes: > Thursday 29 July 2004 19:36, wrote Lars Kr.Lundin: > > > > > So, cutting to the bottom, I would be glad to help writing rel_da.py > > > > > but I need you to fill me in on the details. Lars, please feel > > > > > free to email me privately with the rules for forming the kinship > > > > > terms. I have a sample diagram Eero sent me, so I can send it to you > > > > > if you'd like and you can convert it to Danish terms. > > > > I made a new diagram: > > http://www.lklundin.dk/gramps/bloodrelatives.dia > > http://www.lklundin.dk/gramps/bloodrelatives.png > > Norwegian version: > http://www.jemtland.com/bloodrelatives_no.dia > http://www.jemtland.com/bloodrelatives_no.png And in Swedish: http://www.algonet.se/~arvid/bloodrelatives_sv.dia http://www.algonet.se/~arvid/bloodrelatives_sv.png I made some changes in the diagram, hopefully it is still readable. A few comments: Swedish for the most part doesn't have the more general words that Danish and Norwegian (and English) have: We only use faster/moster and farbror/morbror. The word onkel (uncle) exists, but is rarely used. "Tant" (aunt) is used, but nowadays only in the meaning "old woman". :-) We don't use "beste" (grand), "olde" or "tip" (great). (There is the prefix "gamla-", but it's only used for the great grandparent generation, and its use is rather irregular and probably not very useful in a genealogy program.) "Nevö" (nephew) and "niece" exist, but are seldom, if ever, used. For cousin, Danish and Norwegian has fætter/kusine, Swedish uses "kusin" in both cases. The genitive forms are no different in Swedish than in Danish and Norwegian, apart from spelling. The nth-cousin-relations are different in Swedish, which I try to describe in the comments. Jens P. S. I looked at the link with Norwegian kinship vocabulary, very interesting! In particular, I noticed the term "dobbeltsyskenbarn" (dubbelkusin in Swedish) [double (1st) cousin; child of mother's brother/sister and father's sister/brother, children that have all four grandparents common]. To be able to find such relationships via the relationship calculator would indeed be very cool. |
From: Alex R. <sh...@al...> - 2004-07-30 19:36:24
|
Jens, On 07/30/2004 02:16:15 PM, Jens Arvidsson wrote: > Frode Jemtland <fro...@sk...> writes: > > Thursday 29 July 2004 19:36, wrote Lars Kr.Lundin: > > > > > > I made a new diagram: > > > http://www.lklundin.dk/gramps/bloodrelatives.dia > > > http://www.lklundin.dk/gramps/bloodrelatives.png > >=20 > > Norwegian version: > > http://www.jemtland.com/bloodrelatives_no.dia > > http://www.jemtland.com/bloodrelatives_no.png >=20 > And in Swedish: > http://www.algonet.se/~arvid/bloodrelatives_sv.dia > http://www.algonet.se/~arvid/bloodrelatives_sv.png Thanks! I am overwhelmed with all these developments! > Swedish for the most part doesn't have the more general words that > Danish and Norwegian (and English) have: >=20 > We only use faster/moster and farbror/morbror. The word onkel (uncle) > exists, but is rarely used. "Tant" (aunt) is used, but nowadays only > in the meaning "old woman". :-) That is a huge simplification for me -- I have to only code for the=20 simple genitive relations :-) > We don't use "beste" (grand), "olde" or "tip" (great). (There is the > prefix "gamla-", but it's only used for the great grandparent > generation, and its use is rather irregular and probably not very > useful in a genealogy program.) >=20 > "Nev=F6" (nephew) and "niece" exist, but are seldom, if ever, used. >=20 > For cousin, Danish and Norwegian has f=E6tter/kusine, Swedish uses > "kusin" in both cases. >=20 > The genitive forms are no different in Swedish than in Danish and > Norwegian, apart from spelling. Awesome!!! > The nth-cousin-relations are different in Swedish, which I try to > describe in the comments. I'll look it over and get back to you with more questions. You're=20 the third in line now, after Lars and Frode :-) Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Lars Kr.L. <gr...@lk...> - 2004-07-30 09:30:51
|
On Fri, Jul 30, 2004 at 11:08:42AM +0200, Frode Jemtland wrote: > Norwegian version: > http://www.jemtland.com/bloodrelatives_no.dia Nice! > I find the terms "moster" and "faster" strange to use in Norwegian (I always > use onkel(uncle)), but the Clue book[1][2] finds them, so they must be > Norwegian words..... I have never heard these terms being used by anyone else > than my cuisine, and she is danish. :) > I personally think that > -"kusine" is a bether word for "mosters datter", "fasters datter", "morbrors > datter" "farbrors datter" > -"fetter" is a better word for "farbrors sønn", "morbrors sønn", "mosters > sønn"and "fasters sønn" > > (and the same for sønnesønn/dattersønn and datterdatter/sønnedatter of the > above....) > > As a side note, in my part of the contry it is more common to use søskenbarn > for cousin, also on persons you know the gender on. But it's more correct to > use kusine for females and fetter for males. Similar thoughts are nagging me: Some people may prefer the more commonly used (often shorter) words than the more accurate (but often longer) ones, as Frode exemplifies above. Also many Danes would prefer f.ex. kusine (female cousin) to one of the more accurate mosters/fasters/morbrors/farbrors datter. So it could be useful with a GRAMPS option or preference setting along the lines of: Prefer relationship terms that are more 1) accurate (but in some cases less simple) 2) simple (but in some cases less accurate) In any case, 2) would require extra functions for the non-systematic relationship-terms (even though many of them are surely already coded for the English/German cases). -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Alex R. <sh...@al...> - 2004-07-30 13:58:20
|
On 07/30/2004 04:30:29 AM, Lars Kr. Lundin wrote: > On Fri, Jul 30, 2004 at 11:08:42AM +0200, Frode Jemtland wrote: > >=20 > > As a side note, in my part of the contry it is more common to use s=F8s= kenbarn=20 > > for cousin, also on persons you know the gender on. But it's more corre= ct to=20 > > use kusine for females and fetter for males. >=20 > Similar thoughts are nagging me: Some people may prefer the more commonly > used (often shorter) words than the more accurate (but often longer) > ones, as Frode exemplifies above. >=20 > Also many Danes would prefer f.ex. kusine (female cousin) to one of > the more accurate mosters/fasters/morbrors/farbrors datter. >=20 > So it could be useful with a GRAMPS option or preference setting along > the lines of: Prefer relationship terms that are more > 1) accurate (but in some cases less simple) > 2) simple (but in some cases less accurate) >=20 > In any case, 2) would require extra functions for the non-systematic > relationship-terms (even though many of them are surely already coded > for the English/German cases). We can add that, either as a separate option as you suggest, or in parentheses as Frode suggested. Let me first get the basics done, and we will improve it from there on :-) Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Lars Kr.L. <gr...@lk...> - 2004-07-30 11:03:08
|
On Thu, Jul 29, 2004 at 02:18:41PM -0500, Alex Roitman wrote: > > In addition they, especially Norwegian, seem to have a number of more > > special relationship terms that are not present in Danish. Frode, I wrote the above after a look at http://www.mtf.ntnu.no/people/ivarse/slektord.html > The [mf] strings have all the information. Here's how it works: suppose we > need to know the relation between person A and person B. We first find > their closest common ancestor C and the [mf] path from A to C and from > B to C. So, if you'd like to unroll the [mf] string from older to younger > generation, you'll have sons and daughters. The other way it's mothers > and fathers. OK. So not only the construction, but also the parsing of the relationship string regarding A and B involves C. If we at a later stage want to support relations that are not through a single person (currently a common ancestor [*]) the string parsing will be tied to a number of persons apart from A and B. If A is B's > 3. cousins great-great- > grandmothers grandchild. the parsing of the resulting [mf]-string will require knowledge about not only A and B, but also D (the 3. cousin), C (the common ancestor of B & D) and E (the common ancestor of D & A). This seems more complicated than simply parsing an [mfds]-string, but I cannot read the python code well enough to see if the example relationship would actually be more complicated to code with the current [mf]-string. [*] is it checked if it is really two common ancestors ? That would make the difference between a half-brother and a brother. > I would guess that you had configured and made and > installed it at least once before as a root. Then all the > created files are owned by root, and it becomes a mess. Actually no. I have only installed gramps as myself (never as root) and the problems occured with % rm -rf gramps2 % cvs -z3 -d:ext:<username>@cvs.sourceforge.net:/cvsroot/gramps co -r STABLE gramps2 % cd gramps2/ % ./autogen.sh --prefix=$HOME - so I guess the make errors where caused by permissions on files from the CVS (my umask is 22), unless the files/permissions are modified by the make itself. -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Frode J. <fro...@sk...> - 2004-07-30 13:46:47
|
=46riday 30 July 2004 13:03, wrote Lars Kr.Lundin: > On Thu, Jul 29, 2004 at 02:18:41PM -0500, Alex Roitman wrote: > > > In addition they, especially Norwegian, seem to have a number of more > > > special relationship terms that are not present in Danish. > > Frode, I wrote the above after a look at > http://www.mtf.ntnu.no/people/ivarse/slektord.html Hmm. This was extensive. There was a lot of words I have never heard. I do= =20 think we have covered the most important part in the previous mailed dia=20 file.=20 One thing that's interesting is that in Norwegian we can also use fars=F8st= er=20 instead of faster, and mors=F8ster for moster. (I do see that the later are= =20 shortform of the earlier, but it removes any doubt). I add them to the char= t. =2D-=20 =2DFrode "Life and death are seldom logical." "But attaining a desired goal always is." -- McCoy and Spock, "The Galileo Seven", stardate 2821.7 |
From: Alex R. <sh...@al...> - 2004-07-30 14:07:23
|
On 07/30/2004 06:03:04 AM, Lars Kr. Lundin wrote: > On Thu, Jul 29, 2004 at 02:18:41PM -0500, Alex Roitman wrote: > > > The [mf] strings have all the information. Here's how it works: suppose= we > > need to know the relation between person A and person B. We first find > > their closest common ancestor C and the [mf] path from A to C and from > > B to C. So, if you'd like to unroll the [mf] string from older to young= er=20 > > generation, you'll have sons and daughters. The other way it's mothers= =20 > > and fathers. >=20 > OK. So not only the construction, but also the parsing of the relationship > string regarding A and B involves C. Not necessarily C as a person, but definitely number of generations with=20 the genders of all participants from A to C and from B to C. > If we at a later stage want to support relations that are not through a > single person (currently a common ancestor [*]) the string parsing will be > tied to a number of persons apart from A and B. >=20 > If A is B's > > 3. cousins great-great- > > grandmothers grandchild. > the parsing of the resulting [mf]-string will require knowledge about > not only A and B, but also D (the 3. cousin), C (the common ancestor of > B & D) and E (the common ancestor of D & A). Wait a second, your 3. cousins great-great-grandmothers=20 grandchild is your first cousin once removed, or simply your great-great-grandmothers grandchild. This is because your 3. cousins great-great-grandmother is also=20 your great-great-grandmother. It's like saying "my father's son" which is either myself or my brother, or like "my grandfather's grandson" which could be me, my brother, or my cousin. In short, any relation should be explainable through the=20 closest common ancestor. While there could be many=20 alternative terms (father's son insetad of brother),=20 we don't have to list all of them. A single unambiguous=20 result should be good enough, I think.=20 > [*] is it checked if it is really two common ancestors ? That > would make the difference between a half-brother and a=20 > brother. Not yet, but we should be able to add it in the future. Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Lars Kr.L. <gr...@lk...> - 2004-07-30 16:35:27
|
On Fri, Jul 30, 2004 at 09:07:20AM -0500, Alex Roitman wrote: > Not necessarily C as a person, but definitely number of generations with > the genders of all participants from A to C and from B to C. > > If A is B's > > > 3. cousins great-great- > > > grandmothers grandchild. > > the parsing of the resulting [mf]-string will require knowledge about > > not only A and B, but also D (the 3. cousin), C (the common ancestor of > > B & D) and E (the common ancestor of D & A). > > Wait a second, your 3. cousins great-great-grandmothers > grandchild is your first cousin once removed I apologize for not having expressed my thoughts more clearly. Clearly the current method works and is simple, when A & B have a known common ancestor. However, I think we should try to picture how things may look if GRAMPS have determined that A & B have _no_ known common ancestor and that they are instead related more distantly, f.ex. as in the example I gave above, where (and this is what I forgot to mention) E & C have no known common ancestor. Then GRAMPS will have to have the > number of generations with > the genders of all participants from A to E and from D to E and from D to > C and from B to C. The idea I had was to generate a relationship-path that is complete in its description. So in the above example the string would be a sequence of [mf]+ from A to E, and [ds]+ from E to D, and [mf]+ from D to C, and [ds]+ from C to B. Then that string is complete GRAMPS can translate the string with having to know anything about the generation counts. This is what I meant in my previous mail, but now I have an idea that may be better: Continue to use m and f (and p for a person with unknown gender) for the people in the relationship-path. For the common ancestor insert a meta-character, f.ex. upper-case: M or F for a single common ancestor with known gender P for a single common ancestor with unknown gender (rare) D for double common ancestors (common), i.e. when the common ancestor's two children in the relationship-path also share the other parent (should be a simple check to add). That means that when the parsing of the relationship-path meets a meta-character the interpretation of [mfp] changes from parent to child (or vice-versa) - and in addition there is a simple way to the determine/describe the relationships involving half-brothers/sisters. Anyway, I don't know if we ever want to support these kinds of relationship terms, but I think we should try to ensure that the design of the relationship-calculator will not prevent us from easily adding some functionality that may be wished for later. > > [*] is it checked if it is really two common ancestors ? That > > would make the difference between a half-brother and a > > brother. > > Not yet, but we should be able to add it in the future. Sounds good - especially since I would not yet know how to express these half-relationship terms in Danish :-) Now that I started, how about more tricky relationships like the following: A and a are sisters and B and b are brothers. A and B have a child C, and a and b have a child c. Now C and c are cousins through all 4 of their grandparents! How would we handle that? Have a nice week-end. -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Alex R. <sh...@al...> - 2004-07-30 17:23:49
|
On 07/30/2004 11:35:20 AM, Lars Kr. Lundin wrote: > > Clearly the current method works and is simple, > when A & B have a known common ancestor. >=20 > However, I think we should try to picture how things may look if > GRAMPS have determined that A & B have _no_ known common ancestor > and that they are instead related more distantly, f.ex. as in the > example I gave above, where (and this is what I forgot to mention) > E & C have no known common ancestor. >=20 > Then GRAMPS will have to have the > > number of generations with > > the genders of all participants from A to > E and from D to E and from D to > > C and from B to C. >=20 > The idea I had was to generate a relationship-path that is complete > in its description. So in the above example the string would be a > sequence of > [mf]+ from A to E, and > [ds]+ from E to D, and > [mf]+ from D to C, and > [ds]+ from C to B. >=20 > Then that string is complete GRAMPS can translate the string with > having to know anything about the generation counts. Lars, It seems to me that, if A and B have no common ancestor then we cannot determine their relationship at all. This is because there's no way to find out that e.g. E is a brother to A except when they are both children of the same person, D. Same aboun=20 cousins, nephews, and the like. Had we had the "brother", "cousin",=20 "nephew", and other tags in the database then we could have done=20 that. Currently, the only blood relations recorded in the database are child-parent. So, our only chance to track a relationship is through a common ancestor.=20 > This is what I meant in my previous mail, but now I have an idea > that may be better: > Continue to use m and f (and p for a person with unknown gender) > for the people in the relationship-path. > For the common ancestor insert a meta-character, f.ex. upper-case: > M or F for a single common ancestor with known gender > P for a single common ancestor with unknown gender (rare) > D for double common ancestors (common), i.e. when the common > ancestor's two children in the relationship-path also share the > other parent (should be a simple check to add). >=20 > That means that when the parsing of the relationship-path meets > a meta-character the interpretation of [mfp] changes from > parent to child (or vice-versa) - and in addition there is a > simple way to the determine/describe the relationships involving > half-brothers/sisters. Sure, this makes sense.=20 > Anyway, I don't know if we ever want to support these kinds of > relationship terms, but I think we should try to ensure that the > design of the relationship-calculator will not prevent us from > easily adding some functionality that may be wished for later. Sure.=20 > Now that I started, how about more tricky relationships > like the following: > A and a are sisters and > B and b are brothers. >=20 > A and B have a child C, and > a and b have a child c. >=20 > Now C and c are cousins through all 4 of their grandparents! >=20 > How would we handle that? Hey, this is too tricky for a poor computer :-) Seriously, we can report one (possibly out of many) correct=20 relationship term and the list of all closest common ancestors. In this case, there will be four closest common ancestors (usually two, sometimes just one). Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Frode J. <fro...@sk...> - 2004-08-02 06:33:34
|
=46riday 30 July 2004 18:35, wrote Lars Kr.Lundin: > Now that I started, how about more tricky relationships > like the following: > A and a are sisters and > B and b are brothers. > > A and B have a child C, and > a and b have a child c. > > Now C and c are cousins through all 4 of their grandparents! This specific relationship is what Jens talks about in the end of his mail.= In=20 Norwegian it is called dobbels=F8skenbarn (doublecusins) =2D-=20 =2DFrode "The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." -- McCloctnik the Lucid |
From: Lars Kr.L. <gr...@lk...> - 2004-08-03 14:18:02
|
On Fri, Jul 30, 2004 at 12:23:46PM -0500, Alex Roitman wrote: > It seems to me that, if A and B have no common ancestor then we > cannot determine their relationship at all. Are you sure about this? Let us take a simple example: A and B have no known common ancestor. A is the maternal grandfather of C. B is the paternal grandfather of C. The parents of C are not married. Given A and B the relationship-calculator of GRAMPS would currently bail out with something to the effect: A and B are not related. Surely the internal data structure of GRAMPS would allow a function to examine any children of person X. By repeated calls to this function it could be determined that A and B are related through their grandchild C (and possibly through additional grandchildren). It is basically the same approach as for finding a closest common ancestor, except that the two trees that need to be traversed are not binary. I have been looking at the python code and thought more about the internal representation of the relationship path. When GRAMPS searches for a common ancestor of A and B, I can see how it is natural to represent each of those two paths with the [fmp] characters (denoting one of father, mother or parent with unknown gender). Suppose GRAMPS keeps the [fmp] characters to build the two relationship paths towards the common ancestor. Then we could use the characters [sdc] (son, daughter or child) to represent the two relationship paths towards a common descendant. I made a proposal to use a meta-character to describe the common ancestor(s). If we adopt this approach, we could use meta-characters for the common descendant(s) as well. For the common descendant(s) GRAMPS could use as meta-characters a sequence of one of S: for a son as common descendant D: for a daughter as common descendant C: for a child (with unknown gender) as common descendant So in the above example the relationship can be described by the two paths "d" and "s" with "C" as meta-character. If A and B are both grandfathers of two sons and a daughter their relationship could be described by "d", "s" and "SSD", to describe that from A the relationship goes to a daughter to her son + son + daughter back to their father to B. (I consider this relationship stronger than the one where two children of A and B are married, but without children). The translator of some language XYZ could then say: "Aah, but in my language two grandfathers who share exactly two sons and one daughter are each others <some rare relationship term> so I will put that term in rel_XYZ.py" That would be pretty neat. The next step could be the relationship that is not through a common ancestor nor through a common descendant, but though a (childless) marriage. If we introduce another meta-character to represent marriage, f.ex. "=" (a non-letter because there is no individual in this point of the path), we can represent relationships like: My grandsons wifes grandfather with "cs" and "cd" (with "=" as meta-character). The paths "pm", "pf" and "=" would mean that A's grandmother married (someone else than A's grandfather) and that B is the grandson of that husband. Next kind of relationship could be through an ancestor back to a marriage and then further back trough some other ancestors, f.ex. my grandfathers (second) wifes grandfather. That would be represented as one path consisting of [fmp] characters and one with [sdc] characters. Construction of such two paths would require the traversal of A's ancestor tree and the traversal of B's descendant tree (or vice-versa) until a marriage between two persons was found. The two paths would then match [fmp]* and [sdc]* (with "=" as meta-character). F.ex. if B is A's grandsons wifes grandson the two paths would be "cs" and "mp" (with "=" as meta-character). In case someone is still reading: Let us try to imagine a hardcore relationship calculator that simply does not want to call A and B unrelated, even though none of the above applies. Suppose the relationship cannot be described by two relationship paths separated by a meta-character(-string). One way to represent more general relationships could be with three relationship paths separated by two meta-character(-string)s. This would be required to express f.ex. B is A's cousins father-in-law. This could be generalized to N+1 relationship paths separated by N meta-character(-string)s. In large datasets the search for such relationships could require the traversal of not just one pair of ancestor/descendant-trees, but _many_ such pairs. Anyway, I cannot see anything that would keep us from implementing that one day... > > Now that I started, how about more tricky relationships > > like the following: > > A and a are sisters and > > B and b are brothers. > > > > A and B have a child C, and > > a and b have a child c. > > > > Now C and c are cousins through all 4 of their grandparents! > > > > How would we handle that? (The above "double cousinship" is actually not that rare). Once a closest ancestor is found, determining whether or not there are more equally close common ancestors requires some additional (but limited) checking that can be added at a later stage. -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Alex R. <sh...@al...> - 2004-08-04 04:32:37
|
Lars, On Tue, Aug 03, 2004 at 02:17:16PM -0000, Lars Kr.Lundin wrote: > On Fri, Jul 30, 2004 at 12:23:46PM -0500, Alex Roitman wrote: >=20 > > It seems to me that, if A and B have no common ancestor then we > > cannot determine their relationship at all. >=20 > Are you sure about this? Not completely, but it seemed like a right idea to me at the time :-) > Let us take a simple example: > A and B have no known common ancestor. > A is the maternal grandfather of C. > B is the paternal grandfather of C. > The parents of C are not married. >=20 > Given A and B the relationship-calculator of GRAMPS would > currently bail out with something to the effect: > A and B are not related. >=20 > Surely the internal data structure of GRAMPS would allow a function > to examine any children of person X. By repeated calls to this > function it could be determined that A and B are related through > their grandchild C (and possibly through additional grandchildren). So, it eventually comes down to the question of what we call a relation.=20 You are proposing to call two people related when they have a common descendant. This means that I am related to my mother in law. This may be a proper relationship in most cultures. But what about the former mother in law? She's still a grandmom of my daughter, but should I consider her my relative?=20 > It is basically the same approach as for finding a closest common > ancestor, except that the two trees that need to be traversed are > not binary. Right, it includes a closest common descendant. > I have been looking at the python code and thought more about the > internal representation of the relationship path. >=20 > When GRAMPS searches for a common ancestor of A and B, I can see how > it is natural to represent each of those two paths with the [fmp] > characters (denoting one of father, mother or parent with unknown gender). >=20 > Suppose GRAMPS keeps the [fmp] characters to build the two relationship > paths towards the common ancestor. >=20 > Then we could use the characters [sdc] (son, daughter or child) to > represent the two relationship paths towards a common descendant. >=20 > I made a proposal to use a meta-character to describe the common > ancestor(s). If we adopt this approach, we could use meta-characters > for the common descendant(s) as well. >=20 > For the common descendant(s) GRAMPS could use as meta-characters a > sequence of one of > S: for a son as common descendant > D: for a daughter as common descendant > C: for a child (with unknown gender) as common descendant >=20 > So in the above example the relationship can be described by the > two paths "d" and "s" with "C" as meta-character. >=20 > If A and B are both grandfathers of two sons and a daughter > their relationship could be described by "d", "s" and "SSD", to > describe that from A the relationship goes to a daughter to her > son + son + daughter back to their father to B. (I consider this > relationship stronger than the one where two children of A and B > are married, but without children). >=20 > The translator of some language XYZ could then say: > "Aah, but in my language two grandfathers who share exactly two > sons and one daughter are each others <some rare relationship term> > so I will put that term in rel_XYZ.py" >=20 > That would be pretty neat. Before we discuss the concrete implementation details I'd like to be clear on the final goal. I think the idea of people being related through a common descendant is something that needs to be discussed a bit before we go and implement it. Yes, some may consider their former mother in law a relative. But she's also a relative to my grandmother using same standards, and this sounds like a stretch to me :-) Does it sit well with everybody to use common descendant criterion? (There's nothing wrong with the implementation, BTW, I like it a lot.=20 Just wanted to get the first thing first).=20 > The next step could be the relationship that is not through > a common ancestor nor through a common descendant, but though a > (childless) marriage. >=20 > If we introduce another meta-character to represent marriage, > f.ex. "=3D" (a non-letter because there is no individual in this point > of the path), we can represent relationships like: > My grandsons wifes grandfather with > "cs" and "cd" (with "=3D" as meta-character). >=20 > The paths "pm", "pf" and "=3D" would mean that A's grandmother married > (someone else than A's grandfather) and that B is the grandson of that > husband. This brings a set of questions I like to ask every time we start talking=20 about marriage-based relations. Is my former wife a relative to me? What about her present husband? What about his former wife? And what about her present husband? We can get more and more remote people=20 in this chain. This brings both the problems of detecting a relationship (a quite severe problem, if you think about it: no longer you can traverse a single ancestral-descendant line, but rather you have to examine endless possible marriages). It also brings up a problem of what we call a relation. One can argue that there's nothing relating myself and my former wife's husband, let alone his former wife.=20 > Next kind of relationship could be through an ancestor back to > a marriage and then further back trough some other ancestors, f.ex. > my grandfathers (second) wifes grandfather. That would be represented > as one path consisting of [fmp] characters and one with > [sdc] characters. Construction of such two paths would require the > traversal of A's ancestor tree and the traversal of B's descendant > tree (or vice-versa) until a marriage between two persons was found. I think my questions above undermine the usefulness of such relationship types, at least in some cases.=20 > The two paths would then match [fmp]* and [sdc]* (with "=3D" as > meta-character). >=20 > F.ex. if B is A's grandsons wifes grandson the two paths would be > "cs" and "mp" (with "=3D" as meta-character). >=20 > In case someone is still reading: >=20 > Let us try to imagine a hardcore relationship calculator > that simply does not want to call A and B unrelated, > even though none of the above applies. I see -- if the never-failing tool is an idea then the above makes sense :-) > Suppose the relationship cannot be described by two relationship > paths separated by a meta-character(-string). >=20 > One way to represent more general relationships could be with > three relationship paths separated by two meta-character(-string)s. > This would be required to express f.ex. > B is A's cousins father-in-law. >=20 > This could be generalized to N+1 relationship paths separated by N > meta-character(-string)s. >=20 > In large datasets the search for such relationships could require > the traversal of not just one pair of ancestor/descendant-trees, > but _many_ such pairs. An almost infinite amount, since one has to consider all possible ways A is related to B: married, A's ancestor married to B, A's ancestor married to B's ancestor, A's ancestor married to B's descendant,=20 A's ancestor married to somebody married to B (at some point),=20 A's ancestor married to somebody married to B's ancestor, ... > Anyway, I cannot see anything that would keep us from implementing > that one day... O brother, I feared that :-))) > > > Now that I started, how about more tricky relationships > > > like the following: > > > A and a are sisters and > > > B and b are brothers. > > >=20 > > > A and B have a child C, and > > > a and b have a child c. > > >=20 > > > Now C and c are cousins through all 4 of their grandparents! > > >=20 > > > How would we handle that? >=20 > (The above "double cousinship" is actually not that rare). > Once a closest ancestor is found, determining whether or not there > are more equally close common ancestors requires some additional > (but limited) checking that can be added at a later stage. This is an easy problem, especially compared to the all-married=20 possibilities :-) While being big at criticizing the marriage-based relationships, I don't=20 have a good answer to the problem. It would certainly be useful to list spouses of my aunts and cousins, since they are part of the family. Is there any simple solution I'm missing? Some criteria on whom to include to make it sane (and avoid my former wife's husband's former wif= e?) Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Runar P. <ru...@ru...> - 2004-08-05 12:09:07
|
When writing my own analysis tools (pre Gramps), I created two types of "relationship" calculators. The first did the same thing as Gramps currently does--calculated blood relation. The second was much more experimental, but tried to answer the question, how are these two individuals "connected". I used the term connected as in basic graph theory--this is after all, just a simple graph--and traversed the graph in all directions away from the starting node (parents, children, spouses), identifying all the path's to the second node. There are fairly efficient algorithms out there for that. This resulted in some interesting, and fun, facts. I think this type of tool in Gramps would be useful, but I don't think it should be an "upgrade" to the relationship calculator--it's a completely different animal. Runar -----Original Message----- From: Alex Roitman [mailto:sh...@al...] Sent: Wednesday, August 04, 2004 12:33 AM To: Lars Kr.Lundin Cc: gra...@li... Subject: Re: [Gramps-devel] Scandinavian (and not only) relationship calculators Lars, On Tue, Aug 03, 2004 at 02:17:16PM -0000, Lars Kr.Lundin wrote: > On Fri, Jul 30, 2004 at 12:23:46PM -0500, Alex Roitman wrote: > > > It seems to me that, if A and B have no common ancestor then we > > cannot determine their relationship at all. > > Are you sure about this? Not completely, but it seemed like a right idea to me at the time :-) > Let us take a simple example: > A and B have no known common ancestor. > A is the maternal grandfather of C. > B is the paternal grandfather of C. > The parents of C are not married. > > Given A and B the relationship-calculator of GRAMPS would currently > bail out with something to the effect: > A and B are not related. > > Surely the internal data structure of GRAMPS would allow a function to > examine any children of person X. By repeated calls to this function > it could be determined that A and B are related through their > grandchild C (and possibly through additional grandchildren). So, it eventually comes down to the question of what we call a relation. You are proposing to call two people related when they have a common descendant. This means that I am related to my mother in law. This may be a proper relationship in most cultures. But what about the former mother in law? She's still a grandmom of my daughter, but should I consider her my relative? > It is basically the same approach as for finding a closest common > ancestor, except that the two trees that need to be traversed are not > binary. Right, it includes a closest common descendant. > I have been looking at the python code and thought more about the > internal representation of the relationship path. > > When GRAMPS searches for a common ancestor of A and B, I can see how > it is natural to represent each of those two paths with the [fmp] > characters (denoting one of father, mother or parent with unknown gender). > > Suppose GRAMPS keeps the [fmp] characters to build the two > relationship paths towards the common ancestor. > > Then we could use the characters [sdc] (son, daughter or child) to > represent the two relationship paths towards a common descendant. > > I made a proposal to use a meta-character to describe the common > ancestor(s). If we adopt this approach, we could use meta-characters > for the common descendant(s) as well. > > For the common descendant(s) GRAMPS could use as meta-characters a > sequence of one of > S: for a son as common descendant > D: for a daughter as common descendant > C: for a child (with unknown gender) as common descendant > > So in the above example the relationship can be described by the two > paths "d" and "s" with "C" as meta-character. > > If A and B are both grandfathers of two sons and a daughter their > relationship could be described by "d", "s" and "SSD", to describe > that from A the relationship goes to a daughter to her son + son + > daughter back to their father to B. (I consider this relationship > stronger than the one where two children of A and B are married, but > without children). > > The translator of some language XYZ could then say: > "Aah, but in my language two grandfathers who share exactly two sons > and one daughter are each others <some rare relationship term> so I > will put that term in rel_XYZ.py" > > That would be pretty neat. Before we discuss the concrete implementation details I'd like to be clear on the final goal. I think the idea of people being related through a common descendant is something that needs to be discussed a bit before we go and implement it. Yes, some may consider their former mother in law a relative. But she's also a relative to my grandmother using same standards, and this sounds like a stretch to me :-) Does it sit well with everybody to use common descendant criterion? (There's nothing wrong with the implementation, BTW, I like it a lot. Just wanted to get the first thing first). > The next step could be the relationship that is not through a common > ancestor nor through a common descendant, but though a > (childless) marriage. > > If we introduce another meta-character to represent marriage, f.ex. > "=" (a non-letter because there is no individual in this point of the > path), we can represent relationships like: > My grandsons wifes grandfather with > "cs" and "cd" (with "=" as meta-character). > > The paths "pm", "pf" and "=" would mean that A's grandmother married > (someone else than A's grandfather) and that B is the grandson of that > husband. This brings a set of questions I like to ask every time we start talking about marriage-based relations. Is my former wife a relative to me? What about her present husband? What about his former wife? And what about her present husband? We can get more and more remote people in this chain. This brings both the problems of detecting a relationship (a quite severe problem, if you think about it: no longer you can traverse a single ancestral-descendant line, but rather you have to examine endless possible marriages). It also brings up a problem of what we call a relation. One can argue that there's nothing relating myself and my former wife's husband, let alone his former wife. > Next kind of relationship could be through an ancestor back to a > marriage and then further back trough some other ancestors, f.ex. > my grandfathers (second) wifes grandfather. That would be represented > as one path consisting of [fmp] characters and one with [sdc] > characters. Construction of such two paths would require the traversal > of A's ancestor tree and the traversal of B's descendant tree (or > vice-versa) until a marriage between two persons was found. I think my questions above undermine the usefulness of such relationship types, at least in some cases. > The two paths would then match [fmp]* and [sdc]* (with "=" as > meta-character). > > F.ex. if B is A's grandsons wifes grandson the two paths would be "cs" > and "mp" (with "=" as meta-character). > > In case someone is still reading: > > Let us try to imagine a hardcore relationship calculator that simply > does not want to call A and B unrelated, even though none of the above > applies. I see -- if the never-failing tool is an idea then the above makes sense :-) > Suppose the relationship cannot be described by two relationship paths > separated by a meta-character(-string). > > One way to represent more general relationships could be with three > relationship paths separated by two meta-character(-string)s. > This would be required to express f.ex. > B is A's cousins father-in-law. > > This could be generalized to N+1 relationship paths separated by N > meta-character(-string)s. > > In large datasets the search for such relationships could require the > traversal of not just one pair of ancestor/descendant-trees, but > _many_ such pairs. An almost infinite amount, since one has to consider all possible ways A is related to B: married, A's ancestor married to B, A's ancestor married to B's ancestor, A's ancestor married to B's descendant, A's ancestor married to somebody married to B (at some point), A's ancestor married to somebody married to B's ancestor, ... > Anyway, I cannot see anything that would keep us from implementing > that one day... O brother, I feared that :-))) > > > Now that I started, how about more tricky relationships like the > > > following: > > > A and a are sisters and > > > B and b are brothers. > > > > > > A and B have a child C, and > > > a and b have a child c. > > > > > > Now C and c are cousins through all 4 of their grandparents! > > > > > > How would we handle that? > > (The above "double cousinship" is actually not that rare). > Once a closest ancestor is found, determining whether or not there are > more equally close common ancestors requires some additional (but > limited) checking that can be added at a later stage. This is an easy problem, especially compared to the all-married possibilities :-) While being big at criticizing the marriage-based relationships, I don't have a good answer to the problem. It would certainly be useful to list spouses of my aunts and cousins, since they are part of the family. Is there any simple solution I'm missing? Some criteria on whom to include to make it sane (and avoid my former wife's husband's former wife?) Alex -- Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Alex R. <sh...@al...> - 2004-08-05 14:19:54
|
Runar, On 08/05/2004 07:08:55 AM, Runar Petursson wrote: > When writing my own analysis tools (pre Gramps), I created two types of > "relationship" calculators. The first did the same thing as Gramps > currently does--calculated blood relation. The second was much more > experimental, but tried to answer the question, how are these two > individuals "connected". I used the term connected as in basic graph > theory--this is after all, just a simple graph--and traversed the graph in > all directions away from the starting node (parents, children, spouses), > identifying all the path's to the second node. There are fairly efficient > algorithms out there for that. This resulted in some interesting, and fu= n, > facts. =20 I would be very curious to see your tool that does that in an efficient way. Especially, how the former spouses (and their former/present spouses) are treated in regards to connections.=20 > I think this type of tool in Gramps would be useful, but I don't think it > should be an "upgrade" to the relationship calculator--it's a completely > different animal. Absolutley! If there's a chance to see what you've done it would be great! Thanks, Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Lars Kr.L. <gr...@lk...> - 2004-08-05 14:48:40
|
On Thu, Aug 05, 2004 at 08:08:55AM -0400, Runar Petursson wrote: > When writing my own analysis tools (pre Gramps), I created two types of > "relationship" calculators. The first did the same thing as Gramps > currently does--calculated blood relation. The second was much more > experimental, but tried to answer the question, how are these two > individuals "connected". I used the term connected as in basic graph > theory--this is after all, just a simple graph--and traversed the graph in > all directions away from the starting node (parents, children, spouses), > identifying all the path's to the second node. There are fairly efficient > algorithms out there for that. This resulted in some interesting, and fun, > facts. > > I think this type of tool in Gramps would be useful, but I don't think it > should be an "upgrade" to the relationship calculator--it's a completely > different animal. I think this view of related versus connected is very useful, especially after the questions Alex posed. A connnection calculator implemented as a separate plugin/function would be very interesting (for me). -Lars Lundin. -- GEDCOMP: An extensive and free database for genealogists with interest in Denmark: http://www.lklundin.dk/gedcomp/ |
From: Don A. <don...@co...> - 2004-07-28 11:49:28
|
On Wed, 2004-07-28 at 01:49, Lars Kr.Lundin wrote: > On Mon, Jul 26, 2004 at 08:40:06PM -0500, Alex Roitman wrote: > > > Finnish relationship calculator plugin has been added to the STABLE CVS branch > > today, thanks to the input from Eero Tamminen. > > Is this a correct command for checking out the source > cvs -z3 -d:ext:<myusername>@cvs.sourceforge.net:/cvsroot/gramps co gramps2 ? > - I cannot see a rel_fi.py in the resulting source. :-( This will get you the unstable version. You want: cvs -z3 -d:ext:<username>@cvs.sourceforge.net:/cvsroot/gramps co -r STABLE gramps2 Don |
From: Alex R. <sh...@al...> - 2004-07-28 13:51:51
|
Lars, On Wed, Jul 28, 2004 at 07:49:12AM -0000, Lars Kr.Lundin wrote: >=20 > Is this a correct command for checking out the source > cvs -z3 -d:ext:<myusername>@cvs.sourceforge.net:/cvsroot/gramps co gramps= 2 ? > - I cannot see a rel_fi.py in the resulting source. :-( Add '-r STABLE' between co and gramps2. If you have just checked the unstable tree with the above command, you may instead say $ cvs update -r STABLE in the top-level dir of the tree (gramps2) to switch the whole tree to the STABLE branch.=20 > In Danish many nouns are simply a concatenation between two nouns, > but sometimes also between an adjective and a noun. > Would a future rel_da.py have the necessary information available to > correctly generate a relationship like "lilles?ster" (little sister) ? > (relevant for the concatenation of big/little with brother/sister). Sure -- we can use any information that is in the database. For every person we can find out the birth date, if it is necessary to determine the older-younger relationships.=20 > > So, if somebody steps up (Lars? Jens? Frode?) and provides the input > > we can add another few plugins with almost no development effort. >=20 > OK, we need support for this exciting functionality - and I can do some > translation (including strings in a .py file). My Finnish is however only > at the beer-ordering level, so hopefully rel_fi.py can be understood by > English readers. I haven't heavily commented it, but it should be more-or-less clear what is what. BTW, it's all written in English (well, its Python dialect,= =20 to be precise :-) with few Finnish words here and there :-) > Wouldn't it be a good idea to try an identify similarities between the > various rel_*.py and handle these similarities with common functions and > translated strings ? I absolutely agree that it would. The exact nature of what is common will become apparent when there's more plugins available. At the moment, all of them but Finnish use a common function that determines whether the two people are related and how many generations away they are =66rom their closest common ancestor. English, German, Hungarian, Italian, and Russian could all use this function. With Finnish, knowing how many generations away the person is from the common ancestor didn't quite work, because all the genders of people between the common ancestor and a person must be known. So, that function had to be rewritten. What the re-written version does is to append the person's gender to the=20 string as we traverse the ancestor line(s), instead of just adding 1 to=20 the count. Then the number of generations will be equal to the length of the resulting string ('ffmfm'=3D=3D father father mother father mother), and the gender sequence can be easily unrolled. But IMHO we can optimize the code later, once it works and works correctly. As Donald Knuth teaches us about programming, the premature optimization is evil :-) What I would like to do is to write rel_da.py (based on rel_fi.py) and then, if a lot of similarities will exist, maybe create a prototype =66rom which both plugins will use the parts. Definitely so if more than two plugins will share a lot, like Swedish and Norwegian. So, cutting to the bottom, I would be glad to help writing rel_da.py but I need you to fill me in on the details. Lars, please feel free to email me privately with the rules for forming the kinship terms. I have a sample diagram Eero sent me, so I can send it to you if you'd like and you can convert it to Danish terms. If you'd like to write the plugin yourself, please feel free to ask about the details. > The ease with which such capability can be added demonstrates the > strength of the underlying design of GRAMPS. Yes, we all owe this to Don :-) Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |