The European Skills, Competences, Qualifications, and Occupations (ESCO) taxonomy provides a comprehensive - albeit improvable - taxonomy of skills and occupations, on which our work builds.
As explained here, Tabiya's work enhances widely used skill and competence taxonomies to ensure that our inclusive taxonomy aligns with existing tools employed by governments and organizations. Several key taxonomies serve as the foundation for job matching platforms and public policies, among which the ILO's International Standard Classification of Occupations (ISCO), the European Commission's European Skills, Competences, Qualifications and Occupations (ESCO; built on top of ISCO), and the United States' Occupation Information Network (O*NET) are the most widely-accepted globally standardized taxonomies. Many countries have their own established taxonomies, built independently or based on these global frameworks such as South Africa's Organizing Framework for Occupations (OFO) and Singapore's SkillsFuture.
Tabiya's challenge when picking a base taxonomy is the following: we were trying to pick a comprehensive base of the "seen" economy with which to be able to expand for the "unseen" economy. This fundamental expansion of how global labor taxonomy is applied and can be used requires that the base taxonomy is -
Broad enough to account for the occupations and human capital of individuals all over the world.
Adaptable to local contexts, which implies using a language understandable by local users, and encompassing context-specific skills and occupations.
Open-source and regularly updated, to account for the rapid evolution of labor markets, as well as the integration of new skills and occupations, such as the ones linked to AI or the green economy.
Based on these considerations and discussions with our local implementing partners, ESCO was deemed the most appropriate taxonomy.
When it comes to user experience, one of our main concerns is to make sure that demographics who may be traditionally marginalized from labor market intermediation solutions can use our inclusive taxonomy. In some contexts, the mastery of official languages, such as English in South Africa, is limited. Compared to O*NET, ESCO relies on skill tags that are easier to understand.
ESCO contains a list of ‘similar titles’ or what they call, "alternative labels" for each occupation – making it easier to search for an occupation from a broad starting point. For example, "data engineer" and "data expert" are saved as alternative labels for "data scientist".
Contrary to O*NET, ESCO includes "attitudes and values", which are soft-skills missing in O*NET. Therefore, it covers a broader range of skills that are sought after by employers.
ESCO is a European Commission project administered by the Directorate General Employment, Social Affairs and Inclusion. This ensures that the taxonomy is frequently updated and will be used by major actors in the long run. On the contrary, the last update of ISCO was made in 2008. Frequent updates of ESCO allow it to include skills and occupations associated with major evolutions in labor markets worldwide - for example, the ESCO taxonomy already contains designated skill trees for green and digital skills.
From a technical standpoint, ESCO is designed to be used by third-party organizations. It is specifically built for others to use and embed the taxonomy in their own technologies.
ESCO is arguably more widely adopted across countries. Developing countries in Latin America have also adopted ESCO as their skills framework rather than ONET, and they are contributing to the open-source tools around ESCO which can be leveraged (for instance, ML-classification models which take in free-text job-titles and assign the ESCO occupations).
ESCO provides a Local API in addition to their web-based API. This means that Tabiya can host this API locally and adjust it as need be without depending on third-party performance when the volumes of requests are scaled up. This also gives Tabiya the ability to edit and adapt the framework freely.
We aim to make visible and usable the human capital of everyone in an economy. This page outlines our foundational approach to building a taxonomy that covers the full spectrum of economic activities.
Human capital—the collective skills, knowledge, and experiences of individuals—is a key driver of economic productivity and income potential. The extent of an individual's human capital often determines their earning ability and is deeply tied to human agency, or the capacity to make independent decisions and shape one's life. Recognizing and valuing all forms of human capital is essential for creating inclusive economic opportunities.
The motivation for our work is described well by a quote from one our key partners, Harambee Youth Employment Accelerator:
Young people in South Africa often lack the resources, networks, education and work experiences needed to be considered for formal employment. But, in the past 12 years, our work at Harambee has taught us that young people have the potential to perform in these jobs if we give them a chance! What if a young person was better able to identify and articulate the skills they have gained outside of the formal economy? What if they could signal skills gained from unpaid work?
Harambee Youth Employment Accelerator, South Africa
Organizations supporting young people in accessing economic opportunities often use structured frameworks to define available opportunities and the skills, competencies, and qualifications required. However, most widely used labor market taxonomies fail to capture the diverse economic contributions of individuals. These frameworks, such as the System of National Accounts (SNA)—an international standard for measuring national economic activity—primarily account for formal, market-based transactions.
However, many forms of human capital investment and productivity remain outside these traditional boundaries, including household labor, volunteer work, and informal employment. These activities play a crucial role in economic development and individual livelihoods yet remain undervalued because they do not generate direct monetary compensation. We refer to these overlooked activities as the "unseen economy".
The "unseen" parts of the economy must be acknowledged to ensure a comprehensive understanding of human capital. Seen economic activities typically involve paid labor, whether formal or informal. Unseen activities, by contrast, include unpaid but productive work—such as caring for family members or performing household tasks—that could, in theory, be outsourced for payment. Notably, this definition excludes leisure, as one cannot pay someone to engage in leisure on their behalf.
Recognizing and accounting for the human capital in the unseen parts of the economy is vital for accurately representing people's contributions to the economy, and providing a basis for policies that protect and support all forms of work, thereby enhancing individual agency.
Our mission is to make visible and usable the human capital of everyone in an economy. This involves two related efforts:
Making visible all economic activity and the skills, knowledge, and experience gained through these activities, particularly those in traditionally "unseen" sectors, such as informal and unpaid work.
Making usable the skills, knowledge, and experience gained through these activities by integrating them into conventional labor market frameworks.
The first has long been explored in social science and economic research, a base that we continue to utilize and build upon through our own research. The second objective of making these unseen skills usable is accomplished by expanding the existing map of the labor market: creating an inclusive reference taxonomy that partners can adapt and build upon.
With Tabiya's Inclusive Livelihoods Taxonomy, we aim provide a more inclusive map of the labor market – one that includes activities from the "unseen economy." A more inclusive map of the labor market will allow more inclusive matching, the identification of more diverse career and skill development pathways, and richer data analysis. A more detailed description of our methodology can be found here and our reference taxonomy can be accessed, adapted, and updated through our Open Taxonomy Platform.
Labor markets are diverse and fast changing, so a useful taxonomy must be localizable and adaptable in a transparent way. Our open taxonomy platform empower partners to do this.
We are currently developing the Open Taxonomy Platform, which lets partners flexibly adapt our reference taxonomy in a transparent way. The platform is currently under active open-source development. You can follow along and contribute on Github. If you would like to learn more, please get in touch.
Reference Taxonomy We maintain a canonical set of occupations and skills for general use. This includes both traditional roles (e.g., Accountant) and informal or unpaid roles (e.g., Family Caregiver).
Localization Partners create “forks” or branches of the base taxonomy to adapt local job titles, language requirements, or cultural specifics—without losing the broader structure. This means a localized taxonomy can still talk “under the hood” to other regions.
API Access A simple REST API (with plans for GraphQL in the future) allows you to search, retrieve, and update taxonomy entries. Whether you’re building a job-matching platform or a chatbot, you can programmatically look up occupations, skills, tasks, or synonyms.
Version Control & Transparency Every revision is tracked, and older versions remain accessible. Anyone can see what changed, when, and why—a key requirement when multiple organizations or contributors collaborate over time.
Community Contributions We welcome pull requests and issue reports on GitHub. Contributors can:
Propose new occupations or skills that capture informal work or emerging digital livelihoods.
Offer local language translations.
Flag redundancies or gaps in the taxonomy structure.
This taxonomy is best used for:
Public Employment Services (PES) A government job portal may need to index both formal occupations (like Nurse or Electrician) and informal tasks (like Childcare at Home). The Open Taxonomy Platform lets PES administrators adapt the reference taxonomy to local categories while remaining compatible with international frameworks.
Youth Employment NGOs A non-profit that focuses on upskilling young people can integrate the platform’s API into its app. When a user describes an unpaid or informal experience—such as cooking at home for large extended families—the NGO’s app can quickly map that to recognized culinary or budget-management skills.
Research and Analytics Think tanks or academic teams might want to track how the labor market shifts over time, especially in informal sectors. By using version-controlled, transparent data on occupations and skills, they can compare how certain roles or skill sets grow or shrink across multiple regions.
Explore the Reference Taxonomy Head to our GitHub repository for an overview. You’ll find JSON definitions of occupations, tasks, and skill mappings, along with instructions on how to propose changes.
Set Up the Platform Locally If you want to adapt or extend the taxonomy for your own region, clone the repo and follow the quick-start guide to run a local instance of our platform.
Use the API
Documentation on authentication, queries, and updates is available in our /docs folder on GitHub. You can also find sample scripts and postman collections that show how to retrieve occupations, look up skill definitions, and commit changes.
Contribute
Issues and Pull Requests: Found an occupation that needs local adaptation or noticed a skill that’s missing? Open an issue or submit a pull request on GitHub.
Discussion & Feedback: Join our community forum (link coming soon!) where practitioners and developers share best practices, tips, and localized expansions.
While the Open Taxonomy Platform is already in active development, some exciting features are in progress:
Multilingual Support: We aim to standardize how we store localized names and synonyms for occupations and skills, making it easy to deploy in multiple languages.
Advanced API Queries: Searching by skill clusters or skill synonyms to quickly find relevant occupations.
Integrations with Compass and Classifier: Our Compass conversational tool and Inclusive Livelihoods Classifier both rely on the taxonomy. We plan to release more examples of how to combine them seamlessly.
The Open Taxonomy Platform is licensed under MIT, reflecting our commitment to openness and widespread adoption. We encourage everyone—government agencies, NGOs, private job-matching platforms, researchers, and individuals—to explore, test, and refine the taxonomy so that, together, we build a more inclusive, dynamic picture of labor markets.
Our Core Taxonomy introduces important changes to ESCO to better reflect the livelihoods and economic realities in low- and middle-income countries, but avoids country-specific adaptations.
Our Inclusive Livelihoods Taxonomy introduces important changes to ESCO to better reflect the livelihoods and economic realities in low- and middle-income countries. This page presents our standardized Core version, which is not country-specific. We use our Taxonomy Management Platform to manage and maintain various adapted and country-specific versions.
Version 1.0.0 of the Core Taxonomy expands conventional job and skill classifications by changing ESCO v.1.1.1 in the following ways:
Including New Occupations: Such as "Micro-entrepreneur," explicitly recognizing self-employed individuals and small-scale entrepreneurial activities.
Capturing Unseen Economic Activities: Integrating overlooked roles and activities such as caregiving, housework, volunteer work, and informal employment, guided by the International Classification of Activities for Time-Use Statistics (ICATUS) 2016.
Enhancing Accessibility: Adding simplified alternative labels and clearer terminology, making the taxonomy more approachable and easy to use.
Ensuring Data Quality: Regularly refining taxonomy entries by fixing missing labels, removing duplicate records, and standardizing formatting and textual clarity.
This version builds on ESCO v1.1.1. The latest Tabiya Core taxonomy version includes these specific updates:
Added: New Micro-entrepreneur occupation (code: 5221_2 uuid: d76f0bac-7145-4acc-a53e-259b96a6346b).
Added: Unseen economy occupations/activities from the ICATUS 2016 classification:
12 Occupation Groups (I3, I31, I32, I33, I34, I35, I36, I37, I4, I41, I42, I43, I44, I5, I51, I52).
60 Occupations (e.g., I31_0..., I32_0..., I33_0..., etc.).
72 Occupation hierarchy entries.
3689 Skills Relations.
Fixed: Missing preferred labels in altLabels of ISCO groups, skill groups, some occupations, and some skills.
Fixed: Duplicate alternative labels.
Fixed: Invisible characters such as \t, nbsp, etc., in several text fields.
Fixed: Leading/trailing spaces or new lines in several text fields.
Fixed: Reformatted scope notes for better readability.
Our taxonomy is distributed in a CSV (Comma-Separated Values) format, ensuring ease of use, integration, and compatibility with existing ESCO-based systems.
A Zip file with all CSV files of Version 1.0.0 can be downloaded here.
conceptId: A unique identifier (UUID) for each occupation or skill.
preferredLabel: The primary, official label for the occupation or skill.
alternativeLabels: Additional labels or synonyms, improving accessibility and understanding.
description: Concise notes providing context, scope, or detailed explanations of occupations or skills.
broaderConcept: Links to parent classifications, creating hierarchical relationships.
narrowerConcept: Links to subordinate classifications, detailing hierarchical depth.
relatedConcept: Associations indicating related occupations or skills.
skillRelations: Explicit relationships linking specific skills to relevant occupations, allowing precise mapping.
iscoGroup: ISCO occupational group codes aligning occupations with international standards.
This format closely follows ESCO’s CSV structure, enhancing interoperability and facilitating easy integration into existing workflows. For detailed technical documentation, refer to the Tabiya CSV Format Specification.
The Tabiya Core Taxonomy is openly available under the Creative Commons Attribution 4.0 International (CC BY 4.0) license, facilitating unrestricted use, adaptation, and sharing with appropriate attribution.
Creating an inclusive livelihoods taxonomy involves assigning human capital and skills to activities that are usually unseen, which comes with challenges.
Tabiya's work on the inclusive livelihoods taxonomy can be divided in two streams:
Adaptation of the Seen Economy. Making sure that the "seen" part of the pre-existing taxonomies such as ISCO and ESCO adequately fit local contexts. This work is highly specific to country contexts, and
Making Visible the Unseen Economy. Broadening existing taxonomies so that they include the unseen part of the economy, namely the activities that are typically not considered as productive and the skills that are associated with them.
In this section we detail our approach to the second workstream - our work expanding the map of the labor market.
The challenge is the following: Tabiya aims at creating an inclusive taxonomy of livelihoods, while ensuring that this taxonomy is compatible with existing ones such as ISCO or ESCO. This allows us to ensure that the developed taxonomy can be used by institutions that rely on globally standardized and widely-used taxonomies. We chose to base our work on the European Skills, Competencies, Qualifications and Occupations (ESCO) taxonomy (reasons detailed here).
The first step, naturally, was to evaluate the inclusiveness of the existing ESCO taxonomy. The intellectual underpinning of this work builds upon the "Counting Women's Work" literature, that aims at assigning a monetary value to the tasks done by women, especially in their households. In Tabiya's work, we aim to highlight the human capital gained from these tasks more than assigning monetary values. Additionally, our work covers all job-seekers, not just women, although depending on local contexts they may de facto represent the majority of unseen job-seekers.
Counting Women's Work: The necessity to better understand sex inequalities in the labor market led to the finding that while both men and women work, their work is valued differently, and this differential valuation yields a perceived differential “productive characteristic endowment” amongst sexes that, in turn, drives sex wage disparities for the African case. In particular, men generally perform paid labor market activities, while women perform both paid labor market and unpaid home production activities (Dinkelman & Ngai, 2022). Hence, a literature that seeks to count women’s work has emerged. This literature relies on time-use data to attribute an equivalent labor market wage to home production activities done by women (Samarasinghe, 1997; Hoskyns and Rai, 2007; Donehower, 2018 and Abrigo & Francisco-Abrigo, 2019). For the South African case, this work’s results have found that if household work done predominantly by women were valued by its nearest specialized occupation, it would account for half of the nation’s aggregate labor income (Oosthuizen, 2018). Of course, if a given household activity can be equated to a specialized occupation, this implies that this activity comprises similar tasks to those performed in the specialized occupation. Then, by definition, the fact that tasks are an output of the application of a skill implies that at least some skills used outside of the market are comparable to those used in the market.
For the “unseen economy,” i.e. activities outside of the specific SNA production boundary, we rely on an existing classification of all time-uses and tasks one may gain human capital from - the International Classification of Activities for Time Use Statistics (ICATUS). This standard lists all time uses someone may have throughout the day. ICATUS represents the internationally applicable classifications of activities that people engage in during their 24-hour days.
ICATUS is made up of three levels. The first digit level of disaggregation (highest level of aggregation) is called the major division, the second digit level is called the division level, and the third digit level, which is the most granular level, is called the group level. We first start by comparing ICATUS with the System of National Account, to define the boundaries of the "seen" and the "unseen" economies.
From the mapping above, it is evident that countries use the ICATUS taxonomy as a skeleton that they use to build a locally-adapted time use survey based on. Hence, a key characteristic that positions the ICATUS Framework very well for our purposes is its amenability to local contexts’ time use surveys.
Based on the System of National Accounts, we therefore nominate the following ICATUS major division to encompass the unseen economy:
Unpaid domestic services for household and family members
Unpaid caregiving services for household and family members
Unpaid volunteer, trainee and other unpaid work
Excluding: 53. Unpaid trainee work and related activities.
Excluding: 9. Other unpaid work activities;
Excluding: All activities within ICATUS categories 3, 4 and 5 that include time allocated to waiting, traveling, or accompanying someone.
Once ICATUS activities have been associated with the "unseen" part of the economy, the challenge is to make sure the unseen part of our inclusive taxonomy follow the same structure as the existing ESCO taxonomy. Namely, we need to assign skills to the ICATUS activities forming the unseen part of the economy. Therefore, Tabiya conceptualizes a framework that links the most granular level of unseen economy ICATUS activities (3-digit level) to a set of non-exhaustive candidate ESCO skills and knowledge tags per ICATUS Activity.
ICATUS structure: ICATUS 3 digit level activities comprise more specific activities that lie within ICATUS Divisions 3,4, and 5. For example, “Preparing meals/snacks'' is a Group Level Activity that falls within the Division 3 of ICATUS, namely Unpaid domestic services for household and family members. At the Group Level, ICATUS includes a definition of each activity, and a non-exhaustive list of the tasks that each activity includes and does not include, and at least one example of each Group Level Activity.
ESCO structure: The ESCO taxonomy is made up of a set of occupations at level five or lower that are derived from the four ISCO-08 occupations hierarchy. For the purpose of the Tabiya Framework, we use only ESCO occupations at level five or lower for our analysis, since this provides the desirable granularity and metadata to adequately link ESCO to ICATUS. The ESCO taxonomy provides a brief description of each occupation it comprises, the occupation’s alternative labels as well as access to regulatory information pertaining to the occupation.
The ESCO taxonomy is particularly valuable because of how it structures the full set of skills required by an occupation: every occupation consists of "skills/competencies" and "knowledges" required, and each of these skills/competencies/knowledges are further assigned to being essential or optional to the occupation.
ICATUS Group Level activities are used as one of the inputs and ESCO occupations and skills, competences and knowledge (skills, competences and knowledge will be referred to as skills henceforth for simplicity) are used as the other input for the matching procedure.
First, each ICATUS Group Level activity is manually matched to at most four ESCO occupations by a team of researchers. ICATUS, even at the Group Level, is more broad than ESCO occupations and so, to ensure comprehensiveness in the Tabiya matching procedure, up to four ESCO occupations were potentially matched to each ICATUS Group Level activity. Since the ESCO taxonomy assigns skills to occupations, these ESCO-assigned skills then form the initial list of candidate assigned skills per ICATUS Group Level activity.
Once at most four ESCO occupations are matched to each ICATUS Group Level activity by a team of at least two researchers, these matches are then reviewed by another independent researcher. Throughout this process, there were no instances where the independent researcher disputed an occupation without mutual agreement from the pair of researchers who initially made the match. The process ensures that person-specific biases do not prevail during the matching process.
While we endeavor to minimize biases and human error through this process, we cannot completely rule out the possibility that other (group level) biases and errors may have occured. Over time, as Tabiya accumulates more data and learns from this, the framework will use these learnings to improve and ultimately, not succumb to any currently prevailing biases and errors.
After the ICATUS to ESCO occupations match is done and verified, the next stage of the Tabiya framework formulation can commence. By design, the ESCO taxonomy pre-assigns skills to each ESCO occupation at disaggregation level five and below. Thus, we exploit this structure for the Tabiya framework. In particular, once ICATUS activities are matched to ESCO Occupations, we adopt the pre-assigned ESCO skills as the first set of candidate skills assigned to each unseen economy ICATUS activity. After duplicate skills are removed, each ICATUS activity now has a comprehensive list of skills assigned to it. The procedure is shown below:
The skills taxonomy obtained following this method is hardly usable: each ICATUS activity ended up being associated with numerous skills. In order to provide a manageable list to job seekers when they are selecting skills, the team concluded that the list of skills needed to be condensed. Reducing this also allowed to addressed the transferability and signaling issues inherent to the unseen economy.
We do this in two stages for our first use-case in the South African labor market: first, the Tabiya team proceeded with a first round of skill selection in order to delete skills that were deemed obviously not consistent with the definition and description of ICATUS activities. For the skills list that come out of this first stage filtering, a panel validation approach involving South-African labour market experts was adopted. An expert panel structured as a series of validation exercises would generate context-specific insights from a wide range of stakeholders, making it possible to compensate holders' biases pertaining to the transferability and credibility of skills.
Below we describe the 4 principles used in the first stage skills reduction by Tabiya's researchers. The panel at Harambee is described in details .
Isolating knowledges and retaining only skills/competencies: The ESCO classification distinguishes between "skills" - that all describe an action - and "knowledges". For instance, the occupation "cook" is associated with the skill "use cooking techniques" and the knowledge "cooking technique". As a first step, we chose to isolate knowledges and to mainly focus on skills. However, we chose to let the panel decide to keep certain knowledges when they brought important new informations. For instance, "common children's diseases" may be deemed an essential knowledge when one claims to have experience raising children.
Deleting irrelevant skills:
In ICATUS, each activity is associated with a definition, and explicit list of tasks included in the activity, a list of tasks that are not included, and one or more examples. ESCO is built similarly. However, ICATUS activities are typically not only broader, but conceptually different from ESCO occupations. For example, "Budgeting, planning, organizing duties and activities in the household" is not a formal sector activity that is included in ESCO. Therefore, to assign ESCO skills to this ICATUS activity, it was matched to "Office clerk", "Accountant", "Bed and breakfast operator", three ESCO occupations that encompass all tasks involved in "Budgeting, planning, organizing duties and activities in the household". The issue is that they encompass a lot more work than what budgeting and planning for a household would entail. For example, because of "bed and breakfast operator", the skill "serve beverages" ended up being associated to "Budgeting, planning, organizing duties and activities in the household", even though serving tasks are not included in the description of the ICATUS activity. When we came across such cases, we decided to exclude these skills.
Deleting skills that are deemed too formal: Some of the skills associated with ESCO occupations directly refer to situations or tasks only imaginable in the seen economy, whether it is formal or informal. For instance, "maintain customer service" cannot be appropriately associated with "serving meals and snacks", as it describes serving meals and snacks to one's own children/family members.
Deleting redundant skills: ESCO occupations are typically associated with numerous skills, and each ICATUS activity was associated with multiple ESCO occupations. The lists of skills from each ESCO activity was added to a list of skills for each ICATUS activity, with deletion of duplicate instances of skills. For instance, "Outdoor cleaning" was associated with both "prune plants" and "prune hedges and trees". We considered that associating both skills to "outdoor cleaning" did not bring new information.
This makes up the generalizable unseen economy framework methodology. From this candidate list of skills associated with each unseen economy ICATUS activity, differing contexts can begin to localize this framework.
The Tabiya CSV format is used to import and export data from the Tabiya Open Taxonomy platform.
Each taxonomy version is made up of nine CSV files Each file contains a different type of data. The files are:
A UUIDHISTORY field is a list of all the UUIDs that have been assigned to an entity during its lifecycle, e.g. when the entity is created, imported, exported or copied into our platform.
It is an identifier that can be used for tracking objects not only across their lifecycle, but also across systems.
The UUID history is ordered from newest to oldest UUID.
The first entry in the list is the current UUID of the object. The last entry in the list is the very first (initial) UUID of the object.
The entities in this dataset have been assigned an initial UUID. When an entity is imported into our platform, a new UUID will be issued and added at the top of UUID history.
The UUID used by the platform are based on the Universally Unique Identifier v4 standard.
The maximum number of UUIDs in the history for an object is constrained to
10000.
The ORIGINURI field is a URI that points to the location where an entity was originally defined.
The maximum length for the Origin Uri is
4096characters.
The ID field is a unique identifier for each entity in the CSV dataset. It is used for referencing within the CSV dataset, for example, in the relations between entities.
This field is not meant to be used as an identifier outside the scope of the CSV files, for that purpose you should use the first entry in the UUID History.
The object types are used to differentiate between different types of entities in the dataset.
For example in relations between entities, the object types are used to specify the type of the parent and child objects and determine in which file these objects can be located.
The object types in the CSV files are:
skill: Represents a skill.
skillgroup: Represents a skill group.
escooccupation: Represents an occupation that originates from the ESCO framework.
localoccupation: Represents an occupation that not originate from the ESCO framework and is defined only this taxonomy.
occupationgroup: Represents an Occupation group.
List properties are stored in the CSV files as strings separated by a character. Currently, we do not support values that contain a new line.
The dates in the CSV files are stored in the ISO 8601 format.
Contains information about the model. The export filename is model_info.csv
UUIDHISTORY: A list of UUIDs.
NAME: The name of the model.
LOCALE: The short code of the model's locale.
DESCRIPTION: The description of the model.
VERSION: The version of the model.
RELEASED: A boolean value that indicates whether the model is released or not.
RELEASENOTES: The release notes of the model.
CREATEDAT: The date the model was created.
UPDATEDAT: The date the model was last updated.
Contains the skills of the taxonomy. The export filename is skills.csv
ID: A unique identifier, used for referencing the skill within the CSV dataset.
UUIDHISTORY: A list of UUIDs.
SKILLTYPE: The skill type.
Possible values: skill/competence,knowledge,language,attitude or empty ( ).
REUSELEVEL: The skill reuse level.
Possible values: sector-specific,occupation-specific,cross-sector,transversal or empty ( ).
PREFERREDLABEL: The preferred label of the skill.
ALTLABELS: A list of alternative labels for the skill.
Maximum length per label: 256 characters.
Maximum number of labels: 100.
DESCRIPTION: The skill description.
Maximum length:4000 characters.
DEFINITION: The skill definition.
Maximum length:4000 characters.
SCOPENOTE: The skill scope note.
Maximum length:4000 characters.
ISLOCALIZED: A boolean value that indicates whether the skill is localized or not.
Possible values: true or false.
CREATEDAT: The date the skill was created.
UPDATEDAT: The date the skill was last updated.\
Contains the skill groups of the taxonomy. The export filename is skill_groups.csv
ID: A unique identifier, used for referencing the skill group within the CSV dataset.
UUIDHISTORY: A list of UUIDs.
CODE: SkillGroup code as defined in ESCO. It has the general format SX.X.X, where X is a number.
PREFERREDLABEL: The preferred label of the skill group.
ALTLABELS: A list of alternative labels for the skill group.
Maximum length per label: 256 characters.
Maximum number of labels: 100.
DESCRIPTION: The skill group description.
Maximum length:4000 characters.
SCOPENOTE: The skill group scope note.
Maximum length:4000 characters.
CREATEDAT: The date the skill group was created.
UPDATEDAT: The date the skill group was last updated.
Contains the occupations of the taxonomy. The export filename is occupations.csv
ID: A unique identifier, used for referencing the occupation within the CSV dataset.
UUIDHISTORY: A list of UUIDs.
OCCUPATIONGROUPCODE:The Occupation group that the occupation belongs to.
CODE: An occupation code assigned to the occupation.
For ESCO occupations, the code will be the parent code, followed by a . and any number of digits. Eg: XXXX.1234
For local occupations, the code will be the parent code, followed by an _ and any number of digits. XXXX_1234
PREFERREDLABEL: The preferred label of the occupation.
ALTLABELS: A list of alternative labels for the occupation.
Maximum length per label: 256 characters.
Maximum number of labels: 100.
DESCRIPTION: The occupation description.
Maximum length:4000 characters.
DEFINITION: The occupation definition.
Maximum length:4000 characters.
SCOPENOTE: The occupation scope note.
Maximum length:4000 characters.
REGULATEDPROFESSIONNOTE: The regulated profession note.
Maximum length:4000 characters.
OCCUPATIONTYPE: The type of the occupation.
Possible values: escooccupation or localoccupation.
ISLOCALIZED: A boolean value that indicates whether the occupation is localized or not. Only ocuppations of the type escooccupation can be localized.
Possible values: true or false.
CREATEDAT: The date the occupation was created.
UPDATEDAT: The date the occupation was last updated.
Contains the Occupation groups of the taxonomy. The export filename is occupation_groups.csv
ID: A unique identifier, used for referencing the Occupation group within the CSV dataset.
UUIDHISTORY: A list of UUIDs.
CODE: A four digit identification code of the Occupation group. Each digit represents a level in the hierarchy.
For ISCO groups, the code is a maximum of 4 digits, and each child group should have a code that begins with the parent group code. Eg: 1234
For local groups without a parent group, the code should start with an alphabetical character. Eg: A1234
For local groups, if the parent occupation group is an isco group, the code should start with the parent group code and then have one alphabetical character. Eg: 1234A
For local groups, if the parent occupation group is also a local group, the code should start with the parent group code and then have either an alphabetical character or a number. Eg: 1234AB or 1234A1
GROUPTYPE: The type of the Occupation group.
Possible values: iscogroup or localgroup.
PREFERREDLABEL: The preferred label of the Occupation group.
ALTLABELS: A list of alternative labels for the Occupation group.
Maximum length per label: 256 characters.
Maximum number of labels: 100.
DESCRIPTION: The Occupation group description.
Maximum length:4000 characters.
CREATEDAT: The date the Occupation group was created.
UPDATEDAT: The date the Occupation group was last updated.
Contains the relations between skills. The export filename is skill_to_skill_relations.csv
REQUIRINGID: The ID of the skill that requires another skill.
RELATIONTYPE: The type of the relation.
Possible values: essential or optional.
REQUIREDID: The ID of the skill that is required by another skill.
CREATEDAT: The date the relation was created.
UPDATEDAT: The date the relation was last updated.
Contains the relations between occupations and skills. The export filename is occupation_to_skill_relations.csv
OCCUPATIONTYPE: The type of the occupation.
Possible values: escooccupation or localoccupation.
OCCUPATIONID: The ID of the occupation.
RELATIONTYPE: The type of the relation.
Possible values: essential, optional, or it can be left empty.
SIGNALLINGVALUELABEL: The signalling value label of the relation.
Possible values: low, medium, high, or it can be left empty.
SIGNALLINGVALUE: The signalling value of the relation.
A number between 0 and 1, or it can be left empty. The only allowed delimiter for decimal numbers is a ..
SKILLID: The ID of the skill.
CREATEDAT: The date the relation was created.
UPDATEDAT: The date the relation was last updated.
Caveat: An escooccuption cannot have a
signalling valueorsignalling value label. It must have arelationType. For localoccupationssignalling valueandrelationTypeare mutually exclusive. Alocaloccupationcan either have asignalling valueandsignalling value labelor it can have arelationType, but not both.
Contains the hierarchical structure of various skills. The export filename is skill_hierarchy.csv
PARENTOBJECTTYPE: The type of the parent object.
Possible values: skill or skillgroup.
PARENTID: The ID of the parent object.
CHILDID: The ID of the child object.
CHILDOBJECTTYPE: The type of the child object.
Possible values: skill or skillgroup.
CREATEDAT: The date the relation was created.
UPDATEDAT: The date the relation was last updated.
Caveat: A skill cannot be the parent of a skill group.
Contains the hierarchical structure of various occupations. The export filename is occupation_hierarchy.csv
PARENTOBJECTTYPE: The type of the parent object.
Possible values: occupationgroup, escooccupation, localoccupation.
PARENTID: The ID of the parent object.
CHILDID: The ID of the child object.
CHILDOBJECTTYPE: The type of the child object.
Possible values: occupationgroup, escooccupation, localoccupation.
CREATEDAT: The date the relation was created.
UPDATEDAT: The date the relation was last updated.
Caveat: An
escooccupationcannot be the parent of an 'occupationgroup'. Caveat: Anlocaloccupationcan be a child of anescooccupationor anotherlocaloccupation.
Contains the license information for the model. If one wants to add a license to the dataset, it can be added to a file named LICENSE in the root of the dataset.
The LICENSE file supports plain text and Markdown format. During export the license information of the model will also be exported in the LICENSE file.