Embedding semantics in human resources management automation via SQL

Abstract

Among enterprise business processes, those related to HR management are characterized by conflicting issues: on one hand, the peculiarities of intellectual capital ask for rather expressive representation languages to convey as many facets as possible; on the other hand, such processes deal with huge amounts of resources to be managed. For handling HR management tasks, our approach combines the representation power of a logical language with the information processing efficiency of a DBMS. It has been implemented in a fully functioning platform, I.M.P.A.K.T., that we present here highlighting its peculiarities for three relevant business processes: skill matching, task/team composition and company core competence identification.

Appendices

Appendix A: Basic description logics

Description Logics are a family of formalisms and reasoning services widely employed for knowledge representation, in a decidable fragment of First Order Logic. We give here a limited introduction to make this paper self-contained, referring the interested reader to more comprehensive introductions [1, Ch.2].

The alphabet of each DL is made up by unary and binary predicates, known as Concept Names A ₁,A ₂,A ₃,… and Role Names r ₁,r ₂,r ₃,…, respectively. Complex Concept Descriptions—which we denote with the symbols C, D—are built (recursively) from concept and role names composed by constructors like, for example, conjunction of concepts A ₁⊓A ₂, minimum number of role fillers $(\geqslant n r)$, and many others. Intuitively, concepts represent classes of individuals of the domain of interest, and roles represent binary relations between them. Each choice of constructors defines a different DL, and characterizes such DL both in terms of expressiveness and computational complexity of reasoning tasks. In fact, it is well established that the more a DL is expressive, the harder is inferring new knowledge from its descriptions [1, Ch.3].

The expressiveness of a DL may be also enriched by the introduction of concrete features f ₁,f ₂,f ₃,…, which are binary predicates whose second argument belongs to a concrete domain D (e.g., integers, reals, strings, dates). Each domain comes along its set of unary predicates p ₁,p ₂,p ₃,…, and new classes can be constructed by requiring that an individual satisfying a predicate—for instance, a feature years representing years of experience of an individual, could be used with a predicate =₃ to form the class =₃(years) of individuals having exactly three years of experience. There is also the possibility of having n-ary predicates over n concrete domains, but we are not going to use them here. Given a DL $\mathcal {L}$, its enrichment with concrete features is usually denoted by $\mathcal {L}(\mathrm {D})$.

The semantics of concept descriptions is conveyed through an Interpretation $\mathcal {I} = (\Delta ^{\mathcal {I}}, \cdot ^{\mathcal {I}})$, where $\Delta ^{\mathcal {I}}$ is the domain of $\mathcal {I}$—a nonempty set—and $\cdot ^{\mathcal {I}}$ is an interpretation function such that, conforming to the above intuition about concepts and roles,

• $\cdot ^{\mathcal {I}}$ maps each concept name A in a set $A^{\mathcal {I}} \subseteq \Delta ^{\mathcal {I}}$

• $\cdot ^{\mathcal {I}}$ maps each role name r in a binary relation $r^{\mathcal {I}} \subseteq \Delta ^{\mathcal {I}} \times \Delta ^{\mathcal {I}}$

• if concrete features with some domain D are used, $\cdot ^{\mathcal {I}}$ maps each feature name f in a binary relation $f^{\mathcal {I}} \subseteq \Delta ^{\mathcal {I}} \times \mathrm {D}$, and each predicate p to a subset $p^{\mathcal {I}} \subseteq \mathrm {D}$.

The DL constructors we use or mention in this paper, along with their semantics, are shown in Table 4. In the last four columns, an “x” in the cell of row c (the constructor) and column $\mathcal {L}$ (the DL) means that c is used in $\mathcal {L}$, except for the last row that names $\mathcal {L}$ with concrete domain D as $\mathcal {L}(\mathrm {D})$.

Table 4 DLs set of adopted constructors

