The purpose of this white paper is to explain the limitations of today’s keyword-based search technology within the scope of recruiting, job seeking, talent acquisition and sourcing, skills profiling, matching and management. This paper seeks to highlight how the demands of government labour departments, statistics offices and other stakeholders in the labour markets themselves, comprised of both industry talent seekers and job seekers, both active and passive, are not being met to a satisfactory level of expected or desired precision by technology.
Current technology such as keyword-base search and CV Parsing is incapable of simultaneously and bidirectionally comparing occupation-specific Big Data. As a result, the needs of public labour initiatives e.g., matching profiles and records of unemployed workers, government education offices, the databases of job boards, job engines and professional and social networks (hereafter collectively known as ‘online services’), CVs libraries and job description databases are not being met.
Furthermore, it will be explained how the rise of semantic technology and in particular the use of occupation data ontologies has provided the solution to comparing large datasets with greater efficiency and accuracy. In order to clarify this complex topic, examples will be provided throughout and a section outlining four use cases for the real-world application of ontology-based semantic matching will be supplied. The paper will then conclude with final commentary on the benefits of ontology-based semantic matching in this sphere.
1.1 Terminology and references used in this paper
In this section the terminology, if needed, that is used in this sphere will be explained for future reference. For additional terminology please use our detailed glossary in the APPENDIX.
the source of information concerning ontologies and developer of semantic technology, products and solutions outlined later in this paper.
The Smart Matching Engine designed and developed by JANZZ.technology to search for and match target entries from data sources (structured and unstructured) such as government labour records of unemployment statistics, CV or job offer databases, and return results defined within the user’s desired parameters.
The unique Ontology designed and constructed by JANZZ.technology to act as an encyclopaedic knowledge base that contains inter-connected occupation data in a multi-relational semantic system for use typically via the JANZZrestAPI in providing context to a matching engine, or in statistical analysis tools or third party platforms for data enrichment, to name but a few.
The ultimate classification tool designed and built by JANZZ.technology to classify and standardize huge datasets and make the data comparable because of the annotated metadata including the official classifications, related skills, jobs, functions and much more.
is the terminology specific to professions and includes all other relevant data, called “concepts”. Occupation data therefore consists of the occupation or profession itself, the specialisation (particular to that profession), the skills and competences required, the functions necessary, the experience (that is built up in the profession), the qualification and education level, and finally the transversal or soft skills. More can be added though in future according to developments in the requirements of industry statistics, e.g., work environment.
(OC): The OC defines how strongly the occupation itself is considered in relation to the other occupation data when comparison and matching between two or more complex sets of data. The occupations are defined from very specific to not very specific at all. Highly specific occupations are weighted highly, and less-specific are given a progressively lower weighting.
Example: Midwife is highly specific (OC1); Teacher falls in the middle of the specificity scale (OC3); Consultant is not specific and populates a low OC (5).
With less-specific occupations the strength of argument shifts from the occupation to the other related occupation data, e.g. specialisation, function, skills, experience etc.
In the context of data comparison, as opposed to linguistics, semantic describes how concepts are related logically and contextually with each other – with a reference to their backgrounds and origins.
Example: ERP↔SAP. An example of an ERP is SAP, among others. SAP is an ERP
There is no linguistic connection between ERP and SAP or carpenter and joiner except for when both terms are used or referred to in the same job offer text by coincidence or by specific design. A keyword search engine will find both but not through context but by accident. Semantically there is a connection, the relationship is known but only because that information is supplied by an ontology which stores those relationships and the context. An ontology will store synonyms in the first instance but a multilingual ontology like that of JANZZon! will also contain the translation of the concepts AND their synonyms. However, also included within an ontology are features such as excluded terms, that is, terms that should be ignored when searching for a target entry.
Example: When searching for a CEO, exclude Assistant, Personal Assistant, Executive Assistant, as appears in job titles such as Assistant to the CEO as well as in other sectors like serviceoriented architecture etc.
In addition, an ontology establishes ‘part equivalent’ relationships and ‘same but different’ (for more on these terms see APPENDIX). When a search or match is semantic it takes into consideration the relationship and meaning of words and phrases for comparison, allowing systems such as matching or search engines to ‘understand’ the context of the targeted phrase.
Example: When searching for English Coach, the similar professions Teacher of English and, Language tutor specialising in English and French will be fully or partially included in the result because the bi-lingual tutor is not an exact match to the teacher who only focusses on English. From the perspective of the tutor herself it is only a 50% match.
These features are but some of the reasons why an ontology powers a matching engine with semantic capability.
Homonyms and Polysemes:
One particular use that an ontology has is clarifying the distinction between words and concepts that look very similar or the same but have different meaning. This particularly occurs cross-lingually and found within cultural differences. Homonyms are words and word pairs that are spelt the same, sound the same but have different meanings.
Example: Sales Reps, Account Managers, Consultants and Project Managers are used in countless cases but have different meanings depending on the industry, company or organisation, specialisation, function and skills.
Polysemes are very similar to homonyms in that they can be spelt the same, but also can be spelt differently, but nevertheless sound the same and also have different but related meanings because of shared origins.
Example: Polysemes include Designer (many different meanings depending on context); Manager can be either a person in charge of a process or personnel; Executive can hold either a senior position in an organisation or be salesperson as in “Advertising Sales Executive”; and Application can be a software tool, a software for mobile devices or many other things.
This is the reason why, in an ontology, concepts are tagged with alternative meanings in order to counter the discrepancies and confusion so concepts can be compared accurately.