[tracker: 15/20] docs: Fix some broken links in ontology introduction docs

[Carlos Garnacho <carlosg src gnome org>]

commit fe6adc258def0984b498640f4f343677c8289137
Author: Carlos Garnacho <carlosg gnome org>
Date:   Sat Oct 13 15:28:15 2018 +0200

    docs: Fix some broken links in ontology introduction docs
    
    There were also some references to no longer existing ontology, that's
    been wiped out.

 docs/reference/ontology/mfo-introduction.xml |  8 ++++----
 docs/reference/ontology/mlo-introduction.xml | 16 +++++++--------
 docs/reference/ontology/nco-introduction.xml |  2 +-
 docs/reference/ontology/nie-introduction.xml | 30 ++++++++++++++--------------
 docs/reference/ontology/nmm-introduction.xml |  4 ++--
 docs/reference/ontology/nmo-introduction.xml | 25 +++++++++++------------
 6 files changed, 42 insertions(+), 43 deletions(-)
---
diff --git a/docs/reference/ontology/mfo-introduction.xml b/docs/reference/ontology/mfo-introduction.xml
index d78aff3e1..84a2154a3 100644
--- a/docs/reference/ontology/mfo-introduction.xml
+++ b/docs/reference/ontology/mfo-introduction.xml
@@ -7,15 +7,15 @@
 
 <para>The basic assumption in the ontology is that all these feeds are unidirectional conversations with 
(from) the author of the content and every post on those channels is a message.</para>
 
-<para>The source of the posts, the feed itself, is an instance of <link 
linkend="mfo-FeedChannel">mfo:FeedChannel</link>. Each post in that feed will be an instance of <link 
linkend="mfo-FeedMessage">mfo:FeedMessage</link> . The relation between the messages and the channel comes 
from their superclasses, <link linkend="nmo-communicationChannel">nmo:communicationChannel</link> (taking 
into account that <link linkend="mfo-FeedChannel">mfo:FeedChannel</link> is a subclass of <link 
linkend="nmo-CommunicationChannel">nmo:CommunicationChannel</link> and <link 
linkend="mfo-FeedMessage">mfo:FeedMessage</link> a subclass of <link 
linkend="nmo-Message">nmo:Message</link>).</para>
+<para>The source of the posts, the feed itself, is an instance of <link 
linkend="mfo-FeedChannel">mfo:FeedChannel</link>. Each post in that feed will be an instance of <link 
linkend="mfo-FeedMessage">mfo:FeedMessage</link> . The relation between the messages and the channel comes 
from their superclasses, <link linkend="nmo-Message.nmo-communicationChannel">nmo:communicationChannel</link> 
(taking into account that <link linkend="mfo-FeedChannel">mfo:FeedChannel</link> is a subclass of <link 
linkend="nmo-CommunicationChannel">nmo:CommunicationChannel</link> and <link 
linkend="mfo-FeedMessage">mfo:FeedMessage</link> a subclass of <link 
linkend="nmo-Message">nmo:Message</link>).</para>
 
-<para>A post can be plain text but can contain also more things like links, videos or Mp3. We represent 
those internal pieces in instances of <link linkend="mfo-Enclosure.">mfo:Enclosure.</link> This class has 
properties to link with the remote and local representation of the resource (in case the content has been 
downloaded).</para>
+<para>A post can be plain text but can contain also more things like links, videos or Mp3. We represent 
those internal pieces in instances of <link linkend="mfo-Enclosure">mfo:Enclosure.</link> This class has 
properties to link with the remote and local representation of the resource (in case the content has been 
downloaded).</para>
 
-<para>Finally, the three important classes (mfo:FeedChannel, mfo:FeedMessage, mfo:Enclosure) are subclasses 
of <link linkend="mfo-FeedElement">mfo:FeedElement</link>, just an abstract class to share the link with 
mfo:FeedSettings. <link linkend="mfo-FeedSettings">mfo:FeedSettings</link> contains some common configuration 
options. Not all of them applies to all, but it is a quite cleaner solution. For instance the <link 
linkend="mfo-maxSize">mfo:maxSize</link> property only makes sense per-enclosure, while the <link 
linkend="mfo-updateInterval">mfo:updateInterval</link> is useful for the channel.</para>
+<para>Finally, the three important classes (mfo:FeedChannel, mfo:FeedMessage, mfo:Enclosure) are subclasses 
of <link linkend="mfo-FeedElement">mfo:FeedElement</link>, just an abstract class to share the link with 
mfo:FeedSettings. <link linkend="mfo-FeedSettings">mfo:FeedSettings</link> contains some common configuration 
options. Not all of them applies to all, but it is a quite cleaner solution. For instance the <link 
linkend="mfo-FeedSettings.mfo-maxSize">mfo:maxSize</link> property only makes sense per-enclosure, while the 
<link linkend="mfo-FeedSettings.mfo-updateInterval">mfo:updateInterval</link> is useful for the 
channel.</para>
  </sect2>
 
  <sect2 id="mfo-special-remarks">
   <title>Special remarks</title>
