1. Contacts ontology

We are using Nepomuk NCO ontology as basis in tracker. We have modified it to suit the needs of the real world applications; this implies some assumptions and some expectations how the ontology must be used. This page collects that knowledge.

1.1. Metacontacts

Some contacts come from IM accounts, others from the local addressbook, and we need a way to merge them at ontology level.

1.1.1. Authors

• Ivan Frade, Tracker <ivan.frade@nokia.com>

• Ian Monroe, Telepathy <ian.monroe@collabora.co.uk>

1.1.2. Changes introduced in Nepomuk

• New classes

  • nco:MetaContact

  • nco:IMContact (subclass of nfo:PersonContact). It is a person contact that comes from an IM Account.

  • nco:PresenceStatus a class that contains predefined instances with presence levels. These levels are taken from Telepathy Spec

  • nco:IMCapability: a predefined set of instances for the features supported by a certain Contact. Values taken from Telepathy QT spec

• New properties
  • nco:fromIMAccount (nco:IMContacts, nco:IMAccount)
    • Indicates that the IM Contact and its details has been imported from certain IM Account.

  • nco:metacontact (nco:PersonContact, nco:MetaContact)

  • nco:imContactID, nco:imContactNickname, nco:imContactStatusMessage to set this information in the nco:IMContact
  • nco:imDisplayName, nco:imEnable, nco:imAccountAvatar to nco:IMAccount representing this information about 'me'.
  • nco:imContactCapability (nco:IMContact, nco:IMCapability): that contact support certain feature (voice, video, file-transfer...)
• Changed properties:

  • nco:hasIMAccount (nco:Role, nco:IMAccount) -> nco:hasIMAccount (nco:PersonContact, nco:IMAccount)

    • Different semantic: it indicates that a PersonContact has an IM account in certain service/server. Technically only 'me' in the ontology will have IM Accounts configured.

  • nco:imStatus (nco:IMAccount, xsd:string) -> nco:imPresence (nco:IMAccount, nco:PresenceStatus)

• Other changes:
  • Added predefined instance for "me": nco:default-contact-me

1.1.3. Diagram

Contact-metacontact.png

1.1.4. Description of the changes

• It is important to understand that there are "my accounts" in jabber, gmail, MSN... and there are the contacts inside each of those accounts.

• A nco:PersonContact can have nco:IMAccounts using the property nco:hasIMAccount. Conceptually, only the predefined user "me" can have IMAccounts, but that restriction is not included in the ontology)

• After logging in an IMAccount, we can retrieve contacts from there. Those new contacts are nco:IMContact, and are linked with the account they come
  • from via nco:fromIMAccount
• IMAccount contain the details of user 'me' (imNickname, imPresence, imStatusMessage...). To store the same information about the remote contacts, we have similar properties for IMContact (imContactNickname, imContactPresence,...)

• Every contact can be linked with (at most) one nco:MetaContact.

  • We can understand "MetaContact" as the person in the real world, "PersonContact" what we add by hand or via sync to our address book, and "IMContact" what comes from IM services. So multiple Person/IM Contacts can be linked with one (but only one) MetaContact. This link is done with the nco:metacontact property.

• When two contacts refer to the same person in the real world, they should share the same nco:MetaContact instance.

• The picture/avatar of the nco:IMContacts is set with nco:photo (inherited from nco:Contact), while 'my' avatar in an account is set with nco:imAccountAvatar.
• The IMContact has a property "imContactCapability" to store what kind of features are available in the connection with that contact.

1.1.5. Implementation / Open issues

• Is it mandatory to have a MetaContact instance per individual contact? or only after merge?

• MetaContact contains any information or is just an ID to merge contacts?

• The uris for IMAccount has the following format: telepathy:/account/path (e.g. telepathy:/org/freedesktop...)

1.2. More discussion

Well, I now comment the current tracker's nco (0.7.14):

• I think IMContact should not exist because you loose meaning as IMContact is both a Contact and a ContactMedium, so when an apps will want to get all the PersonContact and their ContactMedium it won't know that the contact has an IMAccount. So just use nepomuk's IMAccount instead but keep the capability, presence and fromIMAccount great properties !

• Then delete the MetaContact class as it's not needed anymore; moreover it will avoid data duplication (e.g. a name in PersonContact and another one in IMContact) and all issues it raises.

• Add new ContactMedium to get a usefull PersonContact class; e.g. here are my ideas:

  • OnlineServiceAccount

  • SocialNetworkAccount (subclass of OnlineServiceAccount)

  • MicroBloggingAccount (subclass of OnlineServiceAccount)

How to use nco:Role and nco:Affiliation : I think roles & affiliations are a great way to handle a "work" and a "personal" (and whatever other role you can associate to a contact) role for each contact. A contact always has a 'PERSONAL' role (because nco:PersonContact doesn't have properties : nco:title, nco:org, nco:department and nco:role) (So the default role -PersonContact- can only be 'PERSONAL'). Then every nco:Affiliation added to a contact should be tagged with "WORK" or "OTHER" (for v-card export) and with a user defined string (for user ). Don't know how to handle that : maybe a nao:Tag with "WORK", "PERSONAL", "OTHER" as rdfs:title and the user defined string as nao:prefLabel.

Some mockups of an address book using this idea of Role & Affiliation... coming soon illustration.png