Ron Savage wrote:
Hi John
On Wed, 2011-07-27 at 08:47 +0100, John Dobson wrote:
Hi,
Let me first admit to not being a webtrees expert, although I am going
to use it. Webtrees is a 'fork' in open source terms from the popular
PhpGedView. It initially populates the custom database from data in one
or more GEDCOM files which remain in the file store but aren't referred
to again in operation after the initial loading use. The idea is that
the database is updated online by those collaborating in the project
and, subject to configuration; any user can export a GEDCOM for their
own use at any time.
OK.
Multi-media is more problematic when it comes to portability, the GEDCOM
FILE statement contains just a file pointer to a multimedia item, not
the item itself. It's unlikely that this location would stay the same
through a migration to webtrees so the program optionally strips off the
leading part of the path and replaces it with a media directory
constant. It's the left to the user to migrate media items manually.
Yes, external files add a lot of complexity to processing.
Let's pretend our non-existent new spec is called Gedcom+ (to save
typing).
So, in Gedcom+ I'm thinking it'd have a config file, and 1 item therein
would be a media directory name, so all file references in the Gedcom+
file would be relative to the local user's value for that dir name.
Then come the problem of file type, codecs, etc.
I guess we need to d/l a few open source genealogy program and see what
they do. That's why I examined the source of Webtrees.
I think you are working this problem from the wrong end. Rather than
look at file/database content, you should first be defining what your
application is going to do. What information (reports) do you want to be
able to extract from the data you collect? What relationships do you
need to track within your family trees? How will that data be
documented? Do scans of the source documents become part of the data?
After you have the purpose and scope defined, then you can decide how to
build the database to support those activities.
Basically, you need to determine what you want to create before you can
decide how to build it. Think of it as working with an architect to draw
up plans for a house before you hire the contractor to build it.
I believe that GEDCOM is the minimalist approach to transferring and
exchanging genealogy data. So while it may be an easy means to populate
some parts of a database, it is less likely to be useful within the
application itself. It may not even be useful as a backup format if it
does not support all of the data you need to collect as well as the meta
data that gives it structure. It certainly won't support any of the meta
data (table definitions and static content) necessary for a full scale
application.
Bob McConnell
N2SPP
