This document specifies the target configuration format for OpenFisca Data Manager. It is intentionally separate from the current INI/JSON implementation so the migration can be implemented in small, testable steps.
- Replace the historical
config.ini+raw_data.inipair with a single human-maintained YAML file. - Replace collection JSON files with YAML files that can still be generated by the tools.
- Keep global user configuration separate from generated collection metadata.
- Make paths, formats and per-survey overrides explicit.
- Keep old INI/JSON files importable during the transition.
Recommended layout:
~/.config/openfisca-data-manager/
├── data-manager.yaml
└── collections/
├── erfs.yaml
└── bdf.yaml
data-manager.yaml is the user-maintained entrypoint. Files under collections/ describe collection metadata and may be generated or edited manually.
Example data-manager.yaml:
version: 1
storage:
collections_directory: /path/to/collections
output_directory: /path/to/data
tmp_directory: /path/to/tmp
defaults:
source_format: sas
store_format: parquet
categorical_strategy: unique_labels
collections:
erfs:
label: Enquete revenus fiscaux et sociaux
metadata: collections/erfs.yaml
raw_surveys:
"2019": /raw/erfs/2019
"2020": /raw/erfs/2020
bdf:
label: Budget des familles
metadata: collections/bdf.yaml
source_format: parquet
raw_surveys:
"2017": /raw/bdf/2017version is required and must be 1 for this format.
storage.collections_directory is the directory containing collection metadata files when relative metadata paths are used.
storage.output_directory is where transformed data is written.
storage.tmp_directory is where temporary files are written.
defaults is optional. Values apply to all collections and surveys unless overridden.
collections maps collection names to collection declarations.
label is optional.
metadata is optional. If omitted, the default is <storage.collections_directory>/<collection_name>.yaml.
source_format, store_format and categorical_strategy are optional collection-level overrides.
raw_surveys replaces raw_data.ini. It maps survey suffixes, usually years, to raw input paths. Values may be either a string path or an object with overrides.
Example with per-survey overrides:
collections:
erfs:
metadata: collections/erfs.yaml
raw_surveys:
"2019": /raw/erfs/2019
"2020":
path: /raw/erfs/2020
source_format: parquet
store_format: parquetExample collections/erfs.yaml:
version: 1
name: erfs
label: Enquete revenus fiscaux et sociaux
surveys:
erfs_2019:
label: ERFS 2019
raw_path: /raw/erfs/2019
source_format: sas
store_format: parquet
parquet_file_path: /path/to/data/erfs_2019
tables:
household:
label: Household table
source_format: parquet
variables:
- household_id
- household_weight
parquet_file: /path/to/data/erfs_2019/household.parquet
person:
label: Person table
source_format: parquet
parquet_file: /path/to/data/erfs_2019/person.parquetversion is required and must be 1.
name is required and must match the key used in data-manager.yaml.
label is optional.
surveys maps survey names to survey metadata.
label is optional.
raw_path is optional but recommended for traceability.
source_format, store_format and categorical_strategy are optional effective values used to build or rebuild the survey.
hdf5_file_path and parquet_file_path describe transformed storage. New builds should prefer parquet_file_path.
tables maps table names to table metadata.
label is optional.
source_format is optional if inherited from the survey.
variables is optional and contains the known variables for the table.
parquet_file is optional and points to the table parquet file when data is stored as parquet.
Additional reader-specific fields may be stored under reader_options later.
Legacy:
[collections]
collections_directory = /path/to/collections
erfs = /path/to/collections/erfs.json
[data]
output_directory = /path/to/data
tmp_directory = /path/to/tmpMaps to:
storage:
collections_directory: /path/to/collections
output_directory: /path/to/data
tmp_directory: /path/to/tmp
collections:
erfs:
metadata: /path/to/collections/erfs.yamlLegacy:
[erfs]
2019 = /raw/erfs/2019
2020 = /raw/erfs/2020Maps to:
collections:
erfs:
raw_surveys:
"2019": /raw/erfs/2019
"2020": /raw/erfs/2020Legacy JSON:
{
"name": "erfs",
"label": "ERFS",
"surveys": {
"erfs_2019": {
"name": "erfs_2019",
"label": "ERFS 2019",
"parquet_file_path": "/path/to/data/erfs_2019",
"tables": {
"person": {
"source_format": "parquet",
"variables": ["person_id"]
}
}
}
}
}Maps to:
version: 1
name: erfs
label: ERFS
surveys:
erfs_2019:
label: ERFS 2019
parquet_file_path: /path/to/data/erfs_2019
tables:
person:
source_format: parquet
variables:
- person_idThe survey name field is redundant with the surveys key and should not be repeated in the YAML form unless a future use case requires aliases.
- Absolute paths are kept as-is.
- Relative paths in
data-manager.yamlare resolved relative to the directory containingdata-manager.yaml. - Relative
metadatapaths are resolved relative tostorage.collections_directoryif that field is absolute, otherwise relative todata-manager.yaml. - Relative paths in collection metadata are resolved relative to the collection metadata file.
The loader should support three combinations during the transition:
- INI global config + JSON collection metadata.
- YAML global config + JSON collection metadata.
- YAML global config + YAML collection metadata.
The canonical format is YAML global config + YAML collection metadata.
The migrate-survey-manager-config command supports both conservative INI migration and YAML migration:
migrate-survey-manager-config
migrate-survey-manager-config --format yaml
migrate-survey-manager-config --format yaml --collections--format yaml creates data-manager.yaml from config.ini and raw_data.ini.
--format yaml --collections also converts referenced collection JSON files to collection YAML files.
The old files must not be deleted by the migration command.
- Whether
source_formatshould be mandatory once inferred from raw files. - Whether generated collection metadata should include all raw file paths or only transformed storage paths.
- Whether collection metadata files should be treated as generated artifacts or user-editable configuration.
- Whether
data-manager.yamlshould allow environment-variable expansion such as${DATA_DIR}.