So here I am … continuing the thread of the logic of competence, nearly 7 years on. I’m delighted to see renewed interest from several quarters in the field of competence frameworks. There’s work being done by the LRMI; and much potential interest from those interested in various kinds of soft skills. And some kinds of “badges” – open credentials intended to be displayed and easily recognised – often rely on competence definitions for their award criteria.

I just have to say to everyone who explores this area, beware! There are two different kinds of things that are both called similar things: “competencies”; “competences”; “competence definitions”; skills; etc.

1. There is one kind of statements of ability that people measure up to or not. My favourite simple understandable examples are things like “can juggle 5 balls for a minute without dropping any” or “can type at 120 words per minute from dictation making fewer than 10 mistakes”. But there are many less exact examples of similar things, that clearly either do or do not apply to individuals at a given time of testing. “Knows how to solve quadratic equations using the formula” or “can apply Pythagoras’ theorem to find the length of the third side of a right-angled triangle” might be two from mathematics. Many more from the vocational world, but they would mean less to those not in that profession or occupation.
2. Then there is another kind, more of a statement indicating an ability or area of competence in which someone can be more or less proficient. Taking the examples above, these might be: “can juggle” or “juggling skills”; “can type” or “typing ability”; “knows about mathematics” or “mathematical ability”. There are vast numbers of these, because they are easier to construct than the other kind. “Can manage a small business”; “good communicator”; “can speak French”; “good at knitting”; “a good diplomat”; “programming”; “chess”; you think of your own.

What you can see quite plainly, on looking, is that with the first kind of statement, it is possible to say whether or not someone comes up to that standard; while with the second kind of phrase, either there is no standard defined, or the standard is too vague to judge whether or not someone “has” that ability or not — it’s more like, how much of that ability do you have?

In the past, I’ve called the first kind form of words a “binary” competence definition, and the second kind “rankable”. (Just search for “binary rankable” and you’ll get plenty.) But these are so unmemorable that I even forgot myself what I had called them. I’m looking for better names, that people (including myself) can easily remember.

Woe betide anyone who mixes the two kinds without realising what they are doing! Woe betide also anyone who uses one kind only, and imagines that the other kind either don’t exist or don’t matter.

The world is full of lists of skills which people should have some of. “Communication skills”. “Empathy”. “Resilience”. Loads of them. And in most cases, these are just of the second kind. They have not defined any particular level of the skill, and expect people to produce evidence about how good they are at the given skill, when asked.

In the vocational world of occupations and professions, however, we see very many well-defined statements that are of the first kind. This is to be expected, because to give someone a professional qualification requires that they are assessed as possessing skills to a certain, sufficient level.

The two kinds of statements are intimately related. Take any statement of the first kind. What would be better, or not so good? Juggling 3 balls for 30 seconds? Typing a 60 words per minute? These belong, as points on scales, respectively, of juggling skills and typing ability. Thus, every statement of the first kind has at least one scale that it is a point on. Conversely, every scale description, of the second kind, can, with sufficient insight, be detailed with positions on that scale, which will be statements of the first kind.

In the InLOC information model, these reciprocal relationships are given identifiers hasDefinedLevel and isDefinedLevelOf. These is perhaps the most essential and vital pair of relationships in InLOC.

So what about competence frameworks? Well, a framework, whether explicitly or implicitly, is about relating these two kind of statements together. It is about defining areas of ability that are important, perhaps to an activity or a role; and then also defining levels of those abilities that people can be assessed at. It’s only when these levels are defined that one has criteria, not only for passing exams or recruiting employees, but also for awarding badges. And the interest in badges has held this space open for the seven years I’ve been writing about the logic of competence. Thank you, those working with badges!

Now I’ve explained this again, could you help me by saying which pair of terms would best describe for you the two kinds of statements, better than “binary” and “rankable”? I’d be most grateful.

1. People agree it’s political

The response to my presentation (What will we need to learn and have evidence for? on Slideshare) reassured me that many of the excellent people at the conference shared something like my sense that the world of learning, education, e-portfolios and open badges is more political now than it has ever been in the past history of this conference. It is not simply well-meaning educators helping “their” learners to a richer, more fulfilling education, learning and life (a great aim though that remains). It is, to me, increasingly about what kind of society we want.

Serge Ravet (whose conference it is) and others have understood a political dimension to e-portfolios since the beginning. It seems now that it is increasingly plain to everyone.

2. It’s not about the technology, but about what it’s used for

People are understanding, but do not all yet understand, that it is not the technology by itself that makes the difference, but the ends for which it is used. Maybe this needs to be explained a bit more…

There seems to be a tendency for people to attach their cause (if, as often, they have a cause: in our case, predominantly an educational cause) to any new technology that comes along, perhaps with the justification that the new technology makes it easier to do things differently, or at least gives people the opportunity to do things differently.

