GDB Newsletter #17, September 2009
In this newsletter: Correcting Family Tree Errors ................................................................................................... 1
Who can you record in your tree? ............................................................................................. 2
Record quality and colour-coded search results. ...................................................................... 2
Succession Planning ................................................................................................................. 3
Remote Presentations Anybody? .............................................................................................. 3
Development – mainly FamNet ................................................................................................. 3
Creating your own tables ....................................................................................................... 4
Defining Columns ............................................................................................................... 5
Specifying Access Rules .................................................................................................... 5
Displaying and Updating Table Data ..................................................................................... 6
Images and Photo Libraries ................................................................................................... 7
Further development .............................................................................................................. 8
Correcting Family Tree Errors
What do you do when you find a record of your ancestors, and it’s wrong?
We sometimes field criticism from GDB users who find incorrect information in some of our
records, and I have had a few people tell me that they won’t support the GDB, by either
subscribing or by putting their own records into it, until I “Fix this problem”. Such criticism
misses the point.
Around the world millions of people are collecting information about their ancestors. Some of
this information is gold standard, well documented information about close ancestors, some is
unsourced but probably true, and some is carelessly collected and flat out wrong.
When we work in the traditional way, hoarding information in our private database, nobody
else can use it, or check it. Perhaps our “facts” are actually wrong – but nobody can help us.
Perhaps we have the truth – but nobody knows, and so they continue to believe the mistakes
of others. Genealogy is often likened to doing a jigsaw. The traditional approach has us
each doing our jigsaw in a private room on our own. Using the GDB is like us all working on
our parts of a large jigsaw around a large table – we pass each other pieces, sometimes we
find that our piece links to somebody else’s piece, and so on. Not only is this much more fun,
but we make much more rapid progress, and the constant peer review means that mistakes
are more easily detected and corrected.
To hold back from publishing your database because other databases have mistakes, or have
been put together by “mere name gatherers”, is daft. You may indeed have the truth, but by
not publishing your database you leave the field to others whose facts may be wrong. And
how can you criticize someone from copying incorrect facts and relationship into their
database when you haven’t published the truth to set them straight?
Systems like NZGDB have many mechanisms to improve the quality of everybody’s records.
Firstly, when you submit a database the system will match up duplicates, making it very easy
to compare what different people say about a person. For example, check on a record such
as Hannah OLD(1860-1939). You’ll find many records: open any of these records and you’ll
see a list of duplicates, with tools to compare the records. You can easily judge which
records are correct, and which are not, and you can contact those with incorrect information
(or they can contact you) to correct the errors.
Secondly, when you discover an error you can often contact the record owner with better
information. If you cannot contact the owner you can put a “Post-it” note on the record so that
anybody else can see that you have different information.
Finally, you can link your tree with others, so that your good information about your family
replaces poor information that was only peripheral to somebody else’s tree. This requires the
active cooperation of both genealogists of course, so can’t always be done, but when done
well (as in Merged-001.ged) you can end up with a very large tree of high quality information,
where multiple owners each look after a different part of the database.
Who can you record in your tree?
In the past few months I’ve fielded a couple of complaints about users who are “collecting
names that are not even related”. One complaint was about a person who was “Just
collecting names, without any concern for accuracy”, another was that somebody had
incorporated information that had been given to them “for their own use only, not to be
published” and this 2nd complainant was angry to find this data within records when the record
owner was “not even related to xxxxx” (it was claimed).
All this puts us in a difficult situation. Fundamentally, any issue of this kind is between the
database owner and the complainant, all that we can do is to attempt play the role of an
independent mediator, helping the two parties to reach some sort of agreement. Unless our
rules have been breached we will not force anybody to remove or change data on the site. It
is a database owner’s right to say whatever they like, provide they keep within the rules or
privacy and copyright.
In this case the result was that the people complained about amended their data, in one case
replacing a database of about 90,000 names with one of about 20,000. Frankly, I was sorry
to see this happen. Although I can understand his being worn down by the carping about
“mere name grabbing”, actually we have all lost, especially as the complainant has not put
their own (presumably better) data on to the GDB to compensate for the loss of the earlier
data. Yes, we would all like every record to be well researched and accurate, but even lowquality records are useful even if they do no more than suggest lines of enquiry. It is not
difficult to determine the quality of information.
What of the criticism about “collecting unrelated names”? In this case the criticism was
unfounded, there was in fact a relationship (if distant) between the list owner and the disputed
records. But what if there had not been? Isn’t this what people do when they trace the family
relationships of royalty or other famous people? Or what somebody doing a one-name study
does? What do you think? To me it seems a little odd to collect unrelated names, but not
actually something we should forbid.
Record quality and colour-coded search results.
You may have noticed a change a couple of months ago, in which the search results lines
may now be green, white, or gray. This is an attempt to indicate the quality of the information
before you even open the record.
Green lines indicated a record that has scrapbook items. These are the highest quality
records. Scrapbook items cannot be automatically uploaded with a GED, but require
somebody to upload the photo (or document etc) to the record. These records are therefore
being looked after by somebody who has access to family photos and other documents, and
are therefore likely to be accurate and full of information.
White lines are normal database records with a real owner. The quality varies, but you can
contact the owner if you have any queries.
Gray lines are Datamanager databases. These are the lowest quality of information: we have
been unable to make contact with the record owner, and so if you use the “Contact Record
Owner” link you’ll just be sending an email to Tony who won’t know much about the
information there. We have considered suppressing these records, but the feedback we’ve
received suggests that the records are useful provided you’re a bit cautious, and so they
should remain provided people realize that these are of lesser quality than other records.
Succession Planning
The ideal is that every database in the GDB has an active owner who keeps it up to date, and
can respond to queries should anybody have a question about the data within it. However we
have a number of databases in the GDB where we have been unable to contact the
database’s owner. Usually the only contact information is an email address, but of course
email often stop working. So these databases exist in a sort of limbo, they will remain on the
database indefinitely, but with nobody to look after them they won’t be kept up to date, and
there is nobody who can respond to queries.
And of course what happens an owner ceases being contactable. This may be simply that
they have changed their email provider and not updated their profile, or perhaps they have
gone to join their ancestors. Either way, we have lost contact with them.
What should we do about finding new owners for these databases? We have added a
section to the profile “Trustees” to help with this. If you have a database on the GDB, please
use this to record alternate emails and people we should contact if your main email ceases to
work. If your email fails (which we will know when we attempt to send you a newsletter), then
we can use this to find your new contact details, or a new owner for your data. That way we
can ensure that your data lives on, even if you loose contact with it.
Remote Presentations Anybody?
I have given presentations about NZGDB throughout much of New Zealand. There is a
standing offer to make a presentation anywhere within driving range of Auckland, and I have
also given presentations in the South Island and in Taranaki, Kapiti, and Wanganui when I
have been able to combine this with other travel such as family holidays. However, travelling
further afield is usually too expensive.
I’d like to experiment with giving a remote presentation using Skype. So far I have used
Skype just for video phone calls, but there are software options that should allow me to show
you my screen, take you through a demonstration of the site, and interact with an audience
almost as if I were there. Would this be as good as having a live speaker? Probably not, but
it might come close. If so, this would be a good way of presenting to distant groups without
the expenses of airfares and accommodation. If anybody is interested in trying this out,
please contact me and we’ll start discussing how to go about it.
Development – mainly FamNet
Development has continued to focus on “FamNet”, particularly the ability to create and
manage your own databases of whatever kind of information you want.
In the last newsletter the combined search was described. Click the link “FamNet Combined
Database Search” from the home page of www.nzgdb.co.nz, or go to www.famnet.org.nz and
click the relevant button, and you’ll see a list of databases with the ability to do a combined
search, and have the search tell you the number of hits for each database so that you know
which ones are worth looking at: -
Creating your own tables
A new feature is the button [Edit/Create Table definition]. Click this, and a page appears in
which you can define your own tables. If you are a group administrator then these tables may
be within your own group, but for others tables can be defined within FamNet.
Creating a table is basically a four-stage dialog: 1.
You give the table a name, and give a few details such as notes, and link to a parent
table (if this is table like Burials, which is related to a Cemetery record)
2.
You then define the fields (or “columns”) of the table. See below for more detail.
3.
You specify the access rules – who can see this table, who can add records to it,
whether anybody can download it’s data in a spreadsheet, and so on.
4.
Finally you “Fix” the table. This creates the table within the database and makes it
ready for accepting data. It will now appear in the database list, and be included in
the general search if it contains fields about people.
You can also edit the details of your tables (but not anybody else’s), changing or adding
columns, changing the access rules, and so on. If the table has been fixed, then there are
some restrictions on what you can do without deleting and re-creating the table.
All this is described in detail in Help, which you’ll find as usual in the left hand column.
“If you build it, they will come”: I feel like Kevin Costner’s character in “Field of Dreams”. Will
people use this facility? It will be interesting to see if they do. We have a few Cemetery/
Burial records from one GDB user, and the GDB shipping data has come from another user
on Gt Barrier Island. I’m hopeful that many others will use this facility.
Let me stress: the data remains yours, you are identified as table administrator, you can do
what you like with it, and you don’t even have to leave your own web site as both the general
database search, and the specific table page, can be pasted into your own web site if you
want this. It does not constrain in any way what the data contains, or what you can do with it!
The facility has been designed to support restricted and subscription databases as well as
free databases, but so far everything except the GDB is completely free. My policy will be
that GDBServer will host without charge anybody’s data that is freely available to all, but
restricted or subscription will involve some cost or revenue sharing.
As I said in the last newsletter, it will be interesting to see whether this idea is well supported,
or whether the present situation remains the norm where each group’s individual web site and
databases remain lost in the web forest, undiscovered by most of the people who would be
interested in its information. If the idea is well supported there is tremendous potential for
further development of this idea. Even with the advances of the last few months, this is just
the beginning of our the ideas for providing advanced web services to the family history
community. But if few people use what’s there now, then further development is less likely.
The next two sections show you how easy it is to define your database, and to manage
access to it: -
Defining Columns
Defining columns is very simple: you just name the columns that are in your table, and say
what type of data they are. Normally you’ll add the columns from top to bottom, but you can
easily reorder the columns, or add columns out of sequence, simply by editing the sequence
number: -
Field types are:  Text
 Number
 Date (when you know the date exactly)
 Genealogy date (when you may use the genealogy forms “ABT”, “AFT”, etc, or when you
only know the year
 Reference value. This is when there is a table of valid values. Here the value of
“Country of Origin” must exist in the table “Countries”.
 Image.
A picture, which you will upload as a .jpg (etc) file.
Specifying Access Rules
The table owner can define who can access (and update) the table. Tables may be freely
available, restricted to a particular group, or private to their owner. They may be available for
free, or require a subscription. There may be different subscription charges depending on
group membership. (Facilities to manage payment for tables will be developed when there is
a requirement for them: at the moment all tables are free). Some or all of those who can see
the table may be able to download it, and/or to update it on line or by download/upload.
Only the owner (and administrators) can change the table's definition and rules.
The following example shows typical access rules. In this case, each record in the table can
be individually owned, and anybody can add a new record (which they will own). For
example, this rule applied to the Cemeteries table means that anybody can add a cemetery
record, and an associated set of burial records: they will control this set of records, while
others will control other cemeteries. Rather like the way you control your own family tree in
NZGDB, but not anybody else’s.
Displaying and Updating Table Data
When you select a table from the list by clicking “Open”, a page such as this will display the
table data, with a search panel. Here we have displayed the burials table with a search for
family name “Quick”:-
If you are the table owner, or have been given various rights by the table owner, then a
number of other buttons may appear, and the search panel is also used to add and update
records. Select a record and the grid disappears, with the selected record appearing in the
search/update panel where it can be changed and [Update] clicked to update it: -
As this example also shows, if you have the appropriate permissions you can download the
table as a spreadsheet, including downloading it in a form that will allow you to edit it off line
and re-upload it again. The table owner also has the ability to edit the table’s definition.
Images and Photo Libraries
One of the columns of a table can be an image. For example, I’ve created a table in which
people can post pictures so that other people can help them to identify them: -
Select an image and it is displayed at full size. Somebody who can help to identify the
picture can click the link “Contact Record Owner”, or “Contact Table Administrator” to pass on
what they know.
Further development
Already this is a very flexible facility, able to meet many needs. If you want further
information, you can read the two Help pages: Table searching and updating: http://www.famnet.org.nz/help/Table_Help.htm
Creating and editing table definitions: http://www.famnet.org.nz/help/TableAdmin_Help.htm
But this is only a starting point, and I expect this facility to develop further in response to user
experience. Already I have a list of further ideas to make it even better. But let me know
what you think.
Robert Barnes,
NZGDB and FamNet Developer