Statements about classes in the domain of interest are divided into Concept Definitions and Concept Inclusions. Definitions (denoted by A≡C) state—in the form of a complex concept C—the necessary and sufficient conditions for an individual to belong to the concept A. For instance, A ₃≡A ₁,A ₂ states that an individual belongs to A ₃ if and only if it belongs to both A ₁ and A ₂. Inclusions (denoted by $A \sqsubseteq C$) state in C only the necessary conditions for membership in A. For instance, $A_{4} \sqsubseteq A_{5}$ states that an individual belongs to A ₄ only if it belongs to A ₅. Each concept name A can appear on the left-hand side of at most one of such definitions or inclusions—if any. Concept names are divided into Defined Concepts, appearing on the left-hand side of some concept definition, and Primitive Concepts, which do not appear on the left-hand side of any definition (but can appear on the left-hand side of an inclusion). Intuitively, an individual belongs to a primitive concept A only if this membership is explicitly stated (we define later on how this can be done), while membership can be implicit for defined concepts (and reasoning can be necessary to derive it).

The set of inclusions and definitions yield a formal representation of the intensional knowledge of the domain of interest, known as TBox in DL systems, and Ontology in the generic knowledge representation framework. TBoxes containing recursive concept definitions are called cyclic (acyclic otherwise). In this paper we use only acyclic TBoxes.

An interpretation $\mathcal {I}$ is a model for a TBox $\mathcal {T}$ if it satisfies all concept definitions and inclusions in $\mathcal {T}$.

A DL system usually allows one to make statements about named individuals a ₁,a ₂,a ₃,…. This part of a DL-knowledge base is known as ABox, and statements have one of the following two forms:

• Concept assertions: C(a) states that an individual a belongs to the concept C

• Role assertions: r(a, b) states that individual a relates to the individual b through role r.

An interpretation ${\mathcal {I}}$ assigns an element $a^{\mathcal {I}} \in \Delta$ to each individual a, and is a model for an ABox ${\mathcal {A}}$ if it satisfies $(a^{\mathcal {I}}, b^{\mathcal {I}})\in r^{\mathcal {I}}$ for all role assertions $r(a, b) \in {\mathcal {A}}$ and $a^{\mathcal {I}} \in C^{\mathcal {I}}$ for all concept assertions $C(a)\in {\mathcal {A}}$.

I.M.P.A.K.T. adopts a CV representation (see Definition 2) allowing for reasoning only on $\mathcal {F}\mathcal {L}_{0}$(D) concepts which represent knowledge about our domain. The full expressiveness of the adopted $\mathcal {F}\mathcal {L}_{0}$(D) subset is explained, with the aid of constructors usage examples, in Table 5.

Table 5 The expressiveness of $\mathcal {F}\mathcal {L}_{0}$(D) (adopted by I.M.P.A.K.T.) explained with examples

1.1 A.1 Standard inference services

The most important service characterizing reasoning in DL checks for specificity hierarchies, by determining whether a concept description is more specific than another one or, formally, if there is a subsumption relation between them.

Definition 4 (Subsumption)

Given two concept descriptions C and D and a TBox $\mathcal {T}$ in a DL $\mathcal {L}$, we say that D subsumes C w.r.t. $\mathcal {T}$ if for every model of $\mathcal {T}$, $C^{\mathcal {I}}\subset D^{\mathcal {I}}$. We write $C \sqsubseteq _{\mathcal {T}} D$, or simply $C \sqsubseteq D$ if we assume an empty TBox.

For example, consider the following concept descriptions, referred to a required task and a personnel profile, respectively:

• T ₁=∀hasKnowledge.ProgrammingLanguage⊓≥₃(years)

• P ₁=∀hasKnowledge.Java⊓=₅(years)⊓∀hasLevel.ComputerScience

Considering a TBox with the two following concept inclusions $\texttt {Java}\sqsubseteq \texttt {OOP}$ and $\texttt {OOP}\sqsubseteq \texttt {ProgrammingLanguage}$, knowledge expressed by P ₁ is more specific than the one required by T ₁: according to the previous definition T ₁ subsumes P ₁.

Several widely used services may be reduced to subsumption, like concept equivalence and concept satisfiability (intuitively, a concept description is satisfiable if it can be somehow interpreted in the knowledge domain).

1.2 A.2 Non-standard inference services

