Interim Guidelines

Skip to end of metadata
Go to start of metadata
(Thinking has moved on since this Interim draft – please now see the current Guidelines)

Guidelines for the application of the InLOC Information Model

Interim draft towards a CEN Workshop Agreement

By the InLOC team

2012-06-29

Foreword

This draft CWA was originally entitled “Guidelines for the Integration of Learning Outcomes and Competences into existing ELM specifications”. While that material is present in draft in this document, the project team considered it advisable to give the document a name more suited to its actual role. The accompanying Interim Information Model document is kept short and technical, so that all the guidance material can appear in this document.

These Interim Guidelines are also available as the submitted PDF: 20120629_InLOC_Guidelines.pdf.

Issues arising from further discussion and consultation on the Interim documents are recorded at Interim Issues.

Contents


An introduction to the InLOC Guidelines

The meaning of InLOC

The name "InLOC" stands for "Integrating Learning Outcomes and Competences". InLOC is building a unified way of representing both definitions of intended learning outcomes, as used in learning, education and training, and definitions 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 chapters 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 document.

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 chapter following, each of the stakeholder groups is addressed in turn, because the importance and relevance differs between different groups of people. But there is 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 chapter 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. The chapter explaining InLOC 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 chapter on 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 fully 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

The chapter on integrating InLOC finished these Guidelines, which will explain in more detail how the InLOC approach can be integrated effectively with Europass, with EuroLMAI (EN 15981), with MLO (EN 15982), and related processes.


NOTE for interim version

Please note that some of the sections of these Guidelines have not been fully drafted. This is because much of the detailed information, and its presentation, depend on feedback and comment that will be obtained from stakeholder contacts during the process of consultation on the interim information model.


The relevance of InLOC to different stakeholders

This chapter 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 is backed up by a very extensive and ongoing programme of stakeholder engagement. Much of the analysis of stakeholder needs is displayed through the Stakeholders pages on the project web site.

This is one of the areas where the full and proper expression of the motivational arguments will naturally have to wait until the team have received feedback from their many stakeholders about these interim proposals. This chapter will be tailored to present concisely the main considerations that are found in practice to motivate the various stakeholder groups.

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

  • skill or competence standards setting bodies
  • competence model and framework developers
  • curriculum developers and managers
  • assessment and accreditation bodies
  • recruitment and human resources (HR) systems managers
  • individuals seeking jobs or learning in educational institutions or the workplace
  • learning technology systems providers
  • recruitment and HR management systems providers
  • policy makers
  • participants in technical specifications and standards development

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.

  • In the UK, there are Sector Skills Councils overseen by the UKCES.
  • In Germany, BIBB plays a role in defining the content of vocational education and training.
  • In France, it is the French Ministry of Education that supervises the content of vocational qualifications.
  • C2i covers IT competencies in higher education.
  • The French Cigref maintain a reference point for job competencies for IT professionals "Information Systems roles in large companies" based now on the e-CF.
  • At a European level, Cedefop’s mission is to support development of European VET policies and contribute to their implementation.

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 curricula. 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 leading to more 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. Widely available InLOC formatted materials will 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 outside one organisation.

InLOC could also help human resources management in other ways:

  • Job Application
  • Employee performance management
  • Employee Personal Development Plan

InLOC will form the basis for future systems for building job profiles from existing InLOC structures. This needs extra work built on top of InLOC, but by writing such functionality into their requirements, managers will stimulate providers to implement them.

Individuals seeking jobs or learning 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, UK). 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.

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

  • It shifts focus from providers to users of education and training. By explaining what a learner is expected to know, understand or be able to do at the end of a learning process, individuals will be better able to see what is offered in a particular course and how this links with other courses and programmes. It is also an effort to increase transparency and strengthen accountability of qualifications – for the benefit of individual learners and employers.
  • It introduces a common language making it easier to address the barriers between different education and training sectors and systems. If lifelong (and lifewide) learning is to become a reality, there is an urgent need to see how learning acquired in one setting can be combined with learning acquired in another. In a situation where lifetime jobs have become exceptions and where moving between work and learning has become a significant factor in most people’s lives, learning outcomes may help to reduce barriers and build bridges.
  • It also provides an important tool for international cooperation, allowing us to focus on the profile and content of qualifications, rather than on the particularities of the institutions delivering them.” CEDEFOP, The shift to learning outcomes: Policies and practices in Europe

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


References


Background to InLOC – competence in the world of employment

This chapter will give a brief summary of the usage of the terms "competence" in the area of work, and an explanation of what is meant within InLOC.

A few examples will be given, to try to ensure:

  1. that the explanation is rooted in real practice
  2. that readers understand what is meant by competence in the context of InLOC.

One of the aims of this chapter will be to point out the similarities with learning outcomes.

Job Application

Job application is a classical use case, based on the need to match a 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.


References

Simon, et al. (2010) A Discussion on Competency Management Systems from a Design Theory Perspective
http://www.springerlink.com/content/96221486k43p7461/fulltext.pdf?MUD=MP

