Appearance
Respecting data sovereignty means recognising that the communities a record is about have authority over how that data is collected, stored, accessed, and reused — and building that authority into your workflow rather than bolting it on at the end. For cultural-heritage work this most often means Indigenous Data Sovereignty (IDSov), governed in practice through the CARE Principles, Traditional Knowledge Labels, and negotiated access agreements. This guide walks the full workflow, from first contact to long-term stewardship, with reusable examples.
What is data sovereignty, and how does it differ from data residency?
People conflate the two and get it badly wrong. Data residency asks where does the server sit? Data sovereignty asks who has the authority to govern this data, and under whose law and cultural protocols? You can host a community's data on a server inside their country and still violate their sovereignty if you grant access, license reuse, or set retention without their say.
In heritage, the dominant frame is IDSov: Indigenous peoples' right to govern data about their communities, lands, knowledge, and ancestors. It rests on the reality that historical collections were very often created about communities, not with them.
How do CARE and FAIR work together?
FAIR (Findable, Accessible, Interoperable, Reusable) optimises data for machines and researchers. CARE adds the people the machines ignore. Use both, with CARE as the governing layer.
| CARE | Means in practice | A concrete action |
|---|---|---|
| Collective benefit | Community gains from the data | Share outputs and skills back, not just take |
| Authority to control | Community governs access and use | Give them a veto and a seat in decisions |
| Responsibility | Relationships are nurtured, not extractive | Document obligations and report back |
| Ethics | Rights and wellbeing come first | Honour protocols even when law does not require it |
The slogan that keeps it straight: be FAIR for the data, be CARE-ful for the people.
How do I set up a sovereignty-respecting workflow?
Build governance into the pipeline from the start. A reusable sequence:
- Engage before you ingest. Identify the originating community and open a conversation before digitising or cataloguing.
- Agree the terms. Negotiate a written access and use agreement: who may see what, under what conditions, for how long.
- Encode the protocols. Translate the agreement into machine-readable controls — access tiers, TK Labels, and metadata.
- Store with jurisdiction in mind. Choose hosting whose governing law the community accepts.
- Report back and revise. Treat the agreement as living; revisit it as relationships and uses change.
The principle is that consent is ongoing, not a one-off signature at accession.
How do I encode community protocols in metadata?
This is where the abstract becomes operational. Use Local Contexts TK Labels to carry the community's own permissions alongside your technical access tiers.
json
{
"identifier": "ark:/12345/photo-0421",
"tk_labels": ["TK Attribution", "TK Community Voice", "TK Culturally Sensitive"],
"access_tier": "community-restricted",
"governing_agreement": "MOU-2025-007",
"permitted_uses": ["research-on-request", "community-education"],
"review_date": "2027-02-01"
}TK Labels do what copyright cannot: they express cultural expectations — that an item is sacred, seasonal, or restricted by gender — in a form your catalogue and your users can read.
Where should the data physically live?
Cross-border storage is a sovereignty question disguised as an IT decision. Putting a community's data on a US-based cloud can expose it to foreign legal process; an EU host engages GDPR. None of this is automatically wrong, but it must be a governed choice. Present the trade-offs to the community, document the decision in the agreement, and prefer arrangements — local hosting, repatriated copies, or community-controlled repositories — that keep authority where it belongs.
What happens when legal ownership and moral authority diverge?
Frequently your institution holds copyright while the community holds the moral claim. Sovereignty practice resolves this in the community's favour even when the law does not compel it. Formalise the split: copyright may stay with the holder for administrative purposes, while a memorandum of understanding gives the originating community a governing voice over access and reuse. The test of a real sovereignty workflow is whether the community could say "stop" and have it honoured — if the answer is no, you have residency, not sovereignty.
Key Takeaways
- Data sovereignty is about authority over data, not the country the server sits in.
- In heritage it usually means Indigenous Data Sovereignty, governed via the CARE Principles.
- Be FAIR for the data and CARE-ful for the people; use the two layers together.
- Build governance in from first contact; treat consent as ongoing, not a one-time signature.
- Encode community protocols with TK Labels and access tiers your systems can enforce.
- Make cross-border storage a governed decision, not a default.
- Honour moral authority over access even when legal ownership sits elsewhere.
Frequently Asked Questions
What is data sovereignty in a cultural heritage context?
It is the principle that peoples and communities have the right to govern the collection, ownership, and use of data about them, their territories, and their cultural materials. For Indigenous data it is often framed as Indigenous Data Sovereignty (IDSov).
How does data sovereignty differ from data residency?
Data residency is purely about which country a server sits in; data sovereignty is about who has authority over the data and under whose law and protocols it is governed. You can satisfy residency and still violate sovereignty.
What are the CARE Principles?
CARE stands for Collective benefit, Authority to control, Responsibility, and Ethics. It complements the technical FAIR principles by foregrounding the rights and interests of the people the data is about.
What are Traditional Knowledge (TK) Labels?
TK Labels are a digital tool from Local Contexts that let communities attach their own cultural protocols and access expectations to heritage items, communicating permissions that copyright cannot express.
Can I put community heritage data on a US or EU cloud?
Sometimes, but only with the community's informed agreement and attention to which laws then apply. Cross-border storage can subject the data to foreign jurisdiction, so it should be a governed decision, not a default.
Who decides access if the community is not the legal owner?
Legal ownership and moral authority can diverge. Good practice gives the originating community a governing voice over access regardless of who holds copyright, often formalised through an agreement or memorandum of understanding.