Semantic Ontology for Collections Knowledge

Standard GIS treats space as a neutral container: points, lines, and polygons that data gets overlaid onto. A lot of Indigenous spatial frameworks work differently — land, kin, story, and time are treated as co-constitutive rather than separable layers. For historical anthropological collections data in particular, that mismatch matters: the standard cataloging model tends to flatten exactly the kind of situated, relational knowledge that's most important to preserve accurately.

This project started as an open question: what would it actually look like to represent that kind of data — relationally, with community authority built in, rather than bolted on as an afterthought?

Data governance frameworks

• CARE Principles (Collective Benefit, Authority to Control, Responsibility, Ethics) — developed by the Global Indigenous Data Alliance as a complement to FAIR data principles, specifically meant to sit alongside FAIR in scientific data contexts rather than replace it.
• Traditional Knowledge (TK) and Biocultural (BC) Labels — from the Local Contexts project (Jane Anderson, Kim Christen). Metadata labels designed to travel with records, indicating community protocols, restrictions, or context that standard rights/license metadata doesn't capture.
• Indigenous Data Sovereignty networks — the US Indigenous Data Sovereignty Network, Te Mana Raraunga (Māori Data Sovereignty Network), and Maiam nayri Wingara (Australia), which frame "who has authority over representation" as distinct from "who has technical access."

Relational and technical models

• Counter-mapping / Indigenous cartography literature — including Renee Pualani Louis's work on Indigenous cartographies, Margaret Pearce's cartographic work, and the broader "deep mapping" tradition.
• Relational ontologies vs. Western GIS ontologies — critical GIS work (Sarah Elwood and others) that tries to formalize this tension technically rather than only critique it.
• CIDOC-CRM (and extensions like CRMsci, CRMgeo) — an event-based, relational cultural heritage ontology that models "who did what, where, when, in relation to whom," rather than a flat feature table.
• PeriodO and gazetteer-adjacent linked-open-data work, for handling multiple names for the same place across time and community, including contested or overlapping toponymy.
• Mukurtu CMS — a content management platform built explicitly around Indigenous cultural protocols, with different circles of access per record and community-controlled metadata.

One touchstone for this project: the Plateau Peoples' Web Portal, a Mukurtu-based site built by Washington State University Libraries in partnership with eight tribes of the Columbia Plateau. It pairs archival object records with community-authored narratives, oral history excerpts, and TK Labels.

A specific example that's stuck with me: the Woman's Saddle (ˀáayatom sapoˀsaapóˀs) from the Nez Perce Wetxuuwíitin' Collection — formerly known as the Spalding-Allen Collection. Missionary Henry Spalding shipped the collection to Ohio in 1847; in 1996, the Nez Perce Tribe raised $608,100 to buy it back. The portal record pairs the object image with TK Labels, oral history, and community-provided context — a working example of what this kind of relational, protocol-aware metadata actually looks like in practice, not just in theory.

The direction I've landed on: an extension of CIDOC-CRM that formally incorporates TK Labels.

Right now, TK/BC Labels exist as a flat, application-specific schema — the Local Contexts Hub API returns structured JSON per project, with fields like label type, community name, provenance, protocol text, and permissions. That's real, working infrastructure — GBIF even has a pilot integrating Local Contexts Notices and Labels directly into its data-publishing framework — but it's not a formal ontology. There's no RDF/OWL representation, no class hierarchy, no defined relationships to persons, places, activities, or time — the things CIDOC-CRM is built around.

As far as I've been able to find, nobody has built a CRM extension (in the style of CRMsci, CRMgeo, or CRMdig) that specifically incorporates TK Labels or Indigenous data sovereignty concepts. The extension methodology itself is well-established and documented — this would be applying an existing, mature pattern to a new and specifically contested domain, not inventing a modeling approach from scratch.

CRM's core assumption is that entities have stable, hierarchical, universally-addressable identity. TK Labels need to express something different: conditional, community-controlled, non-universal access and description, where the same object can carry different valid truths depending on who's asking.

That means the extension needs first-class properties for things like "this attribution or description is authoritative only within a specific community context" — not just another metadata field bolted onto an existing class. That maps fairly directly onto CARE's "Authority to Control" principle, and onto the Provenance, Protocol, and Permission label types Local Contexts already defines. It's the actual hard modeling problem here, and the place I'd want to start building from.

This project developed out of SFPC's (School for Poetic Computation) Indigenous Cartographies course. I also collaborated on a classmate's project within the same course.

Early and conceptual. I've gathered the research landscape and landed on a direction — a CIDOC-CRM extension incorporating TK Labels — but haven't yet had dedicated time to formalize a first pass at the class hierarchy. Next step is sketching out the actual extension classes and properties, starting from the "context-dependent authority" problem above.