InLOC — Guidelines
including the integration of Learning Outcomes
and Competences into existing specifications

 

 

This document is produced by the InLOC team:
Simon Grant, Mike Collett, Marc Van Coillie, Jan Górecki, Jad Najjar, Cleo Sgouropoulou, Christian M. Stracke.

 

 

 

2013-04-23

 

 


Contents

  1. An introduction to the InLOC Guidelines
  2. The relevance of InLOC to different stakeholders
  3. Background to InLOC – learning outcomes in learning education and training
  4. Background to InLOC – competence in the world of employment
  5. An example to explain the InLOC Information Model
  6. How to follow InLOC in the structuring of LOC information
  7. Extending InLOC
  8. Referencing InLOC information
  9. Integrating InLOC with European Learner Mobility specifications
  10. List of references

An introduction to the InLOC Guidelines

The meaning of InLOC

The name "InLOC" stands for "Integrating Learning Outcomes and Competences". InLOC offers a unified way of representing definitions both of intended learning outcomes – as used in learning, education and training – and of competences – as used typically by employers and those concerned with professional development. For readers who are not familiar with those terms and their background, please see the sections on Learning outcomes and Work competences.

InLOC aims to help enable services that guide people to and through learning into employment. It will support mobility by enabling links to be made between information about a learner's capability, employers' requirements and intended outcomes of learning opportunities.

As "InLOC" already stands for "Integrating Learning Outcomes and Competences", we use the shorter acronyms "LOC" to stand for "learning outcome or competence" and "LOCs" to stand for "learning outcomes and/or competences" according to context. Both "learning outcome" and "competence" are already a very well-used terms, with their own associated meanings. By bringing together both of these terms, "LOC" is intentionally wide in scope, and sidesteps some of the old arguments that have attached to the other terms. It could be said that the term "competency" was another attempt to establish a broad term, but "LOC" has the advantage of not being used before, and is therefore free of the connotations of the older terms.

For concise definitions of the terms "learning outcome" and "competence", please see the Terms and Definitions section of the Information Model.

Why should anyone be interested in InLOC?

The subject matter of InLOC is relevant, more or less directly, to a wide range of people. In the section following, each of the Stakeholder groups is addressed in turn, because the importance and relevance differs between different groups of people.

There is also a general point to be made, not to individual stakeholder groups, but about the human and technical systems as a whole that they participate in. First and foremost, there is a need for a general purpose interoperability standard that enables different software to work with the same competence structures, and one piece of software to work with any number of different competence structures. There are currently very few published specifications that deal with structures of learning outcome or competence information, and the ones that exist appear to be specialised for specific uses.

When this kind of standard is implemented and adopted, it will allow purchasers and users of relevant systems to be able to choose the system they work with, and the LOC structures they work with, independently. It will allow developers and vendors to develop software for one application area and use it in any application area. It will mean that people who develop frameworks or occupational standards can publish their structures in just one format, and all relevant systems will be able to process that.

The benefits that come from this will only be realised and appear clearly when substantial investment has been made in representing existing frameworks and occupational standards in this common format. When this has happened, many services will be able to spring up, all serving the needs of the various stakeholder groups. These are discussed in the section following.

With the right kind of policy and motivation, it seems likely that the appearance of a range of services such as is hinted at will in turn stimulate the production of many more frameworks and structures, thus feeding a "virtuous circle" of development, whose endpoint may hardly be recognisable. While there have been several initiatives to achieve goals in this direction, they have suffered from the lack of electronically published fully structured definitions and structures, which in turn is held back by the lack of a commonly accepted format for the full structuring of this information. This is exactly the gap that InLOC is designed to fill.

How can InLOC be understood?

The InLOC information model is necessarily quite general in purpose and broad in scope. This means that, inevitably, some aspects of the model will need more explanation that others. InLOC explained through example is the section that introduces the InLOC model to the general audience.

Some readers will have an interest in using the InLOC model to represent their own LOC information. The section How to follow InLOC takes the common features of existing information about LOCs, and explains more directly how to represent each feature using InLOC. This means that readers will only need to refer to the features in which they have an interest – the features of the information that they deal with. Extending InLOC then briefly points to how features not covered by InLOC may be added to the InLOC model.

Other readers will want to refer to LOC information from their information – for instance, if their information is about courses or other resources for learning, education or training. Referencing InLOC information outlines the approaches to doing this, though detail will depend greatly on what information is required, both for display to users, and for processing by ICT systems.

Integration with other European standards and processes

Integrating InLOC is the final section of these Guidelines, which will explain in more detail how the InLOC approach can be integrated effectively with Europass, with EuroLMAI (EN 15981, [EuroLMAI]), with MLO (EN 15982, [MLO]), and related processes.


The relevance of InLOC to different stakeholders

This section very briefly sets out the different kinds of stakeholders who may have an interest in InLOC, and explains more about how those different stakeholders can use InLOC outputs and interact with InLOC more generally. The material here has been derived from an extensive programme of stakeholder engagement. Much of the analysis of stakeholder needs is displayed through the Stakeholders pages on the project web site.

InLOC is intended for the benefit of several stakeholder groups, in one way or another. Here are distinguished:

Skill or competence standards setting bodies

There are several bodies across Europe whose business it is to define the skill or competence requirements for occupations.

They will be able to use the InLOC information model and bindings to publish machine-readable electronic versions of their frameworks or occupational standards, that can easily be referred to and used by others.

InLOC can enable and catalyse the popularisation of occupational competence standards. It supports development of applications on top of the standard, which in turn support practical use cases.

Competence model and framework developers

Such people may work for the standards setting bodies mentioned above, or they may work for other bodies.

They too can use the InLOC information model and bindings to publish machine-readable electronic versions of their occupational standards, that can easily be referred to and used by others.

Curriculum developers and managers

Anyone who is developing a course with intended learning outcomes can use the InLOC information model and bindings to publish machine-readable versions of their course learning outcomes, perhaps within machine-readable versions of their course catalogue as a whole. The ease of access to this information, and its standard structure, will mean that many web-based services can find and use the information, advertising the courses at no extra cost.

In the process of development, curriculum developers can take advantage of any available information about occupational competences published in InLOC format, and reuse it as permitted, saving them time, and helping towards greater cross-curricular consistency.

Recruitment and HR system managers

These people can use InLOC approaches to structure their internal competence frameworks, making use of any published competence frameworks. They can also use their own or public frameworks to define employee requirements and development objectives. If InLOC formatted materials were widely available, they would facilitate the processes of gap analysis, using common definitions rather than relying on their own private ones. This will be particularly helpful for gap analysis extended beyond one organisation.

InLOC could also help human resources management in other ways:

InLOC provides a basis for future systems that build job profiles. Job profiles are not explicitly included in InLOC, and thus will need a small amount of extra work. InLOC may stimulate the idea that job profiles could be built using InLOC-formatted information, and that idea can in turn lead to requirements for this kind of functionality.

Individuals seeking places in educational institutions or the workplace

In addition to the use of compliant systems with InLOC, these people could refer to InLOC competence definitions from their online CV or e-portfolio. The fact that the competence definitions are publicly defined and available on the Net can be expected to result in it being much easier for employers to search for people with relevant skills and competences, which in turn will lead to individuals finding appropriate jobs more easily. In other words, the labour market will work more effectively.

Learning technology systems providers

These systems providers can build in support for InLOC formats, so that users can easily customise their systems with any published LOC framework. Providers will not have to develop many different variants of their systems to cover different styles of learning outcome representation, but will instead be able to focus their resources onto producing the best possible products, knowing that they will be very easy to customise for any area of learning.

Recruitment and HR management systems providers

These systems providers can build in support for InLOC formats, enabling their clients and users more easily to find and specify employee ability requirements and targets. Similarly to the advantage for other systems providers, they will be able to focus their resources on their core strengths of developing the best software, without having to worry about customisation for different areas of competence.

When a further specification is agreed for job profiles, system providers will be able to build in support for creating full job profiles on the basis of InLOC information, potentially then feeding in to recruitment services.

Policy makers

Policy makers can recognise the advantages of a coherent approach that InLOC enables, and include the requirement for InLOC support into their policy decisions. Understanding the social and political benefits that are possible, they can justify their policies with reference to the positive outcomes of a much improved labour market.

Participants in specifications and standards development

These people can reuse the structures created in InLOC and integrate them further into learning technology standardisation and beyond.


Background to InLOC – learning outcomes in learning education and training

"A learning outcome sets out what a learner is expected to know, understand and be able to do as the result of a process of learning." [OFQUAL]. Learning outcomes may include technical knowledge and skills or softer, social skills.

A learning outcome, also described as an intended learning outcome or learning objective, predicts or indicates what a learner should, is expected to or needs to gain. In contrast a competence is something a learner has achieved. There is likely to be a very strong connection between an outcome and a competence.

Learning outcomes are often defined in a curriculum, qualification framework, syllabus or course description. They are often defined at specific levels and are often associated with measurable achievements.

"Learning outcomes are, in a way, a tool to describe and define a learning and assessment process and its product, which can lead to improved pedagogical practice in education and improved student learning practice. They place focus on the coherence and aims of the qualification, the judgement of the designer and how the qualification fits within the traditions of the discipline." Learning outcomes: Common framework – different approaches to evaluation learning outcomes in the Nordic countries. [ENQA15]

"The shift to learning outcomes is important for several reasons.

InLOC provides a model to support the digital representation, interoperability and exchange of structures that define, and describe relationships between, learning outcomes.

Learning outcomes have also been seen as constraining and restrictive. Criticism was being voiced already around 1970 by Lawrence Stenhouse.[LS1970] To counter the criticism, it is essential that those drafting learning outcomes are bold and creative, making reasonable attempts to codify even the less tangible and less easily measurable learning outcomes.

See also the Further reading on learning outcomes.


Background to InLOC – competence in the world of employment

Job application and recruitment

In recruitment, and in job application, attempts are made to match an individual's CV with a job profile. HR systems often use job descriptions based on skills, competencies and therefore on a competency framework.

Employers often look for qualifications, experience and specific skills or competences. Qualifications may be seen to be associated with particular competences and attitudes. Academic qualifications imply areas of knowledge, while vocational qualifications may cover both practical knowledge and practically assessed abilities. However, there is often a mismatch between what employers are seeking, and what is associated with qualifications, particularly academic qualifications.

Employee performance and competence management

Employee performance management is commonly based on the idea of a competency framework, and on learning outcomes related to these competencies, and job profiles.

Many organisations regard competence development of their employees as vital to their success, particularly in view of changes caused by economic situations, innovations, integration of technologies in the business process or delivery of new products or services.

