Ontology evolution
The problem in one picture
Section titled “The problem in one picture”NIST publishes CSF 2.0. Suddenly:
- Your evidence links to CSF 1.1 controls might point to renamed/restructured concepts
- Your crosswalk to CIS v7 is now doubly stale (both sides updated)
- Your compliance posture documentation references a retired version
This is ontology evolution — the things you built your knowledge on have changed underneath you.
The three layers of the problem
Section titled “The three layers of the problem”Layer 1: The ontology changes
Section titled “Layer 1: The ontology changes”Real examples of what frameworks actually do when they update:
Each framework evolves differently:
| Framework | What changes | How it changes | How often | Machine-readable? |
|---|---|---|---|---|
| NIST CSF | Added GOVERN function, restructured subcategories | Major version, Excel crosswalk provided | ~5-10 years | Excel only |
| NIST 800-53 | Added 65 controls, 2 new families (PT, SR) | Major revision, comparison workbook | ~5-10 years | Excel only |
| MITRE ATT&CK | Techniques added/deprecated/revoked | Biannual, STIX 2.1 JSON changelogs | Every 6 months | Yes (STIX JSON) |
| CIS Controls | Safeguards consolidated, renumbered | Major version, no automated migration | ~3-4 years | No |
| CRI Profile | Diagnostic statements updated, mappings separated | Ad-hoc, mapping workbook | ~1-2 years | Excel only |
Layer 2: Crosswalks break
Section titled “Layer 2: Crosswalks break”When Framework A updates but the A↔B crosswalk doesn’t, every link through that crosswalk is suspect.
The crosswalk from CSF 1.1 → 800-53 was maintained by NIST OLIR. But OLIR is submission-based — someone has to manually update it. There’s no automatic staleness detection. See crosswalk staleness.
The pivot/interlingua solution: SCF’s STRM maps 175+ frameworks through one central hub. When one framework updates, only one mapping needs updating. See schema matching.
Layer 3: Your work breaks
Section titled “Layer 3: Your work breaks”Your link is now broken
Your evidence mapping work — the hours spent linking policies to controls — is at risk every time a framework updates.
The actors: who owns what
Section titled “The actors: who owns what”The ontology evolution problem involves distinct entities with different roles, incentives, and timelines:
The timing problem
Section titled “The timing problem”Each actor operates on a different timeline:
| Actor | Update cadence | Your notification |
|---|---|---|
| NIST (framework owner) | Every 5-10 years | Federal Register notice, months of public comment |
| MITRE (framework owner) | Every 6 months | Blog post, STIX JSON changelog |
| OLIR (mapping maintainer) | When someone submits an update | No notification — you discover staleness yourself |
| SCF (mapping hub) | When a framework they track updates | Release notes on their site |
| Your GRC team (consumer) | Continuous — evidence links added daily | You need to know when YOUR imported snapshot is stale |
The gap Crosswalker fills: No existing tool watches all these actors and tells you “your imported NIST 800-53 is now outdated, here’s what changed, and here’s which of your evidence links are affected.”
The relationship types
Section titled “The relationship types”Three distinct relationship types, each with different staleness risks:
- Ownership: Framework owner → framework. Stable until they publish an update.
- Mapping: Maintained by a THIRD PARTY (OLIR, SCF, or community). Can go stale independently of either framework.
- Consumption: YOUR work linking evidence to controls. At risk whenever ownership OR mapping changes.
What this means for Crosswalker
Section titled “What this means for Crosswalker”The EvolutionPattern taxonomy needs to track not just how a framework changes, but:
- Who maintains it (and how responsive they are to updates)
- Who maintains the crosswalks (OLIR? SCF? community? unmaintained?)
- What notification mechanisms exist (STIX JSON? Excel diff? nothing?)
- What’s your exposure (how many of your evidence links touch this framework?)
These are the progressive classification inputs — community pre-classified profiles capture this institutional knowledge so individual users don’t have to research it.
How to handle it: Slowly Changing Dimensions
Section titled “How to handle it: Slowly Changing Dimensions”The data warehouse community solved this decades ago with Slowly Changing Dimensions (SCD). These patterns apply directly:
aliases: [PR.AC-1]| SCD Type | What happens | When to use | Crosswalker implementation |
|---|---|---|---|
| Type 1 (overwrite) | Delete old, import new | Framework barely changed (patch/typo fix) | Simple re-import |
| Type 2 (keep history) | Both versions coexist in separate folders | Major version change | Version-tagged import folders |
| Type 3 (alias) | New notes have aliases pointing to old IDs | IDs renamed but concept unchanged | _crosswalker.previous_ids in frontmatter |
| Type 6 (hybrid) | History + alias + current flag | Most complete handling | Full metadata tiers |
Crosswalker’s default: Type 2 (version-tagged folders) + Type 3 (ID aliasing) — keep history, maintain link continuity.
The temporal dimension
Section titled “The temporal dimension”When multiple versions coexist, you need to track WHEN:
Crosswalker’s _crosswalker metadata tracks transaction time today (import_date). Adding framework_version and framework_date enables bitemporal queries: “show me our compliance posture as of date X against framework version Y.”
The translation analogy
Section titled “The translation analogy”Crosswalking is structurally like language translation:
The SCF STRM approach is the interlingua — map each framework to SCF once, get crosswalks to all 175+ others. When a framework updates, only one mapping needs maintaining.
Formal models
Section titled “Formal models”SKOS — the natural fit
Section titled “SKOS — the natural fit”SKOS (Simple Knowledge Organization System) maps directly to Crosswalker’s domain:
| SKOS | Crosswalker | Example |
|---|---|---|
ConceptScheme | A framework | NIST CSF 2.0 |
Concept | A control/technique | AC-2, T1078 |
broader/narrower | Hierarchy | Family → Control → Enhancement |
exactMatch | Exact crosswalk | CSF PR.AC-01 = 800-53 AC-2 |
broadMatch | Partial crosswalk | CIS 6.3 broadly covers AC-2 |
SKOS has a versioning gap (no built-in version tracking). skos-history partially addresses this.
SSSOM — mappings as data
Section titled “SSSOM — mappings as data”SSSOM represents crosswalk mappings as TSV/CSV with standardized columns — essentially what Crosswalker imports and exports. A natural export format.
SchemaVer — versioning for data
Section titled “SchemaVer — versioning for data”Where SemVer tracks API compatibility, SchemaVer tracks data compatibility:
| Component | Question | Framework example |
|---|---|---|
| MODEL | Can old data work with new schema? | ATT&CK sub-technique migration: no (IDs changed) |
| REVISION | Can new data work with old schema? | CSF adding GOVERN: no (new function) |
| ADDITION | Non-breaking additive change? | CIS fixing a typo: yes |
Expand-Migrate-Contract
Section titled “Expand-Migrate-Contract”Zero-downtime migration pattern from databases:
LLM-based matching
Section titled “LLM-based matching”Recent OAEI evaluations show LLM systems achieving 0.83-0.95 F1 on ontology matching benchmarks. Future: Crosswalker could use LLMs to suggest crosswalk mappings between arbitrary frameworks. See schema matching.
What Crosswalker does about all this
Section titled “What Crosswalker does about all this”The ontology lifecycle — specifically the Maintain phase — is where Crosswalker addresses evolution:
- EvolutionPattern taxonomy — classify how each ontology evolves (the spec being designed now)
- Migration strategy engine — given evolution pattern → recommended SCD type
- Metadata tiers — progressive
_crosswalkerenrichment for version tracking - Constraint enforcement — detect stale crosswalks, orphaned links, broken references
Resources
Section titled “Resources”Standards
Section titled “Standards”- NIST IR 8477 — Mapping Relationships Between Documentary Standards
- OWL 2 —
owl:priorVersion,owl:backwardCompatibleWith,owl:deprecated - SKOS — Simple Knowledge Organization System
- SSSOM — Simple Standard for Sharing Ontology Mappings
- OSCAL — Machine-readable security controls with SemVer
- STIX 2.1 — ATT&CK deprecation chains
- SchemaVer — Data compatibility versioning
- Dublin Core —
dcterms:replaces/dcterms:isReplacedBy
- Protégé — Ontology editor
- OAEI — Alignment evaluation
- LogMap — Ontology matching
- SCF STRM — Meta-framework mapping
- skos-history — Version tracking
Academic
Section titled “Academic”- Flouris et al., “Ontology change: classification and survey” (2008)
- Noy & Klein, “Ontology Evolution: Not the Same as Schema Evolution” (2004)
- Euzenat & Shvaiko, “Ontology Matching” (2013, Springer)
- Polleres et al., “How Does Knowledge Evolve in Open Knowledge Graphs?” (2023)
- Kimball & Ross, “The Data Warehouse Toolkit” — SCD patterns
Related pages
Section titled “Related pages”- Ontology diff primitives research — provably complete atomic operations for describing structural changes
- First principles: ontology change — structural primitives revisited
- User-first ontology maintenance — entity-aligned migration experience
- Primitives depth + pluggable layers — detection, decisioning, custom transforms
- EvolutionPattern taxonomy draft — the 8-field classification (under review)
- Framework versioning — how each framework handles updates
- Schema matching — matching algorithms and alignment
- Data model resilience — Crosswalker’s handling strategies
- Constraint enforcement — integrity patterns
- Framework crosswalks — crosswalk configuration
- Ontology lifecycle — the full lifecycle model
- What makes Crosswalker unique — the novel contribution
- Terminology — all terms and aliases
- Roadmap — Foundation phase priorities
- Terminology — definitions for all terms used here