The name GEDCOM2 implies that it will be a superset or evolution of the existing format. However, due to the lack of standard semantics, the original is not a sound base to build onto. For that reason, I suggest a new name that doesn't have those implications.

Bob McConnell
N2SPP

Stephen Woodbridge wrote:
Hi Ron,

This all sounds very interesting and while I would like better support for media, one of my concerns comes from the fact the GEDCOM describes a format but not a semantic of how tags should be implemented regarding content. As a result, it is very hard to merge GEDCOM data from different products that output data to GEDCOM and stuff info in different but potentially legitimate TAGs.

So, I see this project as creating kind of a "super" GEDCOM like database, but if the result is that I have to look in more places to find a given piece of information than I already have to look in, then this does not solve one of the BIGGEST problems of GEDCOM files in my mind.

Anyway, it will be interesting to see how this develops.

-Steve

On 8/4/2011 1:49 AM, Ron Savage wrote:
Hi Folks

I've been thinking about how to develop our software libraries, and I'm
thinking of formally requesting Gedcom2 as the parent namespace.

The aim is to support genealogical data first, with the old Gedcom being
the most likely way data would be imported into the new db(s).

Hence the requirements of g. data support will drive the design, and the
Gedcom spec will not, although it does have a lot to offer.

Then, Gedcom2 would become the module name and the id to reference any
work in this field, and Gedcom2::Gedcom::* would be for modules
importing or exporting data in the original Gedcom format. To make
things clear, I'll try to always refer to the Perl Gedcom as Gedcom.pm.

Also, I have a plan to collect the tags used by the major Open Source
and free programs. I've downloaded:
o Gedcom
o Gramps
o Webtrees
after getting their names from Wikipedia at
http://en.wikipedia.org/wiki/Genealogy_software

My idea is to put these tags into an SQLite db, with an indicator of
which programs support which tags. Then they can be displayed, in HTML
say, with the tags (and explanations) down the left, and program names
across, so the intersection could be green (background) perhaps to
indicate support. This does not show if the support is just import or
just output. Nevertheless, I feel this could be a useful start to
Gedcom2.

Of course, the tag db will be on CPAN under Gedcom2, so anyone can play
with it.

I do realize some programs, e.g. Gedcom.pm, don't add tags (at least I
don't think it does) over and above Gedcom, they just manipulate what's
provided in the data.

As I said, I'll do the above-mentioned, and the HTML display part, to
get started.

So, if you'd like to volunteer to attack a program I haven't mentioned -
to extract it's tag list - just co-ordinate with others via this list.

Ideally, the code will be incorporated into the Gedcom2 namespace, e.g.
as Gedcom2::Gedcom::Import::Tags::Gramps, or some such, so it can be
easily re-run against future releases of that other software. Standalone
scripts, and the file from the other software which is the input file,
would suffice at the start, and we can get more organized later.

What do people think of all this?

Lastly, I'm also thinking of developing a TiddlyWiki
http://tiddlywiki.org/ to record any info, e.g. suggestions for new
tags. I'll start off with some ideas from recent posts to this list.

I would make it publicly accessible, too, perhaps in the Gedcom2 distro.
I'm a great believer in TiddlyWikis...

However I could also use http://tiddlyspot.com/ to have an on-line wiki,
although then passwords are sent in the clear.

Or does anyone have a suggestion about simple but password-protected
wikis? And yes, I know there a whole set of them on CPAN. None have yet
appealed to me.

Reply via email to