Menu
▾
▴
Re: [Gramps-devel] Calculating estimated Birth/Death events
|
From: <ste...@gm...> - 2007-11-21 22:27:45
|
The advantage of having it as a source is we could ensure the source has the necessary text to describe that this was machine-generated. This way when we share a GEDCOM output with a family member, they'll see that the proper source for these dates. And personally, users of GRAMPS could modify the single source to say exactly what they want. This will blend in nicely with existing reports that already list sources. (Specifically, I'm thinking of NarrativeWeb, but all reports that already deal with sources will handle this the same way.) ------------------------- Different thought: if we don't want the information to be statically inserted into the database, could Brian's proxy db server be useful here? So prior to running a report, a proxy db that automatically inserts dates is inserted into the chain, and the report is produced. But the db that exists on the hard drive doesn't get peppered with machine-generated dates. Just another thought... St=E9phane On Nov 21, 2007 2:19 PM, Douglas S. Blank <db...@cs...> wrote: > Thanks for the ideas. It looks like GRAMPS *could* use ABT and (EST or > CAL) (because ABT is a modifier and EST/CAL are qualities) but I don't > think that would produce valid GEDCOM: > > http://homepages.rootsweb.com/~pmcbride/gedcom/55gcch2.htm#DATE_APPROXIMA= TED > > ABT, EST, and CAL look like they are all either-or. > > Perhaps the best solution would be to do something similar to what > St=E9phane suggests. Maybe a special Date Description entry would be less > work for GRAMPS to store than creating a source? Or perhaps a special > single, shared source would keep all of these specially calculated dates > linked together? > > -Doug > > > On Wed, November 21, 2007 4:36 pm, St=E9phane Charette wrote: > > When the tool is run, can we not select a specific source for the > > dates that are about to be inserted? So the source would be an > > indicator of how/where/when the dates were calculated? > > > > St=E9phane > > > > > > On Nov 21, 2007 1:27 PM, Benny Malengier <ben...@gm...> > > wrote: > >> I don't think calc est is possible. It would be a new qualifier. > >> > >> You could use the approach as in eg unused objects tool: calculate > >> everything, then show a treeview with the changes that will happen, > >> allowing > >> people to deselect changes they do not want. > >> > >> To recognize which dates have been created by the tool before, I'm out > >> of > >> ideas. It should be done cleanly, so best not to have a special > >> identifier, > >> it would have to be supported everywhere. As the meaning is not > >> different > >> from calc, that looks like a bad move. > >> > >> Perhaps an attribute you can recognize. Would be usefull for the > >> reseacher > >> too, you see attribute indicating you calculated it with the tool, to = eg > >> key=3D generator, value: thetool. > >> > >> Don't know. Anybody better ideas? > >> > >> Benny > >> > >> 2007/11/21, Douglas S. Blank <db...@cs...>: > >> > >> > I've been exploring integrating ideas around "possibly alive" into > >> GRAMPS > >> > for a while, for example: > >> > > >> http://www.gramps-project.org/wiki/index.php?title=3DGEPS_003:_Compute= d_Ages_and_Probably_Alive > >> > > >> > Thanks to suggestions by Benny, it seems like the right way to do th= is > >> is > >> > to have a tool that goes through and adds birth and death events for > >> > people, and marking the dates as calculated (marked with "cal"). > >> Adding > >> > them seems easy enough. But one issue might be: how would GRAMPS > >> update a > >> > calculated date that it has already added previously? > >> > > >> > First, is it legal having both "cal est" (calculated and estimated) = in > >> a > >> > date field? If I used "cal est" would it be a problem if GRAMPS > >> considered > >> > those type of dates auto-changable (ie, when you re-run the tool, > >> could it > >> > better estimate the dates and update)? > >> > > >> > Anyone see any problems with this approach? Any other suggestions? > >> Questions? > >> > > >> > -Doug > >> > > >> > > >> > --------------------------------------------------------------------= ----- > >> > This SF.net email is sponsored by: Microsoft > >> > Defy all challenges. Microsoft(R) Visual Studio 2005. > >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> > _______________________________________________ > >> > Gramps-devel mailing list > >> > Gra...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > >> > >> > >> ----------------------------------------------------------------------= --- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2005. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > >> > > > > -----------------------------------------------------------------------= -- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > -- > Douglas S. Blank > Associate Professor, Bryn Mawr College > http://cs.brynmawr.edu/~dblank/ > Office: 610 526 6501 > |