Graphs for knowledge representation

[coevolving]

Let's start a discussion thread on potential approaches to graphs (which some might call maps) for the federated wiki. @bobbyno and I spent 90 minutes discussing this so far. I will be travelling for some weeks, so writing may help clarity, that we can discuss together on a future video call.

A story: For a new pattern language (for service systems), federated wiki should work well for one pattern each page. However, if the number of patterns gets to be large (say, 100), selecting a subset (say, 12) and appreciating the relations between them could be difficult. A map (or graph) could aid the visualization in various groupings of patterns.

Christopher Alexander himself had a artistically-drawn graph in his 1968 book on Multi-Service Centers.

Some features: To improve the quality of systems thinking (i.e. perspectives on parts and wholes), it would be helpful to differentiate between structures (e.g. part-part arrangements in space) and processes (e.g. part-part arrangements in time). This has been a direction encouraged in the systems engineering community with INCOSE, in Object Process Methodology. The essential constructs are (i) objects (drawn as rectangles), (ii) processes (drawn as ovals) and (iii) states (drawn as rounded rectangles). Edges are directed. If we could get non-technical professionals (e.g sociologists, not engineers) to draw rectangles and ovals, even if all of the edges were not correctly represented, we would be ahead. The assessment to date is that non-technical systems thinkers can't handle the 13 constructs of SysML.

Two directions (1) We could start with Trivial Graph Format, and add some additional markup to differentiate between rectangles, ovals and rounded rectangles. TGF is not a formally accepted standard, so this could be a simpler way to represent the graph.

(2) We could aim for the DOT graph description language and choose a subset of basics to implement. The simple example of an ethane molecule doesn't look too hard. This approach may be more complicated to manage if the diagram gets large.

Technologies to learn from (a) Tiddlymap "is a TiddlyWiki plugin that allows you to link your wiki-topics (tiddlers) in order to create clickable graphs". In TiddlyWiki 5 (i.e. the node.js version), the plugin uses Vis.js. (b) The Graphviz plug-in for Dokuwiki " can create directed and non-directed graph images from a textual description language called 'dot' using the Graphviz program". (c) The Graphviz extension for Mediawiki " lets you create and display graphs as in-line images on wiki pages using tools from the open-source Graphviz and Mscgen projects". (d) yFiles for HTML "features advanced UI controls for viewing and editing diagrams and unequaled layout algorithms for automatically arranging complex diagrams at the click of a button".
(e) draw.io is a "free online diagram software for making flow charts, process diagrams, org charts, UML, ER and network diagrams", built on top of mxGraph.

@bobbyno and I talked through part of a typical dishwasher example used in systems engineering training. Objects include (i) a door and (ii) a switch. States include (i) switch open and (ii) switch closed. Processes include (i) closing the door, (ii) washing dishes, and (iii) opening the door.

The simplest implementation could be just for TGF. However, satisfying the story described above leads to a slightly larger minimal viable product.

How should we think about approaching the representation of graphs in a wiki?

[almereyda]

In a sense, federated wiki itself is already a graph: http://search.fed.wiki.org:3030/graph/bundle.html

Did you run into https://github.com/fedwiki/wiki-plugin-linkmap/issues/2 yet? It seems we share some of the links.

[WardCunningham]

Regretfully the linkmap plugin has suffered from some neglect. It dates way back to the period where we were most interested in collecting and visualizing real-time data. The link structure of a wiki seemed a convenient source, the web-socket protocol seemed a capable channel, and the d3.js force layout seemed the most likely future for interactive visualizations. We demonstrated all of these to be true but then stopped short of making this a practical tool.

The about page includes a demonstration. Here is a snapshot I just took after clicking the most central node in the graph to open the welcome page.

I will list some of the deficiencies here from memory.

• The server-side was not particularly selective in which pages it examined.
• The server connection closed rather than tracking updates to pages.
• The server-side plugin launch logic had problems in farms. We disabled it until they could be fixed.
• The websocket library has some optional native code optimizations that produce scary warnings.
• The force layout turned into a fuzzy ball for any real wiki. We discarded links to make it look better.
• The force layout did handle clicks to open nodes but seems to have some drag-release bug.
• The force layout needs the room of a full-screen mode which we don't yet have.
• The force layout drag arrangements aren't saved, whatever that means in the presence of change.