Think first of e-portfolios, because this conference started as the “ePortfolio” conference (and I’ve been to all of them). Yes, e-portfolios can be used to promote reflection. They can be used to give authentic evidence of authentic learning – whatever that may mean – but then they can be used to assemble and present evidence of almost anything, in almost any way. Thus, many people in this community (myself included) would like to play down the label “e-portfolio”, and instead focus on the values of the kind of learning and education that we think benefits people and society, which we would like to see come about through the use of e-portfolio technology.

Think now of Badges. Mozilla Open Badges includes a technological framework perhaps mixed in with some implicit values. One major appeal of Badge technology is that it promises to be a tool that can be used to reclaim credentials from the grip of established educational, training, or professional institutions. And this aim goes along with much else laudable in learning technology and forward-looking practice. But, equally, Badges can be used by established players to replicate the existing systems of qualifications and certificates. In no way does the use of Badges ensure that a system is in accordance with any particular set of values, aims, or aspirations. This was understood several times in the conference discussion.

Thus, we need to be careful that we don’t overemphasise the technology, but keep a clear eye on the values we want to promote. This may mean making those values explicit; but then I would say it’s time to do that anyway.

3. It’s not about having a “line”, it’s about being open

It’s easy to imagine some groups of people – and maybe this includes politicians, authors, speakers and many academics – attaching themselves to a recognisable “line”, which can be “sold”, in the form of manifestos, books, papers, talks, or project proposals touting the “next big thing”. Maybe having a consistent, recognisable line contributes to their success. Maybe it is vital component of their public identity. I wonder if sometimes it becomes their personal identity as well.

Personally, I don’t want a static “line”, I want to be OPEN. I thrive on openness. I love seeing and feeling the evolution and growth of ideas that are freed from the constraints of their originator’s conceptual framework, to have lives of their own. I love seeing young people venture beyond the constraints of their background and upbringing, and exploring new ideas, new places, new thoughts, new ways of being, freely choosing the traditional or the new.

And, particularly, I relish the thought (as Theodore Zeldin also expressed in “An Intimate History of Humanity“) of what could ensue when two or more open people come together; when they risk trusting each other; when they find that trust justified; when they freely and openly share their good ideas; when they grow into truly fruitful collaboration and co-creation.

4. Motivation is not just about intrinsic or extrinsic

Reflection on the conference conversations suggests that the question of intrisic motivation and extrinsic (or instrumental) motivation is not as simple as it might first appear. Following Alfie Kohn, who spoke remotely, one can indeed see extrinsic rewards as squeezing out natural motivation for learning. But if you see other people’s approval as an extrinsic reward, might Kohn’s view be setting up an autistic nightmare of individuals sociopathically following their own whims, no matter what others say?

It might be more fruitful to put that typology of motivation to one side. The reward of seeing other people’s needs being met – of seeing them thrive – may be best seen as intrinsic, but my guess is that few people have the courage and strength to follow this through without the extrinsic reward of approval of one’s trusted and valued peers.

Maybe this is related to what Adam Grant expresses in his recent book, “Give and Take“. Givers are intrisically motivated to contribute to other people’s good, but far from the myth that givers are losers, they often shine out as supremely successful in business as well as life. The idea of delight in the satisfaction of the needs of others is shared by Marshall Rosenberg in his Non-Violent Communication work.

These are just two pointers to something that seems to have been almost entirely missed out from educational theory. It’s about what works as motivation for the common good, but the common good is something that doesn’t appear much in the kind of thinking that might be described by Robert Kegan and others as “modernism”, which is more to do with the individual than the collective. Personally, I identify my own desire to promote the common good with the kind of reconstructive post-modernism written about by Kegan.

What is the relevance to Cetis, and to learning technology?

This is a question that naturally relates to the fact that this post is on the Cetis web site. Here I am moving beyond what I learned at the conference, and relating it back to my (currently half time) affiliation.

1. The fact that the technology is not the biggest issue is one that we have known in Cetis for many a year. Nothing new here, then, but it is a worthwhile confirmation and reminder. It’s the human practices and culture that are the challenge.
2. Cetis is not at present in a good position to be explicitly political. But I do believe that our advocacy of what is “open” in education and technology has a political dimension, and that needs to sit happily with a host that appreciates that, rather than awkwardly with a host that finds it an irritant.
3. Maybe, and here I own up to speculation, maybe it is time for us as Cetis to resume the role that we used to play for many years – that of facilitating, fostering, promoting discussion within communities of practice, which are fundamentally places where peer groups meet to investigate collaboration, or at least to share knowledge openly.
4. And lastly, a question: how can e-portfolios, badges, or other related technology support the values, the politics, of sharing, collaboration, and the common good?

Perhaps I may compare the ePIC conference with the Cetis conference. The Cetis conference, like ePIC, is a conference of enthusiasts, but this year, instead of being free of charge, the Cetis conference was successfully run at a very moderate cost. Maybe the ePIC conference (or whatever it will be called) can move to a similar point but in the opposite direction, reducing its cost to encourage wider participation, and to enable the ongoing participation of the enthusiastic supporters that we have kept. We all need to be careful with expenses such as keynote speakers. Cetis did well this year, but we all need to be careful to get the right people, if anyone!

So, I hope that the enthusiasm and engagement of the ePIC conference continues, and that the community it represents grows and develops towards the common good.

Wikipedia has culture, or cultures. I personally have little experience of them, simply from doing little edits, but was prodding around recently while researching for this session. Some Wikipedia culture seems very “geek” – with in jokes, perhaps putting off the uninitiated. Maybe this comes from much older newsgroup culture. People got to misunderstand each other much too frequently, and flame wars resulted. Rather harsh words like “mercilessly” still appear in the Wikipedia documentation, despite being debated extensively. They stand as a warning of the apparent harshness that may be felt, and also serve to put people off.

For example, there is an in joke, abbreviated to “TINC”, standing for “there is no cabal”. The article that explains this gives a good flavour of the culture it comes from and belongs in. I don’t think anyone would claim that this culture is a majority culture, and it is prone to excluding people. If we want Wikipedia to be a universal open educational resource, part of a proper “knowledge commons”, we must open this up.

An example that came up in our session was Wikipedia’s use of the term “editor”. Now many of us may assume that we all know that a Wikipedia “editor” is simply anyone who chooses to edit any article, but that awareness is not in fact a majority awareness. In the rest of the world, an “editor” has connotations of a book editor, or a newspaper editor – someone with a particular structured role. A Wikipedia “101” course needs to explain that right away. Or could the term be changed?

This links to an issue that was of wider relevance to the conference. What does “open” mean? Yes, there is the helpful open definition. But also, “open” is used in the phrase “open for business”, which is too frequently understood as meaning low on regulation, with few if any barriers preventing corporate money-making, even if that tramples over people and things that are important to them. The word “open”, like the word “freedom”, carries with it much ambivalence. What is open, to who, and why? Open for some may imply closed for others.

Just on the morning of our session I picked up two leads from tweets on related topics. Back in 2008, Michel Bauwens was asking Is something fundamentally wrong with Wikipedia governance process? In reply, P2P Lab pointed to a First Monday article from 2010 about Wikipedia’s peer governance. Then today I see reference to a more recent article on Wikipedia’s problems by Deepak Chopra. People are not unaware of problematic issues with Wikipedia.

One approach to dealing with the issues arising is simply to arrange more Wikipedia training. Brian is rightly keen on that. But it does raise the question, what can be trained, and what is more a matter of culture? Is it possible to help cultures that are good for open knowledge and its governance?

What peer governance cultures are there, anyway? I’ve had experience of consensus governance in a number of contexts, and there seem to be common problems. First, though most people are reasonable at collaboration, there are some who seem to act in ways that are indifferent to the common good, and only promote their own interests: takers, rather than givers, in Adam Grant’s scheme of humanity. The problem comes when takers are not dealt with effectively. Even in structures and organisations that are supposed to be managed by consensus, there seems to be a tendency to form cabals, or cliques: small elites who take over governance processes in their own interests (though sometimes they manage to fool themselves and others that they are trying to further the common interest).

Shouldn’t this be one of the roles of education, to bring people up, not only to further the common good, but to detect and deal with people who are not doing so?

Knowledge of what makes the common good, and collaborative skills (including communication and working with others) are clearly important, but seem not to be sufficient. We also need effective enculturation. Some kind of enculturation is at the heart of the hidden curriculum of educational institutions. Maybe it should be less hidden, and more transparent?

I won’t go on to detail possible solutions here, but in terms of where I am, I could easily envisage

• a framework for the competences, values or attitudes needed for effective peer-to-peer collaboration;
• a set of peer-assessed badges attesting these;
• related courses being set up as MOOCs;
• a whole lot of relevant open educational resources

and so on.

Back to the conference title: “Building the Digital Institution”. Is it, I ask, an institution that we want, in any recognisable form, complete with a hidden curriculum of a culture that is unlikely to be collaborative? Or is it a radically different kind of social organisation, built around, and promoting, a positive learners’ culture of learning through and for collaboration, peer-to-peer, co-operative in the best sense? Maybe our ideas, as well as our new technologies, can now help us make new efforts in the right direction. Let us not apply technology to entrenching elitism and privilege, but rather towards co-creating a knowledge commons that is truly open and transparent.

When we understand how frameworks could be used for badges, it becomes clearer that we need to distinguish between different kinds of ability, and that we need tools to manage and manipulate such open frameworks of abilities. InLOC gives a model, and formats, on which such tools can be based.

I’ll be presenting this material at the Crossover Edinburgh conference, 2014-06-05, though my conference presentation will be much more interactive and open, and without much of this detail below.

What are these frameworks?

Frameworks of skill or competence (under whatever name) are not as unfamiliar as they might sound to some people at first. Most of us have some experience or awareness of them. Large numbers of people have completed vocational qualifications — e.g. NVQs in England — which for a long time were each based on a syllabus taken from what are called National Occupational Standards (NOSs). Each NOS is a statement of what a person has to be able to do, and what they have to know to support that ability, in a stated vocational role, or job, or function. The scope of NOSs is very wide — to list the areas would take far too much space — so the reader is asked to take a look at the national database of current NOSs, which is hosted by the UKCES on their dedicated web site.

