## Re: [Gramps-users] Re: [Gramps-devel] further on dates

 Re: [Gramps-users] Re: [Gramps-devel] further on dates From: Doug M-C - 2004-09-14 14:02:49 Attachments: application/pgp-signature ```On Mon, 13 Sep 2004 23:43:17 +0000 Alex Roitman wrote: > On 09/13/2004 05:36:57 PM, Jim Smart wrote: > [snip] > So, this seems like EST is the same as ABT. Why another tag > then? I'm going slightly mad, I guess :-) So, if I have a baptismal date of 1890-12-12 and no age, then I could appropriately have a birth date of: EST BEF 1890-12-12 (My algorithm says that 'Birth is always before Baptism'.) If I have a baptismal date of 1890-12-12 and an age of 3 months, then I could have a birth date of: CAL BET 1890-08-13 AND 1890-09-12 or, perhaps better, CAL BET 1890-08 AND 1890-09 And if I have Aunt Maud say that her aunt was born sometime around September 1890, then I have a birth date of: ABT 1890-09 Subtle, but if used consistently it does adds to the amount of information in an entry - a little! As for +/- and complex nested ranges of dates, I like what the others have already said: +/- is really only useful if its in GEDCOM itself (though I personally like it a lot), and a complex nested range is ultimately the same as the range between the min and max dates, so nesting really isn't necessary. The date dialog looks great. Doug --------------------------- Doug M-C Email: Key ID: D5CC3E8F --------------------------- Email, signature, & copyright policies: ; ```

 [Gramps-users] further on dates From: Jim Smart - 2004-09-13 22:37:10 ```I've been looking for further clarification on the differences between GEDCOM's EST and CAL, which are defined in GEDCOM 6 as: CAL =3D Calculated mathematically, for example, from an event date and age.=20 EST =3D Estimated based on an algorithm using some other event date. ...what I've realised is that GEDCOM 6 further states: "To show date imprecision, MAY 1890 is better than ABT 12 MAY 1890 because ABT or EST do not have assigned limits." ...which might clarify things somewhat: EST is estimated, imprecise and has no assigned limits. I think it's likely that the examples I gave of date range calculations that were based upon other date range calculation should all have been defined as CAL, not EST -- EST seems far woollier than a calculation based upon a calculation. --- The Gentech spec (in section "C.3 DATE EXPERT SYSTEM", p97) says: "Dates are ambiguous, soft data. Examples include dates marked abt, ca, est, say, <=3D (less than or before), or >=3D (greater than or after). Soft dates are also expressible with a =B1 range." ...I think we've got most of that covered so far -- with the exception of the last statement, which could make a great feature! How about we allow imprecise dates to have "+/- n" as an optional suffix? e.g.: - EST 13 MAR 1942 +/- 10d - ABT JUN 1850 +/- 3m - ABT 1795 +/- 1y Internally, Gramps could treat these as date ranges if/when necessary. Of course, if we were to support this additional date format, the +/- suffix could not be exported to GEDCOM files (at least, not in the date itself -- maybe we could add a note?) Alex, following on from our previous dialogue, would we then support things like: BET EST JUN 1853 +/- 2m AND CAL 30 AUG 1853 ..or is this just taking things too far??? ;O) /Jim ```
 [Gramps-users] Re: [Gramps-devel] further on dates From: Alex Roitman - 2004-09-13 23:43:26 Attachments: application/pgp-signature ```On 09/13/2004 05:36:57 PM, Jim Smart wrote: [snip] > "To show date imprecision, MAY 1890 is better than ABT 12 MAY 1890 > because ABT or EST do not have assigned limits." > ...which might clarify things somewhat: EST is estimated, imprecise and > has no assigned limits. So, this seems like EST is the same as ABT. Why another tag then? I'm going slightly mad, I guess :-) > How about we allow imprecise dates to have "+/- n" as an optional > suffix? e.g.: >=20 > - EST 13 MAR 1942 +/- 10d > - ABT JUN 1850 +/- 3m > - ABT 1795 +/- 1y >=20 > Internally, Gramps could treat these as date ranges if/when necessary. Allowing +/- would indeed be a sweet option. > Of course, if we were to support this additional date format, the +/- > suffix could not be exported to GEDCOM files (at least, not in the date > itself -- maybe we could add a note?) It seems that the note is the only fallback we can count on. > Alex, following on from our previous dialogue, would we then support > things like: >=20 > BET EST JUN 1853 +/- 2m AND CAL 30 AUG 1853 >=20 > ..or is this just taking things too far??? ;O) I don't know the answer, but I think I can precisely formulate the question now: When using ranges and spans (from X to Y or between X and Y), do X and Y have to be simple dates (i.e. exact single dates without modifiers, even though incomplete) or can they be any Date objects? If the former, then the above string is a valid date. But then nothing prohibits us from accepting BET (BET X and Y) and Z and so on, for the indefinite depth. Where do we draw the limit? What about BET (BET (BET X AND Y) AND (BET A AND (BET B AND C)) and Z) ? This makes we want to cry :-) 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 ```
 [Gramps-users] Re: further on dates From: Jim Smart - 2004-09-14 00:41:03 ```On Tue, 2004-09-14 at 00:43, Alex Roitman wrote: > On 09/13/2004 05:36:57 PM, Jim Smart wrote: > [snip] (re-inserted for context) EST = Estimated based on an algorithm using some other event date. > > "To show date imprecision, MAY 1890 is better than ABT 12 MAY 1890 > > because ABT or EST do not have assigned limits." > > ...which might clarify things somewhat: EST is estimated, imprecise and > > has no assigned limits. > > So, this seems like EST is the same as ABT. Why another tag then? > I'm going slightly mad, I guess :-) It's almost as if EST is intended to be somewhere between CAL and ABT -- can that make any sense? Maddening indeed. [snip] > > Alex, following on from our previous dialogue, would we then support > > things like: > > > > BET EST JUN 1853 +/- 2m AND CAL 30 AUG 1853 > > > > ..or is this just taking things too far??? ;O) > > I don't know the answer, but I think I can precisely formulate > the question now: > > When using ranges and spans (from X to Y or between X and Y), > do X and Y have to be simple dates (i.e. exact single dates without > modifiers, even though incomplete) or can they be any Date objects? If we allow date objects, it could probably be fairly simple to handle date ranges/periods and before/after dates (i.e. open ended ranges) -- more on this below -- but I think we will hit problems if there is an imprecise date object in the mix. That said, I personally think that the start/end of ranges & spans should likely be a simple date. (Thus postponing at least some of this madness to a future version of Gramps should anyone want that kind of functionality) > If the former, then the above string is a valid date. But then nothing > prohibits us from accepting BET (BET X and Y) and Z and so on, > for the indefinite depth. Where do we draw the limit? What about > BET (BET (BET X AND Y) AND (BET A AND (BET B AND C)) and Z) ? > This makes we want to cry :-) Hmm.. where do we draw the limit? -- it's probably a good assumption that we probably don't want a totally recursive grammar for dates, if at all. Discounting the handling of imprecise dates for one moment, the examples you give are not actually too too difficult to calculate... (although entering them and tracking where each nested range has derived from is another matter). To work out the result between ranges from all the sub-ranges/betweens, one simply looks for the outer limits (min/max dates). i.e.: > BET (BET (BET X AND Y) AND (BET A AND (BET B AND C)) and Z) ? ..becomes BET (min(X, Y, A, B,C) AND Z -- and if you can guarantee that X, Y, A, B and C are all in the correct order, it can be reduced to simply BET X AND Z. Obviously there is a loss of information here, but the resulting expression of the 'sum' of these ranges covers the same span of time. Apart from any implied information held in the structure of such a monsterous date statement, there are no further gains to be had from such statements as a working unit -- a large percentage of the statement is simply redundant at a logical level. Madnesses aside, my vote is for ranges to be bound by simple dates. I'm going to get an ice-pack for my head now... /Jim ```
 Re: [Gramps-users] Re: [Gramps-devel] further on dates From: Doug M-C - 2004-09-14 14:02:49 Attachments: application/pgp-signature ```On Mon, 13 Sep 2004 23:43:17 +0000 Alex Roitman wrote: > On 09/13/2004 05:36:57 PM, Jim Smart wrote: > [snip] > So, this seems like EST is the same as ABT. Why another tag > then? I'm going slightly mad, I guess :-) So, if I have a baptismal date of 1890-12-12 and no age, then I could appropriately have a birth date of: EST BEF 1890-12-12 (My algorithm says that 'Birth is always before Baptism'.) If I have a baptismal date of 1890-12-12 and an age of 3 months, then I could have a birth date of: CAL BET 1890-08-13 AND 1890-09-12 or, perhaps better, CAL BET 1890-08 AND 1890-09 And if I have Aunt Maud say that her aunt was born sometime around September 1890, then I have a birth date of: ABT 1890-09 Subtle, but if used consistently it does adds to the amount of information in an entry - a little! As for +/- and complex nested ranges of dates, I like what the others have already said: +/- is really only useful if its in GEDCOM itself (though I personally like it a lot), and a complex nested range is ultimately the same as the range between the min and max dates, so nesting really isn't necessary. The date dialog looks great. Doug --------------------------- Doug M-C Email: Key ID: D5CC3E8F --------------------------- Email, signature, & copyright policies: ; ```
 Re: [Gramps-users] further on dates From: Jim Smart - 2004-09-14 00:55:37 ```(cc'ing my reply to the list) On Tue, 2004-09-14 at 00:38, John Whitehand wrote: > >I've been looking for further clarification on the differences between > >GEDCOM's EST and CAL, which are defined in GEDCOM 6 as: > > > >CAL = Calculated mathematically, for example, from an event date and > >age. > >EST = Estimated based on an algorithm using some other event date. > > > >...what I've realised is that GEDCOM 6 further states: > > > >"To show date imprecision, MAY 1890 is better than ABT 12 MAY 1890 > >because ABT or EST do not have assigned limits." > > > >...which might clarify things somewhat: EST is estimated, imprecise and > >has no assigned limits. > > > > > >. > > > > > > > Hello Jim ( et al), > Just to add a little more "grist to the mill"- Many indexes( > particularly in UK) have recorded BDM's by Quarter. therefore it is > likely that ( as in my records) MAR; JUN;SEP & DEC have been recorded > in upper case to denote the imprecision. > This also emerges in the absence of a Date of Birth , Marriage or > Death. those dates are often deduced/estimated from baptism, marriage > banns or burial records.( all can have their own TAGS but to > systematically use them as a basis on which to calculate a specific > date can give rise to self perpetuating error) > While Genealogical practice advocates the wisdom of using "Primary > sources", in the real world , indexes, for all their limitations > feature largely as "Fairly reliable and accurate" until costly > certification can be negotiated. > The significance is that many of the imported GEDCOM's ( regardless of > the version) 5.5 or 6 will feature these vagaries for some > consideralbe time to come.. > > " BFN > John > " The beauty of Standards is that we have SO many to choose from ;-) " As I understand it so far John, I don't think we've proposed anything that would break data of that kind, nor prevent data of that kind from being entered into the db by the user (or at import time). [Maybe Gramps should also allow Q1, Q2, Q3 + Q4 in the date notation? On export (and during internal calculations/etc) these quarters would be treated as date ranges] /Jim ```
 [Gramps-users] Re: [Gramps-devel] further on dates From: Tim Waugh - 2004-09-14 09:37:44 Attachments: application/pgp-signature ```On Mon, Sep 13, 2004 at 11:36:57PM +0100, Jim Smart wrote: > Of course, if we were to support this additional date format, the +/- > suffix could not be exported to GEDCOM files (at least, not in the date > itself -- maybe we could add a note?) Personally I don't really see a lot of value in adding things that can't be exported into GEDCOM. If I share the data with someone else, it will always be with GEDCOM. Tim. */ ```