Although very useful in many knowledge management settings, both subsumption and satisfiability return a yes/no answer. The first category of services provided by I.M.P.A.K.T. is instead aimed at returning referral lists of job candidates, ranked according to their ability to fulfill the job request initiating the recruiting process. In such a scenario, both explanation and belief revision turn out to be useful to cope with cases in which no perfect match exists between job request and candidates. The process performed by I.M.P.A.K.T. to return referral lists of candidates conceptually originates from the extended matchmaking approach originally introduced in our past research [16], based on Concept Abduction and Concept Contraction.

Concept Contraction is useful when C⊓D is unsatisfiable in the ontology $\mathcal {T}$, i.e. the task and the profile are not compatible with each other. In this case, as in a belief revision process, we want to retract some requirements G (for Give up) in D, to obtain a new contracted task request K (for Keep) which is compatible with D. In other words, such that K⊓D is satisfiable in $\mathcal {T}$.

Concept Abduction is instead useful when C and D are satisfiable w.r.t. each other (the task and the profile do not contain conflicting information) but subsumption does not hold (i.e. a full match is unavailable). In this case the objective is hypothesizing some explanation on which are the causes of this result.

The third I.M.P.A.K.T. service category aims at determining the strategic competence of a company, denoted by Core Competence in knowledge management literature [25]. The objective of the implementation of services for automatic Core Competence extraction is identifying a common know-how in a significant portion of company personnel, with a degree of coverage to be set by the management. To this aim, I.M.P.A.K.T. framework follows the conceptual line by Colucci et al. [15], based on Least Common Subsumer (LCS) computation.

Appendix B: Theoretical limits of knowledge compilation in SQL

The translation into SQL of a problem stated in Description Logics is subject to some theoretical limitations regarding efficiency. It is well known [59] that deciding whether a relational query Q over a database db retrieves an individual a—a problem that we denote by d b⊧Q(a) in the following—is PSpace-complete in expression complexity (fixed db, varying Q), and LogSpace-complete in data complexity (fixed Q, varying db). We now analyze the consequences of these facts for the size and complexity of our translation. We denote by |d b| the size of a database, which is proportional to the number of tuples assuming relations of bounded arity.

Given a CV C and a profile P expressed in some DL, the standard and non-standard services offered by our system imply—as a special case—deciding Subsumption between C and P, denoted by $C \sqsubseteq P$. Our approach translates:

• a CV C into a database, which we denote v(C), with a special individual a representing the person having that CV, and

• a profile P into an SQL query π(P).

Subsumption between C and P holds iff v(C)⊧π(P)(a), that is, iff a is retrieved from the database v(C) by the query π(P). Hence, subsumption in a given DL could be solved by first applying the translation, and then answering the corresponding query. Rephrasing the complexity results, for a fixed query π(P)(a), the problem v(C)⊧π(P)(a) is solvable in LogSpace considering |v(C)| as input.

Now let C, P be expressed in a DL whose subsumption problem $C \sqsubseteq P$ is ExpTime-complete, such as $\mathcal {SHIN}(D)$, which is equivalent to OWL1-DL. We observe that $C \sqsubseteq P$ iff $(C \sqcap \neg P) \sqsubseteq \bot$, where C⊓¬P is a concept which is still in $\mathcal {SHIN}(D)$, and the same is true for every DL which is closed under concept negation. If transformation v(⋅) could be performed in polynomial time, then its output v(C⊓¬P) has size polynomial in |C⊓¬P|. Since v(C⊓¬P)⊧π(⊥)(a) can be decided in space logarithmic (and hence time polynomial) in |v(C⊓¬P)|, then the ExpTime-complete problem $C \sqsubseteq P$ could be solved in polynomial time by first transforming C, P into v(C⊓¬P), then ⊥ into π(⊥)—a constant since ⊥ is fixed—and then deciding v(C⊓¬P)⊧π(⊥)(a). The same argument could be repeated for DLs in which $C \sqsubseteq \bot$ (concept satisfiability) is a problem in any complexity class a̧bove PTime, such as NP, or co-NP, or PSpace. We can conclude with the following theorem, whose proof is in the above argument.

