Rename Users documentation to Manual

.gitignore

@@ -51,14 +51,6 @@ lib/CMakeFiles/
 lib/cmake_install.cmake
 
 Documentation/Examples/*.generated
-Documentation/Books/Users/book.json
-Documentation/Books/Users/manual.epub
-Documentation/Books/Users/manual.mobi
-Documentation/Books/Users/manual.pdf
-Documentation/Books/Makefile
-Documentation/Books/Users/node_modules/
-Documentation/Books/ppbooks/
-Documentation/Books/allComments.txt
 
 UnitTests/HttpInterface/logs/
 

Documentation/Books/.gitignore

@@ -1,4 +1,11 @@
 *.md
 **/*.md
 !SUMMARY.md
+*/manual.epub
+*/manual.mobi
+*/manual.pdf
+*/node_modules/
 books
+ppbooks
+Makefile
+allComments.txt

Documentation/Books/AQL/DataModification.mdpp

@@ -177,7 +177,7 @@ RETURN { _key: NEW._key, type: opType }
 The name of the modified collection (*users* and *backup* in the above cases) 
 must be known to the AQL executor at query-compile time and cannot change at 
 runtime. Using a bind parameter to specify the
-[collection name](../Users/Appendix/Glossary.html#collection-name) is allowed.
+[collection name](../Manual/Appendix/Glossary.html#collection-name) is allowed.
 
 Data-modification queries are restricted to modifying data in a single 
 collection per query. That means a data-modification query cannot modify 

Documentation/Books/AQL/Examples/CombiningGraphTraversals.mdpp

@@ -1,9 +1,9 @@
 !CHAPTER Combining Graph Traversals
 !SUBSECTION Finding the start vertex via a geo query
-Our first example will locate the start vertex for a graph traversal via [a geo index](../../Users/Indexing/Geo.html).
-We use [the city graph](../../Users/Graphs/index.html#the-city-graph) and its geo indices:
+Our first example will locate the start vertex for a graph traversal via [a geo index](../../Manual/Indexing/Geo.html).
+We use [the city graph](../../Manual/Graphs/index.html#the-city-graph) and its geo indices:
 
-![Cities Example Graph](../../Users/Graphs/cities_graph.png)
+![Cities Example Graph](../../Manual/Graphs/cities_graph.png)
 
 
     @startDocuBlockInline COMBINING_GRAPH_01_create_graph

Documentation/Books/AQL/Examples/README.mdpp

@@ -14,7 +14,7 @@ Some of the following example queries are executed on a collection 'users' with
 Note that all documents created in any collections will automatically get the
 following server-generated attributes:
 
-- *_id*: A unique id, consisting of [collection name](../../Users/Appendix/Glossary.html#collection-name)
+- *_id*: A unique id, consisting of [collection name](../../Manual/Appendix/Glossary.html#collection-name)
   and a server-side sequence value
 - *_key*: The server sequence value
 - *_rev*: The document's revision id
@@ -26,7 +26,7 @@ Please also note that with real-world data, you might want to create additional
 indexes on the data (left out here for brevity). Adding indexes on attributes that are
 used in *FILTER* statements may considerably speed up queries. Furthermore, instead of
 using attributes such as *id*, *from* and *to*, you might want to use the built-in
-*_id*, *_from* and *_to* attributes. Finally, [edge collection](../../Users/Appendix/Glossary.html#edge-collection)s provide a nice way of
+*_id*, *_from* and *_to* attributes. Finally, [edge collection](../../Manual/Appendix/Glossary.html#edge-collection)s provide a nice way of
 establishing references / links between documents. These features have been left out here 
 for brevity as well.
 

Documentation/Books/AQL/Extending/Conventions.mdpp

@@ -123,6 +123,6 @@ Documents in the *_aqlfunctions* collection (or any other system collection)
 should not be accessed directly, but only via the dedicated interfaces.
 
 Keep in mind that system collections are excluded from dumps created with
-[arangodump](../../Users/Administration/Arangodump.html) by default. To include AQL user
+[arangodump](../../Manual/Administration/Arangodump.html) by default. To include AQL user
 functions in a dump, the dump needs to be started with the
 option *--include-system-collections true*.

Documentation/Books/AQL/Functions/Date.mdpp

@@ -39,7 +39,7 @@ You are free to store age determinations of specimens, incomplete or fuzzy dates
 the like in different, more appropriate ways of course. AQL's date functions will
 most certainly not be of any help for such dates, but you can still use language
 constructs like [SORT](../Operations/Sort.md) (which also supports sorting of arrays)
-and [indexes](../../Users/Indexing/index.html) like skiplists.
+and [indexes](../../Manual/Indexing/index.html) like skiplists.
 
 !SECTION Current date and time
 
@@ -623,7 +623,7 @@ There are two recommended ways to store timestamps in ArangoDB:
 The sort order of both is identical due to the sort properties of ISO date strings.
 You can't mix both types, numbers and strings, in a single attribute however.
 
-You can use [skiplist indices](../../Users/Indexing/Skiplist.html) with both date types.
+You can use [skiplist indices](../../Manual/Indexing/Skiplist.html) with both date types.
 When chosing string representations, you can work with string comparisons (less than,
 greater than etc.) to express time ranges in your queries while still utilizing
 skiplist indices:

Documentation/Books/AQL/Functions/Document.mdpp

@@ -79,7 +79,7 @@ HAS( { }, "name" ) // false
 `IS_SAME_COLLECTION(collectionName, documentHandle) → bool`
 
   collection id as the collection specified in *collection*. *document* can either be
-  a [document handle](../../Users/Appendix/Glossary.html#document-handle) string, or a document with
+  a [document handle](../../Manual/Appendix/Glossary.html#document-handle) string, or a document with
   an *_id* attribute. The function does not validate whether the collection actually
   contains the specified document, but only compares the name of the specified collection
   with the collection name part of the specified document.
@@ -283,11 +283,11 @@ MERGE_RECURSIVE(
 
 `PARSE_IDENTIFIER(documentHandle) → parts`
 
-Parse a [document handle](../../Users/Appendix/Glossary.html#document-handle) and return its
+Parse a [document handle](../../Manual/Appendix/Glossary.html#document-handle) and return its
 individual parts a separate attributes.
 
 This function can be used to easily determine the
-[collection name](../../Users/Appendix/Glossary.html#collection-name) and key of a given document.
+[collection name](../../Manual/Appendix/Glossary.html#collection-name) and key of a given document.
 
 - **documentHandle** (string|object): a document identifier string (e.g. *_users/1234*)
   or a regular document from a collection. Passing either a non-string or a non-document

Documentation/Books/AQL/Functions/Fulltext.mdpp

@@ -1,7 +1,7 @@
 !CHAPTER Fulltext functions
 
 AQL offers the following functions to filter data based on
-[fulltext indexes](../../Users/Indexing/Fulltext.html):
+[fulltext indexes](../../Manual/Indexing/Fulltext.html):
 
 !SUBSECTION FULLTEXT()
 

Documentation/Books/AQL/Functions/Geo.mdpp

@@ -3,7 +3,7 @@
 !SECTION Geo index functions
 
 AQL offers the following functions to filter data based on
-[geo indexes](../../Users/Indexing/Geo.html). These functions require the collection to have at
+[geo indexes](../../Manual/Indexing/Geo.html). These functions require the collection to have at
 least one geo index. If no geo index can be found, calling this function will fail
 with an error.
 

Documentation/Books/AQL/Fundamentals/QueryErrors.mdpp

@@ -26,6 +26,6 @@ examples that will cause run-time errors are:
   includes unary (logical not/negation), binary (logical and, logical or), and
   the ternary operators
 
-Please refer to the [Arango Errors](../../Users/Appendix/ErrorCodes.html) page
+Please refer to the [Arango Errors](../../Manual/Appendix/ErrorCodes.html) page
 for a list of error codes and meanings.
 

Documentation/Books/AQL/Fundamentals/Syntax.mdpp

@@ -156,7 +156,7 @@ The example can alternatively written as:
 Collection names can be used in queries as they are. If a collection happens to
 have the same name as a keyword, the name must be enclosed in backticks.
 
-Please refer to the [Naming Conventions in ArangoDB](../../Users/DataModeling/NamingConventions/CollectionNames.html)
+Please refer to the [Naming Conventions in ArangoDB](../../Manual/DataModeling/NamingConventions/CollectionNames.html)
 about collection naming conventions.
 
 !SUBSUBSECTION Attribute names
@@ -166,7 +166,7 @@ attribute name must be used. This is because multiple collections with ambiguous
 attribute names may be used in a query.  To avoid any ambiguity, it is not
 allowed to refer to an unqualified attribute name.
 
-Please refer to the [Naming Conventions in ArangoDB](../../Users/DataModeling/NamingConventions/AttributeNames.html)
+Please refer to the [Naming Conventions in ArangoDB](../../Manual/DataModeling/NamingConventions/AttributeNames.html)
 for more information about the attribute naming conventions.
 
     FOR u IN users

Documentation/Books/AQL/Graphs/Operations.mdpp

@@ -24,9 +24,9 @@ the amount of vertices in the graph, *x* the amount of start vertices and *y* th
 target vertices. Hence a suggestion may be to use Dijkstra when x\*y < n and the functions supports choosing your algorithm.
 
 !SUBSECTION Example Graph
-All examples in this chapter will use [this simple city graph](../../Users/Graphs/index.html#the-city-graph):
+All examples in this chapter will use [this simple city graph](../../Manual/Graphs/index.html#the-city-graph):
 
-![Cities Example Graph](../../Users/Graphs/cities_graph.png)
+![Cities Example Graph](../../Manual/Graphs/cities_graph.png)
 
 !SUBSECTION Edges and Vertices related functions
 

Documentation/Books/AQL/Graphs/README.mdpp

@@ -1,10 +1,10 @@
 !CHAPTER Graphs in AQL
 
-As you already [read about graphs in ArangoDB](../../Users/Graphs/index.html) you can have several views on graphs.
+As you already [read about graphs in ArangoDB](../../Manual/Graphs/index.html) you can have several views on graphs.
 There are also several ways to work with graphs in AQL.
 You can use named graphs where ArangoDB manages the collections involved in one graph.
 You can also use graph functions on a combination of document and edge collections.
-named graphs are defined though the [graph-module](../../Users/Graphs/GeneralGraphs/index.html), that contains the name of the graph, and the vertex and edge collections involved.
+named graphs are defined though the [graph-module](../../Manual/Graphs/GeneralGraphs/index.html), that contains the name of the graph, and the vertex and edge collections involved.
 Since the management functions are layered on top of simple sets of document and edge collections, you can also use regular AQL functions to work with them. 
 
 In AQL you can reach several graphing functions:

Documentation/Books/AQL/Graphs/Traversals.mdpp

@@ -18,7 +18,7 @@ For all vertices that where visited during this process in the range between *mi
 Let's take a look at a simple example to explain how it works.
 This is the graph that we are going to traverse:
 
-![traversal graph](../../Users/Graphs/traversal_graph.png)
+![traversal graph](../../Manual/Graphs/traversal_graph.png)
 
 Now we use the following parameters for our query:
 
@@ -27,36 +27,36 @@ Now we use the following parameters for our query:
 3. We use a *max-depth* of 2.
 4. We follow only *outbound* direction of edges
 
-![traversal graph step 1](../../Users/Graphs/traversal_graph1.png)
+![traversal graph step 1](../../Manual/Graphs/traversal_graph1.png)
 
 Now it walks to one of the direct neighbors of **A**, say **B** (NOTE: ordering is not guaranteed):
 
-![traversal graph step 2](../../Users/Graphs/traversal_graph2.png)
+![traversal graph step 2](../../Manual/Graphs/traversal_graph2.png)
 
 The query will remember the state (red circle) and will emit the first result **A** -> **B** (black box).
 This will also prevent the traverser to be trapped in cycles.
 Now again it will visit one of the direct neighbors of **B**, say **E**:
 
-![traversal graph step 3](../../Users/Graphs/traversal_graph3.png)
+![traversal graph step 3](../../Manual/Graphs/traversal_graph3.png)
 
 We have limited the query with a *max-depth* of *2* then it will not pick any neighbor of **E** as the path from **A** to **E** already requires *2* steps.
 Instead we will go back one level to **B** and continue with any other direct neighbor there:
 
-![traversal graph step 4](../../Users/Graphs/traversal_graph4.png)
+![traversal graph step 4](../../Manual/Graphs/traversal_graph4.png)
 
 Again after we produced this result we will step back to **B**.
 But there is no neighbor of **B** left that we have not yet visited.
 Hence we go another step back to **A** and continue with any other neighbor there.
 
-![traversal graph step 5](../../Users/Graphs/traversal_graph5.png)
+![traversal graph step 5](../../Manual/Graphs/traversal_graph5.png)
 
 And identical to the iterations before we will visit **H**:
 
-![traversal graph step 6](../../Users/Graphs/traversal_graph6.png)
+![traversal graph step 6](../../Manual/Graphs/traversal_graph6.png)
 
 And **J**:
 
-![traversal graph step 7](../../Users/Graphs/traversal_graph7.png)
+![traversal graph step 7](../../Manual/Graphs/traversal_graph7.png)
 
 And after these steps there is no further result left.
 So all together this query has returned the following paths:
@@ -171,7 +171,7 @@ This is because for all results in depth `1` the second edge does not exist and
 
 !SUBSUBSECTION Examples
 We will create a simple symmetric traversal demonstration graph:
-![traversal graph](../../Users/Graphs/traversal_graph.png)
+![traversal graph](../../Manual/Graphs/traversal_graph.png)
 
     @startDocuBlockInline GRAPHTRAV_01_create_graph
     @EXAMPLE_ARANGOSH_OUTPUT{GRAPHTRAV_01_create_graph}
@@ -285,6 +285,6 @@ And finally clean it up again:
     @endDocuBlock GRAPHTRAV_99_drop_graph
 
 
-If this traversal is not powerful enough for your needs, so you cannot describe your conditions as AQL filter statements you might want to look at [manually crafted traverser](../../Users/Graphs/Traversals/index.html).
+If this traversal is not powerful enough for your needs, so you cannot describe your conditions as AQL filter statements you might want to look at [manually crafted traverser](../../Manual/Graphs/Traversals/index.html).
 
 [See here for more traversal examples](../Examples/CombiningGraphTraversals.md).

Documentation/Books/AQL/HEADER.html

@@ -11,7 +11,7 @@
     </div>
     <ul id="navmenu">
       <li>
-        <a href="BASE_PATH/Users/index.html">Manual</a>
+        <a href="BASE_PATH/Manual/index.html">Manual</a>
       </li>
       <li class="active-tab">
         <a href="BASE_PATH/AQL/index.html">AQL</a>

Documentation/Books/AQL/Operations/Insert.mdpp

@@ -5,7 +5,7 @@ single server, an insert operation is executed transactionally in an all-or-noth
 fashion. For sharded collections, the entire insert operation is not transactional.
 
 Each *INSERT* operation is restricted to a single collection, and the 
-[collection name](../../Users/Appendix/Glossary.html#collection-name) must not be dynamic.
+[collection name](../../Manual/Appendix/Glossary.html#collection-name) must not be dynamic.
 Only a single *INSERT* statement per collection is allowed per AQL query, and 
 it cannot be followed by read operations that access the same collection, by
 traversal operations, or AQL functions that can read documents.
@@ -29,7 +29,7 @@ FOR i IN 1..100
   INSERT { value: i } IN numbers
 ```
 
-When inserting into an [edge collection](../../Users/Appendix/Glossary.html#edge-collection), it is mandatory to specify the attributes
+When inserting into an [edge collection](../../Manual/Appendix/Glossary.html#edge-collection), it is mandatory to specify the attributes
 *_from* and *_to* in document:
 
 ```

Documentation/Books/AQL/Operations/Remove.mdpp

@@ -7,7 +7,7 @@ all-or-nothing fashion. For sharded collections, the entire remove operation
 is not transactional.
 
 Each *REMOVE* operation is restricted to a single collection, and the 
-[collection name](../../Users/Appendix/Glossary.html#collection-name) must not be dynamic.
+[collection name](../../Manual/Appendix/Glossary.html#collection-name) must not be dynamic.
 Only a single *REMOVE* statement per collection is allowed per AQL query, and 
 it cannot be followed by read operations that access the same collection, by
 traversal operations, or AQL functions that can read documents.
@@ -21,7 +21,7 @@ REMOVE key-expression IN collection options
 *collection* must contain the name of the collection to remove the documents 
 from. *key-expression* must be an expression that contains the document identification.
 This can either be a string (which must then contain the
-[document key](../../Users/Appendix/Glossary.html#document-key)) or a
+[document key](../../Manual/Appendix/Glossary.html#document-key)) or a
 document, which must contain a *_key* attribute.
 
 The following queries are thus equivalent:

Documentation/Books/AQL/Operations/Replace.mdpp

@@ -5,7 +5,7 @@ single server, the replace operation is executed transactionally in an all-or-no
 fashion. For sharded collections, the entire replace operation is not transactional.
 
 Each *REPLACE* operation is restricted to a single collection, and the 
-[collection name](../../Users/Appendix/Glossary.html#collection-name) must not be dynamic.
+[collection name](../../Manual/Appendix/Glossary.html#collection-name) must not be dynamic.
 Only a single *REPLACE* statement per collection is allowed per AQL query, and 
 it cannot be followed by read operations that access the same collection, by
 traversal operations, or AQL functions that can read documents.

Documentation/Books/AQL/Operations/Update.mdpp

@@ -5,7 +5,7 @@ single server, updates are executed transactionally in an all-or-nothing fashion
 For sharded collections, the entire update operation is not transactional.
 
 Each *UPDATE* operation is restricted to a single collection, and the 
-[collection name](../../Users/Appendix/Glossary.html#collection-name) must not be dynamic.
+[collection name](../../Manual/Appendix/Glossary.html#collection-name) must not be dynamic.
 Only a single *UPDATE* statement per collection is allowed per AQL query, and 
 it cannot be followed by read operations that access the same collection, by
 traversal operations, or AQL functions that can read documents.

Documentation/Books/AQL/Operations/Upsert.mdpp

@@ -6,7 +6,7 @@ On a single server, upserts are executed transactionally in an all-or-nothing fa
 For sharded collections, the entire update operation is not transactional.
 
 Each *UPSERT* operation is restricted to a single collection, and the 
-[collection name](../../Users/Appendix/Glossary.html#collection-name) must not be dynamic.
+[collection name](../../Manual/Appendix/Glossary.html#collection-name) must not be dynamic.
 Only a single *UPSERT* statement per collection is allowed per AQL query, and 
 it cannot be followed by read operations that access the same collection, by
 traversal operations, or AQL functions that can read documents.

Documentation/Books/HTTP/Api/README.mdpp

@@ -5,5 +5,5 @@ Following you have ArangoDB's HTTP Interface for Documents, Databases, Edges and
 There are also some examples provided for every API action. 
 
 You may also use the interactive [Swagger documentation](http://swagger.io) in the
-[ArangoDB webinterface](../../Users/GettingStarted/WebInterface.html)
+[ArangoDB webinterface](../../Manual/GettingStarted/WebInterface.html)
 to explore the API calls below.

Documentation/Books/HTTP/BatchRequest/README.mdpp

@@ -203,7 +203,7 @@ Content-length: 53
 Please note that the database used for all part operations of a batch
 request is determined by scanning the original URL (the URL that contains
 */_api/batch*). It is not possible to override the
-[database name](../../Users/Appendix/Glossary.html#database-name) in
+[database name](../../Manual/Appendix/Glossary.html#database-name) in
 part operations of a batch. When doing so, any other database name used 
 in a batch part will be ignored.
 

Documentation/Books/HTTP/BulkImports/ImportingHeadersAndValues.mdpp

@@ -37,6 +37,6 @@ errors occurred.
 !SECTION Importing into Edge Collections
 
 Please note that when importing documents into an
-[edge collection](../../Users/Appendix/Glossary.html#edge-collection), 
+[edge collection](../../Manual/Appendix/Glossary.html#edge-collection), 
 it is mandatory that all imported documents contain the *_from* and *_to* attributes,
 and that these contain references to existing collections.

Documentation/Books/HTTP/Collection/README.mdpp

@@ -7,7 +7,7 @@ This is an introduction to ArangoDB's HTTP interface for collections.
 !SUBSUBSECTION Collection
 
 A collection consists of documents. It is uniquely identified by its 
-[collection identifier](../../Users/Appendix/Glossary.html#collection-identifier).
+[collection identifier](../../Manual/Appendix/Glossary.html#collection-identifier).
 It also has a unique name that clients should 
 use to identify and access it. Collections can be renamed. This will 
 change the collection name, but not the collection identifier.

Documentation/Books/HTTP/Database/DatabaseEndpoint.mdpp

@@ -1,6 +1,6 @@
 !CHAPTER Database-to-Endpoint Mapping
 
-If a [database name](../../Users/Appendix/Glossary.html#database-name) is present in the
+If a [database name](../../Manual/Appendix/Glossary.html#database-name) is present in the
 URI as above, ArangoDB will consult the database-to-endpoint mapping for the current
 endpoint, and validate if access to the database is allowed on the endpoint. 
 If the endpoint is not restricted to an array of databases, ArangoDB will continue with the 

Documentation/Books/HTTP/Database/NotesOnDatabases.mdpp

@@ -15,7 +15,7 @@ applications until they are explicitly installed for the particular database.
 ArangoDB can handle multiple databases in the same server instance. Databases can be used to logically group and separate data. An ArangoDB database consists of collections and dedicated database-specific worker processes.
 A database contains its own collections (which cannot be accessed from other databases), Foxx applications and replication loggers and appliers. Each ArangoDB database contains its own system collections (e.g. _users, _graphs, ...).
 
-There will always be at least one database in ArangoDB. This is the default [database name](../../Users/Appendix/Glossary.html#database-name)d _system. This database cannot be dropped and provides special operations for creating, dropping and enumerating databases. Users can create additional databases and give them unique names to access them later. Database management operations cannot be initiated from out of user-defined databases.
+There will always be at least one database in ArangoDB. This is the default [database name](../../Manual/Appendix/Glossary.html#database-name)d _system. This database cannot be dropped and provides special operations for creating, dropping and enumerating databases. Users can create additional databases and give them unique names to access them later. Database management operations cannot be initiated from out of user-defined databases.
 
 When ArangoDB is accessed via its HTTP REST API, the database name is read from the first part of the request URI path (e.g. /_db/_system/...). If the request URI does not contain a database name, the database name is automatically determined by the algorithm described in Database-to-Endpoint Mapping .
 

Documentation/Books/HTTP/Database/README.mdpp

@@ -4,7 +4,7 @@
 
 Any operation triggered via ArangoDB's HTTP REST API is executed in the context of exactly
 one database. To explicitly specify the database in a request, the request URI must contain
-the [database name](../../Users/Appendix/Glossary.html#database-name) in front of the actual path:
+the [database name](../../Manual/Appendix/Glossary.html#database-name) in front of the actual path:
 
     http://localhost:8529/_db/mydb/...
 

Documentation/Books/HTTP/Document/AddressAndEtag.mdpp

@@ -4,13 +4,13 @@
 
 Documents in ArangoDB are JSON objects. These objects can be nested (to
 any depth) and may contain lists. Each document has a unique 
-[primary key](../../Users/Appendix/Glossary.html#document-key) which 
+[primary key](../../Manual/Appendix/Glossary.html#document-key) which 
 identifies it within its collection. Furthermore, each document is 
 uniquely identified
-by its [document handle](../../Users/Appendix/Glossary.html#document-handle) 
+by its [document handle](../../Manual/Appendix/Glossary.html#document-handle) 
 across all collections in the same database. Different revisions of
 the same document (identified by its handle) can be distinguished by their 
-[document revision](../../Users/Appendix/Glossary.html#document-revision).
+[document revision](../../Manual/Appendix/Glossary.html#document-revision).
 Any transaction only ever sees a single revision of a document.
 
 Here is an example document:
@@ -35,11 +35,11 @@ Here is an example document:
 ```
 
 All documents contain special attributes: the 
-[document handle](../../Users/Appendix/Glossary.html#document-handle) is stored
+[document handle](../../Manual/Appendix/Glossary.html#document-handle) is stored
 as a string in `_id`, the
-[document's primary key](../../Users/Appendix/Glossary.html#document-key) in 
+[document's primary key](../../Manual/Appendix/Glossary.html#document-key) in 
 `_key` and the 
-[document revision](../../Users/Appendix/Glossary.html#document-revision) in
+[document revision](../../Manual/Appendix/Glossary.html#document-revision) in
 `_rev`. The value of the `_key` attribute can be specified by the user when
 creating a document. `_id` and `_key` values are immutable once the document
 has been created. The `_rev` value is maintained by ArangoDB automatically.
@@ -149,7 +149,7 @@ is:
     http://localhost:8529/_api/document/demo/362549736
 
 The above URL schema does not specify a 
-[database name](../../Users/Appendix/Glossary..html#database-name) 
+[database name](../../Manual/Appendix/Glossary..html#database-name) 
 explicitly, so the 
 default database `_system` will be used. 
 To explicitly specify the database context, use
@@ -163,7 +163,7 @@ Example:
 
 **Note**: The following examples use the short URL format for brevity.
 
-The [document revision](../../Users/Appendix/Glossary.html#document-revision) 
+The [document revision](../../Manual/Appendix/Glossary.html#document-revision) 
 is returned in the "ETag" HTTP header when requesting a document.
 
 If you obtain a document using *GET* and you want to check whether a 

Documentation/Books/HTTP/Edge/AddressAndEtag.mdpp

@@ -1,6 +1,6 @@
 !CHAPTER Address and ETag of an Edge 
 
-All documents in ArangoDB have a [document handle](../../Users/Appendix/Glossary.html#document-handle). This handle uniquely identifies 
+All documents in ArangoDB have a [document handle](../../Manual/Appendix/Glossary.html#document-handle). This handle uniquely identifies 
 a document. Any document can be retrieved using its unique URI:
 
     http://server:port/_api/document/<document-handle>
@@ -15,7 +15,7 @@ attribute of the edge, is *demo/362549736*, then the URL of that edge is:
 
     http://localhost:8529/_api/document/demo/362549736
 
-The above URL scheme does not specify a [database name](../../Users/Appendix/Glossary.html#database-name) explicitly, so the 
+The above URL scheme does not specify a [database name](../../Manual/Appendix/Glossary.html#database-name) explicitly, so the 
 default database will be used. To explicitly specify the database context, use
 the following URL schema:
 

Documentation/Books/HTTP/Edge/README.mdpp

@@ -1,6 +1,6 @@
 !CHAPTER HTTP Interface for Edges 
 
-This is an introduction to ArangoDB's [REST interface for edges](../../Users/Graphs/Edges/index.html).
+This is an introduction to ArangoDB's [REST interface for edges](../../Manual/Graphs/Edges/index.html).
 
-ArangoDB offers [graph functionality](../../Users/Graphs/index.html); Edges are one part of that.
+ArangoDB offers [graph functionality](../../Manual/Graphs/index.html); Edges are one part of that.
 

Documentation/Books/HTTP/Edge/WorkingWithEdges.mdpp

@@ -1,6 +1,6 @@
 !CHAPTER Working with Edges using REST 
 
-This is documentation to ArangoDB's [REST interface for edges](../../Users/Graphs/Edges/index.html).
+This is documentation to ArangoDB's [REST interface for edges](../../Manual/Graphs/Edges/index.html).
 
 <!-- arangod/RestHandler/RestEdgeHandler.cpp -->
 @startDocuBlock API_EDGE_READ

Documentation/Books/HTTP/General/README.mdpp

@@ -76,7 +76,7 @@ response to the client instantly and thus finish this HTTP-request.
 The server will execute the tasks from the queue asynchronously as fast
 as possible, while clients can continue to do other work.
 If the server queue is full (i.e. contains as many tasks as specified by the
-option ["--scheduler.maximal-queue-size"](../../Users/Administration/Configuration/Communication.html),
+option ["--scheduler.maximal-queue-size"](../../Manual/Administration/Configuration/Communication.html),
 then the request will be rejected instantly with an *HTTP 500* (internal
 server error) response.
 
@@ -108,7 +108,7 @@ Client authentication can be achieved by using the *Authorization* HTTP header i
 client requests. ArangoDB supports HTTP Basic authentication.
 
 Authentication is optional. To enforce authentication for incoming requested,
-the server must be started with the option [--server.disable-authentication](../../Users/Administration/Configuration/Arangod.html).
+the server must be started with the option [--server.disable-authentication](../../Manual/Administration/Configuration/Arangod.html).
 Please note that requests using the HTTP OPTIONS method will be answered by
 ArangoDB in any case, even if no authentication data is sent by the client or if
 the authentication data is wrong. This is required for handling CORS preflight
@@ -118,7 +118,7 @@ will be generic and not expose any private data.
 Please note that when authentication is turned on in ArangoDB, it will by
 default affect all incoming requests. 
 
-There is an additional option [-server.authenticate-system-only](../../Users/Administration/Configuration/Arangod.html)
+There is an additional option [-server.authenticate-system-only](../../Manual/Administration/Configuration/Arangod.html)
 "--server.authenticate-system-only" to restrict authentication to requests to the ArangoDB 
 internal APIs and the admin interface. 
 This option can be used to expose a public API built with ArangoDB to the outside

Documentation/Books/HTTP/Gharial/Edges.mdpp

@@ -1,17 +1,17 @@
 !CHAPTER Handling Edges
 
-Examples will explain the REST API for [manipulating edges](../../Users/Graphs/GeneralGraphs/Functions.html)
-of the [graph module](../../Users/Graphs/index.html) on the [knows graph](../../Users/Graphs/index.html#the-knowsgraph):
+Examples will explain the REST API for [manipulating edges](../../Manual/Graphs/GeneralGraphs/Functions.html)
+of the [graph module](../../Manual/Graphs/index.html) on the [knows graph](../../Manual/Graphs/index.html#the-knowsgraph):
 
-![Social Example Graph](../../Users/Graphs/knows_graph.png)
+![Social Example Graph](../../Manual/Graphs/knows_graph.png)
 
 @startDocuBlock JSF_general_graph_edge_create_http_examples
 
 @startDocuBlock JSF_general_graph_edge_get_http_examples
 
-Examples will explain the API on the [social graph](../../Users/Graphs/index.html#the-social-graph):
+Examples will explain the API on the [social graph](../../Manual/Graphs/index.html#the-social-graph):
 
-![Social Example Graph](../../Users/Graphs/social_graph.png)
+![Social Example Graph](../../Manual/Graphs/social_graph.png)
 
 @startDocuBlock JSF_general_graph_edge_modify_http_examples
 

Documentation/Books/HTTP/Gharial/Management.mdpp

@@ -1,9 +1,9 @@
 !CHAPTER Manage your graphs
 
-The [graph module](../../Users/Graphs/index.html) provides functions dealing with graph structures.
-Examples will explain the REST API on the [social graph](../../Users/Graphs/index.html#the-social-graph):
+The [graph module](../../Manual/Graphs/index.html) provides functions dealing with graph structures.
+Examples will explain the REST API on the [social graph](../../Manual/Graphs/index.html#the-social-graph):
 
-![Social Example Graph](../../Users/Graphs/social_graph.png)
+![Social Example Graph](../../Manual/Graphs/social_graph.png)
 
 @startDocuBlock JSF_general_graph_list_http_examples
 @startDocuBlock JSF_general_graph_create_http_examples

Documentation/Books/HTTP/Gharial/README.mdpp

@@ -1,5 +1,5 @@
 !CHAPTER General Graphs
 
-This chapter describes the REST interface for the [multi-collection graph module](../../Users/Graphs/index.html).
+This chapter describes the REST interface for the [multi-collection graph module](../../Manual/Graphs/index.html).
 It allows you to define a graph that is spread across several edge and document collections.
 There is no need to include the referenced collections within the query, this module will handle it for you.

Documentation/Books/HTTP/Gharial/Vertices.mdpp

@@ -1,9 +1,9 @@
 !CHAPTER Handling Vertices
 
-Examples will explain the REST API to the [graph module](../../Users/Graphs/index.html)
-on the [social graph](../../Users/Graphs/index.html#the-social-graph):
+Examples will explain the REST API to the [graph module](../../Manual/Graphs/index.html)
+on the [social graph](../../Manual/Graphs/index.html#the-social-graph):
 
-![Social Example Graph](../../Users/Graphs/social_graph.png)
+![Social Example Graph](../../Manual/Graphs/social_graph.png)
 
 @startDocuBlock JSF_general_graph_vertex_create_http_examples
 @startDocuBlock JSF_general_graph_vertex_get_http_examples

Documentation/Books/HTTP/HEADER.html

@@ -11,7 +11,7 @@
     </div>
     <ul id="navmenu">
       <li>
-        <a href="BASE_PATH/Users/index.html">Manual</a>
+        <a href="BASE_PATH/Manual/index.html">Manual</a>
       </li>
       <li>
         <a href="BASE_PATH/AQL/index.html">AQL</a>

Documentation/Books/HTTP/Indexes/Fulltext.mdpp

@@ -1,6 +1,6 @@
 !CHAPTER Fulltext
 
-If a [fulltext index](../../Users/Glossary/index.html#fulltext-index) exists, then
+If a [fulltext index](../../Manual/Glossary/index.html#fulltext-index) exists, then
 /_api/simple/fulltext will use this index to execute the specified fulltext query.
 
 <!-- js/actions/api-index.js -->

Documentation/Books/HTTP/Indexes/README.mdpp

@@ -7,8 +7,8 @@ general. There are special sections for various index types.
 
 !SUBSUBSECTION Index
 
-Indexes are used to allow fast access to documents. For each collection there is always the primary index which is a hash index for the [document key](../../Users/Glossary/index.html#document-key) (_key attribute). This index cannot be dropped or changed.
-[edge collections](../../Users/Glossary/index.html#edge-collection) will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the `_from` and `_to` attributes.
+Indexes are used to allow fast access to documents. For each collection there is always the primary index which is a hash index for the [document key](../../Manual/Glossary/index.html#document-key) (_key attribute). This index cannot be dropped or changed.
+[edge collections](../../Manual/Glossary/index.html#edge-collection) will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the `_from` and `_to` attributes.
 
 Most user-land indexes can be created by defining the names of the attributes which should be indexed. Some index types allow indexing just one attribute (e.g. fulltext index) whereas other index types allow indexing multiple attributes.
 

Documentation/Books/HTTP/Replications/README.mdpp

@@ -4,7 +4,7 @@
 
 This is an introduction to ArangoDB's HTTP replication interface.
 The replication architecture and components are described in more details in 
-[Replication](../../Users/Administration/Replication/index.html).
+[Replication](../../Manual/Administration/Replication/index.html).
 
 The HTTP replication interface serves four main purposes:
 - fetch initial data from a server (e.g. for a backup, or for the initial synchronization 

Documentation/Books/HTTP/Transaction/README.mdpp

@@ -16,7 +16,7 @@ during transaction execution, all operations performed in the transaction are
 rolled back.
 
 For a more detailed description of how transactions work in ArangoDB please
-refer to [Transactions](../../Users/Transactions/index.html). 
+refer to [Transactions](../../Manual/Transactions/index.html). 
 
 <!-- js/actions/api-transaction.js -->
 @startDocuBlock JSF_post_api_transaction

Documentation/Books/HTTP/Traversal/README.mdpp

@@ -7,7 +7,7 @@ initiated by clients by sending the traversal description for execution to
 the server.
 
 Traversals in ArangoDB are used to walk over a graph
-stored in one [edge collection](../../Users/Appendix/Glossary.html#edge-collection). It can easily be described
+stored in one [edge collection](../../Manual/Appendix/Glossary.html#edge-collection). It can easily be described
 which edges of the graph should be followed and which actions
 should be performed on each visited vertex.
 Furthermore the ordering of visiting the nodes can be

Documentation/Books/Makefile

@@ -1,4 +1,4 @@
-ALLBOOKS=HTTP AQL Users
+ALLBOOKS=HTTP AQL Manual
 
 all: build-books
 
@@ -288,4 +288,4 @@ build-books:
 
 	make check-docublocks
 	make book-check-dangling-anchors
-	echo '<head><meta http-equiv="refresh" content="0; url=Users/"></head><body></body>' > books/index.html
+	echo '<html><head><meta http-equiv="refresh" content="0; url=Manual/"></head><body></body></html>' > books/index.html