Tag Archives: Credentials

PESC Transcript in JSON-LD⤴

from @ Sharing and learning

I was (virtually) at the PESC 2023 Data Summit recently, presenting on a panel about Re-Engineering the “All-Or-Nothing” Academic Transcript to Reveal Its Unequivocal Value. This post is based on that presentation. It sets out the journey of a working group that I have been on, taking an XML record-based approach to detailing a student’s progress through education and turning it into JSON-LD. My input has been to focus on the Linked Data / RDF standards aspects of that. I should note that initially the project was about a transition to JSON, the emphasis on Linked Data and the model we’re adopting dropped out of our discussions about what we wanted to achieve and what various models enabled. We didn’t start with this solution in mind and try to jemmy it in. I think that’s important.

What we started with

We started with the PESC transcript in XML, and translated this to JSON.  XML gives you records with nested elements with meaning that depends on their parent & sibling elements. The image below is incomplete and very simplified and I have taken some liberties to make it presentable, but it gets the idea across.Nested boxes of information, like a form. The outer box is College Transcript. Within that are boxes for Transmission data and Student, each containing further boxes.

Presented like this you can see how the nested structure is kind of reassuringly similar to a printed transcript. Take note of how in the bottom right the information under “course” mixes information that is true of the course that everyone took (Course Number, Name) and information that is specific to the person whose details are provided nested in the same Student element. In reality the Course Number and Name have nothing to do with the Student.

JSON can be similar, but for Linked Data–as in JSON-LD–you no longer have a “record” paradigm, you have sets of statements about different things and the statements describe the characteristics of those things and the relationships between them.

The first cut

We took a first trip through the data model, focusing what were the different things being described and how did they relate to each other. The image below illustrates (again a very simple) example of what we came up with.

This usefully shows that there are some things that “belong” to the transcript, some things that are about a Person and what they have done, and some things that are about an Organization (e.g. a College) and what they offer (Courses).

But, when you look at real world examples, it was actually a bit of a mess: the relationships were more about where you find things on a printed transcript than what makes sense as relationships between the things being described. Look how you go from AcadmicSummary to Academic Session to Academic Achievement to Course.

Where we are now

We started thinking of a transcript as a record of a person’s various types of achievements in programs/courses/sessions/etc offered by an organization. That looks like this.

It looks a little less simplified, but it’s showing two achievements.

See how there is a split between the personal private information (yellow and blue boxes on the middle left) and the corporate public data (pink boxes on right and at the top) typically found in a Course Catalogue or similar, the type of information that could be made available as linked data through the Credential Engine Registry (other registries could exist, but Credential Engine pay me)

What if there were no need to generate the corporate data just for the transcript because it could be reused (either by repeating it in the transcript data or just linking to it.)

One final thought on the data structure. The heart of this view of the transcript is a series of assertions that an organization issues saying that a person has achieved something. These are represented by the Person-Achievement-College boxes running diagonally from botton left to the to right. This is the same core as a W3C Verifiable Credential, and the transcript is the same structure as a Verifiable Presentation. What if the data structure of the transcript were the same as that of a Verifiable Presentation? That is the approach taken by other similar standards, such as the European Learner Model and 1EdTech’s Comprehensive Learner Record. Having a common data model (even without going the whole way into including signed VCs in the transcript) will surely be helpful. If it is compatible with having a transcript made up of VCs, then so much the better, but we shall continue to follow the use cases to find a solution, not the other way round.



The post PESC Transcript in JSON-LD appeared first on Sharing and learning.

What am I doing here? 1. Credential Engine⤴

from @ Sharing and learning

January seems like a good time to review the work that I am doing at the moment. Rather than try all of it in one post, I’ll take it one project at a time. This one is about my work with Credential Engine, a US-based not for profit that aims to provide information about educational and occupational credentials on offer and the things related to them. The aim is to empower learners with the information they need to make decisions about their educational options.

(Note, I think of educational / occupational credential as synonymous with qualification, and tend to use credential as a shorthand for that.)

About the work

I provide consultancy to Credential Engine on their RDF vocabulary, CTDL, the Credential Transparency Description Language. I’ve been associated with CTDL for longer than the Credential Engine has been around: I was on the technical advisory committee for the precursor project, CTI, the Credential Transparency Initiative, seven years ago.

[Aside, fun fact: the first job I had in learning technology was in another CTI, the Computers in Teaching Initiative. Yes this was a factor in my agreeing to serve on the advisory committee.]

