knitr::opts_chunk$set( collapse = TRUE, comment = "#>" )
This tutorial is a companion to the manuscript, which shows how to create different kinds of data in {peacesciencer}
. However, space considerations (for ideal publication in a peer-reviewed journal) preclude the full "knitting" experience (i.e. giving the user a preview of what the data look like). What follows is a brief guide that expands on the tutorial section of the manuscript for creating different kinds of data in {peacesciencer}
.
This vignette will lean on the {tidyverse}
package, which will be included in almost anything you should do (optimally) with {peacesciencer}
. I will also load {lubridate}
. Internal functions in {peacesciencer}
use {lubridate}
---it is a formal dependency of {peacesciencer}
---but users may want to load it for doing some additional stuff outside of {peacesciencer}
.
library(tidyverse) library(peacesciencer) library(lubridate)
The most basic form of data {peacesciencer}
creates is state-year, by way of create_stateyears()
. create_stateyears()
has two arguments: system
and mry
. system
takes either "cow" or "gw", depending on whether the user wants Correlates of War state years or Gleditsch-Ward state-years. It defaults to "cow" in the absence of a user-specified override given the prominence of Correlates of War data in the peace science ecosystem. mry
takes a logical (TRUE
or FALSE
), depending on whether the user wants the function to extend to the most recently concluded calendar year (r year(Sys.Date())-1
). The Correlates of War state system data extend to the end of 2016 while the Gleditsch-Ward state system extend to the end of the 2017. This argument will allow the researcher to extend the data a few years, under the (reasonable) assumption there have been no fundamental composition changes to the state system since these data sets were last updated. mry
defaults to TRUE
in the absence of a user-specified override.
This will create Correlates of War state-year data from 1816 to r year(Sys.Date())-1
.
create_stateyears()
This will create Gleditsch-Ward state-year data from 1816 to 2017.
create_stateyears(system = "gw", mry = FALSE)
create_dyadyears()
is one of the most useful functions in {peacesciencer}
, transforming the raw Correlates of War state system data (cow_states
in {peacesciencer}
) or Gleditsch-Ward state system data (gw_states
) into all possible dyad-years. It has three arguments. system
and mry
operate the same as they do in create_stateyears()
. There is an additional argument---directed
---that also takes a logical (TRUE
or FALSE
). The default here is TRUE
, returning directed dyad-year data (useful for dyadic conflict analyses where the initiator/target distinction matters). FALSE
returns non-directed dyad-year data, useful for cases where the initiator/target distinction does not matter and the researcher cares more about the presence or absence of a conflict. The convention for non-directed dyad-year data is that ccode2 > ccode1
and the underlying code of create_dyadyears()
simply takes the directed dyad-year data and chops it in half with that rule.
Here are all Correlates of War dyad-years from 1816 to r year(Sys.Date())-1
.
create_dyadyears()
Here are all Gleditsch-Ward dyad-years with the same temporal domain.
create_dyadyears(system = "gw")
Consider this section of the vignette as a comparison to the kind of dyad-year data that EUGene would create for a user, apparently on request. EUGene would apparently create these types of dyad-years as specific dyad-year types whereas {peacesciencer}
treats them as case exclusions you can do after the fact given other functionality in the package. For example, here are just major vs. major dyads. For simplicity's sake, these will all be directed dyad-years at their core (and captured with cow_ddy
in the package as a shortcut).
cow_ddy %>% add_cow_majors() %>% filter(cowmaj1 == 1 & cowmaj2 == 1)
These are all dyad-years where any state is a major power.
cow_ddy %>% add_cow_majors() %>% filter(cowmaj1 == 1 | cowmaj2 == 1)
These are all dyad-years separated by 400 miles of water or fewer, though the documentation for add_contiguity()
cautions that users should be at least a little critical of the contiguity data.
cow_ddy %>% add_contiguity() %>% filter(conttype %in% c(1:5))
These are all dyad-years with a minimum distance of some user-specified threshold (in kilometers). This function will lean on add_minimum_distance()
, which does have the side effect of truncating the left bound of the temporal domain to---as of right now---1886. These are all Correlates of War dyad-years from 1886 to 2019 separated by 1,000 kilometers or fewer.
cow_ddy %>% add_minimum_distance() %>% filter(mindist <= 1000)
Dyadic dispute-year data come pre-processed in {peacesciencer}
. Another vignette show how these are transformed to true dyad-year data, but they are also available for analysis. For example, the (directed) dyadic dispute-year Gibler-Miller-Little (GML) MID data are available as gml_dirdisp
. Here, we can add information to these dyadic dispute-years to identify contiguity relationships and Correlates of War major status.
gml_dirdisp %>% add_contiguity() %>% add_cow_majors()
Users interested in the Correlates of War MID data will have this available for use as cow_mid_dirdisps
. Future updates may change the object names for better standardization, but this is how it is now.
{peacesciencer}
comes with a create_statedays()
function. This is admittedly more proof of concept as it is really difficult to conjure too many daily data sets in peace science, certainly with coverage into the 19th century. No matter, create_statedays()
will create these data. It too has the same system
and mry
arguments (and same defaults) as create_stateyears()
.
Here are all Correlates of War state-days from 1816 to r year(Sys.Date())-1
.
create_statedays()
Here are all Gleditsch-Ward state-days with the same temporal domain.
create_statedays(system = "gw")
I can conjure an application where a user may want to think of daily conflict episodes within the Gleditsch-Ward domain. The UCDP armed conflict data have more precise dates than, say, the Correlates of War MID data, making such an analysis possible. However, there are no conflict data before 1946 and you should reflect that with {peacesciencer}
with something like this. This will require {lubridate}
.
create_statedays(system = "gw") %>% filter(year(date) >= 1946)
State-months are simple aggregations of state-days. You can accomplish this with a few more extra commands after create_statedays()
.
create_statedays(system = "gw") %>% mutate(year = year(date), month = month(date)) %>% distinct(gwcode, statename, year, month)
There is some assumption worth belaboring about what a "quarter" would look like in a more general context, but it might look something like this. Again, this is an aggregation of create_statedays()
.
create_statedays(system = "gw") %>% mutate(year = year(date), month = month(date)) %>% filter(month %in% c(1, 4, 7, 10)) %>% mutate(quarter = case_when( month == 1 ~ "Q1", month == 4 ~ "Q2", month == 7 ~ "Q3", month == 10 ~ "Q4" )) %>% distinct(gwcode, statename, year, quarter)
{peacesciencer}
has leader-level units of analysis as well, which can be easily created with the modified Archigos (archigos
) data in {peacesciencer}
. The data are version 4.1.
archigos
create_leaderdays()
will create leader-day data from archigos
.
create_leaderdays()
I do want to note one thing about the leader-level functions in this package. Whereas Correlates of War state system membership is often the default system for a lot of functions (prominently create_stateyears()
and create_dyadyears()
), the Gleditsch-Ward system is the default system because that is the state system around which the Archigos project created its leader data. Moreover, the leader data aren't exactly tethered to the Gleditsch-Ward state system for dates either (e.g. there are leader entries for Gleditsch-Ward states that aren't in the system yet). In a case like this, you can standardize these leader data to either the Correlates of War system or the Gleditsch-Ward system with the standardize
argument. By default, the option here is "none" (i.e. return all available leader days recorded in the Archigos data). "cow" or "gw" standardizes the leader data to Correlates of War state system membership or Gleditsch-Ward state system membership, respectively.
create_leaderdays(standardize = "cow")
The user may want to think about some additional post-processing on top of this, but this is enough to get started. From there, the same process that creates state-months can create something like leader-months.
create_leaderdays() %>% mutate(year = year(date), month = month(date)) %>% group_by(gwcode, obsid, year, month) %>% slice(1)
And here are leader-years, which are pre-packaged as a {peacesciencer}
function. The package also adds some information about leader gender, an approximation of the leader's age that year (i.e. year - yrborn
), and a running count (starting a 1) for the leader's tenure (in years).
create_leaderyears()
{peacesciencer}
can also create leader dyad-year data by way of create_leaderdyadyears()
. You can see some of the underlying code that is creating these data. It's a lot of code, it would take a lot of time to run from scratch, and the ensuing output is too large to store as an R data object in the package because CRAN hard-caps package size at 5 MB. Instead, users who want these data should first run download_extdata()
when they first install or update the package. Therein, they can run create_leaderdyadyears()
to create the full universe of leader dyad-year data.
# create_leaderdyadyears() is effectively doing this. # Let's do the G-W leader dyad-year data for illustration's sake. # `download_extdata()` will download these data into the package directory. # Thus, it is *not* downloading the data fresh each time. the_url <- "http://svmiller.com/R/peacesciencer/gw_dir_leader_dyad_years.rds" readRDS(url(the_url)) %>% declare_attributes(data_type = "leader_dyad_year", system = "gw") # ^ compare with: # download_extdata() # create_leaderdyadyears()
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.