Integrating InLOC

(Part of the InLOC Guidelines)

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.

  • If the scheme attribute URI holds the "rankable" LOC definition, the pattern of reference is "single-URI-LOC-number".
  • If the scheme attribute URI holds the "binary" LOC definition, the pattern of reference is "single-URI-level-number".

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:

  • Communication
  • Organisational
  • Job-related
  • Computer
  • Other

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 AP.

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

  • how the eCOTOOL proposal for representing the Europass CS is fully adequate to reference InLOC information, and
  • an InLOC structure that could be referred to by a Europass CS Section 3.

This concludes the InLOC Guidelines