-<para>In some feeds, like <ulink url="http://video.search.yahoo.com/mrss";>"Yahoo Media RSS</ulink>, there 
can be multiple enclosures together in a group, representing the same resource in different formats, 
qualities, resolutions, etc. Until further notify, the group will be represented using <link 
linkend="nie-identifier">nie:identifier</link> property . To mark the default enclosure of the group, there 
is a <link linkend="mfo-groupDefault">mfo-groupDefault</link> property</para>
+<para>In some feeds, like <ulink url="http://video.search.yahoo.com/mrss";>"Yahoo Media RSS</ulink>, there 
can be multiple enclosures together in a group, representing the same resource in different formats, 
qualities, resolutions, etc. Until further notify, the group will be represented using <link 
linkend="nie-InformationElement.nie-identifier">nie:identifier</link> property . To mark the default 
enclosure of the group, there is a <link linkend="mfo-Enclosure.mfo-groupDefault">mfo-groupDefault</link> 
property</para>
  </sect2>
 </section>
diff --git a/docs/reference/ontology/mlo-introduction.xml b/docs/reference/ontology/mlo-introduction.xml
index 0940da721..2c67715ed 100644
--- a/docs/reference/ontology/mlo-introduction.xml
+++ b/docs/reference/ontology/mlo-introduction.xml
@@ -16,29 +16,29 @@
    <orderedlist>
      <listitem>
        <para>
-       As a Box (using the class <link linkend="mlo-GeoBoundingBox">mlo:GeoBoundingBox</link> and the 
property <link linkend="mlo-asBoundingBox">mlo:asBoundingBox</link>)
+       As a Box (using the class <link linkend="mlo-GeoBoundingBox">mlo:GeoBoundingBox</link> and the 
property <link linkend="mlo-GeoLocation.mlo-asBoundingBox">mlo:asBoundingBox</link>)
        </para>
      </listitem>
      <listitem>
        <para>
-      As a point with coordinates (using the class <link linkend="mlo-GeoPoint">mlo:GeoPoint</link> and the 
property <link linkend="mlo-asGeoPoint">mlo:asGeoPoint</link>) as a single point in the space with its 
coordinates
+      As a point with coordinates (using the class <link linkend="mlo-GeoPoint">mlo:GeoPoint</link> and the 
property <link linkend="mlo-GeoLocation.mlo-asGeoPoint">mlo:asGeoPoint</link>) as a single point in the space 
with its coordinates
        </para>
      </listitem>
      <listitem>
        <para>
-       As a postal address, with the text description (using the class <link 
linkend="nco-PostalAddress">nco:PostalAddress</link> from <link linkend="nco-ontology">NCO ontology</link> 
and the property <link linkend="mlo-asPostalAddress">mlo:asPostalAddress</link>)
+       As a postal address, with the text description (using the class <link 
linkend="nco-PostalAddress">nco:PostalAddress</link> from <link linkend="nco-ontology">NCO ontology</link> 
and the property <link linkend="mlo-GeoLocation.mlo-asPostalAddress">mlo:asPostalAddress</link>)
        </para>
      </listitem>
    </orderedlist>
    <para>These three representations are not exclusive, but is responsibility of the applications to keep 
