Re: [Gramps-users] Re: all duplicates

[Alex R. <sh...@al...>]

Felix,

On 07/23/2004 04:01:06 PM, Felix Roennebeck wrote:
> >>My problem needs to be solved during import (and if I talk about=20
> >>"import", I basically mean merging of two sources, one of the sources=
=20
> >>beeing the actuallly loaded data.gramps file). In my special case, it=
=20
> >>seems pretty easy: the IDs are the key, and gramps could just take from=
=20
> >>both entities whatever is there and merge it into one=20
> >>person/event/relationship/... . If there are conflicts they could be=20
> >>shown to the user in a dialog like the actual "find duplicates"-dialog.
> >
> >But how does gramps know when it sees I0001 in your database=20
> >and I0001 in the one you are importing that it's the same person?
> > =20
> Gramps can never know. That is the point where the wisdom of the user is=
=20
> needed.
>=20
> >It could be a situation like yours (most if not all of the same IDs=20
> >represent same people) versus another situation. Suppose I have=20
> >a tree of 250 people and then my uncle sends me another database
> >with 300 people from another family line which I did not have before.=20
> >That database would almost surely have IDs like I0001, I0002, and so on.
> >
> But this is quite a lot of information the user could tell gramps about.=
=20
> It is pretty obvious in this situation that (at least) one of the=20
> databases needs to be renumbered. By default I would assume, that it=20
> will hit the one that is imported, theoretically it could be the opened=
=20
> database. There is only one exception: The IDs are not key and the user=
=20
> doesn't mind (or maybe even wants to) have duplicates IDs. This is where=
=20
> the mapping could come in very handy: The user could define a mapping=20
> like "I0\d\d\d" becomes "I1\d\d\d" et voila: The numering scheme of both=
=20
> databases is preserved and no conflicts. :)

This seems like a good idea. The only problem I can see is that the I1000
may be already taken in th first database, if it has over 1000 people.

But nobody prohibits us to make it IXXX->IXXX_new or IXXX.1 or=20
whatever else. I'll think more about it, but so far it looks OK.

> >In that case, the database will be full of conflicts.
> >
> If the ID is not key (which seems to be the case in future releases)=20
> this would not even be a problem. ;)
>=20
> >If we require exactly same name the we may also get into trouble: it
> >is not uncommon for a person to be named after grandfather, uncle,=20
> >or another relative. So there's not-so-small probability that more=20
> >than one person have exactly same name.
> >
> That's why I think, that gramps must never merge individuals without=20
> explict order by the user - be it as a default for this merging-run, be=
=20
> it on a step-by-step approach.

Agreed.=20

> >Which brings us to the need for the unique IDs. With the unique IDs
> >you're certain that the same IDs represent records of the same people.
> >
> Agreed. The unique internal IDs seem to be mandatory if gramps is=20
> supposed to support such operations. But still: What is gramp supposed=20
> to do with the unique ID if the user identifies two individuals as=20
> identical? One of the IDs becomes obsolete (unless you want to keep=20
> multiple unique IDs per individual) and if you just "forget" them in the=
=20
> resulting database, you will need to resolve that when you merge the=20
> resulting database back to the origin of the imported one.

Yes, this would be the ugly problem. I don't have good answers to these
questions. Let's keep thinking. Maybe Don will chime in with his view :-)

Alex

--=20
Alexander Roitman   http://ebner.neuroscience.umn.edu/people/alex.html
Dept. of Neuroscience, Lions Research Building
2001 6th Street SE, Minneapolis, MN  55455
Tel (612) 625-7566   FAX (612) 626-9201