Geps045 - type of administrative identifier

I have been looking at the GEPS045 page and have a question.

Will there be a default list of TYPE_OF_ADMINISTRATIVE_IDENTIFIERS?

For instance, I want to add the ISO 3166-1 alpha-2 (2 letter country id) as well as ISO 3166-1 alpha-3 (3 letter country id) and potentially a flag image to some places (countries). I may also want to add other flags to places (like states or regions).

Would the flag attribute value need to be the Media ID?

To leverage these, there needs to be an agreed upon set of IDs that have a specific meaning. For instance, I may want a chart that has a person background image of the flag of where they were born. Type needs to be standardized so addons can leverage them.

Hypothetically, these 3 types could be ISO3166-alpha2, ISO3166-alpha3, and flag.

For instance:

United States of America; ISO3166-alpha2:US; ISO3166-alpha3:USA; flag:O12345
Canada; ISO3166-alpha2:CA; ISO3166-alpha3:CAN; flag:O12346

Or am I misunderstanding? Can the GEPS documentation add the well-known type IDs.

The _AIDN tag and its administrative identifier originated with the Gedcom-L group place enhancements. So the fields could be any text value, the group did not attempt to standardize these further (an exception is countries and states, they have a comment that says “ISO 3166 for countries and states”). You may want to bring this question up to them.

See the (German) page GEDCOM/ LOC-Tag – GenWiki (you may want to use Chrome and let Google translate go to work if you don’t read in German).

Before commenting on your post, I read GEPS045 and I wonder if suggestions are not a bit complicated.

GEPS045 proposals are mainly based on Attributes and bump into attribute limitations, i.e. attributes are simple key/value pairs. Most suggested annotations require more than that.

I presently (Gramps 5.1.4) workaround these limitations with user-typed notes. I can then structure my custom notes a bit like what is described in GEPS045. Of course, ergonomics is not the same as a dedicated field in the GUI dialog. You must open or create a note and commit it. It is the same complexity as using an attribute. On the contrary a field is immediately available; it is more straightforward. But it requires a clear and well structured specification because it will “freeze” the kind of information.

Regarding place identifiers, I already use ISO 3166-1 alpha-3 to build a “hierarchical” id for populated locations, a kind of gramps_id having for sole purpose to uniquely identify a place in the DB. As such, I don’t give any significance to this id, in particular no historical value. This is built in today’s context, within the current political boundaries.

This populated location is enclosed in time-tagged areas describing the then existing relationship. I can’t assign an ISO 3166 id to these “countries” (and even less to their subdivisions) because ISO 3166 was not invented yet. These countries may not survive today (what about the German Holy Roman Empire? what about the United Provinces? what about the duchy of Parma?).

Even a generic default list of administrative identifiers does not make sense because administrative hierarchy depends both on local culture and period of History. Presently, the list provided by Gramps is US- and UK flavored. IMHO, it is an error to translate the names into other languages because the translated word, though conveying the same concept, may not cover the exact same legal definition.

Take the example of country-state-county-town. Country may define the same concept as pays (fr) or Staat (de), but state doesn’t correspond politically to région (fr) or Land (de). County has nearly no equivalence. I consider we should have separate hierarchies per ruling system (both geographically and hitorically) so that there is no ambiguity. But this complicates a lot place management.

Regarding flags, I wouldn’t reference them from an attribute. I’d directly put the flag id in the place gallery. Maybe you have a rationale for suggesting accessing the flag through an attribute. To be able to sort on flag? I think this is equivalent to a consistent “enclosed by” hierarchy. Remember also that flags change with time. So again, assigning them in the time-tagged “enclosed by” hierarchy may be a better solution.

To be honest I have not yet found the way to represent my wishes about places with the present features. And I have done no deep introspection to clarify my needs.

1 Like

ISO3166: Thanks for the reference to the GenWiki. Is there any application that actually uses the _AIDN where I can see GEDCOM file samples of the types used? Or is it in the spec but not generally implemented in export?

Flags: Initially I thought about putting a flag image into the place gallery of the time-tagged entity. But then decided not to, since I was looking at a method of getting the flag image for a Chart or even Report, and how would I know that the image in the place gallery was a flag vs something else. The only other option I could think of was in the newly created Administrative ID IFF there was a consistent naming of at least some subset of the id types. So I threw out a few that seemed standard (alpha2, alpha3, flag). I realize that only current places could have the ISO3166 info.

I agree that the flag should be in the time-tagged entity. The Holy Roman Empire and the Duchy of Parma had flags.

I guess I could fall back to putting the flag in the place gallery and for report/chart purposes assume that if there is a place gallery image, the first is the flag. I suspect this violates the principal of least astonishment, though. Or maybe I postpone updating Charts/Reports to leverage a potential flag image.

The result is that I don’t see the value of the Admin ID if it is free text. It seems it is really just a Note.