Support MLIT Data Platform

[UchidaMizuki]

https://www.mlit-data.jp/

[UchidaMizuki]

Research notes as of 2026-07-20:

After reviewing the MLIT Data Platform API docs (Data Structure, Data Attributes), this API follows a DCAT-style catalog/search model (catalog → dataset → data, where each "data" item is a discrete real-world record, e.g. a construction project) rather than the statistical cube model (SDMX / RDF Data Cube Vocabulary — observations sliced along enumerable dimensions like region × time × category) that e-Stat's getMetaInfo/getStatsData use.

The common attributes are limited to search/discovery metadata (title, location, prefecture code, dates) — there's no equivalent to e-Stat's CLASS_OBJ (an enumerable code list per dimension). The docs explicitly state that per-system metadata is not documented centrally; dataset-specific attributes are just field name/type schema definitions, not controlled-vocabulary axes.

jpstat's navigatr-based design assumes a "fetch metadata → pick axis values → fetch data" UX. This is the same reason reinfolib was removed in #12 (didn't fit the metadata-driven UI). For the same structural reason, integrating MLIT Data Platform into jpstat as an axis-selection interface doesn't seem worthwhile.

The mlitdata package already implements mlitdata_catalog() (catalog/dataset/attribute metadata) and mlitdata_all() (record search via attribute_filter/location_filter), so the better path is probably to keep mlitdata as an independent, search-style API wrapper rather than folding it into jpstat.

(Fuller writeup in my local notes: "Statistical cube model vs. DCAT catalog model")