[derefr]

> duplication of points in many places in a tree

It seems (but I might be wrong) that this syntax allows for nodes to also reference other nodes rather than embedding them (see e.g. the third example on the page, though it’s too trivial to tell if that’s what it’s doing for sure.) I think they expect you to draft the argument map, then go back over it and iteratively reduce it by manually normalizing duplicate sub-arguments into one canonical sub-argument in one place + references to it in other places.

> Also, my gut feeling is that when you're talking about "arguments" instead of "facts", "evidence" and probabilities, you're in business of convincing, not truth seeking.

Usually the point of this kind of software (argument-mapping software) is to, first, efficiently capture an argument that exists, either as a sort of “court stenographer” during the argument, or from a recording after the fact. You want the tree of pros and cons (really, rebuttals / consequents / syllogisms / a bunch of other smaller categories) because you’re trying to capture the structure of the discussion itself.

Then, once you have captured that structure, argument-mapping software has tooling to allow you to massage (refactor!) the discussion from its original shape, into one that lets you more efficiently get at the truth. Turn things graphical, assign arguments weights, unify duplicate branches, etc.

Argument mapping is not just about pro/con trees; but pro/con trees are a nearly-lossless way to capture how people actually debate things, so they’re a good “ingested primary source” format to keep around and refer back to when you’re trying to summarize and judge a debate (rather than having to listen to the audio transcript over and over, or read through a linear stream of debate text.)

[ChrisKor]

> Argument mapping is not just about pro/con trees; but pro/con trees are a nearly-lossless way to capture how people actually debate things, so they’re a good “ingested primary source” format to keep around and refer back to when you’re trying to summarize and judge a debate (rather than having to listen to the audio transcript over and over, or read through a linear stream of debate text.)

We have used Kialo for exactly this. The parties that we suspect to start quarrelling about a decision have to capture their reasoning in a Kialo and send it to everybody before the actual meeting. And then we use the Kialo tree as a source document during the meeting. And if new arguments are brought up, the person taking notes just adds them.

Or if a heated debate ensues, one person starts mapping the arguments in Kialo, for later reference.

One problem we ran into though, is that older management folks seem to prefer traditional meeting notes, instead of hipster pro/con trees. Also, argument trees don't allow for nice print outs.

[TeMPOraL]

Huh, I haven't thought of using them as an input format, a form that matches the typical structure of a discussion. Thanks!

> I think they expect you to draft the argument map, then go back over it and iteratively reduce it by manually normalizing duplicate sub-arguments into one canonical sub-argument in one place + references to it in other places.

That can work with this application/language. It doesn't work with Kialo, unfortunately, where you had different people contributing different nodes of the tree and AFAIR maybe, sometimes, someone then going over the tree and cleaning it up.

> Then, once you have captured that structure, (...) massage (refactor!) the discussion (...) into one that lets you more efficiently get at the truth.

One thing I tried to say is that I believe an argument tree isn't a right end format here, both because it's about arguments (vs. facts and their relationships), and because it's a tree. I think the end format must be a directed graph, very likely containing cycles (mutually supporting arguments).

Why I don't like arguments in the final format? Because they're kind of like an applied function. They hide the parameters. You can decompose an individual argument into pieces of facts and their relationships; an argument takes those, and assigns hidden weights to them - you care about some facts and relationships more than others, and this is usually implicit in the argument (and a source of confusion when doing this multiplayer, a-la Kialo).

I think it'll be more productive to decompose the arguments and deduplicate the resulting graph, and then work at the facts-and-relationships level. The benefits are that all components are now much easier to objectively verify, and whatever conclusion you then read out of this graph could be validated easier.

Note I just think that it'll work better, I haven't really tried it. I have on my TODO list somewhere to take a particular nontrivial topic, like e.g. "animal suffering"[0], and try to decompose it this way to see whether this format will actually work in practice.

--

[0] - It's a topic on which I have no formed opinion at this point, only bunch of inconsistent feelings and heuristics, so I shouldn't have too many preconceptions and biases here. It also seems hard enough to teach me something about myself.

[SiempreViernes]

>directed graph [...] containing cycles

Can you clarify what you mean with cycles? As written it sounds like you think sound arguments contain circular reasoning...

I can see a branching opening and closing in a unidirected graph being the result of a sound argument^, but since you cannot move freely in both directions I don't know if it would count as a cycle.

^ The argument being: some process has a positive an negative effect (one thing happens, another thing never happens), the positive and negative effects are observed in nature, supporting the conclusion that the process in fact is the cause of the two effects.

[TeMPOraL]

Feedback loops.

I don't think modelling "from argument X follows argument Y" is productive; what's productive is modelling that observable phenomenon X is correlated with Y, or causes Y, or has this-and-that impact on Y. At this level, things can be stuck in feedback loops, either positive or negative.

Will increase in coal exports of Poland increase Poland's CO₂ footprint? Let's try to model it the way I think about it:

     Coal exports
          ^
          | [provides Z coal to]
          |
          |     [needs α*X = A kWh for coal]
     Mining coal <---------------------\
          |                            |
          | [provides X coal to]       |
          v                            |
   Coal power plants                   |
    |     |                            |
    |     | [γ*X = Y kWh burning coal] |
    |     v                            |
    |  Electricity --------------------/
    |
    | [burned coal into β*X = N kg of CO₂]
    v
  CO₂ emissions

You have a cycle there: Mining coal -> Coal power plants -> Electricity -> Mining coal. Given A < Y, it's a negative feedback loop. It's a cycle that exists in real life (and the basis of the concept of EROI)!

If this were a reactive model, you could tweak the value of Z to see how X, Y, A and ultimately N change. But even without reactivity, you can clearly see that the answer to original question is "yes, increasing coal exports will increase Poland's carbon footprint". And there's little left open to interpretation or accusations of subjectivity.

If you don't like the answer that the model gives, it also makes some alternative strategies apparent! In this case: can we find a way to reduce α or β to compensate? Or increase γ? Or maybe add an alternative CO₂ sink for the Coal power plants -> CO₂ emissions edge? Note that these alternative strategies involve manipulating reality, not your argument.

I think we should be doing more of this kind of modelling. Building more accurate maps of the world, and reasoning straight from them, instead of trying to build complicated webs of arguments.