Relations

Definition

Types of relations found between concepts within the Taxonomy.

Description

Relations in the Taxonomy database are expressed as edges between different concepts. Essentially, the various relation types are based on SKOS and inherit the properties described there. Local relation types have also been defined as needed.

Relation types

A complete list of existing types of relations can be found through the Taxonomy API.

Please note that some relation types are not included in the list from the Taxonomy API. Relation types that are inverses of each other are not explicitly expressed in the Taxonomy database. For example, broader is used but not narrower. However, if a broader relationship exists from concept A to concept B, then the narrower relationship is implicitly present between concept B and concept A.

In the example below, the relationship between the occupation name concept Dancer and the SSYK-4 group Choreographers and dancers has been defined as broader.

graph TB;
    subgraph "explicit relation" 
    A --broader--> B
    A("Dansare (occupation-name concept)")
    B("Koreografer och dansare (ssyk-level-4 concept)");
    end

Since narrower acts as an inverse of broader, such a relation is present implicitly from the other direction.

graph TB;
    subgraph "implicit relation" 
    B --narrower--> A
    A("Dansare (occupation-name concept)")
    B("Koreografer och dansare (ssyk-level-4 concept)");
    end 

When using the Taxonomy API, both relation types are valid, see:

query MyQuery {
  concepts(id: "euJP_wxo_skF") {
    id
    preferred_label
    type
    broader (id: "gmRr_7tt_eHj") {
      id
      preferred_label
      type
    }
  }
}

and:

query MyQuery {
  concepts(id: "gmRr_7tt_eHj") {
    id
    preferred_label
    type
    narrower (id: "euJP_wxo_skF") {
      id
      preferred_label
      type
    }
  }
}

SKOS

A majority of the relation types in the Taxonomy have their origin in SKOS. The properties of the relationship types, as defined in SKOS, also apply in the Taxonomy. See links in the table below for more information.

Mapping relations

The mapping relations referenced in SKOS are used to define relations between classifications:

The mapping relations are primarily found between concepts in the Taxonomy and ESCO (e.g. between skills and ESCO skills).

Other relation types

Additionally, there are a number of relation types that are specific to the Taxonomy. These are listed below.

substitutability

The substitutability relation can be expressed between two occupation-name concepts, and can be of either high or low. The levels are set in the substitutability-percentage attribute, where low corresponds to 25 and high to 75.

A high substitutability-percentage indicates a high degree of similarity in work tasks carried out in the two occupation-name concepts. In terms of recruitment, the two concepts may be deemed as close to, albeit not fully, interchangable.

A low substitutability-percentage indicates some degree of similarity in work tasks carried out in the two occupation-name concepts. In terms of recrutiment, some education or training may be needed in order to bridge the gap between the two concepts.

A substitutability relation should be seen as an indication that there are apparent similarities between two occupation-name concepts. The relation set is, however, neither exact nor all-encompassing. The relations should be viewed as common sense-classification, as they do not rely on an actual classification of work tasks. A relation might be created as a result from a discussion with a stakeholder/industry expert or through researching sources describing the two occupation-name concepts at hand.

Substitutability is an example of a non-symmetric type of relationship. This means that a relation from occupation-name A to occupation-name B does not imply a relation from occupation-name B to occupation-name A, i.e., the reverse. This may seem illogical considering that the relation is based on a similarity in work tasks between two occupation-name concepts. This is because the relations are derived from a recruitment perspective, where the reasoning has been that the substituted occupation-name-concept (in relation to the occupation-name-concept that an employer specifies in an ad) to a high or some degree could potentially be suitable for the advertised position. In a digital matching context, it then becomes possible to broaden the pool of job seekers considered for the advertised position. The idea is perhaps more easily illustrated with an example.

In the case of Läkemedelskonsulent and Läkare, there is a substitutability relation (low) from Läkare to Läkemedelskonsulent, but not the other way around. The assessment has been that some of the knowledge that a Läkare possesses can be transferred to the context in which a Läkemedelskonsulent finds carries out their work, and that when recruiting a Läkemedelskonsulent, it could be possible to broaden the search to include job seekers registered as Läkare.

The same reasoning cannot be applied the other way around however, since we cannot assume that the Läkemedelskonsulent has a medical licence.

possible-combinations

Relations labeled possible-combinations are used solely to show possible combinations of education level (sun-education-level-2) and education field (sun-education-field-3) concepts, primarily when registering a job seeker's highest education, but also for representing educational requirements in job ads.

The relations are based on mappings, provided by SCB (Statistics Sweden) between the two SUN structures (field and education), and are based on information about how actual educations are coded.

If no relation exists between a sun-education-level-2 and sun-education-field-3 concept, combining the two is not possible.

unlikely-combinations

Relations labeled as unlikely-combinations are used solely to show possible combinations of education level (sun-education-level-2) and education field (sun-education-field-3) concepts, primarily when registering a job seeker's highest education, but also for representing educational requirements in job ads.

The relations are based on mappings, provided by SCB (Statistics Sweden) between the two SUN structures (field and education), and are based on information about how actual educations are coded.

A combination that is unlikely means that there are educations coded with it, albeit very few. The idea of representing this information in the Taxonomy is so that users can build interface solutions that inform the end user (for example, the job seeker) that the chosen combination should only be used in special cases.

On relations and deprecation

Presently, there is no support for deprecation in regards to relations. This means that a removed relation cannot be traced (other than in logs) in versions after the removal occurred.

When a concept is deprecated, we make sure that its relations are not removed so that when interacting with the Taxonomy, it should be possible to look up a deprecated concept and see how it previously related to other concepts.