-
Notifications
You must be signed in to change notification settings - Fork 2
Limitation Inverse Edges Missing
type: synthesis up: "Typed-Edges-and-Frontmatter" criticizes: "Typed-Edges-and-Frontmatter" tags: [limitation, edges, schema]
The SCHEMA defines typed edges (extends:, supports:, criticizes:, etc.) but does not declare their inverses. As a result, when the agent adds a back-reference, it tends to degrade specific edge types to the fallback related:. Filed as GitHub issue #3 against the template repository, surfaced by behavioral testing during PR #4.
Page A declares supports: "[[Page-B]]". The agent then visits Page B to add a back-reference. The natural inverse would be supported-by:, but no such edge type exists in the SCHEMA. The agent's safest choice is related: "[[Page-A]]", which loses the semantic distinction the original supports: edge encoded.
Over time, related: accretes in the wild, and the typed-edge ontology weakens.
The SCHEMA's "Edges as Interface Operations" section would grow a small inverses table:
| Forward | Inverse |
|---|---|
extends: |
extended-by: |
supports: |
supported-by: |
criticizes: |
criticized-by: |
source: |
(no inverse; sources are external) |
up: |
(no inverse; children are implicit) |
And the operation contracts would say: "when adding a back-reference, use the declared inverse, not related:."
The Knowledge-Graph-Pipeline would need to know about the inverse pairs too, so a query for "what supports X" returns the same set whether the data was filed forward or inverted. SPARQL supports this natively via owl:inverseOf declarations on the predicates.
Priscila explicitly flagged this as a separate concern when surfacing it: it is unrelated to the attribution work in PR #4, and a clean fix wants its own PR plus structural/behavioral tests against fresh projects. It is filed and waiting.
Open issue #3 against crcresearch/llm-wiki-memory-template. Not yet implemented.