Introduction to Datagr4m APIs

A 3 layers data model

Data, description layers, and projections

Storage model is different from visualization model. Sometime graph-like structures are better represented by nested groups, sometime nested data structures are better represented by graphs or trees. This is the reason for wrapping input application or storage models into two levels of descriptions:

  1. a topology model describing input model and preparing for a projection
  2. a layout model able to compute a visual representation

With such description layers, one can use any application model as topology input, and any topology as input for the layout models. This let Datagr4m be flexible and reuseable for a large range of inputs.


The effort on Datagr4m has been primarily motivated by the need to generate computer networks documentations. Computer network diagrams follow some domain-model conventions and some variable amount of team/company-specific conventions. This implied to use a broad range layout algorithms with different scopes (nodes, edges, labels, etc) and latency (mono/multi step, linear/quadratic complexity, etc).
Datagr4m has thus rather been built to schedule the computation and rendering of multiple layouts. It incorporates existing open source graph layouts (e.g. Force Atlas from Gephi) and some other layouts (rows, columns, matrixes, circles) able to be mixed in a hierarchical way. One can contribute custom algorithms to the layout library one can easily apply any layout to a set of entities in the map, and define how navigation should work (opening local views, tables, etc).


Reference computer network diagrams drawn "by hand" (with Visio) tend to draw cluster of entities having relations at various OSI level (Ethernet > IP > TCP). This required to wrap input data into multi-level graphs and hierarchies. Topology's graphs described the network connections and hierarchies described the functionnal role of nested device clusters (H/A, server farms, etc).
Hierarchy is sometime not a convenient descriptor as we might wish to describe structures as overlapping zones, whatever their entities connectedness or hierarchy, which is another way to build data projections that will be added the to topology model in the future.




This project is the resurection of prototypes & POCs written some time ago. There might be unoptimal and/or untested code that will be cleaned in the future.