GraphWiki as a means of organizing user-generated content:
- Each bit of user content - raw text, at whatever granularity the user chooses - is placed in a point. Unlike WikiWiki there is no PageName for this point. Behind the scenes exists a unique identifier for the point... e.g. a surrogate key in the database, allowing the point to be updated independently of any data associated with it.
- Users hook content together by application of arrows, which go from one point to another through a third (three points total). The point in the middle serves as a label or value for the arrow, and may also have other arrows attached to it. Each arrow must be unique in these three points, but it is possible to create new points on the fly just to serve as the centerpoint of an arrow. An example: arrow FROM point containing "topic" THROUGH point containing "WikiEngines" TO point containing "MoinMoin". Any given point may serve more than one role in an arrow.
- There is a special point, perhaps called 0 or unit, that is fixed as being empty - nobody can update it, and it can be easily found in searches. This point can serve as any component of an arrow, and may serve in a role twice.
- A user 'view' of the Wiki is a query, and is automatically laid out on the screen (or elsewhere in a tabular form) in accordance with the query. URIs to the wiki are expressed as queries. Users can click on any point in a view and update it, or attach it to any other point in the same view. Given enough resources, a GraphWiki could automatically reflect runtime updates back to the user via AJAX. The query is not navigational: arrows aren't "followed", rather they are simply noted as desired to reflect semantic relationships between points.
- There are no predefined semantics in GraphWiki; rather, all such semantics derive of user-created standards and use of shared points.
- Users creating a new point should have some standard options on the form to help give it a home in the graph, such as associating it with existing 'topic' points. When working with a user-view, a user might be able to choose an option to 'add comment' or 'add example' and perform similar tasks based on what users have deemed worthy of that sort of first-class treatment.
- Some links may be automatically generated based on user content, performed by bots or scripts. AutomaticLinkGeneration, for example, could automatically link all points containing certain words. Users should be able to guide the automatic generation of links, by use of queries.
- Points are versioned in a linear manner (so everyone sees the same graph). They have a linear history, as opposed to a branched history.
- Links are not versioned, have no unique identifier other than (to:point,from:point,through:point), but might have metadata to support versioning of the whole graph.
- Note: It might be interesting to allow arrows to point at particular versions of points. This would help support some notion of immutability without actually making anything 'immutable'.
- Some meta-data is automatically maintained for each point and each link, including who created links, who touched points, when. In queries, one can access this data, so it is possible to create 'recent changes' queries or 'ignore the troll' queries on demand.
- Unless the GraphWiki needs to deal with machine-generated content, garbage collection is probably less valuable than complete versioned history.
- That said, the ability for a few users to excise 'spam' or accidentally created points can be useful.
(In retrospect, it seems the above reinvents
RdfTriples, minus the predicate semantics and plus direct support for quick content generation. In that sense, it might be worthwhile to support external URIs as points in a more direct sense, i.e. by linking remote content into the wiki.)
GraphWiki as a means to display graphical images:
Dig this Wiki:
Here's the source to render that graph:
Put another way, those of you with the itch to diagram via UnifiedModelingLanguage - and who can learn GraphViz's simple markup language - now have a wiki to author in.
Furtherless, if your graph source (in Dot language) contains an URL tag, GraphWiki (aka http://www.xpsd.com/MiniRubyWiki) spots this and creates a client-side image map. Your graphs can contain links into your own Wiki or out into the Wild Wild Web.
See http://www.xpsd.com/MiniRubyWiki
Beware the xpsd.com site does not currently have a page on MiniRubyWiki. It does seem to be hostile and opened extra browser pages which would not shut without rebooting the computer. You can get MiniRubyWiki from the MiniRubyWiki page. -- JohnFletcher (August 2007)
While I am here, what I am looking for is the missing link of how to embed a RubyTk window into a web page. I think one of the problems I have is that the word graph is rather overloaded in meaning. What I want is to be able to display graph plots. -- JohnFletcher
This Java sample can perhaps be used with some tweaks. If you click on a node, then it could become the center node and its nearest neighbors are added to the graph (if not already there). You can keep adding until you get tired or the graph bogs down. The advantage of it is that you can drag things out of your way if nodes are blocking each other.
http://java.sun.com/applets/jdk/1.4/demo/applets/GraphLayout/example1.html
--top
If you're prepared to make gifs of your graphs you can use my PhotoWiki for the same purpose. It's at http://photowiki.ywp.d2g.com
CategoryWikiImplementation
Graph Wiki