Skip to content
Common ApproachDeveloper Docs

Versioning and governance

The Common Impact Data Standard is a community-driven standard.

This MAP documents CIDS release 3.2.1 (ontology date 2025-10-31). Version numbers for ontology, SHACL, contexts, code lists, and this documentation are related but not identical — if posting an issue, always cite the full release bundle you tested against.

Version identifiers

Section titled “Version identifiers”
Artifact Current example Where declared
CIDS ontology 3.2.1 owl:versionInfo in cids.ttl; version IRI …/cids/3.2.1
SFF companion 2.0.0 (module) sff.ttl
SHACL shapes Published with ontology server Filenames unchanged across minor ontology patches unless announced
JSON-LD contexts Published URLs contexts/
Code lists Per-list versioning on server codelist.commonapproach.org
This MAP (developer documentation) Tracks ontology 3.2.1 Normative references

Governance

Section titled “Governance”
  • Copyright and license: Common Approach to Impact Measurement; CIDS ontology under CC BY-SA 4.0 per ontology metadata and CIDS POLICIES.md.
  • URI policy: HTTPS identifiers; HTTP requests upgrade to HTTPS.
  • Changes: Proposed via commonapproach/CIDS issues, Discussions, and release tagging; public artifacts are published at ontology.commonapproach.org.
  • Authorship: Collaborative and community-driven; contributors recorded per ontology revision.

What counts as a breaking change

Section titled “What counts as a breaking change”

Breaking for conformant data generally means:

  • New sh:Violation where data previously passed for the same tier
  • Renamed or removed properties with no backward-compatible alias
  • Changed @context expansion that alters property IRIs
  • Retired code list concepts still required by SHACL

Non-breaking changes include:

  • New optional classes or properties
  • Additional SHACL warnings (not violations)
  • Documentation and HTML guide updates that match existing SHACL

Common Approach will announce breaking changes in release notes and GitHub Discussions several months before users are expected to migrate.

Deprecation process

Section titled “Deprecation process”

If a term is deprecated, Common Approach will:

  1. Mark terms in the ontology with deprecation annotations where OWL supports it.
  2. Maintain SHACL compatibility for at least one release cycle when possible.
  3. Document replacements in release notes and this MAP’s Normative references.
  4. Keep owl:priorVersion links between ontology versions for traceability.

Support window for old paths

Section titled “Support window for old paths”

Versioned ontology paths (e.g. /3.2.1/cids.ttl) remain available for implementers who pin releases. The unversioned cids.ttl URL tracks the current published release on the server.

Version conflict resolution

Section titled “Version conflict resolution”

For conformance precedence (SHACL vs OWL vs MAP vs checklist), see Conflict resolution.

Section titled “Related”