NarrABS v1.0.0

Purpose Starting from the notion that agent behavior is fundamentally based on activity rules, it should be obvious that these need not necessarily be expressed in equations or in other numerical formats, but can also be derived from text information. Furthermore, one of the advantages of object oriented programming, as it is mostly used in agent based modeling, is that agents can have differing viewpoints and types of reasoning within the same institutional setting. In an extreme case, an agent based model should be able to handle different reasoning for every agent; although in practice it may be appropriate to group agents with an identical reasoning, however still different parameter values. The purpose of this simulation is thus to demonstrate the feasibility of creating an agent based model of a political process based on the narratives of the participating stakeholders describing that process in qualitative interviews. The findings are complemented by transcripts of participating observations of group discussions of the same stakeholders. The simulation should not only be able to reconstruct past discussions, but also provide a tool to explore different institutional settings in which these discussions take place. Agent types and state variables The model distinguishes between acting (‘agents’) and static entities (‘resources’). In this case, the agents represent the stakeholders, plus one “Regional Management” agent, while the projects (starting with projects funded in 2009, plus those generated by agents in later simulation scenarios) and the discussion arguments and development goals derived from the empirical analysis are inserted as resources. A “World” agent is responsible for global processes such as setting the date or saving output files. Agents (acting entities) State variables and types Regional Management Projects to be discussed and decided (List of Projects) Decided projects (List of projects) Schedule of meetings (List of dates) Discussion log (List of speaking stakeholders and arguments brought forward) Decision log (List of projects decided with corresponding votes) Regional Stakeholders Name Affiliation (municipality and sector) Schedule of events (List of dates and event types) Individual development goals (List of development goals) Available discussion arguments (List of discussion arguments) Projects supported (List of projects) Projects dismissed (List of projects) World Date Path to output files Resources (static entities) State variables and types Projects ID-Number Project initiator (stakeholder) Project name Date of decision Project category Funding provided Discussion arguments ID-Number Argument category Argument caption Development goals ID-Number Goal category Goal caption Process overview and scheduling The simulation is organized in modules, each of which covers specific tasks of the simulation. Module 1) Project creation The meeting of the agent “regional management” with one of the “stakeholder” agents is simulated at an average of every seven days to create projects that are added to the agenda of the following meeting of the (simulated) assembly. The attributes of the projects are negotiated among the agents corresponding to their development goals. Module 2) Invitation to the regional assembly Usually every second Wednesday of a month, the regional assembly congregates to deliberate about the latest project applications. One week ahead, the regional management agent sends invitations to the assembly members. This is implemented in the simulation by adding the meeting to the respective agents’ schedules. The meeting itself is represented by saving a list of the agents met and the exchange of arguments when discussing the applications. Module 3) Discussions in the regional assembly The agents pipe up and bring forward discussion arguments from a pool of available arguments as investigated empirically. The course of the discussion is logged by the regional management agent. Because a clear assignment of argument categories to groups of agents is not empirically supported, the starting point of discussions is chosen at random. However, depending on the category of the project in question, arguments are preselected in a way that is consistent with the meetings’ observation results. In case more than one argument category is available, the simulated discussions tend to remain in one of them at first, in which the single arguments may also be brought forward repeatedly. The longer the discussion runs, the more likely it will turn to a new argument category, but might as well return to a previous one. Furthermore, a few particular sequences of arguments are excluded to preserve consistency. The total length of a discussion is limited depending on the total number of arguments available. Module 4) Decision When the discussion has come to an end, the assembly members entitled to vote decide about each project application. A project is approved if the number of supporting votes is greater than that of dissenting votes. In this case, the application is removed from the list of pending projects and its budget subtracted from the total budget available. The agents decide predominantly according to the proportion of the own ‘pro’ and ‘con’ arguments in the discussion to support or dissent a project. Agent that had been silent during the discussion direct their vote according to the total numbers of ‘pro’ and ‘con’ arguments, thus being ‘convinced’ in the course of discussion.
This is a companion discussion topic for the original entry at https://www.comses.net/codebases/3172/releases/1.0.0/