JILT 1998 (3) - Bench-Capon et al
|
|
DownloadA Computer Supported Environment for the Teaching of Legal Argument
T.J.M. Bench-Capon [tbc@csc.liv.ac.uk]
P.H. Leng [P.H.Leng@csc.liv.ac.uk]
Department of Computer Science
University of Liverpool
and G.Stanford
Department of Computer Science
Chester College
The effective use of argument is, of course, central to the practice of Law, and it is important that students of Law learn this skill. We describe here the architecture of a computer-based system to enable students to practice argumentation in a regulated environment. The system makes use of the concept of a dialogue game as a means of providing the necessary rule-governed structure for the conduct of an argument between two students, or a student and a teacher. The architecture described is generic in that it can be instantiated with different forms of dialogue game. This instantiation is achieved by the use of performatives to specify the rules of the game and the semantics of operations within the Dialogue Abstract Machine that is used to implement it. We illustrate this with an example using a dialogue game based on an adaptation of the argument schema of Stephen Toulmin.
Keywords: Argumentation, Dialogue Games, Computer-Assisted Learning
This is a Refereed Article published on 30 October 1998.
Citation: Bench-Capon T.J.M. et al, 'A Computer Supported Environment for the Teaching of Legal Argument', 1998 (3) The Journal of Information, Law and Technology (JILT) . <http://elj.warwick.ac.uk/jilt/98-3/capon.html>. New citation as at 1/1/04: <http://www2.warwick.ac.uk/fac/soc/law/elj/jilt/1998_3/bench/>
1. Introduction
One of the things that any student, but perhaps law students more than most, must learn is how to construct and organise an argument in the support of some position. When, in 1993, the Law Society replaced its Law Society Finals Course with the Legal Practice Course, advocacy was one of the five core skills identified as part of an overall change to a more practical approach towards the professional education of lawyers. This was further underlined in the 1996 report of the Lord Chancellor's Advisory Committee on Legal Education and Training (ACLEC, 1996), which recommended that all undergraduate law students should be able to demonstrate competence in analysing and using legal texts, information and argument. Notwithstanding these developments, however, it appears that there is relatively little formal teaching of legal argument in English Law schools. Skill in argument, if at all, is usually developed informally in a tutorial context: Mullender (1997) gives a useful discussion of this. The cost in staff time of small-group teaching has encouraged the use of computers and courseware for this purpose, and Widdison and Pritchard (1995) report a successful experiment in the use of electronic conferencing for Law tutorials.
Since what knowledge based systems are designed to do is to construct arguments, it is tempting to believe that we can go further, and use such systems to help support the acquisition of this skill in a more active way. One early attempt at such a system was STATUTOR (Routen 1991). In this approach the system contains an executable formalisation of a fragment of legislation (relating to the British Nationality Act), and the task of the student is, given a set of case facts, to construct the appropriate and-or tree. A key problem here was that the form of representation and the structure of the argument demanded was far too restrictive. Perhaps the most successful system to teach legal argument skills so far is CATO (Aleven 1997). CATO is firmly grounded in a particular model of legal argumentation, developed as the HYPO system (Ashley 1990). This model provides both an overall framework, the 'three-ply' argument form of citation, response and rebuttal, and a set of argument moves that can be made within the framework. CATO has been extensively trialed with law students (Aleven and Ashley 1994), and the results suggest that it is effective in improving student's argumentation skills. The success of CATO derives from its clear and realistic notion of what a particular form of legal argument is like, coupled with the analysis of a set of leading cases carried over from HYPO and made available to the students.
Despite its success, CATO is tied to a particular, rigid, argument form and its moves are implicit as part of the machinery of the program. In practice, however, it is not possible to view legal argument as a precisely formulated verbalisation of a process of logic. As in other contexts, the purpose of legal argument is persuasion rather than proof, and for this reason the advocate may require to employ a wide range of styles of argument, drawing upon information of various kinds from a variety of sources. We believe that this kind of flexibility is an important characteristic of computer systems to support legal argumentation, and especially of systems to help develop skills of argument. We want to advance in this paper a more generic characterisation of this style of system which will enable a number of different informal argument styles to be offered, and which will make the various argument moves explicit, with rules and heuristics for their use. To achieve this we will employ the notions of dialogue games, which we shall describe in section 2, and performatives, which we draw from distributed AI, in particular work on KQML, as described in Finin et al (1994) and Labrou (1996). In section 3 we will give an overview of our environment. In section 4 we will describe a Prolog prototype of the environment. In section 5 we will give a brief and very simple example of its use, and we will make some concluding remarks in section 6.
2. Dialogue games in legal argumentation
Interest in dialogue games in AI and Law emerged from a search for some more productive means of interacting with Knowledge-Based Systems than is provided by the traditional consultative model, and from a desire to give a precise characterisation to legal argument. The latter use is most fully developed in the pleadings game described in Gordon (1995), which provides a detailed analysis of a particular kind of legal argument, in terms of a dialogue game. Here we will concentrate on work concerned primarily with interaction.
In contrast to the stilted interaction offered by consultative systems, dialogue provides a basis for argumentation rather than advice, enabling alternatives to be explored and fresh ideas to be contributed by the human participant. The essence of this approach is the construction of a convincing argument, rather than the search for a definite answer to a question. This is, of course, particularly appropriate in the legal domain in which answers must almost invariably be mediated through a process of argument.
The role of dialogue games in this enterprise is to provide a precise and rule-governed framework for the conduct of the argument. An exemplar is provided by MacKenzie's dialogue game, DC (MacKenzie, 1979). MacKenzie's game was developed, initially, to define a set of rules for a two-person argument between human participants which would ensure a final resolution of the argument, and was intended as a tool to analyse notions in formal logic. In DC, one of the participants begins by asserting a claim, establishing a commitment to the proposition thus advanced. The game proceeds through a series of alternating moves in which this proposition may be questioned, challenged and supported. The rules of the game are framed specifically to prevent circularity in this argument, which may be brought to an end by a resolution demand. Through this, the proponent is invited to withdraw the proposition or the opponent to accept it, in the light of an apparent contradiction that has arisen.
In the context we are considering, Mackenzie's game is important in that it delineates some of the fundamental characteristics of argument: in particular, the notion of commitment, and the framework of rules governing the debate. In work exploring the use of DC for interaction with Knowledge-based systems (Bench-Capon et al, 1991), however, its limitations rapidly became apparent. The purpose of MacKenzie's game, essentially, is to ensure that both participants are brought to accept the truth of a proposition which is capable of proof through a process of formal deduction. As we have discussed in our introduction, however, the practice of law and the processes of legal argument are largely concerned with propositions which are unlikely to be provable in this way. In the legal domain, we are usually seeking not a formal proof but a (more or less) convincing argument for a proposition.
This thinking has led us, in common with other researchers, to examine the nature of argument, and in particular the argument schema proposed by Toulmin (1958). Toulmin's schema decomposes an argument into a number of constituent elements: claims; data to support a claim; warrants, to provide rules of inference for the use of supporting data; backing, to provide authority for a warrant; and rebuttals, which may negate a warrant in defined circumstances. The relation between these elements is shown in Figure 1.
 |
Figure 1: Toulmin's Argument Schema
Toulmin's schema provides a particularly promising starting point for us, since it is widely used on courses that teach argument skills. We have used a modified form of Toulmin's schema as a basis for the definition of a Dialogue Abstract Machine, TDAM (Bench-Capon et al, 1992), intended to implement a dialogue game based on this schema, the Toulmin Dialogue Game (TDG). The moves available in TDG, and a state transition diagram showing how they can be used are given in Appendix 1.
A dialogue abstract machine is conceived as a device for mediating in a dialogue between human and/or KBS participants, through a form of dialogue 'game'. TDG uses some of the concepts of MacKenzie's game, including in particular the idea of a commitment store which records the commitments of the participants, but within a framework of rules which is richer than Mackenzie's, enabling a less stilted development of the argument. The modified and extended form of Toulmin's schema is used to provide context for this and to facilitate construction of textual argument from the results of the dialogue (Bench-Capon et al, 1993).
MacKenzie's game, and TDG representing a less formal style of argument, are just two examples of the use of argument and dialogue games in AI and Law such as Prakken and Sartor (1997). While much of this work shares common assumptions, differences in the models of argument used create difficulties in establishing a generic model for the kind of dialogue abstract machine exemplified by TDAM. In seeking a common basis for definition, we have made use of the notion of performatives, as used to define the interaction between co-operating systems in Distributed AI, most notably KQML (Finin et al 1994). This notion derives from the theory of speech acts popularised by Searle (1969). A speech act describes the utterance of a locution which has a consequent 'perlocutionary effect'. Originating from philosophy of language, speech act theory has in recent years attracted the interest of computer scientists in a number of fields as a device for formalising the semantics of speech-like interactions with computers: apart from KQML, another example concerns operations to update a database (Colomb, 1997). In this case, a genre of speech acts incorporates both a set of language rules (the database schema) and a further set of conditions defining who may use the database and in what circumstances (framing rules).
The requirements for defining a dialogue game are similar: in this case, we wish to define the performatives that are recognised in the game (the 'moves'), the rules under which they may be used, and their perlocutionary effects. Following Labrou (1996), who gives a semantics for the speech acts used in KQML, we specify each possible locution by defining four components of the corresponding speech act:
- Its description: defining both its formal syntax and informal semantics.
- The preconditions enabling the act to be performed.
- The postconditions, defining the immediate perlocutionary effects.
- Completion conditions, describing the intended final consequences.
As an example, consider the 'Why' performative of TDG. The speech act for this can be described in the above terms, thus:
why (C)
- O seeks data supporting C
- O has control of the dialogue
C is top of claim stack
- P has control of the dialogue
- C is not top of claim stack
We can use speech acts in this way to provide a complete formulation of all the possible moves in a dialogue game. The advantage of this form of specification is that it can readily be translated into a corresponding set of computational actions within a dialogue abstract machine, for which the genre of speech acts may be seen as the equivalent of an instruction-set specification, and perlocutionary effects (including completion conditions) represented by changes of machine state. We have used this to define a model for the implementation of TDG (Bench-Capon et al, 1998), but the significance of the approach is that it enables us to abstract from this a generic model for the architecture of a dialogue abstract machine which can be instantiated with speech act specifications for particular games. It is this model which provides the basis for our proposed teaching system.
3. A computer system for the teaching of legal argument
The process of constructing an effective argument, in law or in other contexts, involves, firstly, access to information relevant to the proposition being asserted; secondly, selection of the right information to support the proposition; and finally, the ability to organise the data thus assembled into a coherent form. In an adversarial system, it will be necessary to do this in the knowledge that each assertion and inference may be challenged, possibly spuriously, and that contradictory information may be elicited in support of a challenge.
|
 |