the data consistent.</para>
-   <para>Some places in the space has an special meaning, E.G. premises, buildings or services. This fact is 
represented in the ontology with the class <link linkend="mlo-Landmark">mlo:Landmark</link>. The title and 
description of the Landmark itself can be set using the <link 
linkend="nie-InformationElement">nie:InformationElement</link> properties (<link 
linkend="nie-title">nie:title</link>, <link linkend="nie-description">nie:description</link>, ...). A 
location is linked with a landmark with the property <link linkend="mlo-location">mlo:location</link> 
inherited from the superclass Information Element.</para>
-   <para>Landmark can be grouped in categories. For this reason, the ontology provides a property <link 
linkend="mlo-belongsToCategory">mlo:belongsToCategory</link> that links a Landmark with the class <link 
linkend="mlo-LandmarkCategory">mlo:LandmarkCategory</link> . The ontology includes also a predefined set of 
instances, very common an a de-facto standard in the industry.</para>
+   <para>Some places in the space has an special meaning, E.G. premises, buildings or services. This fact is 
represented in the ontology with the class <link linkend="mlo-Landmark">mlo:Landmark</link>. The title and 
description of the Landmark itself can be set using the <link 
linkend="nie-InformationElement">nie:InformationElement</link> properties (<link 
linkend="nie-InformationElement.nie-title">nie:title</link>, <link 
linkend="nie-InformationElement.nie-description">nie:description</link>, ...). A location is linked with a 
landmark with the property <link linkend="nie-InformationElement.mlo-location">mlo:location</link> inherited 
from the superclass Information Element.</para>
+   <para>Landmark can be grouped in categories. For this reason, the ontology provides a property <link 
linkend="mlo-Landmark.mlo-belongsToCategory">mlo:belongsToCategory</link> that links a Landmark with the 
class <link linkend="mlo-LandmarkCategory">mlo:LandmarkCategory</link> . The ontology includes also a 
predefined set of instances, very common an a de-facto standard in the industry.</para>
  </refsect2>
 
  <refsect2 id="mlo-considerations">
    <title>Considerations</title>
 
-   <para>A <link linkend="mlo-Landmark">mlo:Landmark</link> is linked with its location using the property 
<link linkend="mlo-location">mlo:location</link>, inherited from its superclass <link 
linkend="nie-InformationElement">nie:InformationElement</link>.</para>
+   <para>A <link linkend="mlo-Landmark">mlo:Landmark</link> is linked with its location using the property 
<link linkend="nie-InformationElement.mlo-location">mlo:location</link>, inherited from its superclass <link 
linkend="nie-InformationElement">nie:InformationElement</link>.</para>
 
    <para>All classes in the ontology are subclasses of <link 
linkend="nie-InformationElement">nie:InformationElement</link>. It is not indicated in the graphic for the 
sake of clarity.</para>
 
@@ -51,8 +51,8 @@
 
    <para>We want to put special emphasis in the point that the applications must keep the different 
representations of the points consistent. Basically a point in the space is very unlikely to change (the 
point is there or not), but it is not difficult to assume that some application can complete the information, 
taking the postal addresses of the points without coordinates, and set the coordinates using some web 
service.</para>
 
-   <para>A box is considered as a <emphasis>2 dimensions</emphasis> area orientated to the north, aligned to 
parallels and meridians. The area is defined with two points: the southern east point (down left corner, in 
the <link linkend="mlo-bbSouthEast">mlo:bbSouthEast</link> property) and northern western point (upper right 
corner, in the <link linkend="mlo-bbNorthWest">mlo:bbNorthWest</link> property).</para>
+   <para>A box is considered as a <emphasis>2 dimensions</emphasis> area orientated to the north, aligned to 
parallels and meridians. The area is defined with two points: the southern east point (down left corner, in 
the <link linkend="mlo-GeoBoundingBox.mlo-bbSouthEast">mlo:bbSouthEast</link> property) and northern western 
point (upper right corner, in the <link linkend="mlo-GeoBoundingBox.mlo-bbNorthWest">mlo:bbNorthWest</link> 
property).</para>
 
-   <para><link linkend="mlo-LandmarkCategory">mlo:LandmarkCategory</link> has a property <link 
linkend="mlo-isRemovable">mlo:isRemovable</link> to mark is the category is predefined and shouldn't be 
deleted by the applications. Tracker (and probably other backends) doesn't enforce applications to respect 
this value, but consider it a gentleman agreement.</para>
+   <para><link linkend="mlo-LandmarkCategory">mlo:LandmarkCategory</link> has a property <link 
linkend="mlo-LandmarkCategory.mlo-isRemovable">mlo:isRemovable</link> to mark is the category is predefined 
and shouldn't be deleted by the applications. Tracker (and probably other backends) doesn't enforce 
applications to respect this value, but consider it a gentleman agreement.</para>
  </refsect2>
 </section>
diff --git a/docs/reference/ontology/nco-introduction.xml b/docs/reference/ontology/nco-introduction.xml
index b60e6f451..8a295531e 100644
--- a/docs/reference/ontology/nco-introduction.xml
+++ b/docs/reference/ontology/nco-introduction.xml
@@ -29,7 +29,7 @@
  <refsect2 id="nco-PostalAddressRepresentation">
    <title>Postal Address</title>
 
