On 14 Nov 2007 in soc.genealogy.computing, Nigel Bufton wrote: > How could it be possible to record the marriage data of two INDIs > without a FAM record? Even if your proposed FAM-less model > included a SPOU tag for each INDI and the marriage information was > held in subtags to the SPOU tag, there would be huge data integrity > issues because each INDI/SPOU tag of a partnership would need to > maintain subtags recording identically duplicated information. Instead of maintaining separate SPOU tags for each individual, you can maintain one 'relationship' record for two individuals involved in a marriage-like relationship, much as the GEDCOM FAM record does. You can then attach to it any added information you want - start date, end date, location(s); even what to call the relationship - marriage, bidie-in, POSSLQ, ... The problem with the GEDCOM FAM record is that it also records the children. You should be able to derive that information from the child's parent links. -- Joe Makowiec http://makowiec.org/ Email: http://makowiec.org/contact/?Joe

You can create your own family trees and timeslines. I created a baby book complete with a timeline. The sign up is free as well! I found it at this site: http://our-story-1.blogspot.com

Bob Velke <bvelke@whollygenes.com> wrote: > Tom said: > > >GEDCOM is a perfectly good standard. It may be old, but the kilogram > >is an old standard and enjoys widespread modern use. > > For a lot of researchers, GEDCOM is far from "perfectly" anything. It misses few things so that the gedcom is a starting point for a serious standard. In other things, the fact that only 4 or 5 softwares respect it! > It's age is not the direct cause of its many weaknesses -- but the > length of time since a revision (and the lack of any prospect for > any) is a negative indicator for those of us who are affected. What good is it since the programs do not respect it ! It is not an update which would change that! -- Téhenne Saint-Denis de la Réunion Logiciel de généalogie ohmiGene (Mac & PC): http://www.nauze.com/ Comparatif Import-Export Gedcom : http://www.nauze.com/gedcom/ Digest du format Gedcom : http://www.nauze.com/format_gedcom/index.html

Denis Beauregard wrote: > Hi: > > I think what is wrong with GEDCOM as a standard is not the GEDCOM > itself. Its structure is quite easy to understand and it is easy > to write a software that will both understand it and generate it. > > I would say the problem, as Bob said, is when the standard is > applied. Any software maker has his/her opinion about that, but > also, and this is more important, very few softwares can indeed > support all the features in GEDCOM and many may have more features. [SNIP] This kind of things has always plagued the software industry, alas. ANSI or ISO or W3C publishes a standard for some document format or language specification, and before you know it, there are half a dozen implementations from different vendors who all add "enhancements" that are incompatible with the standard and with one another. Look at the way Fortran developed after the 1966 and 1977 ANSI standards, for example. Big companies such as Digital Equipment Corporation released compilers which allowed all manner of non-standard extensions, which made portability a huge headache. More recently, Microsoft has gained a dubious reputation for its "embrace and extend" tactic. Ask any web designer about the "standard" for JavaScript in web browsers, and watch them roll their eyes and groan. I work in bioinformatics, using and writing software to analyse, store and interchange biological information about DNA. There are half a dozen different "standard" ways to store some kinds of data, and a lot of software is pretty lax about obeying the standard when writing data files. Like Andrew Tanenbaum said, the great thing about standards is that there are so many to choose from :-) David Harper Cambridge, England

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

"Steve Hayes" <hayesmstw@hotmail.com> wrote in message news:0cokj396vvrkqut358fa7hrr4853ta9lma@4ax.com... > On Tue, 13 Nov 2007 20:39:27 +0000, Ian Goddard <goddai01@hotmail.co.uk> > wrote: > <snip> > 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. > <snip> GEDCOM does not "group people into families" - the FAM records record events, notes, sources, media, etc., regarding the family (which means any combination of people containing one partner - usually plus a spouse and/or children). There are no individual detail data stored within the FAM record except that which pertains to the individual's status within the specific family (e.g., HUSB, WIFE, CHIL) How could it be possible to record the marriage data of two INDIs without a FAM record? Even if your proposed FAM-less model included a SPOU tag for each INDI and the marriage information was held in subtags to the SPOU tag, there would be huge data integrity issues because each INDI/SPOU tag of a partnership would need to maintain subtags recording identically duplicated information. The way to avoid data integrity issues is to store the data once and point to it, rather than maintain multiple identical copies. The FAM record provides precisely this. (As do the SOUR, REPO, OBJE, NOTE, etc., records.) >From my experience of working with GEDCOM files from various sources, the shortcomings are more a result of the weaknesses of genealogy program creators in applying the standard correctly than a result of a weakness of the standard . Nigel www.tcgr.bufton.org

