Terminology

Edge model at a glance

Crosswalker has two kinds of edges. Both have Foundation-committed architectures. Disambiguating them is the point of this page.

Crosswalk

Ontology ↔ Ontology

”These two concepts correspond at such-and-such confidence.”

subject_id: NIST-800-53/AC-2 predicate_id: strm:subset-of ← STRM object_id: ISO-27001/A.9.2.1 confidence: 0.85 ← SSSOM mapping_justification: …

Committed architecture: STRM 5-relationship vocabulary in the predicate_id slot + SSSOM metadata envelope. SKOS rejected as base. See the 04-10 synthesis §edge semantics.

Evidence link

Document → Ontology

”This document implements this control at such-and-such status.”

link_type: evidence-control evidence: "MFA-Policy" control: "NIST--AC-2" status: implemented ← OSCAL reviewer: "Jane-Auditor" # + 8 more fields

Committed architecture: Junction notes — one markdown file per edge with a 13-field flat-YAML schema isomorphic to OSCAL’s by-component. See Challenge 07.

Ontology concept (framework control, spine node)User-authored document (evidence note)

Core terms

Term	Definition
Ontology	A structured representation of knowledge — categories, relationships, and rules
Framework	A specific ontology (NIST 800-53, CIS Controls, etc.)
Crosswalk	A mapping between concepts in two structured ontologies — showing how elements in one correspond to elements in another. Examples: NIST 800-53/AC-2 ↔ ISO 27001/A.9.2.1 (framework-to-framework), NIST AC-2 → SCF/canonical-AM-01 (framework-to-synthetic spine). Crosswalks are a specific kind of edge where both ends are ontology concepts. Distinct from evidence links (see below), which connect user-authored documents to ontology concepts. For the technical vocabulary and metadata envelope Crosswalker commits to for crosswalk edges, see STRM + SSSOM. For the architectural pattern, see the schema matching interlingua / pivot approach.
Evidence link — also: implementation link, junction note (storage shape), typed link (evidence case), edge metadata (evidence case), link metadata, dotKey metadata (legacy)	An edge from a user-authored document to an ontology concept — e.g., MFA-Policy.md → NIST 800-53/AC-2 with properties like status: implemented, confidence: 0.85, reviewer: Alice, review_date: 2026-04-10. Not a crosswalk. The semantic is “this document demonstrates/implements this control at such-and-such status,” not “these two concepts correspond.” Foundation direction committed (pending formal lock-in of open sub-decisions): stored as junction notes (one markdown file per edge) with a 13-field flat-YAML schema isomorphic to OSCAL’s by-component assembly. Three orthogonal status dimensions: status (5 OSCAL values) + freshness (4 computed values) + evidence_type (8 values). Git history is the audit trail. See the 2026-04-10 evidence-link edge model synthesis log for the full decision, Challenge 07 for the research brief, and the roadmap evidence-link edge model item for the commitment tracking + open sub-decisions. The original link metadata system inline-Dataview syntax is superseded by the junction note approach.
Hierarchy column	A data column that defines folder nesting levels
Frontmatter	YAML properties at the top of a markdown note
Typed link	A link with metadata describing the relationship type. Umbrella term that covers both crosswalks and evidence links as specific sub-kinds.
Fingerprint	A hash of a data file’s structure used for config matching

Data flow terms

Term	Definition
ParsedData	The intermediate format after parsing a file (columns + rows)
ColumnInfo	Analysis of a single column (type, unique count, samples)
CrosswalkerConfig	Full import configuration (column mappings, output settings)
SavedConfig	A persisted configuration with fingerprint for reuse
GeneratedNote	The output structure before writing to disk

Framework terms

Term	Example
Control family	AC (Access Control) in NIST 800-53
Control	AC-2 (Account Management)
Enhancement	AC-2(1) (Automated System Account Management)
Safeguard	CIS Controls equivalent of a control
Technique	T1059 (Command and Scripting Interpreter) in MITRE ATT&CK
Diagnostic statement	CRI Profile’s equivalent of a control — a testable assertion
Informative reference	NIST’s term for a crosswalk mapping between frameworks

Ontology evolution terms

These come up throughout the ontology evolution and framework versioning pages.

