Thoughts on IEEE ILR

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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.