[Nepomuk] Re: Special Identifying Properties

[Sebastian Trüg]

On 07/29/2011 02:02 AM, Martin Klapetek wrote:
> On Thu, Jul 28, 2011 at 14:49, Sebastian Trüg <trueg at kde.org
> <mailto: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)?

IMHO it makes perfect sense to have it as a separate service. We have
two levels of merging here:

1. The DMS level which storeResources does. This merging is an actual
merging of two resources into one where one of the two is deleted.
2. The PIMO level merging. This is an ontology based merging, so to
speak. From the DMS point of view all three involved resources simply
are in relation to one another via some property.

I do not see any reason to put PIMO handling into DMS at this point.
Maybe later down the road Martin's service can become more general and
handle more than "just" pimo:Persons.

Cheers,
Sebastian

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