The Reason statement - thoughts

LegacyUser

Adrian Bruce said: Indeed. While "reason this information is correct" is clear to me, where is anyone supposed to put "Standardising place name", which is equally important? Or, "Named after her Aunt", which is equally important? There are all sorts of options and people end up using the same item, I'm afraid.

LegacyUser

m said: exactly.

these same reasoning statements i have created will sit there for years as people make all sorts of changes that have nothing to do with the reasoning statement in the box.

sometimes i have direct quotes from multiple sources such as original records.

the other day someone changed the name of an ancestor and i had so many links and quotes from sources inside the reasoning statement box that i thought well no one looks at the reasoning statement and the reasoning statement box can't be improved so what else can i do? so i made a discussion filled with even more sources and quotes and a custom fact. i'm not sure if i need to make a story or do the same to the siblings because the siblings are also always having their names "corrected."

LegacyUser

ATP said: Jeff Wiseman,

What you say in those last two paragraphs! Especially the fix in the last paragraph!

LegacyUser

Jeff Wiseman said: Well, it would be useful in a couple of ways if you could tag notes to vitals, but like many people. I have been using notes to document vital's derivation logic for years, both in FS and in other sites and 3rd party tools. They ALL have the concept of a Notes list for a given person record. GEDCOM files have this same common structure. Moving data from FS to other locations and 3rd party tools on PCs is a cinch when I do this because it is using a common structure that everything has.

This is just ONE of the many reasons that I will NEVER fill the "Reasons this data is correct" field with Reasons the data is correct (i.e., the documentation on how the values of the vital are derived from a specific set of sources). Those fields are ambiguously defined and are proprietary to FS. There is no traditional "standard" that they match.

There are other reasons of course, such as the fact the detailed logic that you spend so much time on will DISAPPEAR the next time someone makes a change such as "Standardize date". There is also the issue of the severe clogging of the change history logs with all of that long text. Even when I can see 30 changes in the log on my screen, it is still very cryptic trying to understand what has happened. When you start getting verbose logic descriptions in those fields, now I can only get 3 or 4 changes on my screen. Now you have to scroll back and forth through 10 times as many pages in order to find anything.

Most other places too, can not tag notes to vitals so they have always been referenced by title. I.e., a note containing information on how the Birth vital was derived from 3 specific sources would simply be given the title "BIRTH" which then "virtually" tags that note to the Birth vital. I feel that if the ability to actually tag those notes, then as people see it and recognize it's benefits, they will start to use it.

The whole notion of NOTES has been diluted with other FS proprietary places that look more like they should be where that information is put. Discussions are one place. These "Reason" fields are another. This should not be happening, and as it does, functional entropy continues to grow in the system.

Any collection of information on vital derivations that I have to collect and put together is NOT going into the wrong place where it will likely disappear. I will put it where it belongs, where it has always been traditionally, and in an equivalent place that most other genealogical tools already have but FS is ignoring.

And my "Justification for the change being made" text that I put in will only be fairly short, since any really detailed stuff is already in a NOTE for that same person, and I can simply refer to that note (or a change that was made to the note) in the reason for change field.

LegacyUser

Adrian Bruce said: I do wonder if there is scope for an investigation by someone with synching software, into the loss / retention of information when round tripping out to a PC based system and database and back. Or vice versa. Might prove worrying.

LegacyUser

Paul said: One of the things I have never examined properly (though I imagine it relates to tagging) is when the comments I enter under "Reason to Attach Source" are carried over against the vitals and when they are not.

