SFIA 9 in RDF

‍

Motivations

At Semantic Partners we like to continuously learn and use not only tools, but also models (reference ontologies and vocabularies for different domains). Internally and for our clients we often need to keep at hand the various connections between types of projects, of vendors, of tools, of people, of specialties. We realised how even a specialised consultancy like us hosts a good variety of competences: some of us specialise in ontology design, others have their hands in software and engineering (either for data integration or for product building), others have strategy roles, and so on. A workforce (and even a single person on their own) is an intricate connection of orthogonal aspects. It is not trivial to distinguish between virtuosity, seniority, specialty and other facets, and to build a clean and terse picture of what these facets even mean, you need a good model for competences. It is not something that you come out with in just one sleepless night. Reinventing the wheel is never a good idea. Not in physics, not in knowledge engineering. Someone else has already learned the intricacies of these concepts the hard way, and they are what we referred to.

A mini-intro to SFIA

We came across and used SFIA before, because it is widely used, especially in government tenders across the world. SFIA is a competency framework, aimed mainly at the digital domain. It permits to express competences (or skills) along a few axes, such as the level of responsibility, experience and autonomy.

Compared to other frameworks, such as ESCO, it does not try to provide a comprehensive list of occupations or roles. Its philosophy is to let an organisation define their own roles using the competency framework. For this reason, SFIA is a relatively simple and terse dataset of skills and descriptions of their levels.

We refer readers to the SFIA pages for a SFIA introduction, but we summarise here some core ideas:

• SFIA defines 7 general levels of responsibility (from “Follow” to “Set strategy”). Beside an overall description, each level has specific descriptions by “attribute” (such as autonomy, knowledge, leadership, creativity, and others)
• About 150 skills are enumerated and described (some examples: User acceptance testing, Customer Experience, Contract management, Software configuration…)
• Each skill is also described at each level, specifying, in words, what is expected to master that skill at that level (for ex., software configuration level of mastery might go from assisting senior colleagues, up to setting practices for the entire organisation).
• Not all skills are present at each level: some skills might start from, say, Level 3 (“Apply”) because their nature requires a certain level of autonomy and knowledge to start with. This is the case for example with Benefits management

SFIA is published and maintained by a community of experts from around the world. It does not represent any particular institution, and it is open to reviews and iterations, as it has been since its first version was published in 2000. It is openly accessible online as HTML pages, PDFs and as a spreadsheet.

During the time of this work, the UK Royal Air Force gave a presentation on how they use SFIA internally: you can find the recording on the SFIA website – the page also provides a link for people to get in touch and join in the conversation.

‍

‍

What it is used for

SFIA, its codes and descriptions, can be used as a reference model to enable people and software systems to assess skills (and consequently plan new hirings or internal career development) using an inter-operable language.

See again the SFIA pages for a more comprehensive overview.

Why RDF?

We studied the SFIA knowledge model, and came up with a translation to RDF. We presented our idea to SFIA, who have been very helpful in facilitating it. At Semantic Partners we work with RDF all the time, as we believe in some inherent advantages it gives. But let us list some of them:

• RDF is a formal W3C standard to represent, share, and publish knowledge (both schemas and facts). It specialises at representing models where entities are connected to each other in a graph-like manner (in our case, skills with their levels, and how they are categorised)
• A model represented in RDF is incredibly easy to extend and adjust. When SFIA 9 came out, we adapted our RDF already drafted conversion of SFIA from version 8 to 9 in about one day of work
• When the domain modelled is highly connected, representing it on tables becomes cumbersome and technically challenging very quickly. How to represent multi-values? What identifiers should we use as keys between tables? An apparently dull spreadsheet can require the same decisions and design choices of a SQL database very - decisions which if ignored, give rise to very messy (both for humans and machines) sheets. This happens way less with a graph, where each node is naturally described with multi-value fields, easily connected to other nodes, and ids are unique IRIs.
• RDF has a formal underpinning and a standardised software stack and query language (SPARQL) that permits, very easily, to query and navigate the graph of connections lying in the data
• Ontologies and Knowledge Graphs, which have seen a resurgence as companions to genAI applications, are naturally written in RDF (not necessarily: another paradigm being the Property Graph Model - which is equivalent in most applications)
• As we will see, SFIA looks very simple in RDF, as (we argue) RDF can be quite readable not only for machines, but even for humans (although it is not meant to be)

‍

Our conversion

The machine-readable version of the SFIA 9 distribution comes as a spreadsheet of 3 sheets:

• Levels of Responsibilities (the 7 levels and their descriptions)
• Attributes (further describing the 7 levels)
• Skills (the skills, with their codes and descriptions at their various levels)

Let us see an example of the data already converted to RDF (Turtle serialisation format).

Then, we will describe our modelling choices.

