<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Beyond generic skills: creating capability-centric, company-specific knowledge graphs from job descriptions</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Kaan Karakeben</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Henri Egle Sorotos</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Ahmad Assaf</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Beamery</institution>
          ,
          <addr-line>London</addr-line>
          ,
          <country country="UK">United Kingdom</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>The Human Resources domain is a data-rich function in any organisation. Semantic knowledge graphs have previously been discussed as a key enabler to bring clarity to the data, and to enable better decision making. Specifically, a previously proven solution to extract a limited number of basic entities from job descriptions has been established [1]. The previous method linked to a standardised taxonomy of skills, and the result was used to generate Resource Description Framework (RDF) graphs. Additional challenge of this was that these approaches were limited to skills only, and do not take into account the full context of a company [1] [2]. The resulting graph is often generic, incomplete, and not useful for human decision making. In reality, a job description consists of a set of capabilities describing an ideal candidate for the post. Capabilities act as an intermediate layer between a job description's responsibilities and the skills they required to fulfill them. They encompass the common tasks within responsibilities and help identify relevant skills. By doing so, they incorporate the company context into the skills derived from these responsibilities. This paper introduces a novel approach to address the limitations of existing methods by extracting company-specific and bespoke capabilities. The result is a rich graph of both generic and bespoke entities, which can be used to generate a more complete and useful RDF graph. Outcomes are grounded in the context of the company.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Motivation</title>
    </sec>
    <sec id="sec-2">
      <title>2. Solution</title>
      <p>The solution is a multi-step process, which extracts entities from job descriptions iteratively. Entities are
extracted in a hierarchical manner, starting with the most conceptually aggregated entities, and moving
to the most granular. Each stage involves extracting more granular entities from entities extracted in
the previous stage.</p>
      <p>For example, a set of capabilities and responsibilities are extracted as part of the initial stages, and
these are then used to extract skills and others in the later stages. This is depicted in figure 1.</p>
      <p>As entities become more granular, they become less specific to the company. For instance, the
capabilities and responsibilities are highly company specific, but also conceptually aggregated and
abstract. They may contain references to specific technologies used, processes followed, or attributes of
the company culture. These company specific entities have a high cardinality. It is extremely unlikely
that two companies will have a large overlap in these entities. As entities become more granular,
they become less specific to the company. Skills are the final stage of extraction, and are a common
currency across companies. There will be a high degree of overlap in the skills extracted from diferent
companies. These generic skills are then linked to a proprietary taxonomy of skills contained in the
Beamery Knowledge Graph.</p>
      <p>
        As well as extracting entities specific to the role, an additional benefit of the method is extracting
entities describing the company itself. These include, but are not limited to, company values, culture
and technologies. Additionally, attributes of the legal entity such as company age, size, sector and
revenue can also be found within the job descriptions. This represents a new but adjacent domain
of entities that can be extracted. These raw entities are then linked to a standardised taxonomy of
company-specific entities contained within Beamery’s proprietary taxonomy. Taxonomies are all stored
using agreed semantic web standards [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], enabling simple linking and downstream use.
      </p>
      <p>The result is multiple interlinked adjacent domains of entities.</p>
      <p>
        The extraction process is facilitated by a bespoke Large Language Model (LLM) system that has been
built to specifically extract entities from job descriptions [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>
        The system is prompted to process a custom extraction with clear assumptions and expectations
from its concepts unlike generic LLM based systems, and also facilitates automatic reconciliation with
existing canonical entities within the Beamery Knowledge Graph [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
      </p>
      <p>The resulting graph, which matches the precision of human annotators, enriches downstream tasks
with additional entities and company-specific context. This contextual alignment has significantly
accelerated user adoption of AI features, as the incorporation of company-specific details into the
explanations has made the user experience more intuitive and relevant.</p>
    </sec>
    <sec id="sec-3">
      <title>3. Conclusions</title>
      <p>The major shortcoming of the previous method is that it is limited to skills. Whilst this meant AI
systems could understand these entities, it also meant that the resulting graph was generic and not
useful for decision making. Humans consumers found little value in the graph, as it did not reflect the
reality of the company. Downstream tasks such as job matching, skills gap analysis, and workforce
planning can benefit from the richer graph. This is already deployed and in use at Beamery.</p>
      <p>Whilst job descriptions are a rich source of data, they are not the only source. Future developments
are likely to focus on extracting similar entities from other artefacts, such as resumes, competency
frameworks, and company reports.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>Kaan</given-names>
            <surname>Karakeben</surname>
          </string-name>
          , Henri Egle Sorotos, Alisa Milchevskaya, and
          <string-name>
            <given-names>Ahmad</given-names>
            <surname>Assaf</surname>
          </string-name>
          ,
          <article-title>"Rapid Graph Generation from Job Descriptions: Combining Taxonomies</article-title>
          and LLMs,"
          <year>2024</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>M.</given-names>
            <surname>Zhang</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K. N.</given-names>
            <surname>Jensen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S. D.</given-names>
            <surname>Sonniks</surname>
          </string-name>
          , and
          <string-name>
            <given-names>B.</given-names>
            <surname>Plank</surname>
          </string-name>
          , “
          <article-title>SkillSpan: Hard and Soft Skill Extraction from English Job Postings</article-title>
          ,” arXiv preprint,
          <year>2022</year>
          . arXiv:
          <volume>2204</volume>
          .
          <fpage>12811</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>L.</given-names>
            <surname>Dodds</surname>
          </string-name>
          and
          <string-name>
            <surname>I. Davis</surname>
          </string-name>
          ,
          <article-title>Linked Data Patterns: A pattern catalogue for modelling, publishing</article-title>
          ,
          <source>and consuming Linked Data</source>
          ,
          <year>2022</year>
          . Retrieved from https://patterns.dataincubator.org/book/.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <fpage>W3C</fpage>
          , “
          <article-title>SKOS Simple Knowledge Organization System Reference</article-title>
          ,”
          <year>2009</year>
          . Retrieved from https: //www.w3.org/TR/skos-reference/.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>