Suggestion to improve collaboration and document quality of record in Family Tree

LegacyUser

ATP said: Jeff Wiseman,

If you don't mind, would you please advise the source for the following statement in your above comments? You've put it in quotes, so am assuming it is sourceable. Is sourceable a word? : )

'"Note that FS (like many other tools) has implemented the latter requirement as “any vital must be evidenced by zero or more sources”.'

Thanks!

LegacyUser

Jeff Wiseman said: m,

So when you have a situation like having 4 different censuses all tagged to the birth date, but EACH ONE has a different year of birth indicated, where do you document how you arrived at the birth year that is shown? In a formal genealogical proof statement, you must address ALL of the sources including ones that indicate a different value along with the REASON that the value given in that source is not correct but is still pertinent to the conclusion.

This Proof text is NOT a Life Sketch, it is NOT a research ToDo list, it is NOT a reason for any recent changes made to the profile, and it is not a discussion on the hunting for data for that Person Record. The current text there appears to be a combination piece of research notes and life sketch.

I'm not real familiar with how werelate.org works, but it appears to me to just be a single, huge note space assigned to that person record that could contain any or all of the above. I.e., it can contain anything. In other words, it appears to be the only Note for that person that you are allowed to have, and if you have a lot of different unrelated pieces of documentation, they have to ALL be stuffed into the same place.

ATP,

It's my statement :-) It's just the rule or name of the relationship as viewed from the Vital. I probably didn't need the quotes. The first two statements are requirement statements and the third is a chosen implementation or design statement. I guess I used the quotes to set it apart from the previous requirement statements.

LegacyUser

Jeff Wiseman said: M,

BTW, is the text in the middle of the screen supposed to be a Life Sketch? There is no label there identifying it as such. That's why I just assumed it is a general purpose location for Notes of any kind pertinent to that person record.

LegacyUser

Adrian Bruce said: ATP - re "Note that FS (like many other tools) has implemented the latter requirement as “any vital must be evidenced by zero or more sources”.'

I read that as Jeff contrasting this with the Requirements Engineer's view that “any vital must be evidenced by one or more sources”. And the "source" for that is that we can enter Vitals without tagging to a source.

FS is not alone in allowing no sources for any "fact" - in fact I don't think I've seen a single genealogy program that mandated them. The UK's Imperial War Museum, for the centenary of WW1, created a system (now read-only) that crowd sourced the compilation of info for the UK's WW1 servicemen and women. If I recall correctly that did require the entry of sources to justify every fact. However, the system was a ****** to use - not least because it was so different. (The finances were also an issue).

So I'm quite accepting of the idea that that FS implemented “any vital must be evidenced by zero or more sources”. But that's pragmatism possibly polluting requirements! :-)

LegacyUser

m said: The text in the middle of the screen at WeRelate is "Free Space for Whatever" just like Findagrave has a big blank space.

You can write whatever you want there.

Let's take Findagrave Blank Space as an example: You can write:
1) just a Biography.
2) just the Obituary.
3) just the name of his/her parents and grandparents.
4) just the name of his/her spouse and list their kids.
5) just the sources available for the person.
6) just something difficult to explain, like the fact that he gave all 3 of his kids the same first, middle and last names and say who each of them married.
7) just leave it blank with no writing (no blank space).

Same idea. Write whatever you feel is appropriate for that individual.

LegacyUser

m said: Look at the father's page.

https://www.werelate.org/wiki/Person:...

LegacyUser

m said: https://www.werelate.org/wiki/Criteri...

LegacyUser

ATP said: Jeff Wiseman, I thought that you might be onto something with that ZERO source mention!

I returned about a year ago to FSFT after a several year hiatus owing to more important concerns, only to find a completely different FS. That the sources I had submitted identifying and ratifying the families I had submitted for ordinance work had for the most part completely disappeared and most had ZERO sources. In the process I essentially have almost re-created the whole of the 5 or 6 family generations I had previously submitted. I am still at a loss as to how the sources disappeared. While there has been a number of merges, the biggest task, has been having to find and attach once again all the sources. Well, at least the FS Historical Records is a virtual courthouse and archive and doesn't have the costs of the original research! : )

LegacyUser

ATP said: Adrian Bruce,

The Imperial War Museum comment is quite interesting. Finances do have a way of limiting things! : ) If I ever get back to England, might check it out! It's probably closed at the moment.

IMO, I don't think FS implemented such a feature for vitals as ZERO sources. That somehow, it has turned out that way and FS has not quite yet figured out how best to address and solve the issue. As I say, JMO!

LegacyUser

joe martel said: Thanks for the discussion but 'm not sure where the FSFT requirement  quote of “any vital must be evidenced by zero or more sources” originates. This does not match the original requirements which are generalized below:


