I’m on v. 5.2.4 running under Linux (Fedora 40). I cannot find a way to register an address when I register a residence (as event). I tried to use the description field, but that ends in the GEDCOM file as a value for the 1 EVEN - record. Should the event form maybe have an address field entry? In the GEDCOM filew, the ADDR record has no value.
People tend to either use a residence event or an address but not both.
See Why residence event and not Address? for further information.
1 Like
Addresses are a separate 2ndry objects to the Person and Repository objects.
I generally use Residence events for gross place changes (from 1 city to another) and have fine changes (different street address, different apartment) using the Address field.
Others like to put full address information in to Events. I feel that the Address level entries cause too much clutter in the Place table. (Although I do add address level for Homes/Farms that are used acreoss several generations or have special significance.)
Thank you for the quick replay.
I know of the reasoning about residence events and not address. That’s why I went through my database and changed it (+12000 ind.). It made completely sense to me.
But still, I would wish that a residence registration could incude an address field. As I mentioned, the GEDCOM code for a residence (generated by Gramps) include 1 EVENT without a value.
It’s not that an address (like a street address) is important, but more for registering a farm. The family tree until about mid 1900 are mainly people living on farms, and thus farms comprizes an important aspect of the family history. Including the farm (as an adress field) could be simple (?). I don’t see registering all relevant farms in places as a option either.
I think the biggest deciding factor should be which reports you will be using. Information stored in the Address tab is not not included in most reports.The advantage using the Address tab, specific time in residence for each person can be added. Key to this is making sure that the address information is consistent in each record for each person.
A Residence event can easily handle any place information and will appear in many reports. A place hierarchy can be made as deep as needed.
Country: U.S.A.
Regions: District of Columbia
City: Washington
Street: Pennsylvania Avenue
Number: 1600
Building: The White House
Country: Norge
Region: Østlandet
County:Østfold
Municipality: Tune
Village: Varteig
Farm: Pick a Name
Using the Residence event with a place entry from the database has the added advantage of taking advantage of handling changes in naming and structure within the hierarchy over time, each tracing down to the farm. The address tab only has static information and does not have access to mapping that the place in an event has.
Thanks again for the reply.
I agree that the way you enter data is guided to a large degree on the way you want to generate reports. Generally you want to register all information in an easily accessible way, and that’s what make Gramps stand out. And I wish that that was the case for the generated GEDCOM file.
I try to keep the places that I register close to the official jurisdiction, which is four levels in the US, if I understand correctly. In Norway it is only three, but I have “sinned” and have one level beneath the county (kommune) level.
Therefore I’m very reluctant to include privet places in my list. In that’s why I also wat to avoud including farms and private property and even churches in mu places list.
Below is an example entry of a residence for a family
And the resulting GEDCOM code is:
1 EVEN Mokk
2 TYPE Residence
2 DATE 1772
2 PLAC Ogndal, Steinkjer, Nord-Trøndelag, Norge
2 ADDR
3 CTRY Norge
There is an empty 2 ADDR field!
I tried to enter the farm name in the Desription field, but it ended as value to the EVEN tag!
I do some farm history for Norwegian farms, where the borders for the political entities changed over time, both in size and name…
A farm could go from one “Amt” (county) to another or from one Municipality (herred, kommune) to another multiple times in history and where we in addition had a navne change from the old names to the new names herred/amt, kommune/fylke…
AND as if this wasn’t enough, we also had the ecclesiastical regions with different boundaries.
I use the place hierarchy for this, because then I can register every single change through history.
I make a hierarchy for each type, eg. one for det administrative path “Amt”/“fylke” etc. and one for the ecclesiastical path (“sogn”/“sokn” etc.), or more when needed…
That way I can register any changes that happens with that farm/place and any other place there. by adding an Event and register the changes in names/embedded by information and date information when needed.
Even though I use Obsidian for most of my research, I also add this static information into Gramps, so while I wait for Events for places, I add an event linked to the place, without relating any people to it, when it is a place-oriented event, e.g. if the boundaries change so the farm is in another legal entity etc…
Note that in v6.0 the ADDR tag will no longer be exported for places.
See pull request #1705 - Change the output of ADDR tags in the Gedcom export.
Can I ask why you need to generate GEDCOM files? The last time I used a GEDCOM was when I migrated to Gramps and imported from PAF5 8 years ago.
The GEDCOM “standard” is limited in its abilities to transfer geeology data, even with the new 7 version. But it is the only de facto standard we have, and thus it is an important component for all that do computer based geneaology research . With Grams and Gramps Web, doing your gen. activity alone, or in collaboration, you can do well without GEDCOM. If you don’t mind that your research ends with you, and no one will “take over”, the same apply. But if you want the gen. research you have been doing could be of intereset to the someone coming after, I see GEDCOM as the almost only viable option to save that legacy. If your work is mothballed in some way, for someone other to take over and continue, what format would you save it on? Think several decades in the future (20-30 years). Normal magnetic media har a lifetime of about 20 years (at most).
I dont think a .gramps file will be the safest bet. But a GEDCOM file, with a paper printout will probably the safest way to “conserve” your work. Another issue is that if you want someone to inherit the work, it is a possibility that they want to use som othe platform than Grams or Gramps Web.
Fair enough. I understand.
In the short-term, I would go with a full blown place hierarchy and enter the Farm as a Residence event.
While GEDCOM is less than ideal, it is the only universal genealogical standard. And Gramps squeezes its data into the GEDCOM as best it can given GEDCOM’s limitations. Who knows what will exist as a universal standard 5, 10 years from now. I am sure Gramps’ exports will continue to evolve along with it.
But on the flip side of the equation, whatever genealogical program our ancestors who take up our work will use, will need to adapt as it imports the universal standard at that time. We can bequeath to our ancestors both files, a current GEDCOM or the universal standard at that time, and a current, uncompressed, Gramps XML backup file. What they do with them will be out of our hands.
Thank you for all replies, - very appreciated.
I made a couple of reflections during the exchanges:
- It seems that we tend to do things differently, and Gramp with its variety of
options certainly provides the opportunity. Maybe the geneaology reseach
need some more “standardisation”? - As is obvious, I do think that Gramps (and other systems!) should conform to
GEDCOM as much as possible (despite its “flaws”). But as important is to
utilize the GEDCOM as much as possible to conserve gen. data. Thus
removing the ADDR subtag from the RESI tag, ???
This thread made me take a closer look at the GEDCOM definition - I downloaded v5.5.5 as a pdf. Searching for RESI I found this note:
Residence isn’t an Event but an Attribute
This <FAMILY_EVENT_STRUCTURE> definition includes RESI (residence) as a possible event. However, the residences of a family aren’t events, they are attributes. A building has an age, but a residence has a period. Moving in and moving out are events, typically happening on a single day, while having residence is an attribute, typical valid for a period of many years.
The miscategorisation of RESI as an event is a hold-over from earlier GEDCOM version. The FACT record was only introduced in GEDCOM 5.5.1. Prior to GEDCOM 5.5.1, FamilySearch did not really distinguish between events and attributes.
5.5.5 is a deadend branch of GEDCOM proposals. Are there any tools that adopted it?
Could you revalidate against 5.5.1?
(Or perhaps there is a 7.0 reference? Gramps doesn’t support 7.0 yet… and doesn’t have concrete plans to do so. Which means a such a reference might not be pertinent. )
From the v5.5.5 documentation:
Technically, the GEDCOM 5.5.5 specification succeeds the GEDCOM 5.5.1 specification (1999 CE) as the current GEDCOM specification. Practically, it succeeds the GEDCOM 5.5.1 Specification Annotated Edition (2019 CE).
Previous GEDCOM releases were feature releases that introduced major new features. GEDCOM 5.5.5 does not introduce any major new features, quite the opposite: GEDCOM 5.5.5 removes long obsolete and deprecated features. GEDCOM 5.5.5 is a maintenance release; it fixes a variety of issues to provide a better specification, and a solid basis for future versions.
Wasn’t 5.5.5 proposed by Tamura Jones as the LDS copyright was nearing expiration?
Squashing 5.5.5 was was probably the trigger for the LDS’ 15 Nov 2019 official release of the 1999 5.5.1 draft as a “final” succesor to the 5.5 standard from 1996. And started the renewed interest in improving the standard after the abandoned GEDCOM X (used internally by FamilySearch) and XML GEDCOM 6 proposals.
But 5.5.5 was never part of cycle.
How many of you have actually considered that GEDCOM defines certain concepts incorrectly?
The concept of “residence” cannot logically be an attribute, because it represents a separate entity—a physical location. If something akin to an attribute is necessary, it must be clearly defined as “has residence,” rather than just “residence.” Furthermore, the attribute “has residence” reflects a state over time, not a single milestone. Therefore, the RESI attribute must include a time dimension to be historically accurate.
A better approach would be to record “residence” as an event with both a start and end date. This would also allow for the inclusion of related events like “moved to” and “moved from.” Additionally, this approach is more historically accurate, as it enables documenting historical changes related to the residence entity itself. Examples include the geographical location of the residence, its administrative affiliations, and who moved in or out over time.
Genealogical data should be recorded in the most historically accurate way possible, using methods that allow such data to be transcoded into GEDCOM for export if required. GEDCOM should not dictate the primary structure for recording and storing genealogical data—it should only serve as a secondary consideration used for export purposes.
For this reason, I firmly believe that focusing heavily on adhering to GEDCOM definitions in programs like Gramps is misguided.
Programs like Gramps should not aim to “conform to GEDCOM as much as possible (despite its flaws).” Instead, they should prioritize historical guidelines that enable accurate recording, storage, and presentation of data. GEDCOM export should remain a subordinate feature.
Additionally, a strong focus should be placed on robust export functions for other, more open and versatile formats, such as Gramps XML or other open-data formats. This ensures that the data we work to preserve has the best chance of surviving for future generations. Over-reliance on the restrictive GEDCOM format could hinder this long-term goal.
To be frank, the genealogy community is doing itself a disservice by prioritizing GEDCOM. Even its latest iterations remain limited, as GEDCOM has always been primarily shaped by the LDS Church’s family research needs, which are rooted in their belief system. This does not make it historically accurate or the best way to record or share genealogical data.
Note;
This text was transcribed from Norwegian to English with the assistance of AI (Microsoft Copilot), which also ensured the text flows naturally in English grammar, which often differs from what would constitute good flow in Norwegian.
2 Likes
I believe that most people acknowledge the GEDCOM is an inadequate standard for general genealogy and that some/many tags are not well implemented. Acknowledging that GEDCOMs purpose is to support the missions of the Church of Latter Day Saints, not pure and rigorous genealogy research.
It simply has more money and people behind it, more people using it religiously. It reached crtical mass as a standard before even considering application outside the LDS community.
And that the general genealogy community grumbles but found GEDCOM flexible enough to be perverted to a broader use. (Including custom tag dialects that applications intended for internal use by their communities.) Add to this, the broad community has been unable to agree on a more capable standard nor have they been effective in pushing the adoption rate of any proposed format to the point where it reached critical mass. Gramps XML is probably the format mentioned most frequently that is not a GEDCOM variant.
(This does not even consider that the gorilla in the marketplace, Ancestry dot com, has compelling business reasons to undermine adoption of any strong data exchange format.)
1 Like
As I have mentioned earlier, it made sense to me to register residence as an event, - which I do with a date (reference from census, or other reliable source). I cannot see any better way.
I fully agree that Gramps should prioritize guidelines that enable accurate recording. But as long as GEDCOM export is implemented, I still believe that the resulting .ged file should conform to the GEDCOM “standard” (5.5.1) as much as possible. I see no contradictions here?
I would really see Gramps XML becomming a standart for gen. data exchange. This would solve a lot. But I guess the gorillas in the marketplace would not support such an idea;-) Are there any parsers for Gramps XML?
By the way, I applaud the courage that the Gramps-Project has taken to not cave into the GEDCOM conformance. The wiki is utterly forthright when saying that data will be lost when exporting to GEDCOM. There is no waffling by creating custom tags that other programs cannot read.
This has allowed Gramps to step outside unreasonable restraints of GEDCOM in the past. And it expands our horizons to do so in the future.