All this adds up to make linkmap more of an existence proof than a useful tool. I welcome suggestions for how some or all of this could become an everyday utility for all federated wiki readers and authors.

[opn]

Count me in. I have a number of Fedwiki pages listing software and approaches on graph visualisation. I'm not a big fan of force directed algorithms for wiki'so.

On Friday, 6 November 2015, Ward Cunningham notifications@github.com wrote:

Regretfully the linkmap plugin has suffered from some neglect. It dates way back to the period where we were most interested in collecting and visualizing real-time data. The link structure of a wiki seemed a convenient source, the web-socket protocol seemed a capable channel, and the d3.js force layout seemed the most likely future for interactive visualizations. We demonstrated all of these to be true but then stopped short of making this a practical tool.

The about page includes a demonstration. Here is a snapshot I just took after clicking the most central node in the graph to open the welcome page.

[image: image] https://cloud.githubusercontent.com/assets/12127/11000445/ac5660f8-8456-11e5-8ba8-4d9f966d14b6.png

I will list some of the deficiencies here from memory.

• The server-side was not particularly selective in which pages it examined.
• The server connection closed rather than tracking updates to pages.
• The server-side plugin launch logic had problems in farms. We disabled it until they could be fixed.
• The websocket library has some optional native code optimizations that produce scary warnings.
• The force layout turned into a fuzzy ball for any real wiki. We discarded links to make it look better.
• The force layout did handle clicks to open nodes but seems to have some drag-release bug.
• The force layout needs the room of a full-screen mode which we don't yet have.
• The force layout drag arrangements aren't saved, whatever that means in the presence of change.

All this adds up to make linkmap more of an existence proof than a useful tool. I welcome suggestions for how some or all of this could become an everyday utility for all federated wiki readers and authors.

— Reply to this email directly or view it on GitHub https://github.com/fedwiki/wiki/issues/63#issuecomment-154443269.

[bobbyno]

I think there are two distinct high-level use cases in this discussion: "Graphs of Wiki" and "Graphs in Wiki".

"Graphs of Wiki" are representations of the network topology of pages and links in the wiki. They are machine-generated and not directly human-curated, save through edits in the original pages.

"Graphs in Wiki" are networks defined in wiki markup, then transformed into visualizations, statistics, or other representations on the page. Knowledge representation is one of many use cases for a graph defined in a wiki: Such an approach could also be useful for collaborative network definitions of any kind, e.g. a social network.

If we can figure out which types of networks we want humans to be able to create for the latter, it would of course be possible to write code that would generate the markup for the former.

Disclaimer: I'm writing my ideas about both here as a way to explore the topics. I invoke Franklin: "I have already made this paper too long, for which I must crave pardon, not having now time to make it shorter."

What problems are we trying to solve with a graph representation?

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.

Graphs of Wiki

Visualizing fedwiki as a network. The Linkmap plugin "will ask the server to create a map of all its pages and the links between them".

I think this is an interesting topic, but this wasn't the primary focus of the conversation I had with @coevolving that started this thread.

Graphs in Wiki

Defining a network in wiki markup.

As a concrete example, @coevolving created a visualization of an influence network of C.A.'s A Pattern Language Which Generates Multi-Service Centers as SVG. Of course, SVG does not separate presentation and content: Let's explore representing this network in a manner that does.

First, let's describe this network as a unimodal directed graph in one dimension. What does that mean and why do we care? Knowing that the network is unimodal and that edges have uniform meaning is important for many network analytics such as community detection and centrality algorithms.

Vertices: All vertices represent a pattern in the language. Since all the vertices are the same, this is formally known as a unimodal network.

Edges: An edge between two vertices is directed and represents influence: "Small Target Areas" --influences--> "Location" Alternately, we could reverse the direction of the edges and preserve meaning: "Location" --influenced-by--> "Small Target Areas" Since only one type of edge is present, edge-labels can be inferred from the context so long as we are consistent with edge direction.

"An example would be handy right about now..."

The SVG of the 64 vertex multi-service center pattern language can be transformed into a TGF representation that yEd understands.

TGF is purely a representation of network structure, and includes no presentation concerns. yEd can handle the presentation:

Hierarchical Layout, similar to the original SVG

Organic Layout

Circular Layout, ranked by out-degree In the context of an influence network represented as A -influences-> B, a vertex is more important or "central" in network analytics terms relative to the number of outgoing edges it has, its "out-degree". If we invert the edges to mean "influenced by", in-degree centrality will be a better measure of influence.

