Re: Wiki software for genealogy (long)


"SteveW" <steve.m.west@xxxxxxxxxxxxxx> wrote in message
news:46c20ecd-082f-4141-b81c-1ab1f5d53889@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Background
==========
I believe that genalogy software should ideally do three things.
Firstly it should be able to store information about people and their
relationships, including some data which can be in a standardised form
(such as birth dates) and others which can be free-form (biography
etc). Secondly it should be able to store source material:
photographs, document scans, transcripts, emails, etc. Thirdly, it
needs to allow connections to be made flexibly between the people data
and the source data so that, for example, a person's birth date can be
linked in some way to a record such as a scan of their birth
certificate. Most genealogical software is excellent at the first of
these three requirements (except that it may not be able to express
degrees of certainty about relationships between people). Such
software can also cope adequately with the third requirement but is
usually weak at the second, particularly in a case such as a one-name
study (which is part of my own interest in genealogy) where one
collects a lot of source data that is not (yet) linked directly to any
known people. There are some packages, such as "Custodian" which have
been written specifically to address that second area, but they tend
to be weaker in the other areas. This current deficiency of genealogy
software led me to look for alternatives.

A second motivation is that I am always looking for new possibilities
for exploiting technology for genealogy: I began experimenting with
using a computer for genealogy in 1981, I was (as far as I know) one
of the first UK one-namers to put their information on-line on a
website, and for the last 7 years have been generating the complete
site from a database. So, yes I love to try out new technology!

Enter the wiki
==============
Wikis are websites which allow multiple authors to collaborate on
online projects, of which the best-known is probably Wikipedia.
However, although it is the collaborative nature of wikis that is most
discussed, there is nothing to stop them being used as a stand-alone
application for organising information about a family history. And
this is what I have been doing! I chose to use Mediawiki, the same
software, as it happens, that is used for Wikipedia, and it seemed to
me that its strengths are:
- You can load all kinds of "media" into it: images (in lots of
formats), video, pdf documents, word documents and use it like an
electronic filing system.
- It is good at linking information together: take a look at Wikipedia
and the way that everything is linked to everything else.
- It is very good for editing the free-format (eg biographical)
information about people.
- It allows the creation of templates which could be applicable to
such things as recording information from certificates or censuses.
- The software is free

I also recognised the potential disadvantages:
- There are no built-in specifics for genealogy: no direct way to
express relationships between people or to identify a particular
fragment of data as being a birth date, for example.
- It seems like overkill to have to install Mediawiki plus a database
plus a webserver.

Experience so far
==================
This is an ongoing experiment and I haven't reached any "final
conclusions" yet, but here are a few observations.

I installed the software on a Linux machine (I also have a Windows
computer and it should work on that, too, but I haven't tried). The
installation was very straightforward and, although Mediawiki +
database (MySQL in this case) + webserver (Apache) seems like a lot to
install, it's small compared with something like Microsoft office!

With regards to the use of the wiki as a "genealogy filing system", it
excels at this and is much superior to a paper filing system. I have
often found myself holding, say, the marriage certificate of a
Sharratt to a Smith and wondering: so do I file it with the Sharratts
or the Smiths, or does it go in a separate folder for certificates? By
scanning it and loading it into the wiki, I can tag it with
categories. In this case, I can choose to tag it with categories
"Sharratt family", "Smith family", "Certificates", "Marriage records"
and "Documents from the 19th century". Automatically, a link to it
will appear in the wiki's indexes for each of those categories.

The area that is completely missing from the wiki is the ability for
it to understand that particular data items represent, say, dates of
birth. I have got over this, to some extent, through the use of
templates: each page about a person, for example, includes a template
with basic birth, death, baptism, etc information. I have also written
some simple scripts to allow me to populate all this information from
my existing database.

I am currently trying to use the wiki in two slightly different ways.
Firstly I am using it for my own ancestors. Over the years I have
accumulated quite a lot of biographical information for many of them,
and the wiki is quite successful for writing up this information,
whilst providing links to scans and transcripts of source documents.
Secondly, I have just started experimenting with it for storing the
information about my one-name study. This is much more daunting
because it includes an order of magnitude more people and a lot more
"templated data" such as birth indexes.

The experiment continues!

Regards

Steve West

Wiki is much too free-form as a collaborative method Steve. Sure, it can be
linked all over the place but there's no structure to that linkage - you
simply get a cat's cradle of linkages

In order to get the right balance between the structure of the data and the
ability to have free-form references to it, I'm currently working on a
private project to define-and-create an object-model and mark-up language
that together can be incorporated into a UI of choice

I understand the sentiments though. The current range of genealogy software
is completely proprietary and is reminiscent of other database areas of old,
including OLAP, and even relational databases themselves. Unfortunately,
there's little in the way of impetus or vision for consolidating this. Such
suggestions are often mistaken for requests to use a standard database, or a
standard file format, or whatever - none of which are true. For instance, by
defining an object-model you effectively separate the mechanics of the
database from the goodies provided by the UI. In principle this could yield
a mix-and-match situation but it would more likely yield the ability for
products to cooperate and a less ambiguous definition of the data being
exchanged.

Separating the two parts like this would allow genealogical (although they
would have more scope than that) database software to become a commodity,
developed and tested by database specialists. What you do with the data, how
it's presented, what options you provide, and what inferences you make,
would then be the responsibility of the products that sit on such databases.
For instance, no one would now consider writing a program that incorporated
its own proprietary relational database - such databases were consolidated
long ago, and even have a standard(-ish) query language (SQL). No, you would
program to a general SQL database, or to SQLServer/Oracle/others, but you
wouldn't try and compete with them. This has not stopped the development
other more specialised databases, though, such as object-orientated ones,
and multi-dimensional ones (OLAP).

Even though genealogy is becoming more popular, most users would probably
still fall into the category of 'casual' or 'hobbyist'. The vendors of such
databases would not be selling to huge multi-national companies and so the
prices would have to be considerably lower. Less prospect of huge profits
then means that no serious project is likely to get started. However, if the
scope was extended beyond genealogy (for instance, any historical data) then
it might have more of a chance. I can imagine a new category of database
specifically designed for this type of data with its complex linkages.

What we need is another E. F. Codd :-)

Tony Proctor


.

Relevant Pages

  • Re: Specificities of French Medieval genealogy
    ... A genealogical database for medieval Breton nobility exists: ... Liste de diffusion sur la noblesse Bretonne ... indicates by itself some lack of interest for popular genealogy. ...
    (soc.genealogy.medieval)
  • Re: Managing Genealogy Relationships in FMP 8.5
    ... the database (the file has tables for managing photos, documents, ... but a complete map is hella more efficient. ... You now understand how a genealogy tree can be ... Replace a Sort field to 1. ...
    (comp.databases.filemaker)
  • Re: Wiki software for genealogy - update
    ... wiki from my existing genealogy database, ... complementary scripts that will recreate the database from the ... confident to work on the wiki, knowing that I can always switch back ... pages for the source materials. ...
    (soc.genealogy.britain)
  • Re: How many names?
    ... file-size than a simple head-count. ... Sullivans in separate files and don't have anything like that many ... making genealogy very personal has a place also. ... I don't know about the new version, but the old PAF 2.x had a names database. ...
    (soc.genealogy.computing)
  • Managing Genealogy Relationships in FMP 8.5
    ... I recently inherited a genealogy database with 27,000 names in it. ... The file was in GEDCOM format, so I tried lots of genealogy ... constraints of off-the-shelf designs. ...
    (comp.databases.filemaker)