Changes in Place Names Over Time

[Nermal 0]

Hi

 

I'm trying desperately to decide how I want to enter place names in my database, but so far I'm not coming up with anything that I like.

 

I've searched through the Fora here (although I really only found one posting that addressed the problem as I'm seeing it), and I've been through Terry Reigel's help pages.

 

Basically, I'm concerned about major changes in place names and how to record thm/connect them. From what I've seen, there's basically two approaches to this:

a) Record the name of the place as it currently is and make notes regarding the name as it used to be, and

Record the name of the place as it was at the time of the event and make notes (e.g., Comments) regarding how it has changed since.

c) I've also seen the suggestion of having it both ways by using the original name and then (in brackets or parentheses giving the current name: e.g: XXX, in YYY County, Tennessee [now XXX, West Virginia] or something along those lines.

 

My concern is basically this:

I feel fairly strongly that I should record the name of the place as it was at the time of the event; I'm therefore not thrilled with option a). Besides, the name of the city/county/country may change tomorrow and make the entire scheme wrong/obsolete. [i have the same objection to merely giving the name of the place as it was at the time of the (w/o specifying more info, as the name may have changed the year before the event as well].

 

If I record the name as it was, however, I'm forced to use either option or option c), above. Either way, I'm going to end with multiple place names in my Master Place list for the same place.

 

For example, I need to record an event that happened in a specific town. From 1812 to 1873 it was called Yedintsy and it was located in the uyezd "district" of Bessarabia, Russia (some sources say that Bessarabia was technically an independent region). Regardless, as of 1873, Bessarabia was officially incorporated as a guberniya, or province, of Russia and Yedintsy was placed in the Khotin district of this province. After 1919, Bessarabia became the independent country of Moldova, and the name of the city was changed to Edinets.

 

I currently have at least one event to record while it was independent, another when it was in the Khotin district of Bessarabia, and another once it became Edinets, Moldova.

 

I might possibly be willing to simply call it Yedintsy, Bessarabia and explain the changes in the comments, but now that it's in another country altogether, I see no way of linking the various names. It's going to show up in my reports as being at least one city in "Russia" and another in Moldova, regardless of whether I give it the same Lat/Lon coordinates or not.

 

My research makes it imperative that I be able to connect people living in/near the sanme place, and trying to remember all of the name changes, especially when it involves countries, is going to quickly become impossible.

 

When I had first seen that TMG allows you to define a specific place name for a specific time period -- even going to the length of warning you if the recorded event is outside the specified period -- I had been quite excited, assuming that I could simpy tell the program what changes had occurred [i certainly didn't expect the program to keep track of this for me ahead of time; that would clearly be an overwhelming task. But I [b]had[/b] assumed it would allow me to specify such changes in towns/areas that were important to me]. Frankly, I'm not overly sure of what good it does you to tell the program that the town was only called Yedintsy from this year until that year, if it won't then also allow you to tell it what is was called earlier and later.

 

Anyway.....I'd appreciate any and all suggestions.

I don't want to end up with multiple entries for the same place, nor am I overly willing to essentially pick a time at random and use the name of the place as it existed at that particular time.

 

Any and all help appreciated.

Thanks,

 

Rob

[joanmc 0]

Rob, you have my sympathy. I don't have a solution for you other than how I've dealt with that problem. In Eastern Ontario, between the 1780s to the 1860s, the name changed from Quebec to Upper Canada to Canada West to Ontario while the townships changed, the counties were created and, for a time, there were districts as well. I settled on using the name of the location at the time of the event and, in any publication - chart, report or whatever, give a 'legend or timeline' indicating the names of what the area is now. I've also created several different Place Styles to help with this.

 

Just some info on how someone else does it.

 

Joan

 

Hi

 

I'm trying desperately to decide how I want to enter place names in my database, but so far I'm not coming up with anything that I like.

 

I've searched through the Fora here (although I really only found one posting that addressed the problem as I'm seeing it), and I've been through Terry Reigel's help pages.

 

Basically, I'm concerned about major changes in place names and how to record thm/connect them. From what I've seen, there's basically two approaches to this:

a) Record the name of the place as it currently is and make notes regarding the name as it used to be, and

Record the name of the place as it was at the time of the event and make notes (e.g., Comments) regarding how it has changed since.

