About Pletka
Composable semantic modeling for cultural heritage
The Problem
Cultural heritage institutions β museums, archives, libraries β need to describe their collections in structured, interoperable ways. They use ontologies: formal vocabularies that define how things relate to each other. But each institution has historically built their data models from scratch, making different choices for the same concepts. When it came time to share or integrate data, the inconsistencies meant months of reconciliation work.
The barrier to entry was high. The cost of mistakes was invisible until integration time. And the collective knowledge of what worked stayed locked in individual heads and institutional wikis.
Our Building Blocks
Pletka breaks ontology modeling into composable building blocks. You build bottom-up, from small reusable pieces to complete descriptions of your domain.
F Fields
A field is the atomic unit. It is an ontological path that starts with a scope class and ends where a user would enter real content β a name, a date, a reference to another entity. Each field has an ontology path, an expected value type, and multilingual titles and descriptions.
C Categories
Categories are the organisational layer that makes your field library navigable. They group fields into human-readable sections β "Existence", "Description", "Names and Identifiers" β so users can find what they need. Categories carry no ontological meaning; they are how you organise fields for human consumption.
Co Collections
Collections are semantic blocks of meaning. They group related fields that share a common ontological context β for example, a "Birth Event" collection gathers all the fields related to birth: the date, the place, the participants. Inside a collection, you can override field titles and descriptions to match the context.
M Models
A model represents a real-world entity type you want to describe β a Person, an Object, a Place, an Event. A model has a scope class and bundles collections and fields together with its own layer of overrides that can rename, constrain, or hide fields.
W The Weave
The weave is the complete picture: all your models, their collections and fields, the relationships between models, and the overrides that make everything fit your specific use case. If a model describes one entity type, the weave describes how those entity types relate to each other.
The Power of Overrides
Overrides are the mechanism that makes composition and reuse work. You build one field and adapt it everywhere. The same field β same ontology path, same formal semantics β can appear as "Title" in an Object model, "Name" in a Person model, and "Label" in a Concept model. The interoperability is preserved at the ontology level. The human understanding is preserved at the override level.
The override chain has three layers: base field (canonical definition), collection override (context-specific naming), and model override (further specialisation with cardinality constraints). The most specific override wins.
Composition and Reuse
Instead of building from scratch, you compose from a growing library of patterns that the community has already validated. Every time a field path is adopted by another project, the groove gets deeper. The most-adopted patterns float to the top, making reuse the path of least resistance.
Generators
Once you have a well-described weave, Pletka offers generators that produce reusable output formats: RDF/RDFS, SHACL validation shapes, Linked Art JSON-LD, Arches resource models, and more. Change your weave, regenerate, and your implementation formats stay in sync.