LinkedIn http://www.linkedin.com/


An explanation of the InLOC Information Model

The aim of this chapter is to explain the InLOC information model progressively, in a way that communicates effectively to the intended audience.

Throughout this chapter, 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.

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

This chapter's example of a LOCstructure is the European e-Competence Framework e-CF itself as a whole.

Unable to render embedded object: File (e-CF.jpg) not found.
Figure 1

The above diagram illustrates the view that the e-CF is the containing structure, including 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.

While resembling other such frameworks in some ways, this structure is in no way standard. InLOC makes no attempt to standardise such dimensions. Instead, InLOC 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 can be gathered and presented. This can be at any level of generality. So what, in the e-CF, can be regarded as a LOCdefinition?

  • InLOC regards the e-CF areas themselves as LOCdefinitions. For example, individuals could be asked about their abilities in the area of planning ICT systems. Answers might well be generally descriptive, listing particular competences.
  • The e-CF e-Competences are regarded as LOCdefinitions. Taking one example, A2, 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 A2 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 knowledge examples are given with lead-in text: "Knows / Aware of / Familiar with", and K2 for example is "how to compare and interpret management data". It is obviously possible to make some kind of assessment of an individuals level of knowledge of this.
    • The skills examples are given with lead-in text: "Able to", and S3 is "negotiate realistic service level targets". Here as well, it is obviously possible to assess individual ability on this.

Thus, in every "dimension" of the e-CF there are what InLOC terms LOCdefinitions. They may have a title, or a description, or both. In e-CF dimension 1, the area has only a title; in dimension 2, the main e-Competence has both title and description; in dimensions 3 and 4 there is only a description, but no title.

On the other hand, it makes little sense to try to assess someone on their "e-Competence Framework". The framework is a structural container, and it is the included LOCs that are assessable, not the framework.

To summarise: 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 there is a structure that contains LOCdefinitions, InLOC instead terms it a "LOCstructure". The e-CF is a LOCstructure.

The InLOC model so far is as simple as it can be. There are LOCstructures and there are LOCdefinitions, and the structures contain the definitions. All of the figures below use the singular, but they are intended to include the plural where appropriate. In this case, one LOCstructure can contain any number of LOCdefinitions.

Unable to render embedded object: File (2012-06-20_IM2_F2.jpg) not found.
Figure 2 shows just the two basic classes


The requirements for reusing LOCdefinitions

One of the motivations for InLOC is to facilitate reuse of LOCdefinitions. The more that they are reused, the more easily can information about an individual's abilities in one context be applied to another context.

In order best to facilitate reuse, it is important to separate out what is fundamental to a definition, which is reused, and what is not fundamental, which may be included or may be left out. The next section focuses on what is fundamental to a LOCdefinition.

The nature of a LOCdefinition

There have been several specifications that have tackled the issue of representing what are called here LOCdefinitions. In learning technology, perhaps the two best known are the IMS Reusable Definition of Competency or Educational Objective (RDCEO), and its generalisation by IEEE to the Reusable Competency Definition (RCD). These and other specifications have made little or no attempt to represent structures or frameworks.

Though they differ in detail, this type of specification tends to agree on what is fundamental to a definition of a LOC 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;
  • identifier, to allow 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 terms as well.

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

  • rights

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

All of these properties can be seen as fundamental either to the meaning of a LOCdefinition, or to metadata about it that is essential for being held in an electronic system, shared, referred to, and potentially reused 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, and therefore in InLOC they are termed Simple atomic properties.

Unable to render embedded object: File (2012-06-20_IM2_F3.jpg) not found.
Figure 3 adds the most essential of the simple atomic properties to Figure 2.

The e-CF example

As already introduced above, all of the 4 e-CF dimensions comprise LOCdefinitions, and titles and descriptions are used in various ways.

Identifiers in the e-CF are only internal. While it is easy within the document to understand that "A2" refers to the e-Competence titled "Service Level Management", this is not enough for unambiguous reference from outside the framework.

Language is implicit rather than explicit in the e-CF. Several translations have been made of the framework document as a whole.

There are no obvious explicit rights statements given for the e-CF. This is quite different from, say, the UK-originated Skills Framework for the Information Age (SFIA), where the intellectual property rights are clearly circumscribed.


Compound properties of LOCs

The other very common aspect of metadata that has not yet been dealt with is information to do with, for example, authorship. There are four Dublin Core terms that refer to "agents" (people or organisations): "contributor", "creator", "publisher" and "rightsHolder". Being restricted to one literal string is not very useful for describing these agents. For example Atom has a three-part person structure, with name, e-mail and URI. Thus, a simple atomic property was not seen as adequate.

InLOC uses the term by to denote this group of properties. While terms like "authorship" do not cover all relationships with agents, all can be described using the word "by", e.g.: "created by ...", "contributed to by ...", "published by ...", "copyright held by ...", etc.