1. Ability to support one’s (User's) Conclusion by attaching a Source that may reference a record.
2. A Source can be added (Attached) to an ancestor, or hung off Vital, Non-Vital fields (yet to be implemented) through a SourceReference.
3. A Source may exist, unattached to a person or relationship
4. A Source can be tied (Tagged) to multiple Conclusion fields through one SourceReference. A conclusion field may be (Tagged) to multiple Sources via the corresponding multiple SourceReferences

The diagram presented above is generally close but doesn't illustrate the nuance of conclusion field types vs. value, nor the concept of referencing multiplicity.

In summary a source is a great way to support a conclusion but Sources aren't required, and in fact, different users would contend some Sources (like oral genealogies, living memory) don't pass their quality threshold - yet that may be the only proof of a conclusion.

And we all would love to have a full (quantity) tree with perfect quality. Something in between is the compromise we have to live with in reality and lack of evidence across time and locale. That being said, I do like to hear approaches to achieve both. Thanks

LegacyUser

joe martel said: Also, when nFS was replaced by FSFT, part of the migration was to bring over all the Sources (few were created by Users in nFS). This migration still took weeks and I'm not aware of any situations where FS lost Source in migration or features, like Merge. The only way to lose a Source was for a User to cause it to be lost. If there are example where  Sources were  lost please post them. Thanks

LegacyUser

Cousin David said: Thank you. Your patience through much of this extensive, esoteric and complex discussion is appreciated.

LegacyUser

Cousin David said: Ah. I should forebear; however, there is the classic “operator error”. Having said that, we’re back to the inexperienced user and an increasingly complex system.

I was able to teach my mother how to use her flip-phone but was unwilling to risk
my life on a computer or SmartPhone.

LegacyUser

Adrian Bruce said: Actually Joe, in those 4 requirements that you list (for which, thanks) the words are things like "can". That gives an option of *not* attaching a source. And the option to not attach a source means that the designed system has a relationship to zero or more sources. Any system that mandates attaching things would have an implemented relationship to *one* or more sources.

As far as I'm concerned, living in the real world, as you say, my instinct would be to design and build a system like FSFT where source attachment is optional. I suspect that if source attachment were mandatory, then we'd have an awful lot of chicken and egg problems, particularly where the source isn't inside FS.

I can see the justification for the purist view that the general genealogical *requirement* is for mandatory attachment of sources, ie a "must" relationship to one or more sources. But I also suspect that any practical real world *design* would have optional source attachment, ie the relationship is to zero or more sources. Philosophical requirements need to give way to practical designs. (I was a coder and designer)

LegacyUser

Jeff Wiseman said: Joe,

Thanks for your thoughts on this. That quote (of mine) was not a relationship rule in an essential INFORMATION model (i.e. it was not a requirement). It was the relationship rule from an implementation DATA model that is typically how many genealogical tools are designed. I was presenting it to show how the same essential requirements model can be implemented in multiple ways depending on different technological and cultural needs, but all still meet the same true requirements.

In summary a source is a great way to support a conclusion but Sources aren't required

...which is exactly what my quote was saying only using information modeling relationships terminology.

If a source is NOT provided, any given conclusion is MYTHOLOGY and cannot be trusted. Facts are Facts only when they can be shown as such. You cannot build things on foundations that have no basis. Therefore, this implementation of the historic, real world problem domain for genealogist is technically wrong.

But be that as it may, by making a design choice to allow for totally unsupported data to be added to a person record in the tool, you do provide a flexibility that can assist new learners as it is more forgiving when correct workflows are not completely followed. I have no problem with that as it is just the priority of another requirement to be user friendly to novices causing a trade off in the final design.

But when things start getting complicated and some solutions seem to be really elusive, you HAVE to go back to the essential structure of the problem domain to truly understand what is going wrong. If you do not have people with the skills to do that, you end up putting lots of features in and just trying them out to see how well they work and then evolving them through constant tweaks to get them where they finally become acceptable.

The "requirements" that you list are not really essential requirements. Even in the few items that you listed, they contain implementation specific entities (e.g. the SourceReference entity). "Tagging" and "Attaching" are also both Design implementation choices that in this case are used to implement the essential requirements related to the relationship between sources, proofs, and conclusions. If you had a totally different or custom database technology (such as an object oriented database), you might not even need those items--meaning that they are not essential, they are just a technological way of implementing what IS essential.

Remember, there is only one essential model based on the structure of the problem domain. A requirement engineer's job is to identify it and document it. But there are an astronomical number of implementation (design) models that can meet the essential requirements of the system. It is the Designer's job to pick and chose the most appropriate approach to take as they build the design of the system to be implemented.

The diagram presented above is generally close but doesn't illustrate the nuance of conclusion field types vs. value, nor the concept of referencing multiplicity

Agreed completely. But I would only need to add the relationship rules to it to show multiplicity. And the nuances I was trying to avoid. I was trying to make it simple enough to get the point over. I could create a very compact set of diagrams to show the essential model here, but then I'd have to go through and also define all the taxonomy for it.

And since all my verbose contributions to this topic have probably been putting people to sleep or driving them away, I suspect that I've added more nuances than needed at this point :-)

LegacyUser

Tom Huber said: Excellent points, Jeff. Joe wrote

different users would contend some Sources (like oral genealogies, living memory) don't pass their quality threshold - yet that may be the only proof of a conclusion.

That is certainly true,

that some sources may be the only proof of a conclusion.

LegacyUser

Adrian Bruce said: "since all my verbose contributions to this topic have probably been putting people to sleep or driving them away" :-)

