Dear «Name»

NZGDB Newsletter #7, December 2007

 

Seasons Greetings.  I hope you had a fantastic family Christmas, and that you’re going to have a really great new year.  Perhaps 2008 will be the year that you finally track down those missing ancestors.   We’ll do what we can to help.

 

Since the last newsletter NZGDB continues to grow, and there are now more than 1.5 million people in the database.  The software continues to get better too: there have been several changes since the last newsletter: -  

·         Perhaps the most obvious is the change to the search rules, where initials are now handled.  Hopefully everybody will find this intuitive – let me know what you think

·         A few security (privacy) holes have been plugged.  Do you think that we are being too strict now?

·         I have been developing and testing facilities to take subscriptions, as the period in which NZGDB is totally free is coming to an end.  It may even be over by the time you read this.  From 1st January you will need to have a current subscription in order to open any record other than your own.  OF COURSE, YOUR OWN RECORDS REMAIN FREELY AVAILABLE TO YOU.

·         Help now owns in a separate page.  Also, you can open a second page to be able to look at two (or several) people together.

·         Brothers Keeper and Legacy users (and some others) now have a facility to easily upload their scrapbook data

·         Snapshot GED names are detected, and a message produced

·         Document Pages have been given a makeover.

 

There were some interesting emails on the question of whether it is it possible to “score” records, so that when there are duplicates the “best” record can be presented.  I haven’t done anything about this yet.  I’m still thinking about the approaches suggested, and whether this is a problem that is worth the cost of solution.

 

I haven’t done any more work on improving the reports: this is a project that I’ve held over to next year, when I plan to spend some of the subscription money acquiring some new software that should make the task of producing reports on line much easier.

 

To see the newsletter with formatting and examples, see http://www.nzgdb.co.nz/help/Newsletter_7.htm .

 

To stop receiving these newsletters edit your profile and check “No newsletters”.  This is the last checkbox in the “Preferences” section.

 

New Search Rules

 

You might have noticed that the search box looks slightly different, but the changes are subtle and you probably missed them.  Anyway, the real changes are under the covers.

 

So, what’s changed?  The biggest change is that initials are now handled properly.  For example, if you enter “J W” in the given name, instead of looking for the three characters J blank W somewhere in the name, the program now decides that these two single characters should be interpreted as initials, and the search returns these records: -

 

To be interpreted as an initial, you write a single character, followed by either a blank or a period.  You get the same results as above with either “j.w.” or “j w “ in the given name(s) field.  You can enter one or two initials, but not three or more.   You cannot combine initials and names:  “j.William” will be rejected with a message.

 

Occasionally the program chooses the wrong characters as initials.  Admiral Sir William Frederick PYM would be given initials “A S” rather than “W F”, and the program gets very confused with “Edward (Ted) John”, in this case missing the second initial completely.  You can correct such problems in your own records by editing the given name field.

 

I’ve added a field for Sex (OK, enough of the jokes).   There is little need to specify sex when you enter the given name as “John” or “Joan”, but it might be useful when you enter just the initial.   I’ve also taken away the [+] and [X] buttons, as I doubt that anybody ever used this compound search facility.  Intended to enable you to search for multiple names – for example both “McDonald” and “MacDonald” – I decided that it was easier to just do two searches.

 

Behind the scenes, a privacy hole has been plugged, so that if your search returns the record of a person with live parents the parents will simply be shown as “Male” and “Female”.  

 

Privacy strengthened

 

Another privacy issue:  you can see the records of my father, who died in 1985, but if you open one of these records you only see “Male” for his two sons.   However, if there is a duplicate record and you click the Compare command the comparison report showed the name and date of birth of my brother and me. This has now been fixed so that, like the record display, it only shows “Male”.  

 

However the privacy rules that should apply within the context of a comparison report are subtle, and I’m not sure that I’ve got them right.  I’d appreciate some feedback, after you’ve considered this example.

 

Example:  The database contains several records of Arthur Cyril BARNES(1901-1985), with children including Robert Arthur BARNES(1946-?).   There are duplicate links between the robertb records and the tonyc records of these people.   The records of Arthur Cyril BARNES are public, but Robert Arthur BARNES is still living and so these records are private.

 

Situation 1.   A user, who is neither robertb nor tonyc, opens the robertb record of Arthur Cyril BARNES, and clicks the Compare for the tonyc record.  In the compare report the user sees the facts of the two records compared, but in the section of the comparison report dealing with children he sees only “Male”.   No problem so far: the rules seem fairly obvious.

 

Situation 2.  As in situation 1, except that now the user is robertb, or somebody who has been given permission to see robertb’s records of living people.  However this user has NOT been given similar read permission for the tonyc records.   Now the rules become unclear.   The user can see from the Robertb record that there is a son named Robert Arthur BARNES.  Should he be able to see the namedate details that tonyc has recorded about this person?   While a strict interpretation of the privacy rule would say “No”, this seems a bit too strict.  After all, we already know that the record that we can’t see is a duplicate of robertb’s record of Robert Arthur BARNES, so what private information is being exposed that we don’t already know?

 

