InLOC explained through example

(part of the Guidelines)

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:

  • InLOC regards the e-CF areas themselves as LOCdefinitions. If individuals were asked about (for example) their abilities in the area of planning ICT systems, their answers might be generally descriptive, listing particular competences.
  • The e-CF e-Competences are regarded as LOCdefinitions. Taking the example here, A.2, individuals may be asked about their abilities in "Service Level Management". They might answer in terms of the extent of their experience and their proficiency level.
  • Each proficiency level of an e-CF e-Competence is regarded as a LOCdefinition in its own right. For example, Level 3 of e-Competence A.2 is given as "Influences and prepares the final Service Level Agreement (SLA) and accounts for the final content." Clearly, it is possible to assess individuals on whether they are able in practice to do this.
  • The knowledge and skill examples are also regarded as LOCdefinitions.
    • The e-CF gives the knowledge examples some lead-in text: "Knows/ Aware of/ Familiar with:". Taking K2 as an example – "how to compare and interpret management data" – it is clearly possible to make some kind of assessment of an individual's relevant knowledge.
    • Skills examples are also given with lead-in text: "Able to". It is clearly plausible to assess an individual's ability on any of these individual skills.

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.


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

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.

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.

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


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.

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


There are four Dublin Core 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 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.

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


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 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 could be the identifier of the e-Competence, and the 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".


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


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


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:

  • the Atom scheme is represented by the InLOC – InLOC adds the possibility of giving multilingual labels to the scheme;
  • the Atom term is represented by the InLOC object id;
  • the Atom label is represented by the InLOC object label – InLOC adds the possibility of the labels being multilingual.

From the e-CF documentation, 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.:

  • predictable v. unpredictable
  • structured v. unstructured
  • a five or more point scale for autonomy

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.

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.

  • The subject always represents the subject of the relationship or property.
  • The scheme gives the specific relationship, catalogue, scheme, or whatever it is that defines the specific relation or compound property. The scheme can also have human-readable labels. As always, multiple labels may be given, each in a different language.
  • The object gives the object of the relation, or the particular property, category or agent. Ideally, it has an identifier, in the form of an http URI, and it can also have human-readable labels.
  • The number, where used, holds a decimal number. For credit, it is the defined credit value. For level, it is the agreed level number. There is no other usage defined by InLOC.

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,

  • title and description are central to the meaning of any definition;
  • language, and dates created and modified are central metadata about the definition itself;
  • a unique identifier allows unambiguous reference to the definition.

These are so central to so many specifications that we rightly take them for granted. These are all Dublin Core metadata terms 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 is known as "EQF"; the European Credit Transfer and Accumulation System as "ECTS"; other qualifications and credit frameworks or systems are similarly widely known by their initials. For this reason, InLOC includes an

  • abbr (abbreviation)

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.

Next: How to follow InLOC