I would similarly apologise to anyone tired of my discussions on these and similar matters - my excuse is that this is a Community and some of us do like this sort of thing in the vague hope that we might come up with something helpful that illuminates things for us all.

LegacyUser

Tom Huber said: There are often excellent points made in some very long and verbose posts. I don't mind them and sometimes find some real gems of wisdom.

LegacyUser

Juli said: I couldn't decide which subthread this best goes with, so here it is separately.

In Jeff Wiseman's excellent discussions (with pictures!) above, he notes that the current implementation on FS is "zero or more sources". As has been said, this is a practical/pragmatic design choice, and it is not unique to FS. However, I think it's possible to re-interpret the current implementation such that all conclusions do actually have at least an implied proof: "personal belief of userXYZ on [date]", or for vitals that have had multiple contributors, none of whom attached a source citation, "personal beliefs of user123 on [date], user456 on [date], and user789 on [date]".

It should perhaps be emphasized that the use of the word "proof" here is the mathematical one: "the logical argument supporting a statement". It is not the colloquial meaning of "a statement providing absolute certainty that something is true".

LegacyUser

Adrian Bruce said: There is indeed that way to come up with "one or more sources" rather than "zero or more" in an implementation. However, I'm not sure how useful that tactic would have been when it came to converting stuff from nFS into FSFT. More constraints given to us by the real world.... Sigh.

LegacyUser

Juli said: The implied proof on legacy data is something along the lines of "imported from nFS on [date]".

LegacyUser

Adrian Bruce said: That would work.

LegacyUser

Juli said: I would argue that there is an essential reason for allowing an empty proof: otherwise, you end up with a chicken-and-egg problem of not being able to enter a conclusion because there's no citation attached to it yet, but not being able to attach a citation because there's no conclusion to attach it to yet. The process needs to allow for different workflows, and not-yet-filled-in fields are part of that.

LegacyUser

joe martel said: Juli illustrates one of the nuances and problems with a citation. Is the citation attached to the conclusion field(s) (say Birth) or is it attached to the conclusion value (Jan 15, 1900; San Diego) or some part of the value? 

Today the FSFT citation (Source) is tagged to the conclusion field, not the value, even though it looks that way. This affords the user to see Sources about Birth, to let the user make a conclusion later after tagging one or more Sources. The UI in the FS products don't show tagged Sources if there's not a value there, but the Source is Attached to the Person, and is tagged. The design showed Sources for tagged conclusion fields whether there was a value or not.

LegacyUser

Adrian Bruce said: "I would argue that there is an essential reason for allowing an empty proof: otherwise, you end up with a chicken-and-egg problem ... "

That would be my concern. Though it is, I suspect, very much a (pragmatic) Design reason rather than a (rigourous?) Requirements reason.

Certainly, the way I work in FSFT, I've already done all the "proof" work in my desktop system generally using Ancestry or FindMyPast. When I come to reproduce the work in FSFT, things sometimes go awry because of the different indexes that FS have compared to the ones that I used and I end up entering some of a family manually with no sources, copying from my desktop. Only then can I fire up a useful enquiry from FSFT to find the source indexes - there just doesn't seem enough data to make a successful query otherwise.

LegacyUser

Jeff Wiseman said: Actually, I was arguing that there was NOT an essential requirement for providing an empty proof. That would be a design consideration to allow it for flexibility. Yes, we need to allow for different workflows, but to me, the concept of entering a value before you have any clue whatsoever about it origins in the essential structure of things would normally be impossible.

You might think that if a person were to pick a date and place straight out of the air without any reason whatsoever, it could be used in their work flow as an initial "Guess" to be a placeholder until further evidence can found. But nobody EVER does that! They will ALWAYS have some kind of a reason to enter that value as a starting point, REGARDLESS of whether they document it or not. To allow the capability of entering a value with no logic or other evidence simply generates issues. What happens when the person comes back 2 years later and looks at that vital and can't remember why in the world they ever put that value in there.

