Global Sensemaking

Tools for Dialogue and Deliberation on Wicked Problems

Given that we are getting a new name, GlobalSensemaking, how about constructing a topic map such as (partial example):

The topic tree forms a basic backbone to guide parsing the global challenges domain. I'm not sure how this might work in other discourse platforms (e.g. IBIS-based) but the structure is more suggestive of ways to think about how we tackle the issues. This is how I have thought about structured discourse in my ConsensUs project.

These are just a few items at what seem to me to be appropriate levels of analysis, and just for a starting point for discussion. The last one is for those of us thinking about providing the tools to those engaged in the others!

I think it should be clear that the above tree, a topic decomposition structure, suggests cross linkage relations that turn it into a graph (Relational links). I think of this graph as directed with edges possibly going both directions to indicate mutual or circular causality (e.g. global warming and climate change with positive feedbacks like methane release). Additionally, edges can conceivably cross levels (as in population size affecting food challenges and energy production). I imagine a number of edge types similar to what are found in semantic nets. Relations covering things like causes, supports, etc.

In any case the idea is to develop an overall map of the sense making challenges and then attach issues, commentary, and analysis to each node as the work proceeds. What we need is a way to visualize the map so that contributors can add nodes and edges as needed to make links. I've also indicated something Robert suggested: A model can be attached to nodes as support for commentary and issue exploration.

This 'map' is just for example purposes. The topics/sub-topics are just my first pass at trying to establish some kind of structure and in no way represents a complete or correct topic breakdown. I suspect that we can deliberate and make sense of a better parsing to everyone's general satisfaction if there is consensus about taking a direction like this.

I've previewed this with David and Jack Park with encouraging feedback. So let's see where it goes.

Views: 1283

Reply to This

Replies to This Discussion

The map looks really helpful - thanks for contributing that.
I like this approach, for reasons beyond the mention of topic maps (my favorite hat!). Let me take a moment to compare vernaculars (personal ontologies) just so that we can all stay on the same page, not to criticize anything George has said. I guess I'm playing "salesperson" to establish what I mean by topic maps and, perhaps, point out some advantages of topic maps over concept maps (described below).

In general "graph notation" there are nodes and there are edges, where nodes represent concepts/entities/topics/subjects (lots of different names for the same idea), and edges represent relationships between nodes. That's largely the vernacular of Concept Maps, invented by Joe Novak for teaching purposes. Visit here for more on that. Concept maps are profoundly important tools; indeed, Compendium is a concept mapping tool. Cohere, on the other hand, is much closer to a topic mapping tool.

The topic maps folks, mostly started by Steve Newcomb who invented the HyTime SGML standard because he was looking for a way to represent music, take the idea of a relationship to the next level; relations (called associations) are nodes themselves, meaning the tiny arcs that connect nodes are not representations of relationships anymore. Newcomb invented topic maps when he was asked to help organize the entire GNU documentation project. Topic maps, in essence, are like the index in the back of a book, where, in our case, the book is the entire web. Topic maps take things further than a book index: they allow one to model all the relationships found "in the book" directly in the map itself.

Topic maps come in essentially three flavors: SGML, XML, and the latest TMRM flavor, but they are all part of the ISO 13250 standard. TMRM stands for "topic maps reference model" and it makes no specification for an XML serialization; rather, it grants greater syntactical freedom to represent topics. For that reason, to avoid confusion, we say we are "subject mapping" when working with the TMRM, but, at heart, it's still topic mapping.

Why represent associations? So that they can also be "first class citizens" in the map and serve as actors/targets of other relationships, or discussions. Certainly, it's possible to reify arcs in concept maps as nodes; subject maps start with the premise that everything in the map is, itself, a subject, including the property (attribute) types used to represent subjects. Consider George's "Population Changes" under which there are several (what I call) facets or aspects of that subject. I wouldn't model those as sub-classes; rather, I see them as akin to properties or possibly even special kinds of relations for that subject (as well as for other subjects).

What I like about topic maps is that they permit you to take some subject and represent all the many ways that subject is named; this helps reduce ambiguity when several subjects have the same name (my own name is terribly ambiguous in Google unless you add, say, "topic map" to the query in which case I own Google ), where you can just add some other property or relation to the query and rapidly disambiguate.

A topic map allows us to federate all the many information resources, which include the work products of the tools of hypermedia discourse, email lists, forums, and stories and articles everywhere. I use the term federate in contrast to the terms aggregate or integrate for specific reasons. First, topic maps aggressively merge representations of the same subject. Thus, topic maps don't simply aggregate (collect); they organize. Second, integration, as used in database and ontology literature, frequently implies information loss: people select what to combine. My use of the term federate insists that nothing is lost; even disagreeable world views find their way into the same map, yielding opportunities for dialogue, and learning.
George and Jack,

Thank you: this is a marvellously rich and stimulating discussion.

I have bashed out a quick, first interpretation of George's map in Debategraph—which is open to editing, rating, and comments now (after log-in) for anyone interested in experimenting with, and building on, the map beyond the confines of the forum discussion.

The direct URL to the map is:

Happy to guide anyone through the process of exploring and building on the map at any time.

David and all,

I've registered and edited the Understanding Human Nature Challenges expanded text. Not sure where to go from here, but maybe it's good to wait till others have had a chance to look and report back.

This is fun!

Hi George,

Thanks for adding expanded text for the Human Nature Challenges element on the map.

I have embedded a snapshot of the map at the bottom of the Main page of the Ning site; so that the group can keep track of changes to the map as it evolves.


Does the rating feature allow us to essentially vote for an argument object (is that what you call a node???) If so, is there a protocol such that if an entry gets an unfavorable rating it is removed from the map, or placed elsewhere?

I guess what I am looking for, more broadly, is a way to rearrange the map if many feel that a topic (my terminology for the moment) does not belong at one level - move it to an appropriate level.

I guess I should simply read more about Debategraph!


Thanks for the questions.

> We started calling "nodes" "elements" based on feedback that the term "node" was confusing and off-putting to a non-specialist audience. Whether "element" is any clearer is an open question (and, of course, its adoption confuses the dialogue with specialists). I would be interested to learn more about the feedback that others have received on the terminology they are using—and defining a common, universally intelligible terminology might be an interesting project for the group...

> The rating feature in Debategraph allows the different element types to be sorted vertically, so that higher-rated sibling elements are displayed above their lower-rated siblings. You can also apply a filter to any given map display to "filter out" (i.e. remove from view) any elements with an average rating below a value that you specify.

> During an editing session, you have the option to move existing elements to different locations on a map—and to change the element type, where necessary, to facilitate this process.

> We intend to create a manual for Debategraph soon that explains the deeper functionality; however, thus far our focus has been on trying to provide as much guidance as possible in context using the Dashboard messages and Infotip rollover messages.

Feedback on any of the above and the further areas for improvement will be much appreciated—and if you would find it helpful to schedule a time for me to guide you through the features on screen, I would be delighted to do so.






  • Add Videos
  • View All


  • Add Photos
  • View All



© 2024   Created by David Price.   Powered by

Badges  |  Report an Issue  |  Terms of Service