Competence management is often integrated into the workflow of the organisation's activities, including recruitment, expertise, promotion and evaluation. The competences of individuals are identified, managed and evaluated, and job profiles are created, involving combinations of practical knowledge, skills and competences in addition to interpersonal and behavioural ones. Evidence supporting claims to attainment of competences is gathered and kept. This helps in the composition and processing of competence profiles.

Enterprise collaborative solutions, community and professional social networks

Several collaborative approaches in enterprise are using extended employee profiles including competences. This helps for team building, for identification of expertise, and for managing collaboration requests by other employees.

Many organisation are now also using an internal social network, or community, often on an existing online professional social network. These communities are also based on the idea of competency, expertise, groups, micro-community and team/project workgroup building for more efficient teams and a better exploitation of the resources/competences of the organisation's employees. As well as self-described competences, for example LinkedIn has a section on "Skills & Expertise" based on standardised descriptions, not individual ones, so that the same skill or expertise heading can be related to many different people.

See also further reading on work competences.


An example to explain the InLOC Information Model

This section explains the InLOC information model progressively, using one particular detailed example. There are many examples that could have been used – InLOC is carefully designed to be able to represent a very wide range of frameworks or structures – but this example is a useful one to illustrate many of the features of InLOC.

Throughout this section, where appropriate, reference will be made to, and examples drawn from, the the European e-Competence Framework [e-CF], which provides a useful example of many of the aspects of the InLOC model. Readers are invited to familiarise themselves with the e-CF through the material available on their web site.

This section's example of a competence framework is the European e-Competence Framework (e-CF) itself as a whole, focusing on the area A and e-competence A.2 of the e-CF. Here is a reproduction of most of the relevant page in the current documentation. The e-CF documentation as a whole contains 36 such "e-Competence" pages. Here is the page for e-Competence A.2.


Figure 1: A.2 – one of the 36 e-Competence pages in the e-CF

The distinction between definitions and structures of LOCs

This distinction is central to the InLOC model and approach, and needs to be properly understood as a basis for explaining the rest of the model.

A LOC definition is, in essence, a definition of any concept that can be applied to a person's knowledge, skill or competence, for which evidence could be provided, and which could in principle potentially be assessed in some way.


Figure 2: the example page with LOC structure title and LOC definitions shown

According to this definition, Figure 2, above, shows the LOC definitions on the A.2 page. Each one of the red rectangles contains the definition of a single concept, different from every other concept on this page, for which some sort of evidence could be provided for a particular person. The top red-outlined concept, "PLAN", in the context of ICT systems is very broad and quite vague, and what evidence would count towards verifying someone's competence at planning, in an ICT context, may only be vaguely defined. The e-CF clarifies this by breaking it down into 8 "e-Competences" (A.1 to A.8). (Other frameworks or analyses may of course differ in their analysis.) Below the e-CF's general area heading, "PLAN", it becomes increasingly easy to imagine producing evidence for a person's ability for the LOC definitions, and to imagine appropriate assessment.

With an initial idea of a LOC definition, it is easier to formulate a useful idea of a LOC structure. It can be seen as a set of associated LOC definitions, together with information about their properties and how they are related together. Where the boundaries are drawn is a matter of choice, and in the case of the e-CF a good choice is to consider the e-CF as a whole as the single containing LOC structure. This is why the e-CF title has been outlined in yellow in the figure above.

With this initial idea in mind, it becomes easier to explain the terms in more detail.

LOC definitions

While resembling other such frameworks in some ways, the e-CF makes no suggestion that its structure is in any way standard. Such "dimensions" are specific to the e-CF. InLOC therefore takes a very flexible, broad and general view, using the term "LOCdefinition" to mean a definition of any concept about the characteristics of an individual related to the outcomes of learning undertaken, or competence developed, for which evidence might in principle be gathered and presented. This can be at any level of generality, or granularity. Explicitly:

To bring this together, in every "dimension" of the e-CF there are what InLOC terms LOCdefinitions. InLOC considers them as having a title, or a description, or both. In e-CF dimension 1, InLOC only gives the area a title; in dimension 2, InLOC gives the main e-Competences both a title (in the example, "Service Level Management") and a description (in the example, starting with "Defines, validates and makes applicable ..."); in dimensions 3 and 4, InLOC takes the text as a description, with no title. While there is no absolute distinction between a title and a description, in the large majority of cases it is a matter of agreed common sense whether a piece of text looks more like a title or more like a description, and that is what should guide people.

LOC structures

As InLOC takes a LOCdefinition to mean something that is in principle assessable, and against which evidence can be provided, it is important to clarify in what way a LOCstructure differs from this. A LOCstructure is not a single concept to assess — it is, rather, a structure relating the LOCdefinition concepts together. Assessment against a LOCstructure would mean no more and no less than assessment in terms of its associated LOCdefinition concepts.

In Figure 2, the main LOCstructure is shown as the e-CF as a whole; and it makes no sense to assess someone's "e-Competence Framework". But also, there could be a LOCstructure for this e-Competence "A.2", in that it is composed of the associated proficiency levels, knowledge and skill examples. The point here is that the structure that the e-CF gives for "Service Level Management" is just one possible one. It is easy to imagine a different analysis, with a different structure, for "Service Level Management". When the e-CF defines the concept, "Service Level Management", it is giving a LOCdefinition. But when it sets out the "Dimensions" 3 and 4 for this e-Competence, along with knowledge and skills examples, it is defining a LOCstructure. It is a subtle but important distinction.

It is also possible to approach the distinction between LOCdefinition and LOCstructure from another direction. If a title and/or description (related to learning outcome or competence) is about a concept that can be applied to an individual and assessed coherently, then InLOC treats it as a LOCdefinition. If the title and/or description is of a structure of associated LOCdefinitions, InLOC instead will treat it as a LOCstructure.

To detail how the whole e-CF can be considered as a LOCstructure, see the next diagram, Figure 3.


Figure 3: diagram showing the parts of the e-CF (a full diagram would include similar breakdowns of all the 36 "e-Competences", with their examples and their levels).

Figure 3 shows the layout of the overall e-CF structure, showing what the e-CF call four "dimensions":

  1. five broad "areas" of IT professional responsibility: "PLAN"; "BUILD"; "RUN"; "ENABLE"; "MANAGE";
  2. within each area, several specific "e-Competences";
  3. within each e-Competence, some definitions of proficiency levels;
  4. also within each e-Competence, examples of the relevant knowledge and skills.

Identifiers

The e-CF [e-CF], as many other frameworks, uses local internal identifiers so that people can refer to its parts clearly and concisely. The areas have a single letter – in the example, "PLAN" is given the letter "A", and the other areas are identified as "B", "C", "D" and "E". The e-Competence "Service Level Management" is given the identifier "A.2". The knowledge and skills examples are given numbers within the e-Competence that they exemplify.

InLOC generalises this practice of giving identifiers, to maximise their usefulness. Every LOCstructure, and every LOCdefinition in an InLOC representation must have a universally unique identifier, so that they can be referred to clearly, unambiguously, and efficiently, from outside as well as inside the structure. The importance of this will become clear. In the interests of conciseness, InLOC calls an identifier id.


Figure 4: the two basic classes, with identifiers.

This is the first of a series of diagrams that illustrate the information model itself. These diagrams are schematic: so, for example, this one means that every LOCstructure and every LOCdefinition must have an identifier – not the same one of course. All these diagrams use singular forms, but they are intended to include the plural where appropriate. One LOCstructure can be associated with any number of LOCdefinitions. The formal information model is contained in the Information Model documentation.

LOC associations

Associations detailing structural relationships

The InLOC model has so far clarified that there are LOCstructures and there are LOCdefinitions, and stated that the LOCstructure is a set of associated LOCdefinitions. In paper-style documentation, the set of LOCdefinitions is bounded, or delimited, simply by being within the documentation representing the LOCstructure. But in fully flexible electronic documentation, in the style of a database, and with the potential to reuse LOCdefinitions, this may not be so obvious. The associations between LOCstructures and LOCdefinitions must be made explicit.

InLOC introduces LOCassociations to represent these relationships. LOCassociations primarily represent all the relations between different LOCdefinitions included in a LOCstructure, as in the figure that follows.


Figure 5: the example e-CF page with the structural associations between LOC definitions shown

Different kinds of relationship are shown in this figure. InLOC has a general concept of whole-part or broader-narrower relationships, but to cope with the differences in meaning between "hasPart / isPartOf" and "narrower / broader" InLOC introduces a purpose-made pair of relationships, "hasLOCpart" and "isLOCpartOf". The e-CF hasLOCpart each of the 5 areas, and each of these in turn hasLOCpart each of its own e-Competencies. For example, "PLAN" hasLOCpart "Service Level Management". Each of the e-Competences A.1 to A.8 isLOCpartOf "PLAN". In this case, none are different in being more or less important, or mandatory as opposed to optional.

The relationship between A.2 and its knowledge and skills examples is not quite the same. The e-CF is not trying to say that the 5 knowledge examples given represent all that there is to know for Service Level Management, nor that the 5 skills examples given are all the skills that are necessary. They are just representative examples. This is a useful approach, because in a fast-moving field such as ICT, the exact knowledge and skills required may change fairly rapidly. Examples will still be examples. For this usage, InLOC defines the relationship "hasExample", and that also is a sub-relationship of hasLOCpart.

Often one sees component competence or learning outcome concepts that are clearly more or less central to their "parent" concept. It may well be useful to see these as on the one hand necessary (could be called essential, or mandatory), or on the other hand optional, and to support this distinction, InLOC defines the relationships "hasNecessaryPart" and "hasOptionalPart" also as sub-relationships of hasLOCpart.

Defining levels with proper numbers

The relationship between an e-CF e-Competence and one of its proficiency levels has its own peculiar character, different from the other kinds of hasLOCpart. Level 3 and Level 4 are not components of A.2, but rather they are specifically defined levels of the more general A.2 concept. InLOC uses a different term to describe this relationship: "hasDefinedLevel". This is a sub-relationship of hasLOCpart.

The number given to the level has great significance, because it allows computational comparison between different levels, assuming higher levels are represented with greater numbers. For this reason, InLOC provides for an unambiguous number as part of the method of representing relationships.

This is a particular new feature of InLOC, and is so important that it is explained more fully below, in the section on "Defining proficiency levels and generic levels".

Modelling structural relationships

For economy and simplicity, InLOC uses this same general purpose structure for all of these relationships, illustrated here:


Figure 6: associations between LOC structures and definitions.

Figure 6 shows each LOCassociation having a subject, a scheme and an object. The reason why it is called "scheme" will become clearer later. For these structural relationships, the subject, scheme and object must all have identifiers. (We will see later cases where not all have ids.) In all cases, they may also have labels, if needed to aid human understanding of what the subject, scheme and object refer to.

