• Logged in as Unregistered User
  • Sign in

Social-Ecological Systems Meta-Analysis Database: Manual

SESMAD database manual

Download PDF

1. The SES framework:

Our conceptualization of a social-ecological system (SES) has been inspired by a framework proposed by Ostrom (2007, 2009). We adapted this framework to include potentially important variables from several literatures, and more specifically to allow us to analyze a diversity of large-scale SESs. The result is our own SES framework and database structure. Figure 1 shows the original version of the framework as introduced by Ostrom (2009).

Figure 1: the original SES framework as introduced by Ostrom (2009)

Figure 1 shows a SES as consisting of four main components: governance systems, actor groups (referred to as users in the figure), resource units, and resource systems. The SES framework is itself a reflection of earlier work at the Workshop in Political Theory and Policy Analysis that led to the Institutional Analysis and Development (IAD) Framework (see Ostrom 2005), which we will not discuss in depth here.

Ostrom did not define the components in her introduction of the framework. As a result, we have adopted the following definitions for this project, using the term “actor groups” in place of “users”, which is consistent with more recent applications of the framework. We also combined resource systems and resource units into one category, labeling this “environmental commons.” This led to the following definitions for each of these three main components:

Governance system: A set of institutional arrangements (such as rules, policies, and governance activities) that are used by one or more actor groups to interact with and govern an environmental commons. Examples include the Montreal Protocol regime, the Great Barrier Reef Marine Park Act, and the International Convention for the Conservation of Atlantic Tunas.

Actor group: A group of actors, i.e. of individuals, organizations or nations that has developed a set of institutional arrangements in order to directly or indirectly interact an environmental commons. In our analysis we include groups whose members actually interact with each other (e.g. a particular management agency) as well as groups whose members may not interact very often if at all (e.g. fishermen who catch Bluefin tuna in the Atlantic Ocean).

Environmental commons: An environmental phenomenon that is associated with the provision of important benefits to certain actor groups, and the use or production of which is also associated with negative extraction or emission-based externalities. An environmental commons is the subject of governance for any case in the SESMAD project.

A final element to discuss here is the Interactions label in the middle of figure 1. This reflects a concept initially developed for the IAD framework, the action situation. An action situation is a social arena in which a consistent set of actors and/or actor groups repeatedly make a set of decisions that affect social or biophysical outcomes, and the welfare of each other in the process. This is the core unit of analysis for the SES framework, as well as the SESMAD database, as is explained below.


2. The SESMAD database and website

a. Starting a case

SESMAD data is stored in a relational database, meaning that this is constituted by many tables that are linked to each other. The first step in entering data into the database is to create a SES as a “case” in the Case Table, which is the central table for the entire database. This is done by clicking on the “Create a New SES Case” in the main window of the SES cases tab. The fields in the subsequent form are based on the columns that this table contains.

It is in fact not required that the user proceed any further than this if they only wish to describe the case in very general terms. They may enter the studies that they used to code the case, if they did use any. This is also done via the case form, although the studies must be entered separately. Additionally, the user may upload any survey or data collection-related instruments that are relevant for a case and/or a study. In this way, even without the more extensive variable-based tables discussed below, the SESMAD database can serve as a repository for SESs descriptions, the studies that are written about them, and the data collection instruments used to conduct these studies.

Once a case has been created, the next step is to create the components that belong to that SES and link them together. All of the components, regardless of their type, are recorded in the Components Table. To add components to a case, you first create the component by clicking on the components tab and then clicking on the “add a component” button. Once you have created your components, you need to navigate back to the SES cases tab and click on the “manage case components” button for your case. From here you can add components to your case.

Figure 2 shows the relational structure that captures this functionality. Two tables, the Case Table and the Component Table, are linked together in a many-to-many relationship by a linking table called the CaseComponent table. A many-to-many relationship means that each record in either table can be linked to one or more records in the other table. Effectively: a case can have more than one component, and a component can be linked to more than one case. The CaseComponent linking table links records in the Case table to records in the Component table with two columns, one which records the Case record being linked and the other which records which record from the Component table is being linked. Additionally, a second linking table connects the Case table to the Study table to perform a similar function.

Figure 2: Linking cases to components and studies

