What GEDCOM spec really is, and is not ?
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
I'm somewhat amazed at the way so many Gen programs stick to the obviously flawed "GEDCOM specs". Even in phpGEDview, which flags itself as a REVOLUTIONARY new Gen program !!!
First question. Why choose the 5.5.1 spec? Why not the 6.0 spec, which, on the face of it, looks a lot more logical, catering for PLACE and other such items as actual database items. Or is that TOO revolutionary ?
But more importantly, why stick to the GEDCOM specs at all for the way the program handles data internally ? Because the GEDCOM specs only were ever intended as a standard for transferring data.
If it makes real sense to store the data in a better way, (properly handling information on relationships between database items, census records, shared/common information etc) then why not do it ? And then only do the necessary manipulation to meet with the GEDCOM standard on transfer, in or out. With perhaps one process to export to GEDCOM 5.5.1, another to transfer to GEDCOM 6.0 etc. And the same on the input side. With parameter driven options on how to treat certain "translations".
Letting a transfer spec drive the way the program works internally reminds me of the old monolithic batch banking systems, not something revolutionary.
By not separating the operation of the program from the way it handles transferring batch files, by tieing itself to what is already an out of date, flawed, and basically despised standard, the program is guaranteed to become obsolete, not continually growing. Is that what REVOLUTIONARY and OPEN SOURCE is about ? Perhaps this sticking to a flawed design is one reason why the project has too few developers ?
(This has been prompted by recent responses in discussions on Event, and Sourcing)
Yes, GEDCOM 5.5.1 is not a modern standard, but it is a standard that nearly each program supports for data exchange.
GEDCOM 6.0 is a DRAFT paper since 2002 (7 years now) and is not futher driven by its maintainer. I do not know any program that supports it. Yes, it's modern, it's XML, but it doesn't helps me a lot if nobody else is supporting it.
It has a lot of advantages to deal directly with gedcom peaces, because you are more flexible to import the different variations of gedcom from other programs. It has also disadvantages, like performance, we have seen in this project.
So yes, I would also like GEDCOM 6 to be a standard, but it doesn't helps me, if I have noone I can exchange with.
The REVOLUTIONARY concept in phpGedview is not the datahandling, but the opportunity to work together on the same family data via internet.
Why I am interested in PGV is precisely because of that collaboration possibility. Genealogy has to be one of the topics most in need of collaboration and a common data set.
But my view is that to some extent collaboration is made much more difficult when the data set is inappropriately designed, when locations, sources, FACTS and EVENTS are going to be entered multiple times, and inevitably multiple ways, in the present structure.
But I take f-a-b's point that PGV started as a viewer, and am pleased to see he has a view to moving it towards being independent of the gedcom standard as far as internal data structure is concerned.
I'll think about trying to get involved somehow to help.
Meanwhile, thanks to the developers for what we have so far.
<<Why choose the 5.5.1 spec?>>
We don't. We haven't. This fact keeps getting lost, so I'll say it again. PGV does not follow/implement/adhere-to *any* version of *any* gedcom specification.
It happens to contain a standalone utility that will check a gedcom file against a defined grammar, and the utility contains only one grammar definition (for 5.5.1). I had originally intended to add other grammar definitions, but never had time/interest.
Here's a little background - the gedcheck.php utility was written for one purpose, and one purpose only. I wrote it to teach myself PHP, and learn a little about PGV. That's right. It's one step up from "hello world". It's only in PGV because lots of people asked me to put it there.
<<But more importantly, why stick to the GEDCOM specs at all for the way the program handles data internally ? Because the GEDCOM specs only were ever intended as a standard for transferring data.>>
The clue is in the name. PhpGedView started as a program for viewing Gedcom files. For many years, it did not even have a database. Just the gedcom files and some indexes into it.
But you are right, and I agree with you.
However, the application contains *lots* of features, modules, etc., that are depenedent on the current structure. Making any changes to the underlying data model means rewriting almost everything.
Now, we don't have the resources for a complete rewrite, so we are left with making small/incremental changes.
This doesn't mean I'm not trying. I'm currently working on a whole series of database changes that will change the internal focus from "gedcom records" (level 0 data) to "gedcom facts" (level 1 data).
I'm also made a few steps towards separating "internal data-storage format" and "external data-transfer format". If you care to look at the code, you'll see that the data in database isn't quite the same as the data in the files. I intend to build on this in the future.
I've also put a lot of effort into refactoring the code to separate data from application-logic. This is an ongoing effort.
<<By not separating the operation of the program from the way it handles transferring batch files, by tieing itself to what is already an out of date, flawed, and basically despised standard, the program is guaranteed to become obsolete, not continually growing.>>
This is just one of many criticisms of PGV's design/structure/implementation. See the forum archives for more......
If a better application/project comes along, I will be the first to jump ship.
But until then, I think PGV is far from its death-bed.
GEDCOM 6.0 is not a modern standard either, not where it counts.
It is an XML variant of GEDCOM five. The real flaws are not in the lexical/syntax level but the data model. GEDCOM 6 is the same data model as GEDCOM 5. Conversion from one to the other is trivial.
GEDCOM is flawed, but its data model is the only thing with wide acceptance. And (personally) the things that bother me the most about many genealogical programs are things they refuse to do that CAN be done with GEDCOM.
"REVOLUTIONARY concept in phpGedview is not the datahandling, but the opportunity to work together on the same family data via internet."
another is "relationship privacy."
Support via UTF-8 encoding of dozens of non-Latin scripts, while not exactly revolutionary, is not a common thing in genealogy.
The lack of those three items in other programs was the reason I started writing my own--which I was glad to abandon when I discovered PGV.
"when locations, sources, FACTS and EVENTS are going to be entered multiple times, and inevitably multiple ways"
Is it feasible to have a variant of autocomplete in the split place form, where when you enter one level, the next level's autocomplete searches only the known place parts that are within the upper level?
That might help reduce misspellings--or at least make them the same misspelling :-)