Seen together, these are the relationships for structural LOCassociations relating LOCdefinitions within a LOCstructure. The nature of the relationship is specified by having one of these values in the scheme.id of the LOCassociation.

These can also be given as their inverses, with subject and object swapping roles.

Because they relate together parts of the same structure, these relationships are suitable for the inheritance of properties that are usually shared through a whole framework LOCstructure. For more detail, see the Information Model sections on relationships, and on property inheritance.

Sub-structures

In many cases, including the e-CF, the obvious approach is to represent just one LOCstructure, which is associated with all the LOCdefinitions and other relevant information. However, if the e-Competence A.2 was to be represented as a structure in its own right, with self-contained documentation, there would be a need to specify that it was part of the larger e-CF LOCstructure.

The situation is quite similar with UK NOS documents, and InLOC has an analysis of one of these, CFAMLB5. In these cases, the situation is that the document does essentially no more than express and structure a single LOCdefinition in terms of its constituent parts.

In the case of e-CF, these constituent parts include the levels and the examples of knowledge and skills; in the case of CFAMLB5, these constituent parts are the performance criteria, and the items of knowledge and understanding (which are similar to the e-CF knowledge examples). In both these cases, there is no other title and description for the whole document (and thus LOCstructure) than the title and description of the main LOCdefinition.

InLOC can handle this by including the information proper to the main LOCdefinition, the information belonging to its constituent narrower LOCdefinitions, and the relations between these, in a LOCstructure that has an identifier, but no title or description of its own. InLOC allows the statement that the lesser LOCstructures are part of a greater one, using isLOCpartOf.

For more detail, see also the LOCstructure section of the Information Model.

Relationships potentially outside the LOCstructure

In an increasingly networked world, it is becoming more and more important to relate LOCdefinitions to other ones from different authorities. This can be simply for their reuse. When LOCdefinitions are easily available across the Web, it may be advantageous to refer to the source of the information than to copy it. And to allow the greatest degree of automatic comparison, there needs to be a way of showing when a LOCdefinition in one framework is equivalent to one in another framework, or similar. Relationships suitable for expressing similarity are already formalised within SKOS [SKOS].

InLOC here provides two relationships that are equivalent to the ones in SKOS:

Another relationship that frequently occurs in curriculum structures is connected to sequence, or logical dependency. An earlier stage learning outcome must often be attained before learning commences with a later stage one is intended. As there seems to be no universally agreed name for this, InLOC provides

and its inverse

When dealing with structures and definitions that have been revised, perhaps independently of each other, it may be very useful to express which newer resource replaces which older resource. Dublin Core [DCMI] already contains suitable relationships:

and its inverse,

The most general associative relationship, with a less well-defined meaning, also has a SKOS equivalent

No further types of relationship are currently specified in InLOC, though it is possible to use other relationship types that are not specified in InLOC, as one kind of extension of the specification.

The SKOS documentation implies a distinction between relationships within a concept scheme and relationships across different concept schemes. However, as information about InLOC concepts may be provided in many ways, it is hard to justify this distinction in the context of InLOC. Electronically, a LOCdefinition may be presented by itself, or it may be presented within a set (a LOCstructure) of any size. The InLOC position is therefore that any relationship can be applied between concepts either represented in the same framework, or represented in separate frameworks, regardless of whether they resemble SKOS "semantic relations" or SKOS "mapping properties".

Defining proficiency levels and generic levels

Already described above is the way in which the e-CF defines levels of each e-Competence, and how InLOC represents those level definitions, using the "hasDefinedLevel" relationship to link specific e-Competences to the definitions of performance levels of that e-Competence.

As well as defining specific levels of each e-Competence, the e-CF also describes the levels themselves in general terms. In each case, an identifier, a title and a description may be distinguished. Part of the e-CF documentation is reproduced in the figure here.


Figure 7: generic e-CF levels

In Figure 7 what could be called the "generic" e-CF levels are defined. These give descriptions of five overall levels at which ICT professionals could be operating. They are labelled "e-1" to "e-5" here, but this is obviously intended to be the same as the "Level 1" to "Level 5" labels used when giving the proficiency level descriptors on each e-Competence page.

These generic levels were omitted from Figure 3 above, so Figure 8 redraws Figure 3, moving selected information from Dimensions 1 and 2 over to the right, and putting in the generic levels on the left of the diagram.


Figure 8: how generic levels fit into the e-CF

InLOC representation of levels

InLOC represents each of these generic levels as a LOC definition. Naturally, as these level definitions are more generic than the kind of level definitions we have met with above, the range of evidence that someone could produce for their working at a particular level is much wider – similar to all the combined evidence of their working at that level in each of the applicable e-CF e-Competences. The generic levels relate to the e-CF as a whole in a similarly to the way that an e-Competence relates to its particular proficiency levels, so InLOC used the same relationship: the e-CF "hasDefinedLevel" each of the generic level LOC definitions.

In Figure 8, it is pointed out that the specific proficiency levels of an e-Competence correspond to the generic levels, but this relationship needs to be clarified to fit into the InLOC model. There are two main options for relating each generic level to its specific level definitions. If the specific levels are seen as comprehensively detailing all the aspects of that level, they would be related through the hasLOCpart relationship. Alternatively, if there is likely to be more to the generic level than the sum of the specific level definitions, one could say that the generic level hasExample each specific level.

For the case of the e-CF, it seems more appropriate to use hasExample, and this seems likely to be true for most general frameworks. This would be different from the case where perhaps a qualification is defined similarly to a generic level, and the qualification has a clearly defined set of compulsory constituent parts.

The role of "number" in InLOC level definitions

There are many possible applications where people need to be able to compare proficiency levels. For example, if the competences required for a role were expressed in terms of proficiency levels, then finding people suitable to that role would need to include people who had more than the required level of competence, not just exactly the required level of competence, or else suitable people would be missed.

The e-CF has some very convenient numbers, "1" to "5", which can be used for this purpose. Clearly, "e-1" and "Level 1" both correspond to the number "1", etc. The EQF is the same, with numbers "1" to "8" in a clear rising progression. However, this is not always the case in other frameworks. Some levels are labelled with "1" at the top, and lower levels with greater numbers. This includes traditional British degree classification. Some levels are completely or partially non-numeric. In these cases, there is no clear way of automatically comparing levels. But the whole point of defining levels, or stages, or phases, is that there is expected to be a linear progression, with later or higher levels encompassing earlier or lower ones. This exactly fits with a numeric representation, and explains why numeric representations are so popular.

How can proficiency levels, or levels of competence, then be compared where there is no obvious numeric scale in the normal sense? It is to answer this that InLOC provides the "number" element in its information model. This "number" is required to be numeric, not just a textual representation, and therefore guaranteed to allow comparison. But to allow comparison to happen, numbers must be allocated.

Scales for proficiency levels have been done in many ways in various frameworks. The intention with InLOC is to allow the framework owner to choose the numeric scale that seems most familiar and intuitively reasonable for them, because there is no way in which anyone can expect comparability between raw numbers in different level schemes. For example, people from an academic or educational background may be familiar with marks out of 100. What matters is not the actual scale, but the relating of points on the scale to descriptors. If there were a test or examination, marked out of 100, perhaps "40" might indicate a bare pass, "60" a merit and "80" a distinction, and those categories might have descriptors explaining the characteristics of learners achieving those categories. But there is nothing special about the number 100, except its familiarity through the use of percentages. But these kind of marks or points normally work in the same sense, with greater marks being better performance.

It is a requirement for InLOC representation that all levels are allocated a number. This may be very straightforward, as with the EQF and the e-CF, or it may take extensive consulation with the framework owners, but it must happen, in order to allow the comparison that is vital for many practical uses of level information.

Properties of LOCstructure and LOCdefinition

It is clearly essential to have titles and/or descriptions of these concepts and structures, alongside identifiers to help technological implementation. But there is often more information that can usefully be recorded about learning outcome or competence structures and definitions, apart from the relationships between them that have been covered above.

Information such as relevant dates is often usefully represented separately, so that it can be machine-processed. Information about the languages of text is best represented explicitly in a standard way, so that the most helpful language can be automatically presented to readers of documentation. Many of these kinds of information are represented simply, by one chunk of text, possibly in some standard format. This fits in with the idea that a "property" of something has a single "value", which cannot usefully be separated into more basic parts. These properties are tied directly to the LOCstructure or LOCdefinition.

On the other hand, there are several kinds of information which could be called "compound". For instance, when giving information about an author, do you give the name, an e-mail address, a FOAF URI, an identification number, or what? Names are not unique. Not everyone has an e-mail address. Some people have a website where more information can be found about them. For a good, flexible representation, this kind of information needs to have a defined compound structure.

In the field of ICT for learning, education and training, there are other such "compound" properties. A topic, for example, may have a useful, machine-processable entry code, but to understand and process that code, one may need details of the catalogue it comes from, or where to resolve the code. For another example, a credit value only makes sense in the context of the particular credit transfer or accumulation scheme that it is awarded within. Both pieces of information need to be represented separately, for proper machine processing. In the InLOC documentation, these are known as "compound properties".

Very generally, there are two approaches to representing these compound properties. First, a separate element may be defined for each separate kind of property, with a structure that represents the expected component parts of that particular property. Second, a general purpose structure may be used, with each kind of property fitting its component parts into the same general structure. InLOC has chosen the second kind of approach, because of the benefits in terms of both simplicity of the information model, and ease of extensibility. These compound properties also share the same structure as relationships, as will now be discussed.

"by"

There are four Dublin Core [DCMI] metadata terms that refer to "agents" (people or organisations): "creator", "contributor", "publisher" and "rightsHolder". More than just a name is needed for describing these agents unambiguously. For example, the Atom Syndication Format [Atom] has a three-part person structure, consisting of name, e-mail and URI.

InLOC uses the term "by" to denote this group of compound properties. While terms like "authorship" do not cover all relationships with agents, all can be described using the word "by", in these cases: "was created by ..."; "was contributed to by ..."; "is published by ..."; "has rights held by ...".

These compound properties tend to apply to documents, which would usually correspond to LOCstructures. LOCdefinitions that are created along with a LOCstructure would normally inherit these properties from the LOCstructure in which they appear. Here is some information of this kind from the e-CF [e-CF].


Figure 9: information on who the e-CF is produced by.

The e-CF here specifies who created and published the Framework itself (which is a LOCstructure), and this is assumed to cover all the included LOCdefinitions, as they are all published as part of the e-CF as a whole.

InLOC represents these "by" properties using a LOCassociation whose subject is the LOCstructure (or LOCdefinition) about which the information is given; whose scheme.id specifies the exact property; and whose object details the person or organisation who is the agent of that property.

Further details can be found in the Information Model, and the specific documentation of "by".

"level"