These compound properties tend to apply to a document, which would more often correspond to a LOCstructure than a LOCdefinition. But LOCdefinitions that are created with the LOCstructure will inherit these properties. The e-CF does specify who created and published the Framework itself (a LOCstructure) but does not give any specific information of this kind about the included LOCdefinitions. It also suggests a mapping from its 5 levels to the EQF's 8 levels.

Alongside this information about related agents, there are other items of information that are often associated with LOCdefinitions or LOCstructures, all of which need more than a simple atomic representation.

  • The topic or subject of a learning outcome is most usefully represented, not as a a single string, but as a term from a particular catalogue scheme or vocabulary. All library subject classification is done in this way.
  • For intended learning outcomes, the educational level is very often a useful piece of information. But a level number by itself means nothing: the level scheme must also be identified. While it is possible to concatenate the scheme and level into one string, this is only useful if there is a clear convention on how to separate them again, which means that is not actually useful to have only one field.
  • Intended learning outcomes may also be associated with credit values in some credit accumulation and transfer scheme, 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.
  • Beyond these properties that are of particular use for learning education and training, general classification also generally uses more than one field. For example, the Atom category structure has three parts: scheme, term, and label.

There is also the question of the logical position of these compound properties. The InLOC position is 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, the LOCproperty instances are regarded as belonging to the LOCstructure, not the LOCdefinition itself. This means that the subject LOCdefinition cannot be inferred from where the information is, which in turn means that each LOCproperty must specify its subject.

While these structures are not identical, close examination revealed that they all fit well into the same seven-part arrangement, which is InLOC's LOCproperty.

  • The LOCsubjectID is the identifier of the LOCstructure or LOCdefinition that is the subject of the LOCproperty.
  • The propertyType is one of the above: "topic", "credit", "level", "category", or "by". This in turn determines the semantics of the other parts.
  • The scheme identifier is recommended to be a URI identifying the scheme, or the relationship to the agent.
  • The scheme label holds a human-readable label for the previous item. Multiple labels may be given, each in a different language.
  • The particular identifier is recommended to be a URI identifying the particular property, category or agent.
  • The particular label holds a human-readable label for the previous item. Multiple labels may be given, each in a different language.
  • The number holds a decimal number. For credit, it is the defined credit value. For level, it is the agreed level number. For the other propertyTypes, it may represent an ordinal number governing the priority or display order.

None of these compound properties directly affect how an individual would be assessed against a definition of learning outcome or competence. It is therefore reasonable to treat them, not as fundamental components of a LOCdefinition or LOCstructure, but as ancillary properties that add extra useful information.

Unable to render embedded object: File (2012-06-20_IM2_F4.jpg) not found.
Figure 4 shows LOCproperty connected to LOCdefinition and LOCstructure


Relationships between LOCdefinitions and LOCstructures

Relationships typically within a framework

As can be seen in the example of the e-CF diagram in Figure 1 above, a central feature of any framework or similar structure is that it serves to relate LOCdefinitions. Typically, it details the component parts of broader LOCdefinitions in terms of narrower LOCdefinitions. This can be seen in the e-CF with the general area of planning IT systems ("PLAN") is shown as having 8 component parts, the e-Competences A1 to A8. Each of these "A" e-Competences represents a narrower concept than the area concept, with the normal taxonomic meaning of "narrower".

Each e-CF e-Competence is then related both to levels and to examples. While, in a sense, both of these relationships are to narrower concepts, the relationship is not quite the same as the previous example of narrower. In the case of the levels, anyone who was assessed as having attained a higher level would normally also be assessed as attaining any lower level of the same competence. In the case of the examples, there is no attempt to be comprehensive in the examples given. The fact that they are only examples implies that there will be other examples not mentioned, also examples of the same e-Competence. In contrast, using the more common version of the "narrower" relationship, the e-Competences A1 to A8 are intended to cover all the ground of the area "PLAN", not just to be examples; and none of the e-Competences A1 to A8 strictly implies any other one.

Components of a LOCrelation

To represent relations of these kinds, InLOC provides LOCrelation as a class of entity that holds the relation information. Relationship information in many specifications contains the three essential elements:

and InLOC adds two more components to these. No extra information should be needed about the subject and object of the relation, because their respective identifiers can be linked to all the rest of the information about them. However, the meaning of the relationship identifier may not be immediately clear, and furthermore, how the relationship is named in context may not be exactly the same as the standard relationship name. This is the reason for having

is vital to InLOC's increased scope compared with other approaches. It allows several things. First, and most importantly for InLOC, it provides a means for level numbers to be defined. This will be discussed in more detail below. Second, it provides the facility for ordering, for example, narrower components within a broader whole. Where numbers are used in structural relationships between LOCdefinitions, they are used definitively, to express the number that the structure or framework authors assign, related to a particular relation between LOCdefinitions.

Types of LOCrelation

The e-CF does not make the distinction between parts of LOCdefinitions that are mandatory, and parts that are optional. The distinction is however often made within curriculum structures. This will also be discussed further below. Including this distinction, we have a set of relationship types that cover the needs of relating LOCdefinitions within a structure:

  • narrower
    • hasExample
    • hasDefinedLevel
    • hasNecessaryPart
    • hasOptionalPart

