Forum Moderators: open
This could be stored in the database as a table of VCARDS and a table of relationships (vcard1, vcard2, XFN relationship). Sound feasible?
then of course I've just got to work out how to display it in a page. Nested lists and styling (i.e. tree structure) sound like the right way forwards?
I think we can agree that HTML in itself is not sufficient as a tool for managing the data. XML appears ideal, and you should look into RDF too.
I found this university paper which gives a good run-down of how genealogists have been tacking the problem:
There's a good list of resources here:
I have briefly tried the GRAMPS project in the past:
[gramps-project.org...]
However I don't believe it runs on Windows.
I haven't really read them in depth so far, but I installed PHPGedview this year to store and view our own growing database. It has the advantage, IMHO anyway, of storing the information in an SQL database so you could pull it out an present it how you like, and as well it produces a GedCOM file should you need to share the file or want to use it's format. The GedCOM format is very much like XML and could likely be extended, and transformed (XSLT) in the same way. I can understand why it's still the preferred standard. I haven't been interested in making my own data into a site as yet, though straight out of the box PHPGedView produces a usable enough website without knowing the code.
The main thing that surprised me (as I don't have that much data yet) was the scalability that any format would need to have. I wasn't too far back in my own research before oddities such as unwed parents, illegitimate children, 2nd marriages etc, began to cause a problem in the 1:1 (reversible) methodology of relationships. At first glance I think XFN would be too simple for this.
The hCard format might work, my original data is on cards and I don't think it's impossible to see how they might transfer to web, however notes and sources (e.g. census record) could apply to more than one person so a seperate storage system for them (relational database) would be needed so the hCard would just need a "sources" field and even multiple sources, in fact each field would need the ability to sustain a one to many relationship - even name fields as mispellings are common.
very interesting question, Robin, would be interested to hear what you come up with. The Portal I use displays the data in (pretty) tables, which I think is perfectly OK for this type of site as it is in effect tabular data?
There are a number of programs out there specifically designed to manage this data, some free, some very reasonably priced. About a year ago I went through the process of testing a good deal of them and ended up with [legacyfamilytree.com...] One bonus that most of them have is the ability to export the tree as HTML, albeit in rather a simplified formatting.
Then you get into the area of collaboration when other family members decide to pitch in and help. Again I looked at online versions using databases and scripting, and ended up deciding on [phpgedview.net...] which uses php and either of three databases, or even flat files. phpgedview is a global collaborative project that also has input from a university via programming assignments for students. Oh, and it's free. :)
There are also plenty of lists out there for researching Genealogy Programs.
Onya
Woz
NB., Obligatory Disclaimer - I have no affiliation with any of the above other than pleasant and productive usage.