CoKoMo Meta-Model Specification Version 1.0

This version:
https://purl.org/cokomo/v1/meta-model
Latest published version:
https://purl.org/cokomo/v1/meta-model
Previous version:
none
Participate:
Ask a question & get involved
File a bug

Target audience

This document is targeted at

  • client software developers, who want to create client applications or libraries to process model instances
  • annotators of learning resources and authors of model instances, who want to understand the meta-model while using the CoKoMo web application to create their own model instances

Introduction

The CoKoMo Meta-Model’s (CMM) is intended to be used to create CoKoMo model instances (for short: models or model instances) that describe the competencies within a certain area of expertise. These models can be used in a variety of ways, for instance, as controlled vocabularies for use in meta-data standards like schema.org or AMB, but also to support the business logic of client applications, like OER search engines or even Intelligent Tutoring Systems.

The CMM is based on the work of Andersen and Krathwohl, who revised Bloom’s „Taxonomy of Educational Objectives“1 (often referred to as „Bloom’s taxonomy).2 Andersen and Krathwohl introduced two dimensions: the knowledge dimension and the cognitive process dimension. The cognitive process dimension is represented by the CMM type Competence Level.

The Competence Base could be said to represent the knowledge dimension, however it is not limited to the four categories suggested by Andersen and Krathwohl. Instead, using the CMM Competence Base and its relation, one is able to represent arbitrarily complex topics. This part of the CMM, i.e. the subtypes and relations of the Competence Base, is based on Gilbert Paquette’s semi-formal „MOT modelling language“3.

Together, a single Competence Base and a single Competence Level represent a Learning Goal.

Abstract Syntax

Overview

The CMM consists of the following elements:

  • the two base types Competence Base and Competence Level, which cannot be instantiated by the user
  • three concrete subtypes of Competence Base, which can be instantiated be the user: Concept, Principle, and Procedure
  • six pre-defined instances of Competence Levels, i.e. Level 1 through 6
  • six (plus „undefined“) directed relations, which can be used to connect two Competence Bases
  • a Learning Goal, which is the combination of a Competence Base instance and a Competence Level instance
  • a set of properties that can be used to describe each Competence Base
  • a set of Learning Goal Statements that can be used to describe each Learning Goal
  • a set of IDs, which can be used to reference each Competence Base instance, each of the six pre-defined Competence Levels, as well as each Learning Goal

Important: The CoKoMo web application provides a way to organize a single model into several boards. This is not part of the CMM but simply a convenience feature for model authors to make working with large models easier.

Base Types

The CMM defines three abstract base types

  1. Competence Base
  2. Competence Level
  3. Learning Goal

These abstract base types are not intended to be directly instantiated by the user of the CMM. Instead, only specific types of these base types can be instantiated. These are described in the following sections.

Abstract Base Type: Competence Base

In the CMM, a Competence Base represents anything that may be the subject of teaching, of learning etc. In fact, anything can be represented as a Competence Base, if it is useful for the intended use of the model.

However, the type Competence Base itself is an abstract base type and as such it is not intended to be instantiated. In order to create an instance of type Competence Base, one must instantiate one of the concrete subtypes: Concept, Principle, or Procedure.

These are the common properties of all Competence Bases.

Property: Title

  • Usage: A descriptive title for the Competence Base. This property sometimes is also called the „preferred term“ or „preferred label“.
  • Required: Yes
  • Unique: No
  • Value Type: string

Property: Alternate Terms

  • Usage: A set of alternate terms that may be used to refer to this Competence Base.
  • Required: No
  • Unique: No
  • Value Type: Set of string

Property: Short description

  • Usage: A short description to disambiguate this Competence Base from similarly named Competence Bases.
  • Required: No
  • Unique: No
  • Value Type: string

Property: Long description

  • Usage: A long form description that describes the Competence Base in as much or little detail as needed. May contain images, text formatting, and formulas using LaTeX-syntax.
  • Required: No
  • Unique: No
  • Value Type: RichText

Property: Competence Base ID

  • Usage: An ID that uniquely identifies this Competence Base.
  • Required: Yes
  • Unique: Yes
  • Value Type: ID

Property: Competence Base Type

  • Usage: Specifies the concrete subtype of this Competence Base.
  • Required: Yes
  • Unique: No
  • Value Type: One of: concept, principle, or procedure

Concrete Competence Base Subtypes: Concept, Principle, and Procedure

The distinction of these three types is inspired by Gilbert Paquette’s semi-formal version of the „MOT modelling language“3.

Concept

Concepts describe a domain’s classes of objects (the „what“ dimension) by their common properties, the „values“ of an object’s properties making it distinct from others. — (Paquette, Chapter 2, page 27)

Principle

Principles are general statements intended to describe objects [sic!] properties, establish cause-and-effect links between objects (the „why“ dimension), or determin a procedure’s application conditions (the „when“ dimension); principles are most often formulated as „If this condition … then that condition or that action.“ — (Paquette, Chapter 2, page 27)