and their inverses

  • broader
    • isExampleOf
    • isDefinedLevelOf
    • isNecessaryPartOf
    • isOptionalPartOf

The broader and narrower relationships themselves are the same as in SKOS, while the other ones can be seen as sub-relations (known in SKOS documentation as "subproperties") of skos:broader or skos:narrower.

Other types of relationships

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. Suitable relationships are already formalised within SKOS, as

  • skos:closeMatch
    • skos:exactMatch

Another relationship that frequently occurs in curriculum structure is connected to logical dependency. One learning outcome must often be attained before another one is intended. As there seems to be no established name for this, InLOC proposes simply

  • hasPreRequisite

and its inverse

  • isPreRequisiteOf.

The most general associative relationship is given in SKOS as

  • skos:related

No other types of relationship are currently specified in InLOC, though there is a natural extension point here allowing other relationship types that are not specified in InLOC.

No clear distinctions between groups of relationship type

The SKOS documentation implies a distinction between relationships within a concept scheme and relationships across different concept schemes. However, when information about LOC concepts is to be provided in many ways, it is hard to see any clear justification for this distinction. Electronically, a LOCdefinition may be presented by itself, or it may be presented in a set of any size. The InLOC position is therefore that both SKOS "semantic relations" and SKOS "mapping properties" can be applied between LOC concepts represented in the same framework, or represented in separate frameworks.

Unable to render embedded object: File (2012-06-20_IM2_F5.jpg) not found.
Figure 5: Adding LOCrelations to the picture. The sub-relationship types of broader and narrower are omitted.

Relationships within the e-CF

As indicated above, representing the e-CF in InLOC format suggests using the relationship "skos:narrower" between areas (Dimension 1) and e-Competences (Dimension 2); while using sub-relations "hasDefinedLevel" between an e-Competence and its own levels, and sub-relations "hasExample" between an e-Competence and its examples.


The nature of a LOCstructure or framework

The nature of a LOCstructure as a container for a set of LOCdefinitions, together with their interrelationships, has been covered above. As well as this, a LOCstructure can represent a published framework document, with its own information and properties that are not necessarily shared with the contained LOCdefinitions. This is the case with the e-CF, the example here.

As a document, a LOCstructure may have its own title and description. As the semantics of a LOCstructure are quite different from those of a LOCdefinition, the title and description are likely to be different in kind. Whereas a LOCdefinition is about a concept against which an individual can gather evidence and be assessed, a LOCstructure includes 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

  • publication date (dc:issued)
  • start and end dates of validity (the validity of the LOCstructure, not of any licence etc.)
  • version (distinguishing different versions of a LOCstructure with the same title)

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 one or more standard abbreviations. A reasonable 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 simple atomic "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. In order not to lose any of the extra information published in the Framework itself, a reasonable approach would be to represent a whole formatted document as furtherInformation.

As well as these Simple atomic properties, LOCstructures have other compound properties that are instances of LOCproperty, just as LOCdefinitions have, and this has been covered above.

The extra Simple atomic 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 Simple atomic properties for both structure and definition means that inheritance rules may be specified for all of those properties, and these inheritance rules can extend not only across broader/narrower relations between LOCdefinitions, but also to the inclusion relations between LOCdefinitions and LOCstructures. In the light of these considerations, InLOC adds these extra properties to both LOCstructure and LOCdefinition at the same time.

Unable to render embedded object: File (2012-06-20_IM2_F6.jpg) not found.
Figure 6: Adding extra simple atomic properties

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

Smaller LOC structures

Imagine that the e-CF, instead of being published as a single document, was published as a set of separate e-Competence documents. The situation would be quite similar to what happens in the 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 natural title or description of its own.


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 essential 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 essential 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 essential, then if you have the overall competence, you will have that part of the competence as well. 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 this

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.

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.


Modelling level definition

In the e-CF example, the LOCdefinition in Dimension 3 with the description "Influences and prepares the final Service Level Agreement (SLA) and accounts for the final content" is given as proficiency level 3 of the e-Competence A2, which has title "Service Level Management". It is perfectly possible in principle that the same LOCdefinition that is level 3 of A2 might be used as a different level in some other framework. There is nothing essentially "3" about that particular concept.

The most important fact to recognise is that this has a quite different logic to assigning a level to a LOCdefinition. The e-CF example here means that Level 3 of A2 is defined with that description. It is simply logical that something must be defined before it is applied precisely.

Concepts can also be defined by example, but in this case too, the definitive examples need to be chosen by the defining authority as truly representative, and distinguished from possible examples that are not such good examples of the concept.

Because the level number is not an inherent property of the LOCdefinition that describes the level criteria, InLOC instead places the defining level number as part of the LOCrelation. This is the main reason why a number is needed as one of the LOCrelation components.

