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.
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.
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.
Mark Klein
May 13, 2008
Jack Park
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.
May 13, 2008
David Price
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:
http://debategraph.org/default.aspx?sig=5331-5331-4-0
Happy to guide anyone through the process of exploring and building on the map at any time.
David
May 13, 2008