The jQwiery library is a JavaScript client library which wraps the graph API.

Input creates knowledge and knowledge creates answers. This interaction is embodied in the interplay between the oracle module (the NLP if you prefer) and the semantic network (aka graph database or graphdb). This semantic network is a labelled directed graph which in its simplest form is just a heap of JSON bits. Whether you store things in flat files or in a true graph store like Neo4J is not relevant to the ideas below. The default implementation is based on a typical couple of arrays containing the nodes on the one hand and the links between the nodes on the other. A features that does differentiate Qwiery’s network from the other implementation is, however, the idea of workspaces (notebooks) and sharing of entities. The hiearchy of the data is indeed as follows:

Users > Workspaces > Network (Entities, Links)

Workspaces are collections of entities and represent both a semantic boundary and a security context:

  • semantic boundary: on an end-user level one best thinks of workspaces as notesbooks (cfr. Evernote, OneNote and alike) wherein diverse ideas share a common subject e.g. food recipes, trip to Venice and so on. Inside the notebook you can have entities of a particular data type: thoughts, addressed, tasks etc. The entities can be linked together and thus knit a subject in the shape of a graph.
  • security boundary: every user has an initial default workspace where things are stored. You can have as many workspaces as you like however and they are by default only visible to you. So, when Qwiery attempts to find an answer via the acquired knowledge it will only look into your workspaces. You can however make a workspaces public or share it with a particular user. In that case Qwiery will extend its search to the shared or public workspaces. For example, the integrated documentation of Qwiery sits in a public workspace and can hence be accessed by all users. Accessing does not mean altering. Entities are always owned by the owner of the workspace (this is not the case in the Enterprise version of qwiery which has a role-based model).

Internally the data organization is like so:

{
"Users": [
{
"UserId": "John",
"Workspaces": [
"John:default",
"DocumentationSpace"
],
"Tags": [
"Music",
"Documentation"
],
"CurrentWorkspace": "John:default"
},
...
],
"Workspaces": [
{
"WorkspaceId": "John:default",
"Name": "Default workspace",
"IsPublic": false,
"IsDefault": true,
"UserId": "John",
"Users": [
"John"
]
},
{
"WorkspaceId": "DocumentationSpace",
"Name": "Documentation workspace",
"IsPublic": true,
"IsDefault": false,
"UserId": "John",
"Users": [
"John"
]
},
...],
"Entities": [
{
"Id": "SharedThought",
"Title": "SharedT hought",
"Description": "Something which is be accessible to all users.",
"DataType": "Thought",
"WorkspaceId": "Ludwig:default",
"Tags": [],
"Users": [
"Ludwig",
"Everyone"
],
"UserId": "Ludwig"
},
...],
"Links": [
{
"IdSource": "Login",
"IdTarget": "WhoAmI",
"Id": "h5m65iiBlH",
"UserId": "John"
},
...]
}

 

There is some redundancy in this organization helping to improve lookup and performance. The important bits in this structure is:

  • the UserId points to the owner of the entity, workspace or other element.
  • the DataType defines the remaining attributes and helps the client-rendering with deciding what to do with the data.
  • the specification Everyone means that something is public and can be used freely by Qwiery across all requests and users.
  • that an entity belongs to only one workspace and there is no hierarchy of workspaces like a tree of folders. This keeps the effort to figure out the effective security to a minumum.
  • the tags are simple strings which collect things across workspaces. If you prefer, in terms of a content management system you’d think of workspaces as categories and tags as, well, tags or labels. Workspaces organize the content of a book in chapters and tags are the index of the book.
  • that at any point in time a user has only one active workspace where Qwiery stores new (deduced, induced) data and semantic relations.

Storing all of this in MongoDB, Neo4J or similar systems would be really easy but the plain files are easier to deploy and to manage.