Procedure

Procedures describe sets of operations that affect objects (the „how“ dimension); they represent combinations of actions that may apply to several cases, each case distinguishing itself from others by the objects which actions may apply and their resulting transformation. — (Paquette, Chapter 2, page 27)

Abstract Base Type: Competence Level

The CMM type Competence Level represents the cognitive process dimension of Andersen and Krathwohl’s taxonomy (i.e. Bloom’s revised taxonomy). This type is an abstract base type and thus not intended to by instantiated by the user. Instead, there are six pre-defined instances that represent the six cognitive processes defined by Andersen and Krathwohl. Since the CMM is intended for the German speaking educational sector, the actual names of the six levels are currently in German. These are given in parentheses:

  1. Remember (name: „Erinnern“, level: 1)
  2. Understand (name: „Verstehen“, level: 2)
  3. Apply (name: „Anwenden“, level: 3)
  4. Analyze (name: „Analysieren“, level: 4)
  5. Evaluate (name: „Evaluieren“, level: 5)
  6. Create (name: „Kreieren“, level: 6)

These six concrete Competence Level instances are usually referred to as „Competence Level 1“ through „Competence Level 6“.

Note: CMM users can only use the six pre-defined Competence Level instances, but they cannot create their own. I.e. every model will always contain exactly these six instances of type Competence Level.

These are the common properties of all six Competence Level instances:

Property: Name

  • Usage: The name of the Competence Level
  • Required: Yes
  • Unique: Yes
  • Value Type: string

Property: Level

  • Usage: The level of the Competence Level
  • Required: Yes
  • Unique: Yes
  • Value Type: One of 1,2,3,4,5,6.

Property: Competence Level ID

  • Usage: An ID that uniquely identifies this Competence Level.
  • Required: Yes
  • Unique: Yes
  • Value Type: ID

Abstract Base Type: Learning Goal

Similar to the two dimensions in Bloom’s revised taxonomy, where the knowledge dimension and the cognitive process dimension are combined to describe a learning objective, the CMM has a third base type Learning Goal, which serves a similar purpose. A Learning Goal is specified by the combination of a Competence Base instance and a Competence Level instance.

Note: When using the CoKoMo web application, creating a new Competence Base will automatically create six new Learning Goals in the background: one for each of the six Competence Levels. This is a side-effect of the current implementation of the web application but should not be considered a requirement. I.e. client implementations CANNOT assume that every Competence Base has six corresponding Learning Goals. Instead, clients MUST assume that a Competence Base may have zero or more corresponding Learning Goals.

These are the common properties of all Learning Goals:

Property: Competence Base ID

  • Usage: The ID of the Competence Base instance this Learning Goal refers to.
  • Required: Yes
  • Unique: No
  • Value Type: ID of the Competence Base

Property: Competence Level ID

  • Usage: The ID of the Competence Level instance this Learning Goal refers to.
  • Required: Yes
  • Unique: No
  • Value Type: ID of the Competence Level

Property: Learning Goal Statements

  • Usage: A set of learning goal statements.
  • Required: No
  • Unique: No
  • Value Type: set of RichText

Relations between Competence Bases

The CMM supports a number of different relations that can be used to represent relationships between Competence Bses. As with the subtypes of Competence Base, the different types of relations are also based on Gilbert Paquette’s semi-formal „MOT modelling language“3.

Please note: The current implementation allows for an additional relation type called undefined. This type is only supposed to be used during model development and should not be present in published models. However, since this is not enforced by the system, client implementations must expect this value and handle the undefined-relation type without error.

Relation Type: „is composed of“ (Composition)

This represents the well-known hierarchical relationship. It can be used to indicate that one CompetenceBase is a whole, which is composed of other CompetenceBasis, which are the parts.

Relation Type: „specializes“ (Specialization)

This represents the well-known hierarchical relation. It can be used to indicate that one CompetenceBase specializes the other CompetenceBase, in other word, one CompetenceBase is a subclass of the other CompetenceBase.

Relation Type: „precedes“ (Precedence)

This is an associative relation. It can be used to indicate that one Competence Base precedes the another.

Relation Type: „is input to or produces“ (Input / Product)

This is an associative relation. It can be used to indicate two things:

  1. one CompetenceBase is the input for another CompetenceBase
  2. one CompetenceBase is the output (product) of another CompetenceBase

Note: The double meaning of this relation-type is a direct result from the informal model by R. Paquette, which the CMM is currently based on. Future versions of the CMM might represent these as different relation types.

Relation Type: „regulates“ (Regulation)

This is an associative relation. It can be used to indicate that one CompetenceBase regulates or controls another CompetenceBase.

Value Types

This section describes the value types of CMM properties.

Value Type: string

A Unicode string.

Value Type: set of string

An unordered set where each element is of type string.

Value Type: RichText

Any combination of

  • formatted and unformatted text as HTML
  • images
  • LaTeX formulas

Value Type: ID

A UUID as a string.