Above, defining levels has been explained as being done with an InLOC relationship. This is logically separate from assigning levels in an external scheme, which is done here with a different type of LOC association.

This level type of LOCassociation represents, in the e-CF example, how the e-CF generic levels refer to the EQF levels. The e-CF refers to the EQF in the same table, some more of which is reproduced as Figure 10 here. The LOCdefinition that defines the generic e-CF level has the (compound) property of being attributed a particular level in an external level framework — in this case, the EQF.


Figure 10: EQF levels alongside e-CF levels

A level number means nothing without identifying also the level scheme. As reproduced in Figure 10, the e-CF gives the level scheme ("EQF") and the level numbers, and even the definitions of the EQF levels. In fact, the descriptions given at each EQF level are composites of the three areas given in the EQF: knowledge, skills, and competence.

To represent this connection between e-CF levels and EQF levels, in this LOCassociation the subject, as always, is the LOCstructure or LOCdefinition that is being talked about – in this case, the LOCdefinition representing the generic e-CF level. The scheme represents the external level scheme, in this case the EQF, and the object represents the actual level within that scheme. To ensure that the level number is unambiguously represented, the number attribute of the LOCassociation should hold the proper decimal number for that level of the external scheme (in this case, the EQF level number). It is vital to correct machine processing that all these numbers work in the same sense. Therefore, for InLOC represented information, a greater number always means a higher level.

Having other structures refer to levels defined in the current framework

As we have seen, the e-CF defines its levels generically, as well as specifically for each e-Competence, and it is possible for anyone to refer to an e-CF level from outside the e-CF, either to a generic or a specific level. It is therefore important to refer to the correct level identifier.

There are many ways of doing this, but for illustration, assume that InLOC representations are used. To refer to a generic e-CF level, the scheme.id could refer to the e-CF as a whole, using the id of the LOCstructure for the e-CF, and the object would refer to the id of the generic level within the e-CF. Alternatively, if someone wanted to refer to a specific level of a particular e-CF e-Competence, the scheme.id could be the identifier of the e-Competence, and the object.id would be the identifier of the specific level of that e-Competence. In both cases, the level number is given as the number of the LOCassociation.

Thus, there is no difference in principle between a LOCdefinition referring to an external level, and an external definition referring to a level defined within an InLOC structure.

If the external documentation did not use InLOC conventions, there is much less that one can say about the proper way to refer to InLOC-defined levels. But representing a framework in InLOC offers a good range of information to refer to, and from one or more pieces of this information it should be possible to work out which level is actually referred to.

For more detail, see also: the brief formal note on the InLOC treatment of levels within the Information Model documentation; part of the documentation of type; and also the specific documentation of "level".

"topic"

The topic or subject of a learning outcome is most usefully represented, not as a single string, but as a term from a particular catalogue scheme or vocabulary — for instance, the familiar library subject classification schemes.

The scheme represents the topic catalogue, and the object represents the term within that catalogue.

Further details can be found in the Information Model, both in the documentation of type, and the specific documentation of "topic".

"credit"

Intended learning outcomes may also be associated with credit values in some credit accumulation and transfer schemes, working towards qualifications. The CEN Workshop on Learning Technologies has already produced CWA 16077 [CWA_16077] for representing credit, and this has a three-part structure: credit scheme; level; and numeric credit value.

Further details can be found in the Information Model, in the documentation of type, and the specific documentation of "credit".

"category"

Beyond these properties that are of particular use for learning education and training, general classification also fits into this same LOCassociation structure. For example, the [Atom] category structure has three parts: scheme, term, and label. If converting an Atom representation to an InLOC one:

From the e-CF documentation [e-CF], here is some information that might be appropriately represented using category.


Figure 11: some possible categories for e-CF categories.

Representing the information in Figure 11 can potentially be done in several ways, and InLOC does not attempt to standardise it. At the simplest, all this information could simply be reproduced in text or diagrammatic form as further information. If it were seen as useful to represent any of the information in a way that is comparable by ICT systems, then for example category schemes could be published for, e.g.:

and these category schemes could be used with the InLOC category LOCassociations, as described above.

The "Typical Tasks" could be given either as of type category, or perhaps of type topic, as they look rather like topic headings. Perhaps, in a future revision of the e-CF, the typical tasks could be given referring to some standard classification scheme such as (at present) SOC (standard occupational classification) codes, or in future something from ESCO[ESCO].

Further details can be found in the Information Model, in the documentation of type, and the specific documentation of "category".

To what does a LOCassociation belong?

There are different possibilities for integrating these compound properties into an information structure. InLOC takes the view that, in order to keep LOCdefinitions small and clearly reusable, and because different authorities might have different views on what compound properties attach to a LOCdefinition, compound properties (expressed by LOCassociations) are all regarded as tied to the LOCstructure, even the ones giving compound properties of LOCdefinitions. The LOCassociation format requires compound properties to specify their subject, as the subject cannot be inferred from the position of the LOCassociation in an InLOC document.

The "type" of LOCassociation

A type must be specified to distinguish relationship information from compound properties. InLOC uses the type name "LOCrel" to signify relations between LOC entities, and other names as above to specify the kind of compound property.

Adding "LOCrel" to the list of kinds of compound property that have been explained above, the full list of LOCassociation types defined by InLOC becomes:

The type determines the semantics of the other parts.

For further detail, see the Information Model documentation on type.

LOCassociations are allowed an id

It may not be necessary for LOCassociations to be identified explicitly, but in order to facilitate situations in which this might be useful, InLOC allows the possibility of giving each LOCassociation its own id, distinct from the ids of the containing LOCstructure, and the ids of subject, scheme and object.

This then completes the picture of the information model structure of an InLOC LOCassociation.


Figure 12: The complete model for LOCassociations

Direct properties of LOCdefinitions and LOCstructures

There have been several specifications that have tackled the issue of representing what are called here LOCdefinitions. Though they differ in detail, all these various specifications similarly define what is fundamental to a definition of a learning outcome or competence concept. To begin with,

These are so central to so many specifications that we rightly take them for granted. These are all Dublin Core metadata terms [DCMI] as well.

When sharing of information is being considered, it is vital to be clear about the copyright, licensing and any other rights. InLOC again follows Dublin Core in providing a property for

In many cases this should be sufficient — though a more detailed breakdown in this area might be needed if it were desired to process this information automatically, and not simply have it read by people.

These properties can be seen either as fundamental to the meaning of a LOCdefinition, or as metadata essential for electronic systems holding, sharing, referring to, and potentially reusing the information in different contexts. Whenever a LOCdefinition is communicated or reused, there is good reasons why all available information of these kinds should also be carried along with it.

Each of these properties consist of one piece. The ones in a human language may be repeated once for each different language.

A LOCstructure will often represent a published framework document, with its own information and properties that are not necessarily shared with the included LOCdefinitions. This is the case with the e-CF, the example here.

As a document, a LOCstructure may have its own title and description. Whereas a LOCdefinition is about a concept against which an individual can gather evidence and be assessed, a LOCstructure associates a set of these LOCdefinitions, put together for a particular purpose, or with a particular end or use in mind.

Authorities often publish frameworks of competence or skills, perhaps defining what counts from their point of view as the constituent parts of a competence. This may be from the point of view of qualification or licensing. In these cases, there may well be different versions over time, with particular dates of validity. InLOC therefore recognises

all of which are common with editions published on paper. The e-CF does have a date of publication, and an associated version, "2.0", but has no explicit dates of validity.

Often, level or credit frameworks are routinely referred to by an abbreviation. The European Qualifications Framework [EQF] is known as "EQF"; the European Credit Transfer and Accumulation System [ECTS] as "ECTS"; other qualifications and credit frameworks or systems are similarly widely known by their initials. For this reason, InLOC includes an

property to hold a standard abbreviation, which may differ in different languages. A reasonable English abbreviation for the European e-Competence Framework would be "e-CF", though it could also be known as "eCF", and this is one of the reasons it would be useful to have the official abbreviation defined rather than left to personal preference.

There is often significant information about a LOCstructure that is not comfortably represented in a direct "description" field. In contrast to the typically plain format of the title and description, this information benefits from a freer, more open format. InLOC therefore provides a

property that is intended to be left entirely without restrictions on format or medium. If it were important not to lose any of the information published, or implied by the layout of the documentation, a reasonable approach would be to represent a whole formatted document as furtherInformation; or smaller chunks of furtherInformation may be distributed around a document.

These latter direct properties originally designed for LOCstructures could also reasonably be applied to LOCdefinitions. An individual LOCdefinition could well have further information; it could have an abbreviation; it could have separate publication and validity dates, and a version number. Furthermore, having the same direct properties for both structure and definition means that property inheritance rules may be specified for all of those properties, across LOCdefinitions and their containing LOCstructures. In the light of these considerations, InLOC adds these extra properties to both LOCstructure and LOCdefinition at the same time.

Two last properties emerged during review. First, particularly when some narrower LOCdefinitions are optional, it may be that there are rules governing the combinations of the necessary and optional narrower LOCdefinitions within a broader LOCdefinition. The challenge is that these combination rules may differ according to context. If they were included as one of the direct properties of a LOCdefinition, that definition could not be reused in another context.

InLOC therefore defines combinationRules as a literal text property of a LOCstructure, not of a LOCdefinition. If it is required to define combination rules at a finer granularity than for given structure, then sub-structures must be defined.

Second, particularly in view of the fact that LOCdefinitions may be reused in different LOCstructures, if information about a LOCdefinition is to be communicated separately from a containing LOCstructure it may not be clear what it means, out of context. Therefore, InLOC allows the primaryStructure of a LOCdefinition to be defined, pointing to the LOCstructure that is, so to speak, the "home" of the LOCdefinition. This property is not needed for LOCstructures, because they have LOCassociations that can specify what they are parts of.


Figure 13: The InLOC model completed with all the direct properties. Note that in this and similar diagrams, a '*' following an element name indicates that the element may be repeated.

This completes the basic diagram of the components of the InLOC model, but there remain a few other particular points that deserve further detailed explanation.

Modelling optionality

Most people are familiar with structured learning, education or training studies that have some compulsory parts and some optional parts. Perhaps less familiar is that competences themselves may have different ways of being achieved; and that to be competent, it is not always necessary to have a complete set of knowledge and skills. It may be sufficient to have mastered one of a range of possible approaches. This means that optionality may be important also in defining competence.

For example, many business functions related to computer programming of software can be achieved using any of a range of programming languages. There may be constraints in the environment, to do with the systems in use in a particular work environment, but nevertheless jobs can be done equally well using a range of languages, and sometimes also a range of different techniques within that programming language. A person may therefore be fully competent at a particular kind of programming in a range of separate ways. The representation of competence may not need to specify the programming language. But few programmers are fully up-to-date with a wide range of programming languages, so their actual abilities are not identical, even though their competences may be equivalent.