-   <para>Postal address class <link linkend="nco-PostalAddress">nco:PostalAddress</link> represents a point 
in the space defined by the usual street, number, postal code textual data. Most of its parameters come from 
the RFC 2426 section 3.2.1 with few extensions for more granular APIs (<link 
linkend="nco-county">nco:county</link> and <link linkend="nco-district">nco:district</link>)</para>
+   <para>Postal address class <link linkend="nco-PostalAddress">nco:PostalAddress</link> represents a point 
in the space defined by the usual street, number, postal code textual data. Most of its parameters come from 
the RFC 2426 section 3.2.1 with few extensions for more granular APIs (<link 
linkend="nco-PostalAddress.nco-county">nco:county</link> and <link 
linkend="nco-PostalAddress.nco-district">nco:district</link>)</para>
  </refsect2>
 
   <refsect2 id="nco-ImContactsRepresentations">
diff --git a/docs/reference/ontology/nie-introduction.xml b/docs/reference/ontology/nie-introduction.xml
index d1e4e6647..63fcbcbdc 100644
--- a/docs/reference/ontology/nie-introduction.xml
+++ b/docs/reference/ontology/nie-introduction.xml
@@ -23,8 +23,8 @@ ontology.
 
 <para>
 Both sides are linked using the
-property <link linkend="nie-interpretedAs">nie:interpretedAs</link> (and its reverse
-<link linkend="nie-isStoredAs">nie:isStoredAs</link>), indicating the correspondence
+property <link linkend="nie-DataObject.nie-interpretedAs">nie:interpretedAs</link> (and its reverse
+<link linkend="nie-InformationElement.nie-isStoredAs">nie:isStoredAs</link>), indicating the correspondence
 between the physical element and its interpretation. There is also a
 property to
 link <link linkend="nie-InformationElement">nie:InformationElement</link>s,
@@ -42,32 +42,32 @@ its album).
   </para>
   <variablelist>
     <varlistentry>
-      <term><link linkend="nie-title">nie:title</link></term>
+      <term><link linkend="nie-InformationElement.nie-title">nie:title</link></term>
       <listitem><para>Title or name or short text describing the item</para></listitem>
     </varlistentry>
 
     <varlistentry>
-      <term><link linkend="nie-description">nie:description</link></term>
+      <term><link linkend="nie-InformationElement.nie-description">nie:description</link></term>
       <listitem><para>More verbose comment about the element</para></listitem>
     </varlistentry>
 
     <varlistentry>
-      <term><link linkend="nie-language">nie:language</link></term>
+      <term><link linkend="nie-InformationElement.nie-language">nie:language</link></term>
       <listitem><para>To specify the language of the item.</para></listitem>
     </varlistentry>
 
     <varlistentry>
-      <term><link linkend="nie-plainTextContent">nie:plainTextContent</link></term>
+      <term><link linkend="nie-InformationElement.nie-plainTextContent">nie:plainTextContent</link></term>
       <listitem><para>Just the raw content of the file, if it makes sense as text.</para></listitem>
     </varlistentry>
 
     <varlistentry>
-      <term><link linkend="nie-generator">nie:generator</link></term>
+      <term><link linkend="nie-InformationElement.nie-generator">nie:generator</link></term>
       <listitem><para>Software/Agent that set/produced the information.</para></listitem>
     </varlistentry>
 
     <varlistentry>
-      <term><link linkend="nie-usageCounter">nie:usageCounter</link></term>
+      <term><link linkend="nie-InformationElement.nie-usageCounter">nie:usageCounter</link></term>
       <listitem><para>Count number of accesses to the information. It can be an
       indicator of relevance for advanced searches</para></listitem>
     </varlistentry>
@@ -79,7 +79,7 @@ its album).
 <para>There are few important dates for the life-cycle of a resource. These dates are properties of the 
nie:InformationElement class, and inherited for its subclasses:</para>
 <variablelist>
   <varlistentry>
-     <term><link linkend="nie-informationElementDate">nie:informationElementDate</link></term>
+     <term><link 
linkend="nie-InformationElement.nie-informationElementDate">nie:informationElementDate</link></term>
      <listitem>
        <para>This is an ''abstract'' property that act as superproperty of
        the other dates. Don't use it directly.</para>
@@ -87,27 +87,27 @@ its album).
   </varlistentry>
 
   <varlistentry>
-    <term><link linkend="nie-contentLastModified">nie:contentLastModified</link></term>
+    <term><link 
linkend="nie-InformationElement.nie-contentLastModified">nie:contentLastModified</link></term>
     <listitem>
       <para>Modification time of a resource. Usually the mtime of a local file, or information from the 
