Link metadata system

Also known as — aliases across this KB

The same concept appears under several names depending on which angle you’re looking at:

• Link metadata system — this page’s name; the most general umbrella
• Edge metadata — the technical data-model term (terminology entry)
• Typed link system — the product-level term; a link with a type + metadata (terminology entry)
• Evidence-link edge model — the Foundation-phase decision name; specifically about document→framework implementation links (terminology entry: Evidence link)
• Inline field metadata — the Dataview/Datacore-flavored term (legacy; we’ve committed to Obsidian Bases, not Dataview)
• DotKey metadata — this page’s own internal term (framework_here.applies_to::)
• Implementation link — the OSCAL-adjacent framing, referring to its Implementation Layer (by-component, implementation-status, satisfied)

All of these point at the same core idea: a link between two notes that carries structured data about the relationship, not just the endpoints. Crosswalker’s original motivation was this problem (before the ontology-to-ontology crosswalking story was added in the Foundation phase). Its current status is an open Foundation research item — see Challenge 07: Link metadata / edge model for evidence mapping and the Foundation roadmap.

This page is SUPERSEDED by the 2026-04-10 evidence-link synthesis

This page’s inline-Dataview design is no longer Crosswalker’s committed direction. Read it as historical context only.

The original design below relied on Dataview inline fields (framework_here.applies_to:: [[AC-2]] {JSON} syntax) as the storage and query mechanism. Crosswalker has since committed to Obsidian Bases as the viewing/querying layer — Bases cannot process inline fields, only flat-YAML frontmatter. That constraint (plus Bases’ hard limits on nested objects and arrays of objects) eliminated every inline approach.

The committed direction is junction notes — one markdown file per edge, with a 13-field flat-YAML schema, isomorphic to OSCAL’s by-component assembly. Two research sessions on 2026-04-10 independently converged on this architecture; the synthesis log carries the full decision with the proposed schema, three-dimensional status vocabulary, git-based audit trail, and OSCAL round-trip mapping.

What’s still useful on this page:

• The conceptual framing of “edges carry metadata, not just endpoints” remains correct
• The dotKey + destination + metadata conceptual shape inspired the junction note schema’s relationship between the link_type discriminator, evidence / control wikilinks, and the metadata fields
• The five-level priority hierarchy is no longer relevant (one junction note = one edge, no priority resolution needed)

Where to read next:

• 2026-04-10 evidence-link edge model synthesis — the committed direction with the proposed schema
• Challenge 07: Link metadata / edge model — the fresh-agent research brief this resolved
• Terminology: Evidence link — canonical definition with aliases
• Roadmap: Evidence-framework edge model — commitment tracking + 7 open sub-decisions

This page is preserved as the original design record because it captures the motivating problem and the first attempt at a solution — essential context for anyone wondering “why junction notes” or “what was tried before.” The rest of the page below is the historical design text.

The core problem

Traditional markdown links only store a destination. You can link to AC-2.md but you can’t express why — is it evidence? An implementation? A review? Crosswalker’s future link system encodes metadata about relationships, not just the relationships themselves.

Edge metadata

Edge metadata is additional information stored about a link between two notes:

• A dotKey (e.g., framework_here.reviewer) naming the relationship type
• A value — boolean, string, or JSON object with richer details
• A destination — WikiLink or markdown link to the target note

Syntax examples

# Boolean (implied true)
framework_here.applies_to:: [[AC-2]]

# String value
framework_here.reviewer:: "Alice"

# JSON metadata
framework_here.applies_to:: [[AC-2]] {"sufficient": true, "reviewer": "Alice"}

# Markdown link style
framework_here.applies_to:: [AC-2](path/to/AC-2.md) {"status": "complete"}

# Wrapped (hidden in Obsidian reading view)
[framework_here.applies_to:: [[AC-2]]]
(framework_here.applies_to:: [[AC-2]] {"sufficient": true})

Dot notation use cases

The dot notation in framework_here.applies_to serves three purposes:

1. Default value for outgoing links — sets a default that applies to all links from this note
2. Boolean flag — when no JSON follows, the relationship is implicitly true
3. Object default — when JSON follows without a link, sets default properties for all links of that type

Priority structure

When edge metadata appears in multiple places (frontmatter, inline tags, folder attributes), a priority hierarchy resolves conflicts:

Priority	Source	Example
1 (highest)	Inline tag + link + JSON	type:: [[Target]] {"key": "val"}
2	Inline tag + link (implied boolean)	type:: [[Target]]
3	Inline tag (child/leaf) + link + JSON	Nested folder context
4	Inline tag (parent/root) + link + JSON	Parent folder context
5	Inline tag without link + value	type:: "default_value"
6	YAML frontmatter	type: value in frontmatter
7 (lowest)	Folder-level defaults	Inherited from parent folder

Regex parsing

The system uses regex to extract structured data from inline link syntax:

framework_here.applies_to:: [[ID 12]] {"sufficient": true, "control": true}

Captured groups:

• dotKey: framework_here.applies_to
• destination: [[ID 12]] (WikiLink), [ID 12](path.md) (markdown), or plain text
• metadata: {"sufficient": true, "control": true} (JSON) or "quoted value"

Query levels

Relationships can be queried at different hierarchical levels:

Leaf-level query

At a specific framework node (e.g., AC-2.md), find all notes that link to it with their metadata.

Folder-level query

Aggregate all inbound links for an entire folder (e.g., all Access Control family controls), merging or grouping results.

Global query

Search the entire vault for any note linking to any part of the framework, producing a compliance-wide view.

Relationship aggregation

When multiple notes link to the same framework node, their metadata must be aggregated:

• A single control might be referenced by 5 evidence notes, each with different reviewers and coverage levels
• The aggregation uses the priority structure to merge conflicting values
• Output can be nested (JSON/YAML), tabular, or pivoted by category

Current implementation status

The link metadata system is designed but not yet implemented in the Crosswalker plugin. The current MVP focuses on importing structured data. The link system is planned for Phase 2 — see the roadmap.

The Python tool (frameworks_to_obsidian.py) generates basic WikiLinks between framework nodes. The plugin will eventually support the full typed-link syntax described here.

For the complete syntax reference including wrapping styles, link types, the production regex, and the two-tier priority system, see the link metadata syntax specification.

Ecosystem compatibility

The typed-link syntax relies on Dataview inline fields. The Obsidian metadata ecosystem is evolving:

Component	Properties (native)	Dataview	Bases (native)	Datacore
Frontmatter queries	Read only	Full	Full + formulas	Full
Inline field queries	No	Yes	No	TBD
Edge metadata extraction	No	Via DataviewJS	No	TBD
Tabular display	No	TABLE queries	Native views	TBD

Bases limitation

Obsidian Bases is tabular-only — it can query frontmatter properties but cannot process inline fields, traverse typed links, or extract edge metadata. DataviewJS (or future Datacore) is required for relationship-level queries.

Design principle: Store all non-link metadata as YAML frontmatter (queryable everywhere). Reserve inline fields for typed-link edge metadata only (requires Dataview/Datacore).