Several professions also have good reason to set out standards of competence for active members of that profession. One of the most advanced in this development, perhaps because of the consequences of their competence on life and death, is the medical profession. Documents like Good Medical Practice, published by the General Medical Council, starts by addressing doctors:

Patients must be able to trust doctors with their lives and health. To justify that trust you must show respect for human life and make sure your practice meets the standards expected of you in four domains.

and then goes on to detail those domains:

• Knowledge, skills and performance
• Safety and quality
• Communication, partnership and teamwork
• Maintaining trust

The GMC also publishes the related Tomorrow’s Doctors, in which it

sets the knowledge, skills and behaviours that medical students learn at UK medical schools: these are the outcomes that new UK graduates must be able to demonstrate.

These are the kinds of “framework” that we are discussing here. The constituent parts of these frameworks are sometimes called “competencies”, a term that is intended to cover knowledge, skills, behaviours, attitudes, etc., but as that word is a little unfriendly, and bearing in mind that practical knowledge is shown through the ability to put that knowledge into practice, I’ll use “ability” as a catch all term in this context.

Many larger employers have good reasons to know just what the abilities of their employees are. Often, people being recruited into a job are asked in person, and employers have to go through the process of weighing up the evidence of a person’s abilities. A well managed HR department might go beyond this to maintaining ongoing records of employees’ abilities, so that all kinds of planning can be done, skills gaps identified, people suggested for new roles, and training and development managed. And this is just an outsider’s view!

Some employers use their own frameworks, and others use common industry frameworks. One industry where common frameworks are widely used is information and communications technology. SFIA, the Skills Framework for the Information Age, sets out all kinds of skills, at various levels, that are combined together to define what a person needs to be able to do in a particular role. Similar to SFIA, but simpler, is the European e-Competence Framework, which has the advantage of being fully and openly available without charge or restriction.

Some frameworks are intended for wider use than just employment. A good example is Mozilla’s Web Literacy Map, which is “a map of competencies and skills that Mozilla and our community of stakeholders believe are important to pay attention to when getting better at reading, writing and participating on the web.” They say “map”, but the structure is the same as other frameworks. Their background page sets out well the case for their common framework. Doug Belshaw suggests that you could use the Web Literacy Map for “alignment” of the kind of Open Badges that are also promoted by Mozilla.

Links to badges

You can imagine having badges for keeping track of people’s abilities, where the abilities are part of frameworks. To help people move between different roles, from education and training to work, and back again, having their abilities recognised, and not having to retrain on abilities that have already been mastered, those frameworks would have to be openly published, able to be referenced in all the various contexts. It is open frameworks that are of particular interest to us here.

Badges are typically issued by organisations to individuals. Different organisations relate to abilities differently. Some organisations, doing business or providing a service, just use employees’ abilities to deliver products and services. Other organisations, focusing around education and training, just help people develop abilities, which will be used elsewhere. Perhaps most organisations, in practice, are somewhere on the spectrum between these two, where abilities are both used and developed, in varied proportions. Looking at the same thing from an individual point of view, in some roles people are just using their abilities to perform useful activities; in other roles they are developing their abilities to use in a different role. Perhaps there are many roles where, again, there is a mixture between these two positions. The value of using the common, open frameworks for badges is that the badges could (in principle) be valued across different kinds of organisation, and different kinds of role. This would then help people keep account of their abilities while moving between organisations and roles, and have those abilities more easily recognised.

The differing nature of different abilities

However, maybe we need to be more careful than simply to take every open framework, and turn it into badges. If all the abilities than were used in all roles and organisations had separate badges, vast numbers of badges would exist, and we could imagine the horrendous complexity of maintaining them and managing them. So it might make sense to select the most appropriate abilities for badging, as follows.

• Some abilities are plentiful, and don’t need special training or rewarding — maybe organisations should just take them for granted, perhaps checking that what is expected is there.
• Some abilities are hard, or impossible, to develop: you have them or you don’t. In this case, using badges would risk being discriminatory. Badges for e.g. how high a person can reach, or how long they can be in the sun without burning, would be unnecessary as well as seriously problematic, while one can think of many other personal characteristics, potentially framed as abilities, which might be less visible on the surface, but potentially lead to discrimination, as people can’t just change them.
• Some abilities might only be able to be learned within a specific role. There is little point in creating badges for these abilities, if they do not transfer from role to role.
• Some abilities can be developed, are not abundant, and can be transferred substantially from one role to another. These are the ones that deserve to be tracked, and for which badges are perhaps most worth developing. This still leaves open the question of the granularity of the badges.

Practical considerations governing the creation and use of frameworks

It’s hard to create a good, generally accepted common skills or competence framework. In order to do so, one has to put together several factors.