It might therefore be quite reasonable to represent competence at programming as having some necessary parts and some optional parts. Many programming languages share most of their general features, differing perhaps mainly in syntax, but equally there are more basic differences which mean that ability in one programming language may transfer to a different extent to different other programming languages. Some of these differences may be taken as optional parts of the overall competence in computer programming. To master any one programming language properly, some, but not all, of these different features will have to be learned. To convert from competence using one programming language to using a different one, some new features may have to be learned.

To represent this, the simplest distinction that can be made is between necessary and optional parts of a competence. This distinction by itself does not tell you which of the optional parts may be more or less important than which other ones, but some conclusions can still be drawn. If a part is necessary, then if you have the overall competence, you will have that part of the competence as well. That is, if you are competent at the whole, you are necessarily competent in terms of the necessary parts. The fact that something is optional draws attention to the fact that there may be some rules for determining which optional parts fit together with which others.

InLOC examples of optionality

As the e-CF has no explicit optionality, we have to take another example to illustrate it. The UK QCF (Qualifications and Credit Framework) has many good examples. Taking an arbitrary one, the Edexcel BTEC Level 3 90-credit Diploma in Business , we can see how it is structured into mandatory and optional units. The "Structure Requirements" are "To achieve this qualification learners must achieve all 40 mandatory credits in Group A, plus a minimum of 40 optional credits from Group B for the unendorsed route, or from PG for an endorsed route. The remaining 10 credits may come from B or Z. A minimum total of 90 credits." Group A comprises the units "The Business Environment", "Business Resources", "Introduction to Marketing", and "Business Communication". The units in the other groups are extensive, and are best seen on the QCF site itself.

This text would be placed in the combinationRules property of the LOCstructure for that particular qualification.

The InLOC view is that this distinction between necessary (or mandatory) and optional is consistently meaningful and well-recognised in by everyone, therefore it belongs in an interoperability standard. The relevant relationship types, "hasNecessaryPart", "hasOptionalPart" and their inverses have already been introduced above.

Handling multilinguality

As mentioned above, the e-CF has been produced in several different languages, using the same internal identifier codes. But with the increasing versatility offered by electronic communications, the requirement is emerging for a more flexible approach to multilinguality.

The InLOC approach is not at all new, and can be stated briefly.

  1. As is very common, if there is a single or dominant language of a whole document, the language can be given in the root LOCstructure or LOCdefinition element. In XML, this is typically implemented as a language attribute xml:lang within the root element tag.
  2. For multilinguality within a document, InLOC adopts the same general approach as in many other specifications, allowing human-readable strings to be given multiple times, each one with a different language attribute. Again, in XML implementation, this is commonly represented through a xml:lang attribute within each human-readable element. Software systems, when instructed appropriately, can then select the appropriate language version.

How to follow InLOC in the structuring of LOC information

The aim of this section is to explain, in basic terms, what someone needs to do in analysing an existing framework or other structure of learning outcomes, skills or competence (LOCs), in order to represent this in InLOC terms. It should be read after looking at the example in the previous section, InLOC explained through example, though not all the detail of the last section needs to be understood.

For ease of communication, this section will use the 2nd person, "you", for the person who is analysing LOC-related information. The assumption is that you are trying to put some information about learning outcomes or competence into InLOC format. Here, it is explained how you can apply the InLOC conceptual model to the information of interest to you. This is referred to here as "your" information, "your" structure and definitions, etc., because it is of your interest, independently of whether you are the owner of the documentation.

This explanation is a basic one, which deals with the most likely cases. To appreciate this section fully, you will need to be looking at documentation about your learning outcomes and/or competences. You are taken through the process of thinking about your information in InLOC terms.

In order to represent and store information in InLOC format, you will need to use some ICT tools. This section does not explain the use of any such tools, but will prepare you for using any such tool.

Before reading this, you may also find helpful the Overview and Orientation, and the Information Model section on the Features of the InLOC Model, which introduces the ideas of the LOC structure, the LOC definition and the LOC association.

Recognising LOC definitions

To represent your information in the InLOC style, the first thing you need to do is to clarify what your LOC definitions are. This is absolutely essential to InLOC analysis.

In principle, if a single piece of text refers to one concept that could be assessable, or for which you could gather evidence, you can take it as defining a LOC concept. Don't worry at this stage about how vague it is. Even if it is only one word, that may still be fine. Typically, there may be many different layers of LOC information in a single document, and they will mostly be LOC definitions. Looking at the previous section, you will see how LOC definitions were recognised at several different levels. To visualise this, red outlines have been drawn round each identified LOC definition, and you could do something similar on paper documentation.

Things that people might be able to do are all LOC definitions. Statements about what people have to know, or know about, or understand, are also LOC definitions, where they underpin effective abilities. Role and task definitions can be considered as LOC definitions, because people may or may not be able to fill them – they may be assessed, and evidence considered about how well people perform tasks or fulfill roles.

If the question "how well are you able to do this?" is meaningful, looking at a single piece of text, along with its context, then that will be a LOC definition. Other indicative questions are "are you good at this?", "how much do you know about this?", or simply "can you do this?". For more general or vague LOC definitions, you may be able to ask "what can you do in the area of ...?" or "what evidence do you have for this area of competence?", so they are still LOC definitions.

On the other hand, a definition of a tool is not in itself a LOC definition. Knowing about a tool may be a LOC definition, but you do not have to know much about e.g. a car or a computer to use them.

Notes about scope are not in themselves LOC definitions, but rather are about the range of applicability of LOC concepts. Someone does not necessarily need to know about the limits of an ability in order to have it, though recognising the range of one's effectiveness may itself be a useful piece of knowledge to have, and therefore may be defined separately in a LOC definition.

The process of clarifying each LOC definition continues through deciding on a title, a description, or both.

Title

Titles look like names of concepts. If it's a sentence, it probably isn't a title. Titles can sometimes be just one word, as the example in the previous section, "PLAN". Recall that the title must the title of a LOC concept that could be assessed, or for which evidence could be provided. If the title is not like that — for example, containing the terms "unit", "structure", "framework" — then it might in fact be a LOC structure instead.

Description

Descriptions are generally longer than titles, though the boundary is not perfectly clear. But you should make the same decision for each piece of text that has the same role in your model. The distinction between titles and descriptions in practice is not great, but mainly in how they are shown on a page or screen.

For InLOC purposes, every LOC definition will need to have either a title or a description, and it may have both. Quite often, the narrowest LOC definitions, at the low end of your hierarchy, have a definition and nothing else – no title. In the previous section, the levels and the examples were like short phrases or sentences, that did not look like titles, so these pieces of text were taken as descriptions. On the other hand, the e-CF "e-Competences" have both a title and a description.

Identifying the LOC structure

Your LOC structure will in many cases be the whole document you are looking at. The LOC structure is always what contains and relates the LOC definitions you have identified. This may be called a "framework", or possibly something like an occupational "standard", or a "unit".

The simple case is where the documentation defines all the LOC definitions within it. It is less simple when a LOC structure "borrows" LOC definitions defined elsewhere, but usually this is fairly obvious and self-explanatory.

There may be a substantial amount of information in the LOC structure apart from the LOC definitions, and this will be dealt with later.

Sometimes (e.g. in [UKNOS]) a document that obviously defines a structure has a title that could quite reasonably be the title of a LOCdefinition. Individual UK NOS documents are small, and typically could be seen as expressing structure for a main LOCdefinition in terms of LOCdefinitions with a finer granularity.

This can be resolved, and a useful distinction between LOCstructure and LOCdefinition maintained, as follows.

Associating your definitions within the structure

Typically, your documentation will describe a hierarchical structure, with one or more LOC definitions at the "top", and with these analysed into narrower LOC definitions, until you get to a level or granularity where further analysis is of less value.

First, you need to state that your structure contains the top level definitions you have identified. To deal with this in InLOC, you create a LOC association for each one of these relations – that is, one for each top level LOC definition. Then, you need to say how the LOC definitions relate to each other. For example, if they were simply of the form "A consists of B, C and D" then you would record three LOC associations representing A having each of the three LOC definitions B, C, and D as parts.

For all of these relations, you can also record the inverse one if you like, if it helps in your documentation. However, any effective system will understand that if A has B as a part, then it follows logically that B is a part of A. This discussion continues using only the first kind of relationship.

To represent these part relations most generally, InLOC uses the relationship "hasLOCpart". But there are four more specific ways to be a part, described here, which should be used if appropriate.

Optionality

If some of your components are compulsory/mandatory/necessary and others optional, then instead of "hasLOCpart" you need to use "hasNecessaryPart" or "hasOptionalPart" accordingly.

Examples

If some of your components are just examples, then instead of "hasLOCpart" you should use "hasExample". You can recognise a list of examples, because they are not exhaustive, and it appears that other different examples could be added to their list. When you have evidence for examples, that is suggestive, not conclusive evidence for what they examples are of.

Defining levels

This is a substantial matter to understand properly, but vital to many structures. It is introduced in the Information Model section, "InLOC treatment of levels".

You may not call them "levels": your term may be "stages", "phases", or something else. The essential feature of levels, under whatever name, is that having a learning outcome or competence at a higher level implies having the lower levels as well. Typically, the level definitions may look quite similar, and you can ask the question, whether a particular level has been attained or not, with the answers "yes" or "not yet". If, on the other hand, your learning outcome or competence definition allows people to be ranked in order, or in several categories, on that competence, then it is not itself a level definition, though it may have level definitions defined on it.

Each level definition is still a LOC definition, but when defining levels, instead of the relationship hasLOCpart you should use "isDefinedLevelOf". This applies both to generic levels that apply across a framework, and specific levels of particular learning outcomes or competences.

If you have levels that are defined across your whole framework, these are generic levels. If you have descriptors for each level, in general, then that becomes the description for the LOC definition defining your generic level. Your generic levels may have abbreviations, too ("abbr"). The specific levels will use the same numbers as you define for your generic levels, but in contrast applied to specific learning outcome or competence definitions, so the specific level definitions will relate to the particular learning outcome or competence, more specifically than the generic level definition. You can then relate the specific level definitions as examples of the generic levels. This is all illustrated clearly in the e-CF example above.

When defining levels, you must give each level you are defining a decimal number (most simply, a whole positive number) where the greater numbers mean higher levels of learning outcome or competence. In the simplest cases, the number will be the number used in your documentation to indicate the level. But sometimes, the levels go the other way, with the lesser number being the higher level; and sometimes levels do not have simple numbers. To ensure that levels are correctly comparable, the number given as part of the InLOC representation must be such that the greater number is the higher level of ability.