The CTDL is key to Credential Engine’s mission to make credentials more transparent by providing more information about how to obtain them, for example who offers them, what competencies (knowledge, skills, attributes) are necessary to earn them, how are these competencies assessed, what opportunities are available to learn them, and what are the likely outcomes (in terms of things such as employability and salary) of possessing the credential. As such CTDL describes a lot more than just the bare details of a credential, it goes far beyond into organizations, competencies, learning opportunities and outcomes data. In fact, by CTDL we actually mean three related vocabularies:

  • CTDL, itself which covers the core of credentials, courses, pathways, organizations;
  • CTDL-ASN, an extension of the vocabulary for competency frameworks and related entities developed for the Achievement Standards Network;
  • QDATA, for quantitative data about outcomes.

As well as the bare vocabulary definitions we also provide a Handbook with sections for each of the vocabularies, covering how the terms are designed to be used to meet various use cases.

About my role

My first contract with Credential Engine was to set up and lead the EOCred W3C Community Group to improve and extend Schema.org’s capability to describe educational and occupational credentials. CTDL was created following the same model as schema.org, and Credential Engine were keen to keep the two languages harmonized. The outcome of that project was the schema.org EducationalOccupationalCredential class and related terms, and some documentation from the working group about the how to address the use cases we identified.

More recently I have been working more closely with the core Credential Registry team on developing CTDL. They have well-established policies and procedures  for updates, which include setting up open working groups to “socialize” major proposals. While I have been working with them we have produced major updates to address Credit Transfer, Education to Work relationships, Educational Pathways, Scheduling Patterns, Approval Lists, as well as many minor tweaks on an almost monthly basis. Coming soon: assessment rubrics.

One of the things that I really appreciate about the Credential Engine work is that it gives me the freedom (or lets me take the liberty) to explore new RDF-related technologies that might benefit CTDL. The best example of this is how I have been able to build some working knowledge of SHACL as part of our thinking on how we express the CTDL data model and applications profiles of it in such a way that data can be validated. This has helped me justify my (otherwise unfunded) contribution to the Dublin Core Tabular Application Profile work. Other examples come from wanting to make sure CTDL is used as widely as possible, include contributing to the W3C Verifiable Credentials for Education community group, PESC’s work on transcripts and ETF training events on linked data.

Best of all, Credential Engine have a great team, it’s a pleasure to work with them.

The post What am I doing here? 1. Credential Engine appeared first on Sharing and learning.

Thoughts on IEEE ILR⤴

from @ Sharing and learning

I was invited to present as part of a panel for a meeting of the  IEEE P 1484.2 Integrated Learner Records (ILR) working group discussing issues around the “payload” of an ILR, i.e. the description of what someone has achieved. For context I followed Kerri Lemoie who presented on the work happening in the W3C VC-Ed Task Force on Modeling Educational Verifiable Credentials, which is currently the preferred approach. Here’s what I said:

My interest in ILR comes through working with the Credential Engine on the Credential Transparency Description Language (CTDL) family of RDF vocabularies for describing educational credentials (qualifications) and many of the things like competences, assessments, learning opportunities, and education organizations, that are related to them. My relevant areas of expertise are interoperability, RDF data models and education data standards.

The areas I would like us to consider as we go forward are related to issues of scope, issues of maturity and technical issues. 

Issues of scope: we know the W3C VC approach (i.e. cryptographically signed assertions in JSON-LD) has certain desirable characteristics, but in previous calls we have heard of extensive, mature practice regarding learner records that does not make use of such an approach. Are these in scope? What is the use case for the VC approach that they might need?

Issues of maturity and velocity: Verifiable Credentials is relatively new W3C recommendation; the work of the W3C VC-Edu group looking at how it can be applied to education is ongoing (it’s progressing well, being very well led by Kim Hamilton Duffy and Anthony Camilleri, but I hope I do not offend anyone if I say it is not near a conclusion). There are few implementations of VCs in the education domain, and these are ongoing projects (progressing well but not conclusive). It is hard to recommend anything as best practice until you have evaluated the consequences of several options. We need to be especially careful when we say what “should” be done that we do not, by implication, say that the mature, tried, tested and working approaches (that I alluded to above) are somehow less good, as somehow doing something that shouldn’t be done.

Technical issues: cryptographically signed assertions in JSON-LD. JSON-LD is a form of Linked Data, the @context block provides a mapping to an RDF model. Therefore there has to be an RDF model. 

You have to anticipate people taking the JSON-LD and using it as RDF, i.e. as a series of independent statements: triples in the form subject-predicate-object. This has implications because some things that work when you treat properties as “elements” embedded in an XML tree or as “fields” in a record do not work for predicates that link a subject to an object that is an independent entity: the data about the object should not assume any “context” from the subject that is linked to it. 

