> Dunno, don't care. I don't think in the GEDCOM box.
> Ian Goddard
Fair enough. But a lot of vendors do. Well, that's arguable. The more I look at GEDCOM, the more I'm tempted to say a lot of genie programmers don't think in the GEDCOM box. Ironically, PAF is the worst I've seen. No, I take that back. The worst I've seen was caused by trying to be compatible with PAF.
-- Wes Groleau
Even if you do learn to speak correct English, whom are you going to speak it to? -- Clarence Darrow
> I tried importing a file of geo references. The approach adopted in > building the file seemed to have been to chop off a few significant > figures from the reference. Seems reasonable - you can't specify > the position of a village to the nearest yard. Wrong. Lopping off > those extra figures moved the reference right off centre at best, > well over to the next village at worst.
> Ian Goddard
What they should have done is _round_, not truncate.
Unless you actually want it to be in the center, in which case you DO specify to the nearest, oh, say twenty yards. About one thousandth of a degree. That's about the accuracy limit of the GPS in my iPhone.
>> > Having any of that in a sentence that starts out, "Carl was born at >> > 7:05 am EDT on Sunday 1 August, in Gregory Hines School district >> > (city tax district) Pepco D-15, WSSC67-E, WGL AH-45, Fox Haven >> > subdivision, South Dry Prong, Shilong Dist, Dusty County, Wherebego, >> > United States ..." seems like TMI, not to say overkill. Why toss in >> > that Gregory Hines used to be Bill Bailey Section, the tax district >> > used to be rural then was settled, and then urban, and is now city, >> > or that Fox Have subdivision used to be Old MacDonald Farm, which >> > was part of the Bladen Tract ...
> But including those bits of information which will guide someone to > where the relevant vital records may be found may save someone a > good deal of grief; maybe they're not inclined to accept your > version of events until they've checked for themselves.
> Ian Goddard
Well, maybe. But if I use a tax record as a source, I will cite the tax record, and include a repository record, rather than telling someone he lived in that tax district and making them guess whether and where there was a record.
> Wes, I tried your political link and got an error message that it > does not exist. What up?
> SHARON Zingery
The author might consider it educational rather than political. :-) It appears that either my ISP or eternal-septmeber.org has gotten stupid and is changing headers without changing the encoding to match.
=E2 is how a particular encoding method (which I do NOT use) sends out the byte which is in hex E2 (11100010) (and similar for the others).
UTF-8, which I _do_ use, represents an opening quotation mark as E2 80 9C and a closing as E2 80 9C. The correct link is
If the servers/relays screw it up again, note that the same encoding method uses =3D for an equal sign.
If still stuck and you REALLY want to read Richard's article, go to http://Ideas.Lang-Learn.us/russell and put the words Obama and Latin in the search form.
> > unified, and RSA for South Africa (by the way, the abbreviation USA > > was never used for the Union of South Africa -- it was always "the > > Union", which later became "the Republic" in 1961).
> > Steve Hayes
> But USA for Union of South Africa is a misinterpretation that I > would not be surprised to find someone making. So I can understand > if someone wants to disallow USA in files they accept. But I used > USA because I misinterpreted software manual to mean that Chapman > codes were required.
Similarly the abbreviations Ca and CA can be confused. I suppose that's why Chapman used CAN for the latter.
Chapman also used RSA for South Africa, which is the one that is used locally, though many people use SA. That, however can be confused with South Australia, and WA causes similar confusion.
I use USA in my genealogy programs, because United States of America is much longer to type. Leaving it off leads to ambiguity - Georgia could mean either the US state or the Caucasian republic.
>>> I don't know how you could handle this in other applications but >>> Gramps has a Place entity type. A Place has a name, Long& >>> Lat refs and ID and a Location plus zero or more Alternate >>> Locations. A Location is essentially [snip].
>>> Ian Goddard
>> Can you describe what GRAMPS does with all of that when outputting >> GEDCOM ?
>> Wes Groleau
> Dunno, don't care. I don't think in the GEDCOM box.
> Ian Goddard wrote:
Ian, you sure are the grump.
What GEDCOM does with information contained in a genealogy program data depends on whether GEDCOM recognizes the data. Given the age of the GEDCOM protocol I doubt that the L&L refs or the Alternate Location References would be picked up in a GEDCOM export. If they are not picked up then they are just ignored.
Other than the Birth, Christening, Marriage, Divorce, (and I am not sure GEDCOM can handle a Divorce) Death and Burial information with Name Location Date and Source I do not think that any other information can be handled by GEDCOM.
TMG has many features like Name Variations, Witnesses to Tags etc. which AFAIK are ignored in a GEDCOM export.
> What GEDCOM does with information contained in a genealogy program > data depends on whether GEDCOM recognizes the data. Given the age > of the GEDCOM protocol I doubt that the L&L refs or the Alternate > Location References would be picked up in a GEDCOM export. If they > are not picked up then they are just ignored.
> bob gillis
Bob, GEDCOM doesn't do anything with data except hold it. GEDCOM is a way of formatting the data. And it does have a way to hold Latitude/Longitude, divorces, emigrations, immigrations, graduations, residences, and lots of other things.
bob gillis wrote: >>>> I don't know how you could handle this in other applications but >>>> Gramps has a Place entity type. A Place has a name, Long& >>>> Lat refs and ID and a Location plus zero or more Alternate >>>> Locations. A Location is essentially [snip].
>>>> Ian Goddard >>> Can you describe what GRAMPS does with all of that when outputting >>> GEDCOM ?
>>> Wes Groleau >> Dunno, don't care. I don't think in the GEDCOM box.
>> Ian Goddard
> Ian, you sure are the grump.
I spent half of my working life as a scientist which develops the habit of treating evidence fully. The other half was spent in IT, both as a developer & as a DBA. The one set of experiences tells me when systems aren't able to do what the other set tells me should be done.
> What GEDCOM does with information contained in a genealogy program > data depends on whether GEDCOM recognizes the data. Given the age > of the GEDCOM protocol
That may be part of the problem but the real problem AFAIA is that Gedcom was designed to meet the needs of the Mormon church which are not exactly the same as those of family historians. Only the intersect of those two sets of needs is filled as far as the family historian is concerned. This poses a dilemma for the S/W developer: a package which is dominated by what standard Gedcom allows is restricted whilst a package which ignores the restrictions is unable to export all its data without private extensions which may be meaningless to other programs.
> I doubt that the L&L refs or the Alternate > Location References would be picked up in a GEDCOM export. If they > are not picked up then they are just ignored.
FWIW here's an example of what gets exported by Gramps:
1 BIRT 2 TYPE Birth of Goddard, Francis 2 DATE BEF 25 JUN 1760 2 PLAC Larks House, Hepworth 3 MAP 4 LATI N53.558552 4 LONG W1.74641 2 ADDR 3 CITY Hepworth 3 CTRY England
It omits the county (WRY) and church parish (Kirkburton). And by no stretch of the imagination ca Hepworth be described as a city.
> Other than the Birth, Christening, Marriage, Divorce, (and I am not > sure GEDCOM can handle a Divorce) Death and Burial information with > Name Location Date and Source I do not think that any other > information can be handled by GEDCOM.
> TMG has many features like Name Variations, Witnesses to Tags etc. > which AFAIK are ignored in a GEDCOM export.
As I said above.
-- Ian
The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk
Ian Goddard wrote: > That may be part of the problem but the real problem AFAIA is that > Gedcom was designed to meet the needs of the Mormon church which are > not exactly the same as those of family historians. Only the > intersect of those two sets of needs is filled as far as the family > historian is concerned. This poses a dilemma for the S/W developer: > a package which is dominated by what standard Gedcom allows is > restricted whilst a package which ignores the restrictions is unable > to export all its data without private extensions which may be > meaningless to other programs.
GEDCOM has some serious flaws, but it's biggest disadvantage is the plethora of programs that offer features GEDCOM _does_ support, yet refuse to be bound to any "standard."
Examples: (1) there's a program that does 1 NAME Jane /Doe/ 2 _MARNM Jane /Roe/
when the "standard" already defined 1 NAME Jane /Doe/ 1 NAME Jane /Roe/ 2 TYPE married
(2) the "standard" allows you to have a source for an event:
1 BIRT 2 DATE whatever 2 SOUR @source-ref@
yet at least one program prefers to say
1 NOTE ! birth-source yadda yadda
The '1 NOTE' "by the book" says this is a NOTE (not a source) for the entire individual's record. The rest of the line says, "Yeah, but we don't like the GEDCOM spec, so it's really a source for the birth subrecord."
(ironically, a program from the group that invented GEDCOM)
(3) GRAMPS
> FWIW here's an example of what gets exported by Gramps:
> 1 BIRT > 2 TYPE Birth of Goddard, Francis
What's the point of this? We knew it was a birth from the line above. And if you know the name, you should be putting it in a 1 NAME Francis /Goddard/
> 2 DATE BEF 25 JUN 1760 > 2 PLAC Larks House, Hepworth > 3 MAP > 4 LATI N53.558552 > 4 LONG W1.74641 > 2 ADDR > 3 CITY Hepworth > 3 CTRY England
> It omits the county (WRY) and church parish (Kirkburton). And by no > stretch of the imagination ca Hepworth be described as a city.
If Hepworth is not a city, why is GRAMPS saying it is? And if GRAMPS omits the county, which the GEDCOM spec both allows and recommends, why?
-- Wes Groleau
Change is inevitable. We need to learn that "inevitable" is neither a synonym for "good" nor for "bad." -- WWG
> On 8/6/2010 4:45 PM, Wes Groleau quoted: >>> How you enter a location should not depend on the genealogy program >>> being used.
>>> bob gillis
> I did not write the above either in a message with this subject or > any other message to GENMTD in 2010. I have just search the list > archives.
Somebody or something, with or without your approval, put the above on Usenet and included headers of
From: bob gillis <robertgil...@verizon.net> Newsgroups: soc.genealogy.methods Subject: Re: proper entry of locations when names change Date: Wed, 4 Aug 2010 11:48:54 -0700 (PDT)
>> If you choose to use a genealogy program, you enter it in a way the >> program allows or you don't enter it.
> That is a stupid statement.
No, it is a response to a not-well-thought-through statement that somebody forged your name on.
If the program demands that you enter the house number, then the planet, then the name of the next door neighbor, you have four choices:
1. Enter it the way they say 2. Find a more sensible program 3. Don't enter the location 4. Complain on Usenet that how you enter a location should not depend on the genealogy program
-- Wes Groleau
Change is inevitable. We need to learn that "inevitable" is neither a synonym for "good" nor for "bad." -- WWG
If anyone used a genealogy program that forces them to enter a location in a particular format then would be very foolish. No format rules could possibly cover all locations.
>> What GEDCOM does with information contained in a genealogy program >> data depends on whether GEDCOM recognizes the data. Given the age >> of the GEDCOM protocol
> That may be part of the problem but the real problem AFAIA is that > Gedcom was designed to meet the needs of the Mormon church which are > not exactly the same as those of family historians. Only the > intersect of those two sets of needs is filled as far as the family > historian is concerned. This poses a dilemma for the S/W developer: > a package which is dominated by what standard Gedcom allows is > restricted whilst a package which ignores the restrictions is unable > to export all its data without private extensions which may be > meaningless to other programs.
But Program A having private extensions which are NOT universally accepted by Programs B thru ZZ is what allows the developers of Program A to /copyright/ their intellectual property and regain their expenses of developing it. Two copies of Program A should and generally do import correct all content of a GED from one another.
>> I doubt that the L&L refs or the Alternate >> Location References would be picked up in a GEDCOM export. If they >> are not picked up then they are just ignored.
> FWIW here's an example of what gets exported by Gramps:
> 1 BIRT > 2 TYPE Birth of Goddard, Francis > 2 DATE BEF 25 JUN 1760 > 2 PLAC Larks House, Hepworth > 3 MAP > 4 LATI N53.558552 > 4 LONG W1.74641 > 2 ADDR > 3 CITY Hepworth > 3 CTRY England
> It omits the county (WRY) and church parish (Kirkburton). And by no > stretch of the imagination ca Hepworth be described as a city.
You ought to know that it would bloat the code beyond belief if each and every variation of "the entity generally referred to as City" were offered up ... village, town, hamlet, wide-spot, City, Metropolis, Marketing Area (NOT to be confused with Market town). OTOH, I do agree that if you entered WRY it ought to have exported.
>> Other than the Birth, Christening, Marriage, Divorce, (and I am not >> sure GEDCOM can handle a Divorce) Death and Burial information with >> Name Location Date and Source I do not think that any other >> information can be handled by GEDCOM.
GED acknowledges a divorce and will insert a tic in the correct box on the marriage field. If any of the programs I've used had a data-entry field for the details of a divorce, I never spotted it.
>> TMG has many features like Name Variations, Witnesses to Tags etc. >> which AFAIK are ignored in a GEDCOM export.
> As I said above.
I believe TMG exports those fields -- a belief based on the fact that TMG has from the beginning exported everything you can enter. What the importing program does with it is not anything GED or TMG can affect. (And now, someone will prove that TMG doesn't export those, and disappoint me further.)
On 08 Aug 2010 in soc.genealogy.methods, singhals wrote:
> Two copies of Program A should and generally do import correct all > content of a GED from one another.
I seem to recall that somebody did this experiment some 15 years ago, with varying results. However, the results weren't 100%. It might be worth repeating on current versions of genealogical software.
>>> TMG has many features like Name Variations, Witnesses to Tags etc. >>> which AFAIK are ignored in a GEDCOM export.
> I believe TMG exports those fields -- a belief based on the fact > that TMG has from the beginning exported everything you can enter. > What the importing program does with it is not anything GED or TMG > can affect. (And now, someone will prove that TMG doesn't export > those, and disappoint me further.)
TMG - last I checked; I don't export much via GEDCOM - will export every name you put into it. The problems with that are two: - some programs will ignore multiple names on import - (assuming that a program will accept multiple names) there seems to be no concensus in the GEDCOM community over which name of multiple names in an individual's GEDCOM record should be primary.
The export of TMG 'witnesses' was the subject of some debate on the TMG mailing list. (For those not familiar, in TMG terminology, everybody connected to an event is a 'witness'. Depending on the event, either zero, one or two individuals can be primary. However, unlimited numbers of individuals can be linked to an event. You can link all 500 guests who attended your wedding!) Needless to say, the GEDCOM standard has no mechanism to transfer this information. A nagging thought in the back of my mind tells me that there may have been some work done on a third-party solution to export witnesses, but I can't find anything about it at the moment.
>> That may be part of the problem but the real problem AFAIA is that >> Gedcom was designed to meet the needs of the Mormon church which are >> not exactly the same as those of family historians. Only the >> intersect of those two sets of needs is filled as far as the family >> historian is concerned. This poses a dilemma for the S/W developer: >> a package which is dominated by what standard Gedcom allows is >> restricted whilst a package which ignores the restrictions is unable >> to export all its data without private extensions which may be >> meaningless to other programs.
> GEDCOM has some serious flaws, but it's biggest disadvantage is the > plethora of programs that offer features GEDCOM _does_ support, yet > refuse to be bound to any "standard."
> Examples: (1) there's a program that does > 1 NAME Jane /Doe/ > 2 _MARNM Jane /Roe/
> when the "standard" already defined > 1 NAME Jane /Doe/ > 1 NAME Jane /Roe/ > 2 TYPE married
> (2) the "standard" allows you to have a source for an event:
> 1 BIRT > 2 DATE whatever > 2 SOUR @source-ref@
> yet at least one program prefers to say
> 1 NOTE ! birth-source yadda yadda
> The '1 NOTE' "by the book" says this is a NOTE (not a source) for > the entire individual's record. The rest of the line says, "Yeah, > but we don't like the GEDCOM spec, so it's really a source for the > birth subrecord."
> (ironically, a program from the group that invented GEDCOM)
> (3) GRAMPS >> FWIW here's an example of what gets exported by Gramps:
>> 1 BIRT >> 2 TYPE Birth of Goddard, Francis
> What's the point of this? We knew it was a birth from the line > above. And if you know the name, you should be putting it in a 1 > NAME Francis /Goddard/
In terms of the Gramps database structure the Place is linked to the Event and this particular text comes from the Event Description. I guess there must have been a choice of omitting data or bending it to fit the GEDCOM data model. This is essentially free text which can be entered by the user but there is an option to autogenerate the descriptions which gives the text shown.
>> 2 DATE BEF 25 JUN 1760 >> 2 PLAC Larks House, Hepworth >> 3 MAP >> 4 LATI N53.558552 >> 4 LONG W1.74641 >> 2 ADDR >> 3 CITY Hepworth >> 3 CTRY England
>> It omits the county (WRY) and church parish (Kirkburton). And by no >> stretch of the imagination ca Hepworth be described as a city.
> If Hepworth is not a city, why is GRAMPS saying it is?
Because, as I said, it has a fixed address format which makes provision for a city but not for a township so I reused city for township which is the basic land division below manor at that time and place. Again there was a choice of bending data to fit the data model or omitting it.
That's one of my grumps. Too much S/W has built in cultural assumptions. Once one steps outside the bounds of the assumed culture the user has to start to bend data to fit the data model. And the bounds can be temporal as well as geographical.
What I'd like to see is a system where the S/W architect could say "we need an object of class place, or personal name, or whatever here" but there could then be a series of subclasses which provide for the relevant variations such as patronymics etc. If there were to be a mechanism for user-defined subclasses so much the better.
> And if GRAMPS > omits the county, which the GEDCOM spec both allows and recommends, > why?
Pass. I didn't write it. But I think we're in agreement that it should be included.
-- Ian
The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk
>>> What GEDCOM does with information contained in a genealogy program >>> data depends on whether GEDCOM recognizes the data. Given the age >>> of the GEDCOM protocol >> That may be part of the problem but the real problem AFAIA is that >> Gedcom was designed to meet the needs of the Mormon church which are >> not exactly the same as those of family historians. Only the >> intersect of those two sets of needs is filled as far as the family >> historian is concerned. This poses a dilemma for the S/W developer: >> a package which is dominated by what standard Gedcom allows is >> restricted whilst a package which ignores the restrictions is unable >> to export all its data without private extensions which may be >> meaningless to other programs.
> But Program A having private extensions which are NOT universally > accepted by Programs B thru ZZ is what allows the developers of Program > A to /copyright/ their intellectual property and regain their expenses > of developing it. Two copies of Program A should and generally do > import correct all content of a GED from one another.
The relevant word on Bob's post was *protocol*. The important thing about protocols are that they are followed without variation.
The internet is a good example of this. The "P" in "TCP" and "IP" both stand for protocol. Implementors of network stacks are perfectly free to copyright their implementations to regain their expenses but what they're not free to do is cobble on a few private, non-portable extensions; if they did that the 'net would fail to work. If extensions are needed they have to be developed and agreed in an orderly fashion by the relevant parties and then rolled out.
-- Ian
The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk
> You ought to know that it would bloat the code beyond belief if each > and every variation of "the entity generally referred to as City" > were offered up ... village, town, hamlet, wide-spot, City, > Metropolis, Marketing Area (NOT to be confused with Market town). > OTOH, I do agree that if you entered WRY it ought to have exported.
> Cheryl Singhals
But the failure to export it is a flaw in GRAMPS, not in GEDCOM.
As for "every variation," CITY, STAT, CTRY, etc. are GEDCOM's leniency for programs unable to cope with the ideal of completely identifying the place on the PLAC line. Similarly, SURN, GIVN, NPFX, TITL, and umpteen others are GEDCOM's leniency for programs that can't handle
1 NAME Dr. John /Doe/, Jr., M.D.
IMHO, that leniency is one of the flaws in GEDCOM.
Another less serious one is this odd concept that genealogists are only interested in four-letter words.
I adopted the practice of editing my GECOM file directly simply because I could not find ANY affordable program that didn't impose unnecessary restrictions on what could be entered and how.
Even LifeLines. At first, I continued to use LifeLines to catch syntax errors and errors in cross-referencing, until I got enough practice to not need it.
Recently, I started using PGV for its collaboration functions, but still do almost all of my edits in GEDCOM.
> guess there must have been a choice of omitting data or bending it > to fit the GEDCOM data model. This is essentially free text which
> Ian Goddard
Nothing in the GEDCOM spec forces anyone or anything to omit the county.
GEDCOM allows specifying in the header of the file how to interpret PLAC lines, for example, mine says 1 FORM specific, city, township, county, country
GEDCOM also allows adding a FORM tag to a specific place to override the=20 file's default.
> event, either zero, one or two individuals can be primary. However, > unlimited numbers of individuals can be linked to an event. You can > link all 500 guests who attended your wedding!) Needless to say, > the GEDCOM standard has no mechanism to transfer this information.
> Joe Makowiec
GEDCOM has two forms, an event-linked form and a lineage-linked form. I don't know whether an event-linked form has ever been clearly defined.
The lineage-linked form does have an ASSOciated tag which allows the linking of a person to any other by specifying the relationship in a sub-record. BUT it can only be done INDI to INDI to be strictly spec-compliant. Of course, few programs make much effort to be strictly spec-compliant.
Lineage-linked GEDCOM also has a ROLE tag that can specify a person's role in an event. Unfortunately, (1) it has no way to say WHOSE role, so it is only practical if the event is a subrecord of an INDIvidual. (2) And even when in an INDI, it is technically supposed to be part of a source citation, rather than a direct part of the event. Somewhat of a rather odd restriction.
> I adopted the practice of editing my GECOM file directly simply > because I could not find ANY affordable program that didn't impose > unnecessary restrictions on what could be entered and how.
> Even LifeLines. At first, I continued to use LifeLines to catch > syntax errors and errors in cross-referencing, until I got enough > practice to not need it.
> Recently, I started using PGV for its collaboration functions, but > still do almost all of my edits in GEDCOM.
My question related to the claim that there was genealogy software that forces you to enter a location (like birth place) in a specific way. I haven't encountered any and was trying to understand the comment that "If you choose to use a genealogy program, you enter it in a way the program allows or you don't enter it."
Wes Groleau wrote: > > guess there must have been a choice of omitting data or bending it > > to fit the GEDCOM data model. This is essentially free text which
> > Ian Goddard
> Nothing in the GEDCOM spec forces anyone or anything to omit the > county.
For avoidance of doubt, we're in agreement.
> GEDCOM allows specifying in the header of the file how to interpret > PLAC lines, for example, mine says > 1 FORM specific, city, township, county, country
> GEDCOM also allows adding a FORM tag to a specific place to override > the file's default.
Again for avoidance of doubt, I wasn't complaining about how GEDCOM handles places but the fact that I'm presented with a fixed format for handling places in S/W.
My problems with GEDCOM are far more fundamental than that.
-- Ian
The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk
