Hangout Highlights — 11 May, 2021
This is the first in (hopefully) a series of summaries in our several-times-a-week hangouts. Each summary will quickly point out some important topics covered in our meetings, with the goals of making them more accessible, documenting our progress, inviting outside comment, and providing some textual form of lookup for the YouTube videos we have been recording. I'll try to keep this up, but no promises!
This first highlight will also be more dense than most. Since I ran the meeting with a specific set of points to discuss, I'll be summarizing those here, rather than trying to reproduce the actual discussion.
Mapping from Layer 2 to the Base Layer
The members of the CDL had been in a stalemate for some time over questions of what model structures should be in a "base layer" (perhaps defined as the simplest model that should be supported by any Canonical Debate-compatible system). In a previous hangout, the group had come to an agreement that we could present more "advanced" model structures by providing a mapping of their data and elements to the simpler base layer structures.
In this hangout, I decided to give a stab at a first example of this: I presented something loosely called a "Mutually-Exclusive Claim Set", and attempted to illustrate how a debate mapped with this structure could be converted to a base layer argument map (and vice-versa).
Example Debate
As a simple topic, I presented the question "Where should we all have dinner?" Questions are not supported in the base layer structure, but the question was presented as context to show a simple situation in which each Claim (answer) could be considered mutually exclusive of the others.
I included some simple arguments one could make in support of or opposing the options.
Base Layer Confusion
I next attempted to show how in a simple argument map structure, there can (and maybe should!) be quite a bit of redundancy. Any argument made in support of one of the options could, and in practice probably would (inconsistently), be also used as an argument to oppose all the others.
Indexical Claims
Steven very astutely pointed out that one of the example arguments I provided, "Pizza is more affordable", does not work as a stand-alone claim. It begs the question "More affordable than what?". As you can see in the transformation between the two diagrams above, I split the claim into two separate claims, one comparing pizza to burgers and another to sushi.
It turned out this has some interesting implications (complications!) to the mapping I was proposing. More on that below.
Mutually Exclusive Arguments
Part of the fundamental nature of mutually-exclusive claims is that each claim in the set (each "answer" to our question) can be used as an argument against all the others: "We should have pizza" is opposed by "We should have sushi", and so on.
Curation at the Base Layer
In fact, as the diagram somewhat shows, the relationship of arguments for and against each claim can be simplified by grouping them according to their main purpose. Rather than making an argument that "Pizza tastes the best" in support of getting pizza, and then several others with the same name in opposition of all the other claims, it would be cleaner and simpler to make the argument in support of pizza, and let the argument that "We should have pizza" do all the work of opposing the other options.
Note that I called this "Curation" according to the term as presented in our white paper. While we haven't even dared discuss how this type of activity should occur at this point, we are all in agreement that some type of cleaning up, or "refactoring" of the argument map will be necessary over time.
The Mutually-Exclusive Claim Set (MECS)
It was more or less at this point that I presented the candidate Layer 2 advanced structure. The purpose would be to simplify both the viewing and the creation of debates which involve mutually-exclusive claims as presented above.
The structure would:
- Contain a set of claims, all of which are declared to be mutually exclusive of one another
- Represent that each claim in the set automatically opposes all other claims (only one can be "true" or "accepted")
- Accept arguments in support of or opposing a single claim; it would be understood that such arguments automatically oppose all others
- Centralize arguments in support or in opposition of the previous type of argument: Intuitively, by reducing the effectiveness of an argument supporting one of the options, you are simultaneously reducing its effectiveness as an argument against the remainder.
The Revenge of the Comparisons
It became clear that there will be some arguments that only apply to specific claims, such as the "more than" statements highlighted by Steven. In such cases, it seems that such claims could only support and oppose the claims to which they refer.
Not discussed: When an argument supports only one claim, and only opposes one other, how do we avoid the problem of duplicating arguments in support of or against the supports? For example, if one were to oppose the "Pizza is more affordable than sushi" argument by saying "Price is not an issue", we would be force to make the argument once against the support of pizza, and again against the opposition of sushi.
Factors and Matrices
At some point it was also discussed that argument maps are not the best way to handle this type of decision-making. More common is to create a matrix of features we'd like to compare, such as price, flavor, ambience, health, etc. The point was acknowledged, but also opposed somewhat by the following:
- It will be inevitable that people will try to make such arguments within the system. We should support them as best we can.
- We do wish to create a system that can do more than simple argument maps can. We need to keep exploring the boundaries of these features.
The Mapping
I presented the following ideas for how the more sophisticated structure could be mapped to a basic argument map:
- For each ordered pair of Claims A and B in the set, there will be a Support (argument) with A as the premise and the negation of B as its conclusion
That is, each Claim will act as an argument opposing all the other Claims in the set.
- For each Support of a Claim in the MECS, there will be a Support for the negation of all others. Likewise, for each Support of a negation of one of the Claims, there will be a Support for the other Claims
Not discussed: Actually, upon further reflection, this is not necessary, nor desirable. As discussed earlier, NOT adding the additional arguments will leave the map cleaner. The mutual oppositions will take care of this for us.
Reverse-Mapping
The thick grey arrows in the diagrams above are labeled "2-way Mapping" because this appears to be one of the rare cases where it might be possible to intuit the more advanced structure from the base layer map. If it can be detected that there is a depth-1 cycle of opposing arguments in the argument graph, that is at least an indication that the claims are in mutual opposition of one another.
However, it was quickly noted towards the end of the meeting that the example I provided above was unfortunately incorrect. I showed a claim supporting one option and opposing another, and mapped that structure to just a single opposition. There are at least two problems with that:
- How can we automatically determine which of the two, the opposition or the support, is the link that is to be preserved in the second layer?
- How can we determine that the claim is meant to only support one claim, rather than specifically targeting both, as with the "…more than" examples?
I think it might be safe to draw that conclusion in the following cases, however:
- If an argument is only supporting or opposing a single claim, it should continue to do so
- If an argument is supporting one, and opposing ALL others (or vice-versa), we can remove all but the single support/opposition
False Dichotomies
Of course someone had to go and ruin all the fun by pointing out that not every situation involving choice is mutually exclusive:
- Policy decisions can often involve selecting more than one option on the table
- What if someone proposes going to two of the three restaurants, or ordering in and letting each person choose their favorite?
- According to set logic, there can be overlaps in many of the claims (e.g. claims involving a range of numbers: "There are between 1000 and 1500 jelly beans in the jar", "There are around 1200 or 1300 jelly beans", "There are at least 1400 jelly beans in there")
In some cases, the problem could be "solved", at least in the specific case, by adding one more mutually-exclusive option ("Let's go get sushi and then get pizza!"). However, that could lead to the type of explosion of options (claims) that we like to avoid or simplify, where possible. In any case, the structure proposed is not meant to deal with all such situations, but could provide a starting point for more advanced elements.
Composition
A similar question presented is whether or not such MECS could be composable. For example, could you find subsets of non-mutually-exclusive claims, and put them under mutually-exclusive umbrella Claims:
- "There are between 1000 and 1500 jelly beans" vs. "There are less than 1000 jelly beans" vs. "There are more than 1500 jelly beans"
- "There are between 1000 and 1500 jelly beans" is supported by the MECS which includes "There are 1200 jelly beans", "There are 1100 jelly beans" and "There are between 1300 and 1400 jelly beans"
Likewise, a claim might be made of several mutually-exclusive elements. Consider:
- The SARS-CoV2 virus was released intentionally by Chinese scientists after they created it in a lab
- The SARS-CoV2 virus was released in China by American agents
- The SARS-CoV2 virus occurred in nature
These claims seem like they could all be members of a single MECS. However, that might not be the best way to structure such a debate, since some of these involve more than one "mutually-exclusive question":
- How was the virus created?
- Was the virus released intentionally, or by accident?
- Who released the virus?
Notice that not only could each of these questions be answered separately, possibly within a MECS structure, but the answer to one of the questions may render the others moot (unless you add the "it's moot" option):
- The virus evolved naturally
- It wasn't released. It just happened.
- I SAID it wasn't released!
Conclusion
The hangout was a very productive meeting, and a good first example of how we could present more advanced features without stepping on the toes of those that would prefer to keep the model simple. Look forward to more in the future!