Organic layout grouped by detected communities, sized by out-degree

TGF comes with trade-offs:

Pros:

• Human readable and writable

• Easily converted to other representations and exported as CSV, graphml, TGF, etc. for offline analysis or for use in other tools, including JavaScript visualization libraries.

Cons:

• Doesn't easily capture more complex k-partite networks containing multiple types of vertices, and so doesn't handle @coevolving's OPM use case; more formally, such networks are multipartite edge-labeled multigraphs and are the most complex that a wiki would need to support unless someone can make a case for hypergraphs. TGF does support edge labels, and so can handle multi-dimensional graphs, but I'm not aware of a way to support vertex types.

• Doesn't capture vertex or edge properties other than a label. The TGF representation above omits the url's embedded in the SVG vertices for the moment...I'll return to that below.

These are serious drawbacks: Many types of systems are intuitively represented as a multidimensional network with different types of vertices and edges in the same diagram. Even for a unipartite directed graph, vertex and edge properties can be useful. TGF wasn't intended to be a universal graph format, however...hence "trivial".

I took the time to illustrate what a TGF representation looks like not to espouse it or yEd, but to show that the appeal of TGF is its simplicity. Leaving off any XML or JSON syntax and presentation allows for relatively easy human reading and writing while maintaining just enough structure to make programmatic parsing easy.

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.

_For a brief introduction to OPM from the principal investigator, Dov Dori, see this presentation from the MIT SDM Systems Thinking Webinar Series: 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. See http://visjs.org/examples/network/other/manipulation.html for an example of a drag-and-drop interface for vertex and edge creation. 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 do you think of this approach to "Graphs in Wiki"? Is a markup like the proposed PGF worth pursuing?

Should we be solving for "Graphs of Wiki" first?

Something altogether different?

[WardCunningham]

@bobbyno has helped me clarify my ambitions when he asks whether we are graphing wiki or graphing in wiki. I consider the latter, modeling networked things using wiki, far more interesting. I've added this to my list of goals under Dream Big (wiki) and include a snapshot of one section here.

[WardCunningham]

Having now read the Model Based Systems Engineering slides, and especially the section titled "Towards ontological grounding of model-based systems engineering", I am even more excited to embed relations in wiki pages. I have implemented behavior with Method plugins and shown these can be assembled into models various ways. One approach used by the Reduce plugin is to list pages with links in a reserved region of the page. See wiki.

An even better approach would be to open computational pages in a lineup, confirm that it exhibits the desired computation by wiggling numbers and observing results, then compress the lineup into a single item, a Relation of pages, that can be dropped into more complex computations.

[opn]

Great. I'm really excited about cystoscope in this respect. It avoids the SVG problems that Ward pointed out, works on mobile and scales to hundreds or even thousands of nodes in the browser.

It's a node project, and would make a fantastic plugin. It is able to do data analysis on the graphs generated.

It would be great if anyone interested in graphs could turn up to the mini-hackathon today at 3:30pm GMT - to make a plugin?

On Saturday, 7 November 2015, Ward Cunningham notifications@github.com wrote:

Having now read the Model Based Systems Engineering slides, and especially the section titled "Towards ontological grounding of model-based systems engineering", I am even more excited to embed relations in wiki pages. I have implemented behavior with Method plugins and shown these can be assembled into models various ways. One approach used by the Reduce plugin is to list pages with links in a reserved region of the page. See wiki http://ward.asia.wiki.org/view/about-reduce-plugin/view/more-about-reduce-plugin .

[image: image] https://cloud.githubusercontent.com/assets/12127/11016861/44034754-8542-11e5-874b-8a7dff973181.png

An even better approach would be to open computational pages in a lineup, confirm that it exhibits the desired computation by wiggling numbers and observing results, then compress the lineup into a single item, a Relation of pages, that can be dropped into more complex computations.

— Reply to this email directly or view it on GitHub https://github.com/fedwiki/wiki/issues/63#issuecomment-154742057.

[opn]

@bobbyno is it OK to copy your text to Fedwiki - better still if you ad it to your site _ I can then fork it :)

Reminder: 3:30pm GMT today - cytoscape.org Fedwiki plugin session - hoping some people here will be interested in joining.

[WardCunningham]

I will be online at https://plus.google.com/hangouts/_/gurhygn42rrdr4ux3kvoscwcfia

