GDB Newsletter #17, September 2009
In this newsletter:
-
Who
can you record in your tree?
Record
quality and colour-coded search results.
Displaying
and Updating Table Data
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 a few people have even
said 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 low-quality records are useful even if
they do no more than suggest lines of enquiry.
It is not difficult to determine the quality of information. Does the
record contain source citations? Can you contact the record owner? Etc.
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.
In fact, I’m not sure if we could forbid it – there would have to be a
way of detecting it first.
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