Argument mapping is a technique for setting out the structure of an argument in a way that makes clear the individual statements (assertions, evidence etc) and the relationships between them. It can be considered as a subset of the more general field of argumentation, which includes methods for reasoning with arguments represented in a structured (symbolic) form.I'm involved, with a number of colleagues, in seeking to develop an argument ma...
more
Argument mapping is a technique for setting out the structure of an argument in a way that makes clear the individual statements (assertions, evidence etc) and the relationships between them. It can be considered as a subset of the more general field of argumentation, which includes methods for reasoning with arguments represented in a structured (symbolic) form.
I'm involved, with a number of colleagues, in seeking to develop an argument map for the global warming debate. This centres around questions such as:
Is the world getting hotter?
If so, is this dure to human activities, such as increased CO2 emissions ("anthropogenic global warming"), or natural causes?
Because Freebase has been specifically designed to handle structured information, with a nice balance between prose and structure for representing fragments of information, it seems like a good candidate for representing and publishing arguments and debates. Each element of the argument can be represented as a single topic, and the connections between them can be represented with the appropriate links ("supports", "refutes", etc). The "map" involved is then implicit rather than an actual diagram. However, it should be easy enough to develop methods for importing/exporting arguments from/to other tools via the Freebase API.
The open, collaborative approach supported by Freebase will be invaluable in contentious areas. As well as allowing users to navigate through the argument structure, drilliing down to whatever level of detail they choose, they can add/annotate elements of the argument. The whole debate will this be 'owned' by the community as a whole, rather than by any one interest group.
The data modelling of argument structures is a very active area, and my first steps into this field are not meant to be a sophisticated solution to this problem. Rather, I have gone for a very minimalist approach, in which:
User Created Properties
Type: Supporting link (Compound Value Type)
User Created Properties
Type: Challenging link (Compound Value Type)
User Created Properties
----------------------------------------------------------------------------------------------
What follows are temporary notes, for writing up properly later.
There are a number of ways for modelling argument maps, including:
1. Don't have a separate connection Type. Simply have a reciprocal relationship between assertions, using the recirocal properties Supports/Is supported by and Challenges/Is challenged by. Nice and simple, and inttuitive, but does not allow any annotation of the connection.
2. Use the Supporting link and Challenging link Types, with full descriptive display names (e.g. "Melting of glaciers supports the view that temperature is increasing").
3. Use a single link Type, with the label for the link indicating the nature of the link (e.g. 'Supports', 'Challenges'. There will then be lots of links with the same display name, but, in any list, they will always be disambiguated by the two assertion topics.
3. Use a single link Type, with a property indicating the nature of the link. All links could then hav ethe same (short) display name (or none at all?), and this property could be marked as a disambiguator, so that it is always displayed. Not as obvious as other methods.
less
I'm involved, with a number of colleagues, in seeking to develop an argument map for the global warming debate. This centres around questions such as:
Is the world getting hotter?
If so, is this dure to human activities, such as increased CO2 emissions ("anthropogenic global warming"), or natural causes?
Because Freebase has been specifically designed to handle structured information, with a nice balance between prose and structure for representing fragments of information, it seems like a good candidate for representing and publishing arguments and debates. Each element of the argument can be represented as a single topic, and the connections between them can be represented with the appropriate links ("supports", "refutes", etc). The "map" involved is then implicit rather than an actual diagram. However, it should be easy enough to develop methods for importing/exporting arguments from/to other tools via the Freebase API.
The open, collaborative approach supported by Freebase will be invaluable in contentious areas. As well as allowing users to navigate through the argument structure, drilliing down to whatever level of detail they choose, they can add/annotate elements of the argument. The whole debate will this be 'owned' by the community as a whole, rather than by any one interest group.
The data modelling of argument structures is a very active area, and my first steps into this field are not meant to be a sophisticated solution to this problem. Rather, I have gone for a very minimalist approach, in which:
All atomic statements belong to a single Type "Assertion", regardless of whether they are for or against some position, are opinions, or are hard evidence, etc.Initially, I had a single link Type, with an instance (topic) for each of the above types of link, plus others. An individual link was then a Freebase "Compound Value Type", defined as [Assertion, LinkType, Assertion]. While this worked fine, and showed, for each assertion, the way that it linked to, and was linked from, other assertions, it was not particularly readable when viewing the topic page for individual assertions. I therefore decided to elevate each type of link to the status of having its own Type. This makes the topic page for individual assertions much more readable, since you can immediately see what other assertions support, or do not support the assertion. Similarly, it is now much easier to see which other ones it does or does not support.
Only two (currently) types of link are available:
"Supporting link" is used to show that one assertion lends support to another.
"Challenging link" is used to show that one assertion tends to remove support from another.
Data model
Type: AssertionUser Created Properties
- Supported by [Supporting link] (links in as Start of link)
- Challenged by [Challenging link] (links in as Start of link)
- Supports [Supporting link] (links in as End of link)
- Challenges [Challenging link] (links in as End of link)
- name [Text]
- Also known as [Text]
- article [Document]
- image [Image]
- Web link(s) [Webpage]
Type: Supporting link (Compound Value Type)
User Created Properties
- Analysis [Text]
- Start of link [Assertion] (links in as Supported by)
- End of link [Assertion] (links in as Supports)
- name [Text]
Type: Challenging link (Compound Value Type)
User Created Properties
- Analysis [Text]
- Start of link [Assertion] (links in as Challenged by)
- End of link [Assertion] (links in as Challenged)
- name [Text]
----------------------------------------------------------------------------------------------
What follows are temporary notes, for writing up properly later.
There are a number of ways for modelling argument maps, including:
1. Don't have a separate connection Type. Simply have a reciprocal relationship between assertions, using the recirocal properties Supports/Is supported by and Challenges/Is challenged by. Nice and simple, and inttuitive, but does not allow any annotation of the connection.
2. Use the Supporting link and Challenging link Types, with full descriptive display names (e.g. "Melting of glaciers supports the view that temperature is increasing").
3. Use a single link Type, with the label for the link indicating the nature of the link (e.g. 'Supports', 'Challenges'. There will then be lots of links with the same display name, but, in any list, they will always be disambiguated by the two assertion topics.
3. Use a single link Type, with a property indicating the nature of the link. All links could then hav ethe same (short) display name (or none at all?), and this property could be marked as a disambiguator, so that it is always displayed. Not as obvious as other methods.
