Today is the final day of the InLOC project — a European ICT Standardization Work Programme project I have been leading since November 2011. So a good day for an initial review and reflection. I blogged some previous thoughts on InLOC in November 2012 and February this year, and these thoughts are based on some aspects of the project’s final report.

InLOC — Integrating Learning Outcomes and Competences — is all about devising a good way of representing and communicating structures of learning outcomes, competence, skills, competencies, etc. that can be defined by framework owners, and used by many kinds of ICT tools, including those supporting: specifying learning outcomes of courses; claiming skills and competences in portfolios; recruitment and specifying job requirements; learning objectives relevant to resources; and possibly many more.

Project outcomes

We have produced three CEN Workshop Agreements, two formally approved and awaiting publication (Information Model, and Guidelines), and one where a workshop vote will be concluded in the coming days (Application Profile: we don’t expect any problems). Further work includes technical bindings, and two demo prototypes kindly contributed.

The Information Model

There are a number of key advances made in the InLOC Information Model, with respect to other and previous work. “LOC” here stands for “Learning Outcome or Competence”.

1. A clear distinction is made between a LOCdefinition and a LOCstructure.
   • A LOCdefinition is similar in some ways to IMS RDCEO or IEEE RCD. Any idea of structure is kept separate from this, so that the definition can potentially be reused in different structures. Thus, a LOC definition is like the expression of just one concept about learning outcome, competence, etc.
   • A LOCstructure is the information about the structure and compound properties, but this is kept separate from any particular single definition. While it is recognised that in practice the two are often mixed, the InLOC specification separates them for clarity and for effective implementation.
2. A clear distinction is made between defining levels with level definitions, and attributing levels (from another scheme) to definitions. This is explained in InLOC treatment of levels. This is necessary for logical clarity, and therefore at some point for applications. A decimal number is introduced as a key part of the model, to allow level information to be automatically processed.
3. A single structural form, the LOCassociation, is used both to represent relationships between LOC structures and definitions, and to represent several different kinds of compound properties, each with more than one part. This results in structures that are easier to process, with fewer distinct information model components. It also is responsible for the relative ease of representing InLOC naturally in RDF, with minor changes to the model.

Within InLOC in general, a recurrent pattern is of one identifier together with a set of multilingual titles or labels. This is a common pattern elsewhere, and ensures that InLOC representations can naturally work multilingually.

There is a diagrammatic illustration of the Information Model structure as a UML diagram, and many more illustrative diagrams in the Guidelines section on InLOC explained through example.

The Guidelines

The central feature of the Guidelines is a detailed examination of a cross-section of the European e-Competence Framework, given as a good example of the power and flexibility of InLOC in a case from real life. The e-CF is a useful example for InLOC as it identifies 5 levels of competence. The e-CF is analysed in the section on InLOC explained through example. In this section, there are more diagrams illustrating the Information Model and how it is applied in this case.

The e-CF is fully expressed here in InLOC XML format.

Application Profile of Europass CV and Language Passport

The most used Europass instrument is the Europass CV, and Cedefop have recently been revamping it. It is a kind of simple e-portfolio, and the challenge here is to allow it to refer effectively to InLOC structures, so that the end users — the people who have the skills and competences they want to show off — can refer directly to InLOC identifiers, and so have better hope of having them accurately recognised and found in relevant searches. For the Europass CV, the InLOC team have proposed a modification of their XML Schema, and it looks like several if not all of our proposals will be taken on by Cedefop, paving the way for the Europass CV being a leading example of the use of InLOC structures in practice.

Technical bindings

No information model is complete without suggestions for how to bind it to currently relevant technologies. The ones chosen by InLOC were:

• XML
• RDF
• JSON

We hope that they are reasonably clear and self-explanatory.

While the project found no great motivation for developing other bindings, I personally believe that it would be very valuable in the future to develop something with RDFa and schema.org.

Prototypes

We have been really lucky to have two initiatives filling in where the project was not funded to deliver. There is a Viewer-editors page on the project wiki with access details.

• A team from Eummena, led by one of the team, have produced an InLOC viewer/editor based on PHP and MySQL. Here is their login page.
• Henk Vos from Rapasso has produced a prototype using Python and Django. The interface starts here. The code is open source, GPL v3, available on GitHub.

Challenges

The main challenge in this project has been trying to generate interest and contributions from interested parties. It’s not that the topic isn’t important, just that, as usual, busy people need a pressing reason to engage with this kind of activity. This challenge is endemic to all “anticipatory” standardization work. Before either policy mandation or clear economic interest, it takes some spare effort and a clear vision before people are willing to engage.

I’m intending to write more about what this means for my own personal view of what standardization could best be, or perhaps “should” be.

Recommendations

It seems to me good practice to make some recommendations at the end of the project — after all, if one has been engaged in some good work, there should be some ways forward that are clearer at the end than at the beginning. The recommendations that the team agreed included:

• focusing on trying to get people to publish frameworks in InLOC, as this will in turn motivate tool builders;
• ensuring that when people are ready to adopt InLOC, they can find resources and expertise;
• persuading developers to make it easy for users to refer to definitions within InLOC structures;
• get other Workshop, and other European, projects to use InLOC where possible;
• work on APIs, and on automatic configuration of key domain terms within user interfaces.