Re: A draft proposal for UUIDs

On 8/16/2011 7:14 PM, Ron Savage wrote:
> Hi Steve
>
> On Tue, 2011-08-16 at 09:48 -0400, Stephen Woodbridge wrote:
> [snip]
>>> Now, if some interface code allows the user to create INDIs, say, them
>>> they have to be flagged as having a different UUID. Or do they?
>>>
>>> If the original UUID belonged to the source, then yes, since the new
>>> INDIs are coming from a different source.
>>
>> I think this is the correct answer. the UUID belongs to the source of
>> the import action the created the data when the import did not have
>> UUIDs of its own.
>>
>> Adding a UUID for the import action would then allow all the data to be
>> later purged if it needed to be so there might be value in adding a UUID
>> to the import even if the imported data already has UUIDs.
>
> I think we're getting things clearer now.
>
> To summarize: For a given db, each source which contributes records must
> be separately identified by a UUID, with that UUID attached (somehow) to
> each record imported.
>
> That means various types of reports:
>
> o Pick 2 UUIDs and process (e.g. compare, update, export, delete) just
> the records belonging to those UUIDs.
>
> o Pick 2 UUIDs and flag records such that data with (from) UUID #1 is
> deemed more reliable that data with UUID # 2. Clearly both datasets are
> preserved.
>
> o Pick 1 UUID and process (e.g. update, export, delete, ...) just the
> records belonging to it.
>
> o Many others possibilities ...
>
> Good stuff!
>

Hi Ron,

Yes exactly, but I not sure that it should be limited to sources because 
from a single source you might have some good data and some bad data. So 
it is fine to say this is more reliable than that, but you also need to 
be able to say this item is flat out wrong.

Obviously you can go crazy with this and tag everything a UUID, but here 
are the things I think are most important:

1. INDI, FAMI, and NOTE and individual items attached to these
2. actions performed on these or on the database

Oh! I just realized something we are mixing two different needs here

1. INDI, FAMI, SOUR and NOTE records need a UUID that does not change 
this is a persistent object identifier. In a given system INDI::UUID=27 
should always get me the same INDI regardless.

2. for history and object version tracking so you can merge or re-merge 
a data set, you need a version number that gets incremented every time 
the object gets changed. So say I import Joe's GEDCOM and merge it with 
my file in January and then in August I get an update. I can ignore all 
the UUIDs from Joe that have the same version as in the new import and 
only UUIDs that I do not have or have new versions, need to be merged.

So I think we have two separate needs here that should not get merged to 
avoid confusion: Object need UUIDs and Actions (add, import, edit 
delete, etc) cause version changes to Objects. Is a version just another 
UUID? If an object like an INDI or INDI::BIRT is in two separate systems 
and is edited in both systems you would not what them to be able to have 
the same version number.

So a possible use case: I create an INDI in a system A and it has UUID=x 
and this is exported to a GEDCOM and imported into a another system B, I 
assume it retains it UUID=x but also has some additional information 
that it was imported attached to it. Now the BIRT record is 
added/updated separately in both systems. Later I import import the 
system B back into system A.

I'm just trying to think this through. There are obviously a lot of 
additional nuances that can be put on this, like each BIRT record could 
reference a SOUR record that would have a UUID and later identical or 
similar SOUR records could be merged keeping both UUIDs.

Maybe this is getting to be overkill? Is anyone else following this 
thread? I see these things as being a significant aid to managing data 
and merging and updating data in an automated way. But then again maybe 
no one else cares.

Thoughts?
   -Steve