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.

Possible Solutions

Use nao:prefLabel

We could utilize nao:prefLabel and nao:prefSymbol, but that only covers 2 properties. nco:Contact has many more properties which we care about like nco:birthday and nco:nickname.

This approach is a hackish solution at best.

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.