[tracker/tracker-1.4] docs: Spelling fixes

[Martyn James Russell <mr src gnome org>]

commit 490404e8a8e9bfc05742845fccfd71553b19f697
Author: Ville Skyttä <ville skytta iki fi>
Date:   Tue Jun 30 16:05:58 2015 +0300

    docs: Spelling fixes
    
    https://bugzilla.gnome.org/show_bug.cgi?id=751724

 docs/manpages/tracker-index.1        |    2 +-
 docs/ontologies/README.ontologiesdoc |    2 +-
 docs/ontologies/mlo/explanation.xml  |    2 +-
 docs/ontologies/nie/explanation.xml  |    6 +++---
 docs/ontologies/nmo/explanation.xml  |    4 ++--
 5 files changed, 8 insertions(+), 8 deletions(-)
---
diff --git a/docs/manpages/tracker-index.1 b/docs/manpages/tracker-index.1
index 85f5e23..30a3216 100644
--- a/docs/manpages/tracker-index.1
+++ b/docs/manpages/tracker-index.1
@@ -17,7 +17,7 @@ snapshot of the working tree in a database.
 
 The index command allows some level of control on existing data
 indexed, such as re-indexing content from a specific demographic -
-e.g. all JPEG images, or simply reindexing an existing or non-existant
+e.g. all JPEG images, or simply reindexing an existing or non-existent
 file.
 
 It may be a good idea to backup your index before an upgrade in case
diff --git a/docs/ontologies/README.ontologiesdoc b/docs/ontologies/README.ontologiesdoc
index 70de288..17ca7b3 100644
--- a/docs/ontologies/README.ontologiesdoc
+++ b/docs/ontologies/README.ontologiesdoc
@@ -42,7 +42,7 @@ defining a new id in the explanation document.
 
  All images (don't forget point 4. explained above) are copied in the
 root HTML directory, so internally in the documentation must be
-refered using just the filename:
+referred using just the filename:
 
  E.G. <graphic fileref="images-overview.png" ...
 
diff --git a/docs/ontologies/mlo/explanation.xml b/docs/ontologies/mlo/explanation.xml
index 7e419f8..349a1c7 100644
--- a/docs/ontologies/mlo/explanation.xml
+++ b/docs/ontologies/mlo/explanation.xml
@@ -30,7 +30,7 @@
        </para>
      </listitem>
    </orderedlist>
-   <para>These three representations are not exclusive, but is responsability of the applications to keep 
the data consistent.</para>
+   <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>
diff --git a/docs/ontologies/nie/explanation.xml b/docs/ontologies/nie/explanation.xml
index 1ee15fd..954ffd0 100644
--- a/docs/ontologies/nie/explanation.xml
+++ b/docs/ontologies/nie/explanation.xml
@@ -13,8 +13,8 @@
 
 <para>
  <link linkend="nie-DataObject">nie:DataObject</link> class represents a bunch of
- bytes somwhere (local or remote), the physical entity that contain
- data. The <emphasis>meaning</emphasis> (intepretation) of that entity, the
+ 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
@@ -121,7 +121,7 @@ its album).
 <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 efficency 
reasons in Tracker we use the same URI for both of them.</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>
diff --git a/docs/ontologies/nmo/explanation.xml b/docs/ontologies/nmo/explanation.xml
index bc47cdb..dab192c 100644
--- a/docs/ontologies/nmo/explanation.xml
+++ b/docs/ontologies/nmo/explanation.xml
@@ -30,7 +30,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 beggining and end is also important to sort 
the information in the UI.</para>
+    <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>
@@ -67,7 +67,7 @@
     <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 usefull 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>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>