Private tree that is separate from public tree
I think it would be cool if users had a private tree. The private tree would be separate from the public tree. Private information would show either next to or in place of public information depending on what type of information it is. Any work with public records would be stored in the public tree and in the individual who did the work’s private tree, but not automatically to everyone’s private tree (more on that later in the post). Adding private records or memories would only add to the public tree if the individual who added them explicitly decides to. Any public details that are changed would also only be changed in the individual who changed its private tree and the public tree, but not to everyone’s private tree automatically. For each detail or section, users can choose whether they want to “always sync”, “keep private”, or “sync once” (which would then change to keep private). This would be for both syncing data from the private tree to the public, and for syncing from the public tree to the private. This system would allow for the benefits of public records, like collaboration and sharing information, while allowing users to protect their tree from accidental mistakes. This also could be done without much work by utilizing existing infrastructure. In 2014 family search introduced Private Spaces.
Any private data or records could be stored in private spaces. Any private data in a private tree would be a pointer or reference to private spaces, and any data in a private tree that syncs with public data would be a pointer or reference to the public tree and records.
Comments
-
This sounds like a great idea since there are journals, stories and thoughts I would like to share with some people but not have “public.” Being able to make a choice on each piece of information would allow me to do this while still making most of my tree public.
0 -
If you don't like the way the world tree works, you can use a free account on Ancestry. Ancestry lets anyone build a private tree at no cost. Unless you are a Church member, you cannot read many of their sources, but you say what you want is a private space to upload information that no one can see. Right now FamilySearch doesn't work that way while Ancestry does work that way. In Ancestry, using a free account, you can create a private and unsearchable tree and upload anything you want. The only people who will see it is those known individuals that you invite to share your tree. Various levels for their access will be available to you. I suggest you work in each system according to the way the environments are set up. Another benefit to using Ancestry for this instead of FamilySearch is what happens when you die. After your death, Ancestry has a method for a close relative to gain access to your account and thus your private trees there. FamilySearch doesn't have such a process, and so after your death as it is now, one of 2 things happen: if you are a Church member, your death will eventually be recorded and your account with information will be public, excepting on work you did on individuals marked living, and, as I understand it, work on individuals marked living will be lost forever. If you are not a Church member, work you did in a private space (such as on live people or yourself) will be lost forever. (In both cases, you possibly can give someone your login credentials, but my understanding is that the Church locks the LDS accounts after a Church member is marked deceased.)
However, I would highly recommend if you have journals, stories and thoughts that you really don't want public, don't put them in a public space at all. Cloud storage (or back up drives) are available and you can give known individuals access to the files.
2 -
My analogy is that you want the bookstore to start lending books instead of selling them.
As Gail says, there are other websites available for keeping an individual, private tree. There are also offline software options, many of them available for free, and several of them able to synchronize with FamilySearch. (For information about your living family members, I am strongly of the opinion that those offline options are the best choice: the easiest way to protect private data online is to not put it online in the first place.)
2 -
FamilySearch actually already allows you to do this! All memories can be marked as "Private" when added, which makes it so that only you and anyone with the link can access it. If that doesn't work well enough, there is always Google Docs or similar sites.
0 -
A private tree can also be used as a sandbox to do what if and try out ideas without increasing data entropy. The later is major issue on FamilyTree has all users have to try out ideas on the public tree! The year of so I have used FamilySearch the number of people has grown massively but also data inaccuracy as increased faster. I spent 90% of my time correcting this on my tree! Data accuracy could be easily improved by automation!
- Start validation on all inputs including Human e.g. explain UK addresses to USA members, check date formats, Warn or do not allow a save to the public tree when (a) birth date is after christening, (b)death or burial dates, (c) christening after death or burial dates (d) death after burial dates . On my three is there are over 3500 of these alone!
- Start validation on all inputs including Human on family. Do not allow a save on the share public tree for (a) Child born before mother, father or before they can have children unless an exception is asked and flagged suggest a different background colour (b) Children born before parents marriage need to be flagged again I suggest a background colour change (c) Different surname of children to their father need flagging again another etc etc a lot more flagging and data validation could be done .
- Remove spurious field entries and of the wrong datatype. How is unknown string allowed to be saved in a date field for example? Remove all spurious data entry type not just put up a error flag!
- Delete all entries with name = ? with no useful data ! There are millions of them floating around .
- Colour code each person from red no attached docs to say green when every field has supporting docs or a approved genealogy person has approved them. Any number of colours can be used to show intermediate stages
- etc etc I have load more but that is enough to get on with
Moderators feel free to repost my ideas in any appropriate places within g the FamilySearch arena
The other thing about private trees and why suggesting users use ancestry is other apps is really not helpful is familysearch provides no direct way of downloading your family tree! Are you suggesting that people start again on anncestry? Download of family tree is necessary to support using FamilySearch with other tools so you may have a private tree!
1 -
PaulHarrison61 You have many good ideas, but there are problems.
Replys:
- People have always aged at their own pace. It is quite easy to find sources where someone self reported that they were born after the date of their christening. What you are asking is that these records be barred from being attached. That is not a good idea. Also, it was very common in many cultures to name a younger child the same name as an older child if the older child died. This could produce 2 christening records, and if the wrong one record is used for the younger child, you will most certainly have a correct birth years after the christening. This can also explain a confused person noting a birth after a death of someone with the same name and same parents and not realizing what happened. In a confused situation, you need as many sources as possible to sort out what the truth is. You do NOT need a random source to be the anchor for which all other sources will be judged allowable or not. In general, I applaud not allowing birth after death, but you see how it should not be regulated with a cookie cutter approach.
- I agree with a), but not with b) or c). b) Many children were born prior to marriage and many to a previous marriage that is undocumented. An older child in a census with a different name is itself a clue to an unknown marriage for the woman, and if the older child has the same name as the father, is a clue to some family issue OR to the father's previous, but unknown marriage. And then if there is a source, such as a death document, that names parents, then that document needs to be allowed as a source, no matter how much it upsets the nice family unit. You cannot refuse sources just because they don't seem correct. And this type of situation can go back before modern death certificates. Many states instituted death registers in the 1850s which named parents. (VA, for example) c) You really haven't thought this through, I think. If a child takes on the surname of its mothers later husband, then you will see a child of a different surname attached to a father. In the 1800s there was no formal adoption process, but you can see through consecutive census records when a name change occurred with a child. It is more correct to list both fathers with the relationship bio and step correctly set, but list the child with the legal name it assumed for life. That way you will match up later records, such as marriage and death, much easier when they all use the surname taken on in childhood.
- I have no problems with.
- ditto
- Um, many people don't realize they can tag, but not a bad idea.
Edit: I see you added another comment. I have trees in Ancestry and keep both those trees and my FamilySearch ancestors pretty much in sync by working on both together. I am not a Church member so can't connect the accounts.
0 -
Thanks for you reply with Gail.
What you have said in essence is the necessity of a private sandbox development tree allowing tree development. This is classic SW development issue where you may take a local copy of some of the code make your changes then do you own tests then release into the public code base for others to there tests.
The problem FamilySearch has and what is wrong with your reply (I still agree and understand with your reasoning) is the data entered on Familysearch is becoming less accurate every day. Although the reason i choose Familysearch was the share tree vision and documentation driven evidence this simplistic architecture and the merging procedure is ruining data accuracy . Without the necessary architectural changes and data validation Familysearch is becoming less and than less useful and becoming self defeating to its own objectives. I am spending 90% of time correcting data that could have been computer validated (std sw standards since the 1970s!] at source. It is particularly annoying for example USA and other folks thinking they are correcting UK addressees to include the UK centuries before the formation of the UK because Familysearch app incorrectly implies this! Its particularly annoying when family search merge process does not allow the correct result and overwrites perfectly good validated and non standard fields without informing the user first whats the affect this merges on other peoples records
0 -
PaulHarrison61 Note that what I talked about did not involved inaccurate data. It involved conflicting data. HUGE difference. What is your rule of thumb when you stumble upon conflicting data?
Yes, I understand, and have experienced, when people add information that is crazy and clearly mixes up ancestors who, in one case for me, lived a century apart. I also get place name changes. It is not only the UK that suffers, we have people born in the USA who lived in the early 1700s! Imagine that! And born in Kentucky in 1750! A miracle when Kentucky didn't exist until 1792. That is a different topic, I think, and will never be solved because there is a philosophy that the modern place names should always be used, and some people believe that. I steer clear of that as I am not sure all the time which is best. I also cannot address the merge. Others, such as Áine Ní Donnghaile or Julia Szent-Györgyi are more experience than I.
1 -
Irish addresses are worse! Even in Ireland there are many disagreement locally the name of local townlands and worse the correct spelling as it involves poor Irish translators documenting names incorrectly! Even worse some names are different depending on your tribe, religion and hance politics!
It is not possible in UK, Ireland and he rest of countries to use modern addresses simply because the Map has been redrawn many times and areas are moved countries many times. Countries have come and gone, countries names.
FamilySearch quite naturally tries to simply the real world into manageable and a more simplistic version of reality.
- Fundamentally even in relatively young countries like the USA there is a time element to addresses that cannot simply be ignored. So when referencing an adrress a time must be a part of the key in order to match against documents. Maybe burial location should be modern allowing living researchers find them with ease!
- Like all shared code, data it is not possible to allow unlimited release to the common base by any user and expect to keep any resemblance of data quality up. I understand Familysearch wants to void formal process however with is their are consequences. Maybe the background colour coding of each person depending on how many fields have veen backed up by documents of genealogists research is a half way solution
0 -
I haven't read further yet, but I had to comment on item 2.b. in PaulHarrison's post above: my grandmother and her elder brother (and their stillborn elder sister) were born before their parents' marriage. I do not want or need a flag about this fact.
Also, 2.c. shows that you're making assumptions about naming that are unwarranted in many parts of the world, such as Scandinavia up to the late 19th century. (In a culture that uses patronymics, if a daughter's surname is the same as her father's, it's an error.)
3 -
I'm not sure what you mean by "spurious data" in number 3 above, but removing it would make it very difficult for a human to come along and fix it. Similarly, I'd rather have unsourced data than deleted/unentered data: it's much easier to find things if you know what to look for and where/when.
A lot of the "clutter" in the tree is caused by legacy data: profiles entered into FS's previous systems. That's where all the wives came from with nothing but a question mark for their names, and that's the source of the baptismal-index-based tryptichs that are the reason I have so much (undesired) experience with merging. No amount of data validation will fix these things. That ship sailed over a decade ago.
It's true that people don't necessarily pay sufficient attention to the details. I just finished fixing a family where a descendant in South America found a profile with the right name and about the right date to be his beloved great-grandmother, and proceeded to attach photographs and burial information and so on. Trouble is, the baptism on which that profile was based shows a child who died at the age of three days. I can hardly blame the guy for getting it wrong: the baptismal register was in rather ragged shape when it was filmed, so the two-page spread doesn't really line up, and besides, nothing on the second page (residence, godparents, officiant, remarks) was included in the indexing. It's Very Hard to read handwriting in a language you don't know.
While I'm sure some of the errors in the Family Tree are due to carelessness, I'm also sure that a lot of them are like the one I just described: created with the best of intentions and under the belief that they're correct. And regardless of the cause of a discrepancy or conflict, it always has two ends. I fixed the South American great-grandmother by creating a new profile just for her, and detaching her husband from the dead baby, but I could instead have detached her parents and created a new profile for the baby girl. Preventing data entry based on previously-entered data preemptively discards half the options, purely based on who got there first, and I don't think that would be a good thing.
4 -
Julia from my earlier post
Remove spurious field entries and of the wrong datatype. How is unknown string allowed to be saved in a date field for example? Remove all spurious data entry type not just put up a error flag!!!!
OK i explain in non sw technie speak. Each entry box should have a corresponding data type.
e.g.1 Date of birth is date type which has format 4 July 1776 and should not accept text such as UNKOWN or a ? character
e.g.2 A name entry box should only accept alphnumeric characters and spaces and should not accept the ? as a name
Saying thats ships sailed about data validation is never a viable option, we might as well give up right now, A lot of non expert data handlers are suggesting better to have rubbish entered than good data (information)- Sorry this just leads to more and more data entropy and eventually getting overwhelmed by volume of bad data. This is the state of familysearch now and if something is not done about the site will become useless all together. Its like never tidying up the house or the garden and expecting to have a enjoyable life!
My ideas of flagging different people by colours for example different names, born before marriage can be option and where is not useful for some users it would be invaluable to others with large trees.
The idea of flagging different children names from father to mother for countries that take the female line for example my danish cousins
The idea of coding colours depending how many data attachments etc would also deter newbies from altering near perfect genealogical research peeps.
Thanks guys for a very thought provoking discussions. Good to get different and very valid perspectives. Thank you
0 -
I think you would find that if you took a poll of long term users of FamilySearch who are very familiar with past and current versions of Family Tree and who have witnessed past attempts at automatic data correction, they would pretty much all agree that those have typically lead to far more problems than they solved. The current database is such a complex combination of previous databases of various formats that trying to correct everything by just sweeping out old, previously valid data would be a disaster.
To take one example. All those thousands of ? names do have a valid meaning, are linked to underlying data in the database that is not viewable to all users, and need to be dealt with on a one by one basis, not just deleted en masse. Many of the ? mean: this is an extracted christening record from a parish record that contained just the father's name and the child's name, that the record was originally in the IGI, that there has been temple work completed based on {father's name}, Mother, and {child's name}, and best practice is to find the mother's name from other records such as marriage or census records, and correct the ? to the actual mother's name. Doing otherwise messes up the ordinance page display which, admittedly, not all users can see.
Regarding:
FamilySearch quite naturally tries to simply the real world into manageable and a more simplistic version of reality.
1) Fundamentally even in relatively young countries like the USA there is a time element to addresses that cannot simply be ignored. So when referencing an adrress a time must be a part of the key in order to match against documents.
The Family Tree's system of dual entry of all dates and places allows all user to reflect all the required complexities and messiness of history. I would assume that what you are referring to as a simplistic version of the world is just the incompleteness of the Places database. It may take decades, but that database is growing all the time and including more and more places with the proper time elements. In the meantime, users can put in the correct historical places names with just as much detail as needed.
Regarding:
e.g.1 Date of birth is date type which has format 4 July 1776 and should not accept text such as UNKOWN or a ? character
e.g.2 A name entry box should only accept alphnumeric characters and spaces and should not accept the ? as a name
The linked standard for the date box does only include the Day Month Year format. It is impossible to put anything else there. The free-form user-entered date value is designed to allow for the real world and the full richness of historical data like this:
And the name entry box does only allow certain characters as can be seen when trying to enter non-allowed characters.
3 -
"I think you would find that if you took a poll of long term users of FamilySearch who are very familiar with past and current versions of Family Tree and who have witnessed past attempts at automatic data correction, they would pretty much all agree that those have typically lead to far more problems than they solved. The current database is such a complex combination of previous databases of various formats that trying to correct everything by just sweeping out old, previously valid data would be a disaster."
Gordon thus simply means not only these mythical long term users not only will ignorant of best practices with regards to data and maintenance off but have not learnt anything either. Gordon data entropy problem all over the IT world! Shannon started formulating it in 1940s , The need of data validation of all input in software became apparent in the 1970s as did what became known as bad smells in programming. The affects of not managing data and data entropy formalized during 1980s and 90s . I can supply much more details but i think this is enough to show to you and other users this is a IT data problems and well known throughout software world and definitely not unique to Familysearch ! Pretending otherwise is just silly!
The wonderful goal of linking everyone in one shared family tree is absolutely brilliant. From the IT perspective it means linking nodes of data (the person) linking into a network (the tree!). The sw must support the goal ! Key to this goal the sw must get and validate or assist in data validation . Data is king!!!!
Presently (and as you kindly explained worse) Familysearch app is not even keeping a lid on data entropy in fact its actual design is making it worse! Now to be fair to Familysearch developers (who do have my complete sympathy as a fellow IT developer ) their task is massive in terms of data validation. But at the present without validation the amount of stuff on the system is increasing very fast but not necessarily good data. The garden needs weeding, the hedge needs trimming, the lawn is not only uncut it has weeds popping up everyway,
Gordon because keeping on top of stuff entered and making sure its data is yours and ever user main purpose and saying this task is too difficult whilst putting your head in the sand is not helpful. My suggestions are an attempt to be a practical step in the right direction from a life's experience solving similar problems problems.
dont get me started on locations as it a complete disaster and causing data entropy!!!!!!!!!!!!!!!!!! . Simply just copy what the best practices are. That is Definitely not bullying users into so called standardized places that are wrong at a particular time and will not match any documents from that era or force users to input location full location places not commonly used causing even more confusion!!
this note is probably wasted even more of valuable time as I fear you will not get it and those need to read it will not ever see it. Very frustrated Paul
0 -
good news folks I am done. Even your moderators do not follow industrial standards and eliminated me from my own posts due to "Agressive formatting" whatever that is! Again not following accepted standards within the industry! Just like a child taking home the ball because the other kids would not follow the kids own special rules.
You are losing a prolific contributor (not talker or obstructor) who made 25 712 documents attachments , added 5913 new people corrected 1000s of places names in UK and Ireland in the last year. A person who had improved the data quality of 1000s of more records by peeps who the Familysearch app had led astray!!! ( yet all here are in denial so I really question understanding or how often they actually use this app! especially with big trees) .
But with a life time experience of writing , improving, consulting bullet proof sw development what would I know!) . I really loved the Familysearch ideals of providing a free service and getting normal people tools to share and help each other. Unfortunately this doomed to failure if the attitude prevalent here continues.
My apologies ,very sincerely, if my forthright nature has offended anyone as it was not what I set out to do! I thank all who contributed to my family tree. Wishing everyone a good life and please please go and research about data! The texts are for all to read and widely available and even older than the internet! Although most of the most relevant ones were written in the 1970s and 80s by peeps of this generation! All what they incorrectly call AI is actually repackaged renamed version of this (used to be called mulit variablke correlation).
Without understanding data entropy and the necessary continuous improvement mentality required just to keep on top of data entropy family search will just become CICO )crap in crap out) and irrelevant and never achieve its goals. Just having humans do data validation and entry without tools to protect data quality has never worked in the history of computers.
Good luck and have a good life
2 -
PaulHarrison61 I think you should sleep on such a draconian decision. This is a Church sponsored forum, so the rules are more oriented to what we would expect on a playground, but that shouldn't make a valued contributor leave. There is no good idea that won't get picked apart by those of us who engage in the community, and I have had to lick my wounds several times. I know multiple people fundamentally disagree with my stance on several things and I, too, have had a post removed by an admin once as it was too critical.
Don't apologize. Pick up the sword and carry on. We always need new perspectives.
2 -
Gail,
the reason i am leaving familysearch are as follows
- the moderator heavy handed approach of closing off discussions makes these forum redundant.
- Familysearch now puts non standard locations has a red flag but not the execution! Some all they want is some user just select the location and save it without doing anything or adding any info! Automation here is not just possible but a must! Other ones means selecting a standard location from a very long list! Unfortunately the correct one is hidden at the bottom of a long list and even worse all the top options are pushing the user to addresses that never existed and will never be found on any documents!
- Every time anything is pointed out , the wagons are circled around and anything regardless of the truth or reality is posted in an vain attempt to justify old and usually incorrect past ways.
- Gordon may thanks for putting me in touch with the BYU folks. Their approach of an overlay on familySearch as a chrome extension may be work around the familytree limitations and lack of heed here.
- Sorry folks to be a harbinger of doom but a scatter gun and informal non validation of data approach has never worked since the start of data collection . FYI these methods were formularized even before computers!! Having an approach of getting something that might be good is ok for single family project but is a disastrously dangerous for a large scale data collection. Love the data sharing concept but some sort of release control is required for the shared stuff unfortunately.
- So sorry Gail this is why we must go out very different ways. Good luck and have fun. Done my bit in pointing out stuff and hoped it was stir up some action to solved the inherent problems. Got better things to do with my limited earthy time.
1