(Part of the InLOC Guidelines)

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:

  • An individual's CV (e.g. Europass CV) or e-portfolio can be precise when claiming to have achieved specific learning outcomes or attained competence.
  • A course of education or training, or other learning opportunity, can clearly and explicitly set out what its intended learning outcomes are. This is similar to the current Europass Certificate Supplement, which provides a way of setting out a group of "skills and competences" learning outcomes that may be shared between more than one vocational course.
  • Official documentation, including Europass Diploma Supplements and other transcripts, can refer clearly to the learning outcomes, including skills and competences, when giving assessment results of individual learners. This may include the levels of knowledge, skill or competence they have been assessed as attaining.

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 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> (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:


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:

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

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="">(the description of the learning outcome)</learning_outcome>

This has attractive consequences:

  • legacy data would be unaffected
  • the information intended for automatic processing would be kept as attributes, not as text nodes.

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

        <description>(the description of the competence)</description>
        <level>(the level of the competence)</level>
        <!-- other information about the 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="">
        <description>(the description of the competence)</description>
        <level locref="" number="2">
        (EITHER something like: "Second level"
        OR words describing that specific level)
        <!-- other information about the 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: "". 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.

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

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

<competence defref="" levelref="" 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 -->

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="">
                <string xml:lang="en">(a few words in English)</string>
                <string xml:lang="fr">(quelques mots en français)</string>
        <level locref="" number="2">
                <string xml:lang="en">(the level)</string>
                <string xml:lang="fr">(le niveau)</string>
        <!-- other information about the 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 occured 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. 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.


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.

        <Catalog>Medschool University</Catalog>

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:


This would be an effective way of identifying a LOC definition that was originally identified by Medschool as "", perhaps within their LOC structure "" – and reused by Clinischool unchanged in their own framework with identifier "", 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 "" exactMatch ""

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

Next: Integrating InLOC with other ELM specifications