Profile Revision History, Merges, & SmartCopy

Started by Dan Cornett on Thursday, December 10, 2015
Problem with this page?

Participants:

Related Projects:

Showing all 4 posts
12/10/2015 at 12:56 PM

Let me address my understanding of how 'data changes'are retained by Geni ... and how it does or does not relate to SmartCopy.

1) Merges & history of changes (Revisions) -- a Geni.com functionality; nothing to do (directly) with SmartCopy:

1a) Revisions:

The changes made to fields on the "Basic" editing page and the "About" are under 'revision control' ... and the Revisions tab of the profile shows those changes and retains the previous values so they can be examined or restored. That DOES NOT apply to the fields on the other 'edit' pages -- they are not (yet) under the "revision control".

An additional point: it is only those "Basic" fields which can be locked on Master Profiles.

1b) Merges:

When a merge of two profiles occurs, the data from fields under revision control (Basic fields) are kept as a "data conflict" if they differ. Once the data conflict is resolved (a value selected from the choices), the other choices are no longer accessible; they are, for all practical purpose, 'lost'.

The "About" text is always combined from the two profiles; a 'separator line' is placed between the two.
The list of Sources & Media (from their respective profile tabs) are combined.

For the non-Basic fields *AND* the Revisions history list ... the data from the "primary" profile in the merge are retained -- the data & Revisions list from the other profile are no longer visible. (n.b.: they *may* be restored after an unmerge ... which can only be done for merges since August 2015).

The "rules" for which profile is picked by the 'merge engine' as the "primary" are rather complicated; in general, though, the priority is:
(i) Master Profile
(ii) profile with "more managers" (it doesn't matter how many previous merges - just the number of co-managers)
(iii) profile with "more data" (more data fields "filled in" ... a rather imprecise criteria)
(iv) the "older" profile.
There is also something related to "stacking order", but that is (I think) only used as a "tie-breaker".

This means that one might want to be a bit careful about the order multiple profiles are merged.

For example, assume there are 3 profiles, each with a single manager, but one of them clearly has more fields filled in and seems to be 'better'. In that case, the "better" profile should be first merged with one of the other two, giving the result two co-managers. Then merge in the 3rd profile.

Why? Because if the two "sparsely filled in" profiles are merged first, and if there are *non-Basic* data fields with conflicting information, the "sparsely-filled-in" profile's data would be retained, not the "better" one. Remember two things about this, though:
(a) If one profile has a blank field and the other has a value, the 'value' will always be retained, no matter which profile it came from.
(b) If the conflicting fields *are* under revision control, the "conflict" will be retained until it is resolved.

If there is a profile with a single manager which is clearly "better" than a profile with multiple managers, one might consider asking a Curator to mark the "better" profile as a Master Profile before merging them ... or take the time to copy over the 'better-but-conflicting' values for the *non-Basic* fields first.

All of this is purely Geni functionality. It has nothing to do with SmartCopy nor any other 'programmatic' changes to Geni. For the record: SmartCopy is not the only 'external' utility to use the 'programming interface' (API) -- just currently the most widely used.

2) SmartCopy and revisions:

SmartCopy uses the Geni-provided 'programming calls' to update fields and to create profiles. The 'recording of revisions' is solely what is done by Geni.com. Since the "tracking" of revisions is a function of the underlying database (not SmartCopy), any changes which are under 'revision control' (as noted in topic 1 above) will be recorded and can be restored ... just as if the change were done "by hand".

A note-worthy point: fields *not* under 'revision control' will have no "history" of that change. That is no different than if someone made that change "by hand".

There are two fields (currently) which SmartCopy *does* make an effort to only 'add to' the existing contents, rather than replace them. Those are the "About" and the "Also Known As" fields. (That is, SmartCopy retrieves the current text value in those fields, appends the "new" text to the end of it, and replaces those fields with the newly-combined text.)

The decision was made to have SmartCopy add a "minimalist footnote" to the About field whenever it created a profile or updated any fields. The two primary reasons were to:
2a) Provide an indication that a change occurred and when it occurred.
2b) Provide a link to the "page-the-update-came-from".

Notice I did not call that the "source" page: That term 'Source' has a specific genealogical meaning, and there was never any intent to assert any sense of 'correctness' to that "original page" nor to provide details about which values may have been brought over from that "original page".

==================

SmartCopy only has the 'privileges' of the Geni user. It does not have an "elevated access" of its own. (n.b.: technically, SmartCopy actually runs from with the user's browser on that computer. In many ways it simply acts as a very, very fast typist.)

Private User
12/10/2015 at 2:46 PM

Dan - very useful - thank you

Re "rules" for which profile is picked by the 'merge engine' as the "primary": I would add that a claimed profile has priority over an unclaimed profile

Private User
12/10/2015 at 2:50 PM

Another point:

"When a merge of two profiles occurs, the data from fields under revision control (Basic fields) are kept as a "data conflict" if they differ"

This is only true if both are non-blank. If they differ because one was blank and the other wasn't, there is no data conflict.

Often a poor quality display name can "creep in" because an MP had no display name, and the profile merged in has a display name that we would not want to use.

The merged profile gets the poor quality display name with no data conflict.

12/11/2015 at 2:57 AM

Dan - always the teacher....

The clarity wih which you have explained the processes of Revision History, Merges and Smart Copy in simplified and understandable language will be appreciated by many users and probably some curators too.

Thank you.

Showing all 4 posts

Create a free account or login to participate in this discussion