The system we propose, illustrated in Figure 2, is a computer-based environment for the conduct of an argument between two human participants, who might be two students of law, or a student and a tutor. The argument takes the form of a dialogue 'game' of the kind we have been discussing, in which one participant advances a proposition and will be expected to substantiate it, while the other may question, challenge and attempt to refute it. Each move in this game is effected as an execution step in the Dialogue Abstract Machine.
The Dialogue Abstract Machine, in the general case, is a generic architecture for performing steps according to the rules of some particular dialogue game. Each step will involve an execution cycle comprising:
- The selection of an appropriate 'move' in the game. This selection takes place outside the DAM itself, and, in essence, is the action of a player in choosing a locution to advance the argument. This choice is made within a context determined by the current state of the abstract machine; in general, not all locutions of the genre will be legal in every context of the argument.
- The identification of the speech act corresponding to the chosen locution. The stored specifications of speech acts may be seen as the analogue of what in computer-architecture terms would be the machine microcode; each speech act presents an executable semantics for the corresponding locution.
- Checking of the preconditions of the speech act to verify its validity in the current context.
- Evaluation of the speech act to produce the specified perlocutionary effects. The evaluation brings about a change of state in the abstract machine, expressed in two parts. Firstly, the immediate postconditions of the act may specify changes in the commitments of either or both participants. These commitments are encoded explicitly in the commitment store, which functions as the non-finite state memory of the abstract machine. Finally, each speech act will bring about a change in the context of the argument, represented as a (finite) change of state within the abstract machine. These contexts express both the immediate postconditions, augmented by the commitment store, and a progression towards the completion conditions.
 |