@prefix attributes: <https://sfia-online.org/en/shortcode/9/> .
@prefix levels: <https://sfia-online.org/en/lor/9/> .
@prefix skills: <https://sfia-online.org/en/skillcode/9/> .
@prefix skilllevels: <https://rdf.sfia-online.org/9/skilllevels/> .
@prefix categories: <https://rdf.sfia-online.org/9/categories/> .
@prefix sfia: <https://sfia-online.org/ontology/> .

# Property (attribute) definition
attributes:AUTO a owl:AnnotationProperty ;
    rdfs:label "Autonomy"@en ;
    rdfs:comment "The level of independence, [..]."@en ;
    skos:notation "AUTO" ;
    sfia:attributeGuidanceNotes "...."@en ;
    sfia:attributeType "Attributes"@en .

# Level of Responsibility
levels:2 a sfia:Level;
    skos:inScheme sfia:LorScheme ;
    skos:notation 1 ;
    attributes:ADAP "Adjusts to different team dynamics ..[..]"@en ;
    attributes:AUTO "Works under routine direction [..]"@en ;
    # (other attributes...)
    sfia:levelEssence "Provides assistance to others, [..]"@en ;
    sfia:levelGuidingPhrase "Assist"@en .

# Skill definition
skills:ITSP a :Skill;
    rdfs:label "Strategic planning"@en ;
    skos:notation "ITSP" ;
   sfia:definedAtLevel skilllevels:ITSP_4,
        skilllevels:ITSP_5,
        skilllevels:ITSP_6,
        skilllevels:ITSP_7 ;
sfia:skillCategory categories:strategy_and_planning ;
    sfia:skillDescription "Creating and maintaining organisational-level strategies to align overall business plans, actions and resources with high-level business objectives."@en ;
    sfia:skillNotes ".. focused on enterprise-wide strategic planning and management, [..]"@en .


# Skill level
skilllevels:ITSP_4 a :SkillLevel;
skos:notation "ITSP_4" ;
sfia:skillLevel levels:4 ;
sfia:skillLevelDescription "Contributes to the collection and analysis of information [..]"@en .

‍

As you can see, we used RDF properties (such as rdfs:label) commonly known and used in the community, when appropriate. This is mainly because, in the RDF world, people would expect to find labels expressed by rdfs:label or other similar common construct – and that is one of the advantages of using RDF and its Linked Data principles.

Skills and Levels

No person is a “level X” in general, but always in relation to a skill. I may be level 3 in one skill and level 4 in another. However, these 7 levels constitute an abstract vocabulary of their own, that we modelled as a "flat" (1-level only) SKOS concept scheme.

SFIA provides general descriptions for each of them.

SFIA provides resolvable URLs for the levels, for ex. https://sfia-online.org/en/lor/9/1 .

In SFIA, Skills are generic skills, such as "Strategic planning" (code ITSP). In RDF, we treat `Skill` as a class of objects (the various skills).

We introduce the class `SkillLevel`, whose instances are skills at particular levels. For example, a person Johanna might have, at a given point in her life, ITSP_5, that is, a level 5 in Strategic planning.

SFIA provides descriptions and notes both for general skills (ex. `ITSP`) and their embodiment at a level (ex. ITSP_4). SFIA provides resolvable URLs for the skills, for ex. https://sfia-online.org/en/skillcode/9/ITSP .

Skills' categories are given by SFIA to permit grouping skills under topics, for ease of classification, retrievability or navigation. They constitute a mini-taxonomy of their own, so we decided to model them as a (small) SKOS concept scheme. In the current SFIA release, there are 6 top-level categories, with several sub-categories under them. For example:

categories:development_and_implementation a sfia:Category ;
    skos:inScheme sfia:CategoryScheme ;
    skos:prefLabel "Development and implementation"@en .

categories:user_centred_design a sfia:Category ;
    skos:broader categories:development_and_implementation ;
    skos:inScheme sfia:CategoryScheme ;
    skos:prefLabel "User centred design"@en .

‍

We see here that "User centred design" is a sub-category of the broader category "Development and implementation".

Attributes

Attributes are used by SFIA to describe each of the 7 levels of responsibilities in detail. Each level has a general description (the "essence" of the level) but also a description under several dimensions (adaptability, autonomy, influence, knowledge, etc.) describing what it means to be adaptable, autonomous, influential, etc., at that level.

When converting to RDF, we decided to render Attributes as RDF textual properties on the levels of responsibilities.

An alternative decision could have been to make them objects (nodes), but that would have made the model heavier, without a clear advantage in terms of Knowledge Representation.

SFIA provides resolvable URLs for attributes, for ex. https://sfia-online.org/en/shortcode/9/AUTO .

Linked Data

This conversion is meant to produce an RDF distribution for a given SFIA 9 published release.

Even if SFIA does not expose Linked-Data resolvable IRIs, we designed this conversion so that these IRIs are both memorable (transparent) and consistent with a Linked Data approach in mind.

We give here a summary of the IRI schemes used.

We used `camelCase` naming conventions except for categories, where we "hash" the category name with underscores.

