Here we look in more detail at how graphs in wiki can be specified. We look to define a markup, or domain specific language for authors wishing to create maps or network graphs.
Note: Much of this content comes from @bobbynofrom an early discussion of Knowledge Representation - github issue
See: * Graphs of Wiki * Graphs in Wiki * Authoring Graphs in Wiki
# An example would be handy right about now... The SVG of the 64 vertex multi-service centre pattern language can be transformed into a TGF representation that yEd understands.
Trivial Graph Format (TGF) is purely a representation of network structure, and includes no presentation concerns. yEd can handle the presentation:
# Extending TGF with Properties...PGF?
Adding a map of properties on the TGF structure would allow arbitrarily complex graphs to be represented. TGF doesn't currently support this, but maybe we'll create a new graph representation format right here: Property Graph Format.
Extending a few of the edges from the 64 patterns with the URL's from the SVG we omitted earlier could like something closer to DOT graph description language, but in a tool and domain-agnostic way:
1 "Small Target Areas" url=http://bit.ly/1SxrkQ0 2 "Location" url=http://bit.ly/1HycBOq ... # 1 2 1 3 2 7 ...
I think this type of notation will also accommodate @coevolving's dishwasher / OPM example. A simple representation of some dishwasher states could include:
Door has state Open or Closed. Opening changes Door from Closed to Open. Closing changes Door from Open to Closed.
This description is similar to the "Object-Process Language" that accompanies an "Object-Process Diagram" in the OPM methodology. Note again the separation of content from presentation. Rather than support OPL in wiki, which requires a richer grammar, what does this look like in PGF?
0 "Door" type=object 1 "Open" type=state 2 "Closed" type=state 3 "Opening" type=process 4 "Closing" type=process # 0 1 "has state" 0 2 "has state" 3 0 "changes" 3 1 "to state" 4 0 "changes" 4 2 "to state"
Translating to OPL and rendering could produce a diagram similar to OPD. It could also be readily translated into OPL.
For a brief introduction to OPM from the principal investigator Dov Dori, see this presentation from the MIT SDM Systems Thinking Webinar Series by Dov Dori: The Maturation of Model-Based Systems Engineering: OPM as the ISO Conceptual Modeling Language Standard
PGF could readily be transformed into something other tools understand. jsfiddle would be a great place to experiment with vis.js to prototype this idea by transforming PGF into the json format supported by vis.js.
# Visual Editing It's possible to edit a network directly in JavaScript and avoid editing the text representation directly.
This could simplify the otherwise somewhat burdensome task of keeping track of vertex id's when creating edges. For an example of a drag-and-drop interface for vertex and edge creation see visjs.org
Given there would be a need for persisting any edits, however, we still would need to decide how the serialized version of the graph would be represented.
# What problems are we trying to solve?
Here are a few options that come to mind of computationally difficult but useful tasks for which network analytics provide new information that can help drive a decision: * Automatic community detection "A map (or graph) could aid the visualization in various groupings of patterns. An example of this is below. * Topic recommendation via link prediction. * Link Analysis, i.e. find paths between two vertices, if any exist.