There is also the question of how far does the RDF model go into describing the payload: W3C VC provides the mechanism for verifiable credentials in JSON-LD, but we are talking about educational credentials as being the payload — this is confusing to many people. Not every credential issuing organization will be adopting VC as their credentialing approach — other approaches are still valid (PESC Transcripts, IMS CLR, secured PDFs with or without XMP metadata) — so we have to allow for credentials that are “opaque to RDF” (though not to verification) in the “payload”. I’m looking for a balance that exploits the advantages of RDF approaches to describing credentials (like CTDL) while still being capable of providing value to those who don’t use RDF.

The post Thoughts on IEEE ILR appeared first on Sharing and learning.

New work with the Credential Engine⤴

from @ Sharing and learning

Credential Engine logoI am delighted to be starting a new consulting project through Cetis LLP with the Credential Engine, helping them make credentials more transparent in order to empower everyone to make more informed decisions about credentials and their value. The problem that the Credential Engine sets out to solve is that there are (at the last count) over 730,000 different credentials on offer in the US alone. [Aside: let me translate ‘credential’ before going any further; in this context we mean what in Europe we call an educational qualification, from school certificates through to degrees, including trade and vocational qualifications and microcredentials.] For many of these credentials it is difficult to know their value in terms of who recognises them, the competences that they certify, and the occupations they are relevant for. This problem is especially acute in the relatively deregulated US, but it is also an issue when we have learner and worker mobility and need to recognise credentials from all over the world.

The Credential Engine sets out to alleviate this problem by making the credentials more transparent through a Credential Registry. The registry holds linked data descriptions of credentials being offered, using the Credential Transparency Description Language, CTDL, which is based largely on schema.org. (Note that neither the registry nor CTDL deals with information relating to whether an individual holds any credential.) These descriptions include links to Competence Frameworks described in the Credential Engine’s profile of the Achievement Standards Network vocabulary, CTDL-ASN. The registry powers a customizable Credential Finder service as well as providing a linked data platform and an API for partners to develop their own services–there are presentations about some example thrid-party apps on the Credential Engine website.

I have been involved with the Credential Engine since the end of 2015, when it was the Credential Transparency Initiative, and have since worked with them to strengthen the links between the CTDL and schema.org by leading a W3C Community Group to add EducationalOccupationalCredentials ot schema.org. I’ve also helped represent them at a UNESCO World Reference Level expert group meeting, helped partners interested in using data from the registry at an appathon in Indianapolis.  I have come to appreciate that there is a great team behind the Credential Engine, and I am really looking forward to continuing to work with them. I hope to post regular updates here on the new work as we progress.

There are strong linkages between this work and the other main project I have on talent marketplace signalling, and with talent pipeline management in general; and also with other areas of interest such as course description  and with work of the rest of Cetis in curriculum analytics and competency data standards. This new project isn’t exclusive so I will continue to work in those areas.  Please get in touch if you would like to know more about partnering with the Credential Engine or are interested in the wider work.

The post New work with the Credential Engine appeared first on Sharing and learning.

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.

Progress report for Educational and Occupational Credentials in schema.org⤴

from @ Sharing and learning

[This is cross-posted from the Educational and Occupational Credentials in schema.org W3C community group, if you interested please direct your comments there.]

Over the past few months we have been working systematically through the 30-or-so outline use cases for describing Educational and Occupational Credentials in schema.org, suggesting how they can be met with existing schema.org terms, or failing that working on proposals for new terms to add. Here I want to summarize the progress against these use cases, inviting review of our solutions and closure of any outstanding issues.

Use cases enabled

The list below summarizes information from the community group wiki for those use cases that we have addressed, with links to the outline use case description, the wiki page showing how we met the requirements arising from that use case, and proposed new terms on a test instance of schema.org (may be slow to load). I tried to be inclusive / exhaustive in what I have called out as an issue.

1.1 Identify subtypes of credential

1.2 Name search for credential

1.3 Identify the educational level of a credential

1.4 Desired/required competencies

1.6 Name search for credentialing organization

1.8 Labor market value

1.11 Recognize current competencies

1.13 Language of Credential

2.1 Coverage

2.2 Quality assurance

2.5 Renewal/maintenance requirements

2.6 Cost

3.1 Find related courses, assessments or learning materials

3.3 Relate credentials to competencies

3.4 Find credentialing organization

4.2 Compare credentials

  • Credentials can be compared in terms of any of the factors above, notably cost, compentencies required, recognition and validity.

4.3 Build directories

1.5 Industry and occupation analysis

1.7 Career and education goal

1.10 Job vacancy

3.2 Job seeking

Use cases that have been ‘parked’

The following use cases have not been addressed; either they were identified as low priority or there was insufficient consensus as to how to enable them:

1.9 Assessment (see issue 5, no way to represent assessments in schema.org)