Defining and relating the levels will then complete your task of relating your LOC definitions together. The overall structure will probably be tree-like, though sometimes branches recombine. In particular, when generic levels are defined, each specific level branches both from the specific competence it is a level of, and from the generic level.

More information about your structure or framework

Let us assume that your LOC structure is the whole document you are wanting to represent in InLOC. The title of the document will be the title of the LOC structure, and you will probably be able to find some text within the document that can serve as the description of the structure as a whole. Apart from the title and description, look for the following kinds of information, that are "properties" of the structure as a whole.

Abbreviation

Is your document a framework that has an abbreviation that is commonly known, or in common use? If so, note that InLOC will represent it as an "abbr" property.

Rights

If you are going to publish your structure, you should consider carefully how you want others to use them. Without dealing with the legal side, which may vary between countries, you can still state you intentions, however easy or difficult it is to enforce them. You could use the popular Creative Commons licences, but also include your own explanation of what you permit and what you would like people not to do.

InLOC gives a "rights" property for this, as plain text.

Dates and versions

InLOC defines 5 properties representing dates relevant to your documentation, and the first three properties are given names from Dublin Core [DCMI]. None are required, but the most appropriate ones should be used to represent dates that either appear in your documentation, or are otherwise known.

Dates, along with rights, will be assumed to be inherited by all the LOC definitions in the LOC structure, as long as they are not borrowed from some other structure. This means that you won't need to repeat these properties for each LOC definition.

Sometimes, different versions are produced of essentially the same documentation. Different version are likely to have different dates. But to aid distinction between LOC structures with the same title and description, InLOC provides a version property where the version identifier can be recorded.

Compound properties that have some structure

Apart from the structure itself, the titles, definitions, etc, the examples, and the levels, there may be other things in your documentation that might be useful to represent in a way that can be processed automatically. In InLOC, the following information is represented in LOC associations, as for the relations between LOC definitions discussed above. Each of these compound properties uses a different type of LOCassociation.

The selection of compound properties used in InLOC reflects both general purposes and properties more specific to the context of learning, education or training.

By whom?

This is the "by" type of LOCassociation. It is used to represent four of the properties from Dublin Core [DCMI]:

These "by" properties are inherited by LOC definitions within a LOC structure, so you will not need to repeat them, but none of the other compound properties are inherited.

Category

This is the "category" type of LOCassociation. It is used for any classification of the LOC structure as a whole, or any LOC definition. Categories are here (as most places) represented by referring to classification scheme, and a term from that scheme.

Educational credit value

In some newer educational credit schemes, credit is attached not only to courses, but also to the achievement of learning outcomes in ways not involving a fixed course. For that reason, InLOC allows a "credit" type of LOCassociation, where the credit scheme, the educational level, and the credit value can all be separately represented.

Topic

This "topic" type of LOCassociation is similar to category, but rather than classifying a LOC definition, it classifies the subject matter implied in a structure or a definition. There are places for a catalogue or equivalent, and an entry or term within that catalogue.

Levels in other level schemes

Separately from defining levels, it may be useful to associate a LOC definition with a level in another level scheme or framework. InLOC defines a "level" type of LOCassociation, which allows separate representation of the external level scheme, the level within that scheme, and a definite number for that level.

What to leave out

There may be other information in your documentation, that is not itself a LOC definition, or one of the pieces of information specified above about a LOC structure or LOC definition. However, it is presumably there for a purpose, and so InLOC allows it to be recorded for human reading – though it will not be automatically comparable to other such information. All of this further information — for example intended use, context, scope, etc. may be represented in InLOC with one or more furtherInformation properties. There could be an explanation of how you expect your learning outcome or competence to be assessed, or what evidence is relevant. The documentation might state what learning resources or courses will help toward a LOC. Within InLOC, the furtherInformation property of a LOCstructure or LOCdefinition is where this can be placed. Often, this information will have a formal and structured representation elsewhere, and it is not the task of InLOC to reproduce this. Courses will be described in course catalogues, and may refer to InLOC information. Personal achievements and qualifications may be in an e-portfolio that refers to InLOC information, and so on. But this information has no proper place in InLOC.

You should take particular care that your LOC definitions are not tied closely to information that is not relevant in another context that the LOC is relevant in, and then they will be able to be reused.

Important information that is often not represented in paper documentation

Identifiers

For use in ICT systems, it is vital to have clear identifiers that are universally unique. The practice in paper documentation varies considerably. Sometimes one sees codes within a document or group of documents, and where these appear, it makes sense to incorporate these codes into the proper identifiers that are needed in InLOC, for each LOCstructure and each LOCdefinition.

If a LOCstructure has a proper unique identifier, then by using that along with internal codes for each LOCdefinition it may be straightforward to generate all the necessary universally unique identifiers for each LOCdefinition. It may be that a tool helps in this.

A LOCstructure or LOCdefinition may have more than one identifier, particularly if it is used in different contexts. However, for the integrity of InLOC representations, in this case one identifier must be used as primary. Other identifiers are regarded as secondary, but are placed in extraID properties, so that they can also be recognised and processed by ICT systems.

Languages

Paper-style documentation is usually in just one language, with a separate document produced for any translation. It is self-evident which language a document is written in. This is not always obvious for electronic documentation. InLOC allows both the representation of an overall language for documentation, and the representation of a language for each piece of information that is intended for human reading. This allows an InLOC representation to be multilingual, without needing different language versions to be published separately.


Extending InLOC

If extra information needs to represented that is not specified by InLOC, it could be added in some other way to an InLOC representation. However, such additions will not be able to be interpreted correctly by external systems, so these are only useful for internal communication, or where specific agreements are made between the communicating parties. This is often call application profiling, for people interested in building application profile of Inloc specification they could read the CEN CWA Guidelines and support for building application profiles in elearning (pdf) in addition to the explanation given in this section.

Further information

If it is desired to put in extra information into an InLOC representation without affecting, for example, XML validation, it is possible to include any information, both about LOC structures and definitions, as furtherInformation. Any attributes may be added to indicate the nature and role of the information, and for an XML binding, any information containing markup that would interfere with XML validation may be enclosed in a CDATA section.

Extending unchecked vocabularies

This will not affect validation unless the vocabulary is somehow checked, which is it not in e.g. the proposed XML XSD.

Vocabulary for the LOC association type "LOCrel"

Representing the structure of LOC information – that is, the way in which LOC structures and definitions relate together – is done with InLOC relationships, which are represented as LOCassociations of type "LOCrel". The scheme.id is taken from the list of URI values specified by InLOC, listed as the InLOC relationships. InLOC can be extended by adding new relationships to this list, providing they do not duplicate or overlap with the existing ones.

For example, if there were a need to document what LOC definitions had nothing in common, it could be done with an extra relationship.

Vocabulary for the LOC association type "by"

The type "by" is intended to be used to represent information about authorship, or anything relating a structure or definition to agents (people or organisations). The list of possible values may be found with the InLOC compound properties, and is drawn from Dublin Core [DCMI]. It is easy to imagine other possible relationships for use with agents that can be added in place of these, and these could be used, as long as they did not duplicate or overlap with the existing kinds of compound properties.

For example, one could add extra scheme.id values indicating who had reviewed a particular LOCstructure or LOCdefinition, or who had authorised its publication. Alternatively, one could imagine an organisation with a person with responsibility for a particular competence. That would also be suitable for representing through the "by" type of compound properties.

New types of LOC association

The types of LOCassociation group together properties with related semantics, and all LOCassociations must have a type for this reason. The defined types for InLOC are listed on the type page.

It is possible to invent and use some other type, for any compound property not adequately covered by the property types already specified by InLOC. But as the types will typically be checked (as they are by the XSD in the XML binding), the validation files or mechanism will also need to be changed accordingly.

For instance, in a system where there are substantially different kinds of topic, they could be represented by new types instead of the plain InLOC topic.


Referencing InLOC information

One of the main purposes of InLOC is to provide a way of structuring learning outcome and competence information so that it can be referred to clearly from other places. To give examples that have been central to InLOC's vision:

Electronic versions of these have their own specifications, and InLOC is not intended for their complete representation. So the question arises, how, from within any of these other specifications, may reference be made to InLOC information? The challenge is to give enough reference information in the "host" specification to be able to identify what it is exactly that is being referred to in the InLOC structure.

InLOC elements that could be referenced

InLOC specifies that universally unique identifiers be provided for LOC structures and for LOC definitions. The other clearly machine processable element is "number". As LOC definitions may take more than one role, there are at least four roles played by InLOC information that may be referenced.

  1. The LOC structure gives context, and all the structural relationships: its identifier may be referenced.
  2. A LOC definition may represent a fully defined concept, but equally it may be a concept that is less than fully defined. Its identifier may be referenced.
  3. In cases where a LOC definition is not fully defined, or can be interpreted as existing at more than one level, a supplementary LOC definition may be referenced through its id, giving more specific definition to the concept.
  4. A number corresponding to the "number" property of a LOC association can be given, alongside a level scheme properly constructed in InLOC, to indicate a level. The number itself may be given explicitly in a particular LOC association, or it may be compared to the numbers given by more than one association in the LOC structure.

Possibilities for reference to InLOC

Referring to a single, well-defined LOC concept

The simplest option for referring to LOC information occurs when the exact learning outcome, competence, etc. is fully defined, in terms of a LOC definition that leaves no vagueness or ambiguity in the way in which is it defined. In terms of the InLOC Information Model, unambiguous reference to this will be to the id of a single LOC definition. Information about that LOC definition could in principle be searched for in a number of ways, including using a search engine adapted to find the URI identifiers used in the id property. However, the simplest way to retrieve information will be possible when the owner of the LOC definition provides information shown when the URI is entered into a browser (through an http request). When information about a separate LOC definition is communicated, it should include the information specified as being contained in a LOCdefinition element of the Information Model. This includes the property "primaryStructure", which refers to a LOC structure, and when this is in turn requested, all the rest of the contextual information about the LOC definition should be able to be found.

To imagine an example here, let us suppose that some specification allows mention of an intended learning outcome. If the specification has been conceived primarily for structuring human-readable text, this learning outcome is likely to be a simple text element, that may be repeated, in XML looking perhaps like this:

<learning_outcome>(the description of the learning outcome)</learning_outcome>
<learning_outcome>(description of another learning outcome)</learning_outcome>

This kind of pattern can be found in several places in existing XML-bound specifications. The particular form here is a generalisation, and does not reproduce any particular existing specification. Take the first learning outcome. Imagine it is defined within a LOC structure, and the particular LOC definition with that wording has URI http://example.eu/loc/def/1234. How would this be included in the host specification?

There are two ideas that are extremely simple, but not effective. First, the URI could be put inside the text element:

<learning_outcome>http://example.eu/loc/def/1234
     (the description of the learning outcome)</learning_outcome>

