"Wasn't called that" is patently false

Julia Szent-Györgyi

For events in Vienna, I've long given up on the timespans and jurisdictions and just enter it as "Vienna, Austria". So, of course, the algorithm complains about it.

This is patently false: it is not much of an exaggeration to say that it has been called exactly that since time immemorial. A random poke through Google Books yielded one from 1744 naming the city Vienna in English.

(English apparently got it from Italian.)

This message desperately needs re-wording, because as it currently stands, it states ridiculous falsehoods left and right.

Gordon Collett

How is this for rephrasing things:

For the date of birth, 6 September 1855, the current corresponding place standard is Vienna, Lower Austria, Austria, which conflicts with the profile's place standard of Vienna, Austria. If a different standard is needed for the time period, please request an edit to the Places database.

At least this points out that the flag is not looking at just the first part of the place name but the entire place name.

But maybe there is no way to take the folder for the place and find one particular date range in it. That is, maybe they can only say the time period doesn't match but cannot determine what the place name for that time period is.

This is another example of how the quality checker is checking the quality, not just of the profile, but of FamilySearch's databases. I'm not all that informed about Austrian history, but I somehow kind of doubt that Vienna was called Vienna, Lower Austria, Austria from its founding until 1920. Checking Lower Austria I do see that it has a starting date of 1458 so maybe for the purposes of genealogy supported by sources not having a standard for Vienna prior to 1458 isn't really an issue.

Julia Szent-Györgyi

I'm inconsistent in my treatment of large cities: for Budapest, I pay attention to the unification date (1873) and the reorganization that put it outside the county structure (1950), but for Vienna, I don't bother to keep track of which crown land it was in or when they made it independent. I figure the city has been Vienna since forever and the country has been Austria since nearly forever, so "Vienna, Austria" is accurate enough for the entire genealogical timeframe.

I'm not sure the algorithm can (or should) identify a "more correct" timeframe-standard: there are too many ways that that could go wrong (starting with, what if there isn't one in the database?).

I think that if a message is trying to tell you that the dates don't match, then it should say that it's the dates that don't match. It shouldn't instead make ridiculous claims about the name. Maybe something like:

The date of birth, 6 September 1855, does not match the time period of the chosen standardized place of Vienna, Austria, which has a start date of 1920.

It would be more accurate to call it the "chosen jurisdiction" or some such, but people wouldn't know what it was talking about. "Standardized place" is how it's labeled on profiles, so that's what the message needs to use. I'm likewise hesitant to make the message even longer by changing the ending phrase to something like "which currently has a start date of 1920 in the Places database". This would emphasize that the mismatch may not be the user's fault, and if the word "Places" were a link to the tool (even if just to the landing page rather than to the specific entry), that would suggest other ways to fix it, but the increased length of the message may be a problem (especially if the chosen standard is one of those ultra-long ones, like many places in Germany).

Gordon Collett

I agree that having the message start out talking about a date then jumping to a place is a big part of the confusion. The other part is that in all the complaints that have been posted about the message, the focus has been on just the part of the name of the place before the first comma when the message is actually about the entire two to five part place name.

How about this slight editing of your version:

The date of birth, 6 September 1855, does not fall within the time period of the chosen standardized place of Vienna, Austria, which has a start date of 1920.

This avoids any implication that either the date or the place name is wrong in any way and just stresses why the date and place don't match.

I ran across one of these mismatch flags yesterday that was triggered by the fact that the city of Bergen, Norway was known as Bergen, Hordaland, Norway, from 1070 to 1837 but there was also the municipality of Bergen, Hordaland, Norway, from 1972 to 2019 (which was much larger geographically than the city itself and contained many villages and a couple of hundred farms) and I had managed to put in the wrong standardized version a few years ago when the drop down menu did not show the time intervals. I was happy to see the flag and get this corrected. But then I can get a bit pedantic at times.

Gordon Collett

@roberthparker3 I assume someone is already following this issue and working on it, but does the design team have any thoughts about improving this quality flag that appears to be causing so much confusion?

To summarize the two items that seem to be repeatedly causing confusion in flags such as:

The DATE of birth, 6 September 1855, is in conflict with the standardized PLACE of Vienna, Austria, which has only been called that since 1920.

are that:

1) It is jarring and confusing to read that a date conflicts with a place instead of conflicting with another date.

2) People seem to stop reading at the first comma in the place name, skip over the rest of it, then don't understand that usually this is not a problem with the name of the place but with the associated parent of the place to use Places database terminology.

Julia Szent-Györgyi

For "Vienna, Austria", the message as currently phrased is false even if you don't stop at the comma. It was very much called exactly "Vienna, Austria", by everyone, centuries before 1920.

The only cases where the current message will not be false are places like Bratislava, which really wasn't called that before 1919 — and even when the different time period does involve a new name, if it's not the name of the place itself, then the current wording will still be untrue, because higher jurisdictions are not part of what a place is called. They're just part of the administrative structure. Boston was called Boston completely independently of what the country was called.

