Projects/Nepomuk/Pimo Person Discussion

Introduction

On the 4th of July 2012, during Akademy 2012, an impromptu discussion on how Nepomuk should handle meta contacts. The pimo ontology does describe this to a certain extent, but we do not seem to follow pimo, and there are a lot of problems with the approach described in the ontology.

Participants:

• Vishesh Handa (Nepomuk)
• Daniele Domenichelli (Telepathy)
• Martin Klapetek (Telepathy)
• Christian Mollekopf (PIM)

The Problem

The ontologies suggest that there should be one central pimo:Person and various nco:Contacts which act as grounding occurrences for that pimo:Person

<nepomuk:/res/person> a pimo:Person ;
    pimo:groundingOccurance <nepomuk:/res/contact1> ;
    pimo:groundingOccurance <nepomuk:/res/contact2> .

<nepomuk:/res/contact1> a nco:Contact ;
    nco:fullname "Name 1" ;
    nco:photo <nepomuk:/res/photo-file1> .
    
<nepomuk:/res/contact2> a nco:Contact ;
    nco:fullname "Name 2" ;
    nco:photo <nepomuk:/res/photo-file2> .

In this case it is not clear which name and photo should be used when displaying the results to the user. We need some way of specifying the default name, and photo.

Use cases

Contact List

• It shows a list of contacts, possibly applying some filtering (i.e. show only contacts with an im account and that are online).
• It displays only data about the person, not about the single contacts.
• It needs information about the im accounts (i.e. to show a list of accounts with their status in the tooltip).
• It should be able to start a dialog to edit the information about a person (i.e. choose displayed name, avatar, etc). (see Person Information Editor)
• It might have some contact merging capability (i.e. drag and drop a contact over another one).

Address Book

• It must be able to show both the person and the single contact information
• It could show a tree, with the Person as parent and all its Sources as childs
• It might have some contact merging capability (i.e. drag and drop a contact over another one).
• User could see a "global" address book showing persons, and one address book for each configured resource (i.e. company address book, im account) showing only contacts for that resource

Contact Merging

• It will be a service or an ui to help you merging contacts.
• It should not happen automatically, but always require user confirmation.
• It should remember if the user already stated that 2 persons are not the same one.

Contact Information Editor (dialog)

• It should be in some library in order to be available to everyone
• It can be the classic Kontact - Edit contact dialog
• It should allow to edit and possibly write back information on the source (if this is writable)

Person Information Editor (dialog)

• It should be in some library in order to be available to everyone.
• This should be a slightly modified version of the Edit contact dialog
• For properties with max cardinality = 1 (i.e. name, birthday, etc.), instead of having text fields it should have drop-down menu, showing all the versions of that property for all the grounding occurrences. User should be able to choose between one of those or to set a custom value.
• For properties with multiple values (i.e. address) all the values should be shown. User should be able to add more.
• Each value should show where the value comes from, for example showing the icon of the im account or of the akonadi resource where it comes from.
• If 2 contacts have the same values, it could show just one entry in the menu, with all the associated icons.
• It could have some write back feature (drdanz: How? {single property,all properties} to {single backend,all backends}?)

Possible Solutions

Use nao:prefLabel

We could utilize nao:prefLabel and nao:prefSymbol, but nao:prefSymbol has a range of nao:Symbols. Symbols in Nepomuk just have a name, whereas photos correspond a particular file.

Also that only covers 2 properties. nco:Contact has many more properties which we care about like nco:birthday and nco:nickname.

Double type pimo:Person

The preferred solution was that the pimo:Person be double typed with nco:Contact and have itself as a grounding occurance. Depending on the values which we want to present to the user, we copy that data from the nco:Contact to the pimo:Person.

In this way the user can set the nickname and full name that they want to see. They can also choose between a set of options from any of the nco:Contact grounding occurances.

<nepomuk:/res/person> a pimo:Person ;
    nco:fullname "Name 1" ;
    nco:photo <nepomuk:/res/photo-file2> .
    pimo:groundingOccurance <nepomuk:/res/person> ;
    pimo:groundingOccurance <nepomuk:/res/contact1> ;
    pimo:groundingOccurance <nepomuk:/res/contact2> .

<nepomuk:/res/contact1> a nco:Contact ;
    nco:fullname "Name 1" ;
    nco:photo <nepomuk:/res/photo-file1> .
    
<nepomuk:/res/contact2> a nco:Contact ;
    nco:fullname "Name 2" ;
    nco:photo <nepomuk:/res/photo-file2> .

For Discussion

Should we only copy the literal terms? Or should we copy relations like nco:hasIMAccount as well?

vHanda: I think only literals need to be copied. We only need the literals for defaults

drdanz: On the other hand, if you copy all the relations, when you make a query you don't have to query for grounding occurrences... imho it makes sense to have a NCO:Contact that contains all the information about a person and one or more other grounding occurrences that represent the source of a part of that information.

Who should create the pimo:Person

Currently the PIM Contact feeder only creates nco:Contacts, and the Telepathy feeder (not shipped) creates both nco:PersonContacts and pimo:Persons.

mck suggested that none of the feeders should create pimo:Persons, and the kpeople should be the one merging the contacts together to create people.

vHanda: Won't that be a lot of effort to do in kpeople?