This would be little use, as there is no easy and reliable way of separating the URI from the text, particularly if the text is itself structured and might have other links inside it. Second, the URI could replace the text:

<learning_outcome>http://example.eu/loc/def/1234</learning_outcome>

However, this becomes unintelligible to a human without an internet connection. It would rely both on a live internet connection, and something reliable at the other end of the link. It also disrupts expectations: what if there is legacy content that uses the learning_outcome element as it was originally intended, as text?

More promisingly, the URI could be held alongside the text, in two new sub-elements:

<learning_outcome>
        <locref>http://example.eu/loc/def/1234</locref>
        <description>(the description of the learning outcome)</description>
</learning_outcome>

However, this would not be compatible with the supposed original version, because the description is now inside a "description" sub-element, where it was not before. A logically equivalent, but better option would be to place the URI in a new attribute.

<learning_outcome locref="http://example.eu/loc/def/1234">
     (the description of the learning outcome)</learning_outcome>

This has attractive consequences:

The attribute's name is not important to the logic: it could be called "href" or "src" or perhaps "uri" instead of "locref", which would affect only the speed of comprehension by someone reading the XML itself. Neither the attribute name nor the element name is likely to appear at any end user interface.

Whether this approach is fit for purpose depends on the purpose and the context. Assuming that the URI leads to a well-structured InLOC representation, and assuming that from the URI one can automatically find all the relevant information about that LOC definition, and assuming that this returned information is just what is wanted by the users of the host specification, then this could work well enough.

For future reference, this approach to referencing will be called "single-URI-LOC".

Referring to competence and level separately

Levels may be fully defined in an InLOC structure, with each level being represented with a separate LOC definition, with its own proper identifier, and each ("binary") level being related to the learning outcome or competence it is a level of. (See InLOC treatment of levels.) If this "binary" level LOC definition is used in just one place, giving its identifier allows all the other relevant information to be found.

However, this may well not be the case. Where it is not, there may be scope for a double reference. If the same LOC identifier is used as a level in more than one place, it may be necessary to reference something else other than simply the identifier of the level. Another reason to require two identifiers is if a level from one source is being superimposed on a competence from another source.

Another persuasive reason to have the "rankable" competence and the appropriate level of that competence represented separately is to do with facilitating searching for level information. For example, there may be a requirement to search through, say, a course catalogue, to find out if there are any references to a level of a particular competence. If only the level is represented, the search in general has to check for every possible level of that competence. If the rankable competence is also represented, it is relatively easy to find references to any level of that competence.

For examples, let us imagine the XML binding of a specification that has a competence element, and within that a level element. (This is a generic idea, and does not reproduce any particular known specification.)

<competence>
        <description>(the description of the competence)</description>
        <level>(the level of the competence)</level>
        <!-- other information about the competence -->
</competence>

This kind of representation could be useful, for instance: for a specification describing individual levels of attainment; or for the person specification for a job opportunity. Because the level element is separate, it can be used to give a defined level – perhaps from a level framework like the EQF – to any learning outcome or competence that can be described, whether or not it is represented in a format such as InLOC.

If the information to refer to did exist in InLOC form, this is how one might adapt the XML above to reference it effectively.

<competence locref="http://example.eu/loc/def/1234">
        <description>(the description of the competence)</description>
        <level locref="http://example.eu/loc/def/2345" number="2">
        (EITHER something like: "Second level"
        OR words describing that specific level)
        </level>
        <!-- other information about the competence -->
</competence>

Note that the basic idea from the earlier example has been reused here, for referring to the competence that this is referring to a level of. The description of the competence is unchanged.

The level element firstly has a "locref" URI attribute added, in the same form as the competence element, but with a different URI — this time, the URI of the level ("binary") LOC definition: "http://example.eu/loc/def/2345". Then, in addition, a number attribute is added, to represent the fully machine-processable part of the level. This frees the text of the level element either to be a common representation of the level designator itself, like "Second level", or to be a description of the level criteria, and not to be constrained to being simply an uninformative or unfamiliar number. On the other hand, it could also be a simple number, in cases where that was most helpful: the text used in this "text node" would be whatever makes most sense to the users of the specific interface.

If the host specification had a multilingual capacity, it might be that description and level elements could be repeated in different languages.

<competence>
        <description xml:lang="en">(a few words in English)</description>
        <description xml:lang="fr">(quelques mots en français)</description>
        <level xml:lang="en">(the level)</level>
        <level xml:lang="fr">(le niveau)</level>
        <!-- other information about the competence -->
</competence>

If this is the case, all the attributes would need to be attached to the competence element.

<competence defref="http://example.eu/loc/def/1234"
              levelref="http://example.eu/loc/def/2345" number="2">
        <description xml:lang="en">(a few words in English)</description>
        <description xml:lang="fr">(quelques mots en français)</description>
        <level xml:lang="en">(the level)</level>
        <level xml:lang="fr">(le niveau)</level>
        <!-- other information about the competence -->
</competence>

Note that now new names for the attributes are needed, to distinguish the URIs of the competence and the level.

In some specifications, there is an XML type that allows various language strings within the elements. In this case, the example could end up looking more like this.

<competence locref="http://example.eu/loc/def/1234">
        <description>
                <string xml:lang="en">(a few words in English)</string>
                <string xml:lang="fr">(quelques mots en français)</string>
        </description>
        <level locref="http://example.eu/loc/def/2345" number="2">
                <string xml:lang="en">(the level)</string>
                <string xml:lang="fr">(le niveau)</string>
        </level>
        <!-- other information about the competence -->
</competence>

This pattern of multilingual sub-elements is called "langstring" in some specifications.

This pattern of using identifiers both for the "rankable" LOC concept the "binary" level LOC will, for future reference, be called "twin-URI-LOC-level", or if a number is included to refer to or compare with the InLOC number attribute, then it will be called "twin-URI-LOC-level-number".

Referring to a LOC definition in a non-standard context or structure

Some LOC definitions may appear in many contexts. Typically, skills known as "employability skills" have this nature, as they are needed in many contexts for many roles and jobs. Authorities defining frameworks of skill or competence may reuse these without being entirely clear about their actual context. If this is not important, referring to such a skill is still possible using the identifier of a LOC definition alone, as in the above examples. But if the context affects the exact meaning of the learning outcome or competence, then it may be that to be completely clear, the context LOC structure may need to be given as well.

In this case, perhaps two identifiers will be needed to refer clearly and unambiguously to InLOC information:

  1. the id of the LOC definition
  2. the id of the LOC structure for the context referred to.

The illustration here will use a pattern that occurred in IEEE LOM, an influential legacy specification used in learning technology: a two-part "catalog" and "entry". Several versions of this may be found in other specifications. A way of effectively circumventing this two-part scheme, using "URI" as the catalog value, has been discussed for Dublin Core [DCMI]. MedBiquitous use their own variant of LOM, and within their Competency Framework standard they have it both ways:

The following example shows an identifier for a competency definition that uses a URI cataloging scheme.

<Identifier>
        <Catalog>URI</Catalog>
        <Entry>http://www.medschool.edu/competencies/kp87t</Entry>
</Identifier>

The next example shows an identifier for a competency definition that uses a local cataloging scheme. Note that organizations may include a catalog other than a URI for use within local systems as long as a URI identifier is present.

<Identifier>
        <Catalog>Medschool University</Catalog>
        <Entry>2005.10.87</Entry>
</Identifier>

The first version given by MedBiquitous here is in effect the same as referring to a single, well-defined concept, as discussed earlier above. The second version could be adapted for referring to a LOC definition in a non-standard LOC structure. Imagining that "Medschool University" publishes a LOC structure using InLOC, "Clinischool" could reuse the Medschool definition in their MedBiquitous framework:

<Identifier>
        <Catalog>http://www.clinischool.edu/competencies</Catalog>
        <Entry>http://www.medschool.edu/competencies/kp87t</Entry>
</Identifier>

This would be an effective way of identifying a LOC definition that was originally identified by Medschool as "http://www.medschool.edu/competencies/kp87t", perhaps within their LOC structure "http://www.medschool.edu/competencies" – and reused by Clinischool unchanged in their own framework with identifier "http://www.clinischool.edu/competencies", using the same URI to identify the Medschool LOC definition.

Whether this will happen in practice remains to be seen. If Clinischool used InLOC, it could reproduce the Medschool LOC definitions with new identifiers in the Clinischool domain, and the Clinischool LOC structure could contain LOC associations stating that "http://www.clinischool.edu/competencies/kp87t" exactMatch "http://www.medschool.edu/competencies/kp87t"

For future reference, this pattern of reference will be called "twin-URI-structure-definition".

For the purpose of referring to InLOC information, it does not help if "catalog" and "entry" as used as two components of just one actual identifier. That situation would be the same as having just one identifier.

Summary of patterns of reference to InLOC information

The above four patterns are the ones that make most sense. But the actual pattern of reference selected will depend on two factors, neither of which are predictable in general:

  1. the features of the host specification
  2. the nature of the information referred to.

Therefore, here is given a summary of all the reasonably possible patterns, with their constituent parts.

  1. single-URI-LOC (explained above)
    • the URI of the LOC structure or LOC definition
  2. twin-URI-LOC-level (explained above)
    • the URI of the LOC structure or rankable LOC definition
    • the URI of the binary LOC definition of the level
  3. twin-URI-LOC-level-number (explained above)
    • the URI of the LOC structure or rankable LOC definition
    • the URI of the binary LOC definition of the level
    • the level number, referenced against the level numbers given in the LOC structure
  4. twin-URI-structure-definition (explained above)
    • the URI of the LOC structure
    • the URI of the LOC definition
  5. single-URI-LOC-number: the level LOC definition URI may be inferrable from the structure and the number
    • the URI of the LOC structure or rankable LOC definition
    • the level number, referenced against the level numbers specified in the LOC structure
  6. single-URI-level-number: the LOC structure or rankable LOC definition URI may be inferrable from the level definition
    • the URI of the binary LOC level definition
    • the level number, either duplicating or giving more precision to the number associated with the level definition

Integrating InLOC with European Learner Mobility specifications

In the previous section Referencing InLOC information has been explained and discussed. This section illustrates these techniques through the examples of MLO [MLO] and EuroLMAI [EuroLMAI], referring in particular to the ELMO project [ELMO].

MLO

MLO is EN 15982, the European Standard for Metadata for Learning Opportunities (Advertising).

MLO has an "objective" property of a learning opportunity (e.g. a course), which is intended to represent the learning objectives or learning outcomes of that course. However, the property is not defined with any internal structure, and has been thought of simply as a text field, in which the learning opportunity provider could state, in plain language, the intended learning outcomes of the course. However, that is not reliable or accurate in terms of automatic matching of learning outcomes.

