Source Linker/Unfinished Attachment Fix Needed

LegacyUser

Kent Jaffa said: Source linker is a nice tool, especially with the Unfinished Attachment notification. There is, however, a serious flaw with Source Linker and Unfinished Attachments, especially when it is geared to experienced users. The source should be the primary determinant as to whether a source provides information for another person and not the information in FamilyTree.

Here is an example. James Brown’s (KHWB-C5D) death record provides no information on who his parents are. In fact, it states that his parents are unknown. Yet, unfinished attachments suggests this source should be attached to his parents. The only information linking this source to his parents is FamilyTree and the suggestion that it ought to be attached to his parents does not matter whether the source supports this or not. If fact, FamilyTree could show the incorrect parents and the source would show up as an unfinished attachment in source linker.

Please fix this flaw. I realize users can dismiss this attachment, however a significant number of users do not have the skills to realize this is a faulting suggestion and that the source provides no information on who the parents are.

LegacyUser

Juli said: The reason it's suggesting the unfinished attachment is that the computer doesn't know that "unknown" is not a name. There's text in the parent fields, which means there are index "entities" for the parents, and the computer wants those entities to be attached to profiles.

This likely goes back to an indexing error; most project instructions call for leaving fields blank if the image says "unknown" or similar. It looks like this is not a "correctable" index, and even if it were, index corrections do not allow the removal (or creation) of index entities (i.e., you can't leave an existing field blank, and you can't add a field for missed information), so the unknown parents would still be there. I think the best way to deal with it is to just dismiss the unfinished attachment. The notice will go away for every user who looks at James Shaw Brown's profile.

LegacyUser

Kent Jaffa said: That makes sense and I can see the difficulty, however couldn't the code be programed to recognize "unknown" as a blank name?

LegacyUser

Juli said: I suppose it may be possible to write some sort of automated script that could go through and remove a field from the index if the only text in it is "unknown", but the return on investment would be minimal, and expanding the script to lots of collections and corrections is a scary thought: do you include "unk" as equivalent to "unknown"? What if it says "Unk." as an abbreviation for something other than "unknown"? Or what if it was indexed as "unk[nown]" because of a misreading?

I think it would be better to make the index corrections process more flexible, with the ability to add and remove indexed entities (up to and including entire multi-person entries), so that one could fix not only this sort of problem, but also the ones where "pater ignotus" or "todtgeboren" and so on were misindexed as names. Yes, human corrections are much slower than a computer batch process, but "slow" also means "less likely to run amok".

LegacyUser

Kent Jaffa said: I thought of a way to fix the problem. Why not have the source linker require that a name on the index record match the name in FamilyTree. If the name of a parent on the indexed does not closely match the name of the parent in FamilyTree, then the source linker would not link the source to the parent.

Doesn't source linker do any checking to insure their is a match using the indexed data? Does it only rely on FamilyTree for the linking?

LegacyUser

Juli said: Really bad idea. What if the parents were misindexed, in a non-correctable collection?

I have an example in the Slovakia Church Books (which is not correctable) where for some reason, the indexers completely ignored the father's name (which was written very clearly in exactly the expected place), made the mother's name into the father, and then turned the abbreviated religion and occupation into the mother: https://www.familysearch.org/ark:/619...

Your idea would have made that record unattachable, which would have been serious insult to injury, given how hard it was to *find* the dratted thing.

LegacyUser

Kent Jaffa said: You always have to look at the original record when possible whether or not the record is indexed correctly. Relying on the transcription is bad practice whether or not there is a source linker.

In your example, you discovered who the parents are by following this basic rule. The source must have been in the child's source list and an analysis should have been made to determine this source belongs to this person. How would you even know this source is connected to the right person without doing so? Of course, many users just click away when a possible source is suggested. Without first determining that a source is connected to the correct person, you can easily corrupt the database and cause another user hours of time to correct the mistakes that are made based on a false assumption.

Analysis should not be made based on transcriptions when the original is reasonably available. As part of this analysis of this child's source, you should have seen the errors and determined who the parents are. Next, if you have further determined these are the correct parents, then source linker can be used to attach the record to the parents since the record was previously attached to the child or the source box can be used.

Good practice would not make the record unattachable. Source Linker should not be considered a replacement for analysis. Otherwise, you do not know whether you are adding to or corrupting the database? How would you know you even have the correct child and who the correct parents are?

This especially true with FamilyTree since the database is full of errors and the accuracy is not increasing with time. It is very common for users to assume a FT suggestion must be correct, otherwise the suggestion would not be have been made. Numerous users just click away and mess up the database. Attaching sources should be driven by the information in the source; not by what is in FT when the database is unreliable. In both your example and mine, connections should not be driven by what is in FT, but what is in the source.

LegacyUser

Kathryn Grant said: Agreed, Kent. After all, the system recognizes "unknown" in a person's name in Family Tree (along with other non-name words and phrases) and makes them unavailable for temple work.

LegacyUser

Kathryn Grant said: I share Juli's concerns. I am constantly finding and fixing incorrect merges in Family Tree. The parents in Family Tree may very well be wrong.

LegacyUser

