I agree about the data model coming first Ian. However, it seems there's no absolute consensus on what such the data model should encompass. Every time the GEDCOM issue comes up, it seems some very experienced people make excellent critiques of the GEDCOM model, and enumerate all sorts of events, relationships, data-types, etc., that should be included in any new model or format. If this were a new computer language that was to be defined then some authoritative body (possibly a recognised standards body) would put out an RFI (Request for Information) to the public before creating a specification or data model. Although there are several genealogical bodies around, I'm not aware of any that have taken this initiative, or feel any need to. If they did then would the people/companies with software interests respect their authority anyway? I would argue (and have done elsewhere in this thread) that defining a better data model would eventually catch up with the popular software products - and make them better products. There is no such product that currently does everything. Most are great for home use, but less so for the serious genealogical researcher. Once such a data model had been ratified then the door would be open to producing an upgraded GEDCOM (or possibly an entirely new, more modern interchange format), and an open spec for an OOP object model designed around the data model, and eventually new enhanced versions of the popular products. In effect, I guess I'm saying that software designers can't be expect to know all the ins-and-outs of serious genealogical research, and vice versa. This would have to be a collaboration Tony Proctor "Ian Goddard" <goddai01@hotmail.co.uk> wrote in message news:Rdydndl4NcSiq6banZ2dnUVZ8qaqnZ2d@pipex.net... > Rich256 wrote: > > On Nov 14, 3:35 am, Ian Goddard <godda...@hotmail.co.uk> wrote: > >> Steve Hayes wrote: > >>> On Tue, 13 Nov 2007 20:39:27 +0000, Ian Goddard <godda...@hotmail.co.uk> > >>> wrote: > >>>> The underlying data model of GEDCOM is very simple. IMV far too simple. > >>> Or far too complex. > >>> GEDCOM tries to group people into families, which is an unnecessary > >>> complication. > >>> The basic relations are father-child and mother-child, and if GEDCOM stuck to > >>> that it could simplify things. > >> Same difference! The *evidence* provides names of people (often > >> inconsistently spelled even on the same document. A data model should > >> provide an entity to represent data (names and roles) extracted from the > >> evidence; this is *analysis*. A simple data model which stops there > >> would be what you seek and I could go along with that. > >> > >> If we then try to group into families we build hypotheses which identify > >> one analysis record with another. This is *interpretation*. A data > >> model which makes provision for interpretation should provide a separate > >> entity for this - and make the link between the analysis and > >> interpretation representations of individuals a further entity. This is > >> the sort of model I would prefer. > >> > >> GEDCOM does neither. It provides a single entity to represent > >> analytical and interpretive views of individuals. It tries to achieve > >> complex ends by simple means. > >> > >> -- > >> Ian > >> > >> Hotmail is for spammers. Real mail address is igoddard > >> at nildram co uk > > > > > > If anyone can come up with a better standard please feel free to do > > so. However to accomodate the peculiarities of every program is a > > difficult if not impossible task. First of all perhaps all programs > > would have to adhere to a standard defining what data is acceptable. > > > As I've said before, the first thing is to get the data model right. > > Data model comes first, programs and interchange standards come later. > If you have a good data model and a program that follows it then you can > produce a good interchange standard. > > If you wanted to import into a program which only supported GEDCOM you > would be able to do that. You would be able to convert down to GEDCOM > level if need be but this would involve throwing data away. Does the > concept of throwing data away alarm you? It should. > > -- > Ian > > Hotmail is for spammers. Real mail address is igoddard > at nildram co uk

Tony Proctor said: >Although there are several genealogical bodies around, I'm not aware of any >that have taken this initiative [to design a data model], or feel >any need to. The "Genealogical Data Model" (GDM) was started by GENTECH, now a division of the National Genealogical Society, in _1996_ (http://www.ngsgenealogy.org/ngsgentech/projects/Gdm/Gdm.cfm). The project was sponsored by the National Genealogical Society (NGS), Federation of Genealogical Societies (FGS), New England Historic Genealogical Societies (NEHGS), American Society of Genealogists (ASG), Association of Professional Genealogists (APG), and the Board for Certification of Genealogists (BCG). I submit that you'll find nothing closer to an authoritative body within the genealogical community. >If they did then would the people/companies with software interests >respect their authority anyway? The design committee included professional genealogists, software developers, and data modelers. I was a member of that committee as was a representative of the LDS Church. Several of other developers of the most popular genealogy software programs were invited to participate. None accepted. They were invited to attend planning meetings. None accepted. Upon release of the first draft of the GDM in 1998, their peer review was solicited. To my knowledge, none was provided by them. Upon release of v1.1 in 2000, their peer review was solicited again -- and again, none was provided. The "GDM" remains by far the most comprehensive and authoritative effort that has every been made to model genealogical data -- and I'd wager that few of the major genealogy software vendors have ever _looked_ at it. As I said before, I believe that the reason is that they perceive it to be against their interest to do so. Ten years of so-called "market forces" seems to have validated their strategy to ignore the problem. Bob Velke Wholly Genes, Inc. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.32/1131 - Release Date: 11/14/2007 4:54 PM