Jump to content

Projects/Nepomuk/Pimo Person Discussion

From KDE Community Wiki

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

List of use requirements for KTp dealing with people. This is _NOT_ saying all of this should be in nepomuk, it's stating all the information we need to interact with a person (or contact) so we can work out what data _SHOULD_ be in nepomuk, kpeople, or from our code directly.

KTP

Contact List

  • Show a list of contacts, possibly applying some filtering (i.e. show only contacts with an im account and that are online).
  • Show presence of these contacts per account (online/away/etc with presence message)
  • Show most available presence on the top level person (i.e person with an account away/online) = away
  • Show the capabilities for the contact AND therefore person - can voice chat, can webcam, has kwhiteboard tube...
  • It displays only data about the person, not about the single contacts.
Massively disagree --D ed 16:15, 19 July 2012 (BST)
  • It needs information about the im accounts (i.e. to show a list of accounts with their status in the tooltip).
I'm confused, that's the opposite of what you just said above --D ed 16:15, 19 July 2012 (BST)
  • 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)
  • Show custom set information on a person (i.e override the users displayed name, so if Vishesh sets his alias to "Mr Hot Stuff", I can override it back (locally) to "Vishesh Handa")
  • Still allow visible access to the original data
  • Allow a user to create a person from individual contacts
  • It might have some contact merging capability (i.e. drag and drop a contact over another one).
  • Be able to start a text chat with this contact
  • Filter contacts related to a specific activity

Other

  • Be able to start a custom activity with this contact (i.e kwhiteboard-launcher starts a whiteboard channel)
  • Display the user-set name for a person from inside an application with a contact (text-ui)
  • Tag a received file as recieved by a given contact so this can be displayed in Dolphin

PIM

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}?)

Recipient Autocompletion

  • cf. KMail composer and KOrganizer invitation dialog
  • As you type search for a person, showing pictures to make it easier to find the one your are looking for
  • Ability to select one out of possible more email addresses.

Status display and actions for a specific Person

  • cf. KMail message viewer
  • Ability to show image and e.g. IM status of a person based on a given email address
  • Ability to trigger actions related to this person, such as starting a chat

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?

Retrieved from "https://community.kde.org/index.php?title=Projects/Nepomuk/Pimo_Person_Discussion&oldid=22853"