Factorizations¶
Versioned HiTOP structures show how stable core concepts are arranged and grouped within a specific model or publication.
Generated source · factorizations/*/v*/README.mdPurpose¶
The core ontology (ontology/hitop.rdf) is a kit of stable, reusable building blocks — Superspectra, Spectra, Subfactors, Components, Traits — plus the shared vocabulary used to compose them into a hierarchy. A factorization is a concrete, versioned composition of those blocks into one particular published structure. It never defines a new concept and never redefines what a core code means; it only records how an existing set of codes is ordered and grouped for one specific, citable model.
Catalog¶
| Factorization | Directory version | Status |
|---|---|---|
| HiTOP Working Model — v1 (V1052k) | v1 |
active |
| Emotional Dysfunction Superspectrum — v1 (V106mv) | v1 |
active |
| Externalizing Superspectrum — v1 (V108kx) | v1 |
active |
| Psychosis Superspectrum — v1 (V10749) | v1 |
active |
| DZPG Minimal Data Set — v1 (V10dzp) | v1 |
active |
| Bass-Ackwards Structure — v1 (V10bak) | v1 |
active |
How the model works¶
Each factorization's <version>_hierarchy.yaml file is a recursive tree that records parent-child order and the role each concept plays in that particular model. A kind: concept node references an existing core code with the same meaning, allowing equivalent local wording. A kind: partial node represents partial overlap with an existing core concept, using a required stable local id and an optional mapping_note to describe the overlap. A kind: collection node is a factorization-local grouping. level is always a free string, because the same concept can sit at a different level in different factorizations.
Read the specification Create a factorization
Diagrams¶
Every diagram renders as an icicle layout, one row per hierarchy level, colored by a single, factorization-wide palette rule. It is compiled straight from the same hierarchy YAML listed in the catalog above — scripts/generate_factorization_diagram_data.py validates it with the same logic as the test suite and writes the result into <version>_diagram.json, so a diagram can never drift from the data it represents.