On 07/22/2004 05:10:30 PM, Felix Roennebeck wrote:
> If there is any conflicting information you have to ask the user for=20
> sure. Maybe the user could be supported by letting him chose on defaults=
> in advance like "If one field is set in only one of the two records, use=
> it", or "If there is conflicting info keep the one from the record with=
> the higher/lower ID". But this looks like a lot of hassle for little=20
I think so too.
> IMO we should differentiate two situations: Finding duplicates and=20
> merging databases.
> The "find duplicates" tool as it is now serves the purpose it seems to=20
> be designed for very good: Finding duplicates in a database that has=20
> grown over the time.
> 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=
> 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?
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.
In that case, the database will be full of conflicts.
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.
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.
> In a more generic approach there could be a dialog, that lets the user=20
> decide, what the key is. In many situaions e.g. the name (optional with=
> SoundEx), the gender and the date of birth/death should be sufficient.=20
> To allow more automation, the user could define one set of data as the=20
> "primary", which means, that it allways wins in case of conflicts. When=
> talking about importing a file into the opened databse this could be a=20
> selector like "In case of conflict a) never modify actual data b)=20
> allways override actual data c) use imported data als alternative (if=20
> available?) d) use actual data as alternative e)ask user".
> The cherry on the cake would be if the user could define mappings like=20
> "Value A in database 1 means value B in database 2" and reactions like=20
> "Keep only the value from databse 1/2", "Use value from database 1/2 and=
> add the value from database 2 as an alternative". This way e.g.=20
> conflicts in spelling due to different languages could be resolved=20
> automagically. Most of my family lives and lived in germany, but parts=20
> came from poland. Many locations there have german and polish names, but=
> they are still the same location. I have german and polish sources about=
> just the same person, the german source talks about "Posen", the polish=
> one talks about "Poznan". As a result I would like to have "Posen" in=20
> the records, but "Poznan" as an alternate value.
These seem like good ideas, which need to be thought over :-)
> >As for your situation, what about installing gramps on that MacOSX?
> >There's a fink project that packages a lot of *nix software for OSX.=20
> >They have also ported gramps to OSX, take a look here:
> > http://fink.sourceforge.net/pdb/package.php/gramps
> We tried that and failed. The problem is, that my dad is not really a=20
> geek (he is 70+ and using his Mac as a user with no intention to dig too=
> deep into it) and about 800km away from here and I have too little=20
> experience on MacOSX to support him remotely. When I'm there the next=20
> time I will give it a try for shure. But if I understand it correctly,=20
> the fink-version is a little behind the linx-version. Wouldn't that=20
> cause problems?
Actually, they have caught up now. the main problem was porting=20
GNOME2 to OSX. There's little in gramps itself that is hard to port.
Most problems come from dependencies on gnome and its=20
> >If that worked then you and your dad could exchange data.gramps
> >files back and forth, without losing info on import/export.
> Yes and no. Eero touched that problem recently. I would like the=20
> confusion of "where is the latest version? can I do changes or do I have=
> to get the latest version first?".
That's right, you'd have to always work with the recent version.
> I read about the CVS-approach. But that means, that the user has to=20
> resolve conflicts in CVS instead of gramps, right?
Yes. If you forget to get the latest from CVS before making your=20
changes (or if somebody checked in new version while you were editing)
and if the same portions of the file were modified so that CVS cannot
merge your changes in, you'd have to open XML file in the text
editor and manually resolve the conflicts. then you check the fixed
version into CVS.
> IMHO a powerfull merge/import-tool could be a killer feature and I would=
> be happy to contribute to it. I will try to think it through from A to Z=
> and write it down. Don's vacation should give me time to do that. ;)
Sounds like a great plan. The idea I like the most at the moment is=20
to use the unique IDs. They are already implemented in the development=20
version. The only problem is that they will be lost on the export.
However we may use some GEDCOM fields to export them as well.
In that case the importing routine would know for sure whether it's the=20
same person or not.
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