server for online resources.</para>
     </listitem>
   </varlistentry>
 
   <varlistentry>
-    <term><link linkend="nie-contentCreated">nie:contentCreated</link></term>
+    <term><link linkend="nie-InformationElement.nie-contentCreated">nie:contentCreated</link></term>
     <listitem>
       <para>Creation time of the content. If the contents is created by an application, the same application 
should set the value of this property. Note that this property can be undefined for resources in the 
filesystem because the creation time is not available in the most common filesystem formats.</para>
     </listitem>
   </varlistentry>
 
   <varlistentry>
-    <term><link linkend="nie-contentAccessed">nie:contentAccessed</link></term>
+    <term><link linkend="nie-InformationElement.nie-contentAccessed">nie:contentAccessed</link></term>
     <listitem>
       <para>For resources coming from the filesystem, this is the usual access time to the file. For other  
kind of resources (online or virtual), the application accessing it should update its value.</para>
     </listitem>
     </varlistentry>
     <varlistentry>
-      <term><link linkend="nie-lastRefreshed">nie:lastRefreshed</link></term>
+      <term><link linkend="nie-DataObject.nie-lastRefreshed">nie:lastRefreshed</link></term>
       <listitem>
        <para>.</para>
       </listitem>
@@ -123,8 +123,8 @@ its album).
  <listitem>Every file (local or remote) should generate one DataObject instance and an InformationElement 
instance.</listitem>
  <listitem>Even when Data Objects and Information Elements are completely different things, for efficiency 
