Information in this post is superseeded by a material page

Let us extend graphs and build system around their structure to accomodate better persistance.

Relational databases are fine for a domain-specific usecase. Graph databases (like Neo4j) are nice for a very non-structured data. However, we want structure and flexibility. This can be achieved via defining the structure inside the graph itself – storing the metadata as data. Graphs are also not good enough, since they have only nodes and relations (both with parameters), but lack ordered lists of relations as parameters. We will define a structure which will have these features.


All of the following structures are retrieved in JSON format.

  • Node – is an entry of the storage, describes something (Person, Event, Idea, anything really), has id, type, and list of parameters
  • Relation – connects two entries which indicates that the first entry did something to the other (e.g. Author -[wrote]-> Book), has id, type, and list of parameters
  • Id – unique identifier (number) of a node / relation
  • Parameter – is the main way of storing information, has key (name) and value (content)
    • Key – is a string code of the parameter
    • Value – is a content of the entry / relation parameter, has datatype
  • Type – defines the entry / relation structure, i.e., mandatory parameters, their datatypes, and for relations: what entry types they can connect
  • Datatype – what can be stored in the value of a parameter
    • primitive types – string, number (integer, float), bool
    • list of (relation, node) pairs – describe all of the incident relations of a given type, distinguishes outgoing, incoming, and undirected relations, can be unordered or ordered by a specific parameter

Since the data is valid when its type is well defined, the whole structure requires only one entry to be valid – type entry of the node which deifnes the Type type, which can look as follows.

    type: Type
    name: Type
    description: Entries with this type do not store the data as the standard entries, but define
                 various types of entries. Each entry should have its type to say what it should
                 store. Non-complience with this requirement will result in an error.


We use the REST API method format. All of the following work with entities in JSON format.

  • nodes – create, find, remove, edit
  • edges – create, find, remove, edit

Open questions

  • should relations be “global” or always dependent on the entity variable? (or both? somehow)
  • define type for files and folders?
  • relation for types
  • should have inheritance?


The structure is defined generally so it can be implemented with use of any technology.