Re: [Gramps-users] Places Type Taxonomy

[Enno B. <enn...@gm...>]

Hello Hugh,

> As for the polysemous terms, what exactly constitutes a 
> "municipality"? There are several other layers/terms like city, town 
> which could be more accurate. Is there a use case for "municipality" 
> which is not covered under the other terms?
Yes. In my country (The Netherlands) a municipality is where you 
normally find the civil registry, which means that for any birth, 
marriage or death in the past 200 years it helps to know what 
municipality a place belonged too. See also:

https://en.wikipedia.org/wiki/Municipality

I don't use Gramps 4.2 myself, because I prefer the old location model 
used in 3.4, but if I were using it, I would probably not add the 
municipality because they change too often, and the names of places 
(cities, villages) in this small country are unique enough to be 
distinguished by province alone.

Municipalities are visible in my sources though, because I register 
sources by the name of the civil registry.

I need to add that I would not register types like city, town, or 
village either, for a couple of reasons:
1. I often don't know what the exact type of a populated place was, at 
the time,
2. There are only two different Dutch words for these three terms, so 
the word Dorp appears two times in the place type menu,
3. Only city would be exported right in a GEDCOM address, because Gramps 
4.2 discriminates against towns and villages.

For myself, it would be much easier to use a more neutral type like 
place, which is equivalent to the Dutch word "plaats", which refers to 
any populated place of type city ("stad") or village ("dorp"). This type 
should then also be exported to GEDCOM as CITY to prevent information loss.

> From my work in taxonomy development terms usually have a use case 
> before they are added. Can anyone point me to why we have this current 
> set of options, and why it is limited to these options? I would like 
> to know what the intended use/definition is of each term. Is the 
> current list in some way related the "limitations" of the GEDCOM 
> standard?
I think that Nick gave a perfect explanation of the how and why. GEDCOM 
itself is much more limited, in the sense that the extension mentioned 
by Nick is not used much outside Germany, and the standard as made by 
the LDS only defines types like city, state, and country.

The options are not limited though, because you can enter any type you 
like. There is a drawback then, because Gramps will store the type as 
written, so it won't be translated when a tree is imported by a foreign 
user.

> How are others handling the kinds of issues I am raising, with 
> different structures in different countries and (seemingly) 
> insufficient distinctions in the current typology?
I currently handle this by sticking to Gramps version 3.4. I am thinking 
about filing a suggestion to improve Gramps in a couple of ways like:
1. Reduce the number of visible types, so that users won't see 
duplicates, or entries that are irrelevant for the area they are 
researching,
2. Expand the taxonomy so that I can use the type that is appropriate 
for a specific location, and won't have to use a single type named 
"provincie" for a US state or a German Bundesland,
3. Make sure that relevant types are mapped to their equivalents in the 
simplified world of GEDCOM, so that cities, towns, and villages can all 
be indexed as CITY, provinces and states as STAE, etc.

> Is there reason that address entries under people records do not show 
> up under places?
Yes, a technical one. Address entries have always been stored inside the 
person table, and in 4.2, they still follow the flat location structure 
used in Gramps 3.4, which has dedicated fields instead of the more 
flexible (but confusing) hierarchical types.

In my personal opinion, these address entries can better be removed, 
because they're not compatible with the GEDCOM address structure anyway, 
and residence can just as well be registered in the form of real 
residence events that use the new location structure. Person 'addresses' 
are already exported as residence events anyway, so for the outside 
world, there isn't much of a difference.

That said, I do like to have a real GEDCOM compatible address which 
allows me to format address lines as they are used on real mailing 
labels, where in my country the house number sits behind the street 
name, and the zip code sits in front of the place name. Gramps 4.2 only 
supports the English and US format somewhat, and if you separate the 
house number from the street name, i.e. put that number in an extra 
location enclosed by the street, you will notice that the 1st line of 
the exported ADDR has no number, but only the street, rendering it 
useless for the purpose that I think it was made for.

In 4.2, the exported ADDR looks completely redundant to me, because it 
only includes lines that are recognized as street, city, state, and 
country, where the PLAC line exports all known elements of the hierarchy 
in the right order, except for the zipcode. This means that when I enter 
my birth location in the right way, using one of the Dorp entries from 
the menu, no CITY line will appear in the GEDCOM, suggesting that I was 
born in some unregistered place, which is plain wrong. Some real cities 
are smaller than the village where I was born, so there's absolutely no 
reason to discriminate here.

cheers,

Enno