Theorem 1

Let $\mathcal {L}$ be a DL whose subsumption problem is complete for some complexity class $\mathcal {C}$ , and such that either $\mathcal {L}$ is closed under concept negation, or $\mathcal {L}$ contains ⊥. If the transformation v(⋅) could be computed in polynomial time, then $\mathcal {C} \subseteq \textsc {PTime}$.

Recall that PTime is provably strictly contained in ExpTime, hence the above theorem in this case says—by contraposition—that v(⋅) cannot run in polynomial time at all, e.g., for $\mathcal {L} = \mathcal {SHIN}(D)$. For $\mathcal {C}$ below ExpTime and above PTime, e.g., $\mathcal {C} = \textsc {NP}$, the claim is conditioned to $\mathcal {C} \subseteq \textsc {PTime}$, which is considered unlikely.

Regarding the transformation π(⋅), a similar argument could be developed. In fact, $C \sqsubseteq P$ iff $\top \sqsubseteq (\neg C \sqcup P)$, where ¬C⊔P is a concept that still belongs to a DL which is at least as expressive as $\mathcal {ALC}$. So, one could decide $C \sqsubseteq P$ by first transforming ⊤ into v(⊤)—some constant database—then transforming ¬C⊔P into π(¬C⊔P), and then decide v(⊤)⊧π(¬C⊔P)(a). The latter problem can be solved in PSpace with respect to |π(¬C⊔P)|. If π(⋅) could be performed in polynomial time, it would yield a query π(¬C⊔P) whose size is polynomial in |¬C⊔P|. Overall, $C \sqsubseteq P$ would be a problem solvable in PSpace also with respect to the size of C and P.

Theorem 2

Let $\mathcal {L}$ be a DL whose subsumption problem is complete for some complexity class $\mathcal {C}$ , and such that $\mathcal {L}$ is closed under concept disjunction and negation. If the transformation π(⋅) could be computed in polynomial time, then $\mathcal {C} \subseteq \textsc {PSpace}$.

Hence, for languages like $\mathcal {S}\mathcal {H}\mathcal {I}\mathcal {N}(D)$, finding a polynomial-time transformation π(⋅) would imply ExpTime⊆PSpace, a statement that—although not yet disproved—is considered very unlikely in complexity theory.

We conclude that to look for polynomial-time transformations, one should limit the choice of the DL to those in which $C \sqsubseteq P$ is a problem in PTime (for polynomial-time v(⋅)) or in PSpace (for polynomial-time π(⋅)). It seems unreasonable to use different DLs for curricula and profiles, so the stronger PTime-condition dominates the choice. This motivates our choice of ${\mathcal {F}\mathcal {L}_{0}}$ for expressing curricula and profiles, since ${\mathcal {F}\mathcal {L}_{0}}$ is one of the DLs having a polynomial-time subsumption problem.

Appendix C: Alphabet for profile definition

The complete list of possible conjuncts of a profile P is reported Table 6.

Table 6 Skill reference template

Notice that for each profile conjunct in which the feature years is defined, it is mandatory to specify also the feature lastdate, in order to be aware whether the experience level is up to date. Moreover, the proposed approach considers only features of the form = _n p in the profile storage phase, whereas it manages features p in the form { ≤ _n p,≥ _n p,= _n p} in the reasoning phase: intuitively a candidate specifying her level of work experience sets the years to a natural number, while the management of information in the profiles may need the whole set of order relations.

Appendix D: Candidate profiles example set

1 - Mario Rossi

• Level: Computer Science Engineering (mark 110), Secondary School (mark 60), Master Degree

• JobTitle: Database Administrator(4 years), Project Manager (2 years)

• Industry: Banking (4 years), IT and Telematics Applications (2 years)

• Knowledge: Cplusplus (5 years), Java (5 years), Visual Basic(5 years)

• ComplementarySkill: Cooperation (5 years), LeaderShip (5 years)

• Language: English (excellent writing, verbal and reading), French (good writing)

2 - Daniela Bianchi

• Level: Computer Science Engineering (mark 110), Secondary School (mark 60), Bachelor

