Disappointed still possible to bring over two Residence events from same source
As shown at https://www.familysearch.org/search/linker?ark=/ark:/61903/1:1:M73C-MV7&id=MC5B-Z22&hinting=/tree/person/details/MC5B-Z22 two Residence items are often shown in a source.
One is generally quite useless - "Hing'S House" in this example, but commonly "High Street", or another street name. These items inevitably lead to a need for standardisation of the place name, as well as adding a date. The latter is easily added from the date of the source, but "High Street where?" is often very difficult to establish, as it's often not at the same location as the place recorded below it!
I encounter Details pages strewn with red data warning signs, and which nearly always relate to a place carried over from a census source, which would have been better off either not indexed, or not carried over in the source linking process. This "finer" detail is far better found (in context) when opening the source / record itself and just does not need to be shown on the Details page (under Other Information).
I know I am probably in a minority, but I generally feel much of the detail found in a source should not be open for editing, or being carried across to a profile, as this kind of detail is better recorded manually (after verification of the facts) from the Details page(s) of the individual(s) in question.
의견
-
I don't think this is a problem that can be addressed by Source Linker; it can't tell which (if either) of those two residences is a valid location. I much prefer being given the choice than to have the computer make such decisions for me.
0 -
I appreciate this wouldn't be a problem if two items had not been indexed separately, but under the same heading of "Residence". But I stick with my point that it is not a good idea to carry an item across that has no date and a placename that always needs to be expanded / standardised. In practice, I leave this behind during the process, knowing how worthless it will appear once transferred across to the Details page and produce that "red flag".
0 -
I found the Image here on Find My Past. (Sorry I cannot paste it, community has some issues)
https://search.findmypast.co.uk/record?id=GBC/1841/1026/0159&parentid=GBC/1841/0002005826I looked all around for the Hings House and did not find it in the image. I tried to get to the first page or a header but did not find anything in the record.
So it is an indexing, not a source linker issue.1 -
@ScottSeegmiller - just FYI, "Hing's House" is on the previous page. Good bet to look at the header and / or first page but it was a simpler answer in this case. Also FWIW, I doubt the House referred to more than 1 or 2 households, rather than carrying on as per the index, but as Julie implies, I think that's a value judgement by the researcher.
0 -
I appreciate the problem I raise is connected to the indexing process, but the way different items (particularly from census records) are labelled makes them rather meaningless when carried across during the process.
Take the example I am referring to. The "Tannington, Suffolk, England, United Kingdom" Residence data goes across to the Details page with the year (1841) of the census, so it is clear when the individual was resident at that place. But, regardless of my comments on the problems created by a further residence location (e.g. "Hing's House", or "High Street", etc.) there is also the factor that it carries no date. So, once it gets on the Details page "Hing's House" appears as a Residence, but is totally disconnected from the "Tannington, Suffolk" one, in not even carrying a date!
The same problem applies to (what become) "Custom Events" - like Marital Status. So, on the Details page we end up with, say, three Custom Events with this heading. One reads "Single", another "Married" and a further one "Widowed". Again, no dates (from the relevant census records) are carried across, so we merely know that an individual was - at some stage in their life - was single, then married, then widowed. Without any date alongside these "Events" (facts) they are pretty meaningless and just causing clutter.
I would imagine you would state, again, that this is primarily an indexing (or "post-indexing") related factor. But surely this illustrates the lack of coordination between the different teams at FamilySearch? Surely someone from the team connected with the Source Linker process should be able to go to the team responsible for producing the data that is found on the source linker page and say, "Hey, these facts are rather pointless without having a date attached. From the Details page we can't see when he lived at Hing's House or when he was found to be single / married / widowed. Can we have the date / year in question added to all these facts, in the same way it is attached to the (main) Residence field?"
I believe this sort of conversation should have been going on previously (i.e., discussion on the impact of one team's work further down the line), but this case - the introduction of an enhanced feature - surely should be highlighting the flaws in data recording / transfer and provide an impetus to address problems such as those being highlighted?
The profile that was my original reference point is a good illustration of the current need for dates to be attached to all events / facts, so they can be carried across in the source linking exercise. See https://www.familysearch.org/tree/person/details/MC5B-Z22. I would like to see clearly when she was resident at Hing's House, when she is found as "Married" and as a "Labourer Wife". These details are all found in different census records, so we should be able to easily identify the years in question, in the same way as the (village) residence years are clearly indicated - as relating to 1841 and 1851.
1 -
As I've written before (but am too lazy to find), it is highly annoying when we can't access all of the fields for an event (custom or otherwise) while in Source Linker. I agree that it potentially leads to mostly-useless clutter on the profile. However, this is only a potential: we are all perfectly able and free to edit the resulting conclusion to add the missing details and tags. We just have to remember to do it outside of Source Linker.
As I said above, I'd much rather be faced with multiple potentially-creatable conclusions in Source Linker than to have the computer decide for me which of two residence-like indexed fields is the "real" one. In fact, I think it would solve all of our problems nicely to carry that all the way to its logical conclusion: allow us, the users, to make ALL of the decisions. Just 'cause the index only has the baptism date doesn't mean that the document can't be a source for the birthdate as well, and just 'cause the index only has the death registration place doesn't mean that the document isn't a source for the death place. When I transfer an event in Source Linker, give me all of the fields for that conclusion, not just the one that happens to have been indexed. Give me full control of all tagging, not just for the things that happen to match something in the finding aid.
In other words, stop treating indexes as if they were the data. They're not even close. They're just a tiny snippet of the data, designed and meant to make the actual data easier to find.
3
