 |
From: John Nairn <j...@geditcom.com>
Date: Thu, 23 Feb 2012 11:01:39 -0800
Local: Thurs, Feb 23 2012 2:01 pm
Subject: Re: Attribute date sorting revisited and date ranges explained
It actually doesn't matter if you globally sort (which the sort events command does now) or sort events and attributes separately. The sort command changes the order those events and attributes appear in the source GEDCOM data (note - you can even manually sort data in the GEDCOM source editor pane of the index window if built-in sort does not get what you want). The Events pane in the individual record, however, displays events, followed by residences, followed by attributes. Even if an attribute was sorted before an event, it would appear among the attributes in the window and not among the events.
Residences in GEDCOM files are also a schizophrenic type of event/attribute. Over the years of developing GEDitCOM/GEDitCOM II, I have included residences in either events or in attributres. The current version treats that as a unique type of event. The GEDCOM standard calls it an attribute, but unlike every other attribute, no text is allowed on the main RESI line to describe it as an attribute. The residence information is all in the subordinate detail for date, place, and address. Residences are therefore more like events because they also have no text on the first line. Although an event can have the text "Y" to indicate and event as occurred and residences do not formally allow that option. Attribute dates and places are fairly uncommon. About the only attributes I ever create with a date and/or place are residences (if called an attribute), occupation, and education. Dates could make sense for other attributes, but not very often (e.g., a conversion of religious affiliation). BEF x and AFT x are another challenge in fuzzy dates. I used to set the start time for BEF x to a small number (i.e., the beginning of time) and end date for AFT x to a large number in the future. This did not work well with midpoint searching (they would always be first or last). Currently BEF and AFT are ignored and the date is sorted without using that information. The real problem is that BEF x and AFT x just does not provide computer code enough information. They need to be supplemented with some idea on how long before or after. For example someone born BEF x where x was from a baptism record was probably born a few days or at most a month before that date. But, someone who died AFT 1881 (when they appeared in the 1881 census) may have died many years after that date. You could comment the date: AFT 1881 (maybe several years) or make up a range BET 1881 and 1891 (he was not in the 1891 census) The first would sort by middle of 1881, the latter would sort by 1896. On Feb 23, 2012, at 10:21 AM, Swanfoth wrote: > I'm not talking about global sorting but sorting within attributes.
> I have several farmhands and maids who switched residences almost > yearly in their youth. As the research goes backward in time and new > items are added last to the list this is needed often because I want > keep the events in chronological order. > Midpoint calculation should work also if you take the single year date > as such and use the midpoints of period dates. > BTW how do you define midpoint of BEF x or AFT x? Just wondering… > On 22 helmi, 21:32, John Nairn <j...@geditcom.com> wrote: >> I will look at other options instead. For example, perhaps it only matters to sort command and can be done in that code and would not be needed any place else. Also distinguishing 1855 from 1855 to 1866 is difficult in current sort method because it is based on one number. Accounting for start date and end date would require addition of secondary sorting criteria (unless the range can be encoded into a single number somehow for efficiency) >> On nested dates such as FROM CAL 1777 TO BET 1784 AND 1786 >> These cannot be entered because GEDitCOM II has adopted all GEDCOM options for dates, but that option is not one of them. You do however, have some ways to record such a date: >> 1. Any date can be followed by a comment in parentheses such as >> FROM 1777 TO 1786 (1777 was calculated, end date may have been 1784) >> The comment is never used in date calculations, but will be there for your records. >> 2. To do the same thing in a hidden field, you can use the custom GEDitCOM II option to attach a memo to the date (or any) field: >> a. Enter FROM 1777 to 1786 into the field >> Now when you hover the curse over that field, the comment will appear in a pop-up window rather then the help string for date fields. You can control click again to change the memo. >> If you are exporting GEDCOM data to share with others using different software, the first option might be better. The second option exports a custom tag right after that date. If you want to both use memos and export GEDCOMs to share in other software, you can run the script "Export Data/Move Memos to Notes" before exporting your data and all memos for a record will appear in notes for the record. They will not be next to the actual date, but will be available for reference. >> On Feb 21, 2012, at 10:38 PM, Swanfoth wrote: >>> Actually you should treat all attribute dates as date periods. A You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||