c) I've also seen the suggestion of having it both ways by using the original name and then (in brackets or parentheses giving the current name: e.g: XXX, in YYY County, Tennessee [now XXX, West Virginia] or something along those lines.

 

My concern is basically this:

I feel fairly strongly that I should record the name of the place as it was at the time of the event; I'm therefore not thrilled with option a). Besides, the name of the city/county/country may change tomorrow and make the entire scheme wrong/obsolete. [i have the same objection to merely giving the name of the place as it was at the time of the (w/o specifying more info, as the name may have changed the year before the event as well].

 

If I record the name as it was, however, I'm forced to use either option or option c), above. Either way, I'm going to end with multiple place names in my Master Place list for the same place.

 

For example, I need to record an event that happened in a specific town. From 1812 to 1873 it was called Yedintsy and it was located in the uyezd "district" of Bessarabia, Russia (some sources say that Bessarabia was technically an independent region). Regardless, as of 1873, Bessarabia was officially incorporated as a guberniya, or province, of Russia and Yedintsy was placed in the Khotin district of this province. After 1919, Bessarabia became the independent country of Moldova, and the name of the city was changed to Edinets.

 

I currently have at least one event to record while it was independent, another when it was in the Khotin district of Bessarabia, and another once it became Edinets, Moldova.

 

I might possibly be willing to simply call it Yedintsy, Bessarabia and explain the changes in the comments, but now that it's in another country altogether, I see no way of linking the various names. It's going to show up in my reports as being at least one city in "Russia" and another in Moldova, regardless of whether I give it the same Lat/Lon coordinates or not.

 

My research makes it imperative that I be able to connect people living in/near the sanme place, and trying to remember all of the name changes, especially when it involves countries, is going to quickly become impossible.

 

