Clarify purpose of hierarchy, consider a more general relationships construct to complement it.

[mindsocket]

Status: WIP on extending hierarchy to support a "layered DAG" construct. More general relationships approach for non-hierarchy rels TBD

Schema metadata includes a 'hierarchy' attribute, used for hierarchy validation.

I think this basically serves as an optional convenience to get hierarchy validation automatically, but schemas generally don't depend on it.

A more graph-based schema (or hybrid with partial hierarchy) in theory should also work, but the onus is currently on the schema maintainer to enforce those relationship rules another way.

It might make sense to also allow expression of relationships with corresponding automatic validation.

Will need to think about how relationships are expressed in markdown and in schema. A simple start might be to write some jsonata rules that are parameterized, which could be generally useful or render the need for a specific relationships spec unnecessary

[mindsocket]

While more general relationships are good to think about, the more proximate opportunity is to expand from a hierarchical tree to a hierarchical/layered DAG. https://g.co/gemini/share/5ff3bbec3ffb

In short, we keep the hierarchy concept, add a way to specify, express, validate and visualise the layers that have many to many relationships.

Specify:

• hierarchy array (existing)
• a way to indicate per node type pair which ends specifies (parents specify array of children or children specify array of parents), and field name

Express: single wikilink or array matching above

Validate: ensure resolved nodes models and accurately reflects (I'm thinking it should normalise children refs to parent refs on child nodes); ensure we only read relationships as specified ( if expecting children don't allow parents on the other end)

Visualise: ok for Miro, show command may need a dag based format instead of bullets, or to denormalise.

[mindsocket]

Reviewing the collection of modelling issues, here are some observations:

Scope Overlaps & Gaps:

• Issues 5, 6, 7, 8, 17, 31 collectively explore schema extensions and relationship constructs
• Some overlap between Clarify purpose of hierarchy, consider a more general relationships construct to complement it. #31 (general relationships) and Schema composability: shared building blocks and team-composed schemas #17 (schema composability)
• Gap: Missing consideration for temporal relationships (how things evolve over time)

Suggestions:

1. Consolidate Consider more opinionated sub-entities - problem statement, risk, assumption, insight, decision, principle #5, Integrate with other systems of work? #6, Cross-space references: linking entities across schemas and spaces #8 under a 'schema extensions' umbrella - they're all about extending the basic model
2. Clarify that Clarify purpose of hierarchy, consider a more general relationships construct to complement it. #31 is about graph relationships (DAGs, multi-parent) while Schema composability: shared building blocks and team-composed schemas #17 is about schema composition
3. Consider adding a new issue for 'temporal relationships' to capture evolution of entities
4. The modelling scope feels appropriate but could benefit from clearer separation between:

• Static schema composition (Schema composability: shared building blocks and team-composed schemas #17)
• Dynamic relationship definitions (Clarify purpose of hierarchy, consider a more general relationships construct to complement it. #31)
• Entity typing and specialisation (Consider more opinionated sub-entities - problem statement, risk, assumption, insight, decision, principle #5, Cross-space references: linking entities across schemas and spaces #8)

[mindsocket]

This issue may also depend on #33 (Support full cross-schema resolution of refs) - if we want relationships to reference schema definitions across files, we'll need full cross-schema resolution first.

[mindsocket]

Most of this has been address in #52 . New issues cover potential refactor and extension to ways of supporting relationships.