Skip to content

Data model summary

CIDS models impact measurement as an RDF graph: organizations describe what they aim to achieve (outcomes), how they measure progress (indicators), and reported values over time (indicator reports), with optional classification (themes), stakeholders, addresses, funding status, and other tier-scoped entities.

The minimum interchange story is Organization → Outcome → Indicator → IndicatorReport, with optional Theme classification on outcomes (and sometimes indicators). See the diagram and property tables in CIDS for developers.

  1. Describe the organization — identity, legal name, optional address and identifiers (Essential/Full expand here).
  2. Model intended change — outcomes linked to the organization, optionally classified by themes.
  3. Define measurement — indicators linked to outcomes (and organization).
  4. Report results — indicator reports with values, units, and time periods.

SFF reporting extends this graph with organization profiles, team demographics, funding status, and related nodes — see Obligations by tier.

Tier Additional node families (beyond previous tier)
Basic Organization, Theme, Outcome, Indicator, IndicatorReport
Essential Address, OrganizationID, Stakeholder, Population, Code, Person, and related linking properties
Full Activity, Input, Output, Service, and broader operational modeling
SFF companion OrganizationProfile, TeamProfile, EDGProfile, FundingStatus, ReportInfo, and SFF-specific properties on Basic/Essential nodes

Exact class lists and cardinalities are in tier SHACL files and the Alignment Checklist.

Relationships and cardinality (plain language)

Section titled “Relationships and cardinality (plain language)”
  • An organization is the anchor for outcomes, indicators, and reports in a single capsule.
  • Outcomes and indicators may form many-to-many links where the impact model requires it; SHACL encodes allowed patterns per tier.
  • Indicator reports point to one indicator and carry the measured value and reporting interval.
  • Themes reference external taxonomies (commonly SDG IRIs); prefer concept URIs over free-text labels alone. In JSON-LD capsules the property is typically forTheme; Graph Cast CRUD uses themes for the same link — see developers guide.

Not every optional property must be populated for valid data — SHACL distinguishes schema presence (aligned software can store a field) from data completeness (SPO filled it in). See SHACL validation vs. funder requirements.

CIDS reuses established vocabularies instead of redefining universal concepts:

Import CIDS uses it for
TOVE Organization Organization, address, identifier patterns
TOVE Activity Activities, inputs, outputs (Full Tier)
TOVE iContact People and contact points
ISO 21972 Units of measure and measurement structures
W3C Time Intervals and temporal literals on reports
SKOS / external IRIs Theme and code list references

Semantic commitments follow RDFS/OWL semantics of those imports. Custom OWL reasoning is not assumed in the wild: validators and tools treat capsules as asserted graphs validated by SHACL, not as inputs to a general-purpose reasoner.

When an imported vocabulary deprecates a term, CIDS releases document replacements in release notes and ontology changelog discussions. Consumers should pin to a CIDS release bundle (see Versioning and governance).

  • Publishers SHOULD produce graphs that validate under SHACL for their declared tier.
  • Consumers SHOULD NOT depend on OWL entailment for interchange — use explicit triples in capsules.
  • Aligned software MAY use OWL internally; exported capsules must still validate as asserted JSON-LD.