British Colonial America VS. United States
Question I have always wonder why is. . . Why is the date field not looked at for location availability?
Example: I enter the birthdate of June 1980. Location of Maryland, United States. Why would "Maryland, British Colonial America" even be one of the place options to choose?
Same question in reverse. If I enter birth of 1700n location Maryland. Why would United States be an option? There was no United States before 1776?
The system displays dates for locations. Why give users the options to choose the wrong location?
Same thing for England. United Kingdom did not exist before 1802. But if I put a date of 1700 England. The option for United Kingdom is still present.
Answers
-
I suppose the answer is that the Family Tree place names gazetteer is still very much a work in progress?
Also, in cataloging projects generally it is better for rules to be too relaxed rather than too rigid.
0 -
Also, I saw today that the dates given for 'British Colonial America' end in 1981--assuming that an entity with that name might be legitimate--and I'm aware of LegacyUser's 2020 assertion that it's not--how can it possibly run through 1981?
0 -
Integrating location standardization and dates would be a technical nightmare, especially if you're expecting something like the location field to update dynamically based on the current date entered.
1 -
I work with a lot of historical records in Canada, and I use British Colonial America for dates before 1867, other standard place names for dates after. Usually. The gazetteer is not complete, and has some gaps in Canada, so sometimes I need to make a choice between no standard and a slightly incorrect standard.
The end date 1981 on the standard place name British Colonial America reflects the British Nationality Act, explained here:
FamilySearch Places gazetteer does not explain this, so a request on the gazetteer to add an explanation (or link to this Wikipedia page) may be in order. The gazetteer page for British Colonial America is here:
1 -
No where in all my years of school in Canada was this country ever referred to as British Colonial America. Upper Canada, Canada West, and then Quebec and Ontario etc. So why is Family Search trying to change Canada's history??? Check our government history...that term is not there. It is only used for America. I resist deeply at having our Canadian culture abducted like that.
1 -
Building in date vs location would be, as RTorchia indicated, a major technical nightmare. Just keeping track of countries world wide is a mess. But records go down to state / province, county, districts and towns, etc, and the boundaries did a lot of warbling around. They still do. Many people want location to go down to church cemetery level. Also, places that used to exist have disappeared. LOTS of them. Unknowing users would be frustrated having to select an option they don't like which appears to give the wrong information.
And within this thread there is not even consensus on the location information of Canada and the US. I rest my case.
I would like to address two questions of the original post. Why give clearly bad options for location in the drop down list, such as United States for a 1700 record, or British Colonial America for a 1980 record. First, think about the programming required to support that. How long is acceptably long for the display to appear when you are waiting for a drop down list of locations filtered by time and place? As any IT person can agree, millions of people waiting for a drop down list at the same time has the potential to cause everyone to experience a slow down. Second, is there academic agreement on all these location names? I doubt it.
1 -
Presumably the term "British North America" would be no more acceptable to you. Yet both terms appear to be of common use among historians, as the collective name(s) of the British colonies in the area at that period, even though they did not teach you about this in school.
I think the problem lies in the term "America" being usually applied to just the United States. If this were not the case, perhaps you, and no doubt others, would not get upset about this issue. We have a similar thing here in England, where a minority of individuals refuse to acknowledge they are "British" and insist they are (merely) "English". Perhaps, similarly (but for different reasons), you don't regard yourself as "North American" - just "Canadian".
(See https://en.wikipedia.org/wiki/Canada - "Following three constitutional conferences, the British North America Act, 1867 officially proclaimed Canadian Confederation on July 1, 1867.")
2 -
So far as I can remember when I looked into this, British Colonial America, as a name, is a complete fabrication by FamilySearch. It covers basically anything on the lefthand side of the Atlantic (and in the middle) that was once red on the map, so it included (when I last looked) all sorts of islands. The end date of BCA refers to some change in the status of the last of those possessions / territories / whatever.
I found no references at all in Google to BCA before FamilySearch invented it.
British North America, so far as I recall, was a description used to refer to "Canada" (plus or minus various bits) - I don't think it was ever the name of a jurisdiction in its own right but at least, as @Paul W indicates, it was a contemporary term.
As for date filtering, I find it difficult to believe that it would take any material amount of time - not when you compare it to all the other processing to create the User Interface. However, the percentage of names that are dated is, I have been told, still seriously low, meaning it wouldn't be useful code a lot of the time. Secondly, some of the actual dates are nonsensical (e.g. Germany did not exist as a state before 1871) so if I wanted to choose another name with a different date, I'd like to be able to do so.
0 -
@Adrian Bruce1 Your example of Germany is exactly the kind of thing I said would be very difficult to program in. I'm not sure what you thought we were talking about when the suggestion of making in appropriate names unavailable with certain dates, but the whole Germany evolution for the past hundreds of years would be programmed in, and down to the town level. Along with the rest of Europe as well as Africa, China, Latin America, the Middle East, Western Asia, etc. NOW do you think that location filtering by date would be an inconsequential load on the system?
1 -
@Gail Swihart Watson - "Germany" is pointless to program by date when the dates are wrong! 🙂
Sorry, but I don't see how date filtering requires anything more than a trivial increase on the current workload. If I want to standardise "Nantwich" now, I get offered seven variations on Nantwich. Every single one of them has a date range that is already available to the User Interface because it's shown in the dropdown list right now. That drop-down needs to be filtered further by date. If my event has a date of 1890 (say), then 1890 would be checked against just the 7 date ranges already present. The entry with "1801 - present" is accepted into the (filtered) dropdown because 1890 is between those 2 dates. The entry with "980 - 1801" is rejected from the (filtered) dropdown because 1890 isn't between those 2 dates. Etc, etc.
That's all the processing that's needed - look at the dates that are already in that dropdown and filter on those. I am not suggesting doing anything with displaying places, only when place names are being updated, as per the OP's request.
There are a whole host of assumptions (some of which I've already mentioned):
- The placename entries need to have a big enough percentage of them dated to make it worthwhile (possibly not true yet);
- The dates need to be sensible (Germany? Hmmm);
- Nobody should have a legitimate reason for choosing out-of-date range place-names (for instance, I used to choose names ending in "England" for post-1801 dates, when I should have chosen "England, United Kingdom" names. I had no legitimate reason for it - I was just being awkward. But am I convinced that all the data is in place to remove such a need? No...);
- There's also the assumption that I input the date of the event before the name - otherwise, I just get the current list. And if I later amend the date to one incompatible with my chosen place name - well tough on me;
- No doubt there are others...
So I'm highly dubious that it's possible at the moment. But the evolution isn't something to program in - it's already on the file. Or not, as the case may be... The software just needs to work with those year ranges already in the drop-down. So sorry - for my part, I don't understand why it's supposedly looking at a massive amount of data, when it only needs to look at the drop-down that's already there.
0 -
Adrian Bruce1 I think you picked a location that is extremely well documented and has a nice drop down list. and I'm glad YOU can use that to make the right choice. That is NOT the case in all locations. Here are 3 screen shots of completely ridiculous location choices in the drop down lists. Many are even historically stupid. These prove that the person making this suggestion knows this too.
First, Picuris Pueblo (Native Americans in what is now New Mexico, USA) established in 1706? No. They were there for centuries earlier. By the way, that date represents a point in Spanish history, not Native history or British history. Then, look at the errors here. United States didn't exist in 1706. Heck, the Brits didn't even claim this territory in 1706, Spain did. NONE of these choices make any logical sense. How does one know to make the correct choice for a marriage in 1783?
Next: Location one of my German ancestors married in 1710. No nice date range in this drop down list. I guess Empire is correct since that word sounds old. Is that correct? Was there a German Empire or were there duchies? I don't know German history to this level, and this drop down list is not helping.
Finally: Woodford County was part of Virginia until 1 June 1792 when Kentucky was formed. If I search on Woodford, not appending any other information, Woodford, Virginia, United States does not appear AT ALL. Repeat, the correct choice doesn't even appear. See second screen shot down. A long list is in the drop downs as Woodford appears to be a name used all over the world, but as you can see Virginia is not one of them. I have to KNOW the correct location is Woodford, Virginia, United States.
So reviewing your statements, "Nobody should have a legitimate reason for choosing out-of-date range place-names" and "But the evolution isn't something to program in - it's already on the file." are not correct. A considerable amount of historic research is going to have to be done and put in a database to make these lists correct, and even more to support a "smart" filter that correctly lists by date.
2 -
"I think you picked a location that is extremely well documented and has a nice drop-down list."
That's just a typical one of my ancestral towns, @Gail Swihart Watson , and so far as I can see, it's reasonably representative of other towns in England & Wales. Equally, I presume that your examples were taken from your own research so you clearly have ample justification for your concerns.
I did say that my assumptions for doing date-filtering included:
"The placename entries need to have a big enough percentage of them dated to make it worthwhile (possibly not true yet);"
Note my "possibly not true yet". You've demonstrated that we are a long way from having a placename database with enough accurately dated entries to make date filtering viable. That's fine - I'm happy to take that as a sensible verdict because you've shown that my assumption simply doesn't work out. Therefore, although it might not seem like it, we are actually in agreement: "A considerable amount of historic research is going to have to be done and put in a database to make these lists correct". Happy to agree with that conclusion - until we have that data in the Standard Placenames database, date filtering just isn't viable.
0 -
@Adrian Bruce1 Yes, all of my examples were from family. The German example my ancestor, the KY vs VA is that of an in-law and the Native American / Spanish ancestry an adopted relative.
An yes, we are now in agreement. But, even with a perfect database, I still believe that date crunching would be problematic for system performance.
0 -
This is a created problem. If we simply used the current geographical location, we could more easily pinpoint it on a map and more easily determine where records were kept. It is preposterous for a cemetery in Quebec, for example, which has not moved in centuries, to have multiple options for place names. It is also unreasonable to expect a "gazeteer" to accurately reflect 2 centuries of German political geography, let alone 1200 years.
0 -
@EvFinStephen People who use current place names can have sources that seem incorrect, and might be removed by someone unknowing. Also it will seem that sources don't exist for time prior to the current place name's existence.
For example, I came upon marriage with a standardized place name of Kentucky, yet when I looked at the document, the marriage record was issued by the Commonwealth of Virginia, so I changed the place from Kentucky to Virginia and added a comment that this location later became Kentucky.
I agree place names can be a messy and nasty problem. There are times in which I absolutely use the current day location, for several reasons, NONE of which relate to seeing the location on a map. First example is for a historic location in Ukraine established by the Russian Empire in the early 1800s, was later renamed by the Soviets before or during WW II, and is now part of Ukraine. I actually don't know the complete historic name for that, provinces being more the question. So I use the current place name.
2nd example is a different place in Europe, and your German example fits in but for a different reason. Something not typically understood by people in the US, Europeans have, and always have had, a sense of ethnic identity over political identity when the two were in conflict, and this can give you hints about the political map at the time the record was created. A brother in law has a Polish ancestor who claimed to be born in "Polen, Germany." My BIL laughed at that, but to me it spoke volumes, and the date of the birth turned out to be a time when Poland didn't exist (1860). It was all Prussia, a German kingdom (according to Google). I am using the modern day place name of Poland for his birth, not to pinpoint it on a map, but to preserve the ethnic identity he clearly felt. He was not German, he was Polish.
So please don't treat place name problems as simple and that we are making up these issues. Not true.
2 -
@Gail Swihart Watson - you might want to add some notes to the Polish chap's birth and residences. Poland was actually split three ways in the latter part of the 1700s - between Prussia, Russia and Austria.
See https://en.wikipedia.org/wiki/Partitions_of_Poland but be aware that my previous sentence is just the beginning.
2 -
@EvFinStephen, I disagree vehemently with the use of modern placenames. That's what causes my grandfather's birthplace to be essentially fictional on another genealogy site: that political entity didn't exist until thirty years after his death, so he couldn't possibly have been born there without access to a TARDIS or other time machine.
The other consideration with modern placenames is that they change. Administrations get re-arranged, places get combined or separated, borders get moved. When France or Norway re-does its county structure, is everyone on the globe with French or Norwegian ancestors supposed to go through and edit their trees to reflect the new modern jurisdictions?
The genealogical standard is to identify places as they were known at the time of the event. FamilySearch's structure allows for this do be done accurately and precisely even when the database is incomplete and imprecise. We should use it, and make suggestions for additions and corrections to the database as needed.
4 -
@Julia Szent-Györgyi
Rest assured, I follow the standard. Your vehemence, however, does not minimize the confusion and conflict enabled by the current system. How many times do we see changes and edit wars with little speeches by geography police that go something like this: "The United States did not exist yet!" as if everyone did not know that already? And even if France reorganized its internal borders frequently, which it does not, Lille and Dampierre en Burly are not difficult to find. Your French example does not answer the problems faced by those searching in places like Germany with shifting political borders or places with borders that were not clearly defined. I know someone pulling their hair out trying to deal with places in early Utah. Look at Meisenheim and try to make a chart for the entire period covering 1780 to 1880. Is it reasonable to expect people within FamilySearch to get all that right? If an area was effectively controlled by one country but there is a question of rightful ownership, would it not be nice to be able to avoid hard feelings about it?
[P.S. Your contributions here help make this discussion section worth reading.]
0 -
Having an event date used as a filter for places names sounds like a very intriguing idea and could be very useful in a couple of decades when the Places database is closer to completion. It would certainly need to be possible to override it, but it really could help people pick out appropriate place names.
One of the great potentials of Family Tree as people gradually get used to working together as the current generation of genealogists die off and the new one which will have never used anything but Family Tree takes over is that it can be a site where everyone does not need to research everything from scratch but accept well documented prior research and build on it. Place names are a good example of that. While it may be difficult to comprehend that we can "expect a 'gazeteer' to accurately reflect 2 centuries of German political geography, let alone 1200 years," that is exactly the goal, within reasonable bounds, of the Places database. This will be accomplished by a small number of people researching once what a place name should be through time and documenting it once in the Places database that research.
In regards to using place names to find records, having all those historical periods in the Places database and recording events using the name at the time of the event is the quickest way to find those records.
To take a rather simple example, if I find a relative was born 1840 with a recorded using the current name for his birth place of Molve, Ullensvang, Vestland, Norway, and can see it right there on the map, when I start looking for records, I'll find nothing in Vestland. So I have to figure out that Vestland used to be Hordaland. Then searching in Ullensvang, Hordaland, I can't find anything. That's because before 2019, Molve was in Jondal. So search next in Jondal, still nothing. Because before 1863, Molve was in Strandebarm.
If the place name had been recorded as Molve, Strandebarm, Hordaland, Norway, I could of gone right to the proper spot for records instead of repeating the place name research that hundreds of people have done before me.
2 -
Just for those of you with a German interest, I have previously mentioned this to the Placenames team but there is an excellent Historical Gazetteer for Germany on http://gov.genealogy.net/search/index - indeed, it attempts to go further but I don't know how comprehensive its coverage outside Germany is.
To illustrate some of the complexity, look at http://gov.genealogy.net/item/show/JEVVERJO33WN which shows the various units that the town of Jever sat underneath. This satisfies my pedantry by showing the top units as the Holy Roman Empire, German Confederation (1814-66), the North German Confederation (1867-70), the Deutsches Reich 1871 onwards. (Empire is not a good translation of Reich, I am told).
Yes, it is complex and it may be that even this still has gaps. And oddities...
0 -
Speaking from a generalized tech standpoint, the suggestion sounds like a tricky endeavor.
The Date and Place fields are each dynamic and busy places.
Independently, each has a lot of variables for coders to try to anticipate. Users can and do enter anything at all. There are many browsers (+plugins), each ever-changing. There are also the mobile apps that bring their own considerations.
Getting one dynamically adjusting field to automatically adjust to another dynamically adjusting field sounds like playing pufferfish-catch between two cliffs - each having their own earthquake. Not saying it can't be done but it may require more than us wanting the coders to Nerd Harder.
0 -
To anyone who cares, those place names with dates attached are FANTASTIC.
Polish town names (or Galacian or Prussian or Czech or Hungarian or Ottoman or x20) might apply to 5 towns today and an unknown number of towns in my target date. Add to that the ever shifting voivodeship, counties, commonwealths, kingdoms, powiat and a dozen other delimiters, it can be fairly brutal to figure out where BadlyMispelledTown, Poland actually was in 1893. FS's dates+names often ease that burden.
0
