Open data standards: a practical guide for South Africa

Open data standards are documented, reusable agreements — schemas, vocabularies, API contracts, and licences — that make data discoverable, machine-readable, and interoperable across systems and organisations. For South African public-sector and research teams, the core shortlist to prioritise is:

• DCAT v3 + application profiles — national and departmental data catalogues
• OCDS — procurement and public contracting transparency
• Schema.org / JSON-LD — web discoverability and lightweight semantic annotation
• CSV on the Web (CSVW) — tabular data with machine-readable metadata
• GeoJSON — spatial datasets aligned with SASDI obligations
• OpenAPI — API contracts for government services and MzansiXchange integration

Authoritative validation comes from the W3C DCAT recommendation, the OCDS specification, and South Africa’s own Digital Solutions Unit (DSU) via the MyMzansi Service Standard. The quick routing rule: if you publish a national catalogue, start with DCAT; if you publish contracting data, start with OCDS; if you expose a government API, start with OpenAPI.

Key takeaways

Adopting open data standards in South Africa requires pairing global specifications like DCAT v3, OCDS, and OpenAPI with local governance instruments including MIOS, the MyMzansi Service Standard, and POPIA data classification.

Table of Contents

• What are the core open data standards and when should you use each?
• How do you structure metadata and data catalogues with DCAT?
• Why should your organisation adopt open data standards?
• What does South Africa’s policy framework require for open data?
• How do you implement open data standards step by step?
• How do APIs and national data exchange work under open standards?
• Which licence should you use for open data in South Africa?
• How the Madlanga Commission published navigable inquiry data
• Where do you find the official specs, validators, and tools?
• Why standards-first open data matters more than most people admit
• Sources
• FAQ

What are the core open data standards and when should you use each?

Each standard solves a different layer of the interoperability problem. Picking the wrong one for the job creates technical debt fast.

DCAT v3 is the W3C recommendation for describing data catalogs. Its key addition over earlier versions is the DataService class, which lets you represent APIs and programmatic interfaces alongside static datasets. Use it whenever you publish a catalogue — national, provincial, or departmental. Jurisdictions typically create application profiles that constrain DCAT to local requirements; the DCAT-US profile is the most cited example, and South African teams should plan a similar local profile that maps to SANS 1878 spatial metadata requirements.

Open Contracting Data Standard (OCDS) defines a common data model for procurement disclosure across the full contracting lifecycle, from planning through award to implementation. It is a free, non-proprietary model with broad international uptake. If your organisation publishes tender, award, or contract data, OCDS is the right starting point — it produces structured JSON that feeds directly into procurement oversight tools.

Schema.org / JSON-LD sits at the web layer. Embedding Schema.org Dataset markup in JSON-LD on a dataset landing page costs almost nothing and immediately improves discoverability in search engines and data aggregators. Think of it as the SEO layer for open data.

CSV on the Web (CSVW) pairs a plain CSV file with a JSON-LD metadata descriptor that defines column types, units, and relationships. It is the right choice when your audience includes non-technical users who will open files in spreadsheet software, but you still need machine-readable schema information attached.

GeoJSON is the de facto standard for spatial data on the web. It integrates cleanly with the South African Spatial Data Infrastructure (SASDI) obligations and is supported natively by most GIS tools. For national spatial datasets, GeoJSON combined with DCAT catalogue metadata satisfies both the web-interoperability and the Spatial Data Infrastructure Act alignment requirements.

OpenAPI documents REST API contracts in a machine-readable format. It enables automated discovery, client code generation, and testing. The MyMzansi Service Standard explicitly mandates OpenAPI across government delivery, so any agency building or procuring an API should treat an OpenAPI specification as a non-optional deliverable.

How do you structure metadata and data catalogues with DCAT?

DCAT v3 organises catalogue metadata around four core classes: Catalog, Dataset, Distribution, and DataService. A Catalog contains one or more Dataset entries; each Dataset has one or more Distribution records pointing to actual downloadable files or API endpoints; and a DataService describes a programmatic interface independently of any single dataset. That last class matters because it lets you register an API in your catalogue without tying it to a single static file.

Application profiles constrain which fields are mandatory, recommended, or optional for a given jurisdiction. The DCAT-US profile, maintained by the US federal government, is the most widely referenced example of this pattern. South African agencies should build a local profile that maps DCAT fields to SANS 1878 spatial metadata requirements and to the DSU’s open-standards mandate. The kartoza/ckanext-dalrrd-emc-dcpr project shows exactly this kind of mapping work for a CKAN-based electronic metadata catalogue.

Essential metadata fields checklist:

Pro Tip: Add dct:provenance and owl:versionInfo fields from the start. Retrofitting provenance metadata into a large catalogue is painful; capturing the source system, transformation steps, and version at publication time costs almost nothing and dramatically reduces duplication when datasets are updated.

