Request to include names and dates in new GEDCOM-format

Question

I just merged a duplicate created by an unchecked GEDCOM and when starting to edit the biography I had to go to the changes tab to find the name of the person whose GEDCOM it is as well as the date. This I find really frustrating. The data means nothing without at least a semblance of a source. Wiping the bio just clean would not solve anything, and my first impulse was to just remove the newly GEDCOM'd data, even though there was new christening information. But this would in my view constitute vandalism.

I know that the new "look" is great but am getting to the end of my tether with all these continual changes within WikiTree.

Comments

And this GEDCOM'd information of her husband though it could be useful is creating an awful amount of work for the person that has to integrate the bio ... I would appreciate advice or tips on how to proceed with this ...

---

I have seen a few bios that will be a nightmare to edit. A few examples and guidelines would be appreciated.

---

Here's the G2G  update about what is all changed now for the Gedcom imports , now the merged one for the husband you show here indeed looks like a nightmare to edit and most of the time the one that merges the profiles ends up cleaning up and trying to integrate all stuf , so I sure hope they don't all look like this (especially if someone decides to just import again a duplicate gedcom ) 

---

Thanks Bea, missed that one over the holiday season.

Answer 1

I did the integration of the two biographies (example 1 and example 2) and have a few observations to make, the most important one of all that it took me at least twice as long than before to integrate the bio, [also] because of the following reasons:

1. I also wanted to include the name of the GEDCOM and person and date ...
2. The text(s) were punctuated were there is no need for punctuation - I had to do a lot more editing than would be usual for a GENI-import
3. The actual sources (links to primary documents in GENI) had not been migrated. Knowing a bit how GENI-GEDCOM usually works (in the case of South African profiles) I missed many links, even though some of the links are often duplicates ...
4. I have an idea of the actual secondary sources (which may also have mistakes in) but no surety. One also has to have some knowledge of the specific De Villiers / Pama  genealogical numbering system (see also this link on the project page) to edit this bio properly.

Though there is nearly always some new information to be gleaned from a GEDCOM, in both these instances (and as Bea points out in most other cases of duplicate GEDCOM), the amount of energy going into cleaning up after a duplicate GEDCOM is way more than a simple collaborative adding in scholarly fashion by WikiTreers (also keeping in mind that the previous ''boilerplate'' will have to be integrated as well in the case of a duplicated profile, from === Birth === for example to '''Birth:'''). If the duplicates aren't checked in time and the cut-off dates not changed (1800) this issue will not go away, with all consequences of re-directs and data-load etc.

There is one solution [in the case of the South-African profiles within this project period from around 1652-1806] - to create in time a separate database ''within WikiTree'' with all the name variations where people need to go and check first, before being allowed to create any file, in GEDCOM-form or just plain manually. Example of such a surname index ...

Comments

One more example of a recent unchecked GEDCOM'd duplicate with new Boilerplate but absolutely no sources: http://www.wikitree.com/wiki/Janse_van_Rensburg-1074 ...

---

Totally agree on the cut off date for the gedcoms, if 1800 is not possible than the Pre-1700 cut off should really be considered and the surname index could be a great help as well to prevent duplicates .

---

Philip, please help me understand your request. What does the name, date and uploader of the GEDCOM offer in value?

---

It is simple Jillaine - we are also working with massively merged profiles. Separating the different GEDCOM imputs (with their sources) by date and name of uploader makes it much easier to collate the data. When working with tens, hundreds of profiles a day, going to the changes tab to try and untangle the input from various sources and try and ascertain their validity, is simply not feasible. I can also in one glance ascertain the "integrity" of an edited bio by looking at the distinguishing key elements of each GEDCOM (each GEDCOM has it;s unique DNA if you will ...). If something is missing, I know that there might been some data missing from the bio as well.

This request was made in January. We had the new boilerplate then and it meant revisiting the changes tab in order to re-construct the GEDCOM input in order to make sense of them. Since mid-June I think, the old situation was restored.

---

Mmm. I deal with many merges as well and i find nothing at all useful in the identity and date of a GEDCOM upload. When I'm cleaning up a massively merged profile it's the quality of the narrative and especially sources that I'm most interested in.  I see no reason to spend time collating different GEDCOM data. Instead i focus on creating a single narrative using the best information and sources there. (it's often the case that one of the dupes has the best info.)