Juri L. De Coi, Eelco Herder, Arne Koesling, Christoph Lofi,
Daniel Olmedilla, Odysseas Papapetrou and Wolf Siberski
L3S Research Center and University of Hannover, Hannover, Germany
Competence, competency, model, gap analisys, lifelong learning.
Modeling competences is an integral part of many Human Resource (HR) and e-Learning related activities.
HR departments use competence descriptions to define requirements needed for performing specific tasks or
jobs. The same competences are acquired by employees and applicants by e.g. experience or certifications.
Typically, HR departments need to match such required and acquired competences in order to nd suitable
candidates. In e-Learning a similar situation arises. Curricula or training programmes need to describe pre-
requisites that must be fulfilled before joining and the competences that will be acquired after successful
completion. This paper analyses the limitations and extends existing approaches for modeling competences in
order to allow (semi-)automatic competence matching.
Nowadays, people mobility has increased. Learn-
ers may study abroad with the benefits of improving
their language skills, receiving a better certification,
or specializing in a topic not available in their re-
gions. The same applies to the labour market. Peo-
ple do not need to restrict themselves to their city or
region while seeking for a job but may consider of-
fers in other countries, too. This situation compli-
cates the already difficult job of managers in learn-
ing organizations and Human Resource (HR) depart-
ments to decide who may have the right qualifica-
tions to join a project or the company itself. For
learning organizations, requirements to join the pro-
gramme must be taken into account. For example, an
applicant needs to possess a Bachelor degree to apply
for Master studies; in order to attend an expert course
on a topic, a certification on a basic level may be re-
quired. Furthermore, assuming that an applicant ful-
fills such requirements, exemptions could be granted
for parts of the programme that are similar to ear-
This research was partly funded by the
EU TENCompetence project (FP6-IST-02787)
(http://www.tencompetence.org) and EU PROLIX project
(FP6-IST-027905) (http://www.prolixproject.org/).
lier followed courses. Imagine a Mathematician start-
ing a Computer Science degree. Most likely, courses
like Algebra and Statistics could be exempted. In
the case of Human Resource departments, the task
is equally complex. HR experts need to match ap-
plicant or employee experience and knowledge with
the requirements of a job offer or a project, including
both mandatory requirements and desired ones (e.g.,
Business English is required and French would be a
plus). Currently, all these competence matches have
to be performed manually, with hardly any guidelines
or support. One important reason for this is that there
are currently no sufficiently expressive common for-
mats for the representation of competences, which is
needed for complex competence profiles and require-
ments. Some initiatives, such as the IEEE Reusable
Competency Definition (IEEE RCD, 2005) and HR-
XML (HR-XML, 2004), have done initial steps to de-
fine common models and schemas for interoperabil-
ity, but their current work lacks some important infor-
mation that is required for competence matching, like
proficiency levels, context (cf. Section 3) or mech-
anisms for increasing reusability. In this paper, we
enhance and extend the work developed under vari-
ous initiatives and introduce a model for represent-
ing competences with their relationships as well as
L. De Coi J., Herder E., Koesling A., Lofi C., Olmedilla D., Papapetrou O. and Siberski W. (2007).
In Proceedings of the Third International Conference on Web Information Systems and Technologies - Society, e-Business and e-Government /
e-Learning, pages 304-312
DOI: 10.5220/0001272603040312
usage profiles (such as profiles for job requirements
description or for learner achievements description).
This model provides the basis for allowing advanced
(semi-)automatic competence matching and gap anal-
This paper is organized as follows: section 2 clarifies
the terms used throughout the paper and briefly in-
troduces our requirements for modeling competences.
Section 3 provides an overview of existing modeling
specifications, and section 4 describes our modeling
approach for competences in a more detailed manner.
Section 5 introduces competence profiles (collections
of competences) which represent the most visible as-
pect of competence modeling in real-life applications.
Section 6 gives an example on how a simple profile
and related competences can be modeled. Finally,
section 7 concludes this paper with a summary and
an outlook on future work.
In this work we adopt the definition of competence
as “effective performance within a domain/context at
different levels of proficiency”, as given in (Chee-
tam and Chivers, 2005). Note that there exists some
confusion on the term competency
in the literature.
(IEEE RCD, 2005; IMS RDCEO, 2002) define the
stricter term of competency as “any form of knowl-
edge, skill, attitude, ability, or learning objective that
can be described in a context of learning, education
or training”. This definition is insufficiently expres-
sive for competence gap analysis. For example, it is
not clear if “piloting” covers both the ability to pilot a
small plane and to pilot a big passenger airplane. Or
if the competency “English writing skills” represents
a specific level such as intermediate, fluent, native
or simply the existence of the competency. In fact,
if that information becomes part of the competency
definition, its reusability is drastically reduced (with
the consequence of, e.g., having different competency
definitions for each context in which a competency is
applied, and for any proficiency level and proficiency
level scale). The definition given in (HR-XML, 2004)
tries to extend the previous one: A specific, iden-
tifiable, definable, and measurable knowledge, skill,
ability and/or other deployment-related characteristic
(e.g., attitude, behavior, physical ability) which a hu-
man resource may possess and which is necessary for,
or material to, the performance of an activity within
a specific business context”. In this case, “measur-
able” indicates a relationship with a specific profi-
The reader is alerted for the distinction between the two
terms, competence and competency
Figure 1: Competence as a combination of competency,
proficiency level and context.
ciency level
and competency now applies only to the
business context. In any case, since context is im-
plicit, the models proposed from these specifications
do not include context information.
As stated above, current approaches to model-
ing competencies do not explicitly address profi-
ciency level and context. On the contrary, we be-
lieve that competency, proficiency level and context
are three different dimensions that should be mod-
eled separately in order to maximize their reuse.
For example, the same competencies may be used
in different contexts, or the same proficiency level
scales may be reused among different certifications.
The same applies to contexts (or “domain models”),
which in many situations already exist and there-
fore may be reused by competences. Therefore, ac-
cording to what stated above, we model competence
(plural:competences) as a three-dimensional variable,
made up of a competency (plural:competencies), a
proficiency level and a context (see figure 1). For
example, “Fluent Business English” would be com-
posed of the competency “English”, the proficiency
level “Fluent” and the context “Business”.
For sake of clarity, and in order to avoid confusion
between the terms competence and competency, we
may use competency and skill interchangeably here-
after. However the reader should be aware that skill is
not a synonym for competency, as it only covers part
of its scope.
There exist some standardization efforts on modelling
competencies. These efforts focus on different as-
pects related to competency: competencies as such,
competency profiles and relationships among compe-
Although they later refer to it as “grade”, which is dif-
ferent from proficiency level - see section 5.1
The IMS Reusable Definition of Competencies or
Educational Objective (IMS RDCEO, 2002) and the
later IEEE Reusable Competency Definition (IEEE
RCD, 2005) (based on IMS RDCEO) focus on
reusable competency definitions. The primary idea is
to build central repositories which define competen-
cies for certain communities. These definitions can
be referenced by external data structures, encouraging
interoperability and reusability. However, IEEE RCD
lacks information on context and proficiencylevel and
does not allow relationships or recursive dependen-
cies among competencies.
HR-XML focuses on the modeling of a wide range
of information related to human resource tasks (like
contact data or aspects of the curriculum vitae). The
work performed in HR-XML Measurable Competen-
cies (HR-XML, 2004) tries to define profiles in order
to use such competency definitions. It specifies data
sets like job requirement profiles (which describe the
competencies that a person is required to have) or per-
sonal competency profiles (which describe the com-
petencies a person has). Such profiles are composed
of evidences (either required or acquired) referring to
competency definitions (e.g., IEEE RCD). Unfortu-
nately, the proposed model does not clearly separate
required and acquired profiles. The consequence is
that an acquired competency could have mandatory
and optional elements according to the model. Fur-
thermore, it is unclear why a competencyis composed
of several evidences: since a competency is a reusable
object, evidences should rather represent a require-
ment or demonstrate the acquirance of a competency.
Hence, the evidences should refer to or contain com-
petency definitions and not vice versa.
The Simple Reusable Competency Map (SRCM,
2006) tries to model relationships between competen-
cies. A map can contain information about depen-
dencies/equivalences among competencies, including
the composition of complex competencies from sim-
pler ones. In SRCM, relationships are modeled us-
ing a directed acyclic graph. However, the semantics
of the model proposed in SRCM is confusing. Re-
lationships among different nodes may have different
meanings: composition, equivalence or order depen-
dency. This leads to confusion when modeling tasks
as well as when creating algorithms to use such in-
formation. Furthermore, combination and weighting
of competencies is not clearly defined, and external
references to the maps (e.g., from profiles) must point
to the root (and not to any node), therefore requiring
the traversal of the graph until the appropriate node
is found. Moreover, in this paper we argue that it is
not possible to model relationships among competen-
cies, because proficiency level and context have to be
considered. For example, statistics knowledge may
be a requisite for becoming a computer scientist or a
sociologist. However, the proficiency level required
and the context in which the competency is applied
are completely different, hence making impossible to
create relationships directly among competencies.
In OntoProPer (Sure et al., 2000), profiles are
described by flat vectors containing weighted skills
(where weights grow from 0 to 3), which are ex-
pressed as labels. Weights represent importance if ap-
plied to requirements or skill level if applied to ac-
quired skills. The system itself mainly focuses on
profile matching and introduces an automated way
of building and maintaining profiles based on ontolo-
gies. (Colucci et al., 2003) describes an ontology-
based semantic matchmaking(using Description Log-
ics) between skills demand and supply. In (Lefebvre
et al., 2005), which also defines a competence on-
tology for domain knowledge dissemination and re-
trieval, a competence is related to capabilities, skills
and expertise (measured by levels growing from 1 to
5). Although this approach is closer to our definition
of competence, still the context is not tackled, the re-
lationships are defined at the skill level and the profi-
ciency levels are not flexible enough.
In this section we introduce a model for representing a
competence with a broader and clearly defined view.
We base this model on the three dimensions that a
competence is composed of: competency, proficiency
level and context. We first describe each dimension
separately and finally present how they are combined
in order to build a competence and how competences
may be composed of sub-competences. Several issues
encountered during the modeling process, and possi-
ble solutions (eventually with a trade-off between ex-
pressiveness and complexity) are described. We also
discuss the decisions we have taken as well as their
features and the limitations derived from them.
4.1 Competency
The IEEE Reusable Competency Definitions (IEEE
RCD, 2005) provide a model for the representation of
competencies (figure 2). The model does not include
proficiency level or context information. In addition,
as stated in the specification, IEEE RCD is “intended
to meet the simple need of referencing and cataloging
a competency, not classifying it”, that is, it does not
provide any means to specify relationships between
competencies. We agree upon this view and believe
WEBIST 2007 - International Conference on Web Information Systems and Technologies
that relationships should not be modeled at this level
because they also depend on the other two dimen-
sions: proficiency level and context. For example,
piloting cannot be related to other competencies with-
out knowing if it refers to helicopters, small planes or
passenger planes.
The ideas described in (IEEE RCD, 2005) meet
our requirements, with the advantage that this work is
already acknowledged from the community as a draft
standard. Therefore, we decided to reuse IEEE RCD’s
model to represent competencies (see model depicted
in figure 2).
The RCD identifier provides the basis for refer-
encing and reusing such RCDs, while title and de-
scription provide free text to represent them. We as-
sume the existence of repositories of RCD elements
which may be referenced from different competences
by their global identifier. In addition, (IEEE RCD,
2005) includes information which is not thought to be
but for human interpretation.
Such information includes structured descriptions for
more complete definitions.
4.2 Proficiency Level
Different scales (qualitative and quantitative) may be
used in order to represent proficiency levels. For in-
stance, a computer science curriculum may simply
want to specify whether a student has acquired a com-
petence or not, whereas an English certification insti-
tution may want to classify students into intermediate,
advanced or proficient. Many different scales may be
used but it should be possible to reuse them within
and across the borders of the institution. For example,
scales are typically the same for most certifications
given by one institution and even among them (e.g.,
all curricula in Spanish universities). Hence, they can
be modeled once and referenced many times.
Proficiency levels are not simply a flat set of el-
ements. There are implicit relationships among ele-
ments within one scale. For example, a proficiency
level may be subsumed by another (“proficient” sub-
sumes “advanced” which subsumes “intermediate”
and so on). We need to model such relationships be-
cause they will be needed for competence matching.
For instance, a job requiring someone with interme-
diate English skill typically has implicit the quantifier
“with at least”, meaning that anyone with advanced
English would also be accepted (and maybe even pre-
ferred ). In order to represent this relationships, an or-
dered list provides a reasonable means to represent a
proficiency level scale (see figure 2). In such a list, the
minimum value (subsumed by any other in the list) is
Do not confuse with machine-exchangeable
given by the first element and the maximum is given
by the last one. Therefore, the order in the list repre-
sents subsumption relationships, that is, the first ele-
ment is subsumed by the second one which is as well
subsumed by the third one and so on.
In order to improve interoperability and matching
among scales, an optional field is included for map-
ping to a universal scale (e.g., [0,1]). The reason
why this mapping field is optional is that even though
it would be useful to include it, in some contexts it
may not be possible to find a suitable mapping or it
may not even be necessary (e.g., if a scale is used
only within an institution and no interoperability is
Competence descriptions can refer to specific
items of these scales in order to represent the profi-
ciency level acquired/required. Algorithms could take
relationships among proficiency levels into account in
order to find out how much training/learning is re-
quired to reach a determined employee/learner profi-
ciency level. For example, if advanced English skills
are required, training an employee who already ac-
quired intermediate English skills will cost less time
and money than training another employee who has
only beginner English skills.
4.3 Context
(Webster, ) defines context as “the interrelated condi-
tions in which something exists or occurs”, which in-
cludes “the circumstances and conditions which sur-
round it” (Wikipedia, ). Regarding to competences,
context may refer to different concepts. It might be
the specific occupation in which a competence is ac-
quired (e.g., driving as an ambulance driver or a pizza
delivery employee), a set of topics within a domain
(e.g., telecommunications or tourism, or theoretical
vs. applied physics) or even the personal settings re-
lated to the learner (e.g., competences are different if
acquired in a group-based learning setting than indi-
vidually). All these (and possibly more) are contexts
which may be part of a competence. What actually
makes up sufficient context descriptions can not be
defined in general, but depends on the scope and pur-
pose of the competence descriptions to which they are
attached. As with the skill definitions and proficiency
levels, context definitions may be reused.
Modeling contexts may be a complex task, as
it may coincide with modeling the whole domain
knowledge of an institution. Ontologies can capture
such knowledge (Lau and Sure, 2002) and use ar-
bitrary complex structures, from simple sets or tree
structures to directed acyclic graphs. Up to date, our
investigations of existing relationships between con-
text elements (regarding its use within competences)
do not show the need for providing a graph represen-
tation or multiple inheritance. For this reason, we de-
cided to first restrict the modeling of context to trees
(see model
depicted in figure 2). This has multiple
it reduces the computation complexity of compe-
it is easier to understand by users
it avoids the need for cycle-detection mechanisms
while modeling is done
it simplifies the algorithms for competence match-
We are still investigating the advantages and draw-
backs of this decision and we do not discard an ex-
tension of the model in case we find some scenar-
ios for which such a structure would be beneficiary.
Allowing for more advanced algorithms could also
be a reason for choosing a more expressive context
model. Furthermore, the relationship among context
concepts may also be used by algorithms analyzing
competence gaps. For example, assume that a context
models all occupations of an airline company within
an airport. In case it is needed to train a new pilot for
passenger flights, it would be preferred to train some
of the pilots of cargo planes instead of a person from
the check-in counter. This information could be ex-
tracted from e.g. distances between the occupation
“pilot” and the rest of occupations in the tree/graph.
4.4 Competence
Competences are described as reusable domain
knowledge. Any model representing competences de-
scribes what a competence is and how it is composed
of sub-competences. These competences are general
descriptions, independent of specific learners or job
descriptions. For example, being a good taxi driver
or an expert Oracle database administrator are con-
cepts with fixed meaning (domain knowledge), inde-
pendentof which person possesses such competences.
This is important to be noticed, because competences
are to be referenced from certifications or job descrip-
tions, in order to stimulate their reuse. For instance,
a company may define required, relevant or desirable
competences for their business, which are included in
job offers or projects descriptions. The exact meaning
of these competences is provided by a company-wide
The set of attributes in the context structure is the min-
imum one allowing reference and reuse. This model may of
course be extended with more data specific for the areas in
which it is used
competence model. Using this approach, the expla-
nation of a competence needs not to be explicitly in-
cluded every time it is used
. These explanations may
cover a broad range of aspects, such as:
how a competence may be achieved, for example
by acquiring some sub-competences;
to which level each competence should be ac-
quired. As an example, scientific research in a
University may require only basic knowledge of
mathematics while at NASA, expert knowledge is
whether sub-competences must be all achieved or
simply a subset of them. For instance, it is typi-
cal in curricula that in order to get a degree, some
topics are mandatory and some other are optional,
from which a subset has to be chosen (e.g., pass k
optional courses out of n offers);
if the sub-competences must be acquired in a spe-
cific order. Some companies may require that an
applicant acquired a competence on personal task
organization before becoming a good team leader.
Otherwise, they may assume that the performance
related to the competence of being a good team
leader is reduced.
In order to model all these elements we created
an object model derived from the Composite design
pattern (Riehle, 1997) (see figure 2). In our model,
a competence can be either simple, an aggregation
of children, or a selection from children alternatives.
Competence models a competence, with references
to a skill (RCD id), a proficiency level and a context.
It can be a SimpleCompentence (an atomic
description) or a CompositeCompetence. The
latter can be either be an AggregateCompetence
or AlternativeCompetence. An
AggregateCompetence can be used to de-
fine a competence which consists of several
sub-competences, all of them required. The sub-
competences can be either an ordered set (meaning
that the sub-competences must have been acquired
in such an order) or unordered (default). An
AlternativeCompetence can be used to
construct a set of alternative sub-competences. It
is possible to specify a minimum and a maximum
number of alternatives that must be acquired (e.g.,
minimum k out of n). “Exactly” k sub-competences
might be specified by setting both minimum and
maximum to the same number. By default minimum
is set to 1 so at least one subcompetence of the set is
As with the use of ontologies, whose classes can be
simply referenced without the need of copying the whole
ontology every time they are used
WEBIST 2007 - International Conference on Web Information Systems and Technologies
Proficiency Level
-Universal Scale Mapping [0..1]
Aggregate Competence
-Sequenced : boolean = false
Alternative Competence
-minNumber : Integer = 1
-maxNumber : Integer
Composite Competence SimpleCompetence
-RCD Schema Version
-Additional Metadata
-RCD Schema
Proficiency Scale
Global Identifier
-Model Source
-RCD Ref
-Context Ref
-Prof Level Ref
Figure 2: Competence Model.
Such a model allows to represent atomic compe-
tences, (un)ordered aggregation (all sub-competences
must be acquired), alternative composition (a subset
of sub-competences must be acquired) and any com-
bination of all of them.
It is important to notice that if a competence is
composed from several sub-competences, the profi-
ciency level referenced in each subcompetence repre-
sents the minimum level required. For example, if it
is required to have intermediate English skills in the
context of science in order to be a good researcher,
then anyone with advanced skills fulfills such a re-
quirement. The subsumption relationship modeled
within the proficiency levels is used for this purpose,
and the proficiency level on the competence itself
needs not to include all possible subsumers.
Our model is open to the addition of new relation-
ships, among them an equivalence relationship. This
is especially interesting if competence repositories of
two communities are joined and mappings between
overlapping competences have to be modeled.
Previous sections described how competences and re-
lationships among them can be modeled. In real
world applications, competence definitions are to sup-
port different tasks like creating job profiles for hiring
or selecting people for a particular project, creating
personal competence profiles showing the abilities of
a person, and modeling the prerequisites and expected
results of joining a learning or training programme.
These tasks require modeling collections of required
or acquired competences. Furthermore, the require-
ments specified by a job offer must be matched by the
acquired competences an applicant provides. It there-
fore indicates that the model should be similar for all
the cases enumerated in order to ease its matching.
We refer to this model “competence profile” hereafter.
We can distinguish between two types of compe-
tence profiles, depending on their purpose:
Required Competence Profile: Specifies the re-
quirements (in terms of competences) to be
fulfilled by an applicant. These are typically used
for job descriptions or programme prerequisites.
Acquired Competence Profile: Specifies the ac-
complishments (in terms of competences) of
employees and learners. These are typically used
in order to show (and possibly prove) which
competences have been acquired or to represent
the expected accomplishment after successful
completion of a programme.
Each kind of profile is composed of a set of Pro-
. These profile elements may be re-
quired or acquired, depending on the type of the pro-
file container (see figure 3). A profile element con-
tains data which
may be part of the criteria a companyor a learning
programme uses to decide whether an applicant is
an institution providing degrees or certifications
issues to learners as a prove of the acquired com-
a learner uses to describe acquired competences
For clarity, we did not keep the term evidence intro-
duced in (HR-XML, 2004). A ProfileElement represents a
requirement or a statement of an acquired competence but
not necessarily a proof. Therefore, evidence could be mis-
leading since it may be confused with proof or certification
-Supporting Information
-Issuer Organisation
-Competence Ref
-Expiration Date
-Date Issued
-Sequenced : boolean = false
-minNumber : Integer = 1
-maxNumber : Integer
Global Identifier
-Scale Reference
Composite profile
elements are allowed only
for Required Profiles
This association may
hold a tag/weight
-Global Identifier
-contains *
Figure 3: Competence Profile.
in her CV (not necessarily with a proof or certifi-
cation, e.g.,based on her experience)
Such information includes a type (e.g., driving li-
cense or university degree), the competence required
or acquired and (possibly) a grade
, the issuer organi-
zation, issue date and expiration date (i.e., from when
the driving license is not valid anymore). All these
fields are optional since not all are always needed.
Typically, requirement profiles do not need to spec-
ify all fields of expected profile elements but only
part of them. In these cases, some fields may be
left empty, ensuring comparison only on those fields
which specify constraints. For example, expert com-
puter scientist may be a requirement but it may not
be relevant where the competence was acquired (only
competence field is filled in) or any applicant with a
master degree may be sought but it does not matter in
which field (only “type is filled in and competence
is left empty). In contrary, acquired profile elements
should typically be filled in to a larger extent, spe-
cially if provided by certifications.
Note that the structure of a “ProfileElement” is
different for required and acquired profiles. On the
one hand, required profiles need to represent manda-
tory (English and French) and alternative require-
ments (either English or French) or even desired re-
quirements (English mandatory and French is a plus).
For that, we use the same composite model (meta-
model) as the one specified for competences in sec-
tion 4 (with the addition of tagging relationships with
e.g. desired’), thus easing understanding and simpli-
Note that grade and proficiency level represent different
concepts (cf. Section 5.1)
fying the tools needed to process these models. On the
other hand, acquired profiles do not need such com-
plex relationships and will therefore be represented
as sets, that is, a flat collection of “SimpleProfileEle-
ment” elements.
5.1 Competence Proficiency Level vs.
Grade in Competence Profile
Proficiency levels are part of competences, for exam-
ple “Fluent English”. This is different from grades
provided by institutions (e.g., 250 in TOEFL test).
While the former represents that “any person who
has such a competence is supposed to perform ef-
fectively”, the latter provides a “way to rate persons
having such competence at a specific level of profi-
ciency, by means of some sort of assessment”. For
example, two people having successfully completed
an Advanced Oracle Database Administrator” pro-
gramme are able to perform effectively. However,
they may have different grades in their final certifi-
cation, which may be considered by HR departments
before accepting any of them. In other words, pro-
ficiency levels (which are not bound to specific pro-
files) represent the scope of the competence acquired
(advanced database administration vs. basic database
administration) independently of whether a specific
learner or employee (bound to a profile) learned the
content perfectly or sufficiently to acquire the com-
petence (higher or lower grade). For instance, be-
ing a proficient computer scientist requires to have
advanced knowledge on databases, be intermediate
WEBIST 2007 - International Conference on Web Information Systems and Technologies
Intermediate IT Spanish Vocabulary
: SimpleCompetence
Context Ref = IT
Prof Level Ref = Intermediate
RCD Ref = Spanish Vocabulary
Intermediate IT English Vocabulary : SimpleCompetence
Context Ref = IT
Prof Level Ref = Intermediate
RCD Ref = English Vocabulary
: Composite Competence
Intermediate IT Spanish
: SimpleProfileElement
Type = Master’s Degree
Competence Ref = Expert Computer Scientist
Issuer Organisation = Hannover University
Date Issued = 08/04/2005
: SimpleCompetence
Advanced Spanish
Context Ref = Root
Prof Level Ref = Advanced
RCD Ref = Spanish
: SimpleProfileElement
Competence Ref = Intermediate IT Spanish
Issuer Organisation = Cervantes
: Composite Competence
Intermediate IT
: SimpleProfileElement
Competence Ref = Intermediate IT English
Issuer Organisation = TOEFL
: SimpleProfileElement
Type = Certification
Competence Ref = Java Expert
Issuer Organisation = Sun Microsystems
Date Issued = 02/03/2006
: SimpleCompetence
Advanced English
Context Ref = Root
Prof Level Ref = Advanced
RCD Ref = English
: Composite Competence
Java Expert
Context Ref = Prog. Languages
Prof Level Ref = Expert
: SimpleCompetence
Expert Servlet
Context Ref = Prog. Languages
Prof Level Ref = Expert
RCD Ref = Servlets
: SimpleCompetence
Expert J2EE
Context Ref = Prog. Languages
Prof Level Ref = Expert
RCD Ref = J2EE
: SimpleCompetence
Expert JSP
Context Ref = Prog. Languages
Prof Level Ref = Expert
: Proficiency Level
: SimpleProfileElement
Competence Ref = Java Expert
: Proficiency Level
: Proficiency Level
: SimpleProfileElement
Type = Certification
Competence Ref = English
Issuer Organisation = TOEFL
Date Issued = 10/10/2004
: AlternativeProfileElement
English Vocabulary
: AggregateProfileElement
Spanish Vocabulary
: Proficiency Level
Prog. Languages
: Context
Label = Prog. Languages
: Alternative Competence
: Proficiency Level
: Aggregate Competence
: Aggregate Competence
: Aggregate Competence
: SimpleProfileElement
Type = Master’s Degree
: Context
Label = ...
: Context
Label = ...
: Context
Label = Root
: Context
Label = IT
: Required
: Acquired
Figure 4: Competence Profile and Personal Profile Example.
software engineer and have basic knowledge on eco-
nomics. Those represent the content (scope) required
to acquire the competence, independentlyof the grade
received by learners.
We assume the existence of repositories with infor-
mation about skills, proficiency levels, context and
competences as depicted in figure 4. In this work
we do not deal with the problem of ontology hetero-
geneity and we therefore assume that there either ex-
ist appropriate standards for this information or there
are available mappings between different ontologies
(see e.g. (Rahm and Bernstein, 2001; de Bruijn and
Polleres, 2004)). In addition, how these models are
instantiated is also out of the scope of this paper. We
assume the existence of appropriate tools to hide the
model from end users (e.g., competence management
profile or CV creation).
Typically, a recruiter in a HR department would
write a job offer
Wanted: J2EE consultant
Completed Master’s Degree (any faculty)
Expert Knowledge in Java J2EE, Servlets,
Very good English and/or French
Excerpt extracted from a newspaper
Among other drawbacks, such an advertisement does
not indicate what is mandatory or optional and, more
importantly, it is not machine-understandable. Per-
forming a manual matching (as widely performed
now from the recruiters), the recruiter will have a hard
time matching applications against this offer.
An alternative would be to use the model proposed
here, to encode the job advertisement (see figure 4).
The model not only enforces a well-structured pro-
filing, it also saves the information in a machine-
readable and machine-understandable way. The re-
cruiter can as well reuse information created from
previous job advertisements (e.g., reuse the defini-
tion of Java Expert for his company, as well as use
the well-accepted definition of Master). This index-
able’ representation also has significant advantages
compared to the manual approach for the applicants:
the applicants can now quickly seek on the advertise-
ments, filter out advertisements for which their profile
does not satisfy the requirements. In an even more ad-
vanced scenario, the profile representation can enable
some ranking of the advertisements for which the ap-
plicant satisfies the requirements and some of the op-
tional competences. Finally, the cycle is concluded
when the applications come back to the recruiter. The
recruiter can use a (semi)automatic matching engine
to filter the non-satisfactory applicants according to
their profiles, and rate the suitable applicants. For
example, an applicant profile as depicted in figure 4
would be a perfect match for such an offer. More
complex techniques could be used for partial matches
and rankings/ratings, as they have been hinted along
this paper or in (Colucci et al., 2003). However, elab-
orating on the matching techniques themselves is out
of the scope of this work.
This paper addresses the problem of competence
representation and exchange. Current specifications
focus on the modeling of competencies (not com-
petences) and they miss important information that
should be included, such as proficiency level and con-
text. We provide a machine-processable representa-
tion of competences, relationships among them and
competence profiles. Such a model has been spe-
cially designed for reusability and allows advanced
algorithms for competence and profile matching.
We are currently working on the development of
applications in order to help end users to provide such
competences and profiles. We will use our model
within two different areas. On the one hand, we
plan to develop advanced algorithms for competence
matching and gap analysis in the business context as
part of the EU PROLIX project. On the other hand,
we plan to apply to the creation of competence de-
velopment programmes and advanced assessment and
positioning services within the EU TENCompetence
project. Furthermore, we are in contact with repre-
sentatives of the IEEE LTSC WG20 on Competency
Definitions and the HR-XML Consortium in order to
contribute to the improvements of their specifications
according to the ideas presented in this paper.
Cheetam, G. and Chivers, G. (2005). Professions, Compe-
tence and Informal Learning. Edgard Elgar Publish-
ing Limited.
Colucci, S., Noia, T. D., Sciascio, E. D., Donini, F. M.,
Mongiello, M., and Mottola, M. (2003). A formal
approach to ontology-based semantic match of skills
descriptions. J. UCS, 9(12):1437–1454.
de Bruijn, J. and Polleres, A. (2004). Towards an ontology
mapping specification language for the semantic web.
DERI Technical Report.
HR-XML (2004). HR-XML Measurable Competencies.
IEEE RCD (2005). IEEE 1484.20.1/draft - draft stan-
dard for Reusable Competency Definitions (RCD).
IEEE 1484.20.1.D3.pdf.
IMS RDCEO (2002). IMS Reusable Definition of
Competency or Educational Objective (RDCEO).
Lau, T. and Sure, Y. (2002). Introducing ontology-based
skills management at a large insurance company. In
Modellierung 2002, Modellierung in der Praxis -
Modellierung f¨ur die Praxis, pages 123–134, Tutzing,
Lefebvre, B., Gauthier, G., Tadi´e, S., Duc, T. H., and
Achaba, H. (2005). Competence ontology for domain
knowledge dissemination and retrieval. Applied Arti-
ficial Intelligence, 19(9-10):845–859.
Rahm, E. and Bernstein, P. A. (2001). A survey of ap-
proaches to automatic schema matching. VLDB J.,
Riehle, D. (1997). Composite design patterns. In ACM SIG-
PLAN Conference on Object-Oriented Programming
Systems, Languages & Applications, pages 218–228.
SRCM (2006). Simple Reusable Competency Map proposal
(SRCM). http://www.ostyn.com/resources.htm.
Sure, Y., Maedche, A., and Staab, S. (2000). Leveraging
corporate skill knowledge - from proper to ontoproper.
In Mahling, D. and Reimer, U., editors, 3rd Interna-
tional Conference on Practical Aspects of Knowledge
Management, Basel, Switzerland.
Webster. Webster online dictionary.
Wikipedia. Wikipedia encyclopedia.
WEBIST 2007 - International Conference on Web Information Systems and Technologies