Zyndeck: Making Ontologies and Published Vocabularies Easier to Use

I’ve always been interested in taxonomies, ontologies, metadata and semantic text — really the broader question of how we describe things so that both people and systems can make sense of them.

Zyndeck grew from that interest, but also from a much more practical problem. A lot of useful reference knowledge already exists. It is just surprisingly difficult to use consistently.

Industry classifications, occupations, units, currencies, scientific concepts, events and many other domains already have published standards behind them. The trouble is that one arrives as RDF, another as Excel, another as XML, JSON, HTML or a ZIP archive. Sometimes the useful classification is sitting inside tables in a PDF. Another may be published as SKOS or even documented through LaTeX.

One source, one program

The basic Zyndeck design is deliberately simple: each published source gets its own independent program.

That program understands how to fetch or read its source, interpret its hierarchy and identifiers, preserve what matters, and land the result in PostgreSQL in a predictable form.

I deliberately avoided building one giant parser framework. QUDT does not behave like ISCO. Schema.org does not look much like an industry classification. A PDF-based statistical standard is a completely different problem again.

Trying to hide all that source-specific weirdness behind one clever abstraction can simply move the complexity somewhere harder to see. So the weirdness stays close to the source. What becomes common is the boundary around it: storage, packaging, testing, licensing, documentation and inspection.

The workbench has now grown to more than fifty independently built source programs.

What has gone through the workbench

This is probably the part I enjoy most.

ISIC (industry classification), NAICS (North American industries), CPC (products and services), QUDT (units and quantity kinds), UCUM (units of measure), Schema.org (web modelling vocabulary), FIBO (financial concepts), DOLCE (upper ontology), SOSA/SSN (sensors and observations), ISCO (occupations), ESCO (skills and occupations), O*NET (occupational information), ISO country and currency codes, World Development Indicators, IFRS taxonomy, IPTC NewsCodes, CAMEO (event coding), EM-DAT (disaster taxonomy), NASA GCMD (science keywords), UNESCO Thesaurus, FrameNet (semantic frames) and BIAN (banking service domains).

And underneath those names is quite a mix of representation styles: OWL / RDF / TTL · SKOS · XML · Excel · CSV / TSV · JSON · YAML · HTML · LaTeX · PDF tables · gazetteer archives · packaged ZIP distributions.

That variety is really why the one-source-one-program idea matters.

Keep the meaning, not just the rows

Flattening a published vocabulary is not simply about turning something into database rows.

There are hierarchies, editions, identifiers, deprecated concepts, mappings and source provenance that still need to make sense afterwards.

The aim is to make the source easier to query without flattening away what made it meaningful in the first place.

Licensing became part of that too. Some sources are public domain. Some require attribution. Some have share-alike or redistribution restrictions. A few have terms complicated enough that I would rather keep the source restricted than make a convenient assumption.

So Zyndeck treats licence information as part of the data and packaging rather than something somebody remembers to add later to a README.

Coding agents changed what felt practical

Doing this breadth as a solo build would have been difficult for me to justify earlier. Coding agents changed that.

But faster implementation introduces another problem: how do you keep fifty-plus independent programs coherent?

That led to conventions, tests, decision records and some fairly explicit development guardrails.

I also managed to overdo it for a while. Too many checkpoints. Too much ceremony. A process that was starting to become heavier than the solo project it was supposed to support.

So I simplified it again while keeping the controls that were actually useful. That correction is now part of the project method itself.

AI can accelerate the code. The human still has to decide what deserves structure — and what has simply become process.

Tech & engineering snapshot

Area	What I’m using
Core	Python 3.11+, PostgreSQL
Program model	One isolated package per published source
Packaging	uv
Testing	pytest — unit, integration and live-source testing
CI	GitHub Actions
Source parsing	Source-specific parsers and loaders
Source representations	RDF/OWL/TTL, SKOS, XML, Excel, CSV/TSV, JSON, YAML, HTML, LaTeX, PDF and archives
Inspection	Local HTML/JavaScript vocabulary browsers
Development	Coding-agent-assisted workflows

The individual programs are deliberately independent — each has its own dependencies, tests, version and command-line interface rather than importing code from its neighbours.

Where I’m taking it

Today the database and the individual vocabulary browsers are still local tools on my Mac. I built the browsers mainly for myself — to inspect hierarchies, records, mappings and source details while developing each program.

What interests me next is making this feel less like inspecting reference tables and more like exploring a body of knowledge.

That could mean richer browsing across vocabularies, semantic or vector search, and eventually text-to-vocabulary mapping.

Give the system a paragraph, for example, and it could surface concepts from the underlying published vocabularies that appear to describe parts of the text.

That becomes particularly interesting for knowledge assistants and domain-specific knowledge engines. Not because ontologies somehow replace LLMs. More because they may complement each other:

let the LLM help understand the language; let the published vocabulary give that interpretation an explicit concept, identifier and source.

What I keep coming back to

Zyndeck has ended up bringing together two interests that started quite separately for me.

I’ve been curious about structured knowledge for years. Coding agents have now made it practical to build around that interest at a scale I probably wouldn’t have attempted alone.

And LLMs may make those structures much easier for people and applications to actually use.

One side of AI helped me build Zyndeck. The other may eventually become one of the reasons the underlying idea matters.