Charlie said: >It's apparently not *all* that difficult to write software that will >read one programs data, and convert it to what another program >expects... Well, it ain't easy <g> but it would be easier if developers commonly published their own file specifications (as we do). But most refuse to do so for reasons that you might imagine. It is the same reason that most developers decline invitations to be involved in the many efforts that there have been to develop a GEDCOM alternative. Those developers simply have no perceived incentive to help people leave their program. It is not a market-driven thing because, sadly, the vast majority of researchers are oblivious to the problems and have the same opinion of GEDCOM as does Tom who started this thread. It is almost impossible to recognize data loss and corruption from the receiving end. >Maybe if you packaged Genbridge as a separate product, and made it >capable of writing out data files.... Then we wouldn't even need >GEDCOM any more. It is available to developers as a standalone module (FTM 2008 uses it, among others) but it cannot _write_ proprietary data files because that would be a copyright violation. 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.31/1129 - Release Date: 11/13/2007 9:22 PM

Denis said: >Any software maker has his/her opinion about that, but >also, and this is more important, very few softwares can indeed >support all the features in GEDCOM and many may have more features. That's true but I don't know about "more important." A GEDCOM transfer actually involves two transfers, of course: into GEDCOM and out of it. Most of the specific examples I gave of problems occur during the first one. If the data is lost or corrupted during that step, then it doesn't really matter what program is on the other end. It could even be the _same_ program. That's why it is a silly notion to evaluate a program based on how well it does a "round trip test" through GEDCOM. In fact, the common use of that yardstick in the last decade was precisely why some developers felt pressured to design their own transfer spec and call it "GEDCOM." They do remarkably well on the "round trip test" ... while populating the world with .GED files that no other program can reliably read. Thankfully, one less-frequently sees software reviews which use that yardstick nowadays. But the sentiment (that you should always be able to perfectly transfer all of your data to another user of the same software through GEDCOM) is unfortunately still very common among users. 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.31/1129 - Release Date: 11/13/2007 9:22 PM

Hi: I think what is wrong with GEDCOM as a standard is not the GEDCOM itself. Its structure is quite easy to understand and it is easy to write a software that will both understand it and generate it. I would say the problem, as Bob said, is when the standard is applied. Any software maker has his/her opinion about that, but also, and this is more important, very few softwares can indeed support all the features in GEDCOM and many may have more features. If my software can support only one marriage record per couple, or two (with the marriage contract), then it will never import a GEDCOM file where a couple was married many times (as a protestant, then as a catholic, then revalidation of the catholic wedding, then a civil ceremony, then a Jew ceremony because they changed their religion, then then then, your imagination knows what). We don't need a new standard, per se, but to define what softwares should do when they ignore any feature because of internal structure limitation. Denis -- 0 Denis Beauregard - /\/ Les Français d'Amérique du Nord - www.francogene.com/genealogie--quebec/ |\ French in North America before 1722 - www.francogene.com/quebec--genealogy/ / | Maintenant sur cédérom, début à 1770 (Version 2008) oo oo Now on CD-ROM, beginnings to 1770 (2008 Release)

