Re: GEDCOM to Wiki, anyone?

Hi Darren,

Thanks for posting this to the list. I haven't included your  
conversation with Dave in this reply, to keep the posting short.

A few thoughts...

There already exist a number of systems which store genealogical  
information in relational databases, for display by wikis or in more  
traditional genealogical style. I have been using the open-source  
phpGedView (see phpgedview.sourceforge.net or www.phpgedview.net) for  
some while now, and use perl-gedcom utilities for various management  
tasks and for writing the occasional one-off processing tool.

php or perl? Horses for courses, in my view. Both will do the job:  
php, in my view, is better than perl for generating web pages on the  
fly, and more widely used, though perl can do the job tolerably well.  
perl has its own strengths, and if you're just creating a database  
for genealogical data with your own front-end, perl would do it  
perfectly well. But it's already been done.

phpGedView, GeneoTree, Oxy-Gen and other existing systems are all  
designed to parse gedcom files and convert them to SQL databases. It  
would seem to be more useful to contribute to existing open-source  
systems that to start trying to write a new one for one's own use:  
for example, phpGedView already provides tables which allow for  
multiple families, aliases, source information and quality by  
implementing the full GEDCOM structure.

I must admit, I do like your distinction between "first hand  
experience", "assumed most likely considering X" and "just heard it  
somewhere" as examples of differing quality of non-record-based  
sources. GEDCOM 5.5 (still the de facto standard, and the  
implementation on which this list is based) only has QUAY 0/1/2/3  
(which it defines basically as "unreliable" / "questionable" /  
"secondary" / "primary or evidence-based"), and these are neither  
carefully enough defined nor sufficiently widely or consistently used  
to be of much value except to the person ascribing the quality to the  
source in the first place.

Regarding database implementations: I understand (as a software  
developer myself) that there is a camp where PostgreSQL is strongly  
preferred over MySQL, and the recent acquisition of the latter has  
added fuel to the cause. But (imho) you're heavily overstating the  
case to claim that PostgreSQL "is a much more reliable and better  
quality DBMS, which all the savvy people prefer over MySQL". One  
factor many people have to take into account is that many third-party  
web-space providers also provide MySQL servers: users may not have  
the choice. In my experience, they differ more in implementation than  
in quality, and MySQL works perfectly well (and reliably) for the  
sort of task genealogical databases require. It's widely-available,  
well-supported, industrial-strength, scalable, and I like it :-)

Just my two-penn'orth...

/mike

On 29 May 2010, at 05:13, Darren Duncan wrote:

> FYI, the following message is a quick private exchange between Dave  
> Patton and myself, where Dave had written me privately, apparently  
> in response to a post I made to this list in February of 2007 with  
> the same subject line; I am forwarding it in case my contained  
> brief suggestions on how to design a genealogy database would be  
> useful to others. -- Darren Duncan