Problem
The EU adapter and EUProcedure model contain implicit logic for how event types are classified (start, adoption, withdrawal) that is not documented anywhere accessible to users or contributors. This includes:
- Which event type codes map to which semantic category (start, adoption, withdrawal)
- The priority order when multiple terminal events exist (adoption takes precedence over withdrawal)
- How the RDF data mixes abbreviation codes (
ADP_FRM_byCONSIL) and French text labels (Adoption formelle par Conseil) for the same event type
- Whether any inference logic exists (e.g., if X is present but Y is missing, infer Z)
This was surfaced during work on end_event/duration (eda520c), where we empirically discovered missing codes (WDW_byCOM, APR_R1_byCONSIL, etc.) by cross-referencing 1000 RDF fixtures with EUR-Lex scraped validation data.
What should be documented
- The full mapping of event type codes to semantic categories, with their EUR-Lex English labels for readability
- Priority/precedence rules (e.g., adoption > withdrawal for
end_event)
- Any inference or fallback logic in the adapter layer
- How the dual code format (abbreviation vs French label) arises from the Cellar RDF data
- How researchers can verify or extend these mappings using the openbasement validation fixtures
Where
This could live in the EU case model docs page, a dedicated adapter docs page, or both. The current docs mention event type codes only in passing (models-guide.md line about "known event type codes").
Problem
The EU adapter and EUProcedure model contain implicit logic for how event types are classified (start, adoption, withdrawal) that is not documented anywhere accessible to users or contributors. This includes:
ADP_FRM_byCONSIL) and French text labels (Adoption formelle par Conseil) for the same event typeThis was surfaced during work on
end_event/duration(eda520c), where we empirically discovered missing codes (WDW_byCOM,APR_R1_byCONSIL, etc.) by cross-referencing 1000 RDF fixtures with EUR-Lex scraped validation data.What should be documented
end_event)Where
This could live in the EU case model docs page, a dedicated adapter docs page, or both. The current docs mention event type codes only in passing (
models-guide.mdline about "known event type codes").