Why should your organisation adopt open data standards?

The business case is straightforward, but the evidence is more specific than most decision-makers realise.

Standards-based publishing produces interoperability by design: a dataset published with DCAT metadata can be harvested automatically by any standards-compliant portal without custom integration work. That directly reduces integration cost — every bespoke connector your team builds to move data between systems is a liability that standards eliminate. Vendor neutrality follows from the same logic: when data conforms to an open standard, you can swap the underlying platform without losing the data’s usability.

The scale argument is concrete. Data links open standards to improved findability across a corpus of approximately 1.7 million public datasets, and attributes the ability to search and filter across national portals to the consistent application of DCAT-based metadata. That is the direct payoff of catalogue-level standards: discoverability at scale without manual curation.

Beyond discoverability, the benefits stack up:

• Machine-actionability: structured data feeds directly into dashboards, APIs, and analytical pipelines without manual cleaning
• Transparency and accountability: OCDS-compliant contracting data lets civil society and oversight bodies audit procurement without filing information requests
• Research reproducibility: CSVW metadata makes datasets self-describing, so researchers can reproduce analyses without chasing down the original data publisher
• Reduced procurement risk: open standards prevent lock-in to proprietary formats that become inaccessible when a vendor contract ends
• Data quality improvement: validation against a schema catches errors at publication time rather than downstream

South Africa’s National Data and Cloud Policy identifies open data and interoperability as national policy priorities, which means adoption is not just a technical best practice — it is increasingly a compliance expectation for public-sector organisations.

What does South Africa’s policy framework require for open data?

South Africa has a layered governance structure for open data, and understanding which instrument applies to your organisation determines which standards you are obligated to follow.

The Digital Solutions Unit (DSU) sets delivery guardrails through the MyMzansi Service Standard, which mandates open standards (OAuth2, OpenID Connect, OpenAPI, JSON Schema), open-source-by-default tooling, and composable systems. The centrepiece is MzansiXchange, an API-first national data exchange platform designed for real-time inter-agency data sharing. Any government service that exchanges data with another agency should be building toward MzansiXchange compatibility, which means OpenAPI contracts and JSON Schema validation are baseline requirements, not optional enhancements.

SASDI (South African Spatial Data Infrastructure) governs spatial data publication. The Spatial Data Infrastructure Act creates obligations for national and provincial departments to publish spatial datasets with standardised metadata. In practice, this means DCAT-compliant catalogue entries, GeoJSON distributions, and SANS 1878 field mapping — the kartoza/ckanext-dalrrd-emc-dcpr project demonstrates one implementation path.

MIOS (Minimum Interoperability Standards) prescribes the criteria a standard must meet to be considered sufficiently open for government adoption: non-commercial maintenance, open decision processes, publicly accessible documentation, and royalty-free intellectual property. Before selecting any standard, MIOS provides the checklist to confirm it qualifies. Standards that fail MIOS openness criteria should not be adopted as the primary exchange format for public-sector data.

POPIA intersects with open data at the point of data classification. Before publishing any dataset openly, teams must confirm it contains no personal information as defined by the Protection of Personal Information Act. Where a dataset mixes public and personal fields, the personal fields must be suppressed or anonymised before publication. DCAT’s dct:accessRights field is the right place to record the classification outcome.

South Africa’s Open Government Partnership commitment ZA0028 frames this as a move from transparency to participatory outcomes — the policy intent is not just publication for its own sake, but enabling citizens and civil society to act on the data.

Governance actions for public-sector teams:

• Establish a standards adoption board with representation from legal, technical, and policy functions
• Develop a departmental DCAT application profile aligned to MIOS openness criteria
• Create a POPIA data classification workflow that gates publication approval
• Register datasets with SASDI where spatial coverage applies
• Align API contracts to MzansiXchange OpenAPI requirements before procurement

How do you implement open data standards step by step?

The ODI advises that standards creation is resource-intensive and that successful standards solve a specific reuse problem rather than attempting to be generic. The same logic applies to adoption: start with one concrete use case, validate it, then scale.

Phase 1 — Discover (Week 1–2)

1. Inventory all datasets your organisation currently publishes or intends to publish
2. Classify each by type (tabular, spatial, contracting, API) and sensitivity (POPIA check)
3. Identify the primary reuse need: catalogue discovery, procurement transparency, or API exchange

Phase 2 — Choose a profile (Week 2–3) 4. Select the standard that matches the primary use case (DCAT for catalogues, OCDS for contracting, OpenAPI for APIs) 5. Check the standard against MIOS openness criteria 6. Draft or adopt an application profile that constrains the standard to your organisation’s fields