On Wed, 14 Nov 2007 12:55:03 -0500, Bob Velke <bvelke@whollygenes.com> wrote: >Téhenne said: > >>What good is it since the programs do not respect it ! >> >>It is not an update which would change that! > >It isn't as simple as that. > >All serious genealogy programs claim to >import/export GEDCOM and many don't adhere to my >interpretation of the specs. But some of those >developers claim that my programs don't adhere to >their interpretation of the specs. The fact that >it is open to so many varied interpretations is >one of its biggest weaknesses (e.g., the meaning >of the FAMily structure, assumed marriage of >parents, the sequence of undated children, >precedence of names, handling of word-wrapping, >unity of literally-identical sources, and on and on...). > >It is true that a few developers unapologetically >manipulate the specs in a way which _cannot_ be >defended as a difference in >interpretation. While I think those cases are >the minority, those developers would say that >they've taken liberties out of a necessity to >provide structured support for data types which >are not directly addressed by GEDCOM (e.g, >ambiguous parentage, shared non-spousal events, >witnesses, research tasks, and on and on...). > >Some of us choose to not transfer those types of >data with GEDCOM and others will manipulate it to >fit GEDCOM's very-limited data model. But both >of those are forms of data corruption, in my >opinion. When added to all the problems of >interpretation, the "it's better than nothing" >argument becomes" it is better to corrupt it than >to not transfer it" ... and that is at _least_ debatable. > >The cheerleading for GEDCOM on the grounds that >there's nothing else (even if that were true), >reminds me of when my kids complain when I won't >drive them to the mall. They say, "How are we >supposed to get there?" and I answer, "Who says >that you're supposed to get there?" > >Over the years, there have been many revisions to >GEDCOM which clarified some ambiguities, repaired >some internal inconsistencies, and expanded its >data model to account for some data types which >its developers hadn't considered. That is, those >revisions DID help to solidify the >"standard." But it is still woefully >insufficient on almost every scale - except among >those researchers whose world view of >genealogical data is limited to what PAF >supports. In the their defense, that was GEDCOM >developers' intended market and our application >of it for a larger purpose was wishful >thinking. It shouldn't surprise us that our >current complaints with it will never be addressed. > >Bob Velke >Wholly Genes, Inc. It's apparently not *all* that difficult to write software that will read one programs data, and convert it to what another program expects... Gary Bonham did it with GEDCOM Explorer, you did it with Genbridge, and Bruce has done it in a limited manner with RootsMagic (imports FTM files). It's a shame Gary passed away.... it would really be nice if someone else picked up where he left off and made a program to convert GEDCOM files, or better yet, to convert one program's native data files to that of another. Maybe if you packaged Genbridge as a separate product, and made it capable of writing out data files.... Then we wouldn't even need GEDCOM any more. -- Charlie Hoffpauir http://freepages.genealogy.rootsweb.com/~charlieh/

Téhenne said: >What good is it since the programs do not respect it ! > >It is not an update which would change that! It isn't as simple as that. All serious genealogy programs claim to import/export GEDCOM and many don't adhere to my interpretation of the specs. But some of those developers claim that my programs don't adhere to their interpretation of the specs. The fact that it is open to so many varied interpretations is one of its biggest weaknesses (e.g., the meaning of the FAMily structure, assumed marriage of parents, the sequence of undated children, precedence of names, handling of word-wrapping, unity of literally-identical sources, and on and on...). It is true that a few developers unapologetically manipulate the specs in a way which _cannot_ be defended as a difference in interpretation. While I think those cases are the minority, those developers would say that they've taken liberties out of a necessity to provide structured support for data types which are not directly addressed by GEDCOM (e.g, ambiguous parentage, shared non-spousal events, witnesses, research tasks, and on and on...). Some of us choose to not transfer those types of data with GEDCOM and others will manipulate it to fit GEDCOM's very-limited data model. But both of those are forms of data corruption, in my opinion. When added to all the problems of interpretation, the "it's better than nothing" argument becomes" it is better to corrupt it than to not transfer it" ... and that is at _least_ debatable. The cheerleading for GEDCOM on the grounds that there's nothing else (even if that were true), reminds me of when my kids complain when I won't drive them to the mall. They say, "How are we supposed to get there?" and I answer, "Who says that you're supposed to get there?" Over the years, there have been many revisions to GEDCOM which clarified some ambiguities, repaired some internal inconsistencies, and expanded its data model to account for some data types which its developers hadn't considered. That is, those revisions DID help to solidify the "standard." But it is still woefully insufficient on almost every scale - except among those researchers whose world view of genealogical data is limited to what PAF supports. In the their defense, that was GEDCOM developers' intended market and our application of it for a larger purpose was wishful thinking. It shouldn't surprise us that our current complaints with it will never be addressed. 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.31/1129 - Release Date: 11/13/2007 9:22 PM