Figure 2: Architecture of the Teaching System
The essential elements of the abstract machine, therefore, are the control cycle described above; a memory, in the form of a commitment store; a set of execution-step specifications, encoded representations of speech acts; and a context record, recording the current argument state. We see these as generic characteristics of a very wide class of dialogue games; any specific game, such as MacKenzie's or TDG, is instantiated by a particular set of performatives defining the dialogue rules and corresponding state changes and commitments arising. Although the nature of commitments may be very different depending on the type of game being played, the essential form of the commitment store is also generic; it comprises a status part, recording the existence of each commitment and enabling these to be identified and combined in predicates, and a textual part, supplying appropriate corresponding text. Both the status of commitments and the context status of the machine may be used to define preconditions for the validity of a speech act.
The Dialogue Abstract Machine itself is a passive device: its role is to ensure the dialogue can only proceed within the rules of the game. The active part of the system is the Dialogue Manager, which may be seen as a program delivering execution steps to the DAM. Different kinds of dialogue manager may be appropriate for various teaching purposes. In the simplest case, the dialogue manager acts as a passive mediator between the human participants and the DAM. In this case, the role of the dialogue manager comprises:
- Presentation of an interface to the human participants. This interface will present to each participant in turn, the current argument context, in the form of a set of locution forms which are currently applicable. The participant's response will be translated into whatever form is appropriate to enable the DAM to execute the corresponding speech act. A typical implementation of the interface will be menu-based; this kind of interaction has been used, for example, by Aiken and McManus as a means of regulating interactions in a collaborative learning environment (Aiken and McManus, 1997), and in our prototype described below.
- Interfaces to whatever knowledge sources are available via the system. In many cases, locutions by participants will involve the introduction of specific information to the argument; for example, the response to a challenge 'Justify' in a case-based dialogue may be a locution 'By precedent' with an appropriate case being advanced as supporting text. To facilitate this, the dialogue manager can provide access to appropriate case bases, databases or knowledge bases appropriate to the form of the game and the domain of argument.
- Maintenance of a history of the argument. It will be important for teaching purposes that a record of the progress of the argument is kept, perhaps to enable this to be reviewed in retrospect or to be reported as a text.
The framework we have described, however, offers scope for a greater degree of active involvement in the argument by the dialogue manager. One possibility is that access to supporting data need not be simply as directed by the participants. An intelligent dialogue manager can take an active role in identifying and suggesting suitable data to be used to support particular parts of the argument; the simplest instance of this might do this by selecting candidate information by keyword matching, leaving the user to decide whether the data suggested is indeed helpful. At the other extreme, it is possible to envisage a dialogue manager which would employ a range of heuristics to suggest to the players not only relevant supporting data but also lines of argument that they may wish to explore. Different levels of involvement of this kind could correspond to different teaching aims and levels of expertise in the students.
We have implemented in Prolog a prototype form of the DAM which takes as input a set of specifications of performatives, and controls the game so defined.
The main control loop is:
go(A,N):-write(A),nl,read(R),effect(R,A,N).
Here A is the player whose turn it is to move, N the number of the move, and R the speech act, entered by the user. The user's input is handled by effect
effect(R,A,N):-speechact(R,A, Pre,Post,Comp,H),
asserta(move(N,R)),
check(Pre),
check(Post),
retract(completes(L)),asserta(completes([[N,Comp]|L])),
check_for complete([[N,Comp]|L]),
M is N + 1,
report,
go(H ,M).
effect(R,A,N):-write([invalid,move]),nl,go(A,N).
The first clause gives effect to a particular speech act defined in the system. The second clause traps invalid moves and seeks a valid response.
The various speech acts are defined using the predicate speechact. As an example consider the performative why from TDG. (Space does not permit us to define all the performatives here: a full specification of TDG can be found in Bench-Capon et al, 1998 ).
speechact(why(P), S, [claim_stack([P|_])],
[swap(S,H),
retract(open(O)),asserta(open([why(P)|O]))],
[supply_data(P)],
H).
Here S is trying to find the grounds which support P. P must be a current claim (on the claim stack), and the effect is to make the request an open item, which will be completed when data for P is supplied. The rules of the game ensure that the dialogue cannot terminate with an open item, so this challenge must be answered before the dialogue ceases. The final argument, H, gives control to the other player.
Because the pre- and post- conditions are prolog clauses, check can be defined as:
check([]).
check([H|T]):-call(H),check(T).
To check for completions we use
check_for complete([]).
check_for_complete([N,C]|Rest]:-check(C),move(N,M),
retract(open(O),remove(M,O,Z),
asserta(open(Z)'
check_for complete(Rest).
check_for complete([N,C]|Rest]):-check_for complete(Rest).
This will remove any open speech acts whose completion conditions are now satisfied. This prototype has been tested using a specification of TDG. However, as can be seen from the code, any other game specified in the same manner could be executed.
The above can be given an interface which allows for several different interaction styles. In one example use of the system we have added an interface which offers the user a list of possible options. In order to do this we use a predicate options
options(Player,R):-findall(X,(speechact(X,_,Pre,_,_,_,Player),check(Pre)),L),
display_menu(L,R).
This applies the preconditions and generates a menu of legitimate moves for a player. A different use would allow the players to select an option on their own initiative and the system would reject invalid selections. The interaction for a very simple example is given in Appendix 2.
In this example, the first player (a) must begin by making a claim. The second player (b) is then presented with a number of options, from which he chooses to look for supporting data. The first player then chooses to supply such data rather than withdrawing the claim, and the second player accepts this. At this point there is still a claim, so the dialogue manager (ref) draws attention to this. The second player could choose another move, but he is satisfied to accept the original claim on the basis of the data supplied, and so the dialogue manager terminates the discussion.
This is a very simple example, and uses the crude interface provided by Prolog. It does, however, serve to show the dialogue manager in action.
In this case the players simply typed in their own propositions. In another version of the prototype we supply each player with a menu of propositions, representing the facts available to them from which they can select instead of supplying their own propositions.
In this paper we suggest that the teaching of how to argue is an important aspect of legal education. We believe that the use of dialogue games, specified as a set of performatives, which are themselves specified in terms of preconditions, postconditions and completion conditions, can form the basis of a system that can help to teach this skill. Describing the required argument styles in these terms allows us to supply a generic interpreter, which can act as a dialogue manager for games so specified. We have illustrated this by giving the kernel of a prototype dialogue manager and an example run based upon it.
Given such an environment, it is straightforward to design a particular game to bring out particular argumentation skills, and to produce a system, which supplies a chosen level of prompting with which students can argue with one another to acquire these skills.
ACLEC (1996) 'The Lord Chancellor's Advisory Committee on Legal Education and Legal Training: First Report on Legal Education and Legal Training'.
Aiken R M and McManus M (1997) 'Improving Collaborative Learning through Information Technology', Proceedings of IFIP Conference on Human Computer Interaction and Educational Tools, Sofia, Bulgaria
Aleven V and Ashley K D (1994) 'An Instructional Environment for Practicising Argumentation Skills', Proceedings of AAAI 1994 (Cambridge, Mass: MIT Press) 485-192.
Aleven V (1997). Teaching Case Based Argumentation Through a Model and Examples, PhD Thesis, University of Pittsburgh.
Ashley K D (1990) Modelling Legal Argument (Cambridge, Mass: MIT Press)
Bench-Capon T, Dunne P and Leng P (1991) 'Interacting with knowledge Based Systems through Dialogue Games', Proc 11th Annual Conference on Expert Systems and their Applications, Avignon 123-130
Bench-Capon T, Dunne P and Leng P (1992) 'A Dialogue Game for Dialectical Interaction with Expert Systems', Proc 12th Annual Conference on Expert Systems and their Applications, Avignon 105-113
Bench-Capon T, Coenen F and Orton P (1993) 'Argument Based Explanation of the British Nationality Act as a Logic Program', Computers, Law and AI 2(1): 53-6
Bench-Capon T, Geldard T and Leng P (1998) 'Specification of Dialogue and Argument Games', submitted for publication
Colomb R M (1997) 'Impact of semantic heterogeneity on federating databases' The Computer Journal 40(5): 235-244
Finin T, McKay D, Fritzon R and McEntire R (1994) 'KQML: An Information and Knowledge Exchange Protocol' in Fuchi, K., and Yokoi, T., (eds), Knowledge Building and Knowledge Sharing (Omsha and IOS Press)
Gordon T F (1995) The Pleadings Game, (Deventer:Kluwer)
Labrou Y (1996) Semantics for an Agent Communication Language, PhD Thesis, University of Maryland, Baltimore.
MacKenzie J D (1979) 'Question-Begging in Non-Cumulative Systems', Journal of Philosophical Logic 8: 159-177
Mullender R (1997) 'Law, Undergraduates and the Tutorial', Web Journal of Current Legal Issues 3
Prakken H and Sartor G (1997) 'Reasoning with Precedents in a Dialogue Game', proceedings of the Sixth International Conference on AI and Law, Melbourne (New York: ACM Press) 1-9.
Routen T (1991) 'Complex Input: A Practical Way of Increasing the Bandwidth For Feedback and Student Modelling in a Statute-Based Tutoring System' Proceedings of the Third International Conference on AI and Law (New York: ACM Press) 77-80.
Searle J R (1969) Speech Acts (Cambridge: Cambridge University Press)
Toulmin S (1958) The Uses of Argument (Cambridge: Cambridge University Press)
Widdison R and Pritchard F (1995) 'An Experiment with Electronic Law Tutorials' Proceedings of 10th BILETA Conference, Strathclyde.
Appendix 1 - Moves in Toulmin Dialogue Game (TDG).
Claim - used to assert that a proposition is true (example)
Why - seeks the data for a claim (example)
OK - accepts a claim (example)
So - seeks the warrant for a claim (example)
Presupposing - seeks any presuppositions on which a claim is based.
On Account Of - seeks the backing for a warrant
Supply Data - supplies the data for a claim (example)
Supply Warrant - supplies the warrant for a claim
Supply Presupposition - supplies the presupposition of a claim
Supply backing - supplies the backing for a warrant
Withdraw - withdraws a claim (example)
Switch Focus - allows a different claim to be considered (example)
Rebut - invites a player to attempt to rebut a claim
Rebuttal - supplies a rebuttal for a claim (example)
Current Claim - indicates claim under consideration (example)
 |
Figure 3: State Transition Diagram for Toulmin Dialogue Game
Appendix 2: Sample Run of Prototype System
User input is in bold font, annotations are in italic font.
7 ?- go(a,1). initiates the system
a a is the first player
1 claim(G656) <game must begin with a claim
|: 1.
[make,a,claim]
|: [peter,is,a,citizen].
com(a, [[peter,is,a,citizen]]).
com(b, []). player's commitments are displayed
claim_stack([[peter,is,a,citizen]]).
open([claim([peter,is,a,citizen])]).
claims and moves not yet completed are displayed
b b must now move
1 why([peter,is,a,citizen])
2 ok([peter,is,a,citizen])
3 so([peter,is,a,citizen])
4 rebuttal([peter,is,a,citizen], G2112)
|: 1. b chooses one of the four moves available
com(a, [[peter,is,a,citizen]]).
com(b, []).
claim_stack([[peter,is,a,citizen]]).
open([why([peter,is,a,citizen]),claim([peter,is,a,citizen])]).
a a must substantiate his claim or withdraw it
1 supply_data([peter,is,a,citizen], G3836)
2 withdraw([peter,is,a,citizen])
|: 1.
[what,is,the,supporting,data]
|: [the,father,of,peter,is,a,citizen].
a gives the grounds for the claim
com(a, [[the,father,of,peter,is,a,citizen],[peter,is,a,citizen]]).
com(b, []).a now has two commitments
claim_stack([[the,father,of,peter,is,a,citizen],[peter,is,a,citizen]]).
open([claim([the,father,of,peter,is,a,citizen]),claim([peter,is,a,citizen])]).
b
1 why([the,father,of,peter,is,a,citizen])
2 ok([the,father,of,peter,is,a,citizen])
3 so([the,father,of,peter,is,a,citizen])
4 switch_focus([the,father,of,peter,is,a,citizen])
5 switch_focus([peter,is,a,citizen])
6 rebuttal([the,father,of,peter,is,a,citizen], G6056)
|: 2. b accepts this claim
com(b, [[the,father,of,peter,is,a,citizen]]).
com(a, [[the,father,of,peter,is,a,citizen],[peter,is,a,citizen]]).
now b is also committed to a claim
claim_stack([[peter,is,a,citizen]]).
open([claim([peter,is,a,citizen])]).
ref the dialogue manager requires a disputed claim to be considered
1 current_claim
|: 1.
com(b, [[the,father,of,peter,is,a,citizen]]).
com(a, [[the,father,of,peter,is,a,citizen],[peter,is,a,citizen]]).
claim_stack([[peter,is,a,citizen]]).
open([claim([peter,is,a,citizen])]).
b
1 why([peter,is,a,citizen])
2 ok([peter,is,a,citizen])
3 so([peter,is,a,citizen])
4 rebuttal([peter,is,a,citizen], G9932)
|: 2.
b now chooses to accept the claim
com(b, [[peter,is,a,citizen],[the,father,of,peter,is,a,citizen]]).
com(a, [[the,father,of,peter,is,a,citizen],[peter,is,a,citizen]]).
claim_stack([]).
open([]).
ref no claims or open moves are left so the game ends
1 end
|: 1.