• The abilities have to be sufficiently common to a number of different roles, between which people may want to move.
• The abilities have to be described in a way that makes sense to all collaborating parties.
• It must be practical to include the framework into other tools.
• The framework needs to be kept up to date, to reflect changing abilities needed for actual roles.
• In particular, as the requirements for particular jobs vary, the components of a framework need to be presented in such a way that they can be selected, or combined with components of other frameworks, to serve the variety of roles that will naturally occur in a creative economy.
• Thus, the descriptions of the abilities, and the way in which they are put together, need all to be compatible.

Let’s look at some of this in more detail. What is needed for several purposes is the ability to create a tailored set of abilities. This would be clearly useful in describing both job opportunities, and actual personal abilities. It is of course possible to do all of this in a paper-like way, simply cutting and pasting between documents. But realistically, we need tools to help. As soon as we introduce ICT tools, we have the requirement for standard formats which these tools can work with. We need portability of the frameworks, and interoperability of the tools.

For instance, it would be very useful to have a tool or set of tools which could take frameworks, either ones that are published, or ones that are handed over privately, and manipulate them, perhaps with a graphical interface, to create new, bespoke structures.

Contrast with the actual position now. Current frameworks rarely attempt to use any standard format, as there are no very widely accepted standards for such a format. Within NOSs, there are some standards; the UK government has a list of their relevant documents including “NOS Quality Criteria” and a “NOS Guide for Developers” (by Geoff Carroll and Trevor Boutall). But outside this area practice varies widely. In the area of education and training, the scene is generally even less developed. People have started to take on the idea of specifying the “learning outcomes” that are intended to be achieved as a result of completing courses of learning, educaction or training, but practice is patchy, and there is very little progress towards common frameworks of learning outcomes.

We need, therefore, a uniform “model”, not for skills themselves, which are always likely to vary, but for the way of representing skills, and for the way in which they are combined into frameworks.

The InLOC format

Between 2011 and 2013 I led a team developing a specification for just this kind of model and format. The project was called “Integrating Learning Outcomes and Competences”, or InLOC for short. We developed CEN Workshop Agreement CWA 16655 in three parts, available from CEN in PDF format by ftp:

1. Information Model for Learning Outcomes and Competences
2. Guidelines including the integration of Learning Outcomes and Competences into existing specifications
3. Application Profile of Europass Curriculum Vitae and Language Passport for Integrating Learning Outcomes and Competences

The same content and much extra background material is available on the InLOC project web site. This post is not the place to explain InLOC in detail, but anyone interested is welcome to contact me directly for assistance.

What can people do in the meanwhile?

I’ve proposed elsewhere often enough that we need to develop tools and open frameworks together, to achieve a critical mass where there enough frameworks published to make it worthwhile for tool developers, and sufficiently developed tools to make it worthwhile to make the extra effort to format frameworks in the common way (hopefully InLOC) that will work with the tools.

There will be a point at which growth and development in this area will become self-sustaining. But we don’t have to wait for that point. This is what I think we could usefully be doing in the meanwhile, if we are in a position to do so.

1. Build your own frameworks

It’s a challenge if you haven’t been involved in skill or competence frameworks before, but the principles are not too hard to grasp. Start out by asking what roles, and what functions, there are in your organisation, and try to work out what abilities, and what supporting knowledge, are needed for each role and for each function. You really need to do this, if you are to get started in this area. Or, if you are a microbusiness that really doesn’t need a framework, perhaps you can build one for a larger organisation.

2. Use parts of frameworks that are there already, where suitable

It may not be as difficult as you thought at first. There are many resources out there, such as NOSs, and the other frameworks mentioned above. Search, study, see if you can borrow or reuse. Not all frameworks allow it, but many do. So, some of your work may already be done for you.

3. Publish your frameworks, and their constituent abilities, each with a URL

This is the next vital step towards preparing your frameworks for open use and reuse. The constituent abilities (and levels, see the InLOC documentation) really need their own identifiers, as well as the overall frameworks, whether you call those identifiers URLs, URIs or IRIs.

4. Use the frameworks consistently throughout the organisation

To get the frameworks to stick, and to provide the motivation for maintaining them, you will have to use them in your organisation. I’m not an expert on this side of practice, but I would have thought that the principles are reasonably obvious. The more you have a uniform framework in use across your organisation, the more people will be able to see possibilities for transfer of skills, flexible working, moving across roles, job rotation, and other similar initiatives that can help satisfy employees.

5. Use InLOC if possible

It really does provide a good, general purpose model of how to represent a framework, so that it can be ready for use by ICT systems. Just ask if you need help on this!

6. Consider integrating open badges

It makes sense to consider your badge strategy and your framework strategy together. You may also find this old post of mine helpful.

7. Watch for future development of tools, or develop some yourself!

If you see any, try to help them towards being really useful, by giving constructive feedback. I’d be happy to help any tool developers “get” InLOC.

I hope these ideas offer people some pointers on a way forward for skill and competence frameworks. See other of my posts for related ideas. Comments or other feedback would be most welcome!

InLOC is well designed to provide the conceptual “glue” or “thread” for holding together structures and planned pathways of achievement, which can be represented by Mozilla OpenBadges.

