Re: GEDCOM to Wiki, anyone?

Mike Elston wrote:
> 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.
> 
> 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.

Speaking just for my own intended project, not Dave's, my understanding is that 
what I intend to do is so fundamentally different from any existing genealogy 
projects that it really is best for me to start my own, though mine would be 
open source and it can still glean things from other projects.

For one thing, my project is more abstract and extensible, and actually is more 
of an ontology tool than a genealogy tool, but that it would handle genealogy 
particularly well.  For another thing, my project focuses on presenting chains 
of claims, he-said-she-said, with each link being fully described, and not 
simply a bibliography, and this relating to how much stock one can put in the 
claims associated with the sources.

In any event, as I said this project is temporarily shelved while I work on my 
SQL replacement first.  In fact, if one were to look at my (ostensibly 
completely specified) relational Muldis D language and how its design could be 
used by DBMS access tools or ORMs as a front for SQL databases today, and see 
how my approach differs from every other SQL tool/ORM out there, which are 
relatively a lot more self-similar, this might give a hint as to how thoroughly 
I may present a different tool for genealogy than those existing now; I'm no 
more constrained by GEDCOM than by SQL.

> 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.

Yes, each person using the database would be a source themselves, or a proxy for 
one, and can talk about their own first hand experience.  This isn't like an 
encyclopedia where information not first written down elsewhere is disallowed.

> 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

If you want to see an ostensibly objective example of how PostgreSQL is better 
than MySQL, and has been for a long time, just look at the release notes or 
change logs for both projects.  PostgreSQL is much more stable and free of bugs, 
and its change logs dominantly deal in new features or performance enhancements, 
and its bug fixes tend towards the relatively minor, though there are some 
significant ones periodically.  MySQL in contrast dominantly deals with fixing 
bugs, many of them serious, which would indicate that MySQL has a lot more bugs 
in it to begin with.  The release notes or change logs reflect how each 
project's own developers see them, never mind other people.

MySQL has been known, for example in its version 5.1, to declare itself 
"generally available"/"production" quality despite having over a hundred serious 
bugs in it.  In contrast, PostgreSQL would consider such to be "alpha" or maybe 
"beta" quality.

But even ignoring the change logs, the designs of the two DBMSs reflect 
different philosophies, where Postgres considers things like data integrity and 
consistent behavior to be highly important while MySQL is much more likely to 
consider something to much lower standards as "good enough".  MySQL didn't and 
still doesn't support transactions product-wide.  Nor, I think, foreign key 
constraints.  MySQL silently truncates inserted data that is too long for a 
field, saying things are okay even though it just lost some data, rather than 
raising an error citing 'input too long'.  I have first-hand experience with 
that.  MySQL considers the string 'foo ' to be = to 'foo', which it clearly 
isn't.  Postgres nor any proper relational DBMS does these things.  And there 
are many other citable things.  MySQL databases are much more likely to become 
corrupted.

I liken MySQL to Microsoft Windows, which people use dominantly because it has a 
greater number of existing installations or they have for the same reason 
already used it and only it before.  While people having solid experience with 
both MySQL and PostgreSQL, and prefer MySQL exist, I would think those MySQL 
users are a minority compared to those for whom MySQL is the only thing they 
know, because it was pre-installed.  As with MS Windows, while some people who 
have solid experience with other major OSs would like Windows more, I'd think a 
majority of Windows users are those who don't like it more, and just use it 
because it is either all they know or a program they need requires it.

If both MySQL and PostgreSQL were pre-installed on the same number of hosts, and 
the same number of people were solidly experienced with both, I would think that 
more people would choose PostgreSQL by default for their next project.

People who are savvy with databases and know both PostgreSQL and MySQL would 
prefer PostgreSQL for quality and features hands-down.  And if their host 
doesn't provide PostgreSQL, they would demand they provide it, or install it 
themselves, or find another host, or that particular data is unimportant.

-- Darren Duncan