We work at the intersection of culture, technology, and trust.
Our projects help institutions, researchers, and policymakers to restructure digital data infrastructures — not to collect more data, but to restore meaning to what already exists.
A data architecture studio is the place where technology and meaning meet. Where data flows are designed with attention to context, provenance, and trust. And where transparency is not a marketing term, but a form of craftsmanship.
At P-322 Consultancy, we build digital infrastructures that not only function, but also understand why they exist — and for whom.
The name Plimpton-322 comes from a Babylonian clay tablet over 3,700 years old: one of the oldest known datasets in tabular form. The scribes of that tablet did not hide their knowledge — they made it visible, careful, and durable. That attitude forms our core.
We believe that the future of digital systems lies not in complexity, but in clarity. That data architecture is not only a technical matter, but also a cultural one. And that insight is the only true foundation of trust.
Plimpton-322 was founded by Gertjan Filarski and Jauco Noordzij, two pioneers in European research and heritage infrastructures. Together they bring more than thirty years of experience in the world of open data, semantic technology, and digital preservation.
What unites them is a rare combination of precision and imagination: they think like engineers but feel like heritage people. Their collaboration rests on one conviction — that trust does not arise from control, but from clarity.
Gertjan is a software developer, historian, and economist. He helped build the digital infrastructure of the Royal Netherlands Academy of Arts and Sciences - Humanities Cluster (KNAW-HUC) and served as technical director of CLARIAH - the Netherlands' largest research infrastructure for the humanities. His expertise lies in designing semantic data flows and knowledge graphs that bridge museums, archives, and research.
Jauco is a computer scientist and software architect with a background in data integration and heritage informatics. He has worked on multiple Dutch and European projects, including CLARIAH, and focuses on translating conceptual models into reliable, lightweight, and reusable software components.
As a collection manager, you know the feeling: your data is correct, rich, and carefully built — yet you keep hearing that it needs to be “better.” Standardize, clean up, adjust. But at what cost?
In this blog, I show why your most valuable knowledge is at risk of being lost in that drive for improvement. Not because you are doing anything wrong, but because computer systems are not designed for the richness of your knowledge.
If you work with collections and recognize how nuance disappears into generic terms, this is not a theoretical story but everyday practice. Read this if you want to understand what is really going wrong — and how it can be done differently without losing control of your work.
Technical debt sounds like a precise concept. It isn’t.What started as a way to describe the gap between code and understanding has drifted into a catch-all excuse for decisions we regret. Worse, the metaphor tricks you into thinking you can manage it like real debt. You cannot. There is no clear principal, no predictable interest, no way to know the cost when you take it on.And that matters, because teams use this idea to justify choices every day.If the concept you rely on to make trade-offs is fundamentally flawed, what are you actually optimizing for? This piece breaks down why “technical debt” no longer helps you decide anything and what that means the next time you have to choose.
Read more...
Open data sounds simple, but in practice it rarely is. Anyone who shares heritage data inevitably runs into legal limits, technical constraints, ethical considerations, and geopolitical reality. Ahead of publishing my fourth dataspace experiment next week, this blog pauses on a more fundamental question: what does it really mean to set access conditions within an infrastructure that calls itself “open data”? When is “open” no longer unconditional? And how do you translate policy, trust, and responsibility into technology? This post explores where openness starts to chafe, where control becomes unavoidable, and why that is exactly where dataspaces show their value.
Read more...