docs: Include Nepomuk documentation in hotdoc

Move away from it being in its on gtk-doc build.

18 files changed, 159 insertions, 496 deletions

diff --git a/docs/reference/libtracker-sparql/meson.build b/docs/reference/libtracker-sparql/meson.build
index d616dc1f2..bb24c56ba 100644
--- a/docs/reference/libtracker-sparql/meson.build
+++ b/docs/reference/libtracker-sparql/meson.build
@@ -28,6 +28,18 @@ base_ontology_docs = custom_target('ontology-docgen',
     build_by_default: true,
 )
 
+nepomuk_ontology_docs = custom_target('nepomuk-docgen',
+    output: ['nie-ontology.md'],
+    command: [tracker_docgen,
+              '--md',
+              '-d', join_paths(source_root, 'src/ontologies/nepomuk'),
+              '-o', join_paths(meson.current_build_dir()),
+              '-e', meson.current_source_dir()],
+    depends: tracker_docgen,
+    depend_files: [base_ontology],
+    build_by_default: true,
+)
+
 content = [
   'overview.md',
   'ontologies.md',
@@ -39,15 +51,6 @@ content = [
   'tutorial.md',
 ]
 
-generated_content = [
-  'examples.md',
-  'xsd-ontology.md',
-  'dc-ontology.md',
-  'rdf-ontology.md',
-  'rdfs-ontology.md',
-  'nrl-ontology.md',
-]
-
 required_hotdoc_extensions = [
   'gi-extension',
   'devhelp-extension',
diff --git a/docs/reference/libtracker-sparql/mfo-introduction.md b/docs/reference/libtracker-sparql/mfo-introduction.md
new file mode 100644
index 000000000..73b0b09b2
--- /dev/null
+++ b/docs/reference/libtracker-sparql/mfo-introduction.md
@@ -0,0 +1,17 @@
+# Overview
+
+## Introduction
+
+This ontology is an abstract representation of entries coming from feeds. These feeds can be blogs (any of the common syndication formats can be translated into this representation), podcasts or even some online services (like flickr).
+
+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.
+
+The source of the posts, the feed itself, is an instance of [mfo:FeedChannel](mfo-ontology.md#mfo:FeedChannel). Each post in that feed will be an instance of [mfo:FeedMessage](mfo-ontology.md#mfo:FeedMessage). The relation between the messages and the channel comes from their superclasses, [nmo:communicationChannel](nmo-ontology.md#nmo:communicationChannel) (taking into account that [mfo:FeedChannel](mfo-ontology.md#mfo:FeedChannel) is a subclass of [nmo:CommunicationChannel](nmo-ontology.md#nmo:CommunicationChannel) and [mfo:FeedMessage](mfo-ontology.md#mfo:FeedMessage) a subclass of [nmo:Message](nmo-ontology.md#nmo:Message).
+
+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 [mfo:Enclosure](mfo-ontology.md#mfo:Enclosure). This class has properties to link with the remote and local representation of the resource (in case the content has been downloaded).
+
+Finally, the three important classes (mfo:FeedChannel, mfo:FeedMessage, mfo:Enclosure) are subclasses of [mfo:FeedElement](mfo-ontology.md#mfo:FeedElement), just an abstract class to share the link with mfo:FeedSettings. [mfo:FeedSettings](mfo-ontology.md#mfo:FeedSettings) contains some common configuration options. Not all of them applies to all, but it is a quite cleaner solution. For instance the [mfo:maxSize](mfo-ontology.md#mfo:maxSize) property only makes sense per-enclosure, while the [mfo:updateInterval](mfo-ontology.md#mfo:updateInterval) is useful for the channel.
+
+## Special remarks
+
+In some feeds 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 [nie:identifier](nie-ontology.md#nie:identifier) property. To mark the default enclosure of the group, there is a [mfo:groupDefault](mfo-ontology.md#mfo:groupDefault) property.
diff --git a/docs/reference/libtracker-sparql/nco-introduction.md b/docs/reference/libtracker-sparql/nco-introduction.md
new file mode 100644
index 000000000..0bc29ff42
--- /dev/null
+++ b/docs/reference/libtracker-sparql/nco-introduction.md
@@ -0,0 +1,5 @@
+# Overview
+
+## Introduction
+
+This is the ontology modelling contacts and postal addresses. It also extends the original nepomuk adding the Instant Messaging account details, because an 'identity' in an IM account can be consider also a contact.
diff --git a/docs/reference/libtracker-sparql/nepomuk.md b/docs/reference/libtracker-sparql/nepomuk.md
new file mode 100644
index 000000000..4745414b6
--- /dev/null
+++ b/docs/reference/libtracker-sparql/nepomuk.md
@@ -0,0 +1,10 @@
+---
+title: Nepomuk
+short-description: The Nepomuk ontology
+...
+
+# Nepomuk
+
+Nepomuk is the swiss army knife of the semantic desktop. It defines
+data structures for almost any kind of data you might want to store
+in a workstation machine.
diff --git a/docs/reference/libtracker-sparql/nie-introduction.md b/docs/reference/libtracker-sparql/nie-introduction.md
new file mode 100644
index 000000000..cc386c45b
--- /dev/null
+++ b/docs/reference/libtracker-sparql/nie-introduction.md
@@ -0,0 +1,82 @@
+# Overview
+
+## Introduction
+
+The core of the NEPOMUK Information Element Ontology and the entire
+Ontology Framework revolves around the concepts of [nie:DataObject](nie-ontology.md#nie:DataObject) and
+[nie:InformationElement](nie-ontology.md#nie:InformationElement). They express  the representation
+and content of a piece of data. Their specialized subclasses (defined
+in the other ontologies) can be used to classify
+a wide array of desktop resources and express them in RDF.
+
+[nie:DataObject](nie-ontology.md#nie:DataObject) class represents a bunch of
+bytes somewhere (local or remote), the physical entity that contain
+data. The *meaning* (interpretation) of that entity, the
+information for the user contained in those bytes (e.g. a music file,
+a picture) is represented on the
+[nie:InformationElement](nie-ontology.md#nie:InformationElement) side of the
+ontology.
+
+Both sides are linked using the
+property [nie:interpretedAs](nie-ontology.md#nie:interpretedAs) (and its reverse
+[nie:isStoredAs](nie-ontology.md#nie:isStoredAs)), indicating the correspondence
+between the physical element and its interpretation. There is also a
+property to
+link [nie:InformationElement](nie-ontology.md#nie:InformationElement)s,
+representing the logical containment between them (like a picture and
+its album).
+
+## Common properties
+
+Given that the classes defined in this ontology are the superclasses for almost
+everything in the Nepomuk set of ontologies, the
+properties defined here will be inherited for a lot of classes. It is
+worth to comment few of them with special relevance:
+
+ - [nie:title](nie-ontology.md#nie:title): Title or name or short text describing the item
+ - [nie:description](nie-ontology.md#nie:description): More verbose comment about the element
+ - [nie:language](nie-ontology.md#nie:language): To specify the language of the item.
+ - [nie:plainTextContent](nie-ontology.md#nie:plainTextContent): Just the raw content of the file, if it makes sense as text.
+ - [nie:generator](nie-ontology.md#nie:generator): Software/Agent that set/produced the information.
+ - [nie:usageCounter](nie-ontology.md#nie:usageCounter): Count number of accesses to the information. It can be an indicator of relevance for advanced searches
+
+## Date and timestamp representations
+
+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:
+
+ - [nie:informationElementDate](nie-ontology.md#nie:informationElementDate): This is an ''abstract'' property that act as superproperty of the other dates. Don't use it directly.
+ - [nie:contentLastModified](nie-ontology.md#nie:contentLastModified): Modification time of a resource. Usually the mtime of a local file, or information from the server for online resources.
+ - [nie:contentCreated](nie-ontology.md#nie:contentCreated): 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.
+ - [nie:contentAccessed](nie-ontology.md#nie:contentAccessed): 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.
+ - [nie:lastRefreshed](nie-ontology.md#nie:lastRefreshed): The time that the content was last refreshed. Usually for remote resources.
+
+## URIs and full representation of a file
+
+One of the most common resources in a desktop is a file. Given the split between Data Objects and Information Elements, some times it is not clear how a real file is represented into Nepomuk. Here are some indications:
+
+ 1. Every file (local or remote) should generate one DataObject instance and an InformationElement instance.
+ 2. Even when Data Objects and Information Elements are different entities.
+ 3. The URI of the DataObject is the real location of the item (e.g. ''file://path/to/file.mp3'')
+ 3. The URI of the InformationElement(s) will be autogenerated IDs.
+ 4. Every DataObject must have the property [nie:url](nie-ontology.md#nie:url), that points to the location of the resource, and should be used by any program that wants to access it.
+ 5. The InformationElement and DataObject are related via the nie:isStoredAs / nie:interpretedAs properties.
+
+Here comes an example, for the image file /home/user/a.jpeg:
+
+```
+# Properties as nmm:Photo
+<urn:uuid:10293801928301293> a nmm:Photo ;
+	nie:isStoredAs <file:///home/user/a.jpeg> ;
+	nfo:width 49 ;
+	nfo:height 36 ;
+	nmm:flash &lt;nmm:flash-off&gt;;
+	nmm:whiteBalance <nmm:white-balance-automatic> ;
+	nfo:equipment [ a nfo:Equipment ; nfo:make 'Nokia'; nfo:model 'N900'; nfo:equipmentSoftware 'Tracknon' ] .
+
+# Properties from nfo:FileDataObject
+<file:///home/user/a.jpeg> a nfo:FileDataObject ;
+	nie:interpretedAs <urn:uuid:10293801928301293> ;
+	nfo:fileSize 12341234 ;
+	# Mandatory for any nfo:DataObject
+	nie:url <file:///home/user/a.jpeg> .
+```
diff --git a/docs/reference/libtracker-sparql/nmm-introduction.md b/docs/reference/libtracker-sparql/nmm-introduction.md
new file mode 100644
index 000000000..8b89fc709
--- /dev/null
+++ b/docs/reference/libtracker-sparql/nmm-introduction.md
@@ -0,0 +1,23 @@
+# Overview
+
+## Introduction
+
+This ontology extends NIE (Nepomuk Information Element ontology) and NFO (Nepomuk File Ontology) into the domains of multimedia, including Images, Videos, Music and Radio, and includes a couple of properties to support uPnP sharing.
+
+This ontology replaces/complements NID3 and NEXIF. Those ontologies are a direct map of the respective metadata standards, which makes very difficult to map cleanly other standards (like gstreamer metadata, mp4, ogg, and so on). Besides, those ontologies contain a lot of very low level technical information that is useless to the average user of the desktop.
+
+Our approach in NMM is to keep the minimum properties that make sense for the user, and are present in all (or almost all) specific metadata formats. A profesional photographer (or musician) who needs more fine-grained details for its documents, is free to add also nID3 information or other extensions to the ontology.
+
+## Images domain
+
+The core of images in NMM ontology is the class [nmm:Photo](nmm-ontology.md#nmm:Photo). It is (through a long hierarchy) a [nie:InformationElement](nie-ontology.md#nie:InformationElement), an interpretation of some bytes. It has properties to store the basic information (camera, metering mode, white balance, flash), and inherits from [nfo:Image](nfo-ontology.md#nfo:Image) orientation ([nfo:orientation](nfo-ontology.md#nfo:orientation)) and resolution ([nfo:verticalResolution](nfo-ontology.md#nfo:verticalResolution) and [nfo:horizontalResolution](nfo-ontology.md#nfo:horizontalResolution)).
+
+Note that for tags, nie:keywords (from nie:InformationElement) can be used, or the [NAO](nao-ontology.md) ontology.
+
+## Radio domain
+
+NMM includes classes and properties to represent analog and digital radio stations. There is a class [nmm:RadioStation](nmm-ontology.md#nmm:RadioStation) on the [nie:InformationElement](nie-ontology.md#nie:InformationElement) side of the ontology, representing what the user sees about that station (genre via PTY codes, icon, plus title inherited from nie:InformationElement)
+
+A [nmm:RadioStation](nmm-ontology.md#nmm:RadioStation) can have one or more [nmm:carrier](nmm-ontology.md#nmm:carrier) properties representing the different frequencies (or links when it is digitial) it can be tuned. This property links the station with [nfo:MediaStream](nfo-ontology.md#nfo:MediaStream), but usually it will point to one of the subclasses: [nmm:DigitalRadio](nmm-ontology.md#nmm:DigitalRadio) (if digital) or [nmm:AnalogRadio](nmm-ontology.md#nmm:AnalogRadio) (if analog). An analog station has properties as modulation and frequency, while the digial station has streaming bitrate, encoding or protocol.
+
+Note that nfo:MediaStream refers to a flux of bytes/data, and it is on the [nie:DataObject](nie-ontology.md#nie:DataObject)<link linkend="nie-DataObject">nie:DataObject</link> side of the ontology.
diff --git a/docs/reference/libtracker-sparql/sitemap.txt b/docs/reference/libtracker-sparql/sitemap.txt
index 25fca8227..750975a03 100644
--- a/docs/reference/libtracker-sparql/sitemap.txt
+++ b/docs/reference/libtracker-sparql/sitemap.txt
@@ -3,6 +3,16 @@ index.md
 	examples.md
 	tutorial.md
 	ontologies.md
+		nepomuk.md
+			nie-ontology.md
+			nao-ontology.md
+			nfo-ontology.md
+			nco-ontology.md
+			nmm-ontology.md
+			mfo-ontology.md
+			slo-ontology.md
+			tracker-ontology.md
+			osinfo-ontology.md
 		base-ontology.md
 			xsd-ontology.md
 			dc-ontology.md
diff --git a/docs/reference/meson.build b/docs/reference/meson.build
index 0c76203fa..4919f91a0 100644
--- a/docs/reference/meson.build
+++ b/docs/reference/meson.build
@@ -10,4 +10,3 @@ icon_images = files(
 )
 
 subdir('libtracker-sparql')
-subdir('ontology')
diff --git a/docs/reference/ontology/meson.build b/docs/reference/ontology/meson.build
deleted file mode 100644
index 1799d46da..000000000
--- a/docs/reference/ontology/meson.build
+++ /dev/null
@@ -1,23 +0,0 @@
-version_xml = configure_file(input: 'version.xml.in',
-    output: 'version.xml',
-    configuration: conf)
-
-generated = custom_target('ontology-doc-generated',
-    output: 'gen-doc.stamp',
-    command: [tracker_docgen,
-              '--xml',
-              '-d', join_paths(source_root, 'src/ontologies/nepomuk'),
-              '-o', join_paths(meson.current_build_dir(), 'xml/'),
-              '-e', meson.current_source_dir()],
-    depends: tracker_docgen,
-    depend_files: nepomuk,
-    build_by_default: true,
-)
-
-gnome.gtkdoc('ontology',
-    src_dir: include_directories('.'),
-    main_xml: 'ontology-docs.xml',
-    html_assets: icon_images,
-    module_version: tracker_api_major,
-    depends: [generated],
-    install: true)
diff --git a/docs/reference/ontology/mfo-introduction.xml b/docs/reference/ontology/mfo-introduction.xml
deleted file mode 100644
index 236ea0ba2..000000000
--- a/docs/reference/ontology/mfo-introduction.xml
+++ /dev/null
@@ -1,21 +0,0 @@
-<section id="mfo-explanation">
- <title>Overview</title>
- <sect2 id="mfo-introduction">
-   <title>Introduction</title>
-
-<para>This ontology is an abstract representation of entries coming from feeds. These feeds can be blogs (any of the common syndication formats can be translated into this representation), podcasts or even some online services (like flickr).</para>
-
-<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>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>
- </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>
- </sect2>
-</section>
diff --git a/docs/reference/ontology/mlo-introduction.xml b/docs/reference/ontology/mlo-introduction.xml
deleted file mode 100644
index 0940da721..000000000
--- a/docs/reference/ontology/mlo-introduction.xml
+++ /dev/null
@@ -1,58 +0,0 @@
-<!--
- Usual ids:
-
-    xxx-ontology for the whole ontology
-    xxx-explanation 
-    xxx-classes
-    xxx-properties
--->
-
-<section id="mlo-explanation">
- <title>Overview</title>
- <refsect2 id="mlo-introduction">
-   <title>Introduction</title>
-   
-   <para>This is the proposed ontology to integrate geolocation information in the nepomuk set of ontologies. It defines a place in the space with the class <link linkend="mlo-GeoLocation">mlo:GeoLocation</link>. A place can be defined in different ways:</para>
-   <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>)
-       </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
-       </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>)
-       </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>
- </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>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>
-
-   <para>The three possible representations of a location (i.e. <link linkend="mlo-GeoPoint">mlo:GeoPoint</link>, <link linkend="mlo-GeoBoundingBox">mlo:GeoBoundingBox</link>, <link linkend="nco-PostalAddress">nco:PostalAddress</link>) are <emphasis>properties</emphasis> (and <emphasis>not subclasses</emphasis>) of the location object (instance of <link linkend="mlo-GeoLocation">mlo:GeoLocation</link>).</para>
-
- </refsect2>
-
- <refsect2 id="mlo-comments">
-   <title>Contract with applications</title>
-
-   <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><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>
- </refsect2>
-</section>
diff --git a/docs/reference/ontology/nco-introduction.xml b/docs/reference/ontology/nco-introduction.xml
deleted file mode 100644
index b60e6f451..000000000
--- a/docs/reference/ontology/nco-introduction.xml
+++ /dev/null
@@ -1,55 +0,0 @@
-<!--
- Usual ids:
-
-    xxx-ontology for the whole ontology
-    xxx-explanation 
-    xxx-classes
-    xxx-properties
--->
-
-<section id="nco-explanation">
- <title>Overview</title>
- <sect2 id="nco-introduction">
-   <title>Introduction</title>
-
-   <para>This is the ontology modelling contacts and postal addresses. It also extends the original nepomuk adding the Instant Messaging account details, because an 'identity' in an IM account can be consider also a contact.</para>
-   <para>FIXME This documentation must be completed.</para>
-  <!-- Content -->
- </sect2>
-
- <refsect2 id="nco-ContactRepresentation">
-   <title>A contact in this ontology</title>
-
-   <para>Document here how a contact with work and personal details is represented in the ontology. So far the QtContacts API is using this model to store the information internally, document here all the assumptions they are doing in the code, so a client using pure Sparql is completely compatible with that information</para>
-
-   <para>Do not forget contact groups and affiliations</para>
- </refsect2>
- 
-
- <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>
- </refsect2>
-
-  <refsect2 id="nco-ImContactsRepresentations">
-   <title>IM Accounts and contacts</title>
-
-   <para>Explain here how to represent the accounts of 'me' and the contacts coming from the accounts. Do not forget to explain how do we merge the same user in different accounts under one 'identity'. Also the authorization flow.</para>
- </refsect2>
-
-
- <refsect2 id="nco-special-remarks">
-   <title>Special remarks</title>
-   <para>Maybe we need to add here something</para>
- </refsect2>
-
-
- <refsect2 id="nco-related-information">
-   <title>Related information</title>
-   <para>Links to external docs (QT-contacts, Qt-Landmarks would be nice)
-   </para>
- </refsect2>
-
-
-</section>
diff --git a/docs/reference/ontology/nie-introduction.xml b/docs/reference/ontology/nie-introduction.xml
deleted file mode 100644
index d1e4e6647..000000000
--- a/docs/reference/ontology/nie-introduction.xml
+++ /dev/null
@@ -1,158 +0,0 @@
-<section id="nie-explanation">
-<title>Overview</title>
-
-<sect2 id="nie-introduction">
-<title>Introduction</title>
-<para>The core of the NEPOMUK Information Element Ontology and the entire
-  Ontology Framework revolves around the concepts of <link linkend="nie-DataObject">DataObject</link> and
- <link linkend="nie-InformationElement">InformationElement</link>. They express  the representation
- and content of a piece of data. Their specialized subclasses (defined
- in the other ontologies) can be used to classify
- a wide array of desktop resources and express them in RDF.
-</para>
-
-<para>
- <link linkend="nie-DataObject">nie:DataObject</link> class represents a bunch of
- bytes somewhere (local or remote), the physical entity that contain
- data. The <emphasis>meaning</emphasis> (interpretation) of that entity, the
- information for the user contained in those bytes (e.g. a music file,
- a picture) is represented on the
-<link linkend="nie-InformationElement">nie:InformationElement</link> side of the
-ontology.
-</para>
-
-<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
-between the physical element and its interpretation. There is also a
-property to
-link <link linkend="nie-InformationElement">nie:InformationElement</link>s,
-representing the logical containment between them (like a picture and
-its album).
-</para>
-
-<sect3 id="nie-common-properties">
-  <title>Common properties</title>
-  <para>
-    Given that the classes defined in this ontology are the superclasses for almost
-    everything in the Nepomuk set of ontologies, the
-    properties defined here will be inherited for a lot of classes. It is
-    worth to comment few of them with special relevance:
-  </para>
-  <variablelist>
-    <varlistentry>
-      <term><link linkend="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>
-      <listitem><para>More verbose comment about the element</para></listitem>
-    </varlistentry>
-
-    <varlistentry>
-      <term><link linkend="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>
-      <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>
-      <listitem><para>Software/Agent that set/produced the information.</para></listitem>
-    </varlistentry>
-
-    <varlistentry>
-      <term><link linkend="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>
-  </variablelist>
-</sect3>
-
-<sect3 id="nie-dates-timestamps">
-<title>Dates and timestamps representations</title>
-<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>
-     <listitem>
-       <para>This is an ''abstract'' property that act as superproperty of
-       the other dates. Don't use it directly.</para>
-     </listitem>
-  </varlistentry>
-
-  <varlistentry>
-    <term><link linkend="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>
-    <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>
-    <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>
-      <listitem>
-	<para>.</para>
-      </listitem>
-    </varlistentry>
-</variablelist>
-</sect3>
-</sect2>
-
-<refsect2 id="nie-uri-representation">
-<title>URIs and full representation of a file</title>
-<para>One of the most common resources in a desktop is a file. Given the split between Data Objects and Information Elements, some times it is not clear how a real file is represented into Nepomuk. Here are some indications:</para>
-<orderedlist>
- <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>
-</orderedlist>
-
-<para>Here comes an example, for the image file /home/user/a.jpeg:</para>
-
-<programlisting>
-&lt;urn:uuid:10293801928301293&gt; a nmm:Photo, nfo:FileDataObject ;
-	# Properties as nmm:Photo
-	 nfo:width 49 ;
-	 nfo:height 36 ;
-	nmm:flash &lt;nmm:flash-off&gt;;
-	nmm:whiteBalance &lt;nmm:white-balance-automatic&gt; ;
-	nfo:equipment [ a nfo:Equipment ; nfo:make 'Nokia'; nfo:model 'N900'; nfo:equipmentSoftware 'Tracknon' ] ;
-
-	# Properties from nfo:FileDataObject
-	nfo:fileSize 12341234 ;
-
-	# Mandatory for any nfo:DataObject
-	nie:url &lt;file:///home/ivan/test/CC-test-big.png&gt; .
-
-</programlisting>
-
-</refsect2>
-
- <refsect2 id="nie-related-information">
-  <title>Related information</title>
-
-  <para>This explanation is just a brief extract from the
-    original <ulink url="http://www.semanticdesktop.org/ontologies/nie">
-      Nepomuk NIE Ontology</ulink> web page.</para>
-  </refsect2>
-</section>
diff --git a/docs/reference/ontology/nmm-introduction.xml b/docs/reference/ontology/nmm-introduction.xml
deleted file mode 100644
index e5a789de2..000000000
--- a/docs/reference/ontology/nmm-introduction.xml
+++ /dev/null
@@ -1,28 +0,0 @@
-<refsection id="nmm-overview">
-<title>Overview</title>
-<refsection>
-<title>Introduction</title>
-
-<para>This ontology extends NIE (Nepomuk Information Element ontology) and NFO (Nepomuk File Ontology) into the domains of multimedia, including Images, Videos, Music and Radio, and includes a couple of properties to support uPnP sharing.</para>
-
-<para>This ontology replaces/complements NID3 and NEXIF. Those ontologies are a direct map of the respective metadata standards, which makes very difficult to map cleanly other standards (like gstreamer metadata, mp4, ogg, and so on). Besides, those ontologies contain a lot of very low level technical information that is useless to the average user of the desktop.</para>
-
-<para>Our approach in NMM is to keep the minimum properties that make sense for the user, and are present in all (or almost all) specific metadata formats. A profesional photographer (or musician) who needs more fine-grained details for its documents, is free to add also nID3 information or other extensions to the ontology.</para>
-</refsection>
-
-<refsection>
-  <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>Note that for tags, nie:keywords (from nie:InformationElement) can be used, or the <link linkend="nao-ontology">NAO</link> ontology.</para>
-</refsection>
-
-<refsection>
-  <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>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>
-
-</refsection>
-</refsection>
diff --git a/docs/reference/ontology/nmo-introduction.xml b/docs/reference/ontology/nmo-introduction.xml
deleted file mode 100644
index 74301c820..000000000
--- a/docs/reference/ontology/nmo-introduction.xml
+++ /dev/null
@@ -1,90 +0,0 @@
-<section id="nmo-explanation">
-  <title>Overview</title>
-
-  <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="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>
-
-    <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> 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>
-
-  <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>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>
-
-  <sect2 id="nmo-email-domain">
-    <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 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>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>
-
-  <sect2 id="nmo-sms-domain">
-    <title>SMS domain</title>
-    <para>We have a new subclass of message to represent a SMS Message. It is worth to remark that we are talking about a <emphasis>simple</emphasis> text message. Things like MMS are more complex (more similar to an email than a simple message), and will have their own classes.
-    </para>
-
-    <para>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:
-    </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="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-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>
-    </itemizedlist>
-
-    <para>Here is an example of an SMS Message in Tracker/Nepomuk: </para>
-    <programlisting>
-
- # 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
- &lt;file:///home/user/.sms/vcards/123098.vcard&gt; a nfo:FileDataObject
-
- &lt;test://1&gt; a nmo:SMSMessage ;
-        nmo:from &lt;nco:default-contact-me&gt; ;
-        nmo:to  &lt;urn:uuid:here-some-uri-of-a-contact&gt; ;
-        nmo:plainTextContent "Forgot the keys. Are you at home?" ;
-        nie:characterSet "utf-8" ;
-        nmo:toVCard &lt;file:///home/user/.sms/vcards/123098.vcard&gt; ;
-        nmo:isDeleted false .
-
- &lt;nmo:default-sms-folder-inbox&gt; nmo:containsSMS  &lt;test://1&gt;
-
-    </programlisting>
-  </sect2>
-
-  <sect2 id="nmo-mms-domain">
-    <title>MMS Messages</title>
-    <para>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 <link linkend="nmo-MMSMessage">nmo:MMSMessage</link> that inherits from SMS (to get the folders properties) and from <link linkend="nmo-Email">nmo:Email</link> (to use the Multipart/MimePart structure). Please refer to the SMS and Email documentation for more details.</para>
-  </sect2>
-
-  <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>
-  </sect2>
-
-</section>
diff --git a/docs/reference/ontology/ontology-docs.xml b/docs/reference/ontology/ontology-docs.xml
deleted file mode 100644
index 723fcd17c..000000000
--- a/docs/reference/ontology/ontology-docs.xml
+++ /dev/null
@@ -1,52 +0,0 @@
-<?xml version="1.0"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
-               "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % local.common.attrib "xmlns:xi  CDATA  #FIXED 'http://www.w3.org/2003/XInclude'">
-<!ENTITY version SYSTEM "version.xml">
-]>
-<book id="index" xmlns:xi="http://www.w3.org/2003/XInclude">
-  <bookinfo>
-    <title>Tracker Ontology Reference Manual</title>
-    <releaseinfo>
-	  for Tracker &version;.
-	  The latest version of this documentation can be found on-line at
-	  <ulink role="online-location" url="http://library.gnome.org/devel/ontology/unstable">
-		http://library.gnome.org/devel/ontology/unstable
-	  </ulink>.
-	</releaseinfo>
-  </bookinfo>
-
-  <part id="overview">
-    <title>Overview</title>
-    <partintro>
-      <para>
-        <ulink url="http://www.tracker-project.org">Tracker</ulink> is a central repository of user information, that provides two big benefits for the desktop: <emphasis>Share</emphasis> data between applications (it doesn't matter the source once it is stored in the repository) and <emphasis>Link</emphasis> information from different sources (mixing contacts with files, location, activities and whatnot).
-      </para>
-      <para>
-        This central repository can work only with a very well defined data model, that applications can rely to store and recover their information. That data model is defined using a semantic web artifact called <emphasis>ontology</emphasis>. An ontology defines the concepts (classes) and properties (attributes) that the items in the repository can be/have.
-      </para>
-      <para>
-        There is an EU-funded project called <ulink url="http://nepomuk.semanticdesktop.org/">Nepomuk</ulink>, where a core of ontologies to model the Desktop were defined. This set was a very good starting point for Tracker but new requirements and heavy development in collaboration with applications provided a very valuable feedback, in form of fixes and extensions. Some of this work is already submitted for approval in the upstream version, but the process is long and hard, so the Tracker ontologies are diverging slowly.
-      </para>
-      <para>
-        This documentation describes the Tracker flavour of Nepomuk ontologies. The big picture and basic concepts are the same as in the original Nepomuk, but "hell and heaven are in the details". All classes, properties and restrictions included in these pages should work in Tracker. Any error in this documentation can be reported in the Tracker <ulink url="http://mail.gnome.org/mailman/listinfo/tracker-list">Mailing list</ulink> or <ulink url="https://bugzilla.gnome.org/enter_bug.cgi?product=tracker">bugzilla</ulink>.
-      </para>
-      <para>
-        This is just documentation about the ontologies. For more information about Tracker technical details and implementation, please refer to the Tracker <ulink url="http://live.gnome.org/Tracker/Documentation/">Documentation wiki</ulink> page in GNOME.
-      </para>
-    </partintro>
-  </part>
-
-  <part id="ontology">
-    <title>Ontology</title>
-    <xi:include href="xml/nie-ontology.xml" />
-    <xi:include href="xml/nao-ontology.xml"/>
-    <xi:include href="xml/nfo-ontology.xml" />
-    <xi:include href="xml/nco-ontology.xml" />
-    <xi:include href="xml/nmm-ontology.xml" />
-    <xi:include href="xml/mfo-ontology.xml" />
-    <xi:include href="xml/slo-ontology.xml" />
-    <xi:include href="xml/tracker-ontology.xml" />
-    <xi:include href="xml/osinfo-ontology.xml" />
-  </part>
-</book>
diff --git a/docs/reference/ontology/ontology-sections.txt b/docs/reference/ontology/ontology-sections.txt
deleted file mode 100644
index e69de29bb..000000000
--- a/docs/reference/ontology/ontology-sections.txt
+++ /dev/null
diff --git a/docs/reference/ontology/version.xml.in b/docs/reference/ontology/version.xml.in
deleted file mode 100644
index c7e1225e2..000000000
--- a/docs/reference/ontology/version.xml.in
+++ /dev/null
@@ -1 +0,0 @@
-@TRACKER_VERSION@