What is a skill ontology?
A skill ontology sounds complicated, but it is a practical concept for describing skills and their relationships to each other in a way that lets software find related skills as well. The term ontology comes up in different contexts. In computer science it describes a shared vocabulary for a field: which terms exist and how they relate to each other, recorded so that software can work with it.
Its counterpart is the skill taxonomy, which usually describes which category a skill belongs to.
A small example makes the difference easier to grasp: ESCO is the EU’s public skills classification, holding almost 14,000 skills in 28 languages. When we search it for “cybersecurity”, the list stays empty, and the skill only shows up once we type “cyber security” with a space. Things look better for “JavaScript Framework”. ESCO knows the skill and files it under software frameworks. You will not find more specialized skills such as Vue.js or Angular underneath it, though, and nothing records whether someone with Angular experience could quickly work in Vue.js. That is the limit of every taxonomy: it places skills, but it does not show how close they are to each other.
In a world of work where skills renew faster than ever, this limit becomes a problem. According to the World Economic Forum’s Future of Jobs Report 2025, 39 percent of today’s skill sets will be transformed or become outdated by 2030. New skills show up in job postings, projects and resumes long before anyone adds them to a catalog, and often under different names.
This is not just an HR topic, it affects managers and employees just as much.
✦ In short
- Meaning: A skill ontology describes skills together with their relationships, such as specialization, prerequisite or similarity, and records how strong those relationships are.
- Purpose: It makes skills data from different sources comparable and is the foundation for skill inference and skill matching.
- Rollout: It starts with the use cases, a shared definition of skills and a person who reviews new entries on their subject matter.
How does a skill ontology differ from a skill taxonomy?
With the University of Manchester’s pizza tutorial, computer science students have been learning how ontologies work for around 20 years. No pizza is labelled “vegetarian”. The search still finds the Margherita, because tomato counts as a vegetable, mozzarella as cheese, and vegetarian means anything without meat or fish.
And what does this have to do with skills?
An ontology knows the same skills as a taxonomy, but it knows more about them. To stay with the example above: it knows that “cybersecurity” and “cyber security” are the same skill. And it knows that Angular and Vue.js are so closely related that someone with Angular experience gets up to speed in Vue.js quickly. A search can follow these relationships and find a skill’s neighbors as well.
| Skill taxonomy | Skill ontology | |
|---|---|---|
| Describes | which category a skill belongs to | skills with their relationships, such as specialization, prerequisite or similarity |
| Spellings, languages, synonyms | separate entries | one skill |
| How close two skills are | not mapped | strength of the relationship |
| The search finds | exact matches only | related skills as well |
The quality of skills data depends on this. Today, skills sit in profiles, resumes, job descriptions, project lists and learning systems, and every source names them differently. Only the ontology brings these entries together:
- Spellings: “cybersecurity” and “cyber security” mean the same skill.
- Languages: “Projektmanagement” is called “project management” in English.
- Synonyms: “software engineering” and “software development” describe the same work.
This turns scattered entries into data you can compare and analyze.
✦ Our learning
If the search only finds exact matches, people who use different words would rather create an almost identical skill than look for the existing one. If the ontology also shows related skills, they take the existing entry. This reduces duplicates significantly.
As the word ontology suggests, in the context of skills it is about logical relationships between the different levels of a hierarchy. A relationship can mean that two words are semantically related, as in the examples above. Classic relationships between skills are:
- Specialization: Python is a specialization of programming.
- Part of a whole: Pivot tables are part of Excel.
- Prerequisite: Basic statistics is a prerequisite for data analysis.
- Similarity: Angular has similarities with Vue.js.
Direction matters. Python skills include programming. If a profile only says programming, though, it tells you nothing about whether someone can work with Python. A good ontology keeps both directions apart.
The strength of a relationship matters as well. It can be measured, for example, by how quickly someone with one skill becomes productive in the other. Between the package managers npm and yarn that takes hours, between React and Vue.js two to four weeks. Christophe Vantighem describes the types of relationships and how they work together in a catalog in detail in his guide to building a skill catalog.
How does a skill ontology improve skill inference and skill matching?
You might be wondering why all this matters. The answer lies in how skills data comes about in companies. It comes from two sides and from many sources.
What people bring is recorded in resumes, performance reviews, feedback processes, projects, training and self-assessments. What the company needs is recorded in job postings, in the role architecture and in existing taxonomies.
Yet none of these sources speak the same language. The resume says “Cyber Security”, the job posting asks for “IT security”, and the team’s Excel list shows “Cybersecurity” at level 3 of 5.
✦ Shared skills layer
Before you can read anything from this data, it has to be cleaned. The ontology maps every spelling, every language and every synonym to one skill in the catalog and knows that cybersecurity is a specialization of IT security. This creates a shared skills layer on which profiles and roles point to the same skills.
Skill inference starts on this layer. It keeps data current even when nobody maintains their profile by hand.
The software derives skills from the existing sources, for profiles from resumes and projects, for roles from job descriptions. The relationships in the ontology add hints about neighboring skills. Derived skills remain suggestions, though, which employees and managers confirm or correct.
Once both sides sit on the same layer, skill matching brings them together: people with roles, projects, training or internal positions, based on their skills rather than job titles. With an ontology, related skills count as well, and every match can be traced back.
In project staffing, a project might require Spring Boot and Vue.js, both at level 3. The search finds a profile with Spring Boot and Angular, also at level 3. A pure taxonomy only sees that Vue.js is missing and arrives at 50 percent. Through the similarity between Angular and Vue.js, the profile matches 87.5 percent and ranks high in the results.
In training, how close two skills are shows how big a learning step is. With Java experience, someone becomes productive in Kotlin within a few days, but in Python only after one to three months. For Kotlin a short ramp-up is enough, for Python a longer training is worth it.
For new positions, the requirement can be phrased more broadly. If a role requires programming, the search also finds people with Python or Java in their profile through the specializations, even though nobody entered programming word for word.
HR is not the only one to benefit:
- People managers see who in the company could take on a task, including in other departments.
- Employees see which projects, positions and training are within reach with their skills.
- HR gets data that lets it compare gaps across the whole company.
What does it take to roll out a skill ontology?
In many companies, a skill taxonomy lives in Excel. Every team keeps its own lists, with its own terms and its own levels, and at company level you can hardly read anything from them, let alone compare them.
Three figures from current studies show how far companies have come overall.
Many companies are already matching based on skills, but only a few have the catalog and the centralized data that make matching reliable. In the Kienbaum study, how far HR gets with AI is explained by the maturity of HR IT alone, while size and industry make no measurable difference.
On top of this come the hurdles Deloitte measured in its study “The skills-based organization“. At the top are legacy mindsets and practices at 46 percent, followed by the difficulty of keeping pace with changing skill requirements at 32 percent. An ontology that automatically classifies new skills and links them to existing ones helps with the pace. Legacy practices only change through decisions made before the rollout.
Six prerequisites matter for the rollout itself, in this order:
- Use cases first: Christophe Vantighem’s tips for a successful rollout, based on ten years of experience with implementations, recommend defining the use cases first and the taxonomy second. Once it is clear whether the goal is project staffing, training or internal mobility, it also becomes clear how fine-grained a skill needs to be.
- A shared definition: A skill describes what a person can do, not a task, a certificate or a personality trait. If you can no longer name a concrete training for a skill, it is split too finely.
- Described levels: In matching, the level counts as well as the relationship. Every level therefore needs a short description that means the same in every team.
- Existing taxonomies as a basis: A shared catalog does not have to start from zero. ESCO or Lightcast Open Skills with more than 34,000 skills provide a foundation, and your own roles and terms are added on top.
- AI suggestions with expert review: Even a catalog of 1,000 skills contains almost 500,000 possible pairs, which is why language models suggest relationships and their strength. They should be reviewed by people who know the subject, because HR can steer the process but can rarely judge whether a technical skill is named and placed correctly.
- A visible benefit: Employees ask themselves when filling in their profile: what is in it for me? Acceptance rises as soon as a completed profile leads to suitable training, projects or internal positions, and that is exactly what an ontology delivers, because it also takes related skills into account.
✦ Our learning
Define the structure of the catalog and fill the reviewer role from day one, with time set aside for it. Where this was missing at the start, most of the recurring friction came later.
Frequently asked questions about skill ontology
Which relationships does a skill ontology know?
Classic relationships between skills are specialization, part of a whole, prerequisite and similarity. Python, for example, is a specialization of programming.
What is a skill ontology for?
A skill ontology makes skills data from different sources comparable and is the foundation for skill inference and skill matching.
How does a skill ontology help with skill matching?
A search can follow the relationships and find a skill’s neighbors as well. With an ontology, related skills count as well, and every match can be traced back.
Where does the rollout of a skill ontology start?
It starts with the use cases, a shared definition of skills and a person who reviews new entries on their subject matter.
How does Teammeter use a skill ontology?
In Teammeter, the ontology is called SkillNexus. For every new skill, the AI suggests related skills and rates each relationship with two values, one for each direction. If you want, new skills that employees create only enter the shared catalog after approval.
When you search Teammeter for people with specific skills, you see profiles with related or similar skills next to the exact matches, each with a percentage that shows how well they fit. In a demo, we show you what this looks like with your roles and skills.
