Reason To Attach still not populating the 'Residence' reason field
I have been working to discover more about the mechanics behind this issue and concluded the following:
The Reason to attach field is being populated correctly by the Source Linker, for source records that appear when viewed in 'Sources'. For any given source that is attached to a person, the last item, labelled: 'Reason This Source Is Attached:' contains the reason data that was entered via the source linker.
However, the field labelled 'Reason:' that would be displayed beneath a life event in Vitals or beneath Residence in Other Informaton, Events, is not being populated.
Is this intentional ?
의견
-
I would appreciate some feedback on this issue, because I would like the to have the reason field for a Life Event on the person page to be shown with, for example, the reason "TENTATIVE" when there is little corroboration but no better match. It makes it clear to any researcher that this is a possible connection and not a definite one.. At the moment, if this reason is added via the linker, it is only visible when viewed via "Sources" and even then it is buried right down at the bottom of the record in the small print. The reason field for the life event on the person details page gets no text added, thus implying by default that the attachment is not Tentative as was intended to be conveyed.
0 -
A reason for attaching a source is not the reasoning for a conclusion, so Source Linker is doing it exactly right.
The part I do agree with is that the current "halfway-sorta" status of profile editability via Source Linker is …non-ideal. Either let us edit, or don't; don't make the computer decide for us whether we can edit something, based on the decisions of people setting up the finding aids, often decades ago, long before the Tree was even conceived of.
0 -
@Julia Szent-Györgyi - Yes I agree, that's the point … It's tentative, therefore the reason is the same for attaching the source as it is for the life event, they are both possibly correct but not definite. I want to be able to let those who come after me know that I couldn't be certain, I think that the source should be attached rather than not at all because there is chance that it might be pertinent and otherwise it might get msised. The previous source linker copied the 'reason to attach' reason into the life event reason field. The current source linker doesn't continue this behaviour. I wanted to know if this is a deliberate change or simply an omission.
0 -
Thank you both for your comments. I have recorded this to be discussed with the engineers.
0 -
I would really like "Reason to attach" to be shown for Residences on the person page. Right now the wording is different (the Person Page says "Reason this information is correct"), but I use them the same. Currently I have to go back to the Person Page and edit after attaching Residence info.
Is anyone else in the same boat?
0 -
@CherylMillerBlack Yes, it's a pain when you have to do that for each person in the entire family group because it doesn't get copied automatically like it did before. I really do hope that it gets reinstated at the next update, or if not, then some kind of explanation of why it was removed.
0 -
@CherylMillerBlack @Re Searching @Julia Szent-Györgyi
I am reviewing the information that is populating in the Reason to Attach Source field in Source Linker.
1. A same reason statement entered in Reason to Attach Source appears in every other person in the indexed record when added to the tree on the right, but you have the chance to review and change it for each line.2. When adding a new person (using the + button) the source linker asks for sex and Living or Deceased. If you select Deceased, it asks you to enter an optional "Reason you Believe this Person is Deceased". This reason does not populate to any other fields.
3. After creating a new person, you are then presented with the Attach Screen where the Reason to Attach Source from the original (#1 above) is presented and can be edited.
If you put something in Reason to Attach Source for a census record that contains a Residence, this information is not pushed to the Reason this information is Correct in the Residence information screen. It appears that the only way enter information about a residence is to edit the person page. Source Linker will not help you.
The reason a source was attached can be edited at the source:
You can edit reason statements on sources attached to a person.
Click a Source title or View Source below title.
At the bottom, you can click Add or Edit reason statements.
The original statement still shows in the changes list.
The sequence of events as shown in Latest Changes Show All log is
Source Attached
Source Tag Changed (if edited when attaching)
Source Reason Changed (if edited from the Source Tab)
At this point I think that everything is working as designed.
The suggested enhancement would be to allow the Reason to Attach Source to populate to the Reason this Information is Correct in the Residence field.
I would be interested in specific examples with Person ID and URLs where the record has not been attached that is behaving in a way inconsistent with the above describe processes.
Thank you everyone for contributing and helping refine these processes.0 -
Take this 1851 Census record :
https://www.familysearch.org/ark:/61903/1:1:SG1S-SFY
Let's say that extensive but inconclusive research indicates a possibility that the person might be this one :
https://www.familysearch.org/tree/person/details/GYLV-4WG
I progress to attach the person to the census, and include the phrase "TENTATIVE" in the reason field.
While I make the attachment, I edit the Residence to include the missing data "Haydock Lodge Lunatic Asylum, Haydock, Lancashire"
The overall effect is:
The attachment is completed.
The Census record appears in Sources for Mary Simpson 1829–Deceased GYLV-4WG
This Source record contains "TENTATIVE" in Reason This Source Is Attached
In the Person Details page: https://www.familysearch.org/tree/person/details/GYLV-4WG
In the Other Information section, in Events, the Residence shows 1851 Haydock Lodge Lunatic Asylum, Haydock, Lancashire and the Last Changed date etc.
There is no other visible data associated with this Residence event.
Expanding this section using the edit pencil shows that the Reason This Information Is Correct field is empty.
The 'old' version of the source linker would have populated this field with the same data that was written into the "Reason This Source Is Attached" field of the source record, so TENTATIVE would have appeared beneath the Residence 1851 Haydock Lodge Lunatic Asylum, Haydock, Lancashire information.1 -
In this 1841 Census record
https://www.familysearch.org/ark:/61903/1:1:MQ57-3TN
The place name is auto-mangled to become Bradford St James, Yorkshire, England, United Kingdom. This is insufficent to clearly define the place in the timeline. Taking the Census reference data it is possible to determine that the proper place is Oaks Lane, Bowling, Yorkshire, England, United Kingdom.
To clarify the position, I edit the place name within the source linker to become Oaks Lane, Bowling, Yorkshire, England, United Kingdom, and then I add the Reason: "HO 107/1292 Book 12 Folio 31 covers Oaks Lane, Bowling"
The "Reason This Source Is Attached:" field in the Source record under Sources now shows this reason, which is not the desired result. If anything, the Reason This Source Is Attached should have something akin to "Because the family in this record matches the family in the later census in the same place"
This reason that was entered does not get copied into the "Reason This Information Is Correct" of the Event, so there is no data presented to contributors to explain why I have editted the place name. This field is the one that is immediately visible to contributors and it is where the actual information needs to be conveyed. i.e. that the place name shown above is correct because the census reference data has been used to validate it.
I reiterate: The current source linker does not perform the function that was present in the 'old' source linker. The effect is a huge increase in effort to add the reason to every event for every person for every source that is attached where an edit is needed and a supporting reason is to be presented.
1 -
Please don't make Source Linker conflate two totally-unrelated fields. While both the attachment of a source and the addition of a conclusion based on it may be "tentative", this does not make those actions or their motivations into the same thing. They're not really even the same species, and an explanation that applies to the one is likely to sound like unconnected utter nonsense on the other. ("Mentioned as a witness" as the reason for a residence?)
Really what we need is for Source Linker to stop artificially limiting edits. While I don't mind being able to sometimes correct a field straight from Linker, something about it still vaguely bugged me (beyond the random-seeming out-of-my-hands decision about what/when I can edit), and it took until this thread for me to figure out what: SL-based edits don't allow any visibility into the reason field. A carefully-explained death date and place can be blindly obliterated by a single attachment of the gravestone that disagrees with both, and said attachment-and-edit offers no method for adding an explanation for why it might actually be correct.
Source Linker's current halfway-there partial editing peephole is not a good use of anyone's time and energy: users like us get frustrated and/or make less-than-ideal decisions based on the incomplete information presented by the tool, while the programmers waste their efforts on getting the software to make decisions that should be up to human users. The programmer's attention should be on making the tool as useful as possible, by having it show its users all of the information available, not just dribs and drabs of it.
2 -
To add to my post from this morning: the lack of visibility of data extends beyond the reason statements, in the current Source Linker. This makes the tool clunky and ineffective. For example, I was attaching a record just now which offered an immigration conclusion to transfer. I had to check the profile in another tab to see if that immigration was already there or not, because Source Linker cannot be trusted: it may not be showing such a conclusion because it's not there, or it may not be showing it because it's labeled differently, or maybe because it just wasn't in the mood today. If Source Linker offered a residence for a profile with a long list of residences, I'd probably need to switch back and forth between tabs several times to figure out if the conclusion matched an existing one or not.
2 -
@Julia Szent-Györgyi I think I understand your reasoning.
At the risk of expanding this thread well beyond the original subject; currently we are not offered the facility to add reasons to each separate item that we select to be copied into the person record, so we only have one opportunity to add explanatory information.
When attaching a census record we can't even add a date to an occupation or a change in marriage status, that by rights should already have the date attached.
The source linker reason statement, taken literally, applies ONLY to the attachment of the source to the person. I think I'm right in saying that the vast majority of attachments have no reason added because there is no real need, it's fairly obvious that the source and the person are correctly matched. That brings me to think of what the real function of the reason field is, which is to convey information that is pertinent in those cases where the attachment is not obvious. That gets me back to the argument for TENTATIVE, and rewinds back to the start to repeat that the function that was performed by the 'old' source linker is not performed by the current one.
I think @ScottSeegmiller has given the indication that whether or not the change was intentional, it's not going to be reinstated. If that's true then it's probably worth examining the whole argument for reason statements en-masse, and coming up with a better way deal with them that reduces effort rather than increases it.
2
