Dismiss 'data problem' for places

LegacyUser

Kathryn Smith Black said: The software is often unhappy with the way the place names are added and puts up a 'data problem' flag. This is particularly irritating for New York City where the place correctly starts with the boro and then goes to NYC. Would very much like to be able to dismiss these 'data problems'.

LegacyUser

Juli said: There is a lot of flexibility built into the placename entry process, but you _must_ choose a name from the list -- otherwise, the system cannot associate the event with a location, and that is a data problem, no matter what you do. It cannot simply be dismissed.

Part of the flexibility is that the name from the list does not need to exactly match the name that is displayed. For example, if you want to add the street address at the beginning, you can do that. (Depending on the specifics, it may take a bit of ...creativity.) Others on this forum are better at explaining how.

I haven't checked the places database to see what all is in there for NYC, but I'm sure the boroughs are all there, probably in multiple versions corresponding to historical changes in jurisdictions and names. There may be some confusion due to the weird way NYC relates to counties -- the standards for U.S. places on FS are generally "town, county, state, United States of America", and it can be hard to fit things into that when you have boroughs that span multiple counties, and counties that are boroughs but by another name.

LegacyUser

Tom Huber said: I'm not sure (and I could be wrong), but I believe a "data problem" on a place is nothing more than the place not having a standard established for searching.

As Juli mentions, the actual entry does not have to match the standard and for many of my place entries does not. That's because I often add identifying place information that is not part of the standard (and likely never will be).

Edit the place, do not do anything with what has been manually entered, and then select the correct "place" from the standards list. There will be times, when there will be a standard for the place, but it does not show up on the list. In those few instances, you may have to retain (perhaps in a text file) the entered place, change the entered place so it pulls up the correct standard, then paste back in the original entry and save the result.

LegacyUser

Kathryn Smith Black said: Unfortunatly, it's not that straight forward. The place entered for an event should be what is listed in the source, regardless of what the computer thinks of it.

What I want to do is to tell the computer/software to sit down and not complain about what is.

LegacyUser

Tom Huber said: I do not think you understand the whole purpose of the standard -- it exists to facilitate searching, not to establish the exact place.

If a census record contains a street address, then I enter that. But I always set the standard to the equivalent political division.

That is the way FamilySearch FamilyTree works:

Enter the place as it appears in the actual record. Select the standard place as it existed at the time of the event.

For instance, Pieter Claesen was born Wykhof, Nordingen, Aurich, Holy Roman Empire during the thirty years' war when the area was still part of the empire. The only applicable standard is Hold Roman Empire. The place was likely an estate, so it is entered as the place, but the standard was set to the closest geographical region that applied.

LegacyUser

Tom Huber said: Once the standard has been entered, then there will be no more complaints. That is part of the design of the system.

LegacyUser

Gordon Collett said: As usual, pictures always help.

Data problem:



because "No Standard Is Selected."



So select a standard without changing what you want displayed:



and the data problem is dismissed:



Family Tree is programmed this way, which is a vast improvement over any genealogical program I have ever used before, so that you can have "The place entered for an event ... [be] listed in the source, regardless of what the computer thinks of it." and you can "tell the computer/software to sit down and not complain about what is" while at the same time telling the computer what you mean by what you have entered, that is, where it is on the map in at least general terms so that the computer can use all the hinting and matching routines it has to find more information for you and to be able to map the location for you.

LegacyUser

Paul said: I find the problem often be when a Standardised Place IS shown, rather than the Data problem. I think a lot of users would be very surprised at what appears a perfectly correct standardised place really has actually been standardised to. Click on "Edit" and you'll often find your outwardly appearing correct place name has been standardised as a town/city of the same name, but on the other side of the world! Careful the display name does not lead you into a false sense of security.

LegacyUser

Adrian Bruce said: "The place entered for an event should be what is listed in the source, regardless of what the computer thinks of it."
I don't know what others think but I personally couldn't always agree with that.

The indexed record should certainly match what is listed in the source, yes. But the data that goes into the profile is our conclusion and that might take a bit from one indexed record and a bit from another. Similarly, take my GG-GF's brother who emigrated to San Francisco -
- the 1900 census has him counted at "Precinct 16 San Francisco city Ward 41, San Francisco, California, United States"

- the 1910 has him at "San Francisco Assembly District 41, San Francisco, California, United States"

- the 1920 has him at "San Francisco Assembly District 31, San Francisco, California, United States"

Every single one of those place-names is different - but having checked the images, I also know that in all 3 censuses, he was living at the same address - "2546 Jackson St, San Francisco, California, United States". To me, it's better by far to ignore the Asembly Districts, etc, and set the Standard place-name to "San Francisco, San Francisco, California, United States" for all three - this helps the search routine to work correctly.

Then I "decorate" the displayed name by adding "2546 Jackson St., " at the front so each of them reads "2546 Jackson St, San Francisco, California, United States" - looks like I managed to carve off the first "San Francisco" as well, though there will be those who disagree with that. The Standard and Display names get left as I entered by clicking outside the box or whatever.

That ends up with a readable and meaningful address - so far as I understand it, precincts, wards and assembly districts change over the years so they don't convey much useful info.

So yes, while we should be using the contemporary name from the source as our basis, we may need to alter it if it's incomplete; we may need to tweak it to ignore irrelevancies like Ward numbers (if we have a street address**) and we may need to combine bits if, as with a birth pace from censuses, we get two sources disagreeing.

** If we don't have a street address but do have a Ward, then it would seem sensible to use that Ward number to refine where the actual place is.

LegacyUser

Jeff Wiseman said: Also, the statement that:

The place entered for an event should be what is listed in the source

is PHYSICALLY IMPOSSIBLE in many cases. The minute you add a second source that lists the data slightly differently, what was said in the quote is impossible. And I have seen some vitals with many sources that contain different, and even conflicting values.

- The contents of a source is only evidence
- The contents of a vital is a conclusion

Although they can occasionally be identical, it is rarely the case.

LegacyUser

Juli said: Kathryn, I think you're confusing citations and conclusions.

Citations should stick with what the source actually says (the index correction system's stupid "wrong on document" option notwithstanding). However, the things on a person's Details page on the FamilySearch Family Tree are _conclusions_, not citations.

As Jeff points out above, conclusions are often based on multiple sources, and those sources may not agree. Therefore, it is impossible to make them match what was "listed in the source", and you shouldn't want to. You should be using the available sources to figure out exactly where on the globe an event occurred, and you should then be using FamilySearch's places database to come up with the best historically-appropriate label available for that place.