(Part of the InLOC Information Model)
Defining and attributing levels
For a helpful worked example including levels, please see the relevant parts of InLOC explained through example in the Guidelines.
The idea of defining levels
Some LOC documentation defines levels. A classic example in Europe is the European Qualifications Framework (EQF). There are many other more specific examples of frameworks or similar structures that define levels, a few of which have been examined for the InLOC project, including:
- the European Common European Framework of Reference for Languages [CEFR]
- the Australian Core Skills Framework [ACSF]
- the European e-Competence Framework [e-CF]
- the UK Vitae Researcher Development Framework [VRDF]
In some cases these are not called "levels", but some other name. The name is not important, and the common ground is that in each case, there is the idea of possible progression, with higher "levels" (or other term) coming after, and subsuming, lower ones. The assumption is always that someone at a higher level is also able to do the things that are able to be done by someone at a lower level of the same competence.
Binary and rankable definitions
For a definition to be effective as a level definition, one must be able to answer the question, "has this person attained or reached this level?" with possible answers yes or no (not yet). As there are only two possible answers, the kind of definition that can be used as a level definition is called "binary" in InLOC documentation. The kind of learning outcome or competence that it is a level of is then called "rankable" in InLOC documentation, as it allows people to be ranked in order of that learning outcome.
The idea of attributing levels
Given that a level has been defined, any particular learning outcome or competence can be attributed that level. For example, qualifications are routinely given levels on national qualification frameworks, and mapped directly or indirectly to the EQF. Modules, and even distinct intended learning outcomes within modules or courses are also often mapped to level frameworks like the EQF.
None of this attributing, or mapping, plays a part in the definition of the EQF levels, and as such, it is quite a separate activity.
Defining levels in InLOC
InLOC can represent any scheme or framework that defines levels. Two kinds of level definition are frequently seen in existing LOC documentation, as follow. They are seen either separately or together.
Generic levels applicable across a framework
This is where there are levels, stages, etc. that apply right across a framework or other structure. Sometimes they are explicitly designed to apply very widely. The e-CF (the basis for the Guidelines example) has the first; the EQF is a well-known example of the second.
- The definitive description of each level is represented as a LOCdefinition.
- The LOCstructure for the level framework includes LOCassociations that
- have LOCrel as the type
- have the LOCstructure as subject
- have hasDefinedLevel as the scheme.id
- have the LOCdefinition of the generic level as object
- have a number representing the number associated with the defined level.
Levels of specific LOC definitions
This is seen in many occupational frameworks, including the e-CF in the Guidelines example.
- The definitive description of each level is represented as a LOCdefinition.
- What these are levels of is also represented as a LOCdefinition.
- The LOCstructure for the level framework includes LOCassociations that
- have LOCrel as the type
- have the LOCdefinition that the level is of as subject
- have hasDefinedLevel as the scheme.id
- have the LOCdefinition of the particular level as object
- have a number representing the number associated with the defined level.
In cases where both generic and specific levels are defined, the generic levels may be related to the specific levels through LOCassociations of type LOCrel, and scheme.id either hasLOCpart or a sub-relationship, but not hasDefinedLevel.
The significance of the InLOC number property
The number is often taken directly from the level framework documentation, but this is not always possible. Occasionally, a level system uses non-numeric level values, or uses numeric values where a higher level value means a lower level of competence. To enable automatic comparison of levels, it is essential that all level numbers work in the same sense. Any InLOC representation of level definitions must ensure that each level is given a plain decimal number in the standard sense, i.e. where a greater number represents a higher level of competence, or an intended learning outcome that subsumes a lower level one. If suitable numbers are not provided in the documentation, they must be agreed for representing level definitions in an InLOC structure.
Attributing levels in InLOC
In many competence frameworks, levels are not defined in the sense above, but rather levels from a different framework, already existing, are attributed to the LOCdefinitions of the competence framework. This can be represented simply in InLOC using the level type of LOCassociation.
- Create a LOCassociation within the LOCstructure.
- The type of the LOCassociation is level.
- The subject is the LOCdefinition having a level attributed to it.
- The scheme is the level scheme containing the level definition.
- The object is the attributed level:
- The number is the attributed level number.
The attributed level number would often be a level number that has been explicitly defined in the level scheme, but it is not necessarily so. It is perfectly possible to attribute a level number that is between defined numbers, though the meaning of this may not be well-defined. For instance, one could attribute an EQF level 4.5 to something that appeared to fall between the definition of EQF level 4 and of EQF level 5.
Definition mixed with attribution
In some cases, a level system defines levels and also maps these to the levels in another framework. This is simply represented in InLOC by doing both of the above.
Examples
The example worked through in the Guidelines section on InLOC explained through example includes defining and attributing levels.