When I had first seen that TMG allows you to define a specific place name for a specific time period -- even going to the length of warning you if the recorded event is outside the specified period -- I had been quite excited, assuming that I could simpy tell the program what changes had occurred [i certainly didn't expect the program to keep track of this for me ahead of time; that would clearly be an overwhelming task. But I [b]had[/b] assumed it would allow me to specify such changes in towns/areas that were important to me]. Frankly, I'm not overly sure of what good it does you to tell the program that the town was only called Yedintsy from this year until that year, if it won't then also allow you to tell it what is was called earlier and later.

 

Anyway.....I'd appreciate any and all suggestions.

I don't want to end up with multiple entries for the same place, nor am I overly willing to essentially pick a time at random and use the name of the place as it existed at that particular time.

 

Any and all help appreciated.

Thanks,

 

Rob

[elevator 0]

I completely agree. I have the same problem in Norway where many townships and counties have either split into two or more or joined up. The problem is partially solved by the year-range option, but like you said, there's no way to indicate what the place was called before and after the specified time range.

 

Ken.

 

Frankly, I'm not overly sure of what good it does you to tell the program that the town was only called Yedintsy from this year until that year, if it won't then also allow you to tell it what is was called earlier and later.

[Michael Hannah 0]

I agree that this is an issue. My workaround is as follows (but I only use it occasionally and only for those places that have greatly changed over time). I use as the place name for a tag whatever the place was called in the source citation that provided the evidence for this tag. If I know that this place name was only in use during a specific period and not afterwards, I use the date range in the Master Place List so that it prompts me if I use it outside that date range. My real workaround involves the use of a "pseudo" location person.

 

A single location person could be used to link together multiple “place entries” in the Master Place List that actually referred to the same location by using multiple Name-Var tags with possible date ranges to reflect when the location was known by each name. Name indices would link all these locations to this one “person”. The primary name could be the Name-Var that is the “current” name, or could be a name identifying the latitude and longitude. A tag associated with a "real" person would have the actual name of the location as of the time of the event entered as a place from the Master Place List, but the location “person” could be linked as a witness, either using the actual Name-Var for that time or the “current” name with a possible witness sentence of “This location is currently named [W]”. If a larger area was identified by a single name for a period of time and then subdivided, the larger area “person” could be the “mother” of the multiple subdivided “daughters” who were created/born at the time of the subdivision. (I choose to make all location "pseudo" people female.) You can also have a custom tag in the Birth group for the creation or first settlement of this location. Various tags are possible to associate with a location, and various reports are now possible for these location "people".

 

I define the Given name as the specific subdivision/location (e.g. “Adams Township”) and the Surname as the complete higher level locale, comma separated, beginning with smallest (e.g. “Washington County, Ohio”). I choose to place the country in the Suffix so I can define whether to output it by selecting an alternate name style. My two location name styles (one with country in the output, one without) display these names in picklists with the name parts separated by colons since the surname can have internal commas. I also define custom labels in the name style (i.e. [Location], [Locale], [Country]) for the name parts as a data entry aid.

 

Hope this gives you ideas.

[Robert Jacobs 0]

I may be too new at this game to appreciate the subtleties, but it seems to me that the purpose of identifying the place is to tell the contemporary reader where it is. One runs into this sort of thing all the time with Poland. Poland, or pieces of it, have been Lithuania, Russia, Austria-Hungary, Prussia, Sweden and Germany. Once in a great while they even let it be Poland.

 

I think it's only worth attending to if the jurisdictional, orthographic or etymological changes are material to the information one is recording. In that case, of course, a separate notation would be called for.

 

A similar problem used to arise in writing English history: "Midshipman J. Porter (later Sir Joseph Porter, GCMG, OBE, DSO) and his sisters and his cousins who he reckons up by dozens and his aunts." The contemporary usage seems to be to call him "Joe" throughout.

 

Good wishes to all.

 

 

formerprof

[Mike Talbot 0]

I wish I had a good answer to your question. Maybe there is none.

 

What I try to do is to give the place name at the time of the event and then note my data entry year and the then current place name in the memo field (I don't always succeed in remembering to do this). I give the data entry year, because a lot of place names have changed since I started entering data in 1985 to say now or present. A few Acadian event/place examples:

 

date place memo

1641 Pentagoet, Acadie (1986, Penobscot, Maine)

1700 Port Royal, Acadie (2007, Annapolis Royal, Nova Scotia)

1748 Isle Saint Jean, Acadie (1994, Prince Edward Island)

 

This works for me.

 

Good luck and I hope that you devise a better method,

Mike Talbot

 

 

Hi

 

I'm trying desperately to decide how I want to enter place names in my database, but so far I'm not coming up with anything that I like.

 

I've searched through the Fora here (although I really only found one posting that addressed the problem as I'm seeing it), and I've been through Terry Reigel's help pages.

 

Basically, I'm concerned about major changes in place names and how to record thm/connect them. From what I've seen, there's basically two approaches to this:

a) Record the name of the place as it currently is and make notes regarding the name as it used to be, and

Record the name of the place as it was at the time of the event and make notes (e.g., Comments) regarding how it has changed since.

c) I've also seen the suggestion of having it both ways by using the original name and then (in brackets or parentheses giving the current name: e.g: XXX, in YYY County, Tennessee [now XXX, West Virginia] or something along those lines.

 

My concern is basically this:

I feel fairly strongly that I should record the name of the place as it was at the time of the event; I'm therefore not thrilled with option a). Besides, the name of the city/county/country may change tomorrow and make the entire scheme wrong/obsolete. [i have the same objection to merely giving the name of the place as it was at the time of the (w/o specifying more info, as the name may have changed the year before the event as well].

 

If I record the name as it was, however, I'm forced to use either option or option c), above. Either way, I'm going to end with multiple place names in my Master Place list for the same place.

 

For example, I need to record an event that happened in a specific town. From 1812 to 1873 it was called Yedintsy and it was located in the uyezd "district" of Bessarabia, Russia (some sources say that Bessarabia was technically an independent region). Regardless, as of 1873, Bessarabia was officially incorporated as a guberniya, or province, of Russia and Yedintsy was placed in the Khotin district of this province. After 1919, Bessarabia became the independent country of Moldova, and the name of the city was changed to Edinets.

 

I currently have at least one event to record while it was independent, another when it was in the Khotin district of Bessarabia, and another once it became Edinets, Moldova.

 

I might possibly be willing to simply call it Yedintsy, Bessarabia and explain the changes in the comments, but now that it's in another country altogether, I see no way of linking the various names. It's going to show up in my reports as being at least one city in "Russia" and another in Moldova, regardless of whether I give it the same Lat/Lon coordinates or not.

 