Term	Definition
Ontology evolution	How a structured knowledge system changes over time — adding, removing, or restructuring concepts. Distinct from ontology versioning (tracking which version you have). More
Schema evolution	Changes to the structure of data (adding fields, renaming columns) as opposed to changes to the data itself
Deprecation chain	A sequence of revoked-by relationships linking old concepts to their replacements. MITRE ATT&CK uses STIX 2.1 for this — when technique T1234 is deprecated, the chain says “replaced by T5678.” More
SemVer	Semantic Versioning (MAJOR.MINOR.PATCH). OSCAL uses this with a guarantee: content created under a MAJOR version remains valid in later releases within that major. More
SchemaVer	MODEL-REVISION-ADDITION versioning for data (from Snowplow). MODEL = can old consumers read new data? REVISION = can new consumers read old data? ADDITION = non-breaking new fields. More
SCD (Slowly Changing Dimensions)	Data warehouse pattern for handling records that change over time. Type 1 = overwrite, Type 2 = keep history (version-tagged folders), Type 3 = add alias column, Type 6 = hybrid. More
SKOS	Simple Knowledge Organization System (W3C). Natural fit for frameworks: ConceptScheme = framework, Concept = control, broader/narrower = hierarchy, exactMatch = crosswalk. The 5-predicate baseline vocabulary (exactMatch/closeMatch/broadMatch/narrowMatch/relatedMatch) — found insufficient for compliance crosswalks in the 04-10 synthesis (no confidence, provenance, or negation). Registry entry · More in schema matching
SSSOM	Simple Standard for Sharing Ontological Mappings (Matentzoglu et al. 2022). The row-schema envelope for crosswalk edges: mandatory mapping_justification + optional confidence, author_id, mapping_date, mapping_tool, predicate_modifier for negation. Predicate-agnostic (you choose the vocabulary for predicate_id — see STRM). Crosswalker’s candidate edge metadata model. Registry entry · Schema matching
STRM — Set Theory Relationship Mapping	The 5-relationship edge vocabulary — equivalent-to, subset-of, superset-of, intersects-with, no-relationship — that NIST IR 8477 (Feb 2024), SCF’s STRM bundle, and OSCAL’s Control Mapping Model independently converged on. Crosswalker’s candidate predicate_id vocabulary (paired with SSSOM as the envelope). Fills the gaps SKOS leaves open. Registry entry · NIST OLIR formal relationship types · Foundation decision
OSCAL	Open Security Controls Assessment Language (NIST). Machine-readable format for security controls with built-in versioning. Also adopts STRM relationships in its emerging Control Mapping Model. Registry entry · More
OLIR	Online Informative References (NIST). Submission-based crosswalk registry with formal relationship types (Subset, Intersects, Equal, Superset, Not Related). Uses the same STRM vocabulary NIST IR 8477 formalized. Registry entry · Formal relationship types
Interlingua / pivot — also: pivot ontology, synthetic spine, hub-and-spoke mapping, meta-framework	A “universal framework” that others map through — like a pivot language in translation. SCF’s STRM is this for compliance: map to SCF once, get crosswalks to 175+ frameworks. These five terms all describe the same architectural pattern from different disciplines (translation theory, information integration, GRC practice). Open Foundation question — see Challenge 06 and the 04-10 synthesis spine section. Schema matching: interlingua / pivot approach

Architecture & evolution primitives

These terms emerged from the Foundation phase research. Each has aliases that appear across the knowledge base.

Term	Aliases	Definition
Ontology diff primitives	Graph change atoms, structural change primitives, structural diff engine	The 9 provably complete atomic operations for describing what changed between two versions of a labeled directed graph. The mathematical foundation — “what changed?” Based on graph edit distance (Bunke 1983) and algebraic graph transformation (Ehrig 2006).
EvolutionPattern	Framework handling profile, stewardship profile, evolution taxonomy	Per-framework classification of how an ontology evolves. Sets defaults for handling strategies. Open question: may be replaced or complemented by transformation recipes. Original draft
Transformation recipe	Version transition map, migration spec	The actual record of what changed between specific versions of a framework and how to handle each change. E.g., “NIST r5→r6: AC-19(2) merged into AC-19, AC-24 added.” May replace or complement EvolutionPattern.
Handling strategy	—	What to do when a specific change type is detected: overwrite, archive, alias, merge, split, skip, or flag for review.
Decisioning	Strategy selection	The process of selecting handling strategies per change type. Can be default (from primitives), per-framework (from EvolutionPattern), or per-user/org (custom overrides). Layered model
Pluggable layer	Extension point, opinionated layer	Any system behavior that is opinionated and swappable rather than first-principles. Detection, decisioning, and custom transforms are all pluggable. Keeps the system “tight to first principles while allowing extension of opinionation.”
Progressive depth	Progressive complexity	Design principle: start with guided UI, graduate to config-as-code, add CLI. Each interface wraps the same core primitives. Applies to both import and migration workflows.
Entity	User, agent	Any actor utilizing the system — agents or people. The system must be efficacious for all entity types.

