Why attempt to standardise what cannot be standardised?
I'm working through the Record Hints for a Joseph Stubbs, MQVC-3KM, and the Research Help / Show All / Record Hints contains this priceless suggestion:
So the "Other" data on the date of his burial reads - 14 February 1881, Cowfold, Midlands Province, Zimbabwe.
Now, when you actually go into Source Linker for this, the record looks like this:
The Residence for 14 Feb 1881 reads just "Cowfields" - an accurate transcript of the image, by the way. Cowfields is a street in Nantwich, I happen to know, and I presume that it's been standardised to the nearest standard place-name, which must be in Zimbabwe.
Basically this doesn't work, does it?
We've had discussions about standardising these intermediate items such as Research Help / Show All / Record Hints before, and how, particularly with no user intervention, the results are likely to be garbage - as here. If you're a cynic like me and ignore silly values, you won't be affected. If you implicitly believe the computer, you might go no further as you just know that someone in Rhodesia / Zimbabwe isn't your chap.
It all starts to get very risky when the Residence item is (a) pulled out to be indexed and (b) treated as a place-name to be standardised. Residence names like this (and it happens with Census records as well, doesn't it?) are very unlikely to be complete place-names and therefore can't be standardised. You can't concatenate them with the place-name because there's no guarantee it's the place-name with that address - it could be another, higher level place.
I'd be happy to see that "Cowfields" indexed as a simple bit of text. It makes no sense to attempt to standardise it as a place-name - because it isn't - so I recommend that these items are identified as addresses (i.e. just a bit of text), indexed, but not standardised.
Comments
-
Well I suggest FamilySearch have a "place details" field which would help in this area as in other areas too. They would just put the street name in the place details box. Here is where I talked about it https://community.familysearch.org/s/idea/0874V000000siqgQAA/detail
And here are the images originally associated with the post
0 -
It's not just "auxiliary" fields like Residence that often simply cannot be standardized, especially not mechanically. There are hundreds of thousands of index entries where the indexers were instructed to transcribe what they saw, without changing anything, precisely because interpretation is such a steep and slippery slope. Going back and trying to associate those entries with the placenames database is a monumentally, um, impossible task, and basing search results on those associations is, I'm sorry, asininely stupid.
Index fields should always be treated as simple text. Metadata (assigned by a human being, carefully, with a robust error-reporting and -correcting mechanism) can be pulled from a database, but the presentation should make clear what parts are index and what parts are metadata.
Specifically regarding Jordi's comment: these examples happen to be streets, but such fields can contain anything from a house-name to a continent, so fixes that concentrate only on the "additional detail" angle are going to miss a whole lot of other cases.
0 -
I raised this issue some time ago on the GetSat forum. Yes, it's highly annoying to see all those data problem warnings on the person page. They either have to just be ignored or not carried across when attaching the source. My usual practice is to do the latter.
It would just take too much time to work out the standard name for a residence like "High Street", so those that I (or another user) have already added in the source attachment process just have to remain, together with all those unsightly red exclamation marks!
I agree that this field should be "Address" rather than "Residence". The town/city has nearly always been recorded as this, so we should not have two Residence fields in a source.
I doubt if the developers will bother to address this issue - too many other "priorities", I guess - but it is very aggravating.
0