And then there is the more frustrating one in a shared tree, where hundreds of other descendants of the person who has that undocumented vital come across it and can't figure out what it means. They will go chasing down location or date related rabbit holes and wasting a whole lot of time just to later figure out that that conclusion belonged to a spouse and had accidentally been recorded in the wrong person's profile.

I understand what you're saying about the chicken-and-egg issue. But of course it depends on how clever the designers are. In the models above, notice that I named the entity "Vital" and not "Conclusions". The conclusion is the value of a Vital entity. When a Vital is first created it has a null value--or rather a conclusion of "Unknown". Firstly, with no sources and related derivation logic assigned to the Vital, the conclusion of "Unknown" is perfectly correct because that is EXACTLY the conclusion that you would come to when you have no sources/evidence. Secondly, it could be implemented the very way it is with the sources being tagged to the Vital rather than its conclusion. This eliminates the chicken-and-egg problem.

And that exact same way of handling evidence (i.e., sources) can be applied to the derivation logic documents. in FSFT, this would be fairly easy by just allowing Notes to be handled in a similar way as Sources are at present (i.e., Tag them to vitals)

The fact is that the natural progression of things is from evidence with it's connected logic and analysis, to conclusion is ALWAYS how it works. Its a fact of life. You can't avoid it. Even if someone doesn't actually document their evidence or reasoning because it might seem really lame, trivial, or they are just too lazy to put it down, doesn't mean that it doesn't exist. That is a natural part of the problem domain for the tool. It is based on natural fact. That is why it is in the essential model.

So let people be as sloppy as they want in their own private trees. But in a shared environment there must be some social self-control and a willingness to abide by the rules that enable EVERYONE to benefit

LegacyUser

Carolyn Wheeler said: Well, all of your comments may be verbose, extensive, esoteric, and complex, but I sure am enjoying them! Thank you all!!

LegacyUser

Adrian Bruce said: It makes me think! And makes me think about what I'm thinking about.... Neither of which are bad things.

LegacyUser

m said: Comparing these two pages,

https://www.werelate.org/wiki/Person:...

https://www.wikitree.com/wiki/Cooke-3...

Werelate is a better system because when you click on the number next to a vital, it takes you to a Source for that vital, such as birth. You can see and find 1, 2, 3 etc. sources for a birth.

Meanwhile, the page on Wikitree, if you click on the arrow next to each Source, it takes you to the text above which the Source is a Source of. Werelate is just a bit better design.

And then if you want to compare with Familytree:

https://www.familysearch.org/tree/per...

What jumps out at me after looking at both Werelate and Wikitree is the Notes section...

...43 Notes...

...you would have to click 43 times!

...is anyone out there going to click 43 times to read each Note?

(Makes me think the Notes section on FS can go.)

LegacyUser

Jeff Wiseman said: Wow, that profile is a MESS!

The problems are not the fact that there are notes as much as the fact that they have been used inconsistently. Many of those notes are just source citations, and in fact are duplicates of many sources that have also been attached to that profile. Why attach a source and tag it to the different vitals, then turn around and create your very own custom citations using the Notes of the system. From the markings it is apparent that many were brought in into FS via GEDCOM.

Many of the notes are just biographical statements, many are duplicated, and most do not have any source references at all to justify their existence. And many of them that do have related sources, do not have them referenced in any way.

It is apparent that this is the result of many merges where some of those PID records have been electronically brought in from other databases. The "! BIRTH" type markers we're typical of old PAF records as well. Many people were bringing in records and no-one was doing cleanup.

PAF had the ability to define sources and citations, but it was always a bit involved. So people would put all their source citations and derivation discussions in the Notes instead (an easy way to get around not having to actually create source citations).

The Notes section of FS should NOT go away. Instead it should be set up in a way that redundancy with sources is easy to spot and clean up (e.g., support tagging notes to vitals as sources are done now).

And teach people to create SOURCE citations and not just use notes to cite different historic records.

When you put in text blocks where the block is defined as "whatever you want it to be", you are going to get this kind of chaos as well as redundancy due to duplicate types of information stored in different places.

And the ironic thing is that even with all of that "documentation", if you look at the change history on the various vitals, it is extremely rare that anyone actually used the "Reason this info is Correct" field. Here is just a SMALL portion of the BIRTH vital's change history:



There are many necessary explanatory notes (i.e., derivation logic for vitals) included in that collection which are legit. If you were to ban the use of Notes in FS, where would you record all of that information? In the Life Sketch? It sure doesn't belong there.

It's hard to keep your apples and oranges separated so that they can be found easily, when the people doing the work see them all as apples only!

And one last item is that there were some incorrect merges done a ways back. This brought the note all together for the 2 different persons. When this was cleaned up, you had two different persons again, but the notes were not removed from the incorrect surviving person of the initial merge.