Following this, the next step in coding a case in the database is to link the different components together via interactions, which are recorded in the Interactions Table. Components are joined to Interactions via two intermediary tables: first through the CaseComponent table already mentioned, and then through the ComponentInteraction table, both of which are linking tables (see figure 3). The Interactions are linked through the CaseComponent table for this reason: it makes each interaction specific to a particular case and (set of) components. One easy way to think about this schema as discussed so far is through the following series of steps:

  1. The user first introduces a case
  2. The user then creates components and assigns these to a case
  3. The user then creates interactions, and assigns them to a case and a (sub)set of its components.

In addition to linking components to interactions directly, the ComponentInteraction table links to a Rule table, which is used to describe the rules that apply to certain types of actor groups that use an environmental commons. Rules play a central role in the SESMAD database and the social-ecological and institutional literature upon which it is based. Ultimately the outcomes explored and/or explained in the SESMAD database result in large part from the behavior of commons users, and rules play an integral role in affecting this behavior (see the background). The Rule table can be used to record as many rules as the user desires that are applied to a commons user (commons user is a Role that an actor group can have in an interaction: see section 3 on variables and diagnostics below).

Interactions themselves are the focal unit of analysis on the SESMAD approach. Conceptually, interactions play the same role as the “action situation” in the IAD framework, and the “interactions and outcomes” portion of the SES framework. Interactions capture how two or more components relate to each other to produce important outcomes.

Figure 3 shows the tables in the database that have been described so far.

Figure 3: Linking components together via interactions

The database allows a user to add an unlimited number of components to an interaction, but this is not advised. The working rule is to try to minimize the number of components involved in any particular interaction in order to make that interaction as specific to its components as possible. Instead of highly complex interactions, the goal is to have a greater number of interactions in a case, each with relatively few components attached to each interaction.

Additionally, there are be some logic-based rules that restrict how users can use interactions in other ways. The database will not allow users to violate these rules when they enter data for their case. These rules are specific to two the different types of interactions that the database currently contains. The first is a Governance Interaction, and the second is a Biophysical Interaction. A governance interaction involves the governance of an environmental commons by one or more actor groups and at least one governance system. For Governance Interactions, the rules are the following:

  1. They must have at least one governance system
  2. They must have one or more actor groups
  3. They must have exactly one environmental commons

Biophysical interactions don’t describe the governance of a commons by an actor group and a governance system, but instead strictly describe the relationship between commons. This could be, for example, the effects that a pollutant has on natural resource. For these types of interactions, we want to limit the user to only adding commons as components, since that is the sole purpose of such interactions. Thus biophysical interactions must have two environmental commons and cannot have other components.

Other types of interactions are possible in theory, but are not currently planned and will only be developed as needed for particular research needs. In fact this statement applies for all of the content in the database, except for variables and theories, which we will now discuss.


b. Variables and diagnostics

One of the primary purposes of the SESMAD database (and arguably the underlying SES framework) is to enable more consistent measurement of theoretically important concepts from the relevant literatures. To support this goal, the database has a Variables table that describes every variable that the database contains. These variables are each viewable via the System management tab from the main page. The Variables table also links to the Studies table to enable users to record which studies are particularly important in defining or measuring the variable being described. Users can add new variables to the database, pending review and approval by the SESMAD project team.

In order to fully understand the content and function of the Variables table, we need to explore a major aspect of the SESMAD database that has not been explained. This is how exactly the SESMAD database implements what Lin Ostrom and Oran Young and others have referred to as the diagnostic analysis of environmental problems. This essentially means systematically prioritizing the examination of certain variables for certain types of cases. To implement this process, the SESMAD database breaks components into subtypes in several ways, and assigns variables to various subtypes.

We have actually already discussed one such dimension:

ComponentType: Specifies whether a component is a Governance system, an Actor group, or an Environmental commons (see the background for descriptions of these)

Following this, we have component subtypes:

ComponentSubtype: Further disaggregates components into subtypes. The values that are available depend on the type of component that was specified under the ComponentType variable. For each of the component types, the following subtypes are currently available:

Environmental commons: Natural resource system; Natural resource unit; Pollutant

Governance system: Formal; Informal

Actor group: None; Local resource user group(s); Local government(s); Government agency; Quasi-governmental agency; Secretariat ; NGO(s); Corporation(s); Nation(s); Research community

In addition to component types and subtypes, there is a third dimension that is independent of these, that describes what environmental sector a component is involved in.

ComponentSector: Specifies the type of environmental issue that the component is a part of. Examples include irrigation, fisheries, or pollution. The options available for this apply to all component types.

Finally, SESMAD considers the role that a component plays in an interaction, and only asks about variables associated with certain roles. These variables do not describe the component per se, but describe how it participates in an interaction.