[bobbyno]

@opn - Sure, feel free to copy this post to fedwiki. I haven't yet set up my own server, but am planning on doing so soon.

Wish I could join the Cytoscape session, but have some other engagements today. It's been several years since I looked at Cytoscape and I'd forgotten about it: Looking forward to seeing what you all find out!

[WardCunningham]

@opn, @maxkfranz and I met for an hour today online and at mozfest in London.

We wrote the CytoDemo plugin and experimented briefly.

We wrote a graph in the wiki text editor that contained one node.

[{}]

This rendered as one large dot. Makes sense. I was thrilled. But eager to move on we extended this to two dots, then three.

[{}, {}]

[{}, {}, {}]

My mind boggles thinking of all the extra stuff we can put inside of the brackets.

To show off some wiki things I suggested pulling up the second version from the journal. This worked, rendering the third and second versions side by side. I convinced Max to fork the second version back from history which he did.

What we didn't explore was how a large model could be built and rendered piecemeal over multiple servers. That is a hot button for me at the moment. But I look forward to playing with the demo a little first.

Max, please take a moment to add your name and repo info to the package.json and publish that plugin to npm.

[coevolving]

Catching up to the progress ... Cytoscape uses XGMML, which is a trivial conversion from [GML](Graph Modelling Language) ... which is different from GraphML and TGF.

Since the federated wiki is written in node.js, the "Graph theory (a.k.a. network) library for analysis and visualisation" is described at http://js.cytoscape.org/:

Cytoscape.js & Cytoscape Though Cytoscape.js shares its name with Cytoscape, Cytoscape.js is not exactly the same as Cytoscape desktop. Cytoscape.js is a JavaScript library for programmers. It is not an app for end-users, and developers need to write code around Cytoscape.js to build graphcentric apps. Cytoscape.js is a JavaScript library: It gives you a reusable graph widget that you can integrate with the rest of your app with your own JavaScript code. The keen members of the audience will point out that this means that Cytoscape plugins/apps — written in Java — will obviously not work in Cytoscape.js — written in JavaScript. However, Cytoscape.js supports its own ecosystem of extensions. We are trying to make the two projects intercompatible as possible, and we do share philosophies with Cytoscape: Graph style and data should be separate, the library should provide core functionality with extensions adding functionality on top of the library, and so on.

[coevolving]

In a different style (or paradigm) is recent progress on Oink Network Graph Visualization with a video. There's been some side discussion with @marubinotto and @KnowledgeGarden.

[KnowledgeGarden]

@coevolving Yes indeed. I've got a room at oinker.me in which I am working with @marubinotto to learn how to use the platform. At the moment, that room is private, but I'm starting to think seriously about making it public.

[maxkfranz]

@WardCunningham @opn I've uploaded the plugin demo that we created during the call to https://github.com/cytoscape/wiki-plugin-cytodemo

I've also uploaded it to npm : https://www.npmjs.com/package/wiki-plugin-cytodemo

It might be useful for playing around with right now, but we should probably think of a more permanent place to put a more formalised plugin -- maybe under the fedwiki org?

My Google username is maxkfranz; feel free to add me to the call on Wed. Talk with you then!

[WardCunningham]

Thank you @maxkfranz for posting this. The npm module can be included in any site by the mechanisms described in Maintaining a Custom Wiki. wiki

As anyone can tell from this issue alone there is considerable interest in representing and manipulating graphs in wiki. I suggested we focus first on demonstrating the capabilities of Cytoscape.js before thinking about all the ways it might fit into wiki workflows. I suggest we continue this exploration by contributing pull requests to the cytoscape repo where they might be reviewed by Max for correct and effective use of Cytoscape.js. Discussions that are more about graphs in general and possible more complete integration of Cytoscape with wiki are still welcome here.

[almereyda]

Dear @maxkfranz I've forked your repository for documentation purposes to a curated list of widespread wiki contributions at https://github.com/federated-wiki so it can stay somewhat attached to the federated wiki namespace. I believe the closeness to something "official" in npm (by following the naming convention) is sufficient for now.

[opn]

I'm failing to get the plugin installed properly: first it had a couple of dependencies that I had to add:

Local Npm module "grunt-browserify" not found. Is it installed? Warning: Task "browserify:packageClient" not found. Use --force to continue.

