[Nepomuk] Re: Special Identifying Properties

[Christian Mollekopf]

On Fri, 29 Jul 2011 08:31:37 +0200, Sebastian Trüg <trueg at kde.org> wrote:

> On 07/29/2011 08:24 AM, Christian Mollekopf wrote:
>> On Fri, 29 Jul 2011 08:21:30 +0200, Sebastian Trüg <trueg at kde.org>  
>> wrote:
>>
>>> On 07/29/2011 08:11 AM, Christian Mollekopf wrote:
>>>> 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?
>>>
>>> This is completely true for all contacts which exist as actual contacts
>>> in Akonadi. It is, however, a nightmare when done for all contacts in
>>> email header fields like from and to. These cry for merging. Everything
>>> is just impractical, wastes space, and complicates queries.
>>
>> Right..., I feel we need a way to mark IE's as unmergeable (or even as
>> mergable to be more conservative).
>> New ontology?
>
> I don't think we really need that since merging only happens on
> insertion in storeResources and only if the client wants it. Akonadi
> contacts will never be merged since they have unique ids.
>
Alright, then I'm happy =)

> Cheers,
> Sebastian