A vocabulary is an agreed set of terms for describing things such as a person, a business, an address or a public service, so that two systems mean the same thing when they use the same word. Ontologies, taxonomies, code lists and reference data are related tools with different jobs. Together they are the working core of semantic interoperability: without shared definitions, a birth registered in one system and a benefit claim in another cannot be matched with confidence.
How vocabularies, ontologies, taxonomies and code lists differ
The terms are often used loosely, but they describe different levels of formality. The table sets out the working distinctions used in this guide.
| Type | What it is | Public-sector example |
|---|---|---|
| Vocabulary | Named classes and properties for describing things | "Date of birth" as a property of a person |
| Ontology | A formal model whose classes and rules software can reason over | A rule that every registered company has exactly one legal name |
| Taxonomy or thesaurus | Concepts linked as broader, narrower or related, each with preferred labels | Subject terms used to index official documents |
| Code list | A closed list of permitted values, each with a code | Countries, languages or marital status |
| Reference data | Code lists and similar sets that are managed, versioned and published for many systems to share | One central list of country codes used by every agency |
The World Wide Web Consortium (W3C) draws the key line in its Simple Knowledge Organization System (SKOS) standard. A formal ontology states knowledge as axioms and facts, whereas the hierarchies in a thesaurus or classification scheme "do not have any formal semantics"3. SKOS gives thesauri and taxonomies a common web format without forcing them to become ontologies3.
The SEMIC Core Vocabularies
The European Commission's SEMIC action, now part of Interoperable Europe, publishes the Core Vocabularies: "simplified, re-usable and extensible data models that capture the fundamental characteristics of a data entity in a context-neutral fashion"1. The first three, Core Business, Core Person and Core Location, were drafted between November 2011 and May 2012 by a working group of 69 experts from 22 countries, and the coordination group of the Interoperability Solutions for European Public Administrations (ISA) programme endorsed them on 23 May 20121. A public review of four of them began in April 2021 and led to version 2.0.01.
- Core Person: basic facts about a person, such as name, gender and date of birth1.
- Core Business: a legal entity's legal name, activities, address, legal identifier and company type1.
- Core Location: a place given as an address, a geographic name or a geometry, aligned with the data specifications of INSPIRE (Infrastructure for Spatial Information in the European Community)1.
- Core Public Organisation, Core Criterion and Core Evidence and Core Public Event: public bodies, the criteria a business must meet to provide public services or bid for public contracts and the evidence that proves it, and public events1.
The Commission suggests four uses: exchanging data between existing systems, integrating data from different sources, giving base registries such as cadastres and business registers a common export format, and starting the data model of a new system1. Because each vocabulary is context-neutral, a team adds only the detail its own service needs rather than starting from nothing.
CPSV-AP: a shared way to describe public services
The Core Public Service Vocabulary covers what someone needs to know about a service, including its title, description, inputs, outputs, providers and locations1. Its application profile, the Core Public Service Vocabulary Application Profile (CPSV-AP), "provides a minimal common basis within Europe to describe public services"2. An application profile reuses terms from existing standards and says which are mandatory, recommended or optional for a particular use, and which controlled vocabularies to use2.
CPSV-AP links services to the events that trigger them. Its own examples are a diagnosis of illness linked to a claim for sickness benefit, and the group of services involved in setting up a new business2. That structure lets a portal organise services around life events rather than around the departments that run them. Version 3.2.0 has the status of a SEMIC Recommendation, published on 6 May 20242.
Controlled vocabularies: EU Vocabularies and EuroVoc
A controlled vocabulary fixes the values a field may take, so that "Belgium", "BE" and "Belgique" do not end up as three different answers. The Publications Office of the European Union runs EU Vocabularies, which publishes multilingual reference data including code lists, authority lists, taxonomies, thesauri, glossaries and ontologies used by EU institutions and agencies4.
Its best-known asset is EuroVoc, "a multilingual, multidisciplinary thesaurus covering the activities of the EU", with terms in the 24 official EU languages plus Albanian, Macedonian and Serbian5. Its users include the EU institutions, national and regional parliaments in Europe and national governments5. W3C guidance on publishing data names EuroVoc as a prime example of giving standardised terms web identifiers with labels in many languages, which helps reuse across borders6.
Why a small shared vocabulary usually beats a grand ontology
There is a recurring temptation to model a whole subject in one detailed ontology before anyone exchanges data. W3C's Data on the Web Best Practices warns that complex vocabularies "require more effort to produce and understand", which can hamper reuse, and observes that "there is nothing complicated about a list of bus stops"6. SKOS makes a similar point about cost: turning a thesaurus into a formal ontology is demanding, slow and expensive, and much can be gained by using thesauri as they are3.
The same guidance warns against going too far the other way. A vocabulary so thin that it drops useful facts, such as where each bus stop is, fails the people reusing the data6. Formal ontologies still earn their place where software must draw conclusions, and the W3C suggests a profile of OWL (the Web Ontology Language) for data rich enough to support detailed research questions6.
Opinions differ on where the line falls, but for most exchanges between agencies a few agreed terms that several bodies actually use achieve more than a complete model that only its authors understand. The Core Vocabularies follow that approach: small and neutral at the centre, extended locally.
Governance and versioning
A shared vocabulary only stays shared if someone owns it and changes it carefully. The Core Vocabularies are maintained under a published process and methodology, and every change is discussed with the Core Vocabularies Working Group so that it does not break existing implementations1. Anyone can send comments and change requests through the vocabularies' public GitHub repositories1.
W3C guidance gives practical rules that apply to vocabularies as much as to datasets6:
- give every release a version number or date, and keep a history that explains what changed in each version;
- keep identifiers working, so that a withdrawn term or resource still leads to information about it rather than an error;
- reuse existing terms, preferably standardised ones, instead of inventing near-duplicates.
Stable identifiers matter because other organisations build them into their own systems. The guide to linked open government data explains how to design Uniform Resource Identifiers (URIs) that last, and the guide to DCAT-AP, the European profile of the W3C Data Catalog Vocabulary, shows an application profile in use across Europe.
In practice: Ontologies and vocabularies
What it fixes
- Different systems record the same facts, such as a date of birth or a registered address, in the same way.
- Records can be matched across agencies and borders without one-off translation tables.
- New systems start from tested definitions instead of a blank data model.
- Multilingual labels let the same code be read correctly in every official language.
What gets in the way
- Each legacy system has its own field names and local codes, and all of them have to be mapped.
- Teams are tempted to build a complete ontology before they exchange any data.
- Nobody is given ownership of a shared code list, so local copies drift apart.
- Changing a published term can break partners who have built it into their systems.
Where to start: Pick one entity your service exchanges often, such as an address or a business, map your fields to the matching Core Vocabulary and write down the gaps you need to extend.
Sources
- Core Vocabularies, European Commission, Interoperable Europe (SEMIC). Accessed 17 October 2026.
- Core Public Service Vocabulary Application Profile (CPSV-AP), European Commission, Interoperable Europe (SEMIC). Accessed 17 October 2026.
- SKOS Simple Knowledge Organization System Reference, W3C. Accessed 17 October 2026.
- EU Vocabularies - Home, Publications Office of the European Union. Accessed 17 October 2026.
- EuroVoc, Publications Office of the European Union. Accessed 17 October 2026.
- Data on the Web Best Practices, W3C. Accessed 17 October 2026.