The Reason statement - thoughts

LegacyUser

joe martel said: There have been many threads about the use, mis-use, under-use of Reason statements. This most recent thread has had some interesting thoughts.
https://getsatisfaction.com/familysearch/topics/reconciling-sources-and-records

I would like to continue the design thoughts in this thread. Nothing is a bad idea, just don't call each other names

One post is intriguing to me  - being able to attach a Note to a conclusion. It's similar to the GPS (in the quote below). But I would like more thinking about that, or any other ideas that would be simple to progress the quality in a community way.

This may not be totally correct but reflects the original design:
"But the key is the Reason is there for the you to explain to the next user why you believe your action is more correct than what was there previously. It is to convince the user why they shouldn't change it, delete it or restore it. The desire is to evolve the conclusions over time to become more and more quality. The changelog tracks the change, attribution (user and date), and the user's reason for believing they have made the conclusion more correct. Not perfect, and short of having a full genealogical proof standard that interwines person data, sources, family's, narrative it's a simple approach that hopefully most users can grasp."

LegacyUser

Juli said: Thanks for the new thread, Joe. This was rather a sidetrack on that other thread.

My proposed (wished-for?) logical model:

1. A conclusion has a current value, connections to citations and notes, and change events.
2. Citations and notes have current contents, connections to conclusions, and change events.
3. A change event has an attribution, date, reason, and before-and-after values.

Restoring a conclusion (or citation/note) is another change event; it puts the "before" value from a previous change event in as the current value or content.

A conclusion may be an entry in Vitals or Other, or it may be a relationship. Citations or notes connected to a relationship conclusion should appear on the relevant collection pages (currently labeled "Sources" and "Collaborate") for both persons involved.

---
This would separate the functions that are currently conflated in the reason box: "why the change" and "why the conclusion". I basically propose that your reasoning ("why the conclusion") goes in a Note, and I would like for Notes (as well as Citations) to be connectable to any conclusion, anywhere.
The change log comment ("why the change") belongs in the change log, not displayed next to the current conclusion as it currently is; without reference to both values (before and after), such comments are generally senseless non-sequiturs.

LegacyUser

Paul said: The fact that the reason statement added with the Marriage Event details STILL remains hidden is the biggest problem that I experience. We have been able to clearly see reason statements for all the other "vitals" as well against Name, Sex and Other Information fields for quite some time, but the reason statement against the Marriage input remains the exception. No wonder it is often ignored / replaced by other users.

LegacyUser

m said: I would like to see the reasoning statement box enlarged so that a better idea of how much information is there is presented to the viewer.

Right now an entire source link might be visible if it is short but the end of a long source link would not be visible and any quote I have after the link is not visible.