ComponentRole: Specifies the role that a component plays in an interaction. Like the ComponentSubtype variable, the options available for this are specific to each type of component. For actor groups, the two possible roles are currently Commons user and Governance Organization. For Environmental Commons there are a variety of roles, the most important of which is “Is governed” which is the role it plays in Governance Interactions.

Each of these variables are used by the SESMAD database to select which other variables are relevant for a given component and its participation in an interaction. For example, actor groups that are commons users have many variables (such as from the common-pool resource literature) that we want to ask of them that we don’t ask of actor groups that are not commons users.

Which variables are specific to which types of components can be seen be browsing the variables table. There are fields for each variable that specify whether it is specific to certain types of components, and if so, which types. If these fields are left blank, then the variable is assumed to be relevant for all types of components.

Figure 4 shows the tables in the database that have been described so far. The variables table links up to the (1) Component and (2) ComponentInteraction tables via linking tables in order to record the values of the relevant variables for (1) the components themselves, and (2) their participation in a given interaction. Appendix A describes how exactly these particular linking tables record the values of variables, and essentially how the SESMAD database stores most of its data on SESs.

Figure 4: The SESMAD database with the Variables table added

c. Formalizing theories and completing the SESMAD schema.

The final important table that has not yet been discussed is the Theories table. This table allows users to record theories that relate the values of a set of variables to a particular outcome. The user can in turn relate each theory to a case (SES) or a study that (1) confirms or (2) contradicts a theory. This process then will enable the SESMAD database to record what types of cases tend to support or contradict different types of theories. Formally stated theories will also further the diagnostic approach by allowing users to consider what variables to pay particular attention to in their analysis. This can be done by considering what variables play important roles in theories that are confirmed or contradicted by cases similar to the one they happen to be studying.

Figure 5 presents the full SESMAD database schema. The left-hand side of the diagram contains the tables that record the great majority of actual empirical data for all of the cases. The right-hand side, in comparison, holds data pertinent to the manual and to making the database function properly. These are connected by the series of linking tables in the middle of the diagram. Table 1 lists all of the major tables contained in the database.

Figure 5: the full SESMAD database schema



Cox, Michael. 2014. “The SESMAD Project.” International Journal of the Commons.

Ostrom, Elinor. 2005. Understanding Institutional Diversity. Princeton, NJ: Princeton University Press.

———. 2007. “A Diagnostic Approach for Going beyond Panaceas.” PNAS 104 (39): 15181–15187.

———. 2009. “A General Framework for Analyzing Sustainability of Social-Ecological Systems.” Science 325: 419–422.


Appendix A: How the database records variable values:

The SESMAD database uses a Variables table that describes all of the variables in the database. There are linking tables that relate the variables in this table to elements of a particular case. Figure 7 shows an example of this. The first table to the left is the variables table, with one variable in it: GroupSize, which is associated with actor groups. The table to the right is the Components table, with one observation. The ID numbers for the variable and the components are 1 and 5, respectively. What each row in the middle linking table does is record what variable (via the FK_Var field) has what value (in the Value field) in which component (recorded in the FK_Comp) field. This way of recording data changes the syntax of the queries that are used to retrieve data, but this isn’t really a disadvantage. The advantages are that (1) it enables variables to be associated with types and subtypes of components, and (2) users can add their own variables to the variables table (pending approval), which structurally is much simpler, since it involves adding new records, as opposed to adding columns under the traditional structure.

Figure 7: SESMAD data storage

Appendix B: Summary of main SESMAD tables

Table 1: SESMAD tables

Table NameDescription
CaseThe primary table in the database. Each record is an individual social-ecological system.
CaseComponentLinking table that connects cases to components.
ComponentContains instances of the constitutive componens of a SES (Actor Groups, Governance Systems, Commons).
ComponentInteractionLinking table between the CaseComponent and Interaction tables. Records how a component participates in an interaction.
InteractionRecords interactions, which are the focal unit of analysis for the SESMAD database.
RuleRecords rules that an actor group uses to govern a commons. Only applicable to actor groups that are commons users.
VariableContains descriptions of all of the variables contained in the database.
TheoryContains theoretical statements that link several variables together, and are supported (or not) by particular cases.
StudyContains studies that are associated with a particular case, variable, or theory.
PeopleContains members of the SESMAD team as well as authors of cases.
TeamRecords which team members are working on which cases.