Database Error Project: No dates or estimates an error candidate

Question

Suggestion new error

A profile like Albrechtsdotter-4 has no dates or estimates feels could be flagged as an Error

Comments

Error report already exists for this. 901 and 902.

Answer 1

I would find it useful to help me find profiles that require more research rather than having to scroll through my watch list of over 1200 profiles. Anything that simplifies where to direct my attention is worthwhile. Many of my older profiles are not up to current standards but they were when I set them up.

Comments

Good point Geoff and how do we tell the computer a profile needs more research ;-)

---

Hi Magnus, I think that there should be an error to flag a profile if both the birth and death dates are blank to encourage people to bring the profiles into line with current requirements of having at least one date or an estimate on each profile. This helps when checking that a profile doesn't already exist. I don't think that Jillaine Smith's 901 and 902 codes cover this situation as they also require the profile to be unconnected.

Also it would be useful to flag profiles without at least one location. It is very frustrating to have to search through a long list of profiles looking for duplicates/matches when they are not even in the same country.

---

I agree Geoff everything that helps people to do better research and follow the WikiTree Honor Code should be flagged as an error

VIII: We cite sources. Without sources we can't objectively resolve conflicting information.

As most of us don't use templates for sourcing its impossible for a software to guess if a WikiTree profile is following the WikiTree Honor Code and cite sources what we can tell is if a profile is marked Unsourced - using {{Unsourced}} and I hope those profiles will be marked

We also spoke about profile size too big as an indication of garbage and empty profiles is the same

Answer 2

Flagging each missing data as an error is not a good direction. There would be a few errors on each profile.
I have a different idea. To score the profile for each data entered, for each certanty set, for used location categories, sources used,... I could do this with the new dump.
Starting point would be to establish what ideal profile is and what must be in profile to be better.
Give me some proposals for ideal profile.

Comments

Excellent idea.....

You have in a site like Linkedin something called a profile strength that would be a concept that is easy to understand and could be changed and used for WikiTree profiles..... 

The lowest level is that a profile created in Wikitree follow the WikiTree Honour Code and cite sources... 

Below how Linked In classify and visualize it.... we could have 

1. well researched.... 
2. .....
3. .....
4. just started.... 

 

My vote

1. A new Error is defined when we have an Unsourced template on the profile
   
   As the WikiTree Honor code says we cite sources. 
   Without sources we can't objectively resolve conflicting information.
    
2. Somehow we also mark profiles with Category: Family Brick_walls (or a subcategory) so other researches find them easy and can help. Maybe not an error but an icon rescue me :-)  
    
3. Some templates give lower profile strength (maybe add a parameter on the template how severe the problem is)
   1. DateGuess
   2. DateGuess2
   3. Citation_needed
   4. Questionable 
   5. UnverifiedParents
   6. Unverified_Father
   7. Unverified_Mother
   8. Unverified_Spouse
       
4. Profiles with Sources templates gives much much higher ranking...
   1. In the future maybe start looking into GPS and the criteria they have for doing good genealogy and then mark profiles that follow GPS and have been reviewed
       
5. Missing metadata like Location, Birth Date.... gives lower
    
6. Error in Meta data like you have Y in the Death Location gives lower...
    
7. Maybe also have some kind of time parameter and/or location dimension that is based on how difficult the time period/location is for doing good genealogy
    
   1. A profile in Sweden from 1700 is normally rather easy to find at least one source because we normally have Church books from that period 
       
   2. A profile in Norway from 1563 then you are lucky to find anything (more than a link to another family tree at Ancestry ;-))
       
8. Use WikiTree as benchmark for a profile in the area... add a visual hint how good other profiles rank at this time period and location. Click on the WikiTree average ==> you get a list of the profiles that are part of the "benchmark" ==> also a way to learn more and start reading those profiles and learn from them what can be done to find evidence for facts....
   
   Below how it could look with a WikiTree average line  
   
   

 

 

---

Don't try to score each data entered - a profile could be really well done and still missing marriage date or death date.  There won't be sources for precise birth dates for certain locations and time periods so estimated date is all we can expect for those (so not an error).  Don't score for use of location categories if you mean categories of the type [[Category: xxxx]] because those are not very useful, not really worth the time to enter them.

The main thing I want to know is if a profile is more than just internet genealogy junk, has it been researched or just copied from another site, is there at least one real source cited.  If all the source citations are to trees.ancestry.com it is junk to me.  It may take a human judgement to mark a profile properly (which we currently have no option for) or at least allow a human to revise any rating the software cones up with.

it would be relatively easy to find examples of good and bad profiles and post a list if needed.  But would it better to mark them some way in the profile itself?  (in some subtle way that wouldn't cause trouble with the profile manager)

---

I think that it isn't a matter of missing any one specific datum. It is a problem of conjunctions of missing data.

No name and no (DOB OR DOD) for instance makes matching a profile to other data difficult to compare. Creates conditions of ambiguity. This goes back to my post on merging. I outlined what constitutes profiles sufficient to merge vs ambiguous conditions for merger.

I think the conditions I outlined can be expanded into an exhaustive list of cases from most ambiguous to least ambiguous. And as such, the list can be used to identify new errors types or extend old error types.