Dear «Name»
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.
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”.
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.
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!
Among the large number of small changes: -
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.
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.
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.
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.
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