Can we remove the ascribed parents of Robert Ellwell [[Elwell-166]]?

Question

Thank all collaborators for straightening out the ascribed parentage of Robert's wife Joanna. But it seems there is still some more work to do on Robert himself, for he currently has unsourced ascribed parentage that looks suspiciously like clones of his son and dau. in law, who have been moved to England and had ~40 years subtracted from their birth dates???

Aren't Robert and Joanna candidates for PPP status, to prevent these continuing battles.

Comments

Yes if Anderson says his parentage in unknown, that's a pretty good indication that they aren't known. Assuming no one pipes in here and objects, then a disconnect is in order. Afterwards Robert can be Project protected, just add a comment here afterwards and I'll take care of it.

---

Weldon, be sure to add a Disputed Origins section at the top that links to the disputed parents' profiles. This should be done before the parents are detached.

---

I have added the Disputed Origins section to Robert's profile, and disconnected him from the fictitious parents. I then changed the birth date of fictitious Thomas to match Thomas, son of Robert, and initiated a merge. Waiting for the Profile manager to approve the merge; the same process followed for wife Sara (Bassett) as well.

 Thanks for PPP status for Robert and Joanne.

---

Robert's PPP is all set.

---

The 'fake' parents of Robert have been merged away.

---

In the future, you may not want to merge fake people away. Instead use the {{questionable}} template and link to them from a disputed origins section on the purported child's profile. This discourages the profiles from being recreated.

---

The parents were obviously invented, so leaving them as first class database entries seems a questionable practice. Which is functionally preferable: creating an actual link to a first class 'fake',  or removal of such fakes (people coufused with other real people) and flagging the fictitious information in the purported child profile? Perhaps a short expert analysis of each approach could reveal an overall net gain for one over the other, but it is not clear to me as yet.

---

Also, Robert is now PGM PPP.

---

I'm not sure what you mean by "first class database entries", but it's been the experience of more than one wikitree project that when we delete or merge away fictional/questionable-existence profiles, it's pretty likely that they'll get recreated by an unsuspecting newcomer.  

When we leave them in place, appropriately labelled, then when someone comes along with them in their own database/gedcom and starts to add them, they see that a) they already exist and b) the warning serves to educate them.

 

---

I would disagree Jillaine.  Leaving profiles of non-existent people is not really in the spirit of wikitree.  To me it's junk and clutter that will decrease the value and reputation of wikitree.  We should strive for as accurate a tree as possible.

I would suggest to you that this problem of profiles being repeatedly remade has been greatly decreased by the restrictions on gedcom imports.  The problem was they were being repeatedly re-imported from bad gedcoms.  As it is now the profiles must be created 1 at a time, and they are blocked from doing so by Profile Protection.

With the gedcom restrictions, profile protection, and warning notes and explanations on profiles, we no longer need to keep profiles of imaginary people around.  If we need to occasionally delete a profile that slips through, I would rather do that than allow bad genealogy to exist on wikitree.

---

Jillaine, by 1st class, I mean a WT profile, by WT definition, a real, documented person. 2nd class entries might be links to free space, or some similar attachment.

---

Fictive people don't just result from bad gedcoms, though -- they also result from frauds, some of which have been widely accepted by entirely reputable sources.  Others result from name variations, misunderstood documents.  

IMO, these all need to be well-documented, or, as Jilliane points out, they WILL keep recurring.  And IMO, the best documentation is a fictive-person or fraudulent-person profile.  Because what's needed is something that turns up in any search for that person.

I'd rather be franker, and call it that, rather than "disputed origins."   Disputed origin should mean there's still doubt.

Speaking as a computer programmer who has been working with object-oriented code since c. 1986, I have no problem with a class of fictive person, as long as it's clearly distinct from the class of actual documented once-flesh-and-blood person.

So I'm with Jillaine on this -- if this person is likely to recur, then we should have a profile that documents that it's fake.   Functionally, that's what will turn up at the point of creating a new profile.

I generally check to see if the fake is on most of the popular genealogy sites.  If it is, I document it in strong terms AT THE VERY TOP OF THE PROFILE, as well as giving it the appropriate fraud or fictive categories.

---