Kent Jaffa said: Judi --- Yes, that is exactly how I think source linker should work. It should not suggest links without regard to what the transcription states. Doing it the existing way will result in continued corruption of the FT database.

Lots of users assume FT suggestions are correct. Further, they do not want to spend the time to determine if the suggestion is correct or not. They just click away and mess trees up.

From what you say, Source Linker appears to only rely on FT relationships and assumes FT relationships are correct. In your words, that is a really bad idea since lots of users do not know how to deal with it.

LegacyUser

Robert Wren said: The goal in genealogical research is to find a Primary Source or a secondary source, if a true primary is not available.
https://www.familysearch.org/wiki/en/...

Technically speaking, an index is not actually a source, it is, or should be understood to be, a tool to lead to a proper source - as Kent suggests above.

Regrettably, many (most) attached PID 'sources' are simply links to an index. To fulfill the goal of accuracy, IMO, more emphasis needs to be placed on understanding this basic concept.

Kent has highlighted that well in his comments above!!

LegacyUser

Juli said: Source Linker is the tool with which one attaches indexed sources in FS FT. What alternative are you suggesting here? That I not use the tool if the indexing went astray? What the heck should I use instead?

There is an underlying problem with FamilySearch's setup: the tools and procedures make the index primary and the image secondary, which is exactly the opposite of correct practices. This is driven by the fact that indexes are machine-parsable data, while images are not. Unless or until that changes, I'm afraid we all have to live with the bass-ackwardness.

LegacyUser

Kent Jaffa said: In your example, I assume that the source must have been attached to the child. While in the child's source list, the source should be examined and the original looked at if reasonably possible. At that point, you can discover what the original states and decide to add it to the parents' source list if they are the correct parents. If it should be added to their source lists, then copy the source to the FT Source Box and attach it to each of the parents' sources. This does not require the use of Source Linker.

LegacyUser

Juli said: At what level of indexing error would you draw the line for this throwing away of available tools? If the record says "István" but it was indexed as "Istiván", am I still allowed to use Source Linker? What about "Heitler" misread as "Keiszer"? Should I try to find a degree of error somewhere between those, or is the line somewhere beyond "Keiszer" toward "Cath Arendat"?

Another consideration: if I attach the indexed personas to the corresponding profiles, regardless of indexing errors, then those erroneous personas are removed from the hinting "pool". The "Review and Attach Record" button is replaced with "Attached to ...", with the "Review Attachments" function hidden under a grey Tools button. This makes it drastically less likely that a less-than-clueful user will appropriate the erroneous indexed persona and attach it somewhere (or worse, create a profile based on it).

It has been a while since I worked on the "Cath Arendat" example, so I don't remember the precise sequence, but I do remember that I found the record by browsing through the images. I then used the "Index Information" tab at the bottom of the image to go to the index record, and invoked Source Linker from there. As I recall, it came up with the "Good news! We may have found a match!" message, because the index personas had zombie-profiles from FSFT's predecessor system. There followed a bunch of merges-by-ID to get rid of the mythical/zombie profiles. I don't remember whether I did merges or sources first.

I work around the index-primary setup on FS by adding a transcription in the Notes section of the citations that Source Linker creates. If the index has errors or omissions in the location/denomination or other source identification details, I put those in the Notes section as well. As I wrote somewhere already, the index-primary setup is unlikely to change without a drastic expansion of computer capabilities, so I figure workarounds are the best I can do. It makes no sense to me to throw out the tools entirely just because indexes are flawed.

LegacyUser

Bryce Roper said: Kent, what we want you to do in cases like this is the select Dismiss on the sources page so it does not appear again. It is just to risky to have the computer make these link of decisions. We want a person to make the choice.

LegacyUser

Kent Jaffa said: Bryce

Thanks for your review. I understand about the Dismiss. I just think that a large number of users just click away without even thinking or analyzing the situation. I was surprised to see that Source Linker would suggest a source be linked to someone who was not mentioned in the source.

Is Source Linker based solely on what is in the trees? Why would it suggest that "Unknown Father" and "Unkown Mother" be linked to the parents in the tree?

I would have thought that Unfinished Attachments would have not have lined up "Unknown" with the father, but rather show it on a different line like when there is a family member in the Census that is not in the Tree.

LegacyUser

Juli said: I believe Source Linker primarily uses the relationships to determine how to line up index personas with tree profiles. If you tell it that Persona A should be linked to Profile A, and the index includes Persona A's parents, they'll automatically get lined up with Profile A's parents.

LegacyUser

Jeff Wiseman said: Juli,

Yes but just a reminder that the algorithms that try to line up each of the individuals in the source's index "group" (whatever that may be) with the target individual does have limits, especially if it is not an immediate relationship. For example, if a Census shows a family but also includes a nephew or niece, you pretty well have pull that person into the focus position using their PID.

Kent,

Why would it suggest that "Unknown Father" and "Unkown Mother" be linked to the parents in the tree?

That is because the index position was explicitly defined as a Mother or Father regardless of the name you put in there. If a name of the father was unreadable in the original image, then the index data for the father is still available but the name isn't. The indexed data has the relationship information there as well as the person's name.

Douglas McPhaden

This discussion is way too long to be useful. Have a nice day.