The eCOTOOL project and the Europass CS
Introduction
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 http://www.simongrant.org/pubs/eCOTOOL/eCOTOOL_CM.html and indexed together with some other eCOTOOL resources at http://www.simongrant.org/pubs/eCOTOOL/.
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 |
| URL | http://www.competencetools.eu/ |
| 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.