🌀
← Back to Articles & Artefacts
artefactswest

IAIP-Ontology-dev-kit-0c258333-8b60-40c0-bc0f-39f8231c8198--260221

IAIP Research
iaip-ontology-dev-kit-0c258333-8b60-40c0-bc0f-39f8231c8198
<img src="https://r2cdn.perplexity.ai/pplx-full-logo-primary-dark%402x.png" style="height:64px;margin-right:32px"/>

IAIP-Ontology-dev-kit-0c258333-8b60-40c0-bc0f-39f8231c8198--260221

Attached are context for getting you up to date on previous thread and what you produced and also give you the full Shawn Wilson Research is Ceremony text.

"The Ontology Development Kit (ODK)" repo: https://github.com/INCATools/ontology-development-kit seems to contain interesting content that we could fork and derive/extend for our own system based on obviously a different way of thinking.

You also have anothe attempt at using in our forked repo: "RSIS-GitNexus" the CONTENT.md that the other thread as contributed at creating and is reviewing and probably suggest changes...

This thread here would do a quick (but complete) literature review of what is related to "The Ontology Development Kit (ODK)" repo (ex. Database, Volume 2022, 2022, baac087, https://doi.org/10.1093/database/baac087) so we have few paragraphs that are grounded in academic of other domains.

The next part would envision using what they build in 'https://github.com/INCATools/ontology-development-kit' to fork it and make our own 'indigenous-ontology-development-kit' that maybe the "RSIS-GitNexus" would use or that woul be a complete separated experiment, you will evaluate and direct us toward that.

Published abstracted packages

  • that we can use or create parity in other languages (if required)

``` https://www.npmjs.com/package/medicine-wheel-ontology-core https://www.npmjs.com/package/medicine-wheel-relational-query https://www.npmjs.com/package/medicine-wheel-narrative-engine https://www.npmjs.com/package/medicine-wheel-graph-viz https://www.npmjs.com/package/medicine-wheel-ui-components https://www.npmjs.com/package/medicine-wheel-ceremony-protocol ```

Do not use the word 'comprehensive' in your output, just output results.

An Indigenous Ontology Development Kit (iODK) can use the same lifecycle patterns as the Ontology Development Kit (ODK)—templated repos, automated QC and release pipelines—but center Indigenous relational paradigms, OCAP, and medicine‑wheel structures, with RSIS‑GitNexus as one key consumer rather than the only one.12

What ODK is doing in the literature

ODK is framed in recent biomedical ontology work as an opinionated toolkit for building, maintaining, and releasing OWL/RDF ontologies with shared workflows across a family of related projects. It standardizes repository layout, dependency management, QC steps, and release artefacts so that ontologies can co‑evolve in a predictable way rather than each project improvising its own scripts.2

The literature around ODK and similar stacks emphasizes several recurring themes: automated quality checks (domain/range, coherence, missing labels), reproducible builds, and clear versioning and migration guidance for consuming systems. These practices arose in contexts like clinical informatics and biomedical knowledge integration, where many independent ontologies must interoperate and tools need reliable assumptions about identifiers, axioms, and release cycles.12

Related ontology engineering toolchains

The RSIS‑GitNexus content already points at ODK as part of a broader ecosystem of ontology toolkits and release infrastructures. Concrete examples include:2

  • Ontology QC and workflows in clinical/industrial ontologies (e.g., OWL/SHACL‑based checks, GitHub Actions pipelines, dual‑model mappings between conceptual models and physical storage).12
  • Reusable SDKs that expose ontology concepts as typed APIs (e.g., ontology-ts-sdk in the JS/TS world), allowing application code to treat ontology entities and constraints as strongly‑typed objects rather than ad‑hoc strings.2
  • mOWL and related ontology‑aware ML libraries, which use OWL graphs as background knowledge for embeddings and reasoning‑aware features.2

Across these, the shared pattern is: a central ontology or set of ontologies, a release/CI pipeline that enforces formal constraints, and language‑specific SDKs or bindings that let downstream tools consume those ontologies safely.12

Lessons for your stack

Your existing work already aligns with several of those patterns, but from a relational/ceremonial starting point rather than a biomedical one.12

Key parallels:

  • A clear separation of concerns:
    • Ontology and narrative logic live in medicine-wheel-ontology-core and its sibling packages.
    • RSIS‑GitNexus focuses on indexing repos into KuzuDB, wiring MCP tools, and enforcing governance over code and ceremonies.2
  • A shared type system: RelationalNode, Relation, CeremonyLog, NarrativeBeat, OcapFlags, direction constants, and validators form a de‑facto ontology and SDK for all medicine‑wheel‑aware tools.2
  • Governance and sovereignty as first‑class: .rsis-governance.json, OCAP flags, protected paths, and ceremony‑required change patterns explicitly encode Indigenous data governance rather than bolting it on later.2

The missing piece, which ODK and related toolchains highlight, is a standardized ontology lifecycle: formal releases; automated constraints expressed in OWL/SHACL as well as TS/Zod; and migration stories for consumers like RSIS‑GitNexus as the ontology evolves.12

Indigenous Ontology Development Kit: goals

An “indigenous‑ontology‑development‑kit” (iODK) would not just be “ODK with different default templates.” It should embody the ontology/epistemology/axiology/methodology stack Wilson describes: relationality as ontology, relational accountability as axiology/methodology, and research as ceremony.3

Concretely, iODK would aim to:

  • Make relationships and ceremonies first‑class: relations (whakapapa, STEWARDS, SERVES, GIVESBACKTO, BORNFROM, KINSHIPOF), ceremonies, and structural tension objects are primary citizens, not just edges between classes.2
  • Encode accountability: every entity and relation carries stewardship, OCAP flags, consent history, and reciprocity commitments, with checks that these are present and consistent.12
  • Treat change as ceremony: ontology edits and releases are wrapped in explicit ceremonial workflows, including provisions for consent, reflection, and reciprocity, rather than being “just pushes to main.”32
  • Bridge TS/JSON and OWL/SHACL: medicine‑wheel TS types remain the single source of truth, but iODK can generate OWL, SHACL, JSON‑LD, and language bindings, similar to how ODK and ontology SDKs project into multiple artefact forms.2

This positions iODK as a paradigmatic fork of the ODK idea: same lifecycle pattern, different philosophical and governance foundations.

Relationship between ODK, iODK, and RSIS‑GitNexus

A useful way to think about the roles:

AspectODK (INCATools)iODK (proposed)RSIS‑GitNexus role
Primary domainBiomedical / OBO ontologiesIndigenous relational / ceremony ontologies (medicine‑wheel first)Code + ceremony graph over git repos
Ontology formatOWL/RDF, OBOTS/JSON as source; OWL/SHACL/JSON‑LD as generated viewsKuzuDB schema aligned to medicine‑wheel ontology
Core concernsCoherence, interoperability, shared release processRelational accountability, OCAP, ceremonial provenance, directional balanceApplying ontology to real repos and workflows
Governance modelOpen biomedical community processesIndigenous data sovereignty, OCAP, community‑specific protocolsEnforces governance/OCAP on concrete code artefacts
Typical consumersReasoners, data integration tools, analyticsRSIS‑GitNexus, IAIP, medicine‑wheel visualizers, ceremony registriesMCP tools, UI, stewards working with repos

RSIS‑GitNexus already “speaks” the medicine‑wheel ontology in its KuzuDB schema (RelationalNode, RSISRelation, CeremonyLog, KinshipHub, etc.) and MCP tools. That makes it an ideal flagship client of iODK, but not the home of iODK itself. Keeping iODK as a separate project similar to how ODK is separate from any one ontology or application lets:2

  • Other projects (IAIP, ceremony registries, narrative engines) adopt the same ontology and pipelines without inheriting Git‑specific assumptions.
  • RSIS‑GitNexus dogfood the ontology and governance patterns while remaining replaceable as “one application built on the ontology,” not the ontology’s definition site.2

Directionally: iODK should be its own repo, with RSIS‑GitNexus and the medicine‑wheel packages depending on it.

Using the existing medicine‑wheel npm packages

Your published packages already form a de facto “Indigenous ontology SDK” for JS/TS.2

  • medicine-wheel-ontology-core
    • Types: RelationalNode, Relation, CeremonyLog, NarrativeBeat, OcapFlags, direction enums, node types, ceremony types.2
    • Validators: Zod schemas and helpers like computeWilsonAlignment, checkOcapCompliance, relationalCompleteness, beatsByDirection.2
  • medicine-wheel-relational-query
    • Traversal and audit primitives over medicine‑wheel graphs: traversal options, accountability reports, filters tuned for relational and ceremonial boundaries.2
  • medicine-wheel-narrative-engine
    • Converts ceremony lineages into ordered NarrativeBeat sequences across directions and ceremonial phases; validates that arcs honor full cycles.2
  • medicine-wheel-graph-viz
    • MWGraphData and layout hints for wheel‑shaped graph presentations.2
  • medicine-wheel-ui-components, medicine-wheel-ceremony-protocol
    • React components and protocol primitives for ceremony workflows and visualizations used by mcp-medicine-wheel-ui.2

For iODK, these packages become:

  • The canonical in‑language ontology representation (ontology-core), with iODK responsible for generating and validating cross‑language artefacts (OWL, SHACL, JSON Schemas) from it.2
  • The query and audit toolkit (relational-query), where iODK integrates those checks into CI, similar to how ODK integrates ROBOT and other QC tools.2
  • The narrative semantics layer (narrative-engine), which iODK can use to define additional constraints: e.g., “no Inquiry closes without at least one full four‑direction beat cycle” or “ceremony logs must map to coherent narrative arcs.”2
  • The canonical visualization contracts (graph-viz, UI components), which drive example dashboards and human‑in‑the‑loop review flows for ontology evolution and QC in iODK.2

Rather than duplicating logic, iODK should wrap these packages in CLIs and Docker images usable from any language or pipeline (including Make‑file‑driven flows similar to ODK).

Parity in other languages

To support non‑TS stacks while keeping TS as the source of truth:

  • Define language‑neutral artefacts:
    • JSON Schema for each core type (RelationalNode, Relation, CeremonyLog, OcapFlags, etc.).
    • OWL/SHACL shapes expressing key structural and governance constraints (every SERVES edge connects a File to an Inquiry; BORNFROM must target a CeremonyLog; nodes with certain NodeType must carry specific OCAP fields, etc.).2
  • Generate language bindings:
    • TS remains hand‑maintained.
    • Generate Python, Rust, or Kotlin data classes and validators from the JSON Schemas, similar in spirit to ontology-ts-sdk but in reverse (ontology → SDKs in multiple languages).2
  • Provide CLI tools:
    • A mw-ontology-qc CLI (backed by medicine-wheel-ontology-core and relational-query) that can be invoked from any CI system to validate graphs, regardless of implementation language.
    • A mw-ontology-export CLI that emits OWL, SHACL, JSON‑LD, and human‑readable Markdown docs from the TS definitions, in the same way ODK emits OBO/OWL releases and documentation.2

This setup mirrors ODK’s “ontology + release + SDK” triad, but centers your medicine‑wheel primitives and Indigenous governance constraints.

Integrating iODK with RSIS‑GitNexus

RSIS‑GitNexus already extends GitNexus’ code graph with a relational layer whose vocabulary lives in medicine-wheel-ontology-core, adding nodes for people, land, spirits, ancestors, future generations, inquiries, ceremonies, and kinship hubs. Relations like STEWARDS, SERVES, GIVESBACKTO, BORNFROM, and KINSHIPOF, plus OCAP flags and direction tags, are persisted in KuzuDB and surfaced via MCP tools and UI resources.2

iODK can strengthen this by:

  • Making the KuzuDB schema a generated artefact: treat KuzuDB table definitions as compiled from the ontology, so schema changes follow ontology releases rather than diverging.2
  • Embedding QC into RSIS‑GitNexus CI: every ontology or schema change passes both “Western” checks (coherence, missing labels) and Indigenous checks (relational completeness, ceremony provenance, OCAP compliance, directional balance over time).12
  • Using ceremony protocols for migrations: significant ontology changes (e.g., adding SunName, Inquiry, KinshipHub, CeremonyPhase) trigger ceremony‑required workflows in .rsis-governance.json—much as your existing governance spec does for sensitive paths—so that stewards consent and reflect before the new ontology version is adopted.2

RSIS‑GitNexus then becomes a reference deployment of iODK: a concrete example of how code repositories can be indexed into an Indigenous ontology and governed accordingly.

How much to fork from the existing ODK

Technically, there are three levels of reuse:

  1. Conceptual pattern only
    • Copy the structural ideas: cookiecutter‑style templates, Make/CI pipelines, release versioning, QC stages.
    • Implement them in your own stack (TS + Node, maybe with some Python/Java where OWL/SHACL are needed), without depending on the ODK codebase.
  2. Hybrid reuse
    • Use some ODK infrastructure (e.g., its Docker images, Make targets) for OWL/SHACL processing, but treat your TS ontology and Indigenous governance layers as primary.
    • Wrap these in your own higher‑level commands like mw-odk make test, mw-odk release, which orchestrate both ODK tools and your own QS/ceremony logic.
  3. Hard fork of the ODK repo
    • Fork INCATools/ontology-development-kit, change defaults, add Indigenous‑specific scripts and config.
    • Risk: you inherit biomedical‑centric assumptions, Java‑heavy tooling, and a large maintenance surface, and you need to track upstream changes carefully.

Given your current medicine‑wheel stack and the KuzuDB/Node ecosystem around RSIS‑GitNexus, the best path is likely (1) with a bit of (2): treat ODK as an architectural reference and selectively reuse its OWL/SHACL tooling, but build iODK as a distinct kit with TS/Node at the center and explicit Indigenous governance baked in. That preserves philosophical integrity while still learning from ODK’s release discipline.12

Suggested next steps

  • Define the iODK scope in a short spec: what artefacts it owns (TS types, JSON Schemas, OWL/SHACL, CLIs, templates), what guarantees it provides, and how it encodes relational accountability and ceremony.32
  • Extract the ontology core from medicine-wheel-ontology-core into a clearly documented “ontology module,” marking what is normative vs. helper logic.2
  • Prototype a minimal iODK pipeline:
    • Single repo with TS ontology definitions.
    • Scripts to generate JSON Schema, OWL/SHACL, Markdown docs.
    • A small QC CLI using relational-query and ontology-core.
  • Integrate that pipeline into RSIS‑GitNexus as a consumer: use generated artefacts for KuzuDB schema validation, MCP tool contracts, and UI bindings, so you can feel the friction points early.2

Once that loop is working, it will be clear which pieces from ODK proper (if any) are worth importing, and where your ceremony‑centric paradigm requires different design choices. <span style="display:none">4</span>

<div align="center">⁂</div>

Footnotes

  1. CONTENT.md ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. CONTENT.md ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30 ↩31 ↩32 ↩33 ↩34 ↩35 ↩36 ↩37 ↩38 ↩39 ↩40 ↩41

  3. RCH-Wilson-ElementsOfResearchParadigm-001-260111213125-ab2ff9a0-fec7-451e-9fc4-3e6752370ad8.SOURC.md ↩ ↩2 ↩3

  4. RESULT-001___Transform_Indigenous_research_ceremonial_practices.2602140402.md ↩