All Graphs are not Context Graphs. Relationships are not Context

​Before thinking about Context Graph, understanding what is a graph database, how it is different from relational databases is needed.

Representing data in graphs with nodes and edges started in the 1960s. In the 2000s what we know as Graph databases came to life and started to be used in Enterprises.

​Let us see the difference between a relational database and graph database. 

Relational databases define relationships in a structured way. A Person has name, job title, work location entered in a database that has ID, Name, Job Title, Location columns. Rows are the actual data. If a particular row is needed, typing a query with one column name will get the data. This data can be split into different tables, keeping a common identification across tables. Splitting into tables allows faster update and retrieval. Filtering, sorting using column names is the definition of relational database. The relationship between columns and tables is called schema. Relational databases are indexed for faster query execution.

Graph database has no column names, no tables, no schema​ and no indexing. ​​Data is stored in nodes. Nodes are connected by edges which describe the relationship between the nodes. Data is accessed by graph traversal or graph walking​, simply going from one node to another node in the graph. This node hopping is called ​Index-free adjacency. As each node has information about nearby nodes going from one next is easier.

So what are the advantages of graph databases over relational databases? First there is no design. There is no need to design what information would be available and how to store it. Second, querying and updating is faster compared to relational databases. However, graph databases have their own limitations and cant be used everywhere.

Now comes the variety of the graphs. This particular or native graph is useful but may need some modifications. First modification was adding labels to nodes and relationships. Think about tagging or need to group on defined parameters. Another modification is to create triplet stores. Triplet stores as the name indicates, store information in three pieces. It is called Subject-Predicate-Object model where Subject is noun or names, Predicate denotes an action and Object is what/where action performed. It is defined in Resource Description Framework format.

So what is the difference between a graph database and a triplet store? Now we need to understand directions and multiplicity in a graph. Direction means edges ie links point to a node. Multiplicity means a Node can have multiple edges. A normal or an native graph will allow only one edge to one node.

So we have

• Normal Graph - No directions, Only one edge between nodes. Example Image from Wikipedia
  

  

  
  

• Directed Graph - Edges have directions to the nodes. If the direction is always one way, it is unidirectional, if both ways it is a bidirectional graph. Example Image from Wikipedia

  

  
  

• MultiGraph - Nodes can have more than one edge but only between same nodes

  

• HyperGraph - Nodes can have many edges connecting many nodes. Directed Hypergraph example from Wikipedia
  

  

  
  

• LabeledGraph - Nodes or Edges or both added with more information.

This leads to several varieties of graph databases in use. Picking the features from the above list we can create a customized graph database. This is also the reason that there is no universal graph query language as in the case of relational databases. Because all the relational databases are similar but graph databases can vary in functionality and storage.

Usually ​Directed Labeled HyperGraph ​is needed for Knowledge Graph and Context Graph.

Let us see how the context can be added in this.

For understanding what is context and how to extract it, refer to my other article "What is Context how to extract it?"

1. Context is directional - A person reporting to someone is always unidirectional, not bidirectional. Information exchange between teams are bidirectional. Time is also directional.

   
   

2. Context is Edges - Approval can be applied to few functions and few positions. Not to all.

   
   

3. Context is labels/weights - How much money one can approve varies depending upon position.

Assuming that Nodes are Persons, Places, Things and Edges are actions, works.

Let us see how the following can be represented

• Person A reporting to Person B

  
  

• Person A can approve a Job with limit of $10,000

  
  

• Person A with Title of Manager heading a team of 20 people

  
  

• Manager can head a team of 20 people

  
  

• Person A can approve a Computer Purchase with limit of $20,000

  
  

Here when we need to represent we need to represent Person, Position, Money, Count, Approval, Resources

• Person A reports to Person B

  
  

• Person A approves Resource Job units of Money - 10,000

  
  

• Person A approves Resource Computer units of Money - 20,000

  
  

• Person A position Manage Size 15

  
  

• Manager position Manage Size 20.

  
  

Now the context comes into play. As the position manager can have only 20 people team size, Person A can't have more than 20 people even though he can hire people for ​$10,000 ​salar​y.

Edges can be relationships or labels can be relationships, it needs to convey the context, just a Edge in native graph ​c​ant convey or show the context.​ 

So it is clear that a native graph and Edges​/Relationships are not context. ​A Directed Labeled HyperGraph​ is needed to create, store, use and constantly update the context. 

Context Graph conveys direction, limits/weights and actions or steps. Thus a native graph database and connections/relations/edges is not useful for Context Graph.  Contact NaturalText Team at info@naturaltext.com for having a Context Graph database in your Enterprise.