Aborted due to warnings. root@Atopia:/usr/local/lib/node_modules/wiki/node_modules/wiki-plugin-cytodemo# npm install grunt-browserify

and:

Warning: Cannot find module 'coffeeify' from

'/usr/local/lib/node_modules/wiki/node_modules/wiki-plugin-cytodemo' Use --force to continue.

Aborted due to warnings. root@Atopia:/usr/local/lib/node_modules/wiki/node_modules/wiki-plugin-cytodemo# npm install coffeeify coffeeify@1.1.0 node_modules/coffeeify

I'm not sure if I needed to add the -g option?

After which I can npm install and grunt build - but the plugin does not work - see http://plugin.fedwiki.org/view/about-cytodemo-plugin with teh following errors reported in the Javascript console:

plugin error SyntaxError: JSON.parse: unexpected character at line 1 column

1 of the JSON data Stack trace: [1]</emit@http://plugin.fedwiki.org/js/jquery-1.11.3.min.js line 2 > eval:16:15 [24]</g.doPlugin/<@http://plugin.fedwiki.org/client.js:4:3589 [24]</g.getPlugin/<@http://plugin.fedwiki.org/client.js:4:2273 [24]</g.getScript/<@http://plugin.fedwiki.org/client.js:4:2095 m.Callbacks/j@http://plugin.fedwiki.org/js/jquery-1.11.3.min.js:2:27304 m.Callbacks/k.fireWith@ http://plugin.fedwiki.org/js/jquery-1.11.3.min.js:2:28122 x@http://plugin.fedwiki.org/js/jquery-1.11.3.min.js:5:22109 .send/b@http://plugin.fedwiki.org/js/jquery-1.11.3.min.js:5:26030

Anyone tell me what I'm doing wrong?

On 14 November 2015 at 20:11, jon r notifications@github.com wrote:

Dear @maxkfranz https://github.com/maxkfranz I've forked your repo to a curated list of widespread wiki contributions at https://github.com/federated-wiki so it can stay somewhat attached to the federated wiki namespace. I believe the closeness to something "official" in npm (by following the naming convention) is sufficient for now.

— Reply to this email directly or view it on GitHub https://github.com/fedwiki/wiki/issues/63#issuecomment-156743346.

[WardCunningham]

@opn The plugin as published did not include the edits we made to the about page. The error comes from the plugin attempting to parse the mkplugin.sh default text as if it were json. Ironically this is not an easy thing to correct since the error message does not (yet) allow for editing the item's text. I've submitted this error handling improvement: https://github.com/fedwiki/wiki-client/pull/141

With this improvement I was able to insert the json from another example and get it to render, but not with all the visual control I would expect. example

