Graph Hairball

Knowledge graph system logic, the "things" and "relations between things" that graph theory calls "vertices" (a.k.a. nodes, points, entities, things) and "edges" (a.k.a.  links, lines, relations, associations), looks like a big graph hairball as some people call it an example of which you can see here:

Why?  This common view of a graph is because there has to be some "general view" of the information provided by the graph.  This is just like a general view of the information within a relational database is a table; a set of ROWS and COLUMNS for exactly one table at a time.

So what is interesting is that with a graph database the default view is everything in the graph of knowledge.  Whereas the default view of everything in a relational database is one table at a time.

Further, it does not really matter whether the information that populates your knowledge graph comes from, say, CSV files, Excel, JSON, XBRL, RDF, PROLOG or whatever physical (technical) format; the only view that is general enough to show all the information in that graph of knowledge is that graph hairball.  It is just a bunch of "things" and "relations between things".

Now, if you construct your "things" and "relations between things" in the knowledge graph carefully and you apply the notion or science of "classification" which was invented by Aristotle and Plato around 400 BCE and perfected by Carl Linnaeus in about 1735 CE; you can generated an enhanced graph hairball that might look something like this:

Classification is an extremely powerful tool.  So the classification information enables more information to be provided to the graph viewer that can be displayed as different colors, different sized objects, maybe different shapes of objects.  Leveraging classification your graph hairball  is a much nicer looking graph hairball.  But it is still a graph hairball.

Why do you get a “graph hairball”?  Well, because every strength is also a weakness.  Graphs are extremely flexible because the package everything as “vertexes” and “edges” (a.k.a. “things” and “associations between things”) and the fact that you can provide one logical view of the entire knowledge graph that is in fact logical is testament as to the flexibility and power of graph databases.  Further, you can refer to and query all information from that graph of knowledge using one query language, ISO standard graph query language (GSQL) which is being developed.

But the general graph visualization engines are still just general tools to visualize graphs and because they are general tools, they give you general views of the “things” and “relations between things” that populate your logical knowledge graph systems. 

So how do you solve the graph hairball situation?  Well, you build SPECALIZED TOOLS instead of using the generalized tools.  Now, specialized tools can still give you a graph hairball….consider this graph hairball provided by Auditchain Pacioli which is a specialized tool.  (You can view the actual graph information here.)  This graph visualization provides a semi-modified specialized view using pieces of a logical model.  There is more flow and some things are easier to read; but the graph hairball can still be a bit overwhelming.  Again, colors and shapes and sizes and filters and slicing and  dicing the graph can help you focus on specific areas of the graph hairball and make it less overwhelming; when everything is said and done...you are still viewing a graph hairball.

And so how do you get around having to use this graph hairball?  The answer is to use logical models to enhance your view of the information.  Using logical models to view information is not anything new.  When you view information from a relational database, you don't view the actual tables of information, you view a form that helps you visualize one or more tables of information.

So imagine a logical theory of a financial report.  You take the information from the logical theory and you construct a logical model that is machine readable using a global standard technical syntax such as XBRL.  And so you use that specialized information enhanced by the logical model to provide a specialized visualization of a knowledge graph that might look something like the following: (This is a working version of a specialized graph view.)

Now that visualization above is still rather rudimentary because an off the shelf visualization tool was used; but there is one useful feature that that free visualization control provides with is the ability to PIVOT the visualization, making the visualization dynamic, somewhat like an Excel pivot table but more powerful and more flexible.  There is some leverage of classification. 

But if a software engineer put in a little more work and leveraged more mature rendering tools of desktop application, then you can get this rendering that was generated using a control for Microsoft.Net (a desktop application) which looks far more appealing to business professionals: (here are more screen shots of a desktop application) 

But there is a problem.  Desktop applications are falling out of favor as IT people want to make installing software easier and so not cloud-based applications are prevailing over desktop application.  Fair enough.  But cloud-based GUIs (graphical user interfaces) and UXs (user experiences) are not nearly as mature as the desktop applications that they are replacing.  So cloud-based GUI/UX experiences will mature and ARE MATURING.  Take the online version of Microsoft Excel as a case in point.  But Microsoft has invested millions and millions of dollars perfecting Excel in the cloud.  But it has matured….people will copy what Microsoft and others are doing.

Creating software GUI/UXs from underlying logical models is nothing new. The model-view-controller software design pattern is well known and well understood.  But software engineers don't seem to understand the "dots" and how to connect all these pieces together.  But they will figure it out.

And so, the “graph hairball” will be dealt with.  Those that build the best software interfaces (GUI/UX) will prevail.  Those that have the best logical models and meta data to drive those specialized GUI/UX interfaces will prevail. 

What that software will be rendering is not things like the XBRL technical syntax.  The XBRL technical syntax is a physical technical oriented format for moving information from point “A” to point “B”.  Some other technical syntax could be used for that, maybe RDF+OLW+SHACL, perhaps GSQL, some will want Excel or JSON.  Whatever the syntax, that should not even be a concern of business professionals…they just need the most powerful technical syntax that works reliably. 

What business professionals care about is the logical models, like the Standard Business Report Model (SBRM), that drives these sorts of EFFECTIVE GUI/UX interfaces.  They are the subject matter experts that must do the work that is performed using the GUI/UX to perform the tasks and processes in the pipeline of work to get their jobs done. These logical models provide the useful view of things like those “nuggets” of information (or infons or Blocks as I call them).  Other useful things as well.

Additional Information:

• D3 Gallery (these are all general visualizations)
• FO Dot
• IDP Z3
• XULE
• Large-Graph Layout with the Fast Multipole Multilevel Method
• Syncfusion Pivot Table
• Untangling the Integration Hairball