So, following this example, when level 3 of e-CF A2 has been defined, it can then be claimed of other LOCdefinitions that they correspond to e-CF level 3. Any such claims make no difference to the definition of level 3 of A2.


The role of examples

In the e-CF, knowledge and skills are given, not as exhaustive, covering the whole range of the e-Competence, but only as examples, implying that there are other examples not listed that are parts of the same e-Competence. Used in this way, the examples can be seen as complementary to the main description of the e-Competence. In case there was any doubt about what the e-Competence covered, the examples make it clearer.

Examples can also be used as the main content of a definition. In such cases, different from the e-CF, there might be no description text, but instead only examples. The assumption on which this would be based may be that people possess, or do not yet possess, a competence that is manifest in various related ways. The learning process is such that if one example of the competence is mastered, the others are also likely to be mastered. In other words, there are some underlying ability that the person has, that is responsible for competence in the example ways.

Examples may also be useful in the definition of levels. While the general competence may be defined with a straightforward description, levels may be harder to describe definitively. Instead, examples of performance at that level can be given. These would not be criteria in the normal sense, but would guide an assessor on the kind of performance that is expected at that level.


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, there is a need 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 often 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 chapter is to review the features required in the treatment of learning outcome and competence information in learning, education, training, guidance, personal and professional development, recruitment and employment; and to explain how InLOC represents these features.

At this interim stage of the Guidelines, work on the Bindings has only just started, and so we cannot give guidance related to writing in XML or any other particular technology. Examples may be added for the final version, depending on the requirements of our stakeholders. The scope of this chapter is currently limited to explaining how to recognise features in existing materials, and how to think of these in InLOC terms.

For ease of understanding, this chapter will use the 2nd person, "you", for the person who owns LOC-related information that you are trying to put into InLOC format.

This explanation is a basic one, which deals with the most likely cases. Harder cases will be added where consultation with stakeholders ("you") shows that they would be useful.

To follow this chapter, you will need to be looking at documentation about your learning outcomes and/or competences.

Distinguishing structures from definitions

In the previous chapter, the distinction between structure and definitions was explained. To format your information following InLOC, the first thing you need to do is to clarify what your structures are and what your definitions are.

In principle, the difference is straightforward: if a single piece of text refers to one concept that is assessable, or for which you can gather evidence, it will be a LOC definition. Don't worry at this stage about how vague it is, even if it is only one word, that is also OK. Typically, you may have many different layers of LOC information, and they will nearly all be LOC definitions.

If a description starts talking about use in training or in professional development, it is likely that some thought has been given to selecting a set of LOC definitions for a particular purpose. This will be most obvious if it is a whole document. This will surely be a LOC structure. In fact, anything that contains a number of what you have already identified as LOC definitions will be a LOC structure.

Information directly about structures and definitions

You will next need to identify what information plays what role in the structures and definitions.

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.

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.

Unless your information is very strange, 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.

Abbreviation

Do you have a common abbreviation, probably only for LOC structures? If so, record it here.

Further information

If there is extra information in your documentation, that is not itself a LOC definition, or something about a LOC definition, then it might belong to the further information of your LOC structure. This is somewhere you can put anything you are not sure about.

Identifier

At some point you will now need to work out some unique identifiers for your LOC structure and LOC definitions. Your documentation may give you helpful clues. Make sure that the identifiers you use are unique across the whole of your documentation. You need not worry about making these into URIs at this point (particularly if you are not familiar with URLs and URIs!) You may be able to get help later with the URIs.

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.

Recording the structures and definitions in themselves

There is more information you could record about the LOC structures and definitions (see the chapter above, called Simple atomic properties) but the rest is probably less vital, and you can fill it in later.

Now you can write, in your chosen format, the basic information about the structures and definitions. Helpfully, it doesn't matter where you put them. You can have them all separately in a long list, or you can have them set out roughly as in your documentation. You can nest one inside another, or not, as makes most sense to you. The fact that they are nested doesn't mean anything apart from where you see them in your documentation. What does matter is the relations, which come next.

Relating your structures and definitions

First, you need to state that your structure contains every one of the definitions you have found, at all levels. It might also contain definitions from elsewhere, but that is an advanced case which won't be explained just here. Just putting your definitions inside your structure is not enough – you need to make a LOC relation for each one of these relations:

  • The LOCsubjectID is the identifier of your structure
  • The LOCobjectID is the identifier of each different LOC definition
  • the relationshipTypeID is "includes"
  • you don't need a label
  • you don't need a number, unless you particularly want to give a display order to all of these definitions within your structure.

Then, you need to say how the definitions relate to each other. If they are simply of the form "A consists of B, C and D" then you create relationships where

  • The LOCsubjectID is the identifier of A
  • The LOCobjectID is the identifier of B, C and D in turn
  • the relationshipTypeID is "narrower" (it point to the thing that is narrower; means "has narrower term" not "is narrower than")
  • you don't need a label
  • you don't need a number, unless you particularly want to give a display order.

For all of these relations, you can also record the inverse one if you like, if it helps in your documentation. However, any good system will understand that if A "narrower" B, then B "broader" A follows logically.

As you do this right the way through the definitions in your structure, you need to look out for several particular features.

Optionality

If you have compulsory/mandatory/necessary and optional components, then instead of "narrower" you need to use "hasNecessaryPart" or "hasOptionalPart" accordingly.

Examples

If some of your components are just examples, then instead of "narrower" you should use "hasExample" as the relationshipTypeID

Levels

This is a big one to understand properly, but necessary! The first thing to try to clarify is the difference between having a level property and defining a level. If you are just saying something e.g. corresponds to EQF level 6, that is a level property, because you are referring to someone else's level system. If you were in charge of the EQF, you would be defining level 6 to be what you say it is.

Look at it another way. Are you the authority who says what a level means? Then you are defining them. If not, you are just referring to them as properties.

If your structure defines levels, you will need to use another special relationship. You

  • The LOCsubjectID is the identifier of the LOC definition that has levels
  • The LOCobjectID is the identifier of the LOC definition that defines each level in turn
  • the relationshipTypeID is "hasDefinedLevel"
  • you don't need a label, though you may want to say
  • you do need a number, and you must give each level you are defining a decimal number (preferably a whole positive number) where the greater numbers mean higher levels of learning outcome or competence.

You know that you have levels when the different level definitions are quite similar, and where if you have a learning outcome or competence at a higher level it implies that you have the lower levels as well.

Properties

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 for some other system.

These are not as easy to get right. The ones that matter most will be explained in a later version of these guidelines.

What to leave out

As stated above, you can put any information you like into furtherInformation, but it will not have any recognisable structure unless you agree that with other people. You could, for instance, have an explanation of how you expect your learning outcome or competence to be assessed, or what evidence is relevant. You might state what learning resources or courses will help toward this LOC. But further information is the only place in InLOC where this can be placed, as the formal representation of those connections is expected to be elsewhere. 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 none of this has a separate proper place in InLOC.

Rather, you should take care that your LOC definitions, in particular, are not tied closely to information that is not relevant in another context that the LOC is relevant in.


Extending InLOC

Extending InLOC in this context means adding in extra information that is not specified by InLOC. There are two general approaches to doing this, with their own strengths and weaknesses.

Extending in ways envisaged by InLOC

There are three ways envisaged in InLOC for extension. It should be straightforward to extend in these ways, irrespective of the detailed technology used (the "binding") for representing InLOC information.

New relationships

InLOC specifies a particular set of relationships, that cover the envisaged needs for representing LOC information. Documentation is given on the project wiki page relationshipTypeID. This identifier is envisaged as a URI.

In whatever way this is implemented, in principle it is straightforward to use some other unspecified URI in its place.

New property types

The very particular way that InLOC specifies the propertyTypes of LOCproperty is in order to group together properties with related semantics and the same syntactic requirements, using a restricted vocabulary of types, similarly to the relationship types.

Here, too, it is easy in principle to invent and use some other property type, if there were a compound property that was not adequately covered by the property types specified by InLOC.

Vocabulary for the property type "by"

The propertyType by is intended to be used to represent information about authorship, or anything relating a structure or definition to agents (people or organisations). InLOC specifies just the 4 Dublin Core Terms that have "Agent" as the range class. It is easy to imagine other possible relationships for use with Agents that can be added here.

Extending in other ways

The practicality of extending InLOC in other ways (adding new attributes, new simple atomic properties, new classes...) depends more on the technology chosen for implementation (the "binding"). It is often desirable to be able to validate InLOC instances, and therefore the validation technology needs to be considered along with the extension.

This topic will be treated further in the Bindings work.


Referencing InLOC information

There will be many use cases where related information, represented in different ways, will reference learning outcomes or competencies – for example in resource metadata or in personal information.

It is recommended that authorities use URIs as identifiers for their LOC structures and LOC definitions, and this is what they should do particularly if there is any possible requirement for them to be referenced from elsewhere. Because of the rich possibilities of LOCstructure, all LOC definitions that could be wanted for reference can be given their own identifiers. This includes for example, LOC definitions used to define levels within a structure. The URI of an InLOC object should result in information being presented, in InLOC format, from which all the rest of the related information can be found, given an available Internet connection.

However, a URI by itself gives no human-readable information. If a live Internet connection can be relied upon, it is possible to fetch title, description, and all other information associated with the URI, and to display it at the user interface, after possible filtering on what is wanted. This is an ideal approach. The filtering can potentially be done either at the consumer end, or at the producer end. If it is to be done at the producer end, a suitable API needs to be devised, and this in turn will depend on the bindings used.

There are then two situations in which more information about LOC definitions may be wanted to be held within the related information, that is, held together with the information that refers to the original LOC definitions.

  1. If the Internet connection cannot be relied upon, any information that is to be displayed at the user interface needs to be kept locally.
  2. If some variant information about the LOC definition is to be displayed, other than the information held at the source, this needs to be created and stored locally.

1. Simple reference of a LOC definition through its URI