I will push my work-in-progress to github and send Max a pull request as soon as I have enough done to merit his attention. (https://github.com/cytoscape/wiki-plugin-cytodemo/pull/3)

[opn]

OK - tried updating - http://plugin.fedwiki.org/view/welcome-visitors/view/currently-working-on/view/about-cytodemo-plugin

Now I get this error:

grunt@0.4.5 node_modules/grunt

├── which@1.0.9 ├── dateformat@1.0.2-1.2.3 ├── eventemitter2@0.4.14 ├── getobject@0.1.0 ├── rimraf@2.2.8 ├── colors@0.6.2 ├── async@0.1.22 ├── grunt-legacy-util@0.2.0 ├── hooker@0.2.3 ├── nopt@1.0.10 (abbrev@1.0.7) ├── exit@0.1.2 ├── minimatch@0.2.14 (sigmund@1.0.1, lru-cache@2.7.0) ├── glob@3.1.21 (inherits@1.0.2, graceful-fs@1.2.3) ├── lodash@0.9.2 ├── coffee-script@1.3.3 ├── underscore.string@2.2.1 ├── iconv-lite@0.2.11 ├── js-yaml@2.0.5 (argparse@0.1.16, esprima@1.0.4) ├── grunt-legacy-log@0.1.2 (grunt-legacy-log-utils@0.1.1, underscore.string@2.3.3, lodash@2.4.2) └── findup-sync@0.1.3 (glob@3.2.11, lodash@2.4.2) root@Atopia:/usr/local/lib/node_modules/wiki/node_modules/wiki-plugin-cytodemo# grunt build

Local Npm module "grunt-browserify" not found. Is it installed? Warning: Task "browserify:packageClient" not found. Use --force to continue.

On 16 November 2015 at 03:06, Ward Cunningham notifications@github.com wrote:

@opn https://github.com/opn The plugin as published did not include the edits we made to the about page. The error comes from the plugin attempting to parse the mkplugin.sh default text as if it were json. Ironically this is not an easy thing to correct since the error message does not (yet) allow for editing the item's text. I've submitted this error handling improvement: fedwiki/wiki-client#141 https://github.com/fedwiki/wiki-client/pull/141

With this improvement I was able to insert the json from another example and get it to render, but not with all the visual control I would expect. example http://js.cytoscape.org/demos/e52c2fbc0b09edd6ec46/

[image: image] https://cloud.githubusercontent.com/assets/12127/11173440/4c4eeb54-8bcb-11e5-9991-4c2fd4c3cec6.png

I will push my work in progress to github and send Max a pull request as soon as I have enough done to merit his attention.

— Reply to this email directly or view it on GitHub https://github.com/fedwiki/wiki/issues/63#issuecomment-156900731.

[KnowledgeGarden]

Related to graph representations, thanks to Patrick Durusau, just discovered this: http://blog.graphcommons.com/introducing-graph-discussions/

[WardCunningham]

Over the holidays I have been experimenting with neo4j and recording my experiences including screen shots from their ad-hoc query tool. I'm making batch import files from the federation scrape available for those who would like to follow along. wiki

The nodes and relationships I import look like this.

Here is a query and results for one particular who-links-here search.

match
  (s0:Site {title:'ward.asia.wiki.org'})-[:HAS]->
  (p0:Page {title:'federation-search'})-[:IS]->
  (t0:Title)<-[a:LINK]-(p1:Page)<-[b:HAS]-(s1:Site)
where
  (p1)-[:KNOWS]->(s0)
return
  a,b

[KnowledgeGarden]

Now, that's what I'm talkin' about!!! Maybe we are a step closer to topic mapping wikis?

Many thanks, Ward.

Happy New Year Jack

On Sat, Dec 26, 2015 at 3:22 PM, Ward Cunningham notifications@github.com wrote:

Over the holidays I have been experimenting with neo4j and recording my experiences including screen shots from their ad-hoc query tool. I'm making batch import files from the federation scrape available for those who would like to follow along. wiki http://ward.asia.wiki.org/neo4j.html

The nodes and relationships I import look like this.

[image: image] https://cloud.githubusercontent.com/assets/12127/12008214/6229f578-abe1-11e5-8149-ac517ee36efc.png

Here is a query and results for one particular who-links-here search.

match (s0:Site {title:'ward.asia.wiki.org'})-[:HAS]-> (p0:Page {title:'federation-search'})-[:IS]-> (t0:Title)<-[a:LINK]-(p1:Page)<-[b:HAS]-(s1:Site) where (p1)-[:KNOWS]->(s0) return a,b

[image: image] https://cloud.githubusercontent.com/assets/12127/12008219/a53ae566-abe1-11e5-8b00-322b79debbd8.png

— Reply to this email directly or view it on GitHub https://github.com/fedwiki/wiki/issues/63#issuecomment-167371166.

[maxkfranz]

That looks really interesting!

Make sure to let me know if you need any help with the Cytoscape side of things. Thanks

[controversial]

If anyone's interested, I built a project called Wikipedia Map which is a tool that does exactly this for Wikipedia pages.

However, the backend is completely separate from the front-end, not sprinkled within. This makes it very easy to adapt the project to work with new data sources, simply by changing out the API methods in the backend, without touching much of anything in the interface.

If you guys want to try to adapt a similar version to work with fedwiki, you're welcome to. It's 100% open source here on GitHub

[almereyda]

Best @The-Penultimate-Defenestrator, there is an older project called wikiGraph, which follows a similar approach to your software.

It would be interesting to see direct linking to expanded graphs like linking to federated wiki lineups.

Have you ever worked with federated wikis before?

[controversial]

No, I haven't. I just found this page as something describing a similar tool to my project. By direct linking, do you mean saving a graph and then being able to share that graph in its current state? On Thu, Apr 21, 2016 at 11:58 AM jon r notifications@github.com wrote:

Best @The-Penultimate-Defenestrator https://github.com/The-Penultimate-Defenestrator, there is an older project called wikiGraph http://wikigraph.erikaarnold.com/, which follows a similar approach to your software.

It would be interesting to see direct linking to expanded graphs https://github.com/erabug/wikigraph/issues/2 like linking to federated wiki lineups.

Have you ever worked with federated wikis before?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/fedwiki/wiki/issues/63#issuecomment-212986051

[almereyda]

@The-Penultimate-Defenestrator I have tried to answer your question in https://github.com/The-Penultimate-Defenestrator/wikipedia-map/issues/18. Let's move this conversation there.

[WardCunningham]

@opn and I have created a strawman Graph plugin with wiki-friendly graph markup. For example, the circular graph for RSP could be written in one line:

Rock --> Scissors --> Paper --> Rock

This renders as three nodes and three arcs.

Node names need not be pages but if they are they will link. Names are automatically abbreviated but show full on hover. If a graph mentions the page that holds the plugin then that node is highlighted in yellow signalling "you are here".

Welcome Visitors
--> Testing Graph Plugin
--> About Graph Plugin

Hello <-- World

The markup is smart about line breaks rather than requiring lots of punctuation. Subgraphs need not connect but could be connected by Graphs resident elsewhere.

Graphs on other pages can be merged into arbitrarily large networks. The lineup, the neighborhood, rosters or search engines can guide retrieval. We anticipate other plugins participating, especially the Transport plugin which is happy to engage remote services for rendering large graphs.

The dependency-free coffeescrip source is on github

I've installed this work in progress on one wiki where anyone can try it out saving their work in browser local storage. wiki

Enjoy.

[WardCunningham]

My work continues on the Graph plugin, the GRAPH option to the Transport plugin, and a graphviz endpoint on the Image Transporter. I'm now working quickly through variations of the pattern semilattice example in The Timeless Way of Building. Here are screenshots and a link.

I start with an inventory of patterns.

I build by clicking on adjacent patterns. I'm offered to make these blank pages but I choose instead to use the Pattern Template that I have prepared. Among other items, the template has a Graph plugin referring only to HERE, a keyword for the new page. I then cross-connect them by dragging each page flag onto the other graph.

The template also has a link to the Lineup Viewer that will send the graphs to be rendered together with graphviz and returned as one more wiki page.

I'm using graphviz here but any other graph rendering technology could substitute. Graphviz will handle medium to large graphs well. My transporter keeps and serves a copy of the graphs it renders independent of the wiki page it produced. For large graphs this might be the prefered way to view them.

Try this yourself by finding your unique path through the Half-Hidden Garden and plot it with the Lineup Viewer.

http://garden.asia.wiki.org/view/welcome-visitors/view/garden-patterns-inventory/view/half-hidden-garden

Find my notes on Knowledge Graphing on my branch of the goals wiki.

[paul90]

There is an error on the http://fed.wiki.org:4010/graphviz transporter.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at 
http://fed.wiki.org:4010/graphviz. (Reason: invalid token 'DELETE OPTIONS' in CORS header 
'Access-Control-Allow-Methods').

