Unknown with no dates location is that an db_error error by itself?

+11 votes
165 views

Check profiles Unknown ==> Database error report

  1. No name
  2. No dates
  3. No locations

Question: Shouldn't we have an db_error that finds them? Or will the maybe coming "ranking" find them.....? 

Today on profile UNKNOWN-121821 we get 512 and 509 ==> is that enough.... if they just called it Unknown gender Male then it had passed under the radar

Error Link FullName Rel. Birth Death Gender   Link Name Rel. Birth Death Gender   Marriage False error Hide 30 days
512 Separators in first nameHelp UNKNOWN-121821 UNKNOWN   0000-00-00 0000-00-00   image                 False Error Temp hide
509 Missing genderHelp UNKNOWN-121821 UNKNOWN   0000-00-00 0000-00-00   image                 False Error Temp hide
 
WikiTree profile: Leroy Henderson Cox
in Genealogy Help by C S G2G6 Pilot (271k points)
retagged by Dorothy Barry
Besides that, should it not show up in db_error_107: Full name in UPPERCASE?
I think in this case these are well-defined people just waiting for names.  The 1900/10 censuses should be useful.  However, nobody can fix them as they're Green.
Putting it another way, I think it's going too far to classify "unfinished" as an error.
@Pierre,

Error 107 ignores Unknowns, since there is no point in making them look good.

@Magnus,

512 error shouldn't appear. I will recheck.

And this aren't empty profiles, there are relations to them.

2 Answers

+5 votes
Magnus, these will show up under db_error 901 or 902.

If there's no obvious place for them, we categorize Unknown profiles like these for recycling.
by Jillaine Smith G2G6 Pilot (692k points)

They aren't Unconnected.  Their parents are all hooked up to the big tree.

In fact they've got loads of ancestry

http://www.wikitree.com/genealogy/UNKNOWN-Family-Tree-121821

 

Re Horace but with no sources...... 

  1. if you check the imported Gedcom it creates 254 people 
  2. In the RAW file I don't find one source
    1. If I click around in the link above I find no sources

The reason all those unknown profiles are created is because one relation in the Gedcom that says Cox-2659 has a number of child relations ==> it could also just be a export software bug ;-) 

We will never know. 

Sad is that we don't use templates for sourcing so that we faster find unsourced profiles....

The lines in the database that creates the relation between unknowns

1 HUSB @I13@ Henderson Elias /COX/
1 WIFE @I14@ Emma Rosette 
1 CHIL @I15@ Leroy Henderson /COX/ is on findmygrave see link
1 CHIL @I16@ Partha Ann /COX/
1 CHIL @I17@ Elizabeth /COX/
1 CHIL @I18@ Pearl /COX/
1 CHIL @I19@ Wayne Eldon /COX/
1 CHIL @I20@ Marion Edwin /COX/
1 CHIL @I21@ just sex U
1 CHIL @I22@ just sex U
1 CHIL @I23@ just sex U
1 CHIL @I24@ just sex U
1 CHIL @I4@ Hyrum Hunt /COX/
1 CHIL @I71@ just sex U
1 CHIL @I72@ just sex U
1 CHIL @I73@ just sex U
1 CHIL @I74@ just sex U

 

On Find my grave we have

Parents:
  Henderson E Cox (1870 - 1941)
  Emma Rosetta Hunt Cox (1873 - 1946)
 
 Siblings:
 Leroy Henderson Cox (1895 - 1969)
  Partha Ann Cox (1896 - 1897)*
  Pearl Cox (1899 - 1900)*
  Eldon Wayne Cox (1901 - 1949)*
  Marion Edwin Cox (1903 - 1983)*
  Hyrum Hunt Cox (1905 - 1964)*
  Emma Cox Burton (1908 - 1990)*
  Nellie Cox Slade (1911 - 1987)*
  Rulon Cox (1913 - 2000)*
  Robert Edgar Cox (1919 - 2000

+2 votes
I have a few questions about these profiles. It is a weird method to go and skeleton out a bunch of unknowns, but it does make a kind of sense for a private database where you're not wasting WikiTree-IDs due to the LNAB-URL mapping.

My grandfather told me that my great grandfather had seven siblings, and he knew the name of his father and one of his uncles. I wouldn't know the names, locations, or dates of birth or death for any of these siblings, but the fact that I know the relation and rough count of them is actually useful information that can be enough to fill in the blanks. Especially, once I had found the parents of my great grandfather.

So it would be definitely a conclusive error if the profile had no relations, no name, no birth date or no death date, and no locations associated with them. That would be a fully ambiguous set of conditions that couldn't be used to reconstruct the missing information. Having at least one of the siblings with unambiguous vital information, a count of how many siblings there should be, and at least one of the parents with unambiguous vital information would be the minimum conditions for disambiguating the unknowns in this bunch if I am not mistaken; you're looking for a triangulation of data, so it is analogous to solving different cases of a triangle; relationships can be thought of being like angles, and vital data can be thought of like the sides; you want to create an enclosure with known internal angles.

I do think that it is useful to classify the grouping of vital fields as an error in that it draws attention to what amounts to a largely unsolved puzzle. Also, I didn't see anything in the profiles I looked at which indicated why there are so many unknowns, so I don't necessarily think the person managing the profiles knew exactly or even roughly how many siblings there should be. As a mostly impartial third party, there isn't sufficient information for me to clearly regard the conditions as unambiguous or functionally complete in this specific case.
by Ian Mclean G2G6 Mach 1 (12.2k points)
A comment was posted back in January requesting that the LNAB be changed. It looks like the relatively inactive profile manager did a few back in May,  then stopped.

Related questions

+8 votes
1 answer
133 views asked Jul 13, 2016 in The Tree House by Jan Terink G2G6 Pilot (169k points)
+16 votes
9 answers
+13 votes
2 answers
83 views asked Jun 13, 2016 in Policy and Style by Joke van Veenendaal G2G6 Mach 2 (23.6k points)
+9 votes
4 answers
+7 votes
1 answer
+3 votes
1 answer
+5 votes
2 answers
118 views asked Jan 31, 2018 in Policy and Style by Michael Tyler G2G6 Mach 1 (19.7k points)

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...