For example, I put a comment when adding a census source and it gets placed against the Birth field - not a particularly good idea when my statement doesn't relate to the person's birth at all! ("Elizabeth was John's stepmother" added to the reason statement beside John's birth??)

Then there are the occasions when I do add a birth-related source. I dutifully add the statement, "GRO index shows mother's maiden name WILSON", then find I need to add this again in the Vitals / Birth "Reason This Information Is Correct" field.

On another issue, when a merge is involved, I really do find it difficult to add anything other than "Same person / family / event". What more can I say when the information against the person on the left is identical to what appears against the person on the right?

As has been highlighted, "reason statement" fields appear in various places / when performing different actions in Family Tree, so we are really dealing with a few different subjects when discussing their application.

LegacyUser

Jeff Wiseman said: Already looked at some of this. Although some packages like Ancestral Quest will allow you to view FS's change history on many attributes, they will NOT sync that data in. Again, it is because it is change history data and not actual genealogical data. Genealogical data has the same basic structure wherever you go. But the change history mechanism is different on each application, if it is there at all.

By teasing users into using Change History Events to document genealogical vitals derivation logic (which properly belongs in a different place) the FSFT is becoming less compatible with all other platforms. It is also taking a data type that belongs in a single, expected, and easy to find place, and scattering it through other unrelated storage places, leaving the CORRECT place devoid of documentation.

LegacyUser

ATP said: Jeff Wiseman,

".....FSFT is becoming less compatible with all other platforms.... taking a data type that belongs in a single, expected, and easy to find place, and scattering it through other unrelated storage places, leaving the CORRECT place devoid of documentation."

That to me explains why FSFT is so unwieldy with far too many transactions having to negotiate that scattered data to find pertinent information instead of being targeted in a straight line as possible.

If I understand what you are saying, it seems to me that there are 2 concepts in familysearch trying to work together as a single concept. 1. the genealogical vitals which is the blood line and 2. family history stories which is the narrative of those blood lines.

The genealogical concept by authenticating the blood line with ratifying documentation, whether a husband and wife with no children, husband and wife with one or a dozen or more children, or single, is the only concept necessary to seal families together.

The family history may have and often does have authenticating information but it is in narrative form and as I see it should be treated differently and not part of the process to "prove" blood line.

Not sure if I'm being clear in what I'm trying to say, but, I do think that both concepts can be designed to effectively and efficiently work together. What you say?

Thanks again, for your insight.

LegacyUser

JT said: "Juli - 2 days ago
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."

Well we don't just want to know if you believe it applies. In fact, we don't want you to state just something totally useless & over-simplified. But WE DO want you to state WHY you believe it applies. Exactly WHAT matches and precisely how well does it match? Is there anything else that is missing or doesn't quite match? Why still go ahead with it? What did you find useful about it? What is your strategy here/today?

LegacyUser

Juli said: Jon, as I clarified already, if the reasoning is anything more complicated than "birth date from birth certificate", the details belong in a note. Reason statements are just too volatile/transitory for actual reasoning, and the ones for attaching a source are particularly ambiguous in their presentation: is it a change log note, or a conclusion-derivation note? That's why I refuse to use them.

LegacyUser

Jeff Wiseman said: Because of the natural overlap due to the similarities in the different types of data, it is easy to confuse where stuff should go, especially if the User Interface implies a direction that is not consistent.

When a specific piece of information is documented in a system, it needs to be in one place only and logically easy to find. The minute that it can be recorded in two different place, you now get the possibility of differences and then you can't tell which is the "Real" data. That's one of the main reasons I believe that the "Life Sketch" does not belong on the main details page--ESPECIALLY at the top, since by definition, it is not even a VITAL.

You are basically correct, but the two concepts that you refer to aren't exactly what I was talking about. In a sense, for record keeping in FS, there are more like 4 concepts (or major features) in the system that work together.

1. There is the general family history information system know as "Memories". This is were family stories, lore, pictures can be easily be collected. It is also for certain information that can be used as sources for the FamilyTree (e.g., photos of family bible pages, will, or journal entries) that would not be available to the general public otherwise. They can also be used in searching for other sources, but they tend to convey more of the "Family Spirit" through knowledge of the individuals and families involved

2. The Historic Records collections. This is the massive pool of sources that is available for use in uniquely identifying persons (via their vitals) in the FamilyTree. This is done by attaching appropriate sources to person records in the FamilyTree, and tagging them to that person's vitals who's proof of correctness is derived from them.

3. There is the FamilyTree where the formal ancestry and genealogical records for individuals and their relationships to others are kept. These are all of the vital conclusions derived from formal Historic Records and other sources such as those in memories) that when combined, UNIQUELY IDENTIFY different persons. Any documentation that shows a direct correlation between sources and conclusions here obviously has to be a part of this. The reason a specific date and place for a vital such as a birth (i.e., the "Reason this information is correct") goes here.

4. There is the Change History system. This is basically a collection of files that track where, when, by whom, and details of each change that are made to shared information (such as vitals) in each of the systems 1, 2, & 3 above. In addition to the ability to document what the change was, a Justification (i.e, NOT a proof) for why the change was made is part of the change details.

So the "Reason information" in system #3 and system #4 have been glommed together.

It is significant to also recognize that item #4 is a basic type of Configuration Management (CM) system. Because of their significant value (when implemented correctly), there is probably not a single engineering organization out there anywhere that does NOT have such a system for tracking changes in their products. In fact most places I've worked have had two or three of them at least.

Sometimes it can be in the form of a Change Request system where a requested change is initially submitted to a committee for approval. However, in order to evaluate and prioritize the change, THERE MUST BE A JUSTIFICATION FOR THE CHANGE. If a justification is not provided, the change request will be rejected.

But again, this is NOT the reason that the new data for a given vital in system 3 "is correct". That information is documented in System 3 and NOT System 4

LegacyUser