A simple way to refer to a LOCdefinition in other data is to just include the identifier of the LOC definition, assuming it is a URI. Several of the most technically advanced approaches adopt the "linked data" approach of having a single URI referring to a single concept. This relies on the assumption that all the concepts one wants to refer to have their own URIs.

Advantages: This is a simple approach and allows LOCs can be managed by the owning authority independently of the local resource metadata, hence any changes to definitions and structures have a definitive place for resolution. Many changes to information about LOCs would not require updating of legacy metadata. Obviously if a LOC was deprecated then some updating may be required.

Disadvantages: There is little, if any, LOC information available in a resource metadata instance. Hence a service providing information to users would need to obtain the information about the referenced LOCs prior to presentation.

For example, the ASN use "opaque" URIs throughout their documentation. This means that (practically) nothing can be deduced about the nature or content of the resource referred to, simply by looking at the URI. No more needs to be added, because the ASN is held in a database accessible over the Web, and if you can get one resource you can easily follow the links to the others. It does mean, however, that if you downloaded just some of the resources, and you tried to run the system offline, you might quickly run out of links, and it might be unclear what the missing things were, if you can simply see a URI that goes nowhere. In summary, this works fine for any set of resources that are all expected to be online when consulted.

IEEE LOM, an influential legacy specification used in learning technology, does not use single URIs for reference. This can be understood from the origins of LOM, Instead it uses a two-part system, "catalog" and "entry". MedBiquitous use their own variant of LOM, and within this they use the catalog value "URI" and the entry value of the URI itself. This is one way to get a single URI out of a two-part scheme.

Another way works if the LOCstructure is held as a single web page and the LOCdefinitions are locatable within that page. In this case, a single URI (a URL with fragment identifier in this case) has a natural break point, with the main URI locating the LOCstructure page, and the LOCdefinition URI locating the element in that page that contains the LOC definition.

2. Reproducing more than the identifier

There are in principle two sides to this. One is to use InLOC structures to reproduce more than the identifier; the other is to use structures that are native to the local information. Clearly, it is inappropriate for InLOC to specify how other information should be represented in an external format. It has already been stated that, if an Internet connection is available, a single URI by itself is sufficient reference, and from there all the rest of the information can be found.

For that reason, this section will focus on the potential use of InLOC structures themselves within externally defined formats. Depending on bindings, it should be possible to reproduce a LOCdefinition or LOCstructure instance within the external format. This will now be assumed to be true.

Reproducing some LOC definition information with the original URI

If the LOCdefinition has its original identifier, it would be assumed to be simply a private selection of relevant information, perhaps taken from the LOC definition itself, or added. In any case, it would be clear that the intention is not to change the definition in any way. The information reproduced would be that required for the local interface.

Reproducing a similar LOC definition

A similar LOCdefinition instance could be constructed with a new, local URI. This could be enclosed in a LOCstructure, together with a LOCrelation giving a closeMatch or exactMatch to the original. This would be a way to introduce a different wording, or a slight variant.

Creating a bespoke LOCstructure that includes the target LOCdefinition

A LOCstructure could be created with an entirely new top LOCdefinition, and the original LOCdefinition being a narrower concept. This would be a way to specify that the intended LOC concept was something in addition to the original.

3. Using more than one LOC reference is unnecessary and may cause difficulty

It is important to bear in mind that direct comparison is only easily possible with a single URI. If a different system has, for example, two URIs in a single unit, then it will have to define the rules of comparison itself.

This kind of extension is no business of InLOC either to define or to judge in any way.


Integrating InLOC with other European Learner Mobility specifications

The aim of this chapter is to cover the references to InLOC information from other specifications, instruments, and frameworks, so that InLOC can play a full part in the European Learner Mobility landscape. While previous chapters deal more generally with the representation of information about learning outcomes or competences, this chapter covers how to refer to InLOC definitions from other related information and documentation, as well as the benefits from using InLOC to represent information already contained in other European documents.

The rest of this chapter outlines the issues. The detailed explanation of technical aspects will be taken forward following further work on Bindings, with explorations of how to detail the connection between InLOC and the other specifications using the selected bindings.

MLO

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

