[Nepomuk] Re: Special Identifying Properties

[Sebastian Trüg]

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.

Cheers,
Sebastian