Jeff Wiseman said: I agree completely with Juli. You attach the source, and (if not done automatically already) tag it to the appropriate vital(s). If a more complex derivation is required, it belongs in a note. If not for any other reason than a complex vital derivation is almost CERTAINLY going to involve *OTHER* sources! That information cannot be properly placed in a field dealing with only one source.

The issue is putting the information into the correct place. if you had to document justification for source attachment, if can slow you down by up to 2 orders of magnitude. A total waste of time spent to put information in the wrong spot and where it will likely be blown away sometime in the future.

LegacyUser

JT said: I don't understand this business about adding a "NOTE" (under the "COLLABORATION" tab). Notes can be deleted/edited by anybody, and they're not automatically connected to any particular change or source. Why does it have to be so hard to describe why you're making a certain change? Or what matches from a certain source you're attaching?

LegacyUser

Juli said: Part of this discussion is wishful thinking: how things *should* be, rather than how they are. But part of it is how to deal with the faults of the current setup. One of its (major) faults is conflating the change log with derivation logic. I prefer not to put my derivation logic in any reason box, because eventually someone (maybe even me!) *will* use it for a change log reason, thereby relegating my reasoning to the deepest depths of the change log, never to be seen by mere mortal FS users. Yes, notes can be edited, too, but there aren't competing purposes to be dealt with -- people have no motivation to change a note unless the note actually needs changing. No, the current system doesn't allow a connection between notes and conclusions; it's a case of "choose your evil". I guess I put more weight on clarity of purpose than on explicit/prominent linkage.

LegacyUser

Adrian Bruce said: Jon, as Juli says, a lot of this is how we would like the system to work. I'd suggest, for instance, that just because we refer to a Note, it doesn't mean that it has to be physically created on the Collaboration tab. It might, just might, make sense to have it created on another screen as part of the whatever it is process that you're going through and then it simply ends up on the Collaboration tab after, perhaps with the User's text prefixed by some system generated stuff that makes it clear what the note is about. That way you wouldn't need to interrupt your thought process.

None of the above should be taken to mean that one of Jeff's note types should be handled like that. I simply offer it as a possiblity that might be considered IF it made sense.

LegacyUser

ATP said: Thanks for going into such lengths in your explanation and I do understand what you are saying and it greatly helps in clarifying my thinking on the whole of FSFT and how it came to be as it is.

However, I'm still not very sold on the idea of the change log! I see the necessity in a profit making enterprise, but, as constructed in non-profit FSFT not so much, at least as it presently exists.

Too, like you, I think the Life Sketch is in the wrong place having had one deleted 2 times by the same person (who appears to not have read it) when I finally realized it would be better off in Memories and linked to from Sources. So far it has remained there. I think people are more reluctant to remove sources than other kinds of information. Or, maybe, because they have not even bothered to read the sources, which seems to be the case in my own part of FT. I have discovered that the more sources from the Historical Records Collections of FS I have attached to a person and/or family, the more duplicates pop up and I can merge them. A big plus aside of the obvious authentication of identity.

LegacyUser

David Newton said: Whether a changelog is needed is NOTHING to do with whether for-profit or non-profit is an organisation's structure. What determines if a changelog is needed is the usage case and structure of the system. FSFT is a classic case where a proper changelog is needed and also does not exist.

LegacyUser

Adrian Bruce said: Agreed. Debugging is debugging - and I use the term in its loosest sense.

LegacyUser

Juli said: ATP, a changelog is needed because of the open-edit setup. It has nothing to do with profit or lack thereof.

LegacyUser

Jeff Wiseman said: In FS, when multiple merges and changes have been made that are incorrect, it is nigh impossible to figure out what happened in order to undo it. If proper "Justification for the change" statements were included, it is also much easier finding elements in the change log that don't correctly apply.

On nearly any project or the use of any database, having a log of changes made along with their justifications is always extremely useful as long as the change history logs are not ambiguous and are COMPLETE (i.e., that is why a record of a change in a change log must be permanent and unchangeable by normal users of the system--it tells the TRUTH of what happened and not someone's particular opinion of what happened)

LegacyUser

m said: As 1 example of what Jeff is saying, recently someone utterly destroyed a person page.

One of the things they did was to remove almost every custom fact.

In an attempt to reconstruct the custom facts, I tried to punch "restore" to restore the ones that had been deleted. I had to do it from my own personal memory of what custom facts I personally had placed, I could not figure it out from the change log.

LegacyUser

ATP said: m

I hear you on using "restore" in the Change Log, especially when there are several pages of changes. Then I discovered that for me it was more often faster and easier to just start over. But, then, I only use FS Historical Records and records created from Memories such as obituaries and Bible records. Whether attaching or changing records from the commercial sites involves a more detailed process, I am not familiar since I do not use them.