• For Skills: https://rdf.sfia-online.org/9/skills/<skill_code>
• ‍For Attributes: https://rdf.sfia-online.org/9/attributes/<attribute_code>‍
• For levels: https://rdf.sfia-online.org/9/lor/<level>‍
• Skill Levels: https://rdf.sfia-online.org/9/skilllevels/ACIN_2‍
• Categories: https://rdf.sfia-online.org/9/categories/user_centred_design‍
• For other properties and classes: https://rdf.sfia-online.org/9/ontology/‍
  • ex. of a property: `https://rdf.sfia-online.org/9/ontology/skillDescription`‍
  • ex. of a class: `https://rdf.sfia-online.org/9/ontology/SkillLevel`

As for SFIA HTML pages, we provide them in RDF with a `url` property. They follow the following conventions:

• Skills: `https://sfia-online.org/en/skillcode/9/_<skill_code>_`‍
• Attributes: `https://sfia-online.org/en/shortcode/9/_<attribute_code>_`‍
• Levels: `https://sfia-online.org/en/lor/9/_<level>_`

‍

SFIA does not expose individual HTML pages for skill levels – skill levels are a specificity of our adapted model.

The `en` (language) and `9` (version part of the path) are optional, and when not provided they resolve to these two defaults.

The code to generate the SFIA RDF file in accordance with this translation is available on our GitHub. To produce the RDF file you will need the spreadsheet of the SFIA distribution file (see the SFIA website). SFIA will also make this same RDF available on their website.

Let us use it!

Let us use this model, and use it to define one of the internal Semantic Partners’ roles. The following Turtle defines a Senior Ontologist as a set of SFIA Skill Levels, some required (would we normally hire without them? Probably not) and some optional (nice to have).

Notice the “normally”: the philosophy behind these types of definitions is not to give rigid necessary and sufficient conditions for a role, but rather to capture a prototypical description of our idea for the role. In real life, the presence of some skills offset or compensate for the lack of others, and levels are not necessarily easy to capture.

Other aspects that are not captured here are behavioural aspects, for which there are specific models.

@prefix sp: <https://data.semanticpartners.com/> .
@prefix skilllevels: <https://rdf.sfia-online.org/9/skilllevels/> .

sp:seniorInformationArchitect a sp:Role;
    rdfs:label "Senior Information Architect"@en;
    sp:requiredSfiaLevel
        skilllevels:KNOW_5,
        skilllevels:DATM_4,
        skilllevels:TECH_5,
        skilllevels:METL_4,
        skilllevels:RLMT_4,
        skilllevels:TEST_3,
        skilllevels:DTAN_3,
        skilllevels:BUSA_3,
        skilllevels:ETDL_2,
        skilllevels:REQM_2,
        skilllevels:SWDN_2,
    ;
    sp:optionalSfiaLevel
        skilllevels:SINT_2,
        skilllevels:PROG_2
    .

‍

Unfolding the codes along their SFIA labels and attributes would give a more lengthy description of the role. Let us do it for a couple of them:

DATM_4: (Data governance 4): "Devises and implements data governance and master data management processes for specific subsets of data. 

Assesses the integrity of data from multiple sources. 

Advises on transformation of data between formats or media. Maintains and implements data handling procedures. 

Enables data availability, integrity and searchability through formal data and metadata structures and protection measures."

RLMT_4: (Stakeholder relationship management 4): "Deals with problems and issues, managing resolutions, corrective actions, lessons learned and the collection and dissemination of relevant information. 

Implements stakeholder engagement/communications plans.  Collects and uses feedback from customers and stakeholders to help measure the effectiveness of stakeholder management. 

Helps develop and enhance customer and stakeholder relationships."

And so on.

If you do that, and maybe ask an LLM for a summary, you would obtain something like this:

As a Senior Information Architect in our consultancy company, you'll be instrumental in driving knowledge management initiatives at various levels, from programmatic to team-based projects. Your expertise will enable you to implement robust data management processes, ensuring the integrity and accessibility of information across multiple sources. You'll provide definitive advice in your specialist area, consolidating expertise from diverse sources to achieve organizational objectives.

A key aspect of this role involves managing stakeholder relationships effectively. You'll deal with issues proactively, collect feedback, and enhance customer relationships. While you won't be heavily involved in testing or software development tasks, you'll have a solid understanding of these areas, enabling you to contribute to requirements definition and simple software design when needed.

Your ability to learn and adapt quickly will be crucial for success in this role. You'll work under direction to support learning activities and assist in creating learning environments. Your proficiency in standard techniques for eliciting, specifying, and documenting requirements will also prove valuable in contributing to the definition and management of requirements within your projects.

A bit generic, but useful to show how modern tools and models permit passing relatively easily, and relatively consistently, from the structured to the unstructured, from codes and taxonomies to text and descriptions, from database queries to keyword or vector search, from analysis to synthesis.

In another article we will see some use cases where we apply semantic technologies to see SFIA in action.