Denis Beauregard wrote: ... > The gain is because there are more and more tools to read XML > files and to handle this kind of data, event if it is not the > same as you use in genealogy. > > For example, a family is a set of persons where 2 persons have > a special role (dad and mom), and the other persons a more > general role (kids). You can say a car is a of pieces, or an > army regiment is a set of persons, etc. Then you can define > database operations like putting someone in the right box by > dragging that person, i.e. drag John to the dad's box or to the > captain's box, or drag the name of the cathedral to the relevant > box, etc. So, in theory, you could achieve many predefined > operations with the same code and getting some universal > genealogy software that will process the persons, but also the > events, the places, the groups (army, state employees, churchmen, > town elected, trades), the sources, etc. Then you get some kind > of very powerful genealogy system. > ... > > Denis > But that's not specific to XML? Peter
Everett M. Greene wrote: > Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > >>There is no semantic difference between >> >>0 FAM >>1 HUSB >>1 WIFE >>1 MARR >>2 DATE >> >>and >> >><fam> >> <husb> </husb> >> <wife> </wife> >> <marr> >> <date> </date> >> </marr> >></fam> >> >>or >> >><tribe> >> <head> </head> >> <staff> </staff> >> <union> >> <jour> </jour> >> </union> >></tribe> > > > Not having looked at the XML-based proposals, I'm not familiar > with what's being proposed, but if the preceding is a valid > example, I don't see any significant benefit. As you say, > there's not semantic difference and clutter is being added for > no obvious reason. simply said both xml and gedcomn are text files with diffeent forms of mark up language Hugh W -- a wonderful artist in Denmark http://www.ingerlisekristoffersen.dk/ Beta blogger http://snaps4.blogspot.com/ photographs and walks old blogger GENEALOGE http://hughw36.blogspot.com/ MAIN BLOG
the_verminator@comcast.net wrote: > I'd even go so far as to say that the GEDCOM has done more to hurt > online genealogy than it has to help it as it allows the almost But then again -- GEDCOM outdates on-line genealogy as we know it today, and was NEVER intended to carry more than a basic Name-date-place and the necessary links to produce a family group sheet. Sourcing wasn't part of its mandate. People kept hanging tinsel on it and wondering why it doesn't fly. > instantanous transmission of unsourced genealogical garbage and does > too little to encourage sound genealogical research (i.e. mandatory > entry of standard sources and citations). But then again -- not all genealogical valid sources can be called "standard". Cheryl
On Wed, 18 Jul 2007 18:19:54 +0100, Peter J Seymour <moz@pjsey.demon.co.uk> wrote in soc.genealogy.computing: >Denis Beauregard wrote: >... >> The gain is because there are more and more tools to read XML >> files and to handle this kind of data, event if it is not the >> same as you use in genealogy. >> >> For example, a family is a set of persons where 2 persons have >> a special role (dad and mom), and the other persons a more >> general role (kids). You can say a car is a of pieces, or an >> army regiment is a set of persons, etc. Then you can define >> database operations like putting someone in the right box by >> dragging that person, i.e. drag John to the dad's box or to the >> captain's box, or drag the name of the cathedral to the relevant >> box, etc. So, in theory, you could achieve many predefined >> operations with the same code and getting some universal >> genealogy software that will process the persons, but also the >> events, the places, the groups (army, state employees, churchmen, >> town elected, trades), the sources, etc. Then you get some kind >> of very powerful genealogy system. >> >... >> >> Denis >> >But that's not specific to XML? What is specific to XML is the development of tools to handle this kind of structures. GEDCOM can be developed by genealogists only. XML can be developed by any programmer, so more development is expected. Denis
Robert Melson wrote: > In article <iuvq93105be5ochbsi73dh7u0rforplirg@4ax.com>, > Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: >> On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert >> Melson) wrote in soc.genealogy.computing: >> >>>As I understand it, though, XML permits you to add/delete >>>entities locally while still preserving the "universal" >>>entities defined elsewhere. If that's true, then you >>>should be able to add a "hippie marriage" entity in your >>>local DTD that would satisfy your requirements. >> >> From a structural point of view, where is the difference >> with GEDCOM ? >> >> >> Denis >> > > I'm not sure I can answer that question. Anything I think I > know about XML comes from the O'Reilly "XML in a Nutshell" > and is rusty as hell. (Hmmm, now I think of it, though, both > V5.X and V6 are GEDCOM - the realization is different from one > to the other, though.) > > I think the major difference between 5 and 6, however, is not in > the representation but in the entities included and how they're > defined. I haven't really looked at the BNF definitions of > the GED language, so I can't really tell you specifically how > the two versions differ. > > The advantage of XML, though, as I understand it, is that there can > be a centrally defined stylesheet which can be imported into the I think you mean DTD or schema. That's what specifies the data format. DTD is pretty well moribund. Schemas are more powerfull. Stylesheets are what you'd use to specify the transformations between, say a standard version and a vendor-specific version. > local environment and modified locally without affecting the base > stylesheet. You could even, if I remember correctly, have multiple > stylesheets - the base, a vendor version, an o/s specific version, > one for your company and your personal version. In terms of the Apart from the terminology this is correct. I did a number of projects for a client who provided personalised print services where their clients would specify the XML they were sending to be processed. I used stylesheets to transform the various client schemas into into a common in-house schema so that I could handle them all with a common application code-base. > GED standard, you might have the central "standard" maintained at > and by the LDS, a FTM version maintained by the vendor, and a > local version you maintain yourself to fix problems you see in > the other two. > > If there's anybody here who understands this, I'd love to see/hear > what you have to say about the GED V.6 beta standard and what it > will mean for us mere hackers. > > Bob Melson > I took a quick look at the proposed new standard a few weeks ago. As I recall it had actually dropped some components of the original. This would make it far less able to deal with some of the issues raised in a long-running thread in s.g.methods earlier this year. XML has several advantages. Firstly its notions of well-formedness and validaty ensure that a corrupt file or the product of a program generating off-spec XML is easily picked up. Secondly the use of XSLT allows transformation into XML of a different schema, HTML or text formats, possibly even existing non-XML Gedcom. Thirdly there are well-established libraries in all major languages for parsing XML so there's no reason why any application developer should have to roll their own and get it wrong. I doubt it's a passing fad. It's the language I wish I'd had available donkey's years ago for exchanging data. But that's what it is - a language for data exchange. And the issues being raised here are essentially about the data model behind Gedcom. In order to produce a worthwhile replacement one would really have to produce a new data model which is accepted as better than that in use. As far as I can see one weakness of existing data models is that there is a direct link between entities. In another post in this thread I gave an example of how handling of uncertainties could be a property of an improved system but as far as I can see this would be impossible to implement with direct links - one would need additional link entities/classes/tables. The development process would, then be: 1. Data model. 2. Data exchange specification (XML or otherwise). 3. Implementation. -- Ian Goddard Hotmail is for the benefit of spammers. The email address that I actually read is igoddard and that's at nildram dot co dot uk
On Jul 17, 11:39 am, mels...@aragorn.rgmhome.net (Robert Melson) wrote: > In article <1184689853.767732.28...@x35g2000prf.googlegroups.com>, > "the_vermina...@comcast.net" <the_vermina...@comcast.net> writes: > > > > > > > On Jul 17, 12:34 am, Lars Eighner <use...@larseighner.com> wrote: > >> Here is the problem: GEDCOM has become the de facto standard for family > >> history and geneology data. And the problem with that is that the Mormons > >> own GEDCOM and thus it is rife with built-in religious limitations. > > >> As you might expect, GEDCOM does not allow you to enter a family created by > >> same-sex marriage or civil unions even where they are lawful. But there are > >> other limitations. For example, in GEDCOM 5.xx, an adopted child does not > >> belong to his family. When he looks up his family in a GEDCOM-compliant > >> file, he is not there. How needlessly hurtful is that? > > >> If a guy marries his 14-year-old cousin as his fifth wife, GEDCOM has no > >> problem dealing with that kind of family. But it cannot handle the Brady > >> Bunch. > > >> Now I suppose you could defend GEDCOM by saying it is supposed to record > >> only genetic --- that is, biological --- relationships. And of course, > >> there are important scientific and especially medical uses for that kind of > >> information. But it is not really true that GEDCOM records biological > >> relationships. It presumes that the husband of a woman who bears a child is > >> the father of the child, and we know since there is now DNA testing that > >> assumption is untrue in a significant portion of cases. > > >> Which brings me to my point. I'd like to develop a family history system > >> that is as compatible with GEDCOM as possible (since it is, as I have said, > >> the de facto standard with tons of software applications), but with > >> extensions to handle many diverse kinds of families that exist both in > >> modern America and in many traditional cultures. > > >> So, I would be grateful for any pointers to existing software that handles > >> all families or suggestions for extensions. > > >> -- > >> Lars Eighner <http://larseighner.com/> <http://myspace.com/larseighner> > >> Countdown: 553 days to go. > >> Owing to massive spam from googlegroups, I do not see most posts from there. > > > Check out The Master Genealogist. > > > As an aside you should note that any program that depends on GEDCOM > > for anything other basic BMD info will have serious shortcomings > > depending on how the exporting and importing software follow the > > GEDCOM "standard" - which, imho, should be scrapped in its entirety. > > Out of curiosity, what would you suggest replace the gedcom > "standard"? Is the problem so much with the standard or with > the programs that implement it? As Micro$oft and Oracle have > amply proved, a standard exists as a standard only so long as > the players consider themselves bound by it; once the standard > is breached it becomes meaningless. > > Bob Melson > > -- > Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas > ----- > "People unfit for freedom---who cannot do much with it---are > hungry for power." ---Eric Hoffer- Hide quoted text - > > - Show quoted text - I suggest a narrative text file. That is what I give others to whom I provide information. Thus, I am free to give exactly the information I want to give complete with cautions and warnings about sources, citations, etc. If I'm provided with a gedcom I'll import it to a database and then print out an individual report on each person to see what exactly I want to enter into my main program. A second benefit is that unless someone wants to do a LOT of typing I'm unlikely to see my work spread over the internet willy-nilly without crediting me as the source of the information. I'll gladly provide info on individuals but balk at providing whole lines to name collectors. I'd even go so far as to say that the GEDCOM has done more to hurt online genealogy than it has to help it as it allows the almost instantanous transmission of unsourced genealogical garbage and does too little to encourage sound genealogical research (i.e. mandatory entry of standard sources and citations).
On Wed, 18 Jul 2007 07:45:07 PST, mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote in soc.genealogy.computing: >Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: >> There is no semantic difference between >> >> 0 FAM >> 1 HUSB >> 1 WIFE >> 1 MARR >> 2 DATE >> >> and >> >> <fam> >> <husb> </husb> >> <wife> </wife> >> <marr> >> <date> </date> >> </marr> >> </fam> >> >> or >> >> <tribe> >> <head> </head> >> <staff> </staff> >> <union> >> <jour> </jour> >> </union> >> </tribe> > >Not having looked at the XML-based proposals, I'm not familiar >with what's being proposed, but if the preceding is a valid >example, I don't see any significant benefit. As you say, >there's not semantic difference and clutter is being added for >no obvious reason. While not exactly the same, XML and HTML are somewhat similar. You can look at any HTML page to get an idea about what XML looks like. Keep in mind the exact syntax is different. The gain is because there are more and more tools to read XML files and to handle this kind of data, event if it is not the same as you use in genealogy. For example, a family is a set of persons where 2 persons have a special role (dad and mom), and the other persons a more general role (kids). You can say a car is a of pieces, or an army regiment is a set of persons, etc. Then you can define database operations like putting someone in the right box by dragging that person, i.e. drag John to the dad's box or to the captain's box, or drag the name of the cathedral to the relevant box, etc. So, in theory, you could achieve many predefined operations with the same code and getting some universal genealogy software that will process the persons, but also the events, the places, the groups (army, state employees, churchmen, town elected, trades), the sources, etc. Then you get some kind of very powerful genealogy system. The drawback is if it is too easy, you will get 1000 standards because everybody will create his/her own universal genealogy package. Another drawback is the freedom you get will cut you from getting back to any lineage-oriented databases i.e. from almost any existing genealogy software. Denis
Robert Melson wrote: > In article <iuvq93105be5ochbsi73dh7u0rforplirg@4ax.com>, > Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > >>On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert >>Melson) wrote in soc.genealogy.computing: >> ... > > The advantage of XML, though, as I understand it, is that there can > be a centrally defined stylesheet which can be imported into the > local environment and modified locally without affecting the base > stylesheet. You could even, if I remember correctly, have multiple > stylesheets - the base, a vendor version, an o/s specific version, > one for your company and your personal version. In terms of the > GED standard, you might have the central "standard" maintained at > and by the LDS, a FTM version maintained by the vendor, and a > local version you maintain yourself to fix problems you see in > the other two. > ... > > Bob Melson > There might be something in this is if there were several versions on a straight line dependency, but once you have a tree of dependecies (as you inevitably would) you're stuck. Also if you encountered a data field that isn't defined in the definitions you have because it's defined elsewhere, you also also stuck. The problem with local versions is that they probably won't be known in all the places they need to be known. Basically XML doesnt help. Regards Peter
Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > There is no semantic difference between > > 0 FAM > 1 HUSB > 1 WIFE > 1 MARR > 2 DATE > > and > > <fam> > <husb> </husb> > <wife> </wife> > <marr> > <date> </date> > </marr> > </fam> > > or > > <tribe> > <head> </head> > <staff> </staff> > <union> > <jour> </jour> > </union> > </tribe> Not having looked at the XML-based proposals, I'm not familiar with what's being proposed, but if the preceding is a valid example, I don't see any significant benefit. As you say, there's not semantic difference and clutter is being added for no obvious reason.
In article <po5r9351dijbfha6jo0vafdfskfg4ck59e@4ax.com>, Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > On Wed, 18 Jul 2007 03:55:19 GMT, melsonr@aragorn.rgmhome.net (Robert > Melson) wrote in soc.genealogy.computing: > >>In article <iuvq93105be5ochbsi73dh7u0rforplirg@4ax.com>, >> Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: >>> On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert >>> Melson) wrote in soc.genealogy.computing: >>> >>>>As I understand it, though, XML permits you to add/delete >>>>entities locally while still preserving the "universal" >>>>entities defined elsewhere. If that's true, then you >>>>should be able to add a "hippie marriage" entity in your >>>>local DTD that would satisfy your requirements. >>> >>> From a structural point of view, where is the difference >>> with GEDCOM ? >>> >>I'm not sure I can answer that question. Anything I think I >>know about XML comes from the O'Reilly "XML in a Nutshell" >>and is rusty as hell. (Hmmm, now I think of it, though, both >>V5.X and V6 are GEDCOM - the realization is different from one >>to the other, though.) > > But there is no structural big difference. I mean how you see it is > different (the syntax is different), but it is like more or less > comparing 2 languages. French and English are different, but there is > nothing you can say in one of them and not in the other. A proof is > that I think in French while I write this message in English. > > There is no semantic difference between > > 0 FAM > 1 HUSB > 1 WIFE > 1 MARR > 2 DATE > > and > > <fam> > <husb> </husb> > <wife> </wife> > <marr> > <date> </date> > </marr> > </fam> > > or > > <tribe> > <head> </head> > <staff> </staff> > <union> > <jour> </jour> > </union> > </tribe> > >>I think the major difference between 5 and 6, however, is not in >>the representation but in the entities included and how they're >>defined. I haven't really looked at the BNF definitions of >>the GED language, so I can't really tell you specifically how >>the two versions differ. >> >>The advantage of XML, though, as I understand it, is that there can >>be a centrally defined stylesheet which can be imported into the >>local environment and modified locally without affecting the base >>stylesheet. You could even, if I remember correctly, have multiple >>stylesheets - the base, a vendor version, an o/s specific version, >>one for your company and your personal version. In terms of the >>GED standard, you might have the central "standard" maintained at >>and by the LDS, a FTM version maintained by the vendor, and a >>local version you maintain yourself to fix problems you see in >>the other two. > > And what will that change ? The major problem in a standard to > exchange data is what will you do with the data your own database > doesn't know. Using a GEDCOM style structure or an XML style > structure is irrelevant. XML is more fashion, more 2007, while > GEDCOM is more 1980s or 1990s, but none of them will tell you by > itself what to do with the data your database can't process. > > IMO, GEDCOM 6 failed (it never made it) because it is not addressing > this major problem but is only cosmetical. > >>If there's anybody here who understands this, I'd love to see/hear >>what you have to say about the GED V.6 beta standard and what it >>will mean for us mere hackers. >> >>Bob Melson > > > Denis > In terms of the "language", the BNF specification is definitive. I haven't looked closely at that, so can't say what may have changed or in what way. I agree that "rendering" in language in XML seems to offer little advantage. But, if I'm not way off base, XML is a web-based system, meaning that, properly managed, changes to the core definitions will be transparent to all systems using the XML rendition. The same would be true if, say, FTM or TMG maintained and published their vendor-specific XML supplements to the core standard, at least insofar as users of those programs are concerned. The potential advantage I see in XML is that those supplements - or links to them - can be exported with your data, making the data more widely understood/usable. But I come back to a question I asked earlier. If there's so much dissatisfaction with GEDCOM v5.X and the LDS Church, why has there not been a movement to create or evolve a new standard on the part of the various vendors or genealogy organizations? For that matter, why hasn't a group of advanced, techie genealogy hobbyists gotten together to propose a new definition? If you use the open source software "movement" as an example, what's to prevent a bunch of amateurs donating their time to creating a new data exchange standard for genealogical data and the software to present it? Understand, please, I'm NOT a Mormon and am not defending them on the basis of religion. I do wonder, though, why, amid all the pissing and moaning about the crappy gedcom standard, there isn't some sort of concerted effort to changee it for the better. Bob Melson readable -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- "People unfit for freedom---who cannot do much with it---are hungry for power." ---Eric Hoffer
In article <iuvq93105be5ochbsi73dh7u0rforplirg@4ax.com>, Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert > Melson) wrote in soc.genealogy.computing: > >>As I understand it, though, XML permits you to add/delete >>entities locally while still preserving the "universal" >>entities defined elsewhere. If that's true, then you >>should be able to add a "hippie marriage" entity in your >>local DTD that would satisfy your requirements. > > From a structural point of view, where is the difference > with GEDCOM ? > > > Denis > I'm not sure I can answer that question. Anything I think I know about XML comes from the O'Reilly "XML in a Nutshell" and is rusty as hell. (Hmmm, now I think of it, though, both V5.X and V6 are GEDCOM - the realization is different from one to the other, though.) I think the major difference between 5 and 6, however, is not in the representation but in the entities included and how they're defined. I haven't really looked at the BNF definitions of the GED language, so I can't really tell you specifically how the two versions differ. The advantage of XML, though, as I understand it, is that there can be a centrally defined stylesheet which can be imported into the local environment and modified locally without affecting the base stylesheet. You could even, if I remember correctly, have multiple stylesheets - the base, a vendor version, an o/s specific version, one for your company and your personal version. In terms of the GED standard, you might have the central "standard" maintained at and by the LDS, a FTM version maintained by the vendor, and a local version you maintain yourself to fix problems you see in the other two. If there's anybody here who understands this, I'd love to see/hear what you have to say about the GED V.6 beta standard and what it will mean for us mere hackers. Bob Melson -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- "People unfit for freedom---who cannot do much with it---are hungry for power." ---Eric Hoffer
In article <9Kdni.12915$LH5.785@trnddc02>, Wes Groleau <groleau+news@freeshell.org> writes: > Robert Melson wrote: >> After all the early drum-pounding and huzzahs, it seems the >> proposed gedcom 6 standard, based on xml, has died aborning. > > I will admit to not having read every single word of that > standard, but my impression was that it solved nothing. > From as much as I did read, it seemed to me that there was > as much _practical_ difference between 5.5 and 6.0 as there > is between English and "pig latin" > As I understand it, though, XML permits you to add/delete entities locally while still preserving the "universal" entities defined elsewhere. If that's true, then you should be able to add a "hippie marriage" entity in your local DTD that would satisfy your requirements. I'm not Mormon, so in that respect I don't have a dog in this fight. The Mormons are the ONLY group I know of that has stepped forward with a broadly useful data exchange standard for genealogical data. If that standard is so deficient, as many seem to think, then maybe it's time to pound on the software vendors to come up with a better standard for data exchange and get the LDS out of the picture as the standard setter. However, unless that new standard takes into account the needs of that very large body of "genealogists" represented by the LDS, it's going to fall flat on its ass. Bob Melson -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- "People unfit for freedom---who cannot do much with it---are hungry for power." ---Eric Hoffer
Robert Melson wrote: > After all the early drum-pounding and huzzahs, it seems the > proposed gedcom 6 standard, based on xml, has died aborning. I will admit to not having read every single word of that standard, but my impression was that it solved nothing. From as much as I did read, it seemed to me that there was as much _practical_ difference between 5.5 and 6.0 as there is between English and "pig latin" -- Wes Groleau Expert, n.: Someone who comes from out of town and shows slides.
Robert Melson wrote: > Out of curiosity, what would you suggest replace the gedcom I thought he was asking for us to suggest what should. > "standard"? Is the problem so much with the standard or with > the programs that implement it? Both. But GEDCOM itself is not nearly as limited as most of the implementations of it. (Ironically, the worst I've come across comes from the same source as GEDCOM--PAF) I take it back--the worst I've seen came from a program that desperately took on the futile challenge not only of comprehending PAF's approach to SOURces, but tried to output SOURces PAF could understand WHILE adding to them stuff to make it's job easier on re-import. -- Wes Groleau Is it an on-line compliment to call someone a Net Wit ?
Lars Eighner wrote: > Here is the problem: GEDCOM has become the de facto standard for family > history and geneology data. And the problem with that is that the Mormons > own GEDCOM and thus it is rife with built-in religious limitations. I too have lamented the notion that there are only two kinds of relationships: marriage and child of a marriage. Finally, the LDS realized that was a flaw and introduced "associations" And then there's the 6.0 XML version--while introducing a completely new lexical/syntactic structure, they had the opportunity to correct the semantic inddequacies of the previous model. Instead, they carefully ensured there was no practical difference and that the conversion old format to new and vice versa is almost as trivial as print to Morse code. Is there any software out there that used the "event-linked" GEDCOM model? I'd like to see a "relationship-linked" model: Keep everything currently in GEDCOM 5.5.1 but add a series of tags representing numerous relationships. 0 @person1@ INDI .... 1 FATH @person2@ 1 MOTH @person3@ 1 SIBL @person4@ 1 WIFE @person5@ 2 MARR @event1@ And why this devout slavery to the four-character abbreviation? They already have FAM, AFN, CHR, & SEX so they know there's no magic in the number four. In PLAC, BIRT, DEAT, what does saving a single letter buy us other than making things just a smidgen more difficult for people who aren't English? > So, I would be grateful for any pointers to existing software that handles > all families or suggestions for extensions. A "FAM" should be a list of people who lived together, with their roles, the time period it existed, and the events that are significant to it: 0 FAM @family1@ 1 HUSB @person2@ {{ John /Doe/ }} 1 FATH @person2@ 2 NOTE FATH & HUSB could be interchangeable, 3 CONT or they could be different people-- 3 CONC and there could be more than one 3 CONT (hippie commune of the sixties?) 1 MARR 2 DATE ..... 2 HUSB @person2@ 2 WIFE @person3@ 1 MARR 2 DATE .... 2 HUSB @person2@ 2 WIFE @person9@ 2 NOTE Why not? Polygamy has existed. Plus, 3 CONT this would make it much easier to link 3 CONT a man to two wives without making half- 3 CONC brothers who lived together most of their 3 CONT lives into strangers as far as the file 3 CONT can show. Finally, when you find that 3 CONT last scrap that makes these two women 3 CONT the same person, how much easier is it 3 CONT to merge them within this FAM instead 3 CONT of merging two level zero FAMs ? No doubt other people have put a lot more thought into it than I have, and can find plenty of flaws in my idea. But you asked for ideas, and this is one that has been on my back burner for years. Also, a "comment" syntax would be nice--my {{ John /Doe }} above. Comments are like in programming, in a way--they are information to the human reader that the software does not use. However, they _could_ be more. Software could generate them, and/or use them for an integrity check if they are done with some consistent style. I have some perl code that loads a GEDCOM into a Berkeley DB, easily brings one level zero record out at a time unchanged from how it went in. During output, it scans for Xrefs, retrieves information on the record pointed to, and creates it as a comment in the form above. This helps me as I edit the GEDCOM. After editing, the software strips off the comments before replacing the record in the database. Could do more with it, if I had taken the time to code it. -- Wes Groleau There ain't no right wing, there ain't no left wing. There's only you and me and we just disagree. (apologies to Jim Krueger)
Robert Melson wrote: > > Out of curiosity, what would you suggest replace the gedcom > "standard"? Is the problem so much with the standard or with > the programs that implement it? As Micro$oft and Oracle have > amply proved, a standard exists as a standard only so long as > the players consider themselves bound by it; once the standard > is breached it becomes meaningless. > > Bob Melson > > Well, for a start I'd want it to be based on XML. That would mean that the standard could be extended as required. An example of such extension would be the ability to deal with modern surnames, various patronymic systems and the various styles of epithet which evolved into surnames. I'd also want it to handle the records of individuals separate from their genealogical roles. To illustrate, Kirkburton parish records show two John Goddards born in 1753. The father of one of them was William Goddard. There were two William Goddards, one of whom was the brother of Jonathan the father of the other John Goddard of 1753, My ggg-grandfather was a John Goddard born in 1753. I thus have two candidates for ggg-grandfather, 3 for gggg-grandfather and 2 for ggggg-grandfather. Any system which conflates the two entities, the genealogical role and the historical individual recorded in the registers is powerless to record this situation properly. -- Ian Goddard Hotmail is for the benefit of spammers. The email address that I actually read is igoddard and that's at nildram dot co dot uk
On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert Melson) wrote in soc.genealogy.computing: >As I understand it, though, XML permits you to add/delete >entities locally while still preserving the "universal" >entities defined elsewhere. If that's true, then you >should be able to add a "hippie marriage" entity in your >local DTD that would satisfy your requirements. >From a structural point of view, where is the difference with GEDCOM ? Denis -- 0 Denis Beauregard - /\/ Les Français d'Amérique du Nord - www.francogene.com/genealogie--quebec/ |\ French in North America before 1721 - www.francogene.com/quebec--genealogy/ / | Maintenant sur cédérom, début à 1765 oo oo Now on CD-ROM, beginnings to 1765
Wes Groleau wrote: > And why this devout slavery to the four-character abbreviation? Most likely they were following the fashion for personal computer metadata formats at the time the standard was formalized. A number of (mostly binary) formats developed in the mid-80s use 4-character tags. A surviving example is RIFF, the metadata format used to store Windows AVIs. The idea was that you can treat 4 (or fewer) ASCII characters as a single 32-bit integer, making lookups and comparisons substantially faster and simpler than they would be for tags of arbitrary length. This actually mattered on early PCs, which were thousands of times slower than they are now. - Ernie http://home.comcast.net/~erniew
In article <slrnf9pttu.fnh.usenet@goodwill.larseighner.com>, Lars Eighner <usenet@larseighner.com> writes: > In our last episode, <2h6ni.9164$zA4.5373@newsread3.news.pas.earthlink.net>, > the lovely and talented Robert Melson broadcast on soc.genealogy.misc: > >> Out of curiosity, what would you suggest replace the gedcom >> "standard"? Is the problem so much with the standard or with >> the programs that implement it? As Micro$oft and Oracle have >> amply proved, a standard exists as a standard only so long as >> the players consider themselves bound by it; once the standard >> is breached it becomes meaningless. > > Well, at this point, thanks to a suggestion on another group, > I am looking at gramps. Since it is open source, it seems to me possible > that I can devise a commandline interface to it. > If I'm not totally mistaken, though, the gramps xml scheme is built on gedcom 5.5, which would seem counter to what you propose. As well, I believe there already IS a command-line interface to gramps. After all the early drum-pounding and huzzahs, it seems the proposed gedcom 6 standard, based on xml, has died aborning. The concept, however, is something you might want to look into. If you can't track down a copy of the draft standard, let me know, I think I may still have a copy stashed, together with some DTDs to go with it. Bob Melson -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- "People unfit for freedom---who cannot do much with it---are hungry for power." ---Eric Hoffer
In our last episode, <2h6ni.9164$zA4.5373@newsread3.news.pas.earthlink.net>, the lovely and talented Robert Melson broadcast on soc.genealogy.misc: > Out of curiosity, what would you suggest replace the gedcom > "standard"? Is the problem so much with the standard or with > the programs that implement it? As Micro$oft and Oracle have > amply proved, a standard exists as a standard only so long as > the players consider themselves bound by it; once the standard > is breached it becomes meaningless. Well, at this point, thanks to a suggestion on another group, I am looking at gramps. Since it is open source, it seems to me possible that I can devise a commandline interface to it. -- Lars Eighner <http://larseighner.com/> <http://myspace.com/larseighner> Countdown: 552 days to go. Owing to massive spam from googlegroups, I do not see most posts from there.