Comments on: Trust and Isolde http://www.beyondproject.org/2006/05/25/trust-and-isolde/ Genealogy anywhere. Fri, 04 Jul 2008 05:21:58 +0000 http://wordpress.org/?v=2.0 by: Ben http://www.beyondproject.org/2006/05/25/trust-and-isolde/#comment-285 Tue, 30 May 2006 22:58:15 +0000 http://www.beyondproject.org/2006/05/25/trust-and-isolde/#comment-285 My first reaction was, "What? You'd include data that's patently false? What are you thinking?!?" :) Whenever that's my reaction, though, curiosity teases me along (surely there's a reason for such an opinion), and after mulling it over a bit here's what I've come up with. In a single-user environment (since that will often be the case), being able to mark data as false has the benefit of letting you know that something is clearly wrong (for example, you've found 1919 as a death date for your great grandfather all over the place on the Internet, but you know he was in the 1920 census, so while you don't yet know what his death date is, you know it's <i>not</i> 1919, and you want to remember that). Does something like this belong in the notes? Hmm... It may be a moot point. In a collaborative tree, which is what I'd prefer to design for, you do need to mark data as incorrect -- your uncle has been doing some research, let's say, and he reads a name as Boffacle. But you've seen the records and it's clearly Raffaele. So you mark Boffacle as wrong. This brings up a question I should've thought about long ago. ~blush~ Namely, should all changes be stored separately? For example, in this last example, would you actually change Boffacle to Raffaele, or would you add another first name (so there would be two, Boffacle <i>and</i> Raffaele, with one marked as wrong and the other marked as sure)? Hmm... I've been subconsciously assuming the former, but that doesn't work so well in a collaborative environment (especially when the community gets larger than a handful). Looks like it's time to brainstorm on the ramifications of keeping all the variations... (After that little PhpGedView debate on the other post, by the way, I have to say that you've made a good choice on the name of your project. :)) My first reaction was, “What? You’d include data that’s patently false? What are you thinking?!?” :)

Whenever that’s my reaction, though, curiosity teases me along (surely there’s a reason for such an opinion), and after mulling it over a bit here’s what I’ve come up with. In a single-user environment (since that will often be the case), being able to mark data as false has the benefit of letting you know that something is clearly wrong (for example, you’ve found 1919 as a death date for your great grandfather all over the place on the Internet, but you know he was in the 1920 census, so while you don’t yet know what his death date is, you know it’s not 1919, and you want to remember that). Does something like this belong in the notes? Hmm…

It may be a moot point. In a collaborative tree, which is what I’d prefer to design for, you do need to mark data as incorrect — your uncle has been doing some research, let’s say, and he reads a name as Boffacle. But you’ve seen the records and it’s clearly Raffaele. So you mark Boffacle as wrong.

This brings up a question I should’ve thought about long ago. ~blush~ Namely, should all changes be stored separately? For example, in this last example, would you actually change Boffacle to Raffaele, or would you add another first name (so there would be two, Boffacle and Raffaele, with one marked as wrong and the other marked as sure)? Hmm… I’ve been subconsciously assuming the former, but that doesn’t work so well in a collaborative environment (especially when the community gets larger than a handful). Looks like it’s time to brainstorm on the ramifications of keeping all the variations…

(After that little PhpGedView debate on the other post, by the way, I have to say that you’ve made a good choice on the name of your project. :))

]]> by: Hilton http://www.beyondproject.org/2006/05/25/trust-and-isolde/#comment-279 Tue, 30 May 2006 15:15:29 +0000 http://www.beyondproject.org/2006/05/25/trust-and-isolde/#comment-279 I would suggest another category of conclusion: false. Because there's a lot of disagreement about facts, it can be useful to assert when a specific fact is not true, and optionally why. This would be especially useful for interaction with other online genealogy services. I'm thinking in particular of how Genesis will interact with Beyond. Genesis will have a software agent that identifies highly similar individuals and allows the user to mark them as the same, not the same, and "not sure." Also, it allows the user to have conflicting facts about individuals along with their source data, and mark which ones the user doesn't agree with. They still stick around though, because if they were removed completely, the same data would just get picked up again by the search agent. I would suggest another category of conclusion: false. Because there’s a lot of disagreement about facts, it can be useful to assert when a specific fact is not true, and optionally why. This would be especially useful for interaction with other online genealogy services.

I’m thinking in particular of how Genesis will interact with Beyond. Genesis will have a software agent that identifies highly similar individuals and allows the user to mark them as the same, not the same, and “not sure.” Also, it allows the user to have conflicting facts about individuals along with their source data, and mark which ones the user doesn’t agree with. They still stick around though, because if they were removed completely, the same data would just get picked up again by the search agent.

]]>