From: Brian M. <br...@gr...> - 2010-01-06 17:34:35
|
> The only thing I would add is > provision for people for whom no death > date is reasonably calculable. For example I have > some Welsh > ancestors who lived sometime prior to the Norman Invasion > of England > with no dates (not even unreliable ones) for many > generations > thereafter. However, I am confident that all are > dead! The tool should be able to figure that out. The basis would be "Omar Smith is probably dead because his brother has an 8th grandson who was born in 1945". Obviously, it wouldn't make sense to estimate a date with any more accuracy than a century, but the tool could confidently add a death event with no date. ~Brian |
From: Frederico M. <fs...@gm...> - 2010-01-06 16:59:06
|
Hi, 2010/1/6 Brian Matherly <br...@gr...>: > (...) > I could support a tool that adds death events to my database, but I am *very* particular about the integrity of my data > and my ability to trace data back to its source. > (...) This is just a general comment (I just picked this message to plug mine into)... I'm only understanding half of the debate and I understand that this also concerns the implications of doing calculations on a version that has to make real-time calculations, etc. In any event I just wanted to say that regardless of what the final outcome is I hope that that "Calculate Estimate Dates" tool is maintained since it does everything I need concerning most of the issues being raised, and does so in a way that clearly indicates the source of the added events. Apart from possible improvements in the algorithm that does the calculations and changes (if needed) I consider that tool, as is it right now, extremely useful and one which I use constantly. Regards, Frederico |
From: Doug B. <dou...@gm...> - 2010-01-06 19:20:32
|
On Wed, Jan 6, 2010 at 11:58 AM, Frederico Muñoz <fs...@gm...> wrote: > Hi, > > 2010/1/6 Brian Matherly <br...@gr...>: > > (...) > > I could support a tool that adds death events to my database, but I am > *very* particular about the integrity of my data > > and my ability to trace data back to its source. > > (...) > > This is just a general comment (I just picked this message to plug > mine into)... I'm only understanding half of the debate and I > understand that this also concerns the implications of doing > calculations on a version that has to make real-time calculations, > etc. > > In any event I just wanted to say that regardless of what the final > outcome is I hope that that "Calculate Estimate Dates" tool is > maintained since it does everything I need concerning most of the > issues being raised, and does so in a way that clearly indicates the > source of the added events. Apart from possible improvements in the > algorithm that does the calculations and changes (if needed) I > consider that tool, as is it right now, extremely useful and one which > I use constantly. > > Regards, > > Frederico > > Thanks, Frederico. We don't always know what users use, nor what they like in the vast collection of tools, reports, and gramplets that come with Gramps. So, this is useful, and appreciated! I think what we are talking about will make this an even better tool. But, please let us know if it is--- or isn't! -Doug > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Frederico M. <fs...@gm...> - 2010-01-06 20:08:22
|
Hi, > Thanks, Frederico. We don't always know what users use, nor what they like > in the vast collection of tools, reports, and gramplets that come with > Gramps. So, this is useful, and appreciated! It's my pleasure, really > I think what we are talking about will make this an even better tool. But, > please let us know if it is--- or isn't! One of the reasons why I said I wasn't really understanding the topic is because some of it makes more sense when one assumes that the Calculate Estimated Dates tool *doesn't* exist. It seemed to me - and this is likely a bad interpretation on my part - as if a good chunk of the conversation is about creating a new tool that does what the CED tool does (apart from the issues regarding the applicability of the mechanism to gramps-connects, which I understand), even if the first mail referenced CED. Now, I'm all for enhancing the CED tool to make it behave in a way which serves the needs of more people better, adding additional features (like the interactive selection), etc. I do think that in terms of "process" the tool behaves as it should: it adds events with a "calculated about" date and marks the events with a custom source. If one doesn't want events to be added then one shouldn't use the tool, since that's pretty much what the objective of the tool is. One possible addition would be to use it to generate marriage events: one of the most common uses I make of a calculator is subtracting 16 from the earliest recorded birth of a couple in order to obtain a "calculated before" date which will allow me to start searching from that date down in the marriage registries. One issue I have with the CED tool is that it insists on adding a death event on a few family members which are alive, since their age higher than average. Not sure how to solve this, but it's likely something that related to the discussion concerning the probably_alive issue. Regards, Frederico |
From: Benny M. <ben...@gm...> - 2010-01-06 21:17:30
|
2010/1/6 Frederico Muñoz <fs...@gm...>: > Hi, > >> Thanks, Frederico. We don't always know what users use, nor what they like >> in the vast collection of tools, reports, and gramplets that come with >> Gramps. So, this is useful, and appreciated! > > It's my pleasure, really > >> I think what we are talking about will make this an even better tool. But, >> please let us know if it is--- or isn't! > > One of the reasons why I said I wasn't really understanding the topic > is because some of it makes more sense when one assumes that the > Calculate Estimated Dates tool *doesn't* exist. It seemed to me - and > this is likely a bad interpretation on my part - as if a good chunk of > the conversation is about creating a new tool that does what the CED > tool does (apart from the issues regarding the applicability of the > mechanism to gramps-connects, which I understand), even if the first > mail referenced CED. It's about a fast way to use probably alive in other parts of gramps, while maintaining the tool. Present probably alive function is popular so starts to be used in places where users would have performance issues using Gramps depending on their data and practice. Obviously, if you have used CED to add estimated dates, you will probably have no problems, but users not having used the tool will have problems. Benny > > Now, I'm all for enhancing the CED tool to make it behave in a way > which serves the needs of more people better, adding additional > features (like the interactive selection), etc. I do think that in > terms of "process" the tool behaves as it should: it adds events with > a "calculated about" date and marks the events with a custom source. > If one doesn't want events to be added then one shouldn't use the > tool, since that's pretty much what the objective of the tool is. > > One possible addition would be to use it to generate marriage events: > one of the most common uses I make of a calculator is subtracting 16 > from the earliest recorded birth of a couple in order to obtain a > "calculated before" date which will allow me to start searching from > that date down in the marriage registries. > > One issue I have with the CED tool is that it insists on adding a > death event on a few family members which are alive, since their age > higher than average. Not sure how to solve this, but it's likely > something that related to the discussion concerning the probably_alive > issue. > > Regards, > > Frederico > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jon C. <jo...@go...> - 2010-01-06 21:24:43
|
My user's comments: <quote> The potential problem involving ‘estimated death dates’ and ‘private’ is abuse of information to the detriment of the individual concerned. There is justification for an aid to selection for export of information such that details of living individuals, or of those that might still be living, are excluded from the export file but retained in the source database. The private flag is already available and fully adequate for such purpose. All that should be at issue is the extent to which setting the private flag can be aided by code rather than set manually in every case. 1. The privacy flag may be appropriate if, say, it is desired to avoid the admission/broadcasting of illegitimacy, bigamy or such like – regardless of death date. This requires the facility to set a privacy flag manually, according to circumstances. No program can deal with this situation by a preset collection of rules, so don’t attempt it for this situation. However the code should ensure that if an entire individual is to ‘disappear’ traces should not be left in what is exported, such as in the spouse’s record (eg bigamy) or the parents’ record (eg illegitimacy). 2. A further ‘validation’ program should be available where it is desired to exclude living people from export. For those whose death dates are not known (either through ignorance or because the individuals are still extant) but whose birth dates are, the ‘validation’ program should display details and allow the manual setting of a private flag. 3. To assist with b) for large incomplete databases, the ‘validation’ program should provide i) an option to set the private flag for all whose death dates are not known or ii) provide a display in which privacy flag setting can be set/changed manually for all those without death dates. 4. For c ii) above the display should allow filtering for i) with or without birth dates and ii) for those with birth dates by manually selected maximum current age. 5. The program should also allow for bulk setting or removal of the privacy flag for all displayed entries. 6. The validation programme should also allow the selection of an individual and for validation to apply, by selection, to all individuals up to and including a selected subsequent generation or to all individuals after that selection. IN NO CIRCUMSTANCES should the database be contaminated with unattributable and spurious data based on computer algorithm, however sophisticated. </quote> Cheers, Jon. Benny Malengier wrote: > 2010/1/6 Frederico Muñoz <fs...@gm...>: > >> Hi, >> >> >>> Thanks, Frederico. We don't always know what users use, nor what they like >>> in the vast collection of tools, reports, and gramplets that come with >>> Gramps. So, this is useful, and appreciated! >>> >> It's my pleasure, really >> >> >>> I think what we are talking about will make this an even better tool. But, >>> please let us know if it is--- or isn't! >>> >> One of the reasons why I said I wasn't really understanding the topic >> is because some of it makes more sense when one assumes that the >> Calculate Estimated Dates tool *doesn't* exist. It seemed to me - and >> this is likely a bad interpretation on my part - as if a good chunk of >> the conversation is about creating a new tool that does what the CED >> tool does (apart from the issues regarding the applicability of the >> mechanism to gramps-connects, which I understand), even if the first >> mail referenced CED. >> > > It's about a fast way to use probably alive in other parts of gramps, > while maintaining the tool. Present probably alive function is popular > so starts to be used in places where users would have performance > issues using Gramps depending on their data and practice. > Obviously, if you have used CED to add estimated dates, you will > probably have no problems, but users not having used the tool will > have problems. > > Benny > >> Now, I'm all for enhancing the CED tool to make it behave in a way >> which serves the needs of more people better, adding additional >> features (like the interactive selection), etc. I do think that in >> terms of "process" the tool behaves as it should: it adds events with >> a "calculated about" date and marks the events with a custom source. >> If one doesn't want events to be added then one shouldn't use the >> tool, since that's pretty much what the objective of the tool is. >> >> One possible addition would be to use it to generate marriage events: >> one of the most common uses I make of a calculator is subtracting 16 >> from the earliest recorded birth of a couple in order to obtain a >> "calculated before" date which will allow me to start searching from >> that date down in the marriage registries. >> >> One issue I have with the CED tool is that it insists on adding a >> death event on a few family members which are alive, since their age >> higher than average. Not sure how to solve this, but it's likely >> something that related to the discussion concerning the probably_alive >> issue. >> >> Regards, >> >> Frederico >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Gerald B. <ger...@gm...> - 2010-01-06 21:35:22
|
On Wed, Jan 6, 2010 at 4:24 PM, Jon Clements <jo...@go...> wrote: > My user's comments: > > <quote> > > The potential problem involving ‘estimated death dates’ and ‘private’ is > abuse of information to the detriment of the individual concerned. There > is justification for an aid to selection for export of information such > that details of living individuals, or of those that might still be > living, are excluded from the export file but retained in the source > database. Already available with the "Living" filter > > The private flag is already available and fully adequate for such > purpose. All that should be at issue is the extent to which setting the > private flag can be aided by code rather than set manually in every case. > > 1. > > The privacy flag may be appropriate if, say, it is desired to > avoid the admission/broadcasting of illegitimacy, bigamy or such > like – regardless of death date. This requires the facility to set > a privacy flag manually, according to circumstances. No program > can deal with this situation by a preset collection of rules, so > don’t attempt it for this situation. However the code should > ensure that if an entire individual is to ‘disappear’ traces > should not be left in what is exported, such as in the spouse’s > record (eg bigamy) or the parents’ record (eg illegitimacy). > > 2. > > A further ‘validation’ program should be available where it is > desired to exclude living people from export. For those whose > death dates are not known (either through ignorance or because the > individuals are still extant) but whose birth dates are, the > ‘validation’ program should display details and allow the manual > setting of a private flag. You can filter on people that are considered alive, then manually set them private (or not) or fix their birth and death dates, which is even better In essence, the validation program is gramps itself. > > 3. > > To assist with b) for large incomplete databases, the ‘validation’ > program should provide i) an option to set the private flag for > all whose death dates are not known or ii) provide a display in > which privacy flag setting can be set/changed manually for all > those without death dates. Interesting idea, but you can do the same by filtering out folks with no death event or no death date. > > 4. > > For c ii) above the display should allow filtering for i) with or > without birth dates and ii) for those with birth dates by manually > selected maximum current age. Already present > > 5. > > The program should also allow for bulk setting or removal of the > privacy flag for all displayed entries. Doesn't sound like a good idea. There are many reasons for using the private flag. OTOH you can do this relatively easily by using sed on an exported database then reimporting it > > 6. > > The validation programme should also allow the selection of an > individual and for validation to apply, by selection, to all > individuals up to and including a selected subsequent generation > or to all individuals after that selection. Already present in the filters > > IN NO CIRCUMSTANCES should the database be contaminated with > unattributable and spurious data based on computer algorithm, however > sophisticated. Don't think you'll get much agreement on that one. OTOH the CED tool could present recommended changes first then let the user decide which to commit and which not. -- Gerald Britton |
From: Brian M. <br...@gr...> - 2010-01-06 22:50:20
|
> > IN NO CIRCUMSTANCES should the database be > contaminated with > > unattributable and spurious data based on computer > algorithm, however > > sophisticated. > > Don't think you'll get much agreement on that one. He get's 100% agreement from me. > OTOH the CED tool > could present recommended changes first then let the user > decide which > to commit and which not. Right, that is the only way I would find the tool acceptable for my research - if I (the user) make the final decision on exactly what gets committed to the database. ~Brian |
From: Frederico M. <fs...@gm...> - 2010-01-06 23:42:11
|
Hello, 2010/1/6 Brian Matherly <br...@gr...>: >(...) >> OTOH the CED tool >> could present recommended changes first then let the user >> decide which >> to commit and which not. > Right, that is the only way I would find the tool acceptable for my research - if I (the user) make the final > decision on exactly what gets committed to the database. As long as there is an option to apply it to everyone ("select all" or something) I wouldn't mind that. If not it would be extremely time consuming to check every change, especially since I use the tool exactly due to the automated way it works. Regards, Frederico |
From: Benny M. <ben...@gm...> - 2010-01-07 08:35:27
|
2010/1/7 Frederico Muñoz <fs...@gm...>: > Hello, > > 2010/1/6 Brian Matherly <br...@gr...>: >>(...) >>> OTOH the CED tool >>> could present recommended changes first then let the user >>> decide which >>> to commit and which not. >> Right, that is the only way I would find the tool acceptable for my research - if I (the user) make the final >> decision on exactly what gets committed to the database. > > As long as there is an option to apply it to everyone ("select all" or > something) I wouldn't mind that. If not it would be extremely time > consuming to check every change, especially since I use the tool > exactly due to the automated way it works. For my research seeing the changes that will be done before having them applied is also a must. Several tools already follow this approach. I know I can first backup, ...., but I find that too cumbersome. Benny |
From: derHeinzi <hei...@ya...> - 2010-01-08 16:55:10
|
Benny Malengier wrote: > > For my research seeing the changes that will be done before having > them applied is also a must. > Several tools already follow this approach. I know I can first backup, > ...., but I find that too cumbersome. > To give a feedback as a user: I would never use such a tool that alters my data. I can identify all I need using the filters and edit the found entries by hand. In my opinion it would be more useful to enhance the relationship calculator (and the display in the status line) to show married relationships. So if I select the wife of my uncle it should show "Aunt (by marriage)" and not "not related". Heinz -- View this message in context: http://old.nabble.com/Re%3A-Probably-alive-tp27046516p27079061.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Jérôme <rom...@ya...> - 2010-01-08 17:27:34
|
> to enhance the relationship calculator (and the display in the status line) to show married relationships. So if I select the wife of my uncle it should show "Aunt (by marriage)" and not "not related". Maybe one needs to add a rule on your localized Relationship calculator ? Does main english calculator returns something ? > To give a feedback as a user: I would never use such a tool that alters my data. Maybe by providing dialogs like : http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Find_Possible_Duplicate_People... http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Extract_Information_from_Names http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Fix_Capitalization_of_Family_Names... http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Rename_Event_Types or http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Compare_Individual_Events... (which is not a batch modification tool, just for illustrate) So, Gramps does not need to warn the user anymore ? He makes the choice modify data or not and he knows what has been done. Jérôme derHeinzi a écrit : > > > Benny Malengier wrote: >> For my research seeing the changes that will be done before having >> them applied is also a must. >> Several tools already follow this approach. I know I can first backup, >> ...., but I find that too cumbersome. >> > > To give a feedback as a user: I would never use such a tool that alters my > data. I can identify all I need using the filters and edit the found entries > by hand. In my opinion it would be more useful to enhance the relationship > calculator (and the display in the status line) to show married > relationships. So if I select the wife of my uncle it should show "Aunt (by > marriage)" and not "not related". > > Heinz > |
From: Jérôme <rom...@ya...> - 2010-01-26 17:49:50
|
Thank you, alive algorithm is more accurate, :) but I still get some minor errors... * Gramplet "Age on Date" displays 121 years old individuals but I set 110 years (max age) into preferences dialog. True, by setting +/-10 years before/after a date (default 50), limit becomes 110 years. birth : about 1889 death : after 9/3/1969 will return about 121 years on year 2010 ! * Someone married on 1842 (just this family event), noted "alive" [1] * Someone dead (about date) but buried (validated complete date), noted "alive". Same as the first one : to set +/- 10 years and zombie will rest in peace. * On bug-report [2], I used "ALIVE" as surname because gramps thought they were alive, but they cannot be alive. Alive algorithm still list them as alive, so I tried to use "Calculate Estimated Date" tool [3], but it seems that code should not try to translate the column and use it as key : 867091: ERROR: gramps.py: line 120: Unhandled exception Traceback (most recent call last): File "trunk/src/plugins/tool/CalculateEstimatedDates.py", line 397, in select_all select_col = self.table.model_index_of_column[_("Select")] KeyError: u'S\xe9lectionner' or it is an other unicode issue ? True, by making the change on tool ∕_("Select")/("Select")/ I am able to select all keys, but column header is no more translated. So, after running the tool I saw that "ALIVE (but dead)" people are still "there" ! And the individual with only one marriage event on 1842, too. Should I re-open some bug-reports [1][2] ? [1] http://www.gramps-project.org/bugs/view.php?id=2806 [2] http://www.gramps-project.org/bugs/view.php?id=3464 [3] http://www.gramps-project.org/bugs/view.php?id=3464#c12310 > I've just committed a refined probably_alive to Utils. This is still a recursive, intensive algorithm... even more so now than before. This does a few things: > > 1) rewrite of algorithm to be a bit simpler, but more thorough > 2) fixes a few inconsistencies (now uses fallbacks where possible) > 3) fixes a few missing checks (now checks spouses) > 4) share code between CalcEstDates tool and Utils > > It also ends up being a bit more conservative about declaring someone dead, so in some cases your database will have perhaps 10% more people considered alive. You can tweak that by changing the Preferences -> Dates. > > You can use the Calculate Estimated Dates Tool to get an explanation for why gramps thinks someone is alive. > > There is one special case: if you are looking for people probably_alive Today and they have a death event, then they are considered dead no matter what (even if the event doesn't have a date). Therefore, you will get different results if you see who was probably alive yesterday (or last year). The reason for this is that if you have a death event, you know that a person died in the past, but you don't know when. If you look to see if a person was alive in the past (yesterday and prior) then you can say for certain if they were dead then without know a death date. > > Please let me know of anything that looks wrong. Tools to use to test: Probably Alive person filter, Calc Est Date tool, and Age on Date Gramplet. > > The next step is to remove some of the Date Preferences that aren't needed anymore, and remove the probably_alive_old functions from Utils. I was going to make an option to use a fast, non-recursive probably_alive, but I don't think there is a reason to now: one can just calculate estimated dates, and then it will be fast where it can be. Gramps-connect will use a narrower non-recursive definition of probably_alive, but that is irrelevant here. > > -Doug > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Doug B. <dou...@gm...> - 2010-01-26 18:17:10
|
On Tue, Jan 26, 2010 at 12:49 PM, Jérôme <rom...@ya...> wrote: > Thank you, alive algorithm is more accurate, :) > but I still get some minor errors... > > > * Gramplet "Age on Date" displays 121 years old individuals but I set 110 > years (max age) into preferences dialog. > True, by setting +/-10 years before/after a date (default 50), limit > becomes 110 years. > > birth : about 1889 > death : after 9/3/1969 > will return about 121 years on year 2010 ! > So, it looks like for Age on Date we should use the maximum age as a hard cut-off. > * Someone married on 1842 (just this family event), noted "alive" [1] > Interesting... currently we only look at birth and death events (and their fallbacks). We could look at any other event and if the person is in a primary role, use that as evidence as happening *sometime* during their Lifetime. That would catch marriage, and any other. > * Someone dead (about date) but buried (validated complete date), noted > "alive". Same as the first one : to set +/- 10 years and zombie will rest in > peace. > Hmmm. Interesting, again! So in this case, the burial (fallback) has more detail than the death event itself. Arguably, one should adjust the death date to be "before BURIAL-DATE" rather than "about DEATH-DATE". I'm not sure we should do anything here. > * On bug-report [2], I used "ALIVE" as surname because gramps thought they > were alive, but they cannot be alive. > Alive algorithm still list them as alive, so I tried to use "Calculate > Estimated Date" tool [3], but it seems that code should not try to translate > the column and use it as key : > > 867091: ERROR: gramps.py: line 120: Unhandled exception > Traceback (most recent call last): > File "trunk/src/plugins/tool/CalculateEstimatedDates.py", line 397, in > select_all > select_col = self.table.model_index_of_column[_("Select")] > KeyError: u'S\xe9lectionner' > That looks like an error in CED. I'll look at that. > > or it is an other unicode issue ? > > True, by making the change on tool /_("Select")/("Select")/ > I am able to select all keys, but column header is no more translated. > > So, after running the tool I saw that "ALIVE (but dead)" people are still > "there" ! And the individual with only one marriage event on 1842, too. > > > Should I re-open some bug-reports [1][2] ? > I'll look at these, but if you have a good test database that would be helpful. Just mark their surnames as "Should be Alive". You can make their Given names be descriptive too: "Born before 1847", "Married on 1799/1/1", etc. Thanks, Jérôme! -Doug > > > > [1] http://www.gramps-project.org/bugs/view.php?id=2806 > [2] http://www.gramps-project.org/bugs/view.php?id=3464 > [3] http://www.gramps-project.org/bugs/view.php?id=3464#c12310 > > > I've just committed a refined probably_alive to Utils. This is still a >> recursive, intensive algorithm... even more so now than before. This does a >> few things: >> >> 1) rewrite of algorithm to be a bit simpler, but more thorough >> 2) fixes a few inconsistencies (now uses fallbacks where possible) >> 3) fixes a few missing checks (now checks spouses) >> 4) share code between CalcEstDates tool and Utils >> >> It also ends up being a bit more conservative about declaring someone >> dead, so in some cases your database will have perhaps 10% more people >> considered alive. You can tweak that by changing the Preferences -> Dates. >> >> You can use the Calculate Estimated Dates Tool to get an explanation for >> why gramps thinks someone is alive. >> >> There is one special case: if you are looking for people probably_alive >> Today and they have a death event, then they are considered dead no matter >> what (even if the event doesn't have a date). Therefore, you will get >> different results if you see who was probably alive yesterday (or last >> year). The reason for this is that if you have a death event, you know that >> a person died in the past, but you don't know when. If you look to see if a >> person was alive in the past (yesterday and prior) then you can say for >> certain if they were dead then without know a death date. >> >> Please let me know of anything that looks wrong. Tools to use to test: >> Probably Alive person filter, Calc Est Date tool, and Age on Date Gramplet. >> >> The next step is to remove some of the Date Preferences that aren't needed >> anymore, and remove the probably_alive_old functions from Utils. I was going >> to make an option to use a fast, non-recursive probably_alive, but I don't >> think there is a reason to now: one can just calculate estimated dates, and >> then it will be fast where it can be. Gramps-connect will use a narrower >> non-recursive definition of probably_alive, but that is irrelevant here. >> >> -Doug >> > > > >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev_______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > |
From: Brian M. <br...@gr...> - 2010-01-06 21:21:47
|
Hi Fredrico, > Hi, > > > Thanks, Frederico. We don't always know what users > use, nor what they like > > in the vast collection of tools, reports, and > gramplets that come with > > Gramps. So, this is useful, and appreciated! > > It's my pleasure, really > > > I think what we are talking about will make this an > even better tool. But, > > please let us know if it is--- or isn't! > > One of the reasons why I said I wasn't really understanding > the topic > is because some of it makes more sense when one assumes > that the > Calculate Estimated Dates tool *doesn't* exist. It seemed > to me - and > this is likely a bad interpretation on my part - as if a > good chunk of > the conversation is about creating a new tool that does > what the CED > tool does (apart from the issues regarding the > applicability of the > mechanism to gramps-connects, which I understand), even if > the first > mail referenced CED. At least for my contributions to the conversation, I have been assuming that the CED tool does not exist. Not because I don't know about it, or don't like it, but because I want to describe my work flow and use case without any assumption of implementation. I would predict that such a feature would probably be implemented as an enhancement to CED, but I don't want to be too presumptuous just in case some reason comes along that this should be a separate tool. So, in summary, at this time, no decision has been made whether CED would change or not. ~Brian |
From: Frederico M. <fs...@gm...> - 2010-01-06 21:53:27
|
Hi, 2010/1/6 Brian Matherly <br...@gr...>: > At least for my contributions to the conversation, I have been assuming that the CED tool does not exist. > (...) > I would predict that such a feature would probably be implemented as an enhancement to CED, but I >don't want to be too presumptuous just in case some reason comes along that this should be a separate tool. Ok, now I understand it better, thanks for the explanation. Regards, Frederico |
From: Jon C. <jo...@go...> - 2010-01-06 18:46:47
|
Sorry for piping up again on the list: inline reply: Gerald Britton wrote: > The only thing I would add is provision for people for whom no death > date is reasonably calculable. For example I have some Welsh > ancestors who lived sometime prior to the Norman Invasion of England > with no dates (not even unreliable ones) for many generations > thereafter. However, I am confident that all are dead! > > On Wed, Jan 6, 2010 at 11:32 AM, Brian Matherly > <br...@gr...> wrote: > >>> Jérôme mentioned that the tool is a scary process (and I >>> have seen evidence on the users mailing list that people >>> don't know how to use this tool). But we could make that >>> more interactive and easier to use. >>> >>> I wrote a GEP on making probably_alive more prominent [2] >>> and I think that we have done that through tools, reports, >>> and gramplets. Now, I suggest that we encourage users to use >>> the tool (and make it better) and remove the recursive >>> probably_alive from all uses except in the tool. Further, >>> I'd like to suggest that we redefine probably_alive to >>> be be just a simple determination based a person's own >>> event dates. >>> >> I could support a tool that adds death events to my database, but I am *very* particular about the integrity of my data and my ability to trace data back to its source. >> >> Therefore, such a tool for automatically adding death dates would need to work as follows: >> 1) Scan the database for all people with either no death event, or a death event that was previously estimated by the tool. >> 2) For each person for which the death is to be calculated, do the deepest calculation possible (I don't care how long it takes). >> 2a) If the person previously had a calculated the death date, and the same date is calculated again, then skip over it. >> 2b) If the person did not previously have a calculated date, or a new date was calculated (presumably based on information that is new since the last time the tool was run), then add the person to a list of potential dead people. >> 3) Display the list to the user in the GUI >> 3a) The list must include the person's name >> 3b) The list must include the calculated death date >> 3c) The list must include the basis for the calculation (eg. "John Smith was born in 1801, so he probably died after 1901"). >> 4) For each person in the list, allow the user to individually select which people will have death dates added (a "select all" button might also be appropriate). >> 5) When the user is finished selecting people, he can apply the change. At that time, the program will add the death event with appropriate source references. >> 5a) The source references must reference the death calculator tool >> 5b) The source reference must have text that describes the basis for the calculation (either in a note or somewhere else). >> >> Until a tool exists that supports the functionality as I described, I would prefer the existing functionality (running a deep search in real time each time I do an export). >> >> ~Brian >> I apologise first off for not "really" being a "user" of GRAMPS -- I only found it because I like OSS stuff, and especially if it's Python/C++/Haskell/LISP, whatever... and my friend has been using it for months now (hence I joined this list, re: some matters, and report will still be in hand, to those that makes sense to). As clever as it is, I just (reasonably or not) don't like the idea of software putting death events into a tree -- even with point 5b above. (One line of my family for instance has not had a female death until 103 (the males live to about 65, if that, but heck, you know what the nagging's like <grin>) -- although I do agree that 100 is perfectly reasonable). What about instead of setting an "actual" death, there's a new EventType of "estimated death", but I don't think it'd be a bad idea to ask the user, as per point 4 above, to actually say "Dead - Yes/No". To the protect the living, just have a flag that says "private"?? My 0.02p -- apologies if just making noise. Jon. |
From: Gerald B. <ger...@gm...> - 2010-01-06 18:53:23
|
[snip] > I apologise first off for not "really" being a "user" of GRAMPS -- I only > found it because I like OSS stuff, and especially if it's > Python/C++/Haskell/LISP, whatever... and my friend has been using it for > months now (hence I joined this list, re: some matters, and report will > still be in hand, to those that makes sense to). No apology needed. Glad to have your thoughts! > > As clever as it is, I just (reasonably or not) don't like the idea of > software putting death events into a tree -- even with point 5b above. (One > line of my family for instance has not had a female death until 103 (the > males live to about 65, if that, but heck, you know what the nagging's like > <grin>) -- although I do agree that 100 is perfectly reasonable). That's why it would be in an optional tool. > > What about instead of setting an "actual" death, there's a new EventType of > "estimated death", but I don't think it'd be a bad idea to ask the user, as > per point 4 above, to actually say "Dead - Yes/No". I think it's about the same thing as a Death event with an estimated date. > > To the protect the living, just have a flag that says "private"?? Already there! - Gerald Britton |
From: Doug B. <dou...@gm...> - 2010-01-06 19:00:02
|
On Wed, Jan 6, 2010 at 1:46 PM, Jon Clements <jo...@go...> wrote: > Sorry for piping up again on the list: inline reply: > > Gerald Britton wrote: > > The only thing I would add is provision for people for whom no death > > date is reasonably calculable. For example I have some Welsh > > ancestors who lived sometime prior to the Norman Invasion of England > > with no dates (not even unreliable ones) for many generations > > thereafter. However, I am confident that all are dead! > > > > On Wed, Jan 6, 2010 at 11:32 AM, Brian Matherly > > <br...@gr...> wrote: > > > >>> Jérôme mentioned that the tool is a scary process (and I > >>> have seen evidence on the users mailing list that people > >>> don't know how to use this tool). But we could make that > >>> more interactive and easier to use. > >>> > >>> I wrote a GEP on making probably_alive more prominent [2] > >>> and I think that we have done that through tools, reports, > >>> and gramplets. Now, I suggest that we encourage users to use > >>> the tool (and make it better) and remove the recursive > >>> probably_alive from all uses except in the tool. Further, > >>> I'd like to suggest that we redefine probably_alive to > >>> be be just a simple determination based a person's own > >>> event dates. > >>> > >> I could support a tool that adds death events to my database, but I am > *very* particular about the integrity of my data and my ability to trace > data back to its source. > >> > >> Therefore, such a tool for automatically adding death dates would need > to work as follows: > >> 1) Scan the database for all people with either no death event, or a > death event that was previously estimated by the tool. > >> 2) For each person for which the death is to be calculated, do the > deepest calculation possible (I don't care how long it takes). > >> 2a) If the person previously had a calculated the death date, and the > same date is calculated again, then skip over it. > >> 2b) If the person did not previously have a calculated date, or a new > date was calculated (presumably based on information that is new since the > last time the tool was run), then add the person to a list of potential dead > people. > >> 3) Display the list to the user in the GUI > >> 3a) The list must include the person's name > >> 3b) The list must include the calculated death date > >> 3c) The list must include the basis for the calculation (eg. "John > Smith was born in 1801, so he probably died after 1901"). > >> 4) For each person in the list, allow the user to individually select > which people will have death dates added (a "select all" button might also > be appropriate). > >> 5) When the user is finished selecting people, he can apply the change. > At that time, the program will add the death event with appropriate source > references. > >> 5a) The source references must reference the death calculator tool > >> 5b) The source reference must have text that describes the basis for > the calculation (either in a note or somewhere else). > >> > >> Until a tool exists that supports the functionality as I described, I > would prefer the existing functionality (running a deep search in real time > each time I do an export). > >> > >> ~Brian > >> > I apologise first off for not "really" being a "user" of GRAMPS -- I > only found it because I like OSS stuff, and especially if it's > Python/C++/Haskell/LISP, whatever... and my friend has been using it for > months now (hence I joined this list, re: some matters, and report will > still be in hand, to those that makes sense to). > > No need to apologize... good feedback appreciated regardless of where it comes from. > As clever as it is, I just (reasonably or not) don't like the idea of > software putting death events into a tree -- even with point 5b above. > (One line of my family for instance has not had a female death until 103 > (the males live to about 65, if that, but heck, you know what the > nagging's like <grin>) -- although I do agree that 100 is perfectly > reasonable). > > The fact is that we need to distinguish between living and the dead for privacy reasons. In this case, I think explicit is better than implicit. That is, it is better to clearly mark the assumption that the software is making regarding the persons' living status, and should be therefore a death event if you believe that that person is in fact dead. If they *might* be alive, then don't automatically tag them otherwise. > What about instead of setting an "actual" death, there's a new EventType > of "estimated death", but I don't think it'd be a bad idea to ask the > user, as per point 4 above, to actually say "Dead - Yes/No". > > One could, but this is effectively a Death Event with an estimated date (or without one, for that matter). > To the protect the living, just have a flag that says "private"?? > > We already do that. We have two categories of Privacy: living and private. Thanks! -Doug > My 0.02p -- apologies if just making noise. > > Jon. > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-01-06 19:04:54
|
On Wed, Jan 6, 2010 at 11:32 AM, Brian Matherly <br...@gr...>wrote: > > Jérôme mentioned that the tool is a scary process (and I > > have seen evidence on the users mailing list that people > > don't know how to use this tool). But we could make that > > more interactive and easier to use. > > > > I wrote a GEP on making probably_alive more prominent [2] > > and I think that we have done that through tools, reports, > > and gramplets. Now, I suggest that we encourage users to use > > the tool (and make it better) and remove the recursive > > probably_alive from all uses except in the tool. Further, > > I'd like to suggest that we redefine probably_alive to > > be be just a simple determination based a person's own > > event dates. > > I could support a tool that adds death events to my database, but I am > *very* particular about the integrity of my data and my ability to trace > data back to its source. > > Therefore, such a tool for automatically adding death dates would need to > work as follows: > 1) Scan the database for all people with either no death event, or a death > event that was previously estimated by the tool. > 2) For each person for which the death is to be calculated, do the deepest > calculation possible (I don't care how long it takes). > 2a) If the person previously had a calculated the death date, and the same > date is calculated again, then skip over it. > 2b) If the person did not previously have a calculated date, or a new date > was calculated (presumably based on information that is new since the last > time the tool was run), then add the person to a list of potential dead > people. > 3) Display the list to the user in the GUI > 3a) The list must include the person's name > 3b) The list must include the calculated death date > 3c) The list must include the basis for the calculation (eg. "John Smith > was born in 1801, so he probably died after 1901"). > 4) For each person in the list, allow the user to individually select which > people will have death dates added (a "select all" button might also be > appropriate). > 5) When the user is finished selecting people, he can apply the change. At > that time, the program will add the death event with appropriate source > references. > 5a) The source references must reference the death calculator tool > 5b) The source reference must have text that describes the basis for the > calculation (either in a note or somewhere else). > > Until a tool exists that supports the functionality as I described, I would > prefer the existing functionality (running a deep search in real time each > time I do an export). > > Thanks, Brian! This is a great list of features to add to the Calculate Estimated Dates Tool. It already does some of these, but the ones I think are critical are the interactive selection, and the explanation of how the date was calculated. This will take a little bit of refactoring of the probably_alive, but will be worth it. -Doug > ~Brian > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jon C. <jo...@go...> - 2010-01-06 19:28:33
|
My friend is writing a document detailing his issues and thoughts on this (a user of GRAMPS) -- if I may be so bold, he'll forward the text to me, then I'll copy in this list. Jon. Doug Blank wrote: > On Wed, Jan 6, 2010 at 11:32 AM, Brian Matherly > <br...@gr... <mailto:br...@gr...>> wrote: > > > Jérôme mentioned that the tool is a scary process (and I > > have seen evidence on the users mailing list that people > > don't know how to use this tool). But we could make that > > more interactive and easier to use. > > > > I wrote a GEP on making probably_alive more prominent [2] > > and I think that we have done that through tools, reports, > > and gramplets. Now, I suggest that we encourage users to use > > the tool (and make it better) and remove the recursive > > probably_alive from all uses except in the tool. Further, > > I'd like to suggest that we redefine probably_alive to > > be be just a simple determination based a person's own > > event dates. > > I could support a tool that adds death events to my database, but > I am *very* particular about the integrity of my data and my > ability to trace data back to its source. > > Therefore, such a tool for automatically adding death dates would > need to work as follows: > 1) Scan the database for all people with either no death event, or > a death event that was previously estimated by the tool. > 2) For each person for which the death is to be calculated, do the > deepest calculation possible (I don't care how long it takes). > 2a) If the person previously had a calculated the death date, and > the same date is calculated again, then skip over it. > 2b) If the person did not previously have a calculated date, or a > new date was calculated (presumably based on information that is > new since the last time the tool was run), then add the person to > a list of potential dead people. > 3) Display the list to the user in the GUI > 3a) The list must include the person's name > 3b) The list must include the calculated death date > 3c) The list must include the basis for the calculation (eg. > "John Smith was born in 1801, so he probably died after 1901"). > 4) For each person in the list, allow the user to individually > select which people will have death dates added (a "select all" > button might also be appropriate). > 5) When the user is finished selecting people, he can apply the > change. At that time, the program will add the death event with > appropriate source references. > 5a) The source references must reference the death calculator tool > 5b) The source reference must have text that describes the basis > for the calculation (either in a note or somewhere else). > > Until a tool exists that supports the functionality as I > described, I would prefer the existing functionality (running a > deep search in real time each time I do an export). > > > Thanks, Brian! This is a great list of features to add to the > Calculate Estimated Dates Tool. It already does some of these, but the > ones I think are critical are the interactive selection, and the > explanation of how the date was calculated. This will take a little > bit of refactoring of the probably_alive, but will be worth it. > > -Doug > > > ~Brian > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution > fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Frederico M. <fs...@gm...> - 2010-01-08 17:14:09
|
Hi, 2010/1/8 derHeinzi <hei...@ya...>: > To give a feedback as a user: I would never use such a tool that alters my > data. This is why it is a good thing it is a Tool, and not something that is part of the main dialogs. That way people who do not want a tool that calculates estimated dates of events can simply not use it al all, while others who do want such a tool (like me) know where to find it and use it exactly because it does what it says it does.... which is why one of my previous comments hinted that there are several different issues here, but one which I would oppose would be to change the CED tool to make it more in line with the (legitimate) desires of users who do not want to have batch changes made on their data. This would be IMO *another* different tool, since removing this ability would destroy the reason why *I* use it. Or, as said above, some kind of configuration for the tool to make it behave in different ways, on of which being more or less the way it works now in what regards the actual adding of the events. Regards, Frederico |
From: Doug B. <dou...@gm...> - 2010-01-08 17:54:14
|
Heinz and Frederico, I appreciate both of these points of view, and have a prototype that should be ready for testing in the next few days. I believe that it can be used as both a "filter" + report, or as a batch change tool. First, it goes through the data and finds people for which the old probably_alive function would have had to guess their status. The tool gives a summary of the evidence for their birth/death, including how the person is related to the evidence. You can visit each of these people by clicking on them, if you wanted to manually add or edit their information. If you want to go further, you can then select only those people you wish to automatically add events to. Of course, you will see exactly what it will do, before it does it. I would suggest that we can have an option of using the old probably_alive for use in filters, but it is incomplete and complex. Rather than having this expensive, recursive algorithm guess, I much prefer using this tool to at least know what the algorithm is deducing and how. Then you can manually decide if that is correct, and if not add events to make it more correct. Even better, you can apply the deduction to make the data explicit. I very much appreciate the fact that we are using the official Birth and Death Events to store this information, and some would feel that this is an improper use of the official events. We could store this in a secondary place, but then we may have conflicting information. We could ignore dates on export that were "calculated estimated" as that is an invalid GEDCOM combination anyway. That way the dates would not go beyond your working Gramps. Or we could also mark these calculated estimated events as private... -Doug On Fri, Jan 8, 2010 at 12:14 PM, Frederico Muñoz <fs...@gm...> wrote: > Hi, > > 2010/1/8 derHeinzi <hei...@ya...>: > > > To give a feedback as a user: I would never use such a tool that alters > my > > data. > > This is why it is a good thing it is a Tool, and not something that is > part of the main dialogs. That way people who do not want a tool that > calculates estimated dates of events can simply not use it al all, > while others who do want such a tool (like me) know where to find it > and use it exactly because it does what it says it does.... which is > why one of my previous comments hinted that there are several > different issues here, but one which I would oppose would be to change > the CED tool to make it more in line with the (legitimate) desires of > users who do not want to have batch changes made on their data. This > would be IMO *another* different tool, since removing this ability > would destroy the reason why *I* use it. > > Or, as said above, some kind of configuration for the tool to make it > behave in different ways, on of which being more or less the way it > works now in what regards the actual adding of the events. > > Regards, > > Frederico > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-01-10 04:33:38
|
Ok, I have committed an update Calculated Estimated Dates Tool in trunk. Try it out. This works nicely with the new Timeline Pedigree View (very nice!) A screen shot of the select list: http://www.gramps-project.org/wiki/index.php?title=Image:Screenshot-Calculate_Estimated_Dates.png More details on the CED Tool: Brian said: > I could support a tool that adds death events to my database, but I am > *very* particular about the integrity of my data and my ability to trace > data back to its source. > > It is funny that most of us feel the same way, but we don't pay too much attention to how and why Gramps was marking someone "probably alive". I guess as long as we didn't see any obvious errors, that is ok. But by making probably alive be explicit, and explain itself, I think we can evaluate it better. I've already found some omissions in the old code. This is really pretty critical for getting the privacy right for NarWeb and Gramps-Connect. > Therefore, such a tool for automatically adding death dates would need to > work as follows: > 1) Scan the database for all people with either no death event, or a death > event that was previously estimated by the tool. > I've made it so that you can (optionally) remove the events previously added, so this defaults to no death event. > 2) For each person for which the death is to be calculated, do the deepest > calculation possible (I don't care how long it takes). > Actually, I think you want the shallowest (if I understand your wording). You want to find the closest relative that has a birth/death date to the person. > 2a) If the person previously had a calculated the death date, and the same > date is calculated again, then skip over it. > One can control this by removing/saving previous estimated events. > 2b) If the person did not previously have a calculated date, or a new date > was calculated (presumably based on information that is new since the last > time the tool was run), then add the person to a list of potential dead > people. > 3) Display the list to the user in the GUI > 3a) The list must include the person's name > 3b) The list must include the calculated death date > 3c) The list must include the basis for the calculation (eg. "John Smith > was born in 1801, so he probably died after 1901"). > 4) For each person in the list, allow the user to individually select which > people will have death dates added (a "select all" button might also be > appropriate). > 5) When the user is finished selecting people, he can apply the change. At > that time, the program will add the death event with appropriate source > references. > 5a) The source references must reference the death calculator tool > 5b) The source reference must have text that describes the basis for the > calculation (either in a note or somewhere else). > > The tool now adds the event with or without estimated dates, connects them all to a source (that you can name), and adds a note to each event which gives the supporting evidence. The tool does not add a birth or death event to people that have them... only those without. There are a couple of minor items that I know about (should find spouse connections), but please mention anything that you see. -Doug > Until a tool exists that supports the functionality as I described, I would > prefer the existing functionality (running a deep search in real time each > time I do an export). > > ~Brian > > |
From: Brian M. <br...@gr...> - 2010-01-10 05:04:01
|
Doug, Not bad. Some comments below.. > Date: Saturday, January 9, 2010, 10:25 PM > Ok, I have > committed an update Calculated Estimated Dates Tool in > trunk. Try it out. This works nicely with the new Timeline > Pedigree View (very nice!) More details on the CED > Tool: > > Brian said: > I could support a tool that adds death events to my > database, but I am *very* particular about the integrity of > my data and my ability to trace data back to its source. > > > > It is funny that most of us feel the same way, > but we don't pay too much attention to how and why > Gramps was marking someone "probably alive". I > guess as long as we didn't see any obvious errors, that > is ok. But by making probably alive be explicit, and explain > itself, I think we can evaluate it better. I've already > found some omissions in the old code. For me, it isn't whether it is explicit or not. It is just a matter of whether it changes the data in my database or not. I refuse to have any data in my database that wasn't put there *on purpose* *by me*. Similarly, I would never download a gedcom file from the Internet and import it into my database. It's my data, and I require that all my sources be cited properly. I never enter even the tiniest piece of information into my database if I am not able to certify that the information is accurate and cite the source. The only way to ensure that happens is to do it myself. Using the probably_alive function on export didn't touch my data. So it was a non-issue to me. > Therefore, such a tool for automatically adding death dates > would need to work as follows: > > 1) Scan the database for all people with either no death > event, or a death event that was previously estimated by the > tool. > > I've made it so that you can (optionally) > remove the events previously added, so this defaults to no > death event. Nice touch. I like it. > 2) For each person for which the death is to be calculated, > do the deepest calculation possible (I don't care how > long it takes). > > Actually, I think you want the shallowest (if I > understand your wording). You want to find the closest > relative that has a birth/death date to the person. What i mean is: "don't take any shortcuts". Use all of the information at your disposal. Don't stop at first generation ancestor/descendants - go as deep as possible into the data - visit every single person in the database if necessary. I don't care how long the operation takes. But I want the results to be as accurate as possible. Just because you find one piece of evidence, don't stop there. Keep looking. There might be other evidence that makes the estimate more accurate. If you find more than one piece of evidence, cite all of the evidence in the note. > 2a) If the person previously had a calculated the death > date, and the same date is calculated again, then skip over > it. > > One can control this by removing/saving previous > estimated events. It's a good start. But this will become cumbersome after I have 500 estimated death events in my database. Each time I want to check for new death events, I will have to delete the 499 that I previously added, and then re-evaluate them all. How will I even know if any new ones were added? I do like the ability to easily delete all the previously generated date estimates. > 2b) If the person did not previously have a calculated > date, or a new date was calculated (presumably based on > information that is new since the last time the tool was > run), then add the person to a list of potential dead > people. > > > 3) Display the list to the user in the GUI > > 3a) The list must include the person's name > > 3b) The list must include the calculated death date > > 3c) The list must include the basis for the calculation > (eg. "John Smith was born in 1801, so he probably died > after 1901"). > > 4) For each person in the list, allow the user to > individually select which people will have death dates added > (a "select all" button might also be > appropriate). > > 5) When the user is finished selecting people, he can apply > the change. At that time, the program will add the death > event with appropriate source references. > > 5a) The source references must reference the death > calculator tool > > 5b) The source reference must have text that describes > the basis for the calculation (either in a note or somewhere > else). > > > > The tool now adds the event with or without > estimated dates, Nice touch. I can't decide whether I'll include dates or not. Including estimated dates will throw off things like the statistics report. But then again, it might be nice to see when someone "might" have died when doing research. The tool supports both so I can change my mind. > connects them all to a source (that you can > name), Nice. It would be even better if I could select a source using a source selection dialog. It would also be nice if I could create a source, edit its notes, and add it to a repository from that dialog (like I can from the editor dialogs). > and adds a note to each event which gives the > supporting evidence. The tool does not add a birth or death > event to people that have them... only those > without. > > There are a couple of minor items that I know > about (should find spouse connections), but please mention > anything that you see. When I ran the tool on the example database, it added some death dates with just a year, but no qualifier ("about" or "before"). That doesn't make sense to me. It seems that all estimated dates should have a qualifier. Otherwise, it looks too much like a real date. I don't care much for the "help" tab and the magically appearing "select" tab. That doesn't follow standard user paradigms. I think the whole tool would be more intuitive as a wizard with standard "forward" and "backward" buttons. Well, you asked, so I gave my opinion ;) All in all, its a great step forward. Keep up the good work. ~Brian |