Skills taxonomy vs ontology: how to crosswalk ESCO, O*NET, and SFIA into a working graph

Organizations building a skills intelligence system rarely start with a blank slate. HR and talent acquisition teams inherit occupational codes from ESCO or O*NET, IT and engineering leaders benchmark capability levels against SFIA (Skills Framework for the Information Age), and learning platforms maintain vendor-specific course tags. When teams attempt to merge these catalogs into a single flat spreadsheet, they create thousands of duplicate concepts, incompatible proficiency scales, and circular mappings.

To build an operational skills graph—rather than static shelfware—architects must understand the structural difference between a skills taxonomy and a skills ontology, recognize what ESCO, O*NET, and SFIA each measure, and apply a disciplined crosswalk method that preserves provenance.

Skills taxonomy vs ontology: what changes in the data model

Although vendors frequently use "taxonomy" and "ontology" interchangeably, the two structures support fundamentally different workforce decisions:

In short: use a taxonomy for navigation and reporting roll-ups; use an ontology for prerequisite pathing, adjacency matching, and task-level job redesign.

Comparing the three foundational public standards: ESCO, O*NET, and SFIA

No single public framework covers labour-market comparability, task-level occupational analysis, and engineering autonomy levels equally well. Each was designed for a specific institutional purpose:

1. ESCO (European Skills, Competences, Qualifications and Occupations)

Maintained by the European Commission, the ESCO data model links over 3,000 occupations to nearly 14,000 skills/competences and knowledge concepts across 28 languages. ESCO classifies relations between occupations and skills as either essential or optional and distinguishes between transversal skills, domain-specific skills, and knowledge.

• Strength: Multilingual European interoperability, clear separation between knowledge concepts and actionable skills, public URI identifiers.
• Limitation: Does not provide an embedded multi-level autonomy/responsibility scale for technical engineering levels, and fast-moving GenAI tooling lags behind frontier practice.

2. O*NET (Occupational Information Network)

Sponsored by the US Department of Labor, the O*NET Content Model structures nearly 1,000 standard occupations around a rich empirical schema: worker abilities, occupational interests, work values, work styles, detailed work activities (DWAs)/tasks, and technology skills ("hot technologies").

• Strength: Gold-standard task decomposition and empirical importance/level ratings per occupation—making it foundational for measuring task-level AI exposure.
• Limitation: "Skills" in O*NET (such as Critical Thinking, Complex Problem Solving, or Systems Analysis) are broad cross-occupational capacities rather than granular engineering capabilities like RAG or LoRA / QLoRA.

3. SFIA (Skills Framework for the Information Age — SFIA 9 & SFIA 10 direction)

SFIA is the global reference model for digital, data, cybersecurity, and technology professionals. Rather than listing thousands of ephemeral software libraries, SFIA defines stable professional skills across 7 levels of responsibility (from Level 1 Follow and Level 3 Apply to Level 5 Ensure, advise and Level 7 Set strategy, inspire, mobilise), grounded in generic attributes like autonomy, influence, complexity, and knowledge.

• Strength: Separates tool familiarity from accountable professional responsibility. As SFIA's evolution from SFIA 9 toward SFIA 10 emphasizes, AI fluency is not prompt typing—it is governed engineering, risk ownership, and architectural verification.
• Limitation: Intentionally excludes granular product/framework prerequisites (such as LangChain vs LlamaIndex), which must be supplied by a technical domain graph like the GenAI 2026 Skills Atlas.

How to crosswalk ESCO, O*NET, SFIA, and a technical Atlas in 5 steps

Instead of flattening these four sources into a single text column, skills intelligence software should link them as distinct layers of a unified ontology:

1. Anchor roles to O*NET / ESCO occupations and work activities. Map each internal job family to its closest O*NET occupation and ESCO URI so your Role Dictionary inherits standardized task inventories rather than improvised HR bullet points.
2. Bind role seniority and sign-off authority to SFIA levels (1–7). Define what changes between a mid-level engineer (SFIA Level 3–4: Applies and enables) and a principal architect (SFIA Level 5–6: Ensures, advises, and initiates)—specifically around architecture sign-off, runtime guardrails, and audit review.
3. Map typed crosswalk edges (exactMatch, narrowMatch, broadMatch). Follow W3C SKOS semantics when linking frameworks. Never use an = sign between a broad O*NET skill (Programming), a SFIA capability (Software design — SWDN), and a granular Atlas skill (FastAPI or Structured Outputs). Record the Atlas skill as a narrowMatch or enables_task child of the broader standard.
4. Attach directed prerequisite edges for technical execution. Connect granular technical skills using explicit requires_prerequisite links (as modeled in the GenAI 2026 Skills Atlas) so learning plans respect engineering dependencies.
5. Version every crosswalk and preserve source provenance. Store the external framework version (ESCO v1.2, O*NET 29.x, SFIA 9) and confidence score on every mapping edge, following the cross-validation methodology.

Continue exploring

• Explore the interactive Skills Intelligence concept maps and ontology
• Inspect the GenAI 2026 Skills Atlas and prerequisite graph
• Compare Role Dictionary profiles and task structures and AI Exposure by role
• Read the Skills Intelligence Software Comparison & AI Migration Guide
• See how skills intelligence drives IT role redesign and SFIA accountability