Integration of InLOC into MLO is in principle very simple. MLO has an "objective" property of a learning opportunity (often, 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. Before the idea of InLOC became widely known, this property was 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.

For matching and comparison applications, by far the most reliable solution would be to use a single URI, just by itself. It is very clear whether a URI matches another URI. On the other hand, a URI is not, by itself, meaningful to an average reader. Thus, it is likely that MLO will need both some human-readable text, and some URIs pointing to InLOC-formatted information. Exactly how to do that will be explored in, or following, the Bindings work for InLOC.

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.

The integration of InLOC into EuroLMAI is quite straightforward, and is essentially the same as for MLO. The main difference is that rather than simply referencing the intended learning outcomes, or objectives, of the learning opportunity instances actually taken, EuroLMAI should help to represent results for assessments on these learning outcomes, and possibly also evidence that supports that assessment.

This should not need to involve InLOC as such. The objectives of the course should remain unchanged, even if more or less has actually been learned than was intended in the course design. And the results and evidence again should refer to InLOC definitions, but should not need to use InLOC structures themselves. What remains to be decided is what information from InLOC might be included in a EuroLMAI report, or a Europass Diploma Supplement, apart from the obviously necessary identifier of the learning outcome or competence.

Again, pending further work on the Bindings, this remains to be investigated further.

Using InLOC with the European e-Competence Framework

The e-CF aims to establish a Pan-European common language for ICT competences so that ICT vendor and user companies, as well as qualification and certification providers, have access to a shared reference point. The main applications that can be built on top of e-CF are related to workplace competence, profiling, assessment and measurement.

"European e-Competence Framework 2.0 – User Guidelines" (CWA Part II) identifies 4 primary purposes of the e-CF:

  1. The European e-CF describes competence and can be used in a variety of applications where consistency of competence language is required. These include job descriptions, role profiles, competence specifications and articulation of professional development needs.
  2. It identifies proficiency at 5 e-competence levels and can be used to provide detailed profiling where various competence combinations are involved. Career path association supports workforce development for roles with defined competences.
  3. Assessment of competence from a job role perspective enables targeted and efficient recruitment, contracting, sourcing and hiring.
  4. Measurement of competence gaps at the individual, team or organisational level enables short and long term planning by HR management or by individuals to assess and budget for education and training needs.

Additionally, the e-CF can play important role in certification development.

The e-CF focuses on identifying competences for ICT practitioners, and providing guidelines about how to use them in ICT businesses. However the e-CF does not provide ready made applications built on top of it. The European Commission encourages the use of e-CF widely, by organizing many events like e-Skills week.

Using the InLOC model for the representation of the e-CF in web-based systems can be an enabler and catalyst to popularise the e-CF. By providing a structured model it is more easily possible to implement IT applications on top of the e-CF. Despite the fact that the e-CF is well structured, it does not provide an explicit model. It means that potential solutions implemented on top of e-CF may be specific and will not benefit of any available libraries.

Additionally, InLOC provides following features from which e-CF applications could benefit:

  • External relationships – InLOC provides a means to handle external relationships to other frameworks and certifications. Additionally it is possible to enrich knowledge and skills examples by providing a reference to other stakeholder deliverables.
  • Extensions – InLOC provides a means to enrich the content with possible extensions. Such extensions will be needed when e-CF applications are required to be more specific.
  • Assessment and Evidence – InLOC provides means to provide explicit connection between competence and needed assessment/evidence.

The InLOC model has already been validated to fulfil the needs of e-CF. All the e-CF content can be modelled according to InLOC.

Summarizing, InLOC can make a significant contribution in making e-CF broadly available and can be an enabler in creating e-CF based applications.

Using InLOC with the Common European Framework of Reference for Languages

The CEFR aims to establish a Pan-European common language for language competences in order to help European citizen to study or work in other country.

The CEFR, as used in the Europass CV and Language Portfolio, does not provide a complete technical framework for implementation. The HR-XML Europass CV profile has been able to achieve one step forward while using reference to XML competency definitions hosted on the Cedefop website but these files are not linked together in a coherent framework. Representing the CEFR using the InLOC model will bring a welcome consistency.

Integrating InLOC with Europass CV personal competencies

In addition to CEFR competencies explained above, the Europass CV also brings a list of basic personal competencies which are not able yet to support more granularity, or a specific competency framework such as the e-CF for Computer skills. InLOC could help to bring such granularity support to Cedefop specifications and/or to the HR-XML application profile.


Feedback and consultation

This is the interim draft of the InLOC Guidelines. It will be extended and refined following:

  • feedback and comments from the whole of the interested community on this and the Information Model
  • further work on the Bindings by the team in consultation with standards stakeholders
  • lessons learned by developers who will implement the IM and the bindings in their systems
  • feedback and experience from the work to be done in Application Profiles.

It has been particularly challenging to know how useful are the new features proposed by InLOC, and the team would particularly like feedback in this area. One option under consideration would be to have a slightly more differentiated Information Model, as with this diagram:

Readers are invited to compare this with the main one in the Interim Information Model.

All are welcome to refer to the project web site, starting at http://wiki.teria.no/display/inloc/Home. Please give your comments to any team member (names to be found there) or, if you are permitted, leave comments on the pages themselves.

For this document, the team wishes to create the most useful Guidelines that can be produced in the time available. Among the questions we want to ask are:

  • How easy is it to understand the InLOC Model, along with the Guidelines?
  • Does the InLOC Model cover all the required related information?
  • If not, how might it best be extended?
  • Do the Guidelines include just the material that actually helps readers understand and use the Model?
  • What, if anything, would make it more likely that people will adopt, implement or recommend InLOC, as appropriate?

We hope that the final specification, together with final versions of guidelines, bindings and application profiles, will prove to be genuinely useful, and therefore widely adopted and implemented. They should all be available around the end of 2012.


Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.