Preparing Data for sube • sube

sube works best when the data contracts are explicit. In practice, most projects need four input families:

Supply-use table data in long form or workbook form.
Product and industry correspondence tables.
Industry-level input metrics used for multiplier and elasticity computation.
A prepared modeling table for SUBE regressions.

Whether your data comes from WIOD, FIGARO, or another national statistical office, the same canonical format applies. The package ships importers for WIOD workbooks (import_suts()) and FIGARO CSV flatfiles (read_figaro()), but any supply-use data reshaped into the canonical long format described below will flow through the same downstream pipeline.

The package deliberately separates matrix construction from econometric estimation. That keeps the Leontief benchmark workflow usable even when the modeling table is assembled elsewhere.

The shipped example objects map directly to those four families:

sube_example_data("sut_data") -> normalized supply-use table input
sube_example_data("cpa_map") and sube_example_data("ind_map") -> product and industry correspondence tables
sube_example_data("inputs") -> compute-layer input metrics
sube_example_data("model_data") -> prepared modeling table for estimate_elasticities()

That sample-data path is the easiest way to understand the required contracts before switching to external research data.

Canonical SUT Format

All SUT data must resolve to a long-format data frame with exactly 7 columns. Each row represents one cell of the supply-use table. Supply and use tables are stacked in the same data frame and distinguished by the TYPE column.

Column	Type	Semantics	Example
REP	character	Reporting country - the economy whose supply-use table is being described	`"AAA"`
PAR	character	Partner country - the economy supplying or demanding the product. Equal to REP for the domestic block	`"AAA"`
CPA	character	Product code - identifies the good or service (CPA/NACE product classification)	`"P1"`
VAR	character	Industry or final-demand variable - identifies the column in the SUT (an industry code or a final-demand code)	`"I1"`, `"FU_bas"`
VALUE	numeric	Cell value in the supply-use table, in the unit of the source data (typically millions of current-price currency units)	`10`
YEAR	integer	Reference year of the data	`2020`
TYPE	character	Table type: `"SUP"` for supply table, `"USE"` for use table	`"SUP"`

The shipped example shows this structure concretely:

sube_example_data("sut_data")
#>        REP    PAR    CPA    VAR VALUE  YEAR   TYPE
#>     <char> <char> <char> <char> <int> <int> <char>
#>  1:    AAA    AAA     P1     I1    10  2020    SUP
#>  2:    AAA    AAA     P1     I2     2  2020    SUP
#>  3:    AAA    AAA     P2     I1     1  2020    SUP
#>  4:    AAA    AAA     P2     I2     8  2020    SUP
#>  5:    AAA    AAA     P1     I1     3  2020    USE
#>  6:    AAA    AAA     P1     I2     1  2020    USE
#>  7:    AAA    AAA     P1 FU_bas     6  2020    USE
#>  8:    AAA    AAA     P2     I1     2  2020    USE
#>  9:    AAA    AAA     P2     I2     2  2020    USE
#> 10:    AAA    AAA     P2 FU_bas     5  2020    USE

Column name synonyms

Column names in the 7-column SUT table are matched after uppercasing only - there is no synonym resolution for the SUT columns themselves. Synonyms apply exclusively to mapping table columns (cpa_map, ind_map) passed to functions such as import_suts(). All matching is case-insensitive because column names are uppercased on import.

Canonical Name	Accepted Synonyms
CPA	CPA, CPA56, CPA_CODE
CPAAGG	CPAAGG, CPA_AGG, PRODUCT, PRODUCT_AGG
VARS	VARS, VAR, INDUSTRY, IND, CODE, NACE, NACE_R2
INDAGG	INDAGG, IND_AGG, INDUSTRY_AGG, SECTOR

Satellite Vector Inputs

The inputs table is researcher-supplied from national accounts or external sources - the package does not derive these values from the SUT data. compute_sube() requires it as a separate argument alongside the matrix bundle.

Column	Type	What It Measures	Required?	Source
YEAR	integer	Reference year	Yes	Must match SUT YEAR values
REP	character	Country code	Yes	Must match SUT REP values
INDUSTRY (or synonym)	character	Industry identifier	Yes	Must match VAR codes in the SUT
GO	numeric	Gross output - total production value by industry	Yes	Researcher-supplied (e.g. national accounts)
VA	numeric	Value added - GDP contribution by industry	Optional	Researcher-supplied
EMP	numeric	Employment - workers or hours by industry	Optional	Researcher-supplied
CO2	numeric	CO2 emissions by industry	Optional	Researcher-supplied

The industry identifier column accepts synonyms: IND, INDUSTRY, INDUSTRIES, INDAGG (checked in that order; first match wins). GO is the only metric always required. VA, EMP, and CO2 are computed when present in the data frame.