Since my last post — the last of the previous academic year, also about OpenBadges and InLOC — I have been invited to talk at OBSEG – the Open Badges in Scottish Education Group. This is a great opportunity, because it involves engaging with a community with real aspirations for using Open Badges. One of the things that interests people in OBSEG is setting up combinations of lesser badges, or pathways for several lesser badges to build up to greater badges. I imagine that if badges are set up in this way, the lesser badges are likely to become the stepping stones along the pathway, while it is the greater badge that is likely to be of direct interest to, e.g., employers.

All this is right in the main stream of what InLOC addresses. Remember that, using InLOC, one can set out and publish a structure or framework of learning outcomes, competenc(i)es, etc., (called “LOC definitions”) each one with its own URL (or IRI, to be technically correct), with all the relationships between them set out clearly (as part of the “LOC structure”).

The way in which these Scottish colleagues have been thinking of their badges brings home another key point to put the use of InLOC into perspective. As with so many certificates, awards, qualifications etc., part of the achievement is completion in compliance with the constraints or conditions set out. These are likely not to be learning outcomes or competences in their own right.

The simplest of these non-learning-outcome criteria could be attendance. Attendance, you might say, stands in for some kind of competence; but the kind of basic timekeeping and personal organisation ability that is evidenced by attendance is very common in many activities, so is unlikely to be significant in the context of a Badge awarded for something else. Other such criteria could be grouped together under “ability to follow instructions” or something similar. A different kind of criterion could be the kinds of character “traits” that are not expected to be learned. A person could be expected to be cheerful; respectful; tall; good-looking; or a host of other things not directly under their control, and either difficult or impossible to learn. These non learning outcome aspects of criteria are not what InLOC is principally designed for.

Also, over the summer, Mozilla’s Web Literacy Standard (“WebLitStd”) has been progressing towards version 1.0, to be featured in the upcoming MozFest in London. I have been tracking this with the help of Doug Belshaw, who after great success as an Open Badges evangelist has been focusing on the WebLitStd as its main protagonist. I’m hoping soon (hopefully by MozFest time) to have a version of the WebLitStd in InLOC, and this brings to the fore another very pragmatic question about using InLOC as a representation.

Many posts ago, I was drawing out the distinction between LOC (that is, Learning Outcome or Competence) definitions that are, on the one hand, “binary”, and on the other hand, “rankable”. This is written up in the InLOC documentation. “Binary” ones are the ones for which you can say, without further ado, that someone has achieved this learning outcome, or not yet achieved it. “Rankable” ones are ones where you can put people in order of their ability or competence, but there is no single set of criteria distinguishing two categories that one could call “achieved” and “not yet achieved”.

In the WebLitStd, it is probably fair to say that none of the “competencies” are binary in these terms. One could perhaps characterise them as rankable, though perhaps not fully, in that there may be two people with different configurations of that competency, as a result perhaps of different experiences, each of whom were better in some ways than the other, and each conversely less good in other ways. It may well be similar in some of the Scottish work, or indeed in many other Badge criteria. So what to do for InLOC?

If we recognise a situation where the idea is to issue a badge for an achievement that is clearly not a binary learning outcome, we can outline a few stages of development of their frameworks, which would result in a progressively tighter matching to an InLOC structure or InLOC definitions. I’ll take the WebLitStd as illustrative material here.

First, someone may develop a badge for something that is not yet well-defined anywhere — it could have been conceived without reference to any existing standards. To illustrate this case, an example of a title could be “using Web sites”. There is no one component of the WebLitStd that covers “using the web”, and yet “using” it doesn’t really cover Web literacy as a whole. In this case, the Badge criteria would need to be detailed by the Badge awarder, specifically for that badge. What can still be done within OpenBadges is that there could be alignment information; however it is not always entirely clear what the relationship is meant to be between a badge and a standard it is “aligned” to. The simplest possibility is that the alignment is to some kind of educational level. Beyond this it gets trickier.

A second possibility for a single badge would be to refer to an existing “rankable” definition. For example, consider the WebLitStd skill, “co-creating web resources”, which is part of the “sharing & collaborating” competency of the “Connecting” strand. To think in detail about how this kind of thing could be badged, we need to understand what would count (in the eye of the badge issuer) as “co-creating web resources”. There are very many possible examples that readily come to mind, from talking about what a web page could have on it, to playing a vital part in a team building a sophisticated web service. One may well ask, “what experiences do you have of co-creating web resources?” and, depending on the answer, one could roughly rank people in some kind of order of amount and depth of experience in this area. To create a meaningful badge, a more clearly cut line needs to be drawn. Just talking about what could be on a web page is probably not going to be very significant for anyone, as it is an extremely common experience. So what counts as significant? It depends on the badge issuer, of course, and to make a meaningful badge, the badge issuer will need to define what the criteria are for the badges to be issued.