Phase 3 — Pilot (Week 3–5) 7. Publish one dataset or API contract using the chosen standard 8. Run automated validation (CSVW validator, OpenAPI linter, JSON Schema validator) 9. Share the pilot with one external consumer and collect feedback

Phase 4 — Validate and document (Week 5–6) 10. Fix validation errors and update the application profile 11. Write a data dictionary and publish it alongside the dataset 12. Record provenance, version, and licence metadata

Phase 5 — Scale (Month 2 onward) 13. Apply the validated profile to the full dataset inventory 14. Automate validation in your publication pipeline 15. Register datasets with the national catalogue and SASDI where applicable

Phase 6 — Sustain 16. Assign a named data steward responsible for update cadence and quality 17. Schedule quarterly reviews against updated standards versions 18. Contribute feedback to the community of practice or standards body

Stakeholder roles: the data steward owns metadata quality; the technical lead owns schema and validation tooling; legal owns POPIA classification; the publisher owns the distribution pipeline; the registry manager owns catalogue registration.

Pro Tip: Set up automated validation in your CI/CD pipeline from day one. Tools like the CSVW validator, Spectral for OpenAPI linting, and AJV for JSON Schema validation catch schema errors before publication — fixing them post-publication is significantly more disruptive than catching them in the pipeline.

How do APIs and national data exchange work under open standards?

API-first design means the API contract — the OpenAPI specification — is written before the implementation, not generated from it afterward. That discipline produces contracts that are stable, testable, and consumable by other agencies without coordination overhead. The MyMzansi Service Standard mandates this approach across government delivery, and MzansiXchange is the national platform that operationalises it.

MzansiXchange uses open schemas and consent/audit trail mechanisms to enable secure inter-agency data sharing in real time. The architecture relies on OpenAPI contracts for service description, JSON Schema for payload validation, and OAuth2/OpenID Connect for authentication and authorisation. Recording these in DCAT DataService metadata closes the loop: a consuming agency can discover the API in the catalogue, read its OpenAPI spec, and understand its auth requirements without contacting the publishing agency directly.

API publication checklist:

• Publish an OpenAPI 3.x specification for every government API
• Record the API as a dcat:DataService in your catalogue with a link to the spec
• Implement OAuth2 with short-lived tokens; document token lifecycle in the spec
• Apply OpenID Connect for identity federation across agencies
• Run automated security scanning (OWASP ZAP or equivalent) before go-live
• Classify the API’s datasets under POPIA before enabling public access
• Log all access events for audit trail purposes, as required by MzansiXchange consent patterns

Privacy-by-design is not optional here. An API that exposes personal data without explicit access controls and audit logging violates POPIA regardless of whether the underlying data is technically “open.” The classification step in Phase 1 of the adoption roadmap is what prevents this.

Which licence should you use for open data in South Africa?

Licence choice determines whether your data is actually reusable or just technically available. The two most relevant options for South African open data are CC0 (Creative Commons Zero, a public domain dedication) and ODbL (Open Database Licence, a share-alike licence for databases).

CC0 removes all copyright restrictions and is the most permissive option. It maximises reuse because downstream users face no attribution or share-alike obligations. For government data that has no commercial sensitivity and no personal information, CC0 is the recommended default — it aligns with the open-by-default principle in South Africa’s National Data and Cloud Policy.

ODbL requires that derivative databases be released under the same licence. This is appropriate when the publishing organisation wants to ensure that enriched or combined versions of the data remain open, but it adds friction for commercial reuse and can create compatibility problems when combining datasets under different licences.

Recommended practice:

