The eCOTOOL project and the Europass CS


eCOTOOL was a European (Leonardo da Vinci) project running from December 2009 to November 2011. It created an Application Profile of the Europass Certificate Supplement (ECS), using various other idea sources including the EQF, and went beyond its original target to produce a general-purpose "competence model", which is the basis of the information below.

eCOTOOL's competence model is complementary to its model of the ECS, so it should come as no surprise that the model is carefully restricted in scope. The intention is to provide a common model for competence that can be referred to by the ECS, by other Europass and similar instruments, by learning resources, by job requirements, by people's claims to possess skill and competence, etc.

For ease of reference, the eCOTOOL Competence Model is displayed at and indexed together with some other eCOTOOL resources at

General information

This is meant to be generally useful information about the stakeholder or source model.

information to be gathered details
Name / title of source/model and version if applicable eCOTOOL
Stakeholder Project partners were UDE, BIBB, MAICh, ELOT, Agro-Know, UZEI, KGZS, ISFOL, KION, Bolton
Orientation Very generic: explicitly aimed at link between learning, education, training, and work
Explicit / implicit Explicit
Organisational competence No
Number of people currently affected None currently. Large potential through possible EU policy influence, and through this project, InLOC.
Sectors covered Any sector. Testing of eCOTOOL was done with the agricultural sector.
User communities No established users yet.
Significant use cases  
Significant business cases  
Gather sample materials Refers to samples from various sources; eCOTOOL offers some example XML for representing a single competence definition (but not a framework)
Key features influencing uptake This is a finished project contributing to InLOC, not the other way round.

Features of the model

The model described can be either explicit (as in a specification) or implicit in the stakeholders data or practice. If a source covers separate more than one LOC, it might be useful to duplicate this table, and fill in once for individual LOCs, and once for frameworks or LOC structures. In the "?" column, put 1 if the feature is present, 0 if it is not.

N Features ? notes (replace these explanations with your gathered information)
00 More than one model 1 definitions and frameworks are modelled differently
01 Identifiers 1 any string identifiers allowed, envisaged as eventually being URIs
02 Hierarchy (internal) 1 not restricted: potentially polyhierarchical
03 Internal relationships 0 only as in conditionality / optionality
04 External relationships 1 given as an option
05 Conditionality / optionality 1 examples possible from e.g. training syllabuses
06 Text syntax 1 provision for optional explicit action verb(s) starting short description
07 Structured identifiers 0 no prescribed structure beyond recommended URI
08 Classification 1 categories allowed for: example knowledge/skill/competence from EQF not mandatory
09 Level attribution 1 EQF, ISCED and others quoted as examples
10 Level definition 1 clear model; lack of concrete examples
11 Context 1 a "context identifier" is allowed for any competence definition — however, this is primarily to locate a short definition with no full description into its context in a framework, so that any ambiguity can be resolved in the context of its place in the framework
12 Evidence and assessment 0 evidence and assessment to be linked to competence definitions, not included within them
13 Extensions 0 nothing explicit - meant to be combined rather than extended
14 Profiles 0 other specs expected to aggegate URIs of competences
15 Adaptation 1 describes standard method of describing any adaptations in competence frameworks themselves
16 Definition by example 0 examples not used in definition
17 Learning resources 0 resources expected to refer to competence URI in their own terms
18 Learner records 0 learner records expected to refer to competence URIs in their own ways
19 Multilinguality 1 strings may be present as multiple language equivalents

High-level model

eCOTOOL defined a "high-level" model to provide an explanation as easy as possible to understand for non-technical purposes. This is illustrated around three "forms". Form A is for defining a competence item by itself; Form B documents the hierarchical structure, and also notes optionality; and Form C is used to define levels, which each have an "id code" and a "level number".

Technical model

The model of a separate competence definition contains in essence

  • unique id code (URI recommended)
  • short description (optionally with an initial action verb)
  • optional full description
  • generic metadata (typically Dublin Core Terms, including creator, created, modified)

The remainder of the information that is associated with a specific competence definition may be given with a definition separately, or within a framework. In case a small separate definition is taken out of context, it needs

  • one optional identifier of the framework in which the definition is defined

Either separately or in a framework, a competence definition can have

  • categories
  • relations with other definitions:
    • hierarchical within the home framework using SKOS, including optionality extending SKOS
    • matching definitions from beyond a home framework using SKOS mapping properties
  • level attribution to existing level schemes

The model of a competence framework adds level definition, which can only happen in the context of a framework or structure of some kind.

Guidelines requirements

The InLOC Guidelines need to explain the relationship of InLOC structures to the Europass Certificate Supplement (ECS). eCOTOOL suggested an initial approach to this, which InLOC needs to refine and reach agreement on.