• JobTitle: Database administrator (4 years), Project Manager (2 years)

• Industry: Banking (4 years), IT and Telematics Applications (2 years)

• Knowledge: Cplusplus (2 years), Java (6 years), Visual Basic (1 years)

• ComplementarySkill: Cooperation (5 years), LeaderShip (5 years)

• Language: English (excellent verbal, writing and reading), French (good writing)

3 - Lucio Battista

• Level:Managerial Engineering (mark 104), Secondary School (mark 60), Master Degree, CCDP

• JobTitle: Database Administrator (4 years), Project Manager (2 years)

• Industry: Banking (4 years), IT and Telematics Applications (2 years)

• Knowledge: DBMS (2 years)

• ComplementarySkill: Cooperation (5 years), LeaderShip (5 years)

• Language: English (excellent verbal, writing and reading), French (good writing)

4 - Mariangela Porro

• Level: Managerial Engineering (mark 104), Secondary School (mark 60), Master Degree, Master after master

• JobTitle: Database Administrator (4 years), Network computer systems Administrator (4 years)

• Industry: Banking (4 years), IT and Telematics Applications (2 years)

• Knowledge: DBMS (2 years), Internet Technologies (2 years)

• ComplementarySkill: Learning Strategy (8 years)

• Language: English (good verbal, writing and reading)

5 - Nicola Marco

• Level: Electronics Engineering (mark 104), Bachelor, Master after Master

• JobTitle: Database Administrator (2 years), Network computer systems Administrator (2 years)

• Industry: Banking (4 years), IT and Telematics Applications (2 years)

• Knowledge: DBMS (5 years), Internet Technologies (5 years)

• ComplementarySkill: Learning Strategy (8 years)

• Language: English (good writing, verbal and reading)

6 - Carla Buono

• Level: Statistics (mark 106), Master Degree, Master after Master

• JobTitle: Cost Estimator (4 years), Budget Analysts (10 years)

• Industry: Banking (4 years), Business Strategic Management (2 years), Finance Banking (1 years)

• Knowledge: Sales and Marketing (2 years), Administration and Management (4 years), Mathematics (10 years)

• ComplementarySkill: Critical thinking (8 years), monitoring (8 years)

• Language: English (excellent writing, verbal and reading knowledge), French (good writing knowledge)

7 - Marcello Cannone

• Level: Managerial Engineering Degree (mark 106)

• JobTitle: Training and Development Manager (2 years)

• Industry: Sales, Banking and Consumer Lending

• Knowledge: Economics and Accounting (4 years), WorkflowManagement

• ComplementarySkill: Visualization, Spatial orientation, Verbal abilities

• Language: English, German (excellent writing and reading knowledge, basic verbal knowledge)

8 - Carmelo Piccolo

• Level: Mechanical Engineering (mark 79)

• JobTitle: Patternmaker Metal and Plastic, Process Planner (6 years)

• Industry: Engineering Services (14 years), Clothing and Textile Manufacturing (11 years)

• Knowledge: VBScript, Process Performance Monitoring

• ComplementarySkill: Systems Skills, Complex problem solving (10 years), Visual Color Discrimination (14 years)

• Language: English (basic writing knowledge), French (excellent reading knowledge)

9 - Elena Pomarico

• Level: Computer Science Engineering, Secondary School, Bachelor

• JobTitle: Database Administrator, Project Manager

• Industry: Banking, IT and Telematics Applications

• Knowledge: CplusPlus, Java, Visual Basic

• ComplementarySkill: Cooperation, Leadership

• Language: English (excellent writing, reading and verbal knowledge), French (good writing knowledge)

10 - Domenico De Palo

• Level: Computer Science Engineering (mark 110), Doctoral Degree

• JobTitle: Project Manager (4 years), Teachers (4 years), Database Administrator (4 years)

• Knowledge: OOprogramming (6 years), Artificial intelligence (4 years), Internet technologies (4 years)

• ComplementarySkill: Cooperation (6 years), Complex problem solving (5 years)

• Language: English (excellent verbal knowledge)