• Default to CC0 for government open data with no personal or commercially sensitive content
• Use ODbL where share-alike obligations serve a specific policy goal
• Record the licence as dct:license in DCAT metadata with the full licence URI (e.g., https://creativecommons.org/publicdomain/zero/1.0/)
• Publish a human-readable licence notice alongside the machine-readable metadata field
• Under POPIA, never publish a dataset openly if it contains personal information — suppress or anonymise first, then licence

Stewardship responsibilities do not end at publication. Assign an update cadence (quarterly is a practical minimum for most government datasets), maintain a changelog, and handle embargoed fields by using dct:accessRights to mark restricted distributions while keeping the catalogue entry visible.

How the Madlanga Commission published navigable inquiry data

The Madlanga Commission of Inquiry — a judicial investigation into criminal infiltration, political interference, and corruption in South Africa’s police, prosecution, and intelligence sectors — offers a concrete local example of structured data publication applied to a complex, high-stakes public record.

The Commission publishes daily hearing records, case files, witness profiles, exhibits, official documents, rulings, and media briefings as a searchable online archive. Each record type maps directly to open data concepts: the archive functions as a dcat:Catalog; individual hearing records and case files are dcat:Dataset entries; exhibits and documents are dcat:Distribution items; and witness profiles carry person-level metadata with persistent identifiers that link testimony records to individuals across hearings.

The Commission’s methodology page serves as the transparency proof point — it explains how data is sourced, structured, and corrected, which is the provenance metadata that DCAT’s dct:provenance field is designed to capture formally.

Lessons for policymakers and data teams:

• Persistent identifiers matter immediately. Without stable URIs for witnesses, cases, and exhibits, cross-referencing between records becomes manual and error-prone. The Commission’s witness and case pages demonstrate this pattern at scale.
• Navigation is a metadata problem. The ability to track a witness across multiple hearings, or to find all exhibits related to a specific case, depends entirely on consistent metadata fields and linking — not on search engine quality.
• Provenance builds trust. Publishing a methodology page that explains sourcing and correction processes is the human-readable equivalent of dct:provenance metadata. Both matter; neither substitutes for the other.
• Readable formats reduce barriers. Publishing hearing records in formats that citizens can read without specialist software — structured HTML, accessible PDFs — alongside machine-readable metadata serves both the public-access goal and the data-reuse goal simultaneously.
• Legal data accessibility supports accountability. Structured, searchable legal records enable journalists, researchers, and legal professionals to engage with law enforcement misconduct evidence without attending every hearing — which is precisely the transparency outcome South Africa’s OGP commitments describe.

Where do you find the official specs, validators, and tools?

National resources: the DSU’s MyMzansi Service Standard sets the delivery guardrails; SITA’s MIOS framework provides the openness criteria checklist; and the Madlanga Commission’s methodology page demonstrates provenance documentation in a live South African context.

The EU’s data.europa.eu commentary on open standards and interoperability is worth bookmarking for the scale argument: it links consistent standards application to findability across large multi-national dataset corpora, which is the same outcome South African national catalogues are trying to achieve domestically.

Why standards-first open data matters more than most people admit

The standard critique of open data initiatives is that they produce data dumps nobody uses. That critique is almost always correct — and almost always a metadata problem, not a data problem.

When an agency publishes a CSV with no schema, no licence, no provenance, and no persistent identifier, the data is technically open and practically useless. A researcher who finds it cannot confirm what the columns mean, whether the data has been updated, or whether they are legally permitted to republish a derived analysis. Standards eliminate each of those blockers at the point of publication, not after the fact.

South Africa’s governance context makes this more urgent, not less. The OGP commitment ZA0028 frames open data as a path to participatory outcomes — but participation requires data that citizens and civil society can actually use. The Madlanga Commission’s archive is evidence that this is achievable: a complex, sensitive public record made navigable through consistent structure, persistent identifiers, and transparent methodology.

The ODI’s guidance on creating open standards makes a point that applies equally to adopting them: design for a specific reuse problem, not for theoretical completeness. The organisations that succeed with open data standards are the ones that pick one concrete use case, validate it thoroughly, and build from there — not the ones that attempt to implement every standard simultaneously.

The capacity gap in South Africa is real. Most departments lack dedicated data stewards, and MIOS compliance testing is not yet routine. That is an argument for starting small and building institutional knowledge, not for waiting until resources are perfect.

Sources

• Data Catalog Vocabulary (DCAT) - W3C Recommendation
• Digital Transformation Delivery Guardrails and Standards Agreement | MyMzansi Service Standard
• Electronic Communications Act: National Data and Cloud Policy
• Creating open standards — Getting started | ODI Standards
• Embracing open standards for open data: The ecosystem of interoperability across Europe

FAQ

What is an example of an open data standard?

DCAT (Data Catalog Vocabulary) is one of the most widely used open data standards: it is a W3C recommendation that provides a common vocabulary for describing datasets and data services in catalogues, enabling cross-portal discovery without custom integration.

What is an example of a data standard in South Africa?

SANS 1878 is South Africa’s national standard for spatial metadata, and it is used alongside DCAT application profiles in government catalogues to ensure spatial datasets are consistently described and discoverable through SASDI.

What are examples of open data?

Open data includes government procurement records published under OCDS, national census tables from Statistics South Africa (StatsSA), spatial datasets published through SASDI, and judicial inquiry records like those in the Madlanga Commission archive.

What is an example of an open data format?

GeoJSON is a widely used open data format for spatial data; CSV with a CSVW metadata descriptor is the standard open format for tabular data, and both are machine-readable, royalty-free, and supported by the MIOS framework for South African government use.

How do you implement open data standards in a government context?

Start by inventorying datasets and classifying them under POPIA, then select the appropriate standard (DCAT, OCDS, or OpenAPI) based on the primary use case, build or adopt an application profile, pilot with one dataset, run automated validation, and register with the national catalogue before scaling.

Recommended

• Articles · The Madlanga Commission
• Madlanga Commission Today - Latest Hearings, Rulings & Live Updates