There are actually a lot of new things in this new version. It could almost be named 1.1, but I won’t do that since it would require another submission to Winqual for Behold’s Window’s 7 Certification - which i’ve actually achieved, but recognition of such is being delayed by something on Microsoft’s side - but that’s another story for later.
Please upgrade your beta or 1.0 Version to this 1.0.1 version. It fixes a number of issues that were in 1.0. The main one was that only a few of the dates and places were being shown on the event references. Now they’re all there again.
The major improvement is handling of dates. Behold only used to read in the date as it was given, and then display it out again for you. But now that I’ve been convinced that it’s important for Behold to display events and children and marriages in order of earliest to latest date, it suddenly became important to be able to read and understand dates internally.
As I studied how GEDCOM wants this to be done, which was IMHO very well thought out and quite flexible, I discovered how poorly other programs exported their dates. Some of my recent blog posts were about this problem.
So now Behold will check all your dates for GEDCOM compliance and put a message in the log file for those that are not compliant. You’ll need to know this, because some programs may not be able to read those dates correctly. Behold will also ensure the dates actually exist, and will indicate to you a data problem if, say you stated a date is 31 Nov 2011. I’ve also included a **Check your date** flag in the Everything Report next to these bad dates. Try your GEDCOM on the new 1.0.1 version and see what bad dates you’ve got in your dataset. You might be surprised.
Behold now understands Gregorian, Julian, French Revolutionary and Hebrew dates - the four that are defined in GEDCOM. It also handles and checks double dates (when the Gregorian calendar was partially adopted), and B.C. dates for those of you researching your Pharaoh or Caveman ancestors.
Just for fun, I’ve added the day of week which now shows in the Everything Report before every valid day/month/year.
You can now customize the names of the months, weekdays and date modifiers (e.g. about, from/to, estimated) with settings in Behold’s Organize Reports page. This will now allow you to change the dates so that they are in the same language as your data. The language translation files on Behold’s download page have not been updated for these yet. Any volunteers?
I also found out that there was a GEDCOM 5.5EL (Extended Location) extension in use by a few programs from Germany. With this version, I’ve included support for that.
For a complete list of the changes in this version, see the Behold Version History page.
Joined: Sun, 4 Dec 2011
9 blog comments, 1 forum post
Posted: Wed, 28 Dec 2011
Hi Louis,
Mind if I make one suggestion…Can the sources be made easier to read?
Instead of this-
1. Martin Avery Godfrey
Source: [S67-29 North Carolina Death Certificates, 1909-1975 - ~http://trees.ancestry.com/rd?f=sse&db=ncdeathcerts&h=1833027&ti=0&indiv=try&gss=pt||Birth date: abt 1872Birth place: McDowellDeath date: 10 Jun 1933Death place: Marshall, Madison, North Carolina]. [S1452-43 World War I Draft Registration Cards, 1917-1918 - Registration Location: Madison County, North Carolina; Roll: 1765688; Draft Board: 0.]. [S9-199 1900 United States Federal Census - Year: 1900; Census Place: Marshall, Madison, North Carolina; Roll: T623_1205; Page: 19A; Enumeration District: 72.]. [S11-323 1920 United States Federal Census - Year: 1920; Census Place: Marshall, Madison, North Carolina; Roll: T625_1294; Page: 3A; Enumeration District: 118; Image: .]. [S12-311 1930 United States Federal Census - Year: 1930; Census Place: Marshall, Madison, North Carolina; Roll: 1704; Page: 6A; Enumeration District: 11; Image: 795.0.]. [S10-192 1910 United States Federal Census - Year: 1910; Census Place: Marshall, Madison, North Carolina; Roll: T624_1107; Page: 1B; Enumeration District: 82; Image: 309.]. [S110-4 Unnamed Source - Year: 1930; Census Place: District 4, Clay, Tennessee; Roll: 2237; Page: 13A; Enumeration District: 8; Image: 943.0.]. [S71-1 North Carolina Volunteers, Spanish American War - ~http://trees.ancestry.com/rd?f=sse&db=ncar-saw&h=2280&ti=0&indiv=try&gss=pt||Residence date: Residence place: North Carolina]. [S1152-1 Unnamed Source - ~http://trees.ancestry.com/rd?f=sse&db=ncar-saw&h=2280&ti=0&indiv=try&gss=pt||Residence date: Residence place: North Carolina]
Can we get this-
1. Martin Avery Godfrey
Source:
[S67-29 North Carolina Death Certificates, 1909-1975 - ~http://trees.ancestry.com/rd?f=sse&db=ncdeathcerts&h=1833027&ti=0&indiv=try&gss=pt||Birth date: abt 1872Birth place: McDowellDeath date: 10 Jun 1933Death place: Marshall, Madison, North Carolina].
[S1452-43 World War I Draft Registration Cards, 1917-1918 - Registration Location: Madison County, North Carolina; Roll: 1765688; Draft Board: 0.].
[S9-199 1900 United States Federal Census - Year: 1900; Census Place: Marshall, Madison, North Carolina; Roll: T623_1205; Page: 19A; Enumeration District: 72.].
[S11-323 1920 United States Federal Census - Year: 1920; Census Place: Marshall, Madison, North Carolina; Roll: T625_1294; Page: 3A; Enumeration District: 118; Image: .].
[S12-311 1930 United States Federal Census - Year: 1930; Census Place: Marshall, Madison, North Carolina; Roll: 1704; Page: 6A; Enumeration District: 11; Image: 795.0.].
[S10-192 1910 United States Federal Census - Year: 1910; Census Place: Marshall, Madison, North Carolina; Roll: T624_1107; Page: 1B; Enumeration District: 82; Image: 309.].
[S110-4 Unnamed Source - Year: 1930; Census Place: District 4, Clay, Tennessee; Roll: 2237; Page: 13A; Enumeration District: 8; Image: 943.0.].
[S71-1 North Carolina Volunteers, Spanish American War - ~http://trees.ancestry.com/rd?f=sse&db=ncar-saw&h=2280&ti=0&indiv=try&gss=pt||Residence date: Residence place: North Carolina].
[S1152-1 Unnamed Source - ~http://trees.ancestry.com/rd?f=sse&db=ncar-saw&h=2280&ti=0&indiv=try&gss=pt||Residence date: Residence place: North Carolina]
Yes- it takes a bit more space- but it sure is easier to read and keep track of where you are.
:)
Andy
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Wed, 28 Dec 2011
Andy,
The organization and indentation within an individual is something I haven’t looked at in a few years and it’s worth revisiting.
My original concept was to start each Level 1 event/fact on each line. Then all the information that pertains to the event/fact would be in the same paragraph.
However, as you point out, often there are many sources pertaining to one of these events. And it is difficult to identify and even compare the sources because they are not easy to read. So yes, now I will definitely be doing something about it and I will make it easier to read.
But there is an aspect of this that you haven’t considered. Some sources are at level 1 pertaining to the person, some are at level 2 pertaining to the event, Some are at level 3 pertaining to the date of the event, or the place of the event, or a note about the event.
If I batch all these sources out by event, then I can do what you suggest. I think I just discovered that GEDCOM 5.5.1 made a change from GEDCOM 5.5 that implied that they were leaning this way. See my post on The Place Record in GEDCOM.
I like this idea. In fact I think I should extend it for Notes as well, and always start them in a new row. Multi-line notes will line up better that way as well.
It might end up looking like this:
1. Martin Avery Godfrey
Note: Notes about the person
Source: [Sn-d Source title - Main source detail line]
Source: [Sn-d Source title - Main source detail line]
Birth: Sat 25 Sep 1875 in Madison County, North Carlina, USA
Note: Notes about the birth event
Source: [Sn-d Source title - Main source detail line]
Source: [Sn-d Source title - Main source detail line]
Death: Confirmed.
Note: Notes about the death event
Source: [Sn-d Source title - Main source detail line]
Now continuation lines may still look messy, unless I indent them an extra 6 spaces or more so they are obviously continuations.
Also I’ll sort the sources properly, because then they’ll appear in SmartSort order, e.g.:
[S9-199 1900 United States Federal Census - Year: 1900; …
[S10-192 1910 United States Federal Census - Year: 1910; …
[S11-323 1920 United States Federal Census - Year: 1920; …
[S12-311 1930 United States Federal Census - Year: 1930; …
[S67-29 North Carolina Death Certificates, 1909-1975 - …
[S71-1 North Carolina Volunteers, Spanish American War - …
Finally, I notice the (let me call it) “mess” that appears as the main source detail line, e.g.:
~http://trees.ancestry.com/rd?f=sse&db=ncdeathcerts&h=1833027&ti=0&indiv=try&gss=pt||Birth date: abt 1872Birth place: McDowellDeath date: 10 Jun 1933Death place: Marshall, Madison, North Carolina
This looks like one of the RootsMagic “messes” I’ve been blogging about. I definitely can do some things to clean this up. Firstly, all the extraneous key/value pairs need not be part of the source detail line. All that’s really required on the source reference at this point is enough information for you to identify generally what the source is, and the rest of the detail can be with the source itself.
As well, I should probably detect inline web links and make them hyperlinks, such as the:
http://trees.ancestry.com/rd?f=sse&db=ncdeathcerts&h=1833027&ti=0&indiv=try&gss=pt
I’m really glad you brought this up. This is really a good time for me to implement the restructure/indenting. I was wondering how I’d easily identify where you are within the event for editing purposes, By making the sources and notes (and objects as well) start on new lines will make that task a lot easier.
We’ll see how many of these changes I can squeeze into Version 1.0.2.
Louis
Joined: Sun, 4 Dec 2011
9 blog comments, 1 forum post
Posted: Wed, 28 Dec 2011
Hi Louis,
The ‘mess’ isn’t caused by RM5. It is, unfortunately, what you get when you export an Ancestry Member Tree and download it. If you go to this link there is a whole thread about it. Ancestry fixed the problem but it looks like with patching FTM2012 and the new Mac version, etc. they broke it again. Strangely enough, if you do a direct download of a Member Tree into FTM2012 and then export a GEDCOM from FTM2012 you don’t get the mess.
http://boards.ancestry.com/thread.aspx?mv=tree&m=1186&p=topics.ancestry.membertree.membertrees
I’ll be sending you e-mail with the other stuff you asked for.
Andy
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Thu, 29 Dec 2011
Andy,
Then it must be that FTM must have special code to fix the Member Tree “mess”.
I notice amongst my 683 test files, I only have 2 that indicate they are from Ancestry.com Family Trees. I’ll take a look at those and I’ll download a few more from Google using the search: “sour ancestry.com family trees” filetype:ged
Louis