Data model terms

These appear in the file-based graph database and consistency models pages.

Term	Definition
Property graph	A graph where both nodes and edges carry key-value properties. Obsidian vaults are property graphs: notes = nodes, WikiLinks = edges, frontmatter = properties. More
Edge metadata — also: link metadata, typed link metadata, inline field metadata, dotKey metadata	Structured data attached to a relationship (link) between two notes, not to the notes themselves. The umbrella data-model concept behind both crosswalks and evidence links. Original design: link metadata system (superseded — see its caution callout). Both edge categories now have committed directions: crosswalks use STRM + SSSOM (ontology↔ontology, set-theory predicates + provenance envelope), evidence links use junction notes with a 13-field flat-YAML schema (document→control, OSCAL by-component isomorphic).
Denormalization	Deliberately duplicating data to speed up reads at the cost of write complexity. When Crosswalker stores both forward links and frontmatter arrays, that’s denormalization. More
Materialized view	Pre-computed query results stored for fast access. Dataview/Bases queries over vault files are materialized views — they compute on each query, never getting stale.
Referential integrity	A guarantee that all references (links) point to existing targets. Obsidian vaults have NO referential integrity — you can delete a note and leave broken WikiLinks everywhere. More
ACID	Atomicity, Consistency, Isolation, Durability — database transaction guarantees. File-based systems only provide Durability. More
CAP theorem	A distributed system can provide at most two of: Consistency, Availability, Partition tolerance. Obsidian vaults are AP systems (available + partition-tolerant, not strongly consistent). More
Eventual consistency	Given enough time, all copies of data converge to the same state. In Crosswalker: re-import achieves consistency, but it requires manual action. More
Event sourcing	Storing the sequence of changes (events) rather than just the current state. The _crosswalker.history field (future) would enable this. More

Matching & alignment terms

From the schema matching page.

Term	Definition
Schema matching / schema alignment / ontology matching / ontology alignment / crosswalking / data integration / framework mapping	Not separate things — all names for the same broad concept. Finding correspondences between elements of different structured datasets. Each name comes from a different discipline: schema matching = database community (Rahm & Bernstein 2001), ontology matching/alignment = Semantic Web (Euzenat & Shvaiko 2013), crosswalking = library science (Woodley 2008), data integration = ETL/warehousing, framework mapping = GRC practitioners. Within a single field the terms have precise distinct meanings (see terminology distinctions table), but Crosswalker straddles all these fields — which name you see on any given KB page depends on which community that page is drawing from. Aliases callout on schema-matching page
Schema matching (narrow sense)	Database-community term: finding corresponding elements (columns, fields, keys) between schemas. Output is a set of element pairs. Crosswalker’s column-type detection is a simple example.
Schema mapping (narrow sense)	The executable transformation that implements a match — “split Column A by comma, map each to Column B.”
Ontology alignment (narrow sense)	Semantic-web term: finding corresponding concepts between ontologies with confidence scores. Output is an “alignment” (set of correspondences). When NIST says “AC-2” corresponds to CIS “5.2 at 0.85 confidence,” that’s ontology alignment.
Ontology merging	Combining two ontologies into one unified ontology. SCF combining 175+ frameworks into a single canonical set is an example.
Crosswalk edge semantics stack	Crosswalker-specific term for the layered commitment: STRM as the required predicate_id vocabulary + SSSOM as the required metadata envelope + SKOS rejected-as-base but kept as an export format via the YAML-LD bridge. Foundation decision · Roadmap pillar
OAEI	Ontology Alignment Evaluation Initiative — annual competition benchmarking alignment algorithms. Recent LLM-based systems achieve 0.83-0.95 F1 scores. More
Formal Concept Analysis	Lattice theory approach to finding structural correspondences between concept hierarchies without relying on string similarity. Candidate mechanism for spine distillation. More

Metadata ecosystem terms

From the metadata ecosystem page.

Term	Definition
Inline field	Dataview syntax: key:: value in note body. Only queryable by Dataview (and potentially Datacore), NOT by Obsidian Bases.
Properties	Obsidian’s native YAML frontmatter system (since v1.4). First-class, queryable by Bases and Dataview.
Obsidian Bases	Native database views (.base files). Tabular only — can query frontmatter but CANNOT traverse typed links or query inline fields. More
Datacore	Community successor to Dataview (in development). Different API, better performance.