Wiki has a structure that supports its loosely collaborating authors and readers. We now consider how we might exploit that structure while more rigorously documenting complex relationships. github
We'll use titles to represent things, the entities that we wish to relate. These may name wiki pages.
We'll use markup to represent relationships between titles. We're assuming at least one new plugin to interpret it.
We'll use sites to bound aspects of relation networks and neighborhoods to escape these bounds.
# Relations
We will imagine a new plugin with markup only casually defined here. When we describe writing about relations, we're assuming writing within this new 'relation' plugin.
A relation could be as simple as a list of titles, here warthog predators. wikipedia
Lion Leopard Crocodile Wild Dog Hyena
This list could be marked as 'predators' to distinguish it from 'prey'. The json attribute 'relation' could be used.
Bugs Grubs Eggs
Here we are defining relationships with respect to the page that contains them. The page here (H) has five predators and three prey.
(A B C D E) ⇒ H ⇒ (X Y Z)
We can imagine various markups that would make entering numerous titles convenient, allow more complex relationships, and make the relationship to the hosting page explicit.
Lion Leopard Crocodile Wild Dog Hyena => HERE => Bugs Grubs Eggs
As is our convention we use newlines to separate titles, blank lines to separate groups, special symbols to indicate functions, and all-caps keywords for distinguished names.
# Rendering
The plugin will render the titles and their relations as a graph with interactive features that aid viewing but do not have a lasting effect.
The plugin rendering of title relations confirms structure and offers links to more relations.
Things are most simply represented by their flags as discovered from the neighborhood. If a title is not yet present, a gray flag will substitute. If a title has twins, they will be shown as an intimate cluster. Hover will expose more information such as text title and synopsis.
Arrows will show where relations more explicit than clustering have been expressed. Arrows can be drawn with a translucence that shows density and avoids the need for routing. Wiggling an entity will make its relations more obvious when arrows become congested. See Spray Dots
# Networking
We expect complex networks to be represented by collections of sites containing many pages of relations. The pages represent the network, not the other way around. However, we can expect a purpose-built site to have a page/link structure with many similarities to the network it represents.
Click and shift-click of rendered flags will add pages to the lineup as with other links. Wiki will offer to create pages that don't yet exist. These might come from templates with expected relations already present ready to be edited.
Rendered relations might respond to entities duplicated on other pages in the lineup. Additional arrows could show which way to scroll to find duplicates. Similarly, when twins are uncovered, the rendered relations will update to show their existence.
# Export
The json of the network can be read by file format converters for other graph plotting tools.
Each converter can choose how much and in which ways the information on a page is to be used. For example, images could be located and used to represent the page in place of the flags.
One might launch a converter by dragging a lineup to a Transporter plugin. The returned page could include a thumbnail for the high-resolution graph as well as a link to the repository in which it will be stored. See About Transport Plugin
An external network could be served into the federation as pages from one or more other specialized servers. See Federating Foreign Servers