Patricia, in my opinion, we cannot distinguish fraud from undisciplined overreach, nor need we. Both usually infect WT through GEDCOM, and SysOps is addressing this with a revised process.

it is a mistake for WT to bless any fictive relationship with full participation in WT connections. it is not a person that is usually fictive, but a relationship. Perhaps a new relationship qualifier, 'FICTIVE' could be added for the data field entry area, with perhaps some controls on who could change this flag. Then SysOps could ignore such links in relationship/connection finder and tree views of the data. Of course, still maintain a disputed origins category and flag the fictive parent in the child bio. (But no process can overcome the effect of a Project that asserts fictive relationships in its PPPs as a 'valid' research technique, as I have encountered here.).

Answer 1

I agree with the comments and the post above.  His parents and origins are unknown.  They need to be disconnected.  The parents never existed and need to be merged away.

If you go to ancestry.com and search for 'Thomas Elwell' with a birth date of 1592, you will see this is a very wide-spread error with no basis in fact.  There are over 1500 trees with this imaginary Thomas Elwell, one of which has been uploaded to wikitree.  The sources are always just 'ancestry.com trees' or actually sources which all refer to the real immigrant, Robert Elwell.

It is safe to:

• Disconnect the parents
• Put notes on the profile regarding the false parentage
• Delete the made up information on the parents
• Merge them into the son and daughter-in-law which is where the error undoubtedly, originally occurred. 

Comments

Thanks Joe. I love PGM Project. Yes, 1500 or 15,000,000 family trees on ancestry.com can all be wrong, for it is really only one confused researcher and 1499 copy and paste jobs. (I feel this deserves comment, because another project here accepts such massively popular fake news as fact, with a source of ancestry.com, and gives the resulting profile PPP status. I had to disassociate my name from that project.)

---

Weldon, I'm not going to guarantee that there aren't at least a few PGM PPP's with that error, but please if you find them with sources like Ancestry of someones gedcom, add {{PGM|Needs=Research}} to the profile

---

Hi Anne B. No fears, PGM is a great collaborative environment. Project has supported my requests to remove several undocumented ancestry claims in the treetops of my lineages.

My main concern with your suggested approach of merely leaving a flagged comment in such cases is that the 'fake' links can exist for some indeterminate time longer. And others can see these links as confirmation of fake news and perpetuate the problem in their own trees. In cases of unprovided sourcing (in the WT definition of valid source), I would much rather get an immediate decision from Project regarding disconnect of fake ancestry (here fake meaning anything asserted without valid source). Then the community can argue about it for generations, but absent real sources, the appropriate status quo is maintained.

At the risk of sounding preachy, I consider the profile linking fields to be absolutely sacrosanct, and WT is damaged as a credible source and repository of family information by any conscious decision to leave unsourced data in these fields. It's a big deal to me. OF course, links can be valid with only circumstantial evidence sufficient to build a solid case. I do this when appropriate. But simply defaulting on sources cannot be condoned, and time is of the essence to remove the unsupported data.

Love PGM. The leaders here are a vast source of information and exhibit a real willingness to share and discuss.  You and Joe above are great exemplars.

---

Absolutely, what you said Weldon. Please continue to bring your questions to G2G. I was really referring to those profiles that you run across that you're not researching or concerned with or don't care to work on, that might otherwise go unnoticed for a long time.

---

Anne, let me add that PGM has been fortunate and visionary in finding and  picking Anderson as the de facto legitimizer of genealogical assertions. An impartial Reference of well-researched fact takes the human bias out of first-line of decision regarding assertion validity. In another Project, I believe there is no such resource, so the Project leader becomes the de facto arbiter. And we all have bias that sometimes will obscure the obvious from our vision, particularly when we are too close and personally involved in the situation, as dedicated researchers frequently can be. I would hope that one mission objective of all WT projects would be to establish a 'Project Reference', some document or set of documents, to serve as a first-line decision support. Then follow up with a well-maintained list of known errors/omissions in the reference. Take human bias out of the initial process.

---

I concur with all of Joe's advice except for the merging away of the fake parents. See my comment above. Chances are that someone will come along and recreate them. But maybe the new gedcom approach will limit this.