A third and final stage, ideal for InLOC, would be if a badge is awarded with clearly binary criteria. In this case there is nothing standing in the way of having the criteria property of the Badge holding a URL for a concept directly represented as a binary InLOC LOCdefinition. There are some WebLitStd skills that could fairly easily be seen as binary. Take “distinguishing between open and closed licensing” as an example. You show people some licenses; either they correctly identify the open ones or they don’t. That’s (reasonably) clear cut. Or take “understanding and labeling the Web stack”. Given a clear definition of what the “Web stack” is, this appears to be a fairly clear-cut matter of understanding and memory.

Working back again, we can see that in the third stage, a Badge can have criteria (not just alignments) which refer directly to InLOC information. At the second and first stage, badge criteria need something more than is clearly set out in InLOC information already published elsewhere. So the options appear to be:

1. describing what the criteria are in plain text, with reference to InLOC information only through alignment; and
2. defining an InLOC structure specifically for the badge, detailing the criteria.

The first of these options has its own challenges. It will be vital to coherence to ensure that the alignments are consistent with each other. This will be possible, for example, if the aspects of competence covered are separate (independent; orthogonal even). So, if one alignment is to a level, and the second to a topic area, that might work. But it is much less promising if more specific definitions are referred to.

(I’d like to write an example at this point, but can’t decide on a topic area — I need someone to give me their example and we can discuss it and maybe put it here.)

From the point of view of InLOC, the second option is much more attractive. In principle, any badge criteria could be analysed in sufficient detail to draw out the components which can realistically be thought of as learning outcomes — properties of the learners — that may be knowledge, skill, competence, etc. No matter how unusual or complex these are, they can in principle be expressed in InLOC form, and that will clarify what is really “aligned” with what.

I’ll say again, I would really like to have some well-worked-out examples here. So please, if you’re interested, get in touch and let’s talk through some of interest to you. I hope to be starting that in Glasgow this week.

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.

InLOC can quietly serve as a cornerstone of all three, providing a specification for one of the important things they may all want to refer to. InLOC allows documentation of the frameworks, of learning outcomes, competencies, abilities, whatever you call them, that describe what people need to know and be able to do.

Mozilla has been given, and devoted, plenty of resource to their OpenBadges effort, and as a result is it widely known about, though not so well known is the rapid and impressive development of the actual specification. The key part of the spec is how OpenBadges represents the “assertions” that someone has achieved something. The thing that people achieve (rather that its achievement) could well be represented in an InLOC framework.

Tin Can / Experience API (I’ll use the customary abbreviation “xAPI”) has also been talked about widely, as a successor to SCORM. The xAPI “makes it possible to collect the data about the wide range of experiences a person has (online and offline)”. This clearly includes “experiences” such as completing a task or attaining a learning outcome. But xAPI does not deal with the relationships between these. If one greater learning outcome was composed of several lesser ones, it wouldn’t be natural to represent that fact in xAPI itself. That is where InLOC naturally comes in.

LRMI (“Learning Resource Metadata Initiative”) is, as one would expect, designed to help represent metadata about learning resources, in a way that is integrated with schema.org. What if many of those learning resources are designed to help a learner achieve an intended learning outcome? LRMI can naturally refer to such a learning outcome, but is not designed to represent the structures themselves. Again, InLOC can do that.

What would be chaotic would be if these three specifications, each one potentially very useful in its own way, all specified their own, possibly incompatible ways of representing the structures or frameworks that are often created to bring common ground and order to this whole area of life.

Please don’t let that happen! Instead, I believe we should be using InLOC for what it is good at, leaving each other spec to handle its own area, and no one shamefully “reinventing the wheel”.

Draft proposals

These proposals are only initial proposals at present, looking forward to discussion with other people involved with or interested in the other three specifications. Please don’t hesitate to suggest better ways if you can see them.

OpenBadges

The Assertions page gives the necessary detail of how the OpenBadges spec works.

• The BadgeClass criteria property means the “URL of the criteria for earning the achievement.” If there is an InLOC LOCdefinition or LOCstructure that represents these criteria, as there could well be, then the natural mapping would be for the criteria property simply to hold the URI, either of the (single) LOCdefinition, or of the LOCstructure that comprises all of the definitions together.
• The BadgeClass alignment property gives a list of “objects describing which educational standards this badge aligns to, if any.” In cases where there is no LOCdefinition or LOCstructure representing the whole of the badge criteria, it seems natural to put a set of LOCdefinition URIs into the (multiple) objects of this property — which are AlignmentObjects.
• Each AlignmentObject has the following properties, which map directly onto InLOC.
  • name: this could be the title of a LOCdefinition
  • url: this could be the id of the same LOCdefinition
  • description: this could be the description of the same LOCdefinition

One could also potentially take both approaches at the same time.

I will record more detail, and change it as it evolves, on the InLOC wiki.

xAPI

The developers call this the Tin Can API, but their sponsors, ADL, call it the Experience API or xAPI.

The specification (v1.0.1, 2013-10-01) can be read in this PDF document.

Tin Can is based around the statement. This is defined as “a simple construct consisting of <actor (learner)> <verb> <object>, with <result>, in <context> to track an aspect of a learning experience.” There are a number of ways in which a statement could relate to a learning outcome or competence. How might these correspond to InLOC?

