## NMO Ontology

Authors:
  - Tracker Developers
  - Ludger van Elst, DFKI, <elst@dfki.uni-kl.de>
  - Michael Sintek, DFKI, <michael.sintek@dfki.de>
  - Leo Sauermann, DFKI, <leo.sauermann@dfki.de>
  - Antoni Mylka, DFKI, <antoni.mylka@dfki.de>
Editors:
  - Antoni Mylka, DFKI, <antoni.mylka@dfki.de>
  - Tracker developers (translation into turtle)
Contributors:
  - Christiaan Fluit, Aduna, <christiaan.fluit@aduna-software.com>
  - Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <stexx@mail.ru>
Upstream:

  Upstream version

ChangeLog:

  Tracker changes

Copyright:

  © 2007 DFKI © 2009 Nokia. The ontologies are made available under the terms of NEPOMUK software license (FIXME verify)

## Overview

### Introduction

NEPOMUK Message Ontology extends the NEPOMUK Information Element framework into the domain of messages. This ontology has been heavily extended by Tracker team to include real support for Emails, IM Accounts, SMS and Calls relevant in environments like Maemo.

The messaging domain is too wide to be explained in one shot. For that reason, it has been splitted in few smaller pieces easier to grasp: the Message class (the core of the whole representation), the conversation representation, the translation of an email to Nepomuk terms, and finally SMS and MMS representation.

### The Message class

The nmo:Message class is the common superclass for Emails, SMS, IM Messages, MMS (in NMO domain) and even Feed messages (defined in MFO ontology). As such, it has the common properties for a 'Message' as an meaningful item in a communication: sender and receiver of the message, sent/received time, status of the message (read, answered and so on). It is a subclass of nie:InformationElement and from there inherits the nie:plainTextContent property (which, as its name states, contains the text of the message).

Few considerations from practical point of view:

1. nmo:to and nmo:from should be set always, and there is a predefined instance in NCO for the "me" contact.

2. nmo:isSent should be used to indicate the direction of the message. This helps with the performance of queries to build a conversation view.

3. Even when there is a nmo:MessageHeader class that can store any arbitrary pair of key-values, its use must be as limited as possible. It is there to store the specific headers in the messages (mainly email) that cannot be completely represented in the ontology. Handle those headers in queries is a performance bottleneck that should be avoided in general.

Figure 2. Graphical Overview (Message class)

Notation defined in this page

### Conversations

The dialog between two contacts could be considered a list of messages sorted by time, but that representation is too simplistic. Two contacts can keep a simultaneous communication in two channels (e.g. IM and IRC), and the concept of conversation, a communication with a beggining and end is also important to sort the information in the UI.

The ontology provides a nmo:CommunicationChannel class, which groups all messages between a certain set of contacts (linked via nmo:hasParticipant property). The communication channel can be transient (an ad-hoc conversation in IM represented in the subclass nmo:TransientChannel) or permanent (a well-known IRC channel would be an instance of nmo:PermanentChannel ). Every time 'me' talks with an specific contact, the communication channel should be the same. It identifies somehow the whole list of messages between a set of participants.

There is a second important class, nmo:Conversation to group messages delimited in a time frame. Every time a IM dialog is open (e.g. a window talking with a certain contact) a new instance of nmo:Conversation is created.

### Email domain

The users usually see an Email as a flat Message, with some thread information and maybe 'attachments' in it, but in fact internally an Email message is a tree with a special root node (the envelope) that links to other nodes called MIME parts. This MIME parts can be plain text (for instance the content of the email that the user read) or binary blobs (like a document attached to the message). When a message is forwarded, the previous envelope (the root node of the original message) becomes just a mime part of the forwarded email.

The ontology represents completely that email tree. The Envelope, root node or more external representation of the Email is the basic nmo:Email class, subclass of Message. Every node in the tree is always a nmo:MimePart with the required properties to decode the content (mimetype, encoding, boundaries). When the node is internal, then it is also instance of nmo:MultiPart so it can use the nie:hasPart property to link other nodes. The leaf nodes can be instances of specific content classes (besides nmo:MimePart). For example, an MP3 embedded in an Email, will be represented as an instance nmo:MimePart and nmm:MusicPiece.

For more detailed (and highly technical) explanation of the email representation in general and this example in concrete, please check this wiki page

Figure 3. Graphical Overview (Email related classes)

Notation defined in this page

### Email accounts

Explain here MailAccount and MailFolder

### SMS domain

We have a new subclass of message to represent a SMS Message. It is worth to remark that we are talking about a simple text message. Things like MMS are more complex (more similar to an email than a simple message), and will have their own classes.

An SMS Message comes from the network in vmessage format and contains to/from recipients in vcards. It is represented in the ontology with the following properties:

- A nmo:SMSMessage instance to represent the message itself
- nmo:to and nmo:from linking the contacts (one of them "me", the other a nco:Contact or even a nco:PersonContact if the software is able to identify him).
- For some implementations, is usefull to save the original vcards. For that nmo:fromVCard and nmo:toVCard properties can be used. Those properties point to files in the file system with the vcards
- nmo:plainTextMessageContent inherited from nmo:Message for the content.
- nmo:containsSMS property will link the message with the relevant nmo:SMSFolder.
- If needed, language and characterSet are inherited from NIE (nie:language, nie:characterSet), but there is a specific nmo:encoding property.
- Note that nmo:SMSMessage is a subclass of nmo:Message and inherits all its properties, including nmo:isDeleted

Here is an example of an SMS Message in Tracker/Nepomuk:

     # There are some predefined folder for SMS, like
     #    nmo:default-sms-folder-inbox
     #
     # We also know the 'to' uri from a previous query

     # File containing the 'to' vcard
     <file:///home/user/.sms/vcards/123098.vcard> a nfo:FileDataObject

     <test://1> a nmo:SMSMessage ;
            nmo:from <nco:default-contact-me> ;
            nmo:to  <urn:uuid:here-some-uri-of-a-contact> ;
            nmo:plainTextMessageContent "Forgot the keys. Are you at home?" ;
            nie:characterSet "utf-8" ;
            nmo:toVCard <file:///home/user/.sms/vcards/123098.vcard> ;
            nmo:isDeleted false .

     <nmo:default-sms-folder-inbox> nmo:containsSMS  <test://1>

### MMS Messages

Bascially MMS messages has the structure of Email messages with an SMS envelope. This is exactly how they are represented in the ontology, with an specific class nmo:MMSMessage that inherits from SMS (to get the folders properties) and from nmo:Email (to use the Multipart/MimePart structure). Please refer to the SMS and Email documentation for more details.

### Call domain

Voice calls are considered messages in the ontology. A call is a communication item between two contacts (therefore a Message with to/from properties) with an extra property nmo:duration. Each call is represented as an instance of nmo:Call class. There is also a nmo:VOIPCall class (subclass of nmo:Call) for VOIP communications (e.g. Skype, GTalk,...).