Data contracts
A data contract is an agreement about what “valid” means, backed by something both sides can check independently. Ontoshire’s registry is what makes that agreement possible: not a local SHACL file on someone’s laptop, but a schema at a citeable, versioned URL that anyone can pin and validate against.
The problem with a local file#
Nothing stops two teams from writing SHACL shapes and running pySHACL, or any other SHACL engine, against a file sitting in a repo. That works fine for one team checking its own data. It breaks down the moment a second party needs to agree that the same shapes were used:
- There’s no single copy either side can point to — just whoever’s file is newest.
- Nothing stops the file from changing after the fact, silently, with no record of which version a given validation run actually used.
- A claim like “we validated this” can’t be checked independently — the other party has to take your word for it, or re-request the file and hope it’s the one you meant.
Pin a version, not a file#
Every ontology published to Ontoshire gets an immutable, versioned identity — owner/repo@version — and its author’s SHACL shapes are served alongside it as their own versioned artifact. The Ontoshire client pulls exactly that version, assembles it with your instance data, and validates locally:
pip install ontogate ontogate validate --schema acme/health-model@v1.2.0 --data ./incoming-patient-record.ttl
The version never moves. Publishing a new one doesn’t change what v1.2.0 meant, so a validation run from today and one from six months ago are checking the same thing.
The same URL, checked twice#
A pinned version resolves to one canonical URL — the ontology and its shapes served together, content-negotiated for a browser or a machine. That URL is what makes the contract third-party checkable: whoever receives your data can pull the exact same owner/repo@version and re-run the same validation themselves, rather than trusting a claim they can’t verify.
Nobody has to send anybody a file. Both sides already have the URL, because it’s the one thing about the exchange that was public and citeable from the start.
Where this matters#
SHACL validation against a local file already answers “is this data internally consistent?” A pinned, published schema answers a harder question: can anyone else confirm it was checked against the same thing you checked it against?
| Situation | What a data contract gives you |
|---|---|
| Between organisations | A data provider and consumer, or partners in a supply chain or research consortium, validate against one shared, published schema instead of each maintaining their own interpretation of it. |
| Between internal teams | “Who changed the schema” stops being a Slack argument — the version in the validation report is a specific, citeable owner/repo@version, not a file someone edited last Tuesday. |
| Provable after the fact | A record that says “validated against acme/health-model@v1.2.0” can be checked months later, because that version still resolves to exactly what it resolved to at the time. |
What runs where#
The client runs in your environment — a CI job, a service, a batch step — wherever you already run your own code. Only public schema metadata (the ontology, its dependency closure, and the shapes) is fetched from Ontoshire. Your instance data is never sent anywhere; it’s assembled and validated in memory, locally, with pySHACL.