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?

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.

Nigel Shadbolt, the first keynote speaker, has the co-distinction with Sir Tim B-L of advising for data.gov.uk, and naturally he talked about government linked data. It is great that so much information is being exposed from government sources. I asked him about the National Occupational Standards maintained by Sector Skills Councils, coordinated by the UK Commission on Employment and Skills, and I hope he will be able to advise on leverage points, as even the first steps of the linked data ladder, giving things dereferenceable URIs, would be a highly significant for skills and competences for use in conjunction with learning outcomes, job role competence specifications, and matching outcomes of learning to skills wanted for employment. (UKCES is sponsored by several government departments, though BIS is the lead sponsor and therefore would probably be our best point of contact.)

Crown Copyright information is to have a new, more open, licence, assumed and designed to help reuse. Nigel introduced two sites, enakting.org and sameAs.org, which featured in later presentations as well (both useful and new to me).

Antoine Isaac gave a good introduction to SKOS. I asked him later about applying SKOS to skill definitions, and he seemed to agree that some specialisation of skos:broader and skos:narrower was in order. He also encouraged me to bring the topic up on the SKOS mailing list, which I will do when ready. He seemed to (and Nigel Shadbolt certainly did) imply that linked data meant using RDF/XML as the vehicle — somewhat daunting if not actually dispiriting — but at the end it became apparent that Antoine at least regarded RDFa as equivalent to RDF/XML. The more popular- and commercial-minded participants and presenters seemed to favour RDFa, which left me wondering how in touch RDF/XML proponents are. Probably not that many people are aware that RDFa is currently being developed to be more friendly to people who have started with microformats, so some existing reading on RDFa might not yet be as persuasive as it could be. However, it was good to note that no one at this conference was advocating microformats. Microdata, on the other hand, seems to be an entirely unknown quantity. (Current discussions within the RDFa community suggest a possible cross-mapping.)

Richard Wallis brought the Birmingham origins of Talis (co-sponsors of the event) into a generally informative presentation reinforcing some points already made with interesting examples. His presentation is on slideshare under his id of “rjw”.

Steve Dale told us about the local government “Knowledge Hub“, a “big, bold and ambitious” project going live in February 2011. Again it is about public sector information, though this time perhaps as much for local government workers themselves (who may not even be aware of all the information held) as much as members of the public. Needless to say, none of this involves information about individual members of the public, though I did engage in some discussion around this. Seems that people still shy away from the area. My view would be that individuals have more to gain than to lose by having the infrastructure available for them easily to access information held about them from various sources, particularly in the public sector.

After a pleasant and plenteous lunch, Martin Hepp introduced the GoodRelations ontology, designed for representing the semantics of e-commerce, thus enabling much faster and more accurate matches of offers and requests. He reckons that a very large proportion of GDP — perhaps over 50% — can be accounted for as involved with commercial matchmaking, which becomes quite plausible when you consider that it must include marketing, advertising, etc. Hence it is clear that improvements here can have a huge positive effect on an economy. Martin was one of the explicit advocates of RDFa, and the systems he helps to facilitate use RDFa.

Then came the well-known-to-us Andy Powell (one of the very few I knew there) telling a well-illustrated “long and winding road” story of how Dublin Core has related to RDF, in the process trying to balance the enthusiasm of the Semantic Web evangelists against the cataloguing librarians who were not at all so sure. He introduced the amusing Southampton blog post describing a new Batman antihero, “the Modeller”, which I hadn’t seen before…

Challenges that he pointed out include the fact that modelling is hard, and that models have to gain recognition and consensus within a community before becoming useful. This fits in well with my recent emphasis on the processes supporting consensus in conceptual modelling, as a precursor to standardisation.

John Goodwin went into more detail about the Ordnance Survey’s “OpenData”, exposing for free the small-scale map geographical data of the country, though keeping the large-scale detail to sell. New to me. But some fascinating challenges came up for discussion. How does one relate, and keep track, of geographical entities that may both change their names, and have subtly different meanings in different contexts? “Hampshire” was used as an example (does it include the Isle of Wight, Bournemouth, or even Southampton?) Even more interestingly, he is looking at building up a vernacular gazetteer, for example to help emergency services locate places referred to by local people under the names they actually use.

The other co-sponsor of the event was punkt. netServices from Austria. Andreas Blumauer demonstrated their “PoolParty” system, which certainly looked clever enough, and includes a “corporate ontology” similar to the idea I was advocating for CETIS a while back, in connection with the topics that we have on our web site and blogs. Is it really that easy, I wondered?

The most esoteric presentation was reserved to the final spot. Bernard Vatant of Mondeca explained how there is more than the concept-centric SKOS to his ideal of linking data. Not just the Semantic Web, but the Semiotic Web… He would like to complement the representation of concepts with an explicit representation also of terms themselves. Give the terms their own URIs, make statements about them, don’t just include them as bare literals. Why exactly, I wondered, other than theoretical rigour, or the motive to include the discourse of semiotics (etc.)? If I had a few hours with him some time, I’d really like to bottom this out in conversation, partly to follow my bent towards relating to as many different conceptual starting points as I can.

The networking was valuable. As well as querying Nigel Shadbolt and Antoine Isaac, I caught up with some people I came across some time ago from Metataxis, asked some of the many BBC people there about skills and competences, and at least made one contact interested in linking personal data. (Colleagues are of course very welcome to ask me more while the memories are fresh.)

Ideally, to get a coherent and consistent set of domain tags, they need to be based on an agreed domain model. This could be a domain ontology, but what one calls it is less important than the reality of it being: (a) widely and commonly agreed; and (b) able to be put in a machine-processable form for use on the web – the Semantic Web in fact.

JISC could perhaps fund one or more projects, absolutely not, under any circumstances, to invent their own domain models or ontologies in isolation, but to explore what common ground there is in a particular domain, and to explore also the processes which can result in broadening the area of agreement in the domain model. A by-product of this would be an evaluation of the usefulness of the tools needed to facilitate broadening of consensus in the domain model. Here, graphical representations will be vitally central.