The CEN TC 353 was set up (about seven years ago) as the European Standardization Technical Committee (“TC”) responsible for “ICT for Learning Education and Training” (LET). At the end of the meeting I will be describing below, we recognised that the title has led some people to think it is a committee for standardising e-learning technology, which is far from the truth. I would describe its business as being, effectively, the standardization of the representation of information about LET, so that it can be used in (any kind of) ICT systems. We want the ICT systems we use for LET to be interoperable, and we want to avoid the problems that come from vendors all defining their own ways of storing and handling information, thus making it hard to migrate to alternative systems. Perhaps the clearest evidence of where TC 353 works comes from the two recent European Standards to our name. EN 15981, “EuroLMAI”, is about information about learner results from any kind of learning, specifically including the Diploma Supplement, and the UK HEAR, that document any higher education achievements. EN 15982, “MLO” (Metadata for Learning Opportunities) is the European equivalent of the UK’s XCRI, “eXchanging Course-Related Information”, mainly about the information used to advertise courses, which can be of any kind. Neither of these are linked to the mode of learning, technology enhanced or not; and indeed we have no EN standards about e-learning as such. So that’s straight, then, I trust …
At this CEN TC 353 meeting on 2014-04-08 there were delegates from the National Bodies of: Finland; France (2); Germany; Greece; Norway; Sweden (2); UK (me); and the TC 353 secretary. That’s not very many for an active CEN TC. Many of the people there have been working with CETIS people, including me, for several years. You could see us as the dedicated, committed few.
The main substance of the day’s discussion was about two proposed new work items (“NWIs”), one from France, one from Sweden, and the issues coming out of that. I attended the meeting as the sole delegate (with the high-sounding designation, “head of delegation”) from BSI, with a steer from colleagues that neither proposal was ready for acceptance. That, at least, was agreed by the meeting. But something much more significant appeared to happen, which seemed to me like a subtle shift in the identity of TC 353. This is entirely appropriate, given that the CEN Workshop on Learning Technologies (WS-LT), which was the older, less formal body, is now acccepted as defunct — this is because CEN are maintaining their hard line on process and IPR, which makes running an open CEN workshop effectively impossible.
No technical standardization committee that I know of is designed to manage pre-standardization activities. Floating new ideas, research, project work, comparing national initiatives, etc., need to be done before a proposal reaches a committee of this kind, because TC work, whether in CEN, or in our related ISO JTC1 SC36, tends to be revision of documents that are presented to the committee. It’s very difficult and time consuming to construct a standard from a shaky foundation, simply by requesting formal input and votes from national member bodies. And when a small team is set up to work under the constraints of a bygone era of confidentiality, in some cases it has proved insurmountably difficult to reach a good consensus.
Tore Hoel, a long-time champion of the WS-LT, admitted that it is now effectively defunct. I sadly agree, while appreciating all the good work it has done. So TC 353 has to explore a new role in the absence of what was its own Workshop, which used to do the background work and to suggest the areas of work that needed attention. Tore has recently blogged what he thinks should be the essential characteristics of a future platform for European open standards work, and I very much agree with him. He uses the Open Stand principles as a key reference.
So what could this new role be? The TC members are well connected in our field, and while they do not themselves do much IT systems implementation, they know those people, and are generally in touch with their views. The TC members also have a good overview of how the matters of interest to TC 353 relate to neighbouring issues and stakeholders. We believe that the TC is, collectively, in quite a good position to judge when it is worth working towards a new European Standard, which is after all their raison d’etre. We can’t see any other body that could perform this role as well, in this specific area.
As we were in France, the famous verse of Rouget de Lisle, the “Marseillaise” came to my mind. “Aux armes, citoyens, Formez vos bataillons!” the TC could be saying. What I really like, on reflection, about this aspect of the French national anthem is that it isn’t urging citizens to join some pre-arranged (e.g. royal) battalions, but to create their own. Similarly, the TC could say, effectively, “now is the time to act — do it in your own ways, in your own organisations, whatever they are — but please bring the results together for us to formalise when they are ready.”
For me, this approach could change the whole scene. Instead of risking being an obstacle to progress, the CEN TC 353 could add legitimacy and coherence to the call for pre-standardization activity in chosen areas. It would be up to the individuals listening (us wearing different hats) to take up that challenge in whatever ways we believe are best. Let’s look at the two proposals from that perspective.
AFNOR, the French standards body, was suggesting working towards a European Standard (EN) with the title “Metadata for Learning Opportunities part 2 : Detailed Description of Training and Grading (face to face, distance or blended learning and MOOCs): Framework and Methodology”. The point is to extend MLO (EN 15982), including perhaps some of those characteristics of courses (learning opportunities), perhaps drawn from the Norwegian CDM or its French derivative, that didn’t make it into the initial version of MLO for advertising. There have from time to time in the UK been related conversations about the bits of the wider vision for XCRI that didn’t make it into XCRI-CAP (“Course Advertising Profile”). But they didn’t make it probably for some good reason — maybe either there wasn’t agreement about what they should be, or there wasn’t any pressing need, or there weren’t enough implementations of them to form the basis for effective consensus.
Responding to this, I can imagine BSI and CETIS colleagues in the UK seriously insisting, first, that implemention should go hand in hand with specification. We need to be propertly motivated by practical use cases, and we need to test ideas out in implementation before agreeing to standardize them. I could imagine other European colleagues insisting that the ideas should be accepted by all the relevant EC DGs before they have a chance of success in official circles. And so on — we can all do what we are best at, and bring those together. And perhaps also we need to collaborate between national bodies at this stage. It would make sense, and perhaps bring greater commitment from the national bodies and other agencies, if they were directly involved, rather than simply sending people to remote-feeling committees of standards organisations. In this case, it would be up to the French, whose Ministry of Education seems to be wanting something like this, to arrange to consult with others, to put together an implemented proposal that has a good chance of achieving European consensus.
We agreed that it was a good idea for the French proposal to use the “MOOC” label to gain interest and motivation, while the work would in no way be limited to MOOCs. And it’s important to get on board both some MOOC providers, and related though different, some of the agencies who aggregate information about MOOCs (etc.) and offer information about them through portals so that people can find appropriate ones. The additional new metadata would of course be designed to make that search more effective, in that more of the things that people ask about will be modelled explicitly.
So, let’s move on to the Swedish proposal. This was presented under the title “Linked and Open Data for Learning and Education”, based on their national project “Linked and Open Data in Schools” (LODIS). We agreed that it isn’t really on for a National Body simply to propose a national output for European agreement, without giving evidence on why it would be helpful. In the past, the Workshop would have been a fair place to bring this kind of raw idea, and we could have all pitched in with anything relevant. But under our new arrangements, we need the Swedes themselves to lead some cross-European collaboration to fill in the motivation, and do the necessary research and comparison.
There are additional questions also relevant to both proposals. How will they relate to the big international and American players? For example, are we going to get schema.org to take these ideas on, in the fullness of time? How so? Does it matter? (I’m inclined to think it does matter.)
I hope the essentials of the new approach are apparent in both cases. The principle is that TC 353 acts as a mediator and referee, saying “OK” to the idea that some area might be ripe for further work, and encouraging people to get on with it. I would, however, suggest that three vital conditions should apply, for this approach to be effective as well as generally acceptable.
- The principal stakeholders have to arrange the work themselves, with enough trans-national collaboration to be reasonably sure that the product will gain the European consensus needed in the context of CEN.
- The majority of the drafting and testing work is done clearly before a formal process is started in CEN. In our sector, it is vital that the essential ideas are free and open, so we want a openly licenced document to be presented to the TC as a starting point, as close as can be to the envisioned finishing point. CEN will still add value through the formal process and formal recognition, but the essential input will still be openly and freely licenced for others to work with in whatever way they see fit.
- The TC must assert the right to stop and revoke the CEN work item, if it turns out that it is not filling a genuine European need. There is room for improvement here over the past practice of the TC and the WS-LT. It is vital to our reputation and credibility, and to the ongoing quality of our output, that we are happy with rejecting work that it not of the right quality for CEN. Only in this way can CEN stakeholders have the confidence in a process that allows self-organising groups to do all the spadework, prior to and separate from formal CEN process and oversight.
At the meeting we also heard that the ballot on the TC 353 marketing website was positive. (Disclosure: I am a member of the TC 353 “Communications Board” who advised on the content.) Hopefully, a consequence of this will be that we are able to use the TC 353 website both to flag areas for which TC 353 believes there is potential for new work, and to link to the pre-standardization work that is done in those areas that have been encouraged by the TC, wherever that work is done. We hope that this will all help significantly towards our aim of effectively open standardization work, even where the final resulting EN standards remain as documents with a price tag.
I see the main resolutions made at the meeting as enacting this new role. TC 353 is encouraging proposers of new work to go ahead and develop mature open documentation, and clear standardization proposals, in whatever European collaborations they see fit, and bring them to a future TC meeting. I’d say that promises a new chapter in the work of the TC, which we should welcome, and we should play our part in helping it to work effectively for the common good.
The current situation in Europe regarding the whole process of standardization in the area of ICT for Learning Education and Training (LET) is up in the air just now, because of a conflict between how we, the participants, see it best proceeding, and how the formal de jure standards bodies are reinforcing their set up.
My dealings with European learning technology standardization colleagues in the last few years have probably been at least as much as any other single CETIS staff member. Because of my work on European Learner Mobility and InLOC, since 2009 I have attended most of the meetings of the Workshop Learning Technologies (which also has an official page), and I have also been involved centrally in the eCOTOOL and to a lesser extend in the ICOPER European projects.
So what is going on now — what is of concern?
There has been much discussion recently about Mozilla Open Badges, xAPI (Experience API, alias “Tin Can API“) and LRMI, as new and interesting specifications to help bring standardization particularly into the world of technology and resources involved with people and their learning. They have all reached their “version 1″ this year, along with InLOC.
When engaging deeply in any standardization project, as I have with the InLOC project, one is likely to get new insights into what standardization is, or should be. I tried to encapsulate this in a tweet yesterday, saying “Standardization, properly, should be the process of formulation and formalisation of the terms of collective commitment”.
Then @crispinweston replied “Commitment to whom and why? In the market, fellow standardisers are competitors.” I continued, with the slight frustration at the brevity of the tweet format, “standards are ideally agreed between mutually recognising group who negotiate their common interest in commitment”. But when Crispin went on “What role do you give to the people expected to make the collective commitment in drafting the terms of that commitment?” I knew it was time to revert from micro-blogging to macro-blogging, so to speak.
Crispin casts me in the position of definer of roles — I disclaim that. I am trying, rather, firstly to observe and generalise from my observations about what standardization is, when it is done successfully, whether or not people use or think of the term “standardization”, and secondly, to intuit a good and plausible way forward, perhaps to help grow a consensus about what standardization ought to be, within the standardization community itself.
One of the challenges of the InLOC project was that the project team started from more or less carte blanche. Where there is a lot of existing practice, standardization can (in theory at least) look at existing practice, and attempt to promote standardization on the best aspects of it, knowing that people do it already, and that they might welcome (for various reasons) a way to do it in just one way, rather than many. But in the case of InLOC, and any other “anticipatory” standard, people aren’t doing closely related things already. What they are doing is publishing many documents about the knowledge, skills, competence, or abilities (or “competencies”) that people need for particular roles, typically in jobs, but sometimes as learners outside of employment. However, existing practice says very little about how these should be structured, and interrelated, in general.
So, following this “anticipatory” path, you get to the place where you have the specification, but not the adoption. How do you then get the adoption? It can only be if you have been either lucky, in that you’ve formulated a need that people naturally come to see, or that you are persuasive, in that you persuade people successfully that it is what they really (really) want.
The way of following, rather than anticipating, practice certainly does look the easier, less troubled, surer path. Following in that way, there will be a “community” of some sort. Crispin identifies “fellow standardisers” as “competitors” in the market. “Coopetition” is a now rather old neologism that comes to mind. So let me try to answer the spirit at least of Crispin’s question — not the letter, as I am seeing myself here as more of an ethnographer than a social engineer.
I envisage many possible kinds of community coming together to formulate the terms of their collective commitments, and there may be many roles within those communities. I can’t personally imagine standard roles. I can imagine the community led by authority, imposing a standard requirement, perhaps legally, for regulation. I can imagine a community where any innovator comes up with a new idea for agreeing some way of doing things, and that serves to focus a group of people keen to promote the emerging standard.
I can imagine situations where an informal “norm” is not explicitly formulated at all, and is “enforced” purely by social peer pressure. And I can imagine situations where the standard is formulated by a representative body of appointees or delegates.
The point is that I can see the common thread linking all kinds of these practices, across the spectrum of formality–informality. And my view is that perhaps we can learn from reflecting on the common points across the spectrum. Take an everyday example: the rules of the road. These are both formal and informal; and enforced both by traffic authorities (e.g. police) and by peer pressure (often mediated by lights and/or horn!)
When there is a large majority of a community in support of norms, social pressure will usually be adequate, in the majority of situations. Formal regulation may be unnecessary. Regulation is often needed where there is less of a complete natural consensus about the desirability of a norm.
Formalisation of a norm or standard is, to me, a mixed blessing. It happens — indeed it must happen at some stage if there is to be clear and fair legal regulation. But the formalisation of a standard takes away the natural flexibility of a community’s response both to changing circumstances in general, and to unexpected situations or exceptions.
Time for more comment? You would be welcome.
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.
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”.
- 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.
- 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.
- 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.
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.
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.
No information model is complete without suggestions for how to bind it to currently relevant technologies. The ones chosen by InLOC were:
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.
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.
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.
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.