1. If the statement “verb” is something like completed, or mastered, or passed, the “object” could well be something like a learning outcome, or an assessment directly related to a learning outcome. The object has two properties on top of the expected objectType:
   • id: this can be the same as a LOC id in InLOC
   • definition: this in turn has recommended properties of:
     1. name: this is proposed as the LOC title
     2. description: this is proposed as the LOC description
     3. type: this is proposed as the URI for LOCdefinition or LOCstructure
2. The statement could be that some experiences were had (e.g. an apprenticeship), and the result was the learning outcome or competence. It might therefore be useful to give the URI of an InLOC-formatted learning outcome as part of an xAPI result. Unfortunately, none of the specified properties of the Result object have a URI type, so the URI of a LOC definition would have to go in the extensions property of the result.
3. Often in personal or professional development planning, it is useful to record what is planned. An example of how to represent this, with the object as a sub-statement, is given in the spec section 4.1.4.3, page numbered 20. The sub-statement can be something similar to the first option above.
4. A learning outcome may form part of the context of an activity in diverse ways. If it is not one of the above, it may be possible to use the context property of a statement, either as a statement reference in the statement property of the context, or as part of the context‘s extensions.

In essence, the clearest and most straightforward way of linking to an InLOC LOCstructure or LOCdefinition is as a statement object, rather than its result or context. The other options could be seen as giving too many options, which may lead away from useful interoperability.

I will record more detail, and change it as it evolves, on the InLOC wiki.

LRMI

The documentation for the Learning Resource Metadata Initiative is at http://www.lrmi.net/. The specification, and its correspondence with InLOC, is very simple. All the properties are naturally understood as properties of a learning resource. The property relevant to InLOC is educationalAlignment, whose object is an AlignmentObject.

Here, the LRMI AlignmentObject properties are mapped to LOCdefinition properties.

• targetURL: LOCdefinition id
• targetName: LOCdefinition title
• targetDescription: LOCdefinition description

I will record more detail, and change it as it evolves, on the InLOC wiki.

What this all means

xAPI and LRMI

The implications for xAPI and LRMI are just that they could suggest InLOC as a possible format for the publication of frameworks that they may want to refer to. Neither spec has pretensions to cover this area of frameworks, and the existence of InLOC should help to prevent people inventing diverse solutions, when we really want one standard approach to help interoperability.

A question remains about what a suitable binding of InLOC would be for both specs. In many ways it should not matter, as it will be the URIs and some values that will be used for reference from xAPI and LRMI, not any of the InLOC syntax. However, it might be useful to remember that xAPI’s native language is JSON, and LRMI’s is HTML, with added schema.org markup using microdata or RDFa. Neither of these bindings has been finalised for InLOC, so an opportunity exists to ensure that suitable bindings are agreed, while still conforming to the InLOC information model in one or other form.

OpenBadges

The case of Mozilla Open Badges is perhaps the most interesting. Clearly, there is a potential interest for badges to link to representations of learning outcomes or competences as defined by relevant authorities. It is so much more powerful when these representations reside in a common space that can be referred to by anyone (including e.g. xAPI and LRMI users, personal development, portfolio, and recruitment systems). It is easy to see how badges could usefully become “metadata-infused” tokens of the achievement of something that is already defined elsewhere. Redefining those things would simply confuse people.

InLOC solves several problems that OpenBadges should not have to worry about. One is representing equivalence (or not) between different competencies. That is provided for straightforwardly within InLOC, and should be done by the authorities defining the competencies, whether or not they are the same people as those who define and issue the badges.

Second, InLOC gives a clear, comprehensive and predefined vocabulary for how different competencies relate to each other. Mozilla’s Web Literacy Standard defines a tree structure of “literacies”, “competencies” and “skills”. Other frameworks and standards use other terms and concepts. InLOC is generic enough to represent all the relationships in all of these structures. As with equivalencies, the badge issuer should not have to define, for example, what roles require what skills and what knowledge. That should be up to occupational domain experts.

But OpenBadges do require some way to represent the fact that one, greater, badge can stand for a number of lesser badges. This is necessary to avoid being drowned in a flood of badges each one so small that it is unrecognisable or insignificant.

While so many frameworks have not been expressed in a machine processable format like InLOC, there will remain a requirement for an internal mechanism within OpenBadges to specify precisely which set of lesser badges is represented by a single a greater badge. But when the InLOC structures are in place, and all the OpenBadges in question refer to InLOC URIs for their criteria, we can look forward to automatic consistency checking of super-badges. To check a greater badge with a set of lesser component badges, check that the criteria structure or definition for the greater badge has parts (as defined by InLOC relationships) which are each the criteria of one of the set of lesser badges.

As with xAPI, JSON is the native language of OpenBadges, so one task that remains to be completed is to ensure that there is a JSON binding of InLOC that satisfies both the OpenBadges and the Tin Can communities.

That should be it! Is it?