Situation 3.  What if we try to compare the records of Robert Arthur BARNES?   Robertb doesn’t have permission to open the tonyc record, so it doesn’t appear in the search, and he won’t be able to open the “Male” link in the parent’s record.   This is simply the normal rules so far.  So robertb opens HIS OWN record of Robert Arthur BARNES, where he sees a duplicate link to the tonyc record, with a compare command.   Should he be able to compare these two records?   Again, a strict interpretation says “No”, but robertb has his own record of this person, so is there a privacy issue in comparing this with somebody else’s record?

 

There are two rules that I could program.

Option 1.  We apply the privacy rules strictly.  To compare two records, you have to have read permission for both records.

Option 2.  We apply the privacy rules that apply to record 1.  If you have permission to see record1, then you can compare it with any linked duplicate, even if you don’t have permission to see this record in other circumstances.

 

What do you think?   Currently the system takes the strict approach, Option 1.

 

Free Access is about to end

 

From 1st January the basic (free) registration will only give you access to your own records.   You will be able to search for records, seeing from the search results whether there is anything of interest to you, and you’ll be able to open many of the other facilities such as the document database, the list of useful web sites, and so on.  However, you will not be able to open a record that you find in the search unless it is your own record, or you have a current subscription.

 

There are two ways of getting a current subscription.   You can pay – the annual subscription is only $25, and facilities have been provided to pay by cheque, internet banking, or credit card (Visa and Mastercard). 

 

The other way is to load some records of your own.   If you load a GED with 2000 records you’ll get enough credit for a year’s free access.  Of course those who have already loaded records don’t miss out: their credits are calculated from 1st January.  We have some users who will need several lifetimes to use up all their credit!

 

Other Changes

Among the large number of small changes: -

 

(197): Help now opens in a separate page.

 

This allows you to keep the help page open while you use the page.  I prefer the way that Firefox handles this, where the new page is opened in another tab.  Internet Explorer opens a separate window over the top of the preceding one, and unless you drag it out of the way it looks as if the original page has gone until you close the Help.

 

(211): Facility to upload scrapbook data.

 

For some users there is now a smart way of uploading their scrapbook data.  Many of you will have attached photos (and other documents) to your genealogy records in your PC databases using its “Scrapbook” facility.  If you’ve attached a photo of Great Aunt Maude, when you upload your GED to NZGDB you’d really like this, and the other scrapbook data, to be uploaded as well.   Unfortunately this is quite impossible for users of programs like Family Tree Maker and Personal Ancestry File (PAF) that don’t include scrapbook data in the GED.  If the data isn’t there, then there’s nothing that any program could do.  But what about users of Legacy and My Brothers Keeper (and some other systems) where the GED file includes references to these picture files on your computer?  Can anything be done for these users?

 

It is not possible to write a program to simply upload these files.  If it was, then any programmer could easily write a program to take any file from your computer. An obvious security nightmare!  However what I have been able to do is to provide a dialog that goes through the GED data and prompts you to select the appropriate files, then uploads them and links them to the correct GDB records.  Look under “Manage your GDB Data”, click the [Upload your Scrapbook Data] button.  I hope you’ll find this easy to use.  Let me know what you think.

 

(314): Open another page. 

 

There is now a standard link in the left column, “Another page”.  Click this and you see another home page, from which you can open another page without closing the page that you’re on.  Thus you can have two individual pages open, or an individual page and a document, or whatever you like.  You can have several pages open.  However the pages are not completely independent.  For example, if you log off from one, then the others will have been logged off also.  If one page is busy waiting for a response all your pages will be waiting.

 

(352): Snapshot GED names are now detected, and a message produced.  

 

Users often submit GEDs with names like “Barnes071220.ged” to indicate that this is a snapshot of their data as at the 20th December 2007.   Later an update may be submitted as “Barnes080515”.   This has unexpected consequences however!  Both sets of records are stored independently, leading to duplication and confusion unless the first GED is deleted, but deleting the first GED will loose its scrapbook information and links from other GEDs and so these may have to be re-created with the new GED.  It is better to use a general name like “Barnes.GED”, and to keep reusing the name as new versions of the GED are submitted.

 

I have written about this in a previous newsletter, but snapshot names are still common.  The submission process will now produce a warning message if the GED name contains “07” or “08”, and direct you to a link discussing the reasons why you might like to consider another GED name.   In the list of your GEDs that you see from Manage your GDB Data the date of the GED submission is now displayed, so you don’t need to have this date in the GED’s name.

 

(443): Documents pages have been reviewed. 

 

In the “Documents” section of NZGDB there were a number of pages and functions that were developed in the early stages of this project, but had then received little attention as I concentrated on the GDB and on GED processing.  The documents pages have been given a spruce-up, making their appearance more attractive and consistent with the GDB pages.  The search facilities have been improved, and searching now allows the wildcard character “*” to be used meaning “Any number of any characters”.  The previous wildcard character, “%”, which was a well-kept secret, remains available as an alternative.

 

Other changes are mostly error fixes and minor reformatting.  Click here to see the complete list, and click here to the current task list

 

Regards,

Robert Barnes,

NZGDB Developer