Argument Maps
The yEd graph editor is a general purpose graph drawing tool that can be used to create argument maps. It stores graphs as GraphML, which is an open standard XML format. Argument Interchange Format (AIF) is an open standard for argumentation that can be expressed as OWL/RDF. An argument map drawn in yEd can be transformed into the equivalent AIF with an XSL transformation.
See graphml-to-aif.xsl for a stylesheet that does just this, and here’s how it works…
The object is to translate boxes and arrows in the argument map to AIF nodes and their linkages. This is relatively straightforward in the case of the OVA-style argument maps, where diagrammatic nodes specifically depict AIF nodes. GraphML documents the nodes and edges of a graph and their properties. yEd allows data properties to be defined on nodes and edges in a graph; and these are stored in the GraphML along with various properties relating to visualization and layout.
It would be possible to achieve the desired effect with an XSL stylesheet that just uses stylistic elements (shape, colour, etc.) of the argument map to create AIF. However, this would restrict the utility of the transformation to using yEd as the argument map editor, and then only allow a single style of argument map within yEd. Instead, the following custom data properties on graph nodes are defined:
These custom properties are used alongside the URL and Description properties that yEd assigns to all nodes and edges by default. An example of such an argument map can be found here.
Broadly, the transformation is as follows: Each yEd graph node is translated to an AIF node of type nodeType, which will have URI set to the value of URL if that property is set, or will be an RDF blank node if not. The Description property becomes the claimText of the AIF node. The known and defeasible properties translate into custom boolean RDF properties (currently http://to.do/premise and http://to.do/defeasible) that extend AIF to provide hints for an evaluation of the argument. If known is true, then the AIF-node is presumably an I-node that is a premise of the argument. If defeasible is also true (or not specified) then it is an ordinary premise. If defeasible is false, then it is an axiom. For an RA-node or CA-node, the defeasible property indicates whether the corresponding rule is defeasible (the default) or not.
The defeasible and known properties provide the information needed to create ASPIC+ from the generated AIF – or to create ASPIC+ directly from GraphML. The id property is there to support the latter case, where it becomes the name of the logical proposition representing the I-node. This is not strictly necessary (one-up integer labels could be used instead for example), but does aid readability of the generated ASPIC+ statements. Similarly, it can also be used to generate blank-node ID’s in AIF for the same purpose.