Should people be encourage to clean up after themselves?

Gordon Collett

Just a bit of a philosophical quandary. No real suggestion of how to improve anything.

It's great that there are people who mainly work to get hints attached. It's good that the hint routine has gotten quite strict so that the error rate for hints is quite low. But at what point does just attaching hints actually make more work for the next user coming to a record rather than less? When attaching hints, should a warning be added that not all information in the hint needs to be moved over to the record? Should a notice be added to encourage people to understand what they are adding with the hint and to go to the record afterwards and clean up any mess they made? Or should we be happy that people who don't really understand what the hints are doing are not editing profiles they probably wouldn't understand either?

I am currently going back to an area of my wife's family that has a lot of hints due to a historical database released last year. A lot of other people have also been working on these hints, so I'm finding quite a few profiles like this:

This woman already had her christening information added to her profile and sourced. A new hint gave the option of pulling over a baptismal event. Moving it over while attaching the hint created duplicate information with an abbreviated date and wrong place information (due to the auto-standardization of historical record place name flaw).

This woman had several children. The database supplying the hints does not put a birthplace against the child's information but puts it as an incomplete, frequently mis-transcribed residence for the mother. Here, Nysater should be Nysæter; Dale is fine; Rosad, Rosnæs, Ronds, and Rosmoe should all be Rosnæs, and Lellebo should be Lillebø and none of them really need to be here. They are already properly and fully recorded on the children's profiles. If someone does want them there, then the full place name needs to be determined and date ranges added for them really to be of any meaningful use.

So should people be encouraged to take care of this as they attach each hint? Or to not move it over in the Source Linker in the first place?

Or should we just be grateful the hints are being attached? It does take me less time to delete all this unnecessary duplicate information than it would to attach all the eight hints it came from. But it would be nice to not have it put there in the first place.

Adrian Bruce1

I think that there are (inevitably?) several aspects here.

Firstly, there is a frequent degree of misinterpretation of place names in relation to parish records (to cite my own experience). UK parish records record where someone was buried and I have lost count of the number of times where someone is recorded as dying at the church, as well as being buried there. Or being resident at the church. Yes, we could condemn the indexing and/or the software creating the personas in the source records. But it seems unlikely that anyone will take notice of such views. And, "we are where we are"...

I think that it's virtually impossible to come up with any rules in the software for what should be moved over onto the profile, such is the multiplicity of source types. So perhaps the only possibility is to get users to think a bit more about what they are entering and why... Classic questions such as "Was this person really resident at the church?" ought to be part of the training materials (Oh, hang on... 😕 ). But such a question would, I hope, encourage people to think about other issues such as "Was someone really born where their parents lived?"

So I seem to be saying, "Yes, people should be encouraged to rationalise the data that they have just entered from a hint".

Paul W

I agree that there are different problems attached to what we see illustrated in the screenshot.

Firstly, there are the indexing instructions for the different projects that allow for a place of "residence" to be recorded. I have found two flaws here. Firstly, the parish name is often indexed instead of the actual place of residence recorded in the individual entry. Secondly, when the specific place of residence has been indexed it is often something like "High Street", which is correct from an indexing point of view, but quite meaningless when added to the final record for the event. Also, when the latter situation is the case, there are often two pieces of "Residence" data attached to the record (both of which can be transferred to the Details page under a "Residence" heading).

So, the problem is created somewhere in the indexing process - whereby there are names which have been indexed in line with project instructions, but have obviously not been standardized. For example, the "Dale" or "Ronds" in the screenshot above.

I believe the best way around this - unless you feel it's worth the effort of someone turning these basic names into standardized ones - is to not carry them across in the source linking process. The information will still be there once you open up the record (from the individual's Sources section), but not carrying it across will save a lot of work - and/or prevent all those red "Non-standardized Place" warnings!

I have argued in the past that it is best either not to index residence locations (in this format), or there not to be the ability to carry them across to the Details page when linking the source. The former idea would mean losing potentially useful detail that appeared in the original record, but I have rarely seen the point of carrying the "Residence" field(s) details across - and think the example in the screenshot clearly illustrates my point:

Residence: Ronds - "Ronds" where, let alone when, and ditto for "Dale", "Rosmoe", etc. All completely useless detail, only serving to clutter-up the Details page when there is no indication of the actual location of these places, let alone when the individual actually resided there.

In summary, as long as it is found to be of some use to index these places of residence, it would be best if we did not have the ability to carry them across (to the Details page). You probably know, at present, not every piece of data can be added to the Details page from a source, so why not preclude Residence data, too?

If users really do find it of great use to add residence details to the Details page, they can do so "manually" - adding a date and standardizing the place name at the same time!

(Above suggestions might be useful in dealing with the matter in future, but I realise certainly doesn't help in dealing with the problem in relation to what we - Gordon in this case - are encountering at present!)

RTorchia

I have argued in the past that it is best either not to index residence locations (in this format), or there not to be the ability to carry them across to the Details page when linking the source.

It depends on the info and the database. I don't see much point to undated residences. But there are a few specific residences in records I always want to have the ability to add during linking: namely census reports (at least US, Canadian and British ones -- a can't vouch globally). They're dated and the ten-year interval seems like an ideal way to track residency most of the time. (Oh, with a couple exceptions:

• The 1935 location in the 1940 US census and the 1949 location in the 1950 US census should be diabled, because they're rarely ever actually filled and indexed correctly.
• The street name in British census records Paul mentioned. I agree the fact that these still get added without dates and with no hope of them having any real meaning when disconnected from the town is a clear indication we can't expect people to stop blindly adding every available field -- FS has to disable the ability to add.)

There are a few other tags that shouldn't be available to add during linking:

• Baptisms are still written as Custom Events instead of Christenings, which is just baffling to me that they haven't fixed that yet.
• Revolutionary War pension payments are entered as Military Events, even though clearly no 70 year-old was fighting the British in 1830.
• Other pension payments are also written as Custom Events, but it's unclear if the date is the start or end of the payment, and they're probably fine just staying in Sources.
• Marriage registrations and Banns are written as Custom Events, which is even less useful when the person had more than one spouse. If they could be added as relationship events, maybe, but without that, just don't let those be added.
• WWI & II draft registrations are written as Custom Events -- honoring, I suppose, the ten minutes it took to fill that form out.
• Obituaries are written as Custom Events. The shouldn't be -- they're fine as just as sources. And maybe this is an indexing thing, but a lot of obits don't include the state when identifying the residences of family who live in the same state as the paper, which can be hard to figure out while linking.