reasons in Tracker we use the same URI for both of them.</listitem>
  <listitem>The URI will be an autogenerated ID, and the real location of the item (e.g. 
''file://path/to/file.mp3'') is a property of the Data Object</listitem>
- <listitem>Every DataObject must have the property <link linkend="nie-url">nie:url</link>, that points to 
the location of the resource, and should be used by any program that wants to access it.</listitem>
- <listitem>There is a deprecated property in the ontology: <link 
linkend="nie-isStoredAs">nie:isStoredAs</link> . We discourage its use in the code: in the best case it is a 
loopback to the nie:url value, but in general it can contain any value or not be set at all.</listitem>
+ <listitem>Every DataObject must have the property <link linkend="nie-DataObject.nie-url">nie:url</link>, 
that points to the location of the resource, and should be used by any program that wants to access 
it.</listitem>
+ <listitem>There is a deprecated property in the ontology: <link 
linkend="nie-InformationElement.nie-isStoredAs">nie:isStoredAs</link> . We discourage its use in the code: in 
the best case it is a loopback to the nie:url value, but in general it can contain any value or not be set at 
all.</listitem>
 </orderedlist>
 
 <para>Here comes an example, for the image file /home/user/a.jpeg:</para>
diff --git a/docs/reference/ontology/nmm-introduction.xml b/docs/reference/ontology/nmm-introduction.xml
index 0da24c25e..51353ee24 100644
--- a/docs/reference/ontology/nmm-introduction.xml
+++ b/docs/reference/ontology/nmm-introduction.xml
@@ -13,7 +13,7 @@
 <sect2>
   <title>Images domain</title>
 
-<para>The core of images in NMM ontology is the class <link linkend="nmm-Photo">nmm:Photo.</link> It is 
(through a long hierarchy) a <link linkend="nie-InformationElement">nie:InformationElement</link>, an 
interpretation of some bytes. It has properties to store the basic information (camera, metering mode, white 
balance, flash), and inherits from <link linkend="nfo-Image">nfo:Image</link> orientation (<link 
linkend="nfo-orientation">nfo:orientation</link>) and resolution (<link 
linkend="nfo-verticalResolution">nfo:verticalResolution</link> and <link 
linkend="nfo-horizontalResolution">nfo:horizontalResolution</link>).</para>
+<para>The core of images in NMM ontology is the class <link linkend="nmm-Photo">nmm:Photo.</link> It is 
(through a long hierarchy) a <link linkend="nie-InformationElement">nie:InformationElement</link>, an 
interpretation of some bytes. It has properties to store the basic information (camera, metering mode, white 
balance, flash), and inherits from <link linkend="nfo-Image">nfo:Image</link> orientation (<link 
linkend="nfo-Image.nfo-orientation">nfo:orientation</link>) and resolution (<link 
linkend="nfo-Image.nfo-verticalResolution">nfo:verticalResolution</link> and <link 
linkend="nfo-Image.nfo-horizontalResolution">nfo:horizontalResolution</link>).</para>
 
 <para>Note that for tags, nie:keywords (from nie:InformationElement) can be used, or the <link 
linkend="nao-ontology">NAO</link> ontology.</para>
 </sect2>
@@ -21,7 +21,7 @@
 <sect2>
   <title>Radio domain</title>
 <para>NMM includes classes and properties to represent analog and digital radio stations. There is a class 
<link linkend="nmm-RadioStation">nmm:RadioStation</link> on the <link 
linkend="nie-InformationElement">nie:InformationElement</link> side of the ontology, representing what the 
user sees about that station (genre via PTY codes, icon, plus title inherited from 
nie:InformationElement)</para>
-<para>A <link linkend="nmm-RadioStation">nmm:RadioStation</link> can have one or more <link 
linkend="nmm-carrier">nmm:carrier</link> properties representing the different frequencies (or links when it 
is digitial) it can be tuned. This property links the station with <link 
linkend="nfo-MediaStream">nfo:MediaStream</link>, but usually it will point to one of the subclasses: <link 
linkend="nmm-DigitalRadio">nmm:DigitalRadio</link> (if digital) or <link 
linkend="nmm-AnalogRadio">nmm:AnalogRadio</link> (if analog). An analog station has properties as modulation 
and frequency, while the digial station has streaming bitrate, encoding or protocol.</para>
+<para>A <link linkend="nmm-RadioStation">nmm:RadioStation</link> can have one or more <link 
linkend="nmm-RadioStation.nmm-carrier">nmm:carrier</link> properties representing the different frequencies 
(or links when it is digitial) it can be tuned. This property links the station with <link 
linkend="nfo-MediaStream">nfo:MediaStream</link>, but usually it will point to one of the subclasses: <link 
linkend="nmm-DigitalRadio">nmm:DigitalRadio</link> (if digital) or <link 
linkend="nmm-AnalogRadio">nmm:AnalogRadio</link> (if analog). An analog station has properties as modulation 
and frequency, while the digial station has streaming bitrate, encoding or protocol.</para>
 <para>Note that nfo:MediaStream refers to a flux of bytes/data, and it is on the <link 
linkend="nie-DataObject">nie:DataObject</link> side of the ontology</para>
 
 </sect2>
diff --git a/docs/reference/ontology/nmo-introduction.xml b/docs/reference/ontology/nmo-introduction.xml
index 48a2dfb85..870419e0c 100644
--- a/docs/reference/ontology/nmo-introduction.xml
+++ b/docs/reference/ontology/nmo-introduction.xml
@@ -4,19 +4,19 @@
   <sect2 id="nmo-introduction">
     <title>Introduction</title>
     <para>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 <ulink 
url="http://maemo.nokia.com";>Maemo</ulink>.</para>
-    <para>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 <link linkend="nmm-message-core-class">Message</link> 
class (the core of the whole representation), the <link 
linkend="nmo-conversation-representation">conversation representation</link>, the translation of an <link 
linkend="nmo-email-domain">email</link> to Nepomuk terms, and finally <link 
linkend="nmo-sms-domain">SMS</link> and <link linkend="nmo-mms-domain">MMS</link> representation.</para>
+    <para>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 <link linkend="nmo-message-core-class">Message</link> 
class (the core of the whole representation), the <link 
linkend="nmo-conversation-representation">conversation representation</link>, the translation of an <link 
linkend="nmo-email-domain">email</link> to Nepomuk terms, and finally <link 
linkend="nmo-sms-domain">SMS</link> and <link linkend="nmo-mms-domain">MMS</link> representation.</para>
   </sect2>
 
   <sect2 id="nmo-message-core-class">
     <title>The Message class</title>
 
-    <para>The <link linkend="nmo-Message">nmo:Message</link> class is the common superclass for Emails, SMS, 
IM Messages, MMS (in NMO domain) and even Feed messages (defined in <link linkend="mfo-explanation">MFO 
ontology</link>). 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 <link linkend="nie-InformationElement">nie:InformationElement</link> and from 
there inherits the <link linkend="nie-plainTextContent">nie:plainTextContent</link> property (which, as its 
name states, contains the text of the message).
+    <para>The <link linkend="nmo-Message">nmo:Message</link> class is the common superclass for Emails, SMS, 
IM Messages, MMS (in NMO domain) and even Feed messages (defined in <link linkend="mfo-explanation">MFO 
ontology</link>). 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 <link linkend="nie-InformationElement">nie:InformationElement</link> and from 
there inherits the <link linkend="nie-InformationElement.nie-plainTextContent">nie:plainTextContent</link> 
property (which, as its name states, contains the text of the message).
     </para>
 
     <para>Few considerations from practical point of view:</para>
     <orderedlist>
-      <listitem><para> <link linkend="nmo-to">nmo:to</link> and <link linkend="nmo-from">nmo:from</link> 
should be set always, and there is a predefined instance in NCO for the "me" contact.</para></listitem>
-      <listitem><para> <link linkend="nmo-isSent">nmo:isSent</link> should be used to indicate the direction 
of the message. This helps with the performance of queries to build a conversation view.</para></listitem>
+      <listitem><para> <link linkend="nmo-Message.nmo-to">nmo:to</link> and <link 
linkend="nmo-Message.nmo-from">nmo:from</link> should be set always, and there is a predefined instance in 
NCO for the "me" contact.</para></listitem>
+      <listitem><para> <link linkend="nmo-Message.nmo-isSent">nmo:isSent</link> should be used to indicate 
the direction of the message. This helps with the performance of queries to build a conversation 
view.</para></listitem>
       <listitem><para> Even when there is a <link linkend="nmo-MessageHeader">nmo:MessageHeader</link> 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.</para></listitem>
     </orderedlist>
   </sect2>
@@ -24,7 +24,7 @@
   <sect2 id="nmo-conversation-representation">
     <title>Conversations</title>
     <para>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 beginning and end is also important to sort 
the information in the UI.</para>
-    <para>The ontology provides a <link linkend="nmo-CommunicationChannel">nmo:CommunicationChannel</link> 
class, which groups all messages between a certain set of contacts (linked via <link 
linkend="nmo-hasParticipant">nmo:hasParticipant</link> property). The communication channel can be transient 
(an ad-hoc conversation in IM represented in the subclass <link 
linkend="nmo-TransientChannel">nmo:TransientChannel</link>) or permanent (a well-known IRC channel would be 
an instance of <link linkend="nmo-PermanentChannel">nmo:PermanentChannel</link> ). 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.</para>
+    <para>The ontology provides a <link linkend="nmo-CommunicationChannel">nmo:CommunicationChannel</link> 
class, which groups all messages between a certain set of contacts (linked via <link 
linkend="nmo-CommunicationChannel.nmo-hasParticipant">nmo:hasParticipant</link> property). The communication 
channel can be transient (an ad-hoc conversation in IM represented in the subclass <link 
linkend="nmo-TransientChannel">nmo:TransientChannel</link>) or permanent (a well-known IRC channel would be 
an instance of <link linkend="nmo-PermanentChannel">nmo:PermanentChannel</link> ). 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.</para>
     <para>There is a second important class, <link linkend="nmo-Conversation">nmo:Conversation</link> 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 <link linkend="nmo-Conversation">nmo:Conversation</link> is created.</para>
   </sect2>
 
@@ -32,7 +32,7 @@
     <title>Email domain</title>
     <para>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.</para>
 
-    <para>The ontology represents completely that email tree. The Envelope, root node or more external 
representation of the Email is the basic <link linkend="nmo-Email">nmo:Email</link> class, subclass of 
Message. Every node in the tree is always a <link linkend="nmo-MimePart">nmo:MimePart</link> with the 
required properties to decode the content (mimetype, encoding, boundaries). When the node is internal, then 
it is also instance of <link linkend="nmo-MultiPart">nmo:MultiPart</link> so it can use the <link 
linkend="nie-hasPart">nie:hasPart</link> property to link other nodes. The leaf nodes can be instances of 
specific content classes (besides <link linkend="nmo-MimePart">nmo:MimePart</link>). For example, an MP3 
embedded in an Email, will be represented as an instance nmo:MimePart <emphasis>and</emphasis> <link 
linkend="nmm-MusicPiece">nmm:MusicPiece</link>. </para>
+    <para>The ontology represents completely that email tree. The Envelope, root node or more external 
representation of the Email is the basic <link linkend="nmo-Email">nmo:Email</link> class, subclass of 
Message. Every node in the tree is always a <link linkend="nmo-MimePart">nmo:MimePart</link> with the 
required properties to decode the content (mimetype, encoding, boundaries). When the node is internal, then 
it can use the <link linkend="nie-InformationElement.nie-hasPart">nie:hasPart</link> property to link other 
nodes. The leaf nodes can be instances of specific content classes (besides <link 
linkend="nmo-MimePart">nmo:MimePart</link>). For example, an MP3 embedded in an Email, will be represented as 
an instance nmo:MimePart <emphasis>and</emphasis> <link linkend="nmm-MusicPiece">nmm:MusicPiece</link>. 
</para>
 
     <para>For more detailed (and highly technical) explanation of the email representation in general and 
this example in concrete, please check <ulink 
url="http://live.gnome.org/Tracker/Documentation/Examples/SPARQL/Email";>this wiki page</ulink></para>
   </sect2>
@@ -46,12 +46,11 @@
     </para>
     <itemizedlist>
       <listitem>A <link linkend="nmo-SMSMessage">nmo:SMSMessage</link> instance to represent the message 
itself</listitem>
-      <listitem><link linkend="nmo-to">nmo:to</link> and <link linkend="nmo-from">nmo:from</link> 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).</listitem>
-      <listitem>For some implementations, is useful to save the original vcards. For that <link 
linkend="nmo-fromVCard">nmo:fromVCard</link> and <link linkend="nmo-toVCard">nmo:toVCard</link> properties 
can be used. Those properties point to files in the file system with the vcards</listitem>
-      <listitem><link linkend="nmo-plainTextContent">nmo:plainTextContent</link> inherited from <link 
linkend="nie-InformationElement">nie:InformationElement</link> for the content.</listitem>
-      <listitem><link linkend="nmo-containsSMS">nmo:containsSMS</link> property will link the message with 
the relevant <link linkend="nmo-SMSFolder">nmo:SMSFolder</link>.</listitem>
-      <listitem>If needed, language and characterSet are inherited from NIE (<link 
linkend="nie-language">nie:language</link>, <link linkend="nie-characterSet">nie:characterSet</link>), but 
there is a specific <link linkend="nmo-encoding">nmo:encoding</link> property.</listitem>
-      <listitem>Note that nmo:SMSMessage is a subclass of <link linkend="nmo-Message">nmo:Message</link> and 
inherits all its properties, including <link linkend="nmo-isDeleted">nmo:isDeleted</link></listitem>
+      <listitem><link linkend="nmo-Message.nmo-to">nmo:to</link> and <link 
linkend="nmo-Message.nmo-from">nmo:from</link> 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).</listitem>
+      <listitem>For some implementations, is useful to save the original vcards. For that <link 
linkend="nmo-PhoneMessage.nmo-fromVCard">nmo:fromVCard</link> and <link 
linkend="nmo-PhoneMessage.nmo-toVCard">nmo:toVCard</link> properties can be used. Those properties point to 
files in the file system with the vcards</listitem>
+      <listitem><link linkend="nie-InformationElement.nie-plainTextContent">nie:plainTextContent</link> 
inherited from <link linkend="nie-InformationElement">nie:InformationElement</link> for the 
content.</listitem>
+      <listitem>If needed, language and characterSet are inherited from NIE (<link 
linkend="nie-InformationElement.nie-language">nie:language</link>, <link 
linkend="nie-InformationElement.nie-characterSet">nie:characterSet</link>), but there is a specific <link 
linkend="nmo-PhoneMessage.nmo-encoding">nmo:encoding</link> property.</listitem>
+      <listitem>Note that nmo:SMSMessage is a subclass of <link linkend="nmo-Message">nmo:Message</link> and 
inherits all its properties, including <link 
linkend="nmo-Message.nmo-isDeleted">nmo:isDeleted</link></listitem>
     </itemizedlist>
 
     <para>Here is an example of an SMS Message in Tracker/Nepomuk: </para>
@@ -85,7 +84,7 @@
 
   <sect2 id="nmo-call-domain">
     <title>Call domain</title>
-    <para>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 <link 
linkend="nmo-duration">nmo:duration</link>. Each call is represented as an instance of <link 
linkend="nmo-Call">nmo:Call</link> class. There is also a <link linkend="nmo-VOIPCall">nmo:VOIPCall</link> 
class (subclass of <link linkend="nmo-Call">nmo:Call</link>) for VOIP communications (e.g. Skype, GTalk,...). 
</para>
+    <para>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 <link 
linkend="nmo-Call.nmo-duration">nmo:duration</link>. Each call is represented as an instance of <link 
linkend="nmo-Call">nmo:Call</link> class. There is also a <link linkend="nmo-VOIPCall">nmo:VOIPCall</link> 
class (subclass of <link linkend="nmo-Call">nmo:Call</link>) for VOIP communications (e.g. Skype, GTalk,...). 
</para>
   </sect2>
 
 </section>