[Nepomuk] Re: Special Identifying Properties

[Christian Mollekopf]

On Fri, 29 Jul 2011 02:02:08 +0200, Martin Klapetek  
<martin.klapetek at gmail.com> wrote:

> On Thu, Jul 28, 2011 at 14:49, Sebastian Trüg <trueg at kde.org> wrote:
>
>> On 07/28/2011 02:25 PM, Christian Mollekopf wrote:
>> >> Well, in the case of Akonadi nothing is merged anyway since you  
>> specify
>> >> the url directly.
>> >>
>> >> Contact merging is really only done for the case of "anonymous
>> >> contacts", ie. those that are created as second-level resources.
>> >
>> > Ok, fair enough.
>> > Since we still might want to have contacts merging also for those
>> > contacts, we could do that on a PIMO level I assume.
>> > I.e. as in the android phones, where you get your goolecontacts merged
>> > with the facebook contacts.
>>
>> Yes, definitely. I hope Martin's solution does not only include Akonadi
>> contacts. ;)
>>
>
> Nope, it takes all nco:PersonContacts it finds, no matter where they came
> from. This is actually something I stumbled upon not a long time ago as I
> had a solution only for akonadi contacts. It turned out pretty quickly  
> that
> it needs to be more general.
>
> But to get a bit back - the family use case. I believe that if someone is
> sharing an email in a family (I personally do not know anyone like  
> that), I
> think they'd use something like "Mustermann family" instead of two  
> different
> names for one email. Besides, it's just wrong to do that.
>
> Nevertheless my Nepomuk service currently does exactly what has been
> discussed here - when there is new nco:PersonContact, it searches Nepomuk
> for any other contact with that exact same email and if it finds one, it
> merges them together. In the light of previous discussion and previous  
> use
> case, I guess I could add more parameters to compare, like name. Or  
> should I
> a) discard it completely or b) move it to Nepomuk's core (where the other
> checks currently are)?

IMO it's just wrong to merge the generated contacts directly. You can't  
even do that in a sane way atm,
because all IE's generated by the feeder represent at the same time the  
DataObject side,
and if you merge an akonadi generated contact with another one (or two  
akonadi generated contacts from different resources),
the merged item is just... wrong really. This because you would have to  
merge the two DataObject too, which you can't, for obvious reasons.
So if you really want to do this, we would have to create separate  
DataObjects. But anyways, if the contacts are directly merged we actually  
loose
information (like where the data was coming from), and have no way for a  
writeback service.

It's not a huge problem atm. since all data is generated by the feeder,  
but if I imagine we would do this with contacts manually created by a  
user....

>
> The rest of the service then takes care of creating pimo:person and/or
> adding grounding occurences to already existing pimo:person.
>

IMO the only option to do the merging in a sane way is to create another  
contact, the merged contact,
which you can then add as grounding occurence to the person, leaving the  
feeder generated resources as they are.
This way we don't loose information.

Thoughts?


> --
> Marty K.