Tag Archives: Talent Signal

The confusing concepts of credentials and competences⤴

from @ Sharing and learning

Back in July and August the Talent Marketplace Signaling W3C Community Group made good progress on how to relate JobPostings to Educational and Occupational Credentials (qualifications, if you prefer) and Compentences. These seem to me to be central concepts for linking between the domain of training, education and learning and the domain of talent sourcing, employment and career progression; a common understanding of them would be key to people from one domain understanding signals from the other. I posted a sketch of how I saw these working,.. and that provoked a lot of discussion, some of which led me to evaluate what leads to misunderstandings when trying to discuss such concepts.

This post is my attempt to describe the source those misunderstandings and suggest that we try to avoid them. Finding clarity in talking about competences and credentials is certainly not “all my own work”. Jim Goodell, Alex Jackl and Stuart Sutton and many others in the Talent Signal group and beyond have all been instrumental navigating us through to what I hope will be a common understanding, documentation of which is currently being editted by Alex. This is, however, my own take on some of the factors feeding in to that discussion, I wouldn’t want to laden anyone else with any blame for what’s described below. Also, I have simplified some of the issues raised in the discussion, and for that reason do not want to suggest that they represent the views of specific people. If you want to look at who said what, it’s best you read it in their own words on the email list.

So what are the factors that make talking about competences and credentials difficult?


We might think that we know what a credential/qualification is: the University of Bristol offers a BSc in Physics; I have a BSc in physics from the University of Bristol–I could show you the website describing that qualification and a photo of my certificate. But they are not the same thing, there’s a difference between the abstract credential being offered and the specific certificate that I have, just as the story “Of Mice and Men” is not the same as the thing with the ISBN  978-0582461468, and the thing identified by that ISBN is not the physical copy of the book that I have on my shelf. We’re all familiar with distinguishing between abstract classes (think of Platonic archetypes) and specific instances and we’re pretty good at it, but let’s just acknowledge that it’s difficult. It is difficult to know what level of generality to give to the abstraction (or abstractions, it’s often not a simple as instance and class); it’s difficult to know the words that you can use to make clear which you’re talking about, and it’s easy to talk at cross-purposes by incorrectly assuming that we have made that clear.


Naming things is hard, especially abstract things. One way that we try to deal with this is to refer to things by relation to something more concrete (in our experience): thus we call programmes of study after the credential they lead to (“Jamie is doing an MA in Film Studies”), or we call parts of a course a skill “Phil  has completed 20 skills in Duolingo Greek”, or we refer to people after the credential they hold (“Google hires lots of PhDs”). This may help in narrow contexts: if all you ever talk about is programmes, courses and their components it doesn’t matter if you call them after credentials and skills; but when you start doing that when you talk to someone who usually only deals with credentials and skills then you’ll cause confusion.


Another way to deal with naming abstraction is to coin terms that have specific meanings in context. The only problem with this is that in the Talent Signal work the point is that we are trying to talk across contexts, and the odds are that the jargon used is either meaningless out of context or, worse, means something different. (This latter is especially likely if it is a metonym. Seriously, don’t do metonyms.)

different approaches

As I wrote while I was thinking about this, different technical modelling approaches talk about different things, specifically in RDF we refer to things in the outside world: a description of a person is about that person, the identifier used to say what it is about is the identifier of an instance who is an actual person. When building data objects we might create a class of Person and have instances of that class to describe individual people. So for RDF the instance of Person is out there in the world, for the data object modellers the instance of Person only exists in an information system. This matters if you want to get a copy of the instance. Of course the reality is that what is in the information system is a description of a person, and we have just hit metonymy again.

fallacy of the beard

Bearing all that in mind we can come up with a set of definitions for Compentences and Credentials (the abstract things), Competence and Credential Definitions (descriptions of generic competences and credentials that may exist in information systems or elsewhere), Competence Assertions and Credential Awards (associating instances of competences and credentials with other things).

One use of a credential award is to assert that an individual has acheived a certain competence, so is a credential just a competence assertion? Here we hit some of the issues raised in discussion: it was important to some people that institutions should be able to “offer competences” as distinct from “issuing credentials”. I would rephrase that as make Competence Assertions without there being a Credential Award. This seemed tied to the idea that a credential was related to a complete course or programme whereas a competence was related to a part of the course.

In RDF we make assertions, so is the statement <Phil> <hasAbility> <ShoelaceTying> a competency assertion? If so, what more (if anything) do you need to have a Credential Award? We seems agreed that a Credential is somewhat more substantial and more formal, but the problem with that is that it is a judgement based on graduations along a continuum, not a clear disinction. That’s not to say that credentials and competence assertions are not distinct. I am clean shaven. If don’t shave tomorrow I won’t have beard; if I don’t shave for one more day or another after that I still won’t have one; so at what point would I have a beard? How many days I have to go unshaven before my stubble becomes a beard is impossible to define, but that does not mean that beards don’t exist as distinct category.