My research makes it imperative that I be able to connect people living in/near the sanme place, and trying to remember all of the name changes, especially when it involves countries, is going to quickly become impossible.

 

When I had first seen that TMG allows you to define a specific place name for a specific time period -- even going to the length of warning you if the recorded event is outside the specified period -- I had been quite excited, assuming that I could simpy tell the program what changes had occurred [i certainly didn't expect the program to keep track of this for me ahead of time; that would clearly be an overwhelming task. But I [b]had[/b] assumed it would allow me to specify such changes in towns/areas that were important to me]. Frankly, I'm not overly sure of what good it does you to tell the program that the town was only called Yedintsy from this year until that year, if it won't then also allow you to tell it what is was called earlier and later.

 

Anyway.....I'd appreciate any and all suggestions.

I don't want to end up with multiple entries for the same place, nor am I overly willing to essentially pick a time at random and use the name of the place as it existed at that particular time.

 

Any and all help appreciated.

Thanks,

 

Rob

[elevator 0]

I disagree with this. When it comes to family research I think it is very important to record the information EXACTLY as provided in the source. I try to make no assumptions about what a historic place is currently called; but I know what the place was called in, for example, the 1664 tax records, or in the 1700 census or the 1800 census without making any assumptions about what the place is called today. Hey, I might not even know WHERE the place is today!

 

Another reason I think it is important to follow the development of a particular place name is parishial borders. The parish to which a particular place or farm belongs may change over time and this knowledge is vitally important to track for church records. If I "normalize" the name to it's contemporay form I may miss where information about births, deaths, marriages etc. are recorded for a particular time span.

 

I am sure the importance of this may vary from country to country, but in Scandinavia where I have most of my family, the ability to track a place over time is of great value.

 

With that said, there may be nothing wrong with making things easy for the contemporary reader, but in my opinion it's more important to record the information accurately; it will make the historical record trail a whole lot easier to follow.

 

Ken.

 

I may be too new at this game to appreciate the subtleties, but it seems to me that the purpose of identifying the place is to tell the contemporary reader where it is. One runs into this sort of thing all the time with Poland. Poland, or pieces of it, have been Lithuania, Russia, Austria-Hungary, Prussia, Sweden and Germany. Once in a great while they even let it be Poland.

[Robert Jacobs 0]

I disagree with this. When it comes to family research I think it is very important to record the information EXACTLY as provided in the source. I try to make no assumptions about what a historic place is currently called; but I know what the place was called in, for example, the 1664 tax records, or in the 1700 census or the 1800 census without making any assumptions about what the place is called today. Hey, I might not even know WHERE the place is today!

 

Another reason I think it is important to follow the development of a particular place name is parishial borders. The parish to which a particular place or farm belongs may change over time and this knowledge is vitally important to track for church records. If I "normalize" the name to it's contemporay form I may miss where information about births, deaths, marriages etc. are recorded for a particular time span.

 

. . .

 

I hadn't even considered the question from that point of view. You're quite right -- the original name could be crucial in further research. I see that several workable solutions have been suggested & I may have to adopt one of them at least for the European side of my work.

 

All good wishes.

 

 

formerprof

[Guest Michael Dietz]

I hadn't even considered the question from that point of view. You're quite right -- the original name could be crucial in further research. I see that several workable solutions have been suggested & I may have to adopt one of them at least for the European side of my work.

 

All good wishes.

formerprof

I bump into this problem all the time (pun intended) dealing with counties. They are constantly changing. In many cases the records are moved from the old county to the new county but not always and so any research may have to be done in both places. I wanted to be able to easily identify when I might have to go to two (or more) resource locations from any report or log I am using. The following examples will demonstrate my method.

 

Montgomery County, Maryland was formed from Frederick County in 1776. So if we have a birth at say 1760 in that part of Frederick county which became Montgomery County I list the county as Frederick (now Montgomery) County in the appropriate location entry. If the date happened to be 1730 and the location falls in the current Montgomery County, then the listing could be Prince George's (now Montgomery) County.

 

Another example has to do with Harpers Ferry, Virginia, which became Harpers Ferry, West Virginia, in 1863. Assume a birth in 1840, then the state would be entered as Virginia (now West Virginia).

 

While this technique will not solve all the possible combinations it does have the advantage of having both the old and current names in the place listing where they are easily identified.

 

Hope this helps.

Mike

[elevator 0]

Just a little example from Norway illustrating why it is important to keep track of places (at least in Scandinavia), and Norway is riddled with examples just like these:

 

Balsfjord and Malangen:

Before 1858, they both belonged to Tromso Parish. 2 Feb 1852, they were separated from Tromso to create their own parish: Balsford and Malagen Parish. In 1856, Balsfjord became the main parish. In 1870 the farms Ytre and Indre Navaren was transferred from Lenvik Parish to Malangen Parish. In 1872 the farms Bentsjord, Brokskar, Løgstad, Kvalnes and Bakkjord transferred from Malagen Parish to Tromsoysund Parish. In 1874 the farm Kilen was transferred from Lyngen to Balsfjord Parish. In 1890 the farm Malsnes was transferred from Malselv to Malangen Parish.

 

Not only was individual farms TRANSFERRED between parishes, they were also divided inbetween themselves:

 

Kjolo, Vestfold County, Norway:

Already before 1300, Kjolo was divided into three: Southern, Northern and Vestern Kjolo. Later it was divided again into one more: Eastern Kjolo. In 1660, Eastern Kjolo was divided into 2, each part farmed by two brothers. In 1770 Eastern Kjolo was joined back into one part under one owner. Several smaller farms spawned off of Eastern Kjolo after 1770: Kjoloholmen, Sparronningen, Kjololokken, and Brevigbugten, at which point Easter Kjolo as an individual farm did no longer exist.

 

I hope this illustrates the tremendeous task it is to track name changes in areas like this. If it were possible to have some kind of timeline in place for each place this would be really great. That way the program could also check for inconsistencies as far as places were concerned. Say I put that a person was born in Navaren farm in Lenvik Parish in 1890. This would obviously be wrong because Navaren farm was part of Malangen Parish in 1890. And if I was looking through the Lenvik church records, I would never find the person because his birth was recorded in an entirely different parish.

 

In cases such as this Michael's suggestion wouldn't really work. Right now I keep track of these things externally and it works. There are even books in Norway written to give timelines of these changes for different areas of Norway, so really it's not a BIG deal, but I'd really love to see the current place tracking feature of TMG to be extended as specified by the first poster (Nermal).

 

Ken.

[efcharvet 0]

I am certain that everyone reading this board can cite examples of wholesale place name changes.

 

The issue is what you choose to enter into TMG in the StandardPlace fields, which can be sorted and used to generate various statistical reports and GedCom files versus what is entered into Memo and Citation Detail fields, which are not sortable and do not always export.

 

What is really needed is a second set of place name fields, which I will call "StandardPlace Variation" fields, that link to each "StandardPlace" field (e.g., Detail, City, County, State, Country, to use the U.S. StandardPlace fields as an example), in the same way that Name Variation Tags link to a person's primary name.

 

"StandardPlace Variation" fields might be better called "Primary StandardPlace Name" fields. I envision that a place name entered into an existing "StandardPlace" field would remain the primary sort name unless something is keyed-into the corresponding "StandardPlace Variation" field.

 

This would allow users to "have their cake and eat it, too"; that is, the place name on the record being cited could be entered exactly as it was called at the time of the event (according to NGS standards) AND accurate statistical reports from TMG could be generated that would aggregate all of the various historical names for a given location.

 

(I spend a month or more every year strictly working at various archives in France. Many of their indexes, compiled in spreadsheets, have one group of (sortable) columns that show what places were known as at the time of the historical event, and another set of (sortable) columns for the equivalent contemporary place names. This has been extremely useful in my research. I have always wished TMG could handle multiple place names as easily as these spreadsheets.)

 

I could elaborate, but I will keep this post brief.

 

Regards, Earl

Edited September 18, 2007 by efcharvet

[Nermal 0]

The issue is what you choose to enter into TMG in the StandardPlace fields, which can be sorted and used to generate various statistical reports and GedCom files versus what is entered into Memo and Citation Detail fields, which are not sortable and do not always export.

 

What is really needed is a second set of place name fields, which I will call "StandardPlace Variation" fields, that link to each "StandardPlace" field (e.g., Detail, City, County, State, Country, to use the U.S. StandardPlace fields as an example), in the same way that Name Variation Tags link to a person's primary name.

 

"StandardPlace Variation" fields might be better called "Primary StandardPlace Name" fields. I envision that a place name entered into an existing "StandardPlace" field would remain the primary sort name unless something is keyed-into the corresponding "StandardPlace Variation" field.

 

This would allow users to "have their cake and eat it, too"; that is, the place name on the record being cited could be entered exactly as it was called at the time of the event (according to NGS standards) AND accurate statistical reports from TMG could be generated that would aggregate all of the various historical names for a given location.

 

Hi all...thanks for all of the suggestions, thoughts and comments.

 

I apologize for not saying so earlier, but I'm new to the board (and bulletin boards in general) and thought that by checking the box to be notified of responses, that I would be notified there was any posting in the topic at all. Of course, I know understand that I'll only be notified if someone responds to one of my postings in particular.

 

Anyway....it looks like my options mainly boil down to either making a comment in the Memo filed, or including the current name in parentheses (e.g: AAA County (now BBB County)).

 

Not yet sure which way I'll go.

 

What Earl suggested is precisely what I was looking for, but I guess I'll simply have to wish for its inclusion in a future version.

 

If anyone has any more thoughts/comments,

 

I'd still love to here them,

 

Rob

[Michael Hannah 0]

Anyway....it looks like my options mainly boil down to either making a comment in the Memo filed, or including the current name in parentheses (e.g: AAA County (now BBB County)).

 

Not yet sure which way I'll go.

Don't forget my suggestion of creating a location "pseudo" person. This is the simplest way that I have discovered to document within TMG multiple names of a location. And if you want a given event to reference the "standard" location, the location "pseudo" person can be linked as a Witness with an appropriate role using an appropriate NameVar of that "person".

[RobinL 0]

I would like to explain an enhancement suggestion for TMG to improve the handling of places with more than one name.

 

This involves a slight change in the way places are recorded.

 

It mirrors the suggestion above of creating a "pseudo-person" for a place so I have decided to repeat it here for comment.

 

(1) The basic concept is that a place has a "primary place name", just like Person Names.

 

(2) Each event records the place name given in the source, just like a "Name-Var".

 

(3) Each new unique place entry is initially made primary. (see next step)

 

(4) But the user may make it non-primary by assigning it to be the equivalent of a previously entered other primary place name.

 

Consequences of this suggestion:

=====================

a. There is still one line in the Master Place List per Place Name entry.

 

b. Some entries in the Master Place List are _primary_ others are _non-primary_, that is there would be an extra column in the Master Place List to show this.

 

c. At the Event tag entry screen, there could be an extra step or button, where the user identified which was to primary place entry equivalent to this place entry.

 

d. In a report or chart, the user could have the choice of either outputting the event place name for that event or the primary place name for that event.

 

e. Filters for the Picklists, Project Explorer and Reports could have extra expressions that allowed for searching for tags that had a common _primary_ place name, even though they actually had different recorded place entries.

 

f. If a user did not want to use this suggested additional feature, TMG would act exactly as it does now. All entries in the Master Place List would be considered primary.

[joanmc 0]

Beautifully put Robin and should work very well for all of us wrestling with this issue. Thank you!

 

Joan

 

I would like to explain an enhancement suggestion for TMG to improve the handling of places with more than one name.

 

This involves a slight change in the way places are recorded.

 

It mirrors the suggestion above of creating a "pseudo-person" for a place so I have decided to repeat it here for comment.

 

(1) The basic concept is that a place has a "primary place name", just like Person Names.

 

(2) Each event records the place name given in the source, just like a "Name-Var".

 

(3) Each new unique place entry is initially made primary. (see next step)

 

(4) But the user may make it non-primary by assigning it to be the equivalent of a previously entered other primary place name.

 

Consequences of this suggestion:

=====================

a. There is still one line in the Master Place List per Place Name entry.

 

b. Some entries in the Master Place List are _primary_ others are _non-primary_, that is there would be an extra column in the Master Place List to show this.

 

c. At the Event tag entry screen, there could be an extra step or button, where the user identified which was to primary place entry equivalent to this place entry.

 

d. In a report or chart, the user could have the choice of either outputting the event place name for that event or the primary place name for that event.

 

e. Filters for the Picklists, Project Explorer and Reports could have extra expressions that allowed for searching for tags that had a common _primary_ place name, even though they actually had different recorded place entries.

 

f. If a user did not want to use this suggested additional feature, TMG would act exactly as it does now. All entries in the Master Place List would be considered primary.

[GenerationGoneBy 0]

It mirrors the suggestion above of creating a "pseudo-person" for a place so I have decided to repeat it here for comment.

 

(1) The basic concept is that a place has a "primary place name", just like Person Names.

 

(2) Each event records the place name given in the source, just like a "Name-Var".

 

(3) Each new unique place entry is initially made primary. (see next step)

 

(4) But the user may make it non-primary by assigning it to be the equivalent of a previously entered other primary place name.

 

Consequences of this suggestion:

=====================

a. There is still one line in the Master Place List per Place Name entry.

 

b. Some entries in the Master Place List are _primary_ others are _non-primary_, that is there would be an extra column in the Master Place List to show this.

 

c. At the Event tag entry screen, there could be an extra step or button, where the user identified which was to primary place entry equivalent to this place entry.

 

d. In a report or chart, the user could have the choice of either outputting the event place name for that event or the primary place name for that event.

 

e. Filters for the Picklists, Project Explorer and Reports could have extra expressions that allowed for searching for tags that had a common _primary_ place name, even though they actually had different recorded place entries.

 

f. If a user did not want to use this suggested additional feature, TMG would act exactly as it does now. All entries in the Master Place List would be considered primary.

 

Robin,

 

I love it! How would we (assuming this were a feature and not a suggestion) change our current places to use these new features? It would work exactly like the current names for a person I am assuming where there would be a box where I could select which "name" of the place I wanted for this tag.

 

We all struggle with how to handle this issue. I just add a new place and move on. But I also live in an area, where place names haven't changed names all that much since people first started living there a few hundred years ago.

[efcharvet 0]

a. There is still one line in the Master Place List per Place Name entry.

 

b. Some entries in the Master Place List are _primary_ others are _non-primary_, that is there would be an extra column in the Master Place List to show this.

 

c. At the Event tag entry screen, there could be an extra step or button, where the user identified which was to primary place entry equivalent to this place entry.

 

d. In a report or chart, the user could have the choice of either outputting the event place name for that event or the primary place name for that event.

 

e. Filters for the Picklists, Project Explorer and Reports could have extra expressions that allowed for searching for tags that had a common _primary_ place name, even though they actually had different recorded place entries.

 

f. If a user did not want to use this suggested additional feature, TMG would act exactly as it does now. All entries in the Master Place List would be considered primary.

 

Handling place names is such a big, painful issue. - - Frankly, I don't know if it is possible to get around entering Memo Tags into narrative reports such as this, "Châteaufort, Kingdom of Sardinia is now Motz, France" or "Plainview, Washington Territory is now Moscow, Idaho." And, that is OK by me.

 

However, generating any kind of meaningful statistical reports that includes places in the sort variables are useless in TMG without using speadsheets. Robin, your suggestion attempts to addresses this.

 

Unfortunately, I don't really understand how your "Primary Place Name" LINKS to the "Non-Primary Place Names" in steps a. and c. without identifying BOTH places per event. Is this handled in two screens in your step c.? (A "button" to designate "Primary" or "Non-Primary" place would not do it.)

 

Please go into a little more detail.

 

Thanks, Earl -

[RobinL 0]

Robin,

 

I love it! How would we (assuming this were a feature and not a suggestion) change our current places to use these new features? It would work exactly like the current names for a person I am assuming where there would be a box where I could select which "name" of the place I wanted for this tag.

 

We all struggle with how to handle this issue. I just add a new place and move on. But I also live in an area, where place names haven't changed names all that much since people first started living there a few hundred years ago.

 

Teresa and Joan,

 

Thank you for the encouragement.

 

My take on the use of this suggestion is as follows. If this was a feature that was added to TMG then

 

A. For existing tags, all the existing places would be primary. And the desire is to associate these places where appropriate into groups of equivalents within each group one entry remains primary. I see that this could be done in either or both of two places - the Master Place List itself but that has some data corruption dangers or from within the individual Tag Edit Screen (TES).

 

B. For new Tag Entry, this would the same as the Tag Edit screen above.

 

 

Master Place List - 3 extra buttons here - something like

 

i. Select a place entry X that is already marked primary and click [bookmark Place] button to save this entry for a subsequent operation.

 

ii. Once there is a boomarked place, then select another place entry Y and click [Equivalent Place] button. This later action records place entry X as the primary place entry of Y (thus removing the primary status of Y being itself). If Y is primary and it has equivalent non-primary place entries associated with it, then all of the equivalent place entries also have their primary entry changed from Y to be X.

 

iii. Select a non-primary Z and click [Make Primary] to revert this entry to be no longer be part of an equivalence group and make it primary in its own right.

 

Tag Entry Screen - one extra button here

 

I can't find a short name for this. But I will use [Associated Place...] button. Clicking the [Associated Place...] button opens a screen that is like a filtered version of the Master Place List - I will call it the Place Association screen. If your focus in the Tag Entry Screen was in a particular field then that the value in that field would be used filter to list presented to you. A check box on the Place Association screen would allow you reduce the number of lines by only showing Primary place entries in this list. Select an entry and click the [Equivalent Place] button. The Place Association screen would close setting the TES current place entry as non-primary and the one selected in the Place Assocition screen as the Primary place of this entry. Obviously, I have not discussed the need for [Cancel] in the Place Association screen and [Make Place Primary] on the TES.

 

With the above tools, it is up to the user to migrate their use of places over time. May be if this was a real feature of TMG (not this hypothetical discussion) one could convince John Cardinal to add a suitable feature to the TMG Utility to do some bulk change - this might be difficult for the user to specify and could be more dangerous than it is worth.

 

I have not thought too much about what extra is needed in reports and filters to take advantage of this concept.

[joanmc 0]

Better and better Robin! Imagine the marketing point this could be for TMG......and imagine what an improvement for the accuracy of our data/reports.

 

I have no idea how difficult this would be to program but I believe it would be well worth the effort for a version 7.x add-on! Hope you're following this innovative thread Bob

 

Joan

 

Teresa and Joan,

 

Thank you for the encouragement.

 

My take on the use of this suggestion is as follows. If this was a feature that was added to TMG then

 

A. For existing tags, all the existing places would be primary. And the desire is to associate these places where appropriate into groups of equivalents within each group one entry remains primary. I see that this could be done in either or both of two places - the Master Place List itself but that has some data corruption dangers or from within the individual Tag Edit Screen (TES).

 

B. For new Tag Entry, this would the same as the Tag Edit screen above.

Master Place List - 3 extra buttons here - something like

 

i. Select a place entry X that is already marked primary and click [bookmark Place] button to save this entry for a subsequent operation.

 

ii. Once there is a boomarked place, then select another place entry Y and click [Equivalent Place] button. This later action records place entry X as the primary place entry of Y (thus removing the primary status of Y being itself). If Y is primary and it has equivalent non-primary place entries associated with it, then all of the equivalent place entries also have their primary entry changed from Y to be X.

 

iii. Select a non-primary Z and click [Make Primary] to revert this entry to be no longer be part of an equivalence group and make it primary in its own right.

 

Tag Entry Screen - one extra button here

 

I can't find a short name for this. But I will use [Associated Place...] button. Clicking the [Associated Place...] button opens a screen that is like a filtered version of the Master Place List - I will call it the Place Association screen. If your focus in the Tag Entry Screen was in a particular field then that the value in that field would be used filter to list presented to you. A check box on the Place Association screen would allow you reduce the number of lines by only showing Primary place entries in this list. Select an entry and click the [Equivalent Place] button. The Place Association screen would close setting the TES current place entry as non-primary and the one selected in the Place Assocition screen as the Primary place of this entry. Obviously, I have not discussed the need for [Cancel] in the Place Association screen and [Make Place Primary] on the TES.

 

With the above tools, it is up to the user to migrate their use of places over time. May be if this was a real feature of TMG (not this hypothetical discussion) one could convince John Cardinal to add a suitable feature to the TMG Utility to do some bulk change - this might be difficult for the user to specify and could be more dangerous than it is worth.

 

I have not thought too much about what extra is needed in reports and filters to take advantage of this concept.