Steve Hayes wrote: > On Tue, 13 Nov 2007 20:39:27 +0000, Ian Goddard <goddai01@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

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.

On Tue, 13 Nov 2007 20:39:27 +0000, Ian Goddard <goddai01@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. -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

Thanks a lot! I'll try them! Marek

Bob Velke wrote: > Tom said: > >> GEDCOM is a perfectly good standard. It may be old, but the kilogram >> is an old standard and enjoys widespread modern use. > > For a lot of researchers, GEDCOM is far from "perfectly" anything. And, alas, the kilogram is not what it was, either. Literally. The BBC recently reported that lump of platinum which defines the international standard kilogram is shrinking: http://news.bbc.co.uk/1/hi/sci/tech/7084099.stm David Harper Cambridge, England

TomAlciere wrote: > GEDCOM is a perfectly good standard. It may be old, but the kilogram > is an old standard and enjoys widespread modern use. > > Export your (deceased only) data into a GEDCOM 5.5 file, convert your > transcription project to a home-made GEDCOM file, and post these on > your own website or any website offering free space. > > These can be compiled together. I have a site, GedcomIndex.com where > millions of GEDCOM file entries are listed by town. > > Note the importance, however, of entering the place name correctly, > not putting notes in the place fields. > > Basically, I have run out of downloadable GEDCOM files, while there's > a ton of material out there on HTML pages and spreadsheets of various > formats. We could all find our connecting-line researchers if we would > all post GEDCOM files. > > Tom Alciere > Hudson, New Hampshire, USA > The underlying data model of GEDCOM is very simple. IMV far too simple. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

Genbox www.genbox.com does this nicely and you can drag the boxes around the chart if you want to tweak the final result before printing. -----Original Message----- Date: Mon, 12 Nov 2007 20:15:30 -0800 From: MJ <admire@wp.pl> Subject: 1 Tree with all people from a database To: gencmp@rootsweb.com Message-ID: <1194927330.076731.139330@o80g2000hse.googlegroups.com> Content-Type: text/plain; charset="iso-8859-2" I've found the post from 2 months ago(http://groups.google.pl/group/ soc.genealogy.computing/browse_thread/thread/98c4563a508d9bf9?hl=pl#) but I think it doesn't solve my problem. I've been looking for a genealogy software which lets making automatically all-in-one tree including all people not related directly with me.I would like to include all people - not only my cousins and close relatives but for example all the familly of my grandfather and his second wife (after death of my grandmother), parents of my brother's wife, etc... Is there any soft which makes that possible? Thanks for any comments! Marek

Tom said: >GEDCOM is a perfectly good standard. It may be old, but the kilogram >is an old standard and enjoys widespread modern use. For a lot of researchers, GEDCOM is far from "perfectly" anything. It's age is not the direct cause of its many weaknesses -- but the length of time since a revision (and the lack of any prospect for any) is a negative indicator for those of us who are affected. 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.30/1127 - Release Date: 11/12/2007 9:19 PM

MJ wrote: > I've found the post from 2 months ago(http://groups.google.pl/group/ > soc.genealogy.computing/browse_thread/thread/98c4563a508d9bf9?hl=pl#) > but I think it doesn't solve my problem. > > I've been looking for a genealogy software which lets making > automatically all-in-one tree including all people not related > directly with me.I would like to include all people - not only my > cousins and close relatives but for example all the familly of my > grandfather and his second wife (after death of my grandmother), > parents of my brother's wife, etc... > > Is there any soft which makes that possible? > Thanks for any comments! > Marek > FTM 16 is the latest useable version (NB wait until FTM 2008 has been finished) Hugh W -- For genealogy and help with family and local history in Bristol and district http://groups.yahoo.com/group/Brycgstow/ http://snaps4.blogspot.com/ photographs and walks GENEALOGE http://hughw36.blogspot.com/ MAIN BLOG