I hope that if we acknoweldge and identify the right abstract concepts, recognise that people in different contexts will understand jargon differently and take different approaches to what they consider as important parts of a model, and avoid metonyms then I think we can make ourselves better understood.

The post The confusing concepts of credentials and competences appeared first on Sharing and learning.

Indiana Appathon Credential Data Learn and Build⤴

from @ Sharing and learning

This week I took part in the Credential Engine’s Indiana Appathon in Indianapolis. The Credential Engine is a registry of information about educational and occupational credentials (qualifications, if you prefer; or not, if you don’t) that can be earned, along with further information such as what they are useful for, what competencies a person would need in order to earn one and what opportunities exist to learn those competencies. Indiana is one state that is working with the Credential Engine to ensure that the credentials offered by all the state’s public higher education institutions are represented in the registry. About 70 people gathered in Indianapolis (a roughly equal split between Hoosiers and the rest of the US, plus a couple of Canadians and me) with the stated intentions of Learn and Build: learn about the data the Credential Engine has, how to add more and how to access what is there, and build ideas for apps that use that  data, showing what data was valuable and potentially highlighting gaps.

circles and lines representing entity-relationship domain modelsI was there as a consequence of my project work (supported by the Credential Engine) to represent Educational and Occupational Credentials in schema.org, with the aim of helping  people understand the benefits of putting credentials on to the open web. Cue my chance to reuse here my pictures of how schema.org can act as a cross-domain unifying schema for linked data and how different domains link together from Education to HR.

I’ve been involved in a few events where the idea is to try to get people together to learn/discuss/make, and I know it is really difficult to get the right balance between structure and flexibility. Too much pre-planned activity and delegates don’t get to do what they want, too little and they are left wondering what they should be doing. So I want to emphasize how hugely impressed I was with the event organization and facilitation: Laura Faulkner and colleagues at Credential Engine and Sonya Lopes and team at Learning Tapestry did a great job. Very cleverly they gave the event a headstart with webinars in advance to learn about the aims and technology of the credential engine, and then in Indianapolis we had a series of  activities. On day one these were: cycling through quick, informal presentations in small groups to find out about the available expertise; demos of existing apps that use data from the Credential Engine; small group discussions of personas to generate use cases; generating ideas for apps based on these. On day two we split into some ‘developer’ groups who worked to flesh out some of these ideas (while the ‘publisher’ group did something else, learnt more about publishing data into the Credential Engine, I think,–I wasn’t in that group), before the developer groups presented their ideas to people from the publisher group in a round-robin “speed-dating” session, and then finally to the whole group.

I went wanting to learn more about what data and connections would be of value in a bigger ecosystem around credentials and for the more focussed needs of individual apps. This I did. The one app that I was involved with most surfaced a need for the Credential Engine to be able to provide data about old, possibly discontinued credentials so that this information could be accessed by those wanting more details about a credential held by an individual. I think this is an important thing to learn for a project that has largely focussed on use cases relating to people wanting to develop their careers and look forward to what credentials are currently on offer that are relevant to their aspirations. I (and others I spoke to) also noticed how many of the use cases and apps required information about the competencies entailed in the credentials, quite often in detail that related to the component courses of longer programs of study. This, and other requirements for fine detail about credentials, is of concern to the institutions publishing information into the Credential Engine’s registry. Often do not have all of that information accessible in a centrally managed location, and when they do it is maybe not at the level of detail or in language  suitable for externally-facing applications.

This problem relating to institutions supplying data about courses was somewhat familiar to me. It seems entirely analogous to the experiences of the Jisc XCRI related programs (for example, projects on making the most of course data and later projects on managing course-related data). I would love to say that from those programs we now know how to provide this sort of data at scale and here’s the product that will do it.., but of course it’s not that simple. What we do have are briefings and advice explaining the problem and some of the approaches that have been taken and what were the benefits from these: for example, Ruth Drysdale’s overview Managing and sharing your course information and the more comprehensive guide Managing course information. My understanding from those projects is that they found benefits to institutions from a more coherent approach to their internal management of course data, and I hope that those supplying data to the Credential Engine might be encouraged by this. I also hope that the Credential Engine (or those around it who do funding) might think about how we could create apps and services that help institutions manage their course data better in such a way that benefits their own staff and incidentally provides the data the Credential Engine needs.

Finally, it was great to spend a couple of days in sunny Indianapolis, catching up with old friends, meeting in-person with some colleagues who I have only previously met online and doing some sightseeing. Many thanks to the Credential Engine for their financial assistance in getting me there.

Photo of brick build building next to corporate towers
Aspects of Inidianapolis reminded me of SimCity 2000
White column with statues
Monument in centre of town
plan of a city grid for Inianapolis
The original city design plan (plat)
Photo of indoor market
One of the indoor markets
Fountain and war memorial
The sign said no loitering, but I loitered. That, in the background, is one of the biggest war memorials I have seen


The post Indiana Appathon Credential Data Learn and Build appeared first on Sharing and learning.

Inclusion of Educational and Occupational Credentials in schema.org⤴

from @ Sharing and learning

The new terms developed by the EOCred community group that I chaired were added to the pending area in the April 2019 release of schema.org. This marks a natural endpoint for this round of the community group’s work. You can see most of the outcome  under EducationalOccupationalCredential. As it says, these terms are now “proposed for full integration into Schema.org, pending implementation feedback and adoption from applications and websites”. I am pretty pleased with this outcome.

Please use these terms widely where you wish to meet the use cases outlined in the previous post, and feel free to use the EOCred group to discuss any issues that arise from implementation and adoption.

My own attention is moving on the Talent Marketplace Signalling community group which is just kicking off (as well as continuing with LRMI and some discussions around Courses that I am having). One early outcome for me from this is a picture of how I see Talent Signalling requiring all these linked together:

Outline sketch of the Talent Signaling domain, with many items omitted for clarity. Mostly but not entirely based on things already in schema.org


The post Inclusion of Educational and Occupational Credentials in schema.org appeared first on Sharing and learning.

Talent marketplace signalling and schema.org JobPostings⤴

from @ Sharing and learning

For some time now I have been involved in the Data Working Group of the Jobs Data Exchange (JDX) project. That project aims to help employers and technology partners better describe their job positions and hiring requirements in a machine readable format. This will allow employers to send clearer signals to individuals, recruitment, educational and training organizations about the skills and qualifications that are in demand.  The data model behind JDX, which has been developed largely by Stuart Sutton working with representatives from the HR Open Standards body, leverages schema.org terms where possible. Through the development of this data model, as well as from other input, we have many ideas for guidance on, and improvements to the schema.org JobPosting schema. In order to advance those ideas through a broader community and feed them back to schema.org, we have now created the Talent Marketplace Signaling W3C Community Group.

In the long term I hope that the better expression of job requirements in the same framework as can be used to describe qualifications and educational courses will lead to better understanding and analysis of what is required and provided where, and to improvements in educational and occupational prospects for individuals.circles and lines representing entity-relationship domain models


About the Talent Marketplace Signaling Community Group

Currently, workforce signaling sits at the intersection of a number of existing schema.org types: Course, JobPosting, Occupation, Organization, Person and the proposed EducationalOccupationalCredential. The TalentSignal Community Group will focus initially on the JobPosting Schema and related types. I think the TalentSignal CG can help by:

  • providing guidance on how to use existing schema.org terms to describe JobPostings;
  • proposing refinements (e.g. improved definitions) to existing schema.org types serving the talent pipeline; and
  • suggesting new types and properties where improved signaling cannot otherwise be achieved.

I hope that the outcomes of this work will be discrete improvements to the JobPostings schema, e.g. small changes to definitions, changes to how things like competences are represented and linked to JobPostings, and guidance, probably on the schema.org wiki, about using the JobPosting schema to mark up job adverts. Of course, whatever the Community Group suggests, it’s up to the schema.org steering group to decide on whether they are adopted into schema.org, and then it’s up to the search engines and other data consumers as to whether they make any use of the mark up.

The thinking behind the having a wider remit than the currently envisaged work is to avoid setting up a whole series of new groups every time we have a new idea [lesson learnt from moving from LRMI to Course description to educational and occupational credentials].

Call for participation

If you’ve read this far you must be somewhat interested  in this area of work, so why not join the TMS Community Group to show your support for the JDX and more broadly the need and importance for improved workforce signaling in the talent marketplace? You can join via pink/tan button on the Talent Signal CG web page. You will need to have a W3C account and to be signed in order to join (see the top right of the page to sign-in or join). The only restriction on joining is that you must give some assurances about the openness of the IPR of any contributions that you make. The outcomes of this work will feed into a specification that anyone can use, so there must be no hidden IPR restrictions in there.

The group  is open to all stakeholders so please feel free to share this information with your colleagues and network.


I’m being paid by the US Chambers of Commerce Federation to carry out this work. Thank you US CCF!

The post Talent marketplace signalling and schema.org JobPostings appeared first on Sharing and learning.