sube_example_data("inputs")
#>     YEAR    REP INDUSTRY    GO    VA   EMP   CO2
#>    <int> <char>   <char> <int> <int> <int> <int>
#> 1:  2020    AAA      I01    12     4     3     2
#> 2:  2020    AAA      I02     9     3     2     1

Bring Your Own Data

This section walks through reshaping arbitrary supply-use data into the canonical format expected by the package.

SUT table preparation

Identify which columns in your source data correspond to REP, PAR, CPA, YEAR, and TYPE.
Rename or map columns to the canonical names, or supply them with any casing - import_suts() will uppercase all column names on import.
Choose a layout: long format (all 7 columns including VAR and VALUE) or wide format (5 identity columns with industry codes as column headers). import_suts() accepts both.
If using wide format: be aware that aggregate demand columns (e.g. total final use) will be melted as industry columns unless they match known WIOD aggregates. Remove or rename them before import if needed.
Call import_suts() on the file path. Inspect the result with head() and str() to verify all 7 columns are present and values look correct.

Satellite vector preparation

Obtain gross output (GO) by industry from national accounts or your preferred source. This column is required.
Optionally gather value added (VA), employment (EMP), and CO2 emissions (CO2) by industry.
Structure the data with columns YEAR, REP, and one industry identifier column (any of: IND, INDUSTRY, INDUSTRIES, or INDAGG).
Ensure YEAR and REP values match those in your SUT data exactly.
Provide one row per (YEAR, REP, INDUSTRY) combination. Pass the resulting data frame to the inputs argument of compute_sube().

The remaining sections walk through the shipped example objects in detail, illustrating each data family in the preparation sequence.

Supply-use data

The sut_data example below shows the 7-column canonical format described above in practice - the shipped object already conforms to the contract, so you can inspect its shape before reshaping your own source.

Imported SUT data should resolve to these columns:

names(sube_example_data("sut_data"))
#> [1] "REP"   "PAR"   "CPA"   "VAR"   "VALUE" "YEAR"  "TYPE"

Use import_suts() for normalized CSV files or WIOD-style workbooks, then filter with extract_domestic_block() when the domestic block is required.

For large comparative projects, it is worth standardizing country, partner, year, variable, and product codes before import. The package will normalize column names, but it does not guess missing structural fields.

Mapping tables

Mapping tables bridge the canonical SUT columns to the aggregated matrix dimensions needed by build_matrices(). The synonym resolution described above applies here - use any of the accepted column-name variants for the source code and aggregated code.

The product and industry maps can use simple two-column tables:

sube_example_data("cpa_map")
#>       cpa cpa_agg
#>    <char>  <char>
#> 1:     P1     P01
#> 2:     P2     P02
sube_example_data("ind_map")
#>      vars ind_agg
#>    <char>  <char>
#> 1:     I1     I01
#> 2:     I2     I02

The package normalizes names internally, but the first two columns should still represent source code and aggregated code.

In practice, these mapping tables determine the resolution of the full workflow. If the package-level products differ from the paper-level products, the comparison plots will reflect that aggregation choice.

Input metrics

The inputs example provides the satellite vectors described in the Satellite Vector Inputs section above - researcher-supplied series (GO required; VA, EMP, CO2 optional) joined to the matrix bundle during compute.

The computation stage needs YEAR, REP, one industry identifier column, and at least GO. Additional metrics such as VA, EMP, and CO2 are computed when present.

sube_example_data("inputs")
#>     YEAR    REP INDUSTRY    GO    VA   EMP   CO2
#>    <int> <char>   <char> <int> <int> <int> <int>
#> 1:  2020    AAA      I01    12     4     3     2
#> 2:  2020    AAA      I02     9     3     2     1

Modeling table

The modeling table combines matrix outputs with satellite-derived multipliers for econometric estimation - it is the last-mile object assembled after the Leontief benchmark layer is stable.

estimate_elasticities() uses a prepared table with:

country and year identifiers
one entity column, such as industries or products
response variables such as GO, VA, EMP, or CO2
predictor columns for the supply-use based explanatory structure

names(sube_example_data("model_data"))
#> [1] "COUNTRY"    "YEAR"       "INDUSTRIES" "P01"        "P02"       
#> [6] "GO"         "VA"         "EMP"        "CO2"

This design is intentional. Some projects will derive the modeling table from the same supply-use source, while others will merge additional covariates or paper-specific filters before estimation.

Recommended preparation strategy

For reusable workflows, it is usually best to prepare data in this order. The shipped examples follow the same sequence, so you can inspect each object family before substituting your own files:

standardize raw supply-use inputs,
verify correspondence tables,
build the domestic matrix bundle,
compute Leontief benchmark results, and
construct the modeling table only after the benchmark layer is stable.