docs: Spelling fixes

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

5 files changed, 8 insertions, 8 deletions

diff --git a/docs/manpages/tracker-index.1 b/docs/manpages/tracker-index.1
index 85f5e23d1..30a32169e 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 70de28824..17ca7b3ca 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 7e419f8c0..349a1c705 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 1ee15fd19..954ffd017 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 bc47cdbec..dab192cb9 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>