There should be a coma between DELETE and OPTIONS. But, do you really want to allow those methods?

[WardCunningham]

@paul90 Thanks for the correction. Done.

I guess my browser is more tolerant of malformed CORS headers. Out of curiosity, what are you using and where did this message appear.?

[WardCunningham]

We have extended the federated wiki repertoire of plugins with a subgraph notation suitable for describing, say, an individual pattern in its upward and downward context. Browsing patterns will leave a sequence of these in the lineup. With this pull request we extend the Cytodemo plugin to recognize this collection of subgraphs, merge them into a single graph and then plot this composite with Cytoscape.

https://github.com/cytoscape/wiki-plugin-cytodemo/pull/4

[dobbs]

Eighteen months ago we created a graphviz plugin: https://github.com/dobbs/wiki-plugin-graphviz. Already we have seen some interesting examples of both graphs of wiki and graphs in wiki.

Here is an example of graphs in wiki which demonstrate use of graphviz subgraphs, color schemes, and two different shapes. Short story here is that all of graphviz DOT is available. http://goals.pods.wiki.dbbs.co/slackmatic-and-secrets.html

Here are a couple examples of graphs of wiki... where diagrams are computed from the wiki content: http://growing.bay.wiki.org/view/welcome-visitors/view/neighborhood-patterns https://dev2.wiki.innovateoregon.org/view/welcome-visitors/view/the-challenge-of-transformation

More info about the plugin and usage can be found here: https://goals.pods.wiki.dbbs.co/about-graphviz-plugin.html