Distinguish between "less", "more" and "conflicting" data

Randy Wilson

I love that you can now edit conclusions on the Family Tree person that you see in a record. I see that it often says "Different" when the data is not identical.

It would be helpful if the Source Linker distinguished between 3 scenarios when the data is different, though:

1. Less. When the record has less specific data (like, "1820" or "Texas") and the Family Tree has more specific data (like "3 June 1820" or "El Paso, Texas"), then the record's data is "worse", and it would be nice to discourage using it.
2. More. When the record has more specific data than the Family Tree, then a user should be allowed to copy it over to Family Tree without having to click "Edit". Instead of "Different", it might say something like "More detail."
3. Conflicting. When the record has conflicting data (like "1830" vs. "1820" or "Texas" vs "Eugene, Oregon"), then showing "Different" like we currently do would still be appropriate.

Gail Swihart Watson

I like your idea … mostly. It is helpful to see that a source has less, more or conflicting information when compared to sources already linked to ancestors. But none of those things means the source is not a good source. Census records will always have less birth information that can be obtained elsewhere, but census records are valuable in other ways. In fact, I'm having trouble thinking of any source that should be ignored just because it has less information than other sources. An index record when there is an original image might be one, but some people can't read old handwriting and then would have trouble understanding the value of an image.

But all in all, I would love to see Less, More and Conflicting when I begin to add a source. It would be extremely helpful.

Julia Szent-Györgyi

I'd prefer a move in exactly the opposite direction: just let us edit everything, and don't task the computer with comparisons at all. It's annoying when it says "different" when they're not actually (Sámuel Csiki versus Csiki Sámuel or Samuel Csiky), and it's even more aggravating when it doesn't say "different" when the source offers information for a field.

If I think that having Sámuel Csiki marked "different" from Csiki Sámuel is annoying, you can guess how I'd feel about them being marked "conflicting".

davidleelambert

I was about to post a new thread for the following complaint, but it's pretty close to yours.

The source-linker also says "Different" when the tree profile has a date but not a place for a certain event, and the source's record has a place but not a date for that same event, or vice versa. Here's a screenshot of what I mean:

Here the record has a birth year (estimated from age reported a marriage or pre-marriage registration), and the tree profile has a birth place (also apparently based on place that Maria was "native and resident" of on the wedding certificate, when it was extracted). It seems like there should be some way to use the date from one side and the place from the other, when accepting the data in the linker.

(Of course I can go back and edit the source after linking. In this case I needed to do so anyway, because the "San Miguel, El Salvador" is very wrong: the parish records say just "San Miguel", but they're referring to a certain San Miguel town now in State of Mexico, Mexico, just north of Mexico City.)

Julia Szent-Györgyi

David's comment points out a problem with the more/less/conflicting idea: what should happen when comparing apples to toasters, such as "1793" to "San Miguel"?

Paul W

@davidleelambert

How did you manage to post that screenshot? I thought only moderators were currently able to do that!

If you have found a workaround, please share!

RobJacobson

I like Randy's idea, but it could be simplified. From our standpoint, 'Less' is functionally the same as equal data - we only want the data added if it's more or better than we already have. So treat data that is 'Less' as 'equal'. I can't see that changing 'Different' to 'Conflicting' is useful, 'Different' is what we're used to and seems to serve well. While the 'More' and 'Different' terms may be helpful, the distinction is small, and functionally, in both cases we want them treated the same - give us the option of a right arrow button that transfers the data into our profile (after we've analyzed it of course). Plus as Julia asks, allow editing always.

David's issue is a little different but related. The problem is that we need more atomic comparisons, and the way it's done now is by group, i.e. birth group of birth date and birth place together, same with death date and place, baptismal date and place, burial date and place, and marriage date and place. If we had more atomic comparisons, then David's example becomes a 'More' - his profile already has a birth place, he wants the birth date added.

And a similar and related issue, we often get records with residence info, and a Residence is offered, but without any date. Often, the date is obvious to us from the rest of the record, and we would like to be able to easily add it too, right then (just like Ancestry.com allows). Adding a Residence without a date is usually nonsensical. And you can find a LOT of records out there with undated Residences! That really should be discouraged.

Julia Szent-Györgyi

Another relevant aspect that I haven't seen mentioned in this thread: "more" is not at all the same as "better". If the profile has just a year, while the index has a month and day, but that month and day are wrong, then the profile's year is better than the index's date, despite containing less information.

I really do think this suggestion goes in the wrong direction for making Source Linker better. It continues/propagates the erroneous way of thinking that's at the root of the whole process: that the index is the data. If it's not in the index, Source Linker doesn't let us tag it, or enter it as part of a transferred conclusion; and if the conclusion is the same as what is in the index, then Source Linker doesn't let us edit it.

But indexes are not data. They are by design and fundamental concept incomplete, and they are by nature also error-prone. Why are we expected to treat the partial and unreliable summary as if it were the complete and unassailable Truth-With-Capital-T?

I understand why Source Linker (and the entire Search - Records versus Family Tree infrastructure) is set up the way it is: indexes are machine-parseable. That's a fact that's just as fundamental as their incompleteness and unreliability, and I expect it will continue to drive the system for the foreseeable future. However, this doesn't mean that machine-parseable data should be allowed to override user decisions. The machine should stick to the parts it's good at, and let humans do the parts that they're much better suited to doing.

ScottSeegmiller

@Julia Szent-Györgyi
Thank you for adding this.

I will repeat my previous post here as well. Source Linker is a tool. It will suggest indexed records that may help us with our research. But, let us let the humans do the parts that they're much better at doing.

1. Always look at the image before you attach the indexed record.

2. Do not ignore records that are already attached. Dig in and see if there is a duplicate.

3. Verify the names, dates, places, and relatives carefully. There is no harm in leaving it unattached, or better, marking it as Not a Match if all information creates doubt.

4. When you get back a more than 4 generations, many names are the same. When it doubt, leave it out. Let someone with more experience, more time, more focus figure it out.