MLO also specifies a "prerequisite" property, which could also refer to learning outcomes that are necessary before taking a course, though it may in practice be used more often to indicate prerequisite courses or qualifications.

The main use of MLO is expected to be in conjunction with the ELMO project, so more detail is discussed below under the heading of ELMO.

EuroLMAI and the Europass Diploma Supplement

EuroLMAI is EN 15981, the European Standard for European Learner Mobility Achievement Information. In the same European Standard, there is a specification of the information model for the Europass Diploma Supplement, to provide the basis for any implementation.

EuroLMAI contains many MLO elements. EuroLMAI also represents results for assessments on these learning outcomes, and possibly also evidence that supports that assessment. This is shown in this diagram taken from the EuroLMAI project output on intended learning outcomes

As with MLO, the main implementation of EuroLMAI in Europe is expected to follow the outcomes of the ELMO Project, so the detail is discussed here below together with ELMO.

Integrating InLOC with ELMO

The CEN WS-LT [ELMO] work aims to provide a working specification and binding for the implementation of MLO and EuroLMAI.

Integrating with ELMO is not envisaged as including InLOC-formatted XML, but rather as specifying the use of some existing ELMO elements, and extending ELMO to include a few other XML nodes that are needed for the best effective reference to InLOC information.

Here below is a brief introduction to how InLOC information may be referred to from ELMO. The full and technical details relating InLOC to ELMO are covered separately in InLOC's ELMO Application Profile.

The ELMO result element

ELMO preserves the EuroLMAI result property of the MLO learningOpportunityInstance as a sub-element. Drafts in 2012 proposed the optional addition of a scheme attribute for result, which would otherwise be a simple text element.

The 2012 ELMO proposals give an opportunity to use the "single-URI-LOC" pattern of reference, using ELMO's scheme attribute to hold the URI of the LOC definition that represents the learning outcome or competence associated with that result. The actual result is held in the text node of the result, and could be numeric or descriptive.

If the result has a numeric representation, it may correspond to the "number" property in InLOC. InLOC therefore proposes to include number as an extra optional attribute of ELMO's result, in addition to the text node of the result element, which may instead may hold the name of a result category, as an alternative to the number itself. This would help the result to be processed most easily. The "number" may correspond to one explicitly defined in an InLOC LOC structure, or it may be a value understood in comparison to values defined in the LOC structure.

If this proposed extra number attribute is used, the pattern of reference depends on what is used as ELMO's scheme attribute.

In a fully-defined LOC structure, either would work. But if the resultDistribution element below is used, the former is recommended.

For more details on the patterns of referencing, see the previous section, "Referencing InLOC information".

The ELMO resultDistribution element

The ELMO resultDistribution element was newly formulated in November 2012, to help in the interpretation of a result by giving the numbers of people in different result categories. It is, like result, a sub-element of learningOpportunityInstance. It has a multiple category sub-element, which has attributes: label, standing for the result category; and count, holding the number of people achieving that category of result, drawn from the same set as for the other categories.

The relevant InLOC level LOC definition could be linked to from the category element. This needs an extra attribute of the category to be introduced, and InLOC proposes that this attribute is called locref. The number attribute may not be needed, as suggested above for result, but if it is present, it should correspond to the number given in the LOC structure where those levels are defined.

If the resultDistribution is used, each category scheme corresponds to one "binary" LOC definition. If this is used in conjuntion with the result (as above), the resultant pattern of reference is effectively "twin-URI-LOC-level-number". It is not completely straightforward, but it does fit into the ELMO specification reasonably smoothly.

Referring to the learning outcomes of a learning opportunity

As at the time of writing, ELMO only has the MLO objectives property representing learning outcome information. Relatedly, the British Standard 8581 – the version of XCRI that is harmonised with MLO – has an extra property, called learningOutcome. This learningOutcome may be a property of either of the XCRI course or presentation elements, which are the XCRI equivalents of learningOpportunitySpecification and learningOpportunityInstance respectively. Using the learningOutcome element in this way is an example of the "single-URI-LOC" pattern of referencing InLOC. A LOC definition for each intended learning outcome could be linked to from each learningOutcome element, or a single LOC structure could be linked to, giving a set of intended learning outcomes.

As can be seen in the diagram above, it is envisaged that the learningOutcome would normally be a sub-element of learningOpportunitySpecification rather than learningOpportunityInstance.

Alternative for referring to LOC structures

It may seem odd to have a structure of learning outcomes referred to through an element called "learningOutcome" in the singular. The alternative would be to have a further such element, restricted to just one occurrence for any learningOpportunityInstance or learningOpportunitySpecification, which would mean only one overall for a Diploma Supplement document.

Which solution is adopted – reuse of learningOutcome or defining a new element – should depend on the preferences of ELMO stakeholders.

Integration with the Europass CV and Language Passport

The Europass CV and Language Passport exist to let anyone produce a standard CV, including notes about their skills and competences, under several fixed headings. An opportunity exists to make reference to InLOC information for each of the skills listed.

The present specification for the Europass CV has structured representations for languages (as in the Language Passport) and driving. The representations of general skills are essentially just text, and fall under the headings:

As Europass defines only one piece of text for each of these skills areas, they are not suitable as they stand for reference to InLOC LOC definitions, because typically a CV owner may want to include several distinct skills under some of these headings. Integrating with InLOC requires distinct skills to be represented separately, even if they may still be grouped in the five categories given by Europass. Each separate skill then needs to be given an attribute to hold the URI of the InLOC LOC definition referred to.

Also needed for CVs is information covering the result or level of attainment in any particular skill, for skill definitions that are "rankable" rather than "binary". Europass has provision for an element called ProficiencyLevel, but that is disabled for the general skills listed above. For InLOC, we therefore need to re-enable this ProficiencyLevel element, and allow it to link to the InLOC LOC definition that defines the particular level attained. For further detail, it makes sense to include an attribute for the level number, as in the InLOC attribute "number".

The full pattern for referring to a skill in a suitably modified Europass specification would then be "twin-URI-LOC-level-number".

The Europass CV and Language Passport have specifications including XSDs, and version 3.0 of the XSD was under development at the time of writing. As InLOC is only likely to be implemented for future versions, an application profile of this version 3.0 XSD (rather than of previous versions) has been created to satisfy the requirements noted here. Full technical details are presented in the Europass CV and LP Application Profile.

The Europass Certificate Supplement

The Europass Certificate Supplement (ECS) has not had any suitable XML binding that has been seriously used. In any case, the current understanding is that the ECS will be changed soon in the future, and possibly merged with the Diploma Supplement. The best approach to covering the integration of the ECS with InLOC is to look at the essential features of the ECS, and consider how these are likely to be handled in terms of the reference patterns of the previous section.

Name of the Certificate and related LOC definition

The name of a vocational certificate often corresponds to the concept of an occupational role, which a person can perform competently or not. Therefore, in InLOC terms, one may want a certificate to refer to the LOC definition of that concept.

If there is a larger LOC structure that includes the overall certificate competence concept as a LOC definition, then the overall competence concept may be represented as a LOC definition within that LOC structure. The ECS would refer to that overall competence concept. On the other hand, if there is no such larger structure, for InLOC purposes, the competences referred to by the ECS would need to be represented as a structure. The ECS overall reference might be either to that structure, or to the top definition within the structure.

Profile of skills and competences

This is section 3 of the ECS, and it is the most relevant section to InLOC. The official guidelines for the ECS state:

This box gives a concise description of the essential competences gained at the end of training.
List the skills and competences acquired by the holder of the certificate. This list should start as
follows:
 ‘A typical holder of the certificate is able to:’
and should include a list of about 5 to 15 items using action verbs to describe competences

For integration with InLOC, each of these list items should reference a LOC definition in an InLOC structure. It should be possible to adapt any suitably structured representation of section 3 in this way, following the pattern "single-URI-LOC".

Combination of overall and section 3 references

If all the items on the section 3 list come from the same structure that also contains a suitable overall LOC definition corresponding to the overall ECS, then simply using the "single-URI-LOC" pattern should be adequate. If, in contrast, the section 3 items refer to LOC definitions from a variety of source structures, it would make sense for the ECS owner to define a purpose-build LOC structure for that ECS, which is referred to by the overall ECS. This second option would follow the pattern "twin-URI-structure-definition".

Illustration from the eCOTOOL project

The eCOTOOL project produced interesting proposals for representing the Europass CS, though they have not yet had any adoption in practice. A separately annexed page, InLOC and the Europass CS, illustrates


List of references

[Atom] Atom Syndication Format (text, html)

[BS_8581] BS 8581:2012 "Exchanging course related information"

[Cedefop] "The shift to learning outcomes: Policies and practices in Europe" Retrieved 2013-01-10 from http://www.cedefop.europa.eu/EN/publications/12900.aspx

[CEFR] the European Common European Framework of Reference for Languages (informative website; InLOC page)

[CWA_16077] CWA 16077:2010 "Educational Credit Information Model". Available either at DIN or from CEN by FTP

[DCMI] DCMI Metadata Terms

[e-CF] European e-Competence Framework (informative website; InLOC page)

[eCOTOOL] The eCOTOOL project — e-competences tools (informative website)

[ECS] The Europass Certificate Supplement. (informative website)

[ECTS] ECTS users guide (informative website)

[ECV] Europass Curriculum Vitae (informative website)

[ELMO] ELMO project – how to make a difference with standards like MLO-AD, EuroLMAI, a.o. (project web site)

[ELP] Europass Language Passport (informative website)

[ENQA15] Learning outcomes: Common framework – different approaches to evaluation learning outcomes in the Nordic countries. 2008. Retrieved 2013-01-10 from http://www.enqa.eu/files/NOQA%20report_occasional%20papers%2015.pdf

[EQF] The European Qualifications Framework (informative website)

[ESCO] European Skills/Competences, qualifications and Occupations (informative article; InLOC page)

[EuroLMAI] EN 15981:2011 "European Learner Mobility — Achievement Information (EuroLMAI)"

[Europass] "Five documents to make your skills and qualifications clearly and easily understood in Europe" (informative website)

[LS1970] Lawrence Stenhouse, "Some Limitations of the Use of Objectives in Curriculum Research and Planning". Paedagogica Europaea, Vol. 6, pp. 73-83, 1970.

[MLO] EN 15982:2011 "Metadata for Learning Opportunities (MLO) — Advertising" (InLOC page)

[OFQUAL] Ofqual glossary. Material archived 2011-07-18 and retrieved 2013-01-10 from The National Archives

[SKOS] Simple Knowledge Organization System SKOS reference

[UKNOS] UK National Occupational Standards (informative website; InLOC page)

[VRDF] the UK Vitae Researcher Development Framework (informative website; InLOC page )

Further reading

On Learning outcomes

On Work competences