monnettohio

Part of the issue is how the geographical authority area at Family Search enters its information. While trying to be accurate in its cataloging all of the names for a place, I don't believe their system allows for an Also Known As. I know that dealing with them has been very frustrating for me while trying to get place names in Marion County Ohio corrected. They will accept an unreviewed book take prescidence over the county's engineering department.

Gordon Collett

That document is exactly why the message is confusing everyone. That is, the difference between what a place was named or called that may never have changed and the full place description in which the higher levels of the description may have changed many times.

In your particular example, writing Viennæ, Austriæ, in any publication at any time was never wrong, just an incomplete description. But that is just general practice. When was the last time you ever saw in print anything other than New Orleans, Louisiana, or even just New Orleans. I'm pretty sure anyone you ask would know immediately what place was referred to and not have any idea, or care, what parish it is in.

This whole topic could quickly turn into a rehashing of why place names are important at all and why shouldn't one just toss on the modern name and leave it at that.

Gordon Collett

The Also Known As should be covered by the long list of variant names a place can have. As long as the variant is in the list, it should be easy to have the variant as the display name and link it to the default standard.

Julia Szent-Györgyi

(The -æ at the ends is Latin grammar; it essentially means "of".)

Back to FS: the Places database does have provision for alternate names. For example, I just got a reply about a suggestion I made for two other names for a village that's now in Slovakia (https://www.familysearch.org/research/places/?focusedId=12770604). Technically, each name should have a specific timespan (up to 1899 Szklabonya, 1899-1910 Kürtabony, 1910-1920 Mikszáthfalva, 1920-present Sklabiná), but given that it took two rounds just to get Kürtabony correctly labeled as Hungarian, not Slovak, and given that only the last timespan involves any change to the higher jurisdictions, I'm choosing my battles and leaving it be as is. A pleasing side effect of this is that the "quality" algorithm will be less likely to make unnecessary (and untrue) complaints.

Gordon Collett

Another attempt at rewording the flag:

The date of birth, 6 September 1855, does not fall within the time period for the entered standardized full geographical description: "Vienna, Austria," which has a start date of 1920.

(Julia, have you ever considered volunteering with the Places Authority team as a database editor for Hungary? I'm sure they can use more than they have, which from your report is probably none. All it takes is a willingness to follow the guidelines: https://www.familysearch.org/en/fieldops/familysearch-places-principles-guidelines#historical-periods , the recommendations for each country: https://www.familysearch.org/en/fieldops/fs-places-familysearch-places-country-specific-guidelines#europe (The second listing for Hungary is actually for Iceland. Something got missing in the proofreading.) and a good understanding of the country.)

Julia Szent-Györgyi

Gordon, I did volunteer for a while, but that was six years and two computers ago on my end, and who knows how many revisions of the system ago on FS's end. And then Life happened and I don't even know when I lost editing access. Somehow, I keep finding plenty to occupy my time, but thank you for the links. Perhaps it's time to get off my duff again.

roberthparker3

This has been a very educational conversation. Thank you all!

Here are proposed english sentence templates for the three cases:

• The date of {conclusionType}, {conclusionNormalizedDate}, does not fall within the time period of the chosen standardized place of {placeNormalized}, which has a start date of {placeNormalizedFromYear} and an end date of {placeNormalizedToYear}.
• The date of {conclusionType}, {conclusionNormalizedDate}, does not fall within the time period of the chosen standardized place of {placeNormalized}, which has an end date of {placeNormalizedToYear}.
• The date of {conclusionType}, {conclusionNormalizedDate}, does not fall within the time period of the chosen standardized place of {placeNormalized}, which has a start date of {placeNormalizedFromYear}.

Let me know if this is an improvement.

Julia Szent-Györgyi

@roberthparker3, I'm unable to come up with a use case for the first one, but the other two sound good to me.

(I mean, I can sit here and quibble about every word choice — "associated" instead of "chosen", maybe? — but, ah, diminishing returns ….)

Gordon Collett

Definitely an improvement. They point out better that it is a time period problem rather than a name problem and removed the "not called" which triggered the response "yes, it was."

It would be good to find some way to get people to focus on the last half of the standard since that is usually where the problem is. From what I have seen, it is quite rare to have a change in the first word in a place's group of standards. All I can think of is putting the standard in quotes to show that it is a single unit.

For a specific example of how these flags would look, I'll use the farm of Dalehagen which has the following four time periods and so makes it possible to use one date and make all three standardizing errors:

• Dalehagen, Haus, Hordaland, Norway - Uknown to 1869
• Dalehagen, Bruvik, Hordaland, Norway - 1870 to 1963
• Dalehagen, Vaksdal, Hordaland, Norway - 1963 to 2019
• Dalehagen, Vaksdal, Vestland, Norway - 2020 to Today

If I take the date 27 July 1880, I can standardize the place incorrectly three different ways, generating all three types of error flags:

• The date of birth, 27 July 1880, does not fall within the time period of the chosen standardized place of Dalehagen, Vaksdal, Hordaland, Norway, which has a start date of 1963 and an end date of 2019.
• The date of birth, 27 July 1880, does not fall within the time period of the chosen standardized place of Dalehagen, Haus, Hordaland, Norway, which has an end date of 1869.
• The date of birth, 27 July 1880, does not fall within the time period of the chosen standardized place of Dalehagen, Vaksdal, Vestland, Norway, which has a start date of 2020.

I think I would remember more quickly what these statements actually mean when I run across them than have to think for a bit as I do every time I see the current ones.

Julia Szent-Györgyi

OK, so the first one is for time periods that have both a start and end date? But I really don't see a reason for listing both endpoints. The third message type would work equally well, as it's only the start date that's relevant to this particular mismatch.

• The date of birth, 27 July 1880, does not fall within the time period of the chosen standardized place of Dalehagen, Vaksdal, Hordaland, Norway, which has a start date of 1963.

I was thinking the same thing re: putting the full label in quotes, to encourage seeing it as a unit.

• The date of birth, 27 July 1880, does not fall within the time period of the chosen standardized place of "Dalehagen, Vaksdal, Hordaland, Norway", which has a start date of 1963.

(Punctuation style question: comma first or closing quote first? I believe the former is US while the latter is UK, and FS generally follows US conventions, but this particular one is illogical….)

Gordon Collett

So Julia, you are thinking it best to keep things simple by having only one date such as:

• The date of birth, 27 July 1880, does not fall within the time period of the chosen standardized place of "Dalehagen, Vaksdal, Hordaland, Norway," which has a start date of 1963.
• The date of birth, 14 August 2023, does not fall within the time period of the chosen standardized place of "Dalehagen, Vaksdal, Hordaland, Norway," which has an end date of 2019.

Those do explain the situation fully and eliminating the check for being between two dates might even make the programming simpler. But I kind of like reinforcing the notion that a standard can have a start and an end by listing both of them.

I do think the quotes. help.

Yes, in the US a comma or period always goes inside the quote. Question marks and exclamation points go inside the quote if they are part of the material being quoted but outside the quote if they are part of the statement that happens to include the quote. (I heard him ask "Are you going to the store?" vs. What do you mean "I am going to the store"?)

roberthparker3

Can I please get your reactions to this -

place-date-mismatch.png

What parts are improvements? What parts are more confusing that what is currently on the website?

Julia Szent-Györgyi

@roberthparker3, that's back to conflating dates and names and thereby possibly claiming utter nonsense (at best), such as Vienna, Austria being "not known by that name" at any date in the genealogical timeframe.

As I said somewhere above, if the conflict is with the dates, don't talk about the name.

Gordon Collett

I really like the list of possible solutions. However, I would change two things. First, just remove the "Do nothing" suggestion because you will immediately have people raging "THEN HOW DO I GET RID OF THIS NOTICE!!!" If they really don't want to do anything, then they will want to dismiss the issue. I don't think many will be content to just accept there is a conflict and leave it at that.

Also, I would change "Choose a different standard place" to "Choose a different time span for the standard place" since there is nothing wrong with the place and no one will want to choose a different one. And as per my suggestion posted previously at

https://community.familysearch.org/discussion/170436/we-need-full-place-information

let people see the time spans for the current pick in at least the data view pop up or in both the data view pop up and the editing pop up.

I kind of like the new version but agree that it has to be pointed out that it is a time and comprehensive nomenclature issue not a problem with the name of the place itself.

How about:

The standard "Dalehagen, Vaksdal, Hordaland, Norway" is used for 1963 to 2019. This conflicts with the birthdate of 27 July 1880.

Just about as short as your new version. A bland statement of "this is used" without any judgement of rightness or wrongness of the place name and a clear indication of why a different standard for the same name should be used.

Gordon Collett

One more addition that could be really helpful:

The standard "Dalehagen, Vaksdal, Hordaland, Norway" (ID: 11135213) is used for 1964 to 2019. This conflicts with the birthdate of 27 July 1880.

with the ID number being a live link to the Places database. Or even have the full name be a link to its entry in the database. Then people can click right there, jump to the database, and see all the time period options with their accompanying standards for that single place. While there, they can even click the ID number of an alternate time span to copy it then paste the ID number in place name editing box and be guaranteed they have the right time span standard.

Such would really help the user who has been complaining about an incorrect flag on her use of Mason, Virginia, United States. She hasn't provided enough information to help her, but I'm pretty sure the problem is that she is using the Mason county that ended up in Kentucky rather than the Mason county that ended up in West Virginia and those two have different time spans.

This would also help people who do not realize that the only way to get the right standard would be to completely erase the Vaksdal so that all four version of the place appear in the dropdown menu.