Projects/Nepomuk/Pimo Person Discussion

From KDE Community Wiki
Revision as of 10:10, 16 July 2012 by Vhanda (talk | contribs) (basic summary)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.

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.