When we started designing Prisma, one of the first decisions we faced was whether to build on existing proprietary APIs or commit fully to open W3C standards. We chose the latter — and it has shaped every subsequent architectural decision. This post explains why.
The five pillars of our standards stack
Prisma's architecture rests on five W3C and W3C-adjacent standards. Each one was chosen because it solves a specific problem that arises when organisations need to share structured information across trust boundaries.
DCAT2 (Data Catalogue Vocabulary) provides a standardised way to describe datasets, their distributions, and their relationships. When a Prisma node publishes a dataset, it does so as a DCAT2 catalogue entry. Any compliant harvester — whether from the European Data Portal, a national open data register, or another Prisma node — can discover and index it without custom integration work.
PROV-O (Provenance Ontology) tracks the lineage of every resource in the system. When data flows from one organisation to another, PROV-O records who created it, when it was modified, and through which processes it arrived at its current state. This is not merely good practice — it is a legal requirement under the EU Data Governance Act for many categories of public-sector data.
ODRL (Open Digital Rights Language) lets organisations express data-sharing policies in machine-readable form. Instead of relying on natural-language licence agreements that require human interpretation, ODRL policies are evaluated programmatically. A Prisma node can automatically enforce rules such as "this dataset may be used for research purposes only" or "access expires after 90 days" without manual intervention.
SHACL (Shapes Constraint Language) validates incoming data against predefined shapes. Before any resource is ingested into a Prisma node, SHACL shapes verify that it conforms to the expected schema. This prevents data quality issues from propagating across a federation and ensures that consuming applications can rely on structural guarantees.
SPARQL serves as the query interface for both local and federated queries. Because every Prisma node exposes a SPARQL endpoint, cross-organisation queries can be composed without requiring a centralised data warehouse. Each node evaluates its portion of the query locally and returns only the permitted results.
How this compares to proprietary alternatives
| Concern | Proprietary approach | Prisma (W3C standards) |
|---|---|---|
| Cataloguing | Vendor-specific metadata schemas; migration required when switching | DCAT2 — portable, harvested by EU open data portals |
| Provenance | Audit logs locked in vendor format | PROV-O — interoperable, legally compliant |
| Access control | Platform-specific IAM policies | ODRL — machine-readable, transferable between systems |
| Validation | Custom schema validators per platform | SHACL — reusable shapes, tooling ecosystem |
| Querying | REST/GraphQL APIs with vendor extensions | SPARQL — federated by design, no central broker |
The core difference is portability. An organisation using Prisma can switch hosting providers, replace components, or federate with partners who use entirely different software — as long as both sides speak the same standards. With proprietary platforms, the switching cost grows with every dataset, every integration, and every year of accumulated vendor dependency.
BSW IHH compliance
Prisma is designed to meet the requirements of the Dutch Baseline Informatiehuishouding (BSW IHH), which sets standards for information management within government organisations. BSW IHH requires, among other things, that information assets be catalogued in a standardised format, that provenance be traceable, and that access policies be documented and enforceable.
Because Prisma uses DCAT2, PROV-O, and ODRL natively, BSW IHH compliance is not an afterthought bolted onto the platform — it is a natural consequence of the architecture. Organisations deploying Prisma for public-sector use cases can demonstrate compliance without additional tooling or manual documentation processes.
Trade-offs
We are not claiming this approach has no costs. SPARQL has a steeper learning curve than REST for developers unfamiliar with linked data. RDF serialisation is more verbose than JSON. Tooling for SHACL and ODRL, while improving, is less mature than the ecosystems around JSON Schema or OpenAPI.
We accept these trade-offs because the alternative — building on proprietary foundations and hoping for future compatibility — is a bet we are not willing to make. Infrastructure that is meant to serve the public interest for decades cannot depend on the continued goodwill of any single vendor.
The standards exist. The tooling is ready. The regulatory environment demands it. Prisma simply puts the pieces together.
Explore the source at codeberg.org/prisma-platform/prisma or reach us at info@prisma-platform.eu.