Many times I have very long detailed reasoning statements with multiple links and quotes. (But you can't even see the end of the first source link.)

LegacyUser

Paul said: My other problem is the apparent nonsense of a statement when an a source has been tagged to the birth event. The comments I make when adding a census or death record often don't make any sense when I find I (or someone else) have (has) inadvertently tagged / linked them to the Birth reason statement. Moving birth details across when adding a death / census source does not always prove to be a good idea!

LegacyUser

Paul said: Returning my first comments, I believe the enhancement that led to the clear display of reason statements was one of the best the engineers have made in recent years. It even saves me making comments in the Collaboration section, which other users would probably not notice, anyway!

If other users have doubts about my birth / death inputs, there is my "justification" for making them, directly under the event - not hidden away in the Sources or Collaboration sections.

Relating to this, I think it is probably not a good idea to allow users the option of switching-off Detail View, in either the Vitals or Other Information sections.

LegacyUser

m said: Keeping Detail View "on" permanently is a good idea.

LegacyUser

gasmodels said: This is a comment relative to Adrian's comment above. I did not comment beneath because I wanted to add some images. In particular with regard to Issue 3, it seems to me the system really does handle reasons correctly for changes to Vital Information. If for example you edit a piece of Vital Information, say a christening and click on "See all changes" at the bottom of the edit screen, the system will give you a list of all changes with the associate reason statement for that change. See the images below.



not the result of clicking on the see all changes link



This clearly associates the reason statement with each change and does not require any retention of previous statements to understand what was changed and why.

If I am missing the issue you are attempting to discuss, please let me know.

LegacyUser

JT said: I disagree. I want it on for Vitals, but off for Other Info section. The Other Info is already too cluttered without details.

LegacyUser

JT said: Whatever, the reason statement is a critical place to encourage everyone to take the time to type out their logical thinking. I agree Joe totally with your last quoted paragraph.

So how can we encourage people to put in descriptive reason statements that use GPS principles such as addressing any conflicting info, or stating what exactly does match?

If FamilySearch would please teach all teachers to NEVER EVER give a bad example of glossing over the reason statement. Even during a RootsTech recorded class, I saw a live demo of the teacher giving this merge reason: "Same person". UGH!!

LegacyUser

Adrian Bruce said: For me, there are 2 issues with invoking the filtered Change Log. Firstly if this profile is the result of a merge and the previous Reasons This Information is Correct were on the profile that is merge deleted, then unless I'm mistaken, it's really hard to find them - they're broken away from the later Reasons and I'll bet most people think that they're inaccessible. They're not but it might take some time to find the profile, never mind the changes.

The reasons need all to be in the same place not split between Change Logs on different profiles.

The other issue is that if the Reason This Information is Correct is to be one stack of text, putting the previous entries into a Change Log elsewhere seems to be obscuring the matter. Most previous entries in a Change Log are not directly relevant to the current values. However, text like "Source documents the Christening... " *remains* directly relevant so shouldn't be hidden away in a Change Log.

Those who are adept can use the Change Log for many purposes. It's those who aren't Jedi Genealogists that I'm trying to help.

LegacyUser

m said: On my non-LDS lines,it is rare to see someone besides me who left a reasoning statement.

LegacyUser

JT said: NONE of my lines (nor on other people's lies) shows anybody leaving full paragraphs on merges, nor even complete sentences on source attachments. (Except me)

LegacyUser

Juli said: I never write anything in the box when attaching a source. Ever. The reason I'm attaching it is that I believe it applies. That's just so bloody obvious that I absolutely refuse to write a single word about it.

LegacyUser

Jeff Wiseman said: I put this in another topic but it should probably be included here as well:

The "Reason" text should be the justification for ONLY the one change to a given vital. The field should be blanked when the next change to the vital is made, since the justification for a subsequent change will ALWAYS be different from the previous one.

On top of this, if you go back in and change the reason field on a vital, THAT IS NOT A CHANGE EVENT! It is only a correction to the contents of the previous change event that was recorded in the log.

For example, if you make a change to the Birth Vital and then go back 3 more times and do spelling corrections in the reason field only, there should NEVER be 3 more change events recorded for that Birth Vital in the change history log since the Birth vital was only altered ONCE!

The persistence of text in that field from one change event to the next is completely WRONG. It is a result of an attempt to hack the justification for the change OF A SINGLE CHANGE EVENT into some kind of vital derivation logic which is a totally different thing and needs to be handled differently! The derivation logic does not belong there because that text is unique to one and ONLY one Change Event that has been recorded in the change history log.

That reason statement is NOT an attribute of the vital (the way a description of how the vital is derived from sources, etc). It is an attribute of a Change Event, and by mixing apples and oranges in the same field, it will never come across as an easy to understand entity because it will always be schizophrenic. On the surface it looks simple, but the way it is typically understood by people using it is frequently wrong (And they won't find out about it until data they entered appears to have disappeared from the edit screen for the vital)

Anytime a person goes into the system and wants to know why a vital has a particular value, YOU SHOULD NEVER HAVE TO GO INTO THE CHANGE HISTORY and attempt to gather together all the pieces that contribute to the conclusion. That text is only for the justification for those change events. You should be able to go to the vital and immediately see there either an attribute saved with the vital or a NOTE attached to it that fully describes the complete derivation of that vital's values. If the derivation is dirt simple (i.e., a source is a birth certificate and it is tagged to the Birth vital) the simple tagging of sources is more than adequate.

If you need more that that, put the derivation logic into a NOTE titled with the vital name--and BETTER YET, add the ability to TAG that note to the vital in an identical fashion as the sources are at present.

LegacyUser

Adrian Bruce said: Now that's shocked me Juli. So where do you record the logic that says "This is my Fred Bloggs of Much-Binding-In-The-Marsh and not his cousin of the same name because ...."?

LegacyUser

Adrian Bruce said: "Anytime a person goes into the system and wants to know why a vital has a particular value, YOU SHOULD NEVER HAVE TO GO INTO THE CHANGE HISTORY and attempt to gather together all the pieces that contribute to the conclusion. "

Absolutely. That probably expresses rather better what I've been trying to say.

My idea of "stacking" reasons is effectively dismissed by your statement that "The field should be blanked when the next change to the vital is made, since the justification for a subsequent change will ALWAYS be different from the previous one. "

If we are to split "Why I'm changing this" from "Why is it this value" (as I believe we should) then that makes eminent sense. My stacking idea would make sense only if the split doesn't happen because it then allows all the stuff to be visible in one place.

LegacyUser

Juli said: If it gets at all convoluted, it goes in a note. Which reminds me: my wishlist includes the ability to tag notes to citations and vice versa.

LegacyUser

Adrian Bruce said: OK - I couldn't imagine that you didn't record it.

LegacyUser

Jeff Wiseman said: Adrian,

Yes. I was going to create an essential model for this part of the system in order to illustrate just how different these two pieces of information are, but I just haven't gotten around to it (it's a bit of challenge when I don't have a formal drawing tool on my system).

However, this CAN be seen in part when you consider the genealogical records database as a different system feature from the Change History feature. If you were to remove the entire Change History feature, the removal of that feature's LOGS would eliminate all of those "Reason for Change" texts, since that is where they are stored.

That would leave you with NOTHING formally documenting why any given vital has been given its value based on the sources associated with it! That's because the vital derivation logic belongs with the vital. It has very little to do with each of the little changes made in the EVOLUTION of that vital's value.

Although not necessarily the most efficient implementation (it adds a keystroke and another window), the following is just one way that this structure could have been better implemented in order to be understood easier by all:

• Remove the Reason statement from ALL windows where changes are made. For example, when you do an “Edit Birth” you will not see a Reason field (although you WOULD still see all the sources, and hopefully, NOTES tagged to it)

• After a person has completed editing a vital and then hits a “Save” or "Continue" type button, they would then see a new window containing the following:

• A read-only field showing the date this change is being made on

• A read-only field showing an exact From-To description of what is about to be changed

• A read-only field showing the ID of the person making the change

• An empty, WRITABLE field with a title such as “Justification for why you are making this change”

• The window is showing EXACTLY what is going to be put into the Change History Log

• The change will not be completed unless Justification text has been entered (I suppose that this could be optional in order to allow a change to be made without a justification).

• This same common window would now occur ANYWHERE in the system that a change is made that should be archived into the change log.

Again, I just took this off the top of my head so it needs a bit more thought, but the concept would make it very clear to all users that the text is unique to the change log for the specific change event that is occurring as they type.

Also note that if the ability to tag NOTEs to the vital (which I have requested many months ago), those notes would should up and be apparent BEFORE the Change Justification field ever shows up.

LegacyUser

Jeff Wiseman said: Juli,

In an essential model for this feature, the documented logic (e.g., a NOTE) showing how a set of vitals is derived from a set of sources is an Associative Entity. This means that sources are NEVER directly related to the vitals since the logic document ASSOCIATES the sources with the vitals (i.e., it sets BETWEEN the sources and the vitals)

Although the essential model above is ALWAYS TRUE, in reality, the bulk of all logic for how any vitals have been derived from sources is very simple and obvious (i.e., the Birth Event vital is derived from the Birth Certificate source). If the implementation of the essential model is done as a direct mapping of the essential model, you would have to create a NOTE for every single source to Vital association. Even if that note were empty, implying "This is obvious".

That is why the implementation models used by pretty well any genealogical software out there allows you to DIRECTLY attach (or tag) a source to a vital without the need for an entity to associate them together. However, to completely support the associative nature of the derivation logic for the vital when, as you put it, "it gets all convoluted", you implement it so that all those convolutions can be put into a NOTE and then attached or tagged to the same vitals that the associated sources are already attached to.

That is why in the FT you want the ability to tag notes to the vitals and NOT to the citations as you have suggested. Since the citations can be tagged to different vitals for DIFFERENT vital derivation logic reasons, tagging the notes to the sources loses the relationship information to the vitals that it applies to.

LegacyUser

Jeff Wiseman said: And regarding attaching sources. In the FS database, the pool of sources is huge. There is an entire search system set up just in order to FIND related sources. That makes it totally impractical to directly tag sources in the huge database to vitals on different people records. Note that this IS quite practical on smaller systems such as PAF, Ancestral Quest, Roots Magic, etc. and in fact, is the approach they use.

But a compromise is necessary in the FSFT. Instead of directly attaching database sources directly to vitals in the person records, we must attach any sources that may be somehow pertinent to a person’s record to the source list in that person’s record. The main reason for this is to create a “pool” of relevant sources that can be locally tagged to the various vitals of that person that they support.

If you ever have a source in the source list that is not tagged/associated with at least one vital, then it would likely be questionable that the source even belongs to that person (i.e., there is no simple vital derivation logic showing it’s relationship to a vital—i.e., a tag)

Which is also one of the reasons that “Other Information” items in the record such as Residences need to be source and note tangible as well.

LegacyUser

Adrian Bruce said: "If you ever have a source in the source list that is not tagged/associated with at least one vital, then it would likely be questionable that the source even belongs to that person"
True in theory. But lots of people seem to think that attaching the source to the profile finishes the job. Tagging is an optional extra to them. Or am I being unfair and this is stuff from a pre-tagging era?
Nonetheless, the quote is true in essence.

LegacyUser

m said: This makes sense to me.

Most of the time people make a change and leave the previous reasoning statement (usually written by me) in the box even though the previous reasoning statement says the opposite of the change they are making.

Which leads me to believe that people tend not to even look at the reasoning statement even though I usually have a link or two in there.

LegacyUser

Cherie Gardner Rawlings said: I always use and I have always used this field from the beginning. “Why this information is correct” is very understandable and should not be changed. Nor should extra clicks be added to get to this. Should it be stored in a more permanent way? Yes, but not if extra clicks are required to accomplish this. Making it harder to access just means it will be used less—which is exactly what we do not want.

By the by, there are places in the system where you have limited the amount of space in this field and where it can be down for days and weeks (meaning after filling in these fields the system does not save what I just wrote.) The frustration created by this also means it is used less.

I am referring to the places in the system where we click on the pencil & paper icon and try to add a reason statement as to why this child is the child of these parents or a statement that explains what proof I have that these two people were married to each other.

In earlier centuries this can be quite complicated to explain. For example, Sometimes I am explaining that a particular will mentions that so-and/so is her nephew. This needs to be the explanation as to not only his relationship to his parent but also his parent’s relationship to his grandparents. While I also try to add a pic or at least a transcription of the whole will as a source or memory or discussion or story it can be long or hard or even confusing to read.

It would be nice if I could tag discussions, stories, memories and sources to these particular spots.

LegacyUser

m said: On my NM lines the majority of sources were placed by me and all those are tagged, so that is for sure correct that if it belongs it should be tagged and shows up in the vitals section somewhere.

I spent a lot of time detaching sources that are records unrelated to the person, usually similar name records. Jose Nevares in Peru instead of NM, for example.

If I understand Jeff's idea, he is saying things like Residence could have a tag and the source could be visible on the Right hand side---that is a great idea!

For example, I have one ancestor who all we know is his Residence in such and such year, but we have a record. So that would actually help the whole line if I could tag his Residence because there are 4 or 5 males of the same exact first and surname in a row---so any way to differentiate is great, because the main problem on the line is just people confusing the same name males and putting wrong info on the wrong page.

LegacyUser

Cherie Gardner Rawlings said: For an example of what I am referring to see Robert Sontley, Sr. GQYS-GRP

LegacyUser

Jeff Wiseman said: yea, and when someone goes and undoes a change you have just made, Their reason for changing it back (that is identified with their ID) is the reason that you gave to set it to where it was prior to them changing it. That is impossible to figure out while looking at a change history. Why would somebody be undoing something for the exact same reason that I just did it for in the first place?

The reasoning statement for each change event is different so you should start out with a blank field (i.e., you are creating a brand new Change Event with a new time stamp, and new description of the change, and a new justification text for why you did it.)

LegacyUser

Juli said: What Jeff is talking about is not the "reason this information is correct", but the "reason I made this change". These are very different things, even though they're combined/conflated in the current system.

LegacyUser

Juli said: Jeff, I want connections between notes and citations in addition to connections between notes and conclusions (and between citations and all types of conclusions).

But that brings up another important point: don't conflate sources and citations. What you attach to a profile is a citation, not the source itself. There is absolutely no reason a citation can't be "directly related to a vital" (or other conclusion).

Also, it greatly simplifies things if the associative "logic document" is simply the linkage itself, that is, the bare existence of the tag is the logic document. Anything more complicated than "birthdate from birth certificate" belongs in a note.

LegacyUser

Jeff Wiseman said: I try to not confuse those items but sometimes I find that using the less correct terminology that FS has on the site, it makes it a little easier to grasp to some. But yes, I will forget occasionally.

your last paragraph is also reflecting my third paragraph of this current thread. The logic IS in fact, the entity that associates the sources with the vitals. But when the majority of all derivation logic for vitals is basically "Look at this source. It should be OBVIOUS", you shouldn't have to document that in a formal entity when a tag by itself does the default for this logic. So you connect the source directly in all cases, and then in those few that need the extra documentation, You just add a note as well.