1.12 Transfer value: recognizing current credentials (a complex issue, relating to “stackable” credentials, recognition, and learning pathways)

2.3 Onward transfer value (as previous)

2.4 Eligibility requirements (discussed, but no consensus)

3.5 Find a service to verify a credential (not discussed, low priority)

4.1 Awarding a Credential to a Person  (not discussed, solution may be related to personal self-promotion)

4.4 Personal Self-promotion (pending discussion)

4.5 Replace and retire credentials (not discussed, low priority)

Summary of issues

As well as the unaddressed use cases above, there are some caveats about the way other use cases have been addressed. I have tried to be inclusive / exhaustive in what I have called out as an issue,–I hope many of them can be acknowledged and left for future contributions to schema.org, we just need to clarify that they have been.

  • Issue 1: whether EducationalOccupationalCredential is a subtype of CreativeWork or Intangible.
  • Issue 2: competenceRequired only addresses the simplest case of individual required competencies.
  • Issue 3: whether accreditation is a form of recognition.
  • Issue 4: the actual renewal / maintenance requirements aren’t specified.
  • Issue 5: there is no way represent Assessments in schema.org
  • Issue 6: there is no explicit guidance on how to show required learning materials for a Course in schema.org.

There is an issues page on the wiki for tracking progress in disposing of these issues.

Summary of proposed changes to schema.org

Many of the use cases were addressed using terms that already exist in schema.org. The changes we currently propose are

Addition of a new type EducationalOccupationalCredential

Addition of four properties with domain EducationalOccupationalCredential:

Addition of EducationalOccupationalCredential to the domain of two existing properties (with changes to their definition to reflect this):

Addition of EducationalOccupationalCredential to the range of three existing properties:

The post Progress report for Educational and Occupational Credentials in schema.org appeared first on Sharing and learning.

Educational and occupational credentials in schema.org⤴

from @ Sharing and learning

Since the summer I have been working with the Credential Engine, which is based at Southern Illinois University, Carbondale, on a project to facilitate the description of educational and occupational credentials in schema.org. We have just reached the milestone of setting up a W3C Community Group to carry out that work.  If you would like to contribute to the work of the group (or even just lurk and follow what we do) please join it.

Educational and occupational credentials

By educational and occupational credentials I mean diplomas, academic degrees, certifications, qualifications, badges, etc., that a person can obtain by passing some test or examination of their abilities. (See also the Connecting Credentials project’s glossary of credentialing terms.)  These are already alluded to in some schema.org properties that are pending, for example an Occupation or JobPosting’s qualification or a Course’s educationalCredentialAwarded. These illustrate how educational and occupational credentials are useful for linking career aspirations with discovery of educational opportunities. The other entity type to which educational and occupational credentials link is Competence, i.e. the skills, knowledge and abilities that the credential attests. We have been discussing some work on how to describe competences with schema.org in recent LRMI meetings, more on that later.

Not surprisingly there is already a large amount of relevant work done in the area of educational and occupational credentials. The Credential Engine has developed the Credential Transparency Description Language (CTDL) which has a lot of detail, albeit with a US focus and far more detail that would be appropriate for schema.org. The Badge Alliance has a model for open badges metadata that is applicable more generally. There is a W3C Verifiable Claims working group which is looking at credentials more widely, and the claim to hold one. Also, there are many frameworks which describe credentials in terms of the level and extent of the knowledge and competencies they attest, in the US Connecting Credentials cover this domain, while in the EU there are many national qualification frameworks and a Framework for Qualifications of the European Higher Education Area.

Potential issues

One potential issue is collision with existing work. We’ll have to make sure that we know where the work of the educational and occupational credential working group ends, i.e what work would best be left to those other initiatives, and how we can link to the products of their work. Related to that is scope creep. I don’t want to get involved in describing credentials more widely, e.g. issues of identification, authentication, authorization; hence the rather verbose formula of ‘educational and occupational credential. That formula also encapsulates another issue, a tension I sense between the educational world and the work place: does a degree certificate qualify someone to do anything, or does it just relate to knowledge?  Is an exam certificate a qualification?

The planned approach

I plan to approach this work in the same way that the schema course extension community group worked. We’ll use brief outline use cases to define the scope, and from these define a set of requirements, i.e. what we need to describe in order to facilitate the discovery of educational and occupational credentials. We’ll work through these to define how to encode the information with existing schema.org terms, or if necessary, propose new terms. While doing this we’ll use a set of examples to provide evidence that the information required is actually available from existing credentialling organizations.

Get involved

If you want to help with this, please join the community group. You’ll need a W3C account, and you’ll need to sign an assurance that you are not contributing any intellectual property that cannot be openly and freely licensed.

The post Educational and occupational credentials in schema.org appeared first on Sharing and learning.