🌀
← Back to Articles & Artefacts
artefactswest

RISE Specification: Ontology Bridge Layer

IAIP Research
iaip-dsl-lsp

RISE Specification: Ontology Bridge Layer

Desired Outcome

The DSL server's concept registry is structurally compatible with the medicine-wheel-ontology-core type system, enabling:

  • Concepts to be expressed as RelationalNode instances
  • Relationships to carry typed Relation semantics
  • OCAP governance flags to travel with every concept
  • Bidirectional interoperability: the DSL server can consume iODK-generated artifacts and produce artifacts that iODK pipelines can validate

Current Reality

  • Concept registry uses a custom YAML schema with ad-hoc fields
  • medicine-wheel-ontology-core defines RelationalNode, Relation, OcapFlags, CeremonyLog, NarrativeBeat as canonical types (published npm packages)
  • No formal alignment exists between the DSL concept schema and the ontology core types
  • iODK proposes generating OWL/SHACL/JSON-LD from TS types; the DSL server has no export capability

Structural Tension

Between a concept registry that is semantically rich but structurally isolated, and one that participates as a first-class ontology citizen in the medicine-wheel ecosystem.

Key Features

1. Concept-to-RelationalNode Mapping

Each concept in concept-registry.yaml maps to a RelationalNode:

```python

Pydantic model aligned with medicine-wheel-ontology-core

class ConceptNode(BaseModel): """Maps to RelationalNode from medicine-wheel-ontology-core""" id: str # e.g., "creative-orientation" name: str # e.g., "Creative Orientation" node_type: NodeType # CONCEPT | PRACTICE | KNOWLEDGE_SYSTEM category: str # Framework | Feeling/Capacity | Knowledge System | Integration definition: str direction: Direction # EAST | SOUTH | WEST | NORTH | CENTER

# Relational
related_concepts: list[str]       # IDs of related concepts
relationships: list[TypedRelation]  # Typed edges

# Indigenous Knowledge Integration
indigenous_connections: IndigenousConnections

# OCAP Governance
ocap: OcapFlags                   # ownership, control, access, possession

# Provenance
sources: list[str]
usage_contexts: list[str]
examples: list[str]

# Ontology metadata
ceremony_born: Optional[str]      # CeremonyLog ID if concept emerged from ceremony
wilson_alignment: Optional[float] # 0.0-1.0 score from computeWilsonAlignment

class NodeType(str, Enum): CONCEPT = "concept" PRACTICE = "practice" KNOWLEDGE_SYSTEM = "knowledge_system" FEELING = "feeling" PRINCIPLE = "principle" CEREMONY = "ceremony"

class Direction(str, Enum): EAST = "east" # Nitsáhákees - Thinking & Beginnings SOUTH = "south" # Nahat'á - Planning & Growth WEST = "west" # Iina - Living & Action NORTH = "north" # Siihasin - Assurance & Reflection CENTER = "center" # Central Fire

class TypedRelation(BaseModel): """Maps to Relation from medicine-wheel-ontology-core""" source_id: str target_id: str relation_type: RelationType direction: Optional[Direction] weight: float = 1.0 narrative_context: Optional[str] # Why this relationship matters

class RelationType(str, Enum): FOUNDATIONAL = "foundational" # A is foundational to B COMPLEMENTARY = "complementary" # A and B complement each other ENABLES = "enables" # A enables B CONTEXTUALIZES = "contextualizes" # A gives context to B CEREMONIAL = "ceremonial" # A has ceremonial implications for B STEWARDS = "stewards" # From RSIS: A stewards B SERVES = "serves" # From RSIS: A serves B GIVES_BACK_TO = "gives_back_to" # From RSIS: reciprocity BORN_FROM = "born_from" # From RSIS: emerged from ceremony KINSHIP_OF = "kinship_of" # From RSIS: kinship relation

class IndigenousConnections(BaseModel): two_eyed_seeing: Optional[str] polycentric: Optional[str] relational: Optional[str] ceremonial: Optional[str]

class OcapFlags(BaseModel): """Maps to OcapFlags from medicine-wheel-ontology-core""" ownership: str = "community" # Who owns this knowledge control: str = "steward" # Who controls access access: str = "open" # open | restricted | ceremony_required possession: str = "shared" # How knowledge is held ```

2. Export Pipeline

Generate interoperable artifacts from the concept registry:

``` concept-registry.yaml ↓ (loader.py) In-memory ConceptNode instances ↓ (export.py) ├─ concept-registry.json # Fast-load index ├─ concept-registry.schema.json # JSON Schema for validation ├─ concept-registry.owl # OWL ontology (via rdflib) ├─ concept-registry.shacl.ttl # SHACL shapes for constraint checking └─ concept-registry.jsonld # JSON-LD for linked data consumers ```

3. iODK Pipeline Compatibility

The export pipeline produces artifacts that an iODK QC pipeline can validate:

  • JSON Schema validates structure
  • SHACL shapes check relational completeness (every concept has ≥3 relations)
  • SHACL shapes check OCAP completeness (every concept has all 4 OCAP flags)
  • SHACL shapes check directional balance (concepts span all 4 directions)
  • SHACL shapes check Indigenous knowledge completeness (all 4 lenses present)

4. Bidirectional Sync

When iODK evolves the ontology:

  • New types added to medicine-wheel-ontology-core are reflected in the DSL server's type system
  • Schema changes trigger a ceremony-aware review before the DSL server adopts them
  • The DSL server can contribute new concepts back to the ontology via a proposal mechanism

Success Metrics

  • Every concept in the registry validates against the ConceptNode pydantic model
  • JSON Schema export passes ajv validation against medicine-wheel-ontology-core contracts
  • OWL export is parseable by Protégé and owl-api
  • SHACL shapes catch at least 5 types of relational incompleteness
  • Export pipeline runs in <2 seconds for 50 concepts
  • Type alignment is documented and testable

Dependencies

  • pydantic for type modeling
  • rdflib for OWL/SHACL/JSON-LD generation (optional dependency)
  • pyyaml for YAML loading
  • medicine-wheel-ontology-core type definitions as reference (not runtime dependency)