We examine two systems that translate a selected subgraph into useful diagrams rendered in Graphviz using features of its Dot description language.
See Graph a Structure with Graphviz for background.
A general strategy is to query a large graph for a subgraph of interest then draw that subgraph in an informative way. We will focus on the second step with special attention to what the translator needs to know to be successful.
digraph { rankdir=LR node [shape=box style=filled fillcolor=bisque] Query Translate node [fillcolor=lightblue] "Large\nGraph" -> Query -> Subgraph Subgraph -> Translate -> "Small\nDiagram" Ornament -> Translate }
We accept that the translation will be supplemented with visual details such as shape, color and layout preferences independent of the specific nodes and relations in a subgraph. We can think of ornament as macro definitions that describe what to do with arguments when eventually called.
Our strategy is to recognize Ornament that is written purely in the Dot syntax and to pass that through the translator without modification. Ornament that describes treatment of subgraph nodes and arcs will be held and repeated as necessary to expand the complete subgraph.
Dot input is order sensitive with some input configuring the interpretation of later input. These are examples of pure ornament that we let pass through translation unmodified.
strict digraph layout=neto rankdir=LR node [shape=box style=filled fillcolor=bisque]
# El Dorado
El Dorado is a server-side application that queries a large graph using cypher, accepts the resulting subgraph as a table with query specified rows and columns, and then translates that through dot to svg for display.
Translation proceeds by processing each line of ornament in order. When the line contains parameters that match subgraph column headings then all of these are substituted before going on to the next line. The entry to this logic is called "dotify". github 
for each ornament line if line has parameters like {Name} for each subgraph row for each parameter substitute cell from row and named column emit line with substitutions else copy line as is
This translator has the full subgraph available as a table and process the ornament one line at a time holding a buffer for the line where substitutions take place.
# Federated Wiki
Wiki's Graphviz plugin supports a query markup that guides silent navigation through links from page to page collecting information it finds within and translating that through dot to svg for display.
Query and translation are interleaved. Nested lines of ornament are recursively evaluated with keywords guiding the traversal and accumulating a complete dot description as it goes. The entry is called "makedot". github
while traversing the ornament breadth first if step contains an instruction switch on instruction keywords when HERE fetch the page full text when WHERE subset the page text when LINK scan text for links emit nodes and arcs based on instruction else copy step as is
This query/translator represents the ornament as a tree, keeps a pointer into the tree, and updates a queue of deeper tree nodes to be evaluated once one level is complete. Instructions are performed repeatedly when the links found indicate a need. Adjacent pure ornament is copied repeatedly as the nesting of markup indicates.
# Complexity
Both translators control the construction of arbitrarily complex diagrams with a bounded amount of state and a static description of ornament. Does this defy Ashby's Law that insists the control must be as complex as that controlled?
Misapplication of Ashby's Law implies that to get any useful work done at higher levels of abstraction a designer faces relentless growth in complexity. Instead we construct useful diagrams by placing our logic within a pipeline where mere switching between what is understood and that which will be understood later can be distinguished.
The reader of a hypertext must make a similar distinction: click a link or continue reading. The authors of hypertext (the users of wiki) need not fully understand their readers in Ashby's sense in order to exert positive and useful control. And, more indirectly, the implementers of wiki need not fully understand their authors.