How to enter burials at sea? Data issue warning: Standardized burial place missing
I live in coastal area and have several family members who wished to have a funeral in the Baltic Sea.
That means, take the urn on a boat, go a few miles out to a certain area reserved for this, make the funeral and let the urn go down into the water.
So, how do I get rid of that annoying data issue message
Standardized burial place missing (in German displayed):
"Standardisierter Bestattungsort fehlt. Für den Betreffenden ist kein standardisierter Bestattungsort angegeben."
For now I have typed "Ostsee, Seebestattung", meaning Baltic Sea, burial at sea
Answers
-
@Stefan6374
I have a few seaman in my extended research who were buried at sea. An example: G4PP-61J
I entered both his place of death and place of burial as "At Sea", and provided a more complete description in the "Reason" field.
Neither the Data Quality Score nor the place standards algorithm calls out an error in that case.
5 -
@Áine.ní.Donnghaile - I never knew that!
To make it explicit for everyone else, the list of Standardised Placenames includes a place called "At Sea". That's why the DQ system is happy.
"At Sea" happens to have coordinates in the middle of the North Atlantic, but hey, we can't have everything!
NB - there are versions in other languages such as "Auf dem Meer"
3 -
If you go to the Places database at https://www.familysearch.org/en/research/places/ and check using the filters, you will see that the list of standards includes 20 oceans and 89 seas:
Including the Baltic Sea:
The trouble you are having stems from the fact that Ostsee has not been included as one of its forms. I suspect this particular place and its names were imported from a bulk source of such and never actually touched by anyone at FamilySearch because the proper language for the names have never been added and the only citation is from 2005.
You can request that Ostsee be added as the correct name for it in the language you are using (German?). It would also be good for anyone who knows the languages those other names are in to post that so those can be corrected. All I can say is the first is English and the next to last is Swedish. The last is probably Danish as I can find the Danish name as Östersøen a couple of places but mainly as Østersøen.
5 -
To request corrections and additions, you use the Improve This Place link:
or e-mailing the team in charge directly. Their address is found towards the end of this article:
Sometimes if the issue is simple enough, like this one, sometimes just posting about it here with the specific need and enough information so that no one has to go research anything is sufficient to get it fixed.
1 -
Baltic Sea comes back as a standardized placename as well. Tried other oceans/seas with success as well.
Perhaps you would like the following:
Atlantic Ocean, Bar Harbor, Hancock, Maine, United States (suggested standard place.) Might find more of these around populated seafaring ports (?)
1 -
Do keep in mind that if you have a place that does not have a sufficient standard that if you want to make sure that users who never turn on the Detail View option and so never see reason statements will still see the full information about the place, you can preface the needed standard with the real information:
The data quality checker will be just fine with this because it only looks at the linked standard:
and not at the full displayed text.
1 -
I avoid living in the land of "What If". For the tiny percentage of lookie-loo users who fail to turn on "Detail View", then they are at a loss. The FS guidelines for data entry should supersede "what if".
Plus, whenever I see "Standized Data" under an entry, I feel like the FS Robot is scolding me or the previous user for entering the place wrong.This seems cleaner:
0 -
I don't have any actual data on how many users turn on Detail View, but I would be quite confident that the truth is the opposite of what you surmise (you referred to "the tiny percentage of lookie-loo users who fail to turn on Detail View"). Instead, we can be sure that relatively few people turn on Detail View, based on the general principle that most users never change the default for a setting, and the default setting for Detail View is "off." I have helped hundreds of people with FamilySearch through the years, and only a handful of them have turned on Detail View.
In any case, I would suggest that it is not prudent to rely on the Detail View. After all, places are shown on many pages throughout FamilySearch besides the person profile page. Almost all those other pages show the display place without the standardized place or the reason statement being shown. So it is helpful to other users to put the best information available in the display field.
Besides, a reason statement that simply says "Between Callao, Peru, and Los Angeles, California" is not a particularly good reason statement. It provides no explanation as to why the death place is correct (which is the purpose for the reason statement). A better explanation would be something like "The ship's manifest upon docking in Los Angeles, CA, after sailing from Callao, Peru, indicated that he died during the voyage."
You said:
The FS guidelines for data entry should supersede "what if".
What guidelines are you referring to? I am unaware of any guidelines for data entry that would indicate that the standardized data should exactly match the entered data. To the contrary, if that were the way it is to be done, then there would be no need to have the system allow them to be different. Yet it does allow them to be different, for abundantly good reasons, as @Gordon Collett has ably defended many times through the years (and again in this very thread).
Plus, whenever I see "Standardized Data" under an entry, I feel like the FS Robot is scolding me or the previous user for entering the place wrong.
I'm sorry you feel that way, but I certainly never feel that way. FS is simply sharing some helpful information. The place is not wrong simply because the displayed place differs from the standardized place, and there is no indication or implication that it is wrong.
1 -
@Alan E. Brown mentioned in his excellent reply
"... It provides no explanation as to why the death place is correct (which is the purpose for the reason statement). ..."
I'm certain that was indeed the designed purpose of the reason statement. However I would suggest that, for some of us, the item has become dual purpose. Rightly or wrongly.
Where the value is simply a direct quote from an attached source record, it seems to me to be superfluous to explain it again, when the explanation was surely provided (hopefully!) at the attachment of the source record. But what is missing otherwise from the FS design is a general purpose note to expand on the bare fact and that's what I often end up using the reason statement for. Eg, "His aircraft went down at sea, and his body was never recovered "
2 -
Thank you Gordon and to the others for the detailed information.
I've just requested for an improvement to include the German name.
And thanks for the places link. Will definitely dive more into that to fix some other place issues.
Was a bit tricky, but the system finally accepted
"Seebestattung (N54°02.3' E10°54.9') - Baltic Sea"
3 -
Besides, a reason statement that simply says "Between Callao, Peru, and Los Angeles, California" is not a particularly good reason statement. It provides no explanation as to why the death place is correct (which is the purpose for the reason statement). A better explanation would be something like "The ship's manifest upon docking in Los Angeles, CA, after sailing from Callao, Peru, indicated that he died during the voyage."
That information, from the manifest, is listed elsewhere on the profile. As that was not part of this discussion, I did not feel it was necessary to put a screenshot of the entire profile in my reply.
2 -
@Stefan6374 Yes, it can take a bit of work to figure out how to get the display name to show what you need it to show. Just when I think I know most of rules for special characters that can be used to format the name for clarity, they seem to change.
Looks like someone has been working on your request. This was pretty quick. Usually it can take a fair amount of time. But checking this morning shows:
and more for names. It might take a day or so before all the various systems sync for Ostsee to become available in Family Tree. But now it will be.
@Nyx773 Don't take the appearance of both the Displayed Name and the Standardized Data Name as the program scolding you! Take it as a message to FamilySearch that the Places Database is still incomplete and insufficient.
I've gotten very familiar with FamilySearch's dual place name entry system due a problem I ran into very quickly when Family Tree first opened. I mainly research in Norway. For the vast majority of the country, the basic unit of residence is the farm. The initial build for the Places database was imported from a database referenced in the citations as NGA. This brought in hundreds of thousands of farm names.
However, that database only had the place names in the form Farm, County, Country. It did not include the Municipality the farms were in. This is a big problem because most farm names in Norway are geological and there is a high rate of repetition. Take the farm name of Eide, for example. Eide just means Property. A county will be made up of 20 to 30 municipalities. Each municipality will likely have a farm by the name of Eide. That means that there could be 20 to 30 Eide in a single country. But it appears that the database did not allow duplicates which means only 1 of those couple of dozen Eide is actually in the database.
Another problem is that all of FamilySearch's indexed records for Norway are based on Municipality, County, Country. If places are entered Farm, County, Country, nothing will match with the indexes.
To illustrate with an example, here is the standard for Eide, Sogn og Fjordane, Norway:
If I use this standard, it has a very high probability of not being the correct farm because there are actually ten different farms by the name of Eide in Sogn og Fjordane. And because it does not include the municipality, the hinting and other routines that use the standard place name won't work.
The farm I actually mean is in Selje municipality which municipality has this standard;
If I use just this standard, then there is no indication in the place name of where the family actually lived even though it is clear, from the other standard, that FamilySearch intends the farm name to be included.
Here you can see my choices when entering this farm in Family Tree;
I work to get the best of both possibilities by entering it like this:
Users can see which farm the family lived at. The program can use the less complete standard for all computational needs.
The situation is improving. As I understand it, the Places database team has 3 or 4 volunteers working to correct the hundreds of thousands of three part place names in Norway to be four part place names and we can find more and more of these in database for use in Family Tree. If I repeat the search I did above in Hordaland instead of Sogn og Fjordane I get:
(this is only a about a third of the list that comes up for Eides in Hordaland.)
The dual place entry system is wonderful because it lets one manage situations such as in my example here.
1 -
The above took so long to write that I just checked Family Tree again:
Clicking on the first line keeps it in German (this is another function of the dual place name entry system):
So you can now enter the burial place as:
If you have the website set to German, you will see this instead:
0
