A User-Model for a Next Generation Learning Management System

Introduction

Currently, learner data are highly distributed and duplicated: academic records are traditionally held by the respective institutions that the learner attended. Within those institutions, some data are in institution-wide databases, while other data are stored in particular learning platforms like course management systems, and frequently associated with particular courses. 

 

Leaners usually receive paper copies of their certified transcripts (showing earned course credits) and degrees, and they need to make photocopies or scans of those documents to transmit their credentials to other institutions or potential employers.  Not surprisingly, fraud abounds, particularly in an increasingly global education and work space. 

 

Learners leave behind a breadcrumb trail of educational data across platforms and institutions, over which they have very little control, and often they cannot even access it – the user lacks sovereignty. An alternative view would be to see the learner’s educational experience as one contiguous, lifelong journey, and that data gathered along the way gets added to one continuous transcript (“ledger”) of achievements, credits, certifications, and degrees.

 

Also along the way, learning analytics data builds up, which could enable learners to take better advantage of each station along their educational journey. While a perfect human tutor or mentor would accompany a learner over an extended amount of time and get to know him or her, the status quo is that any kind of AI-mentor would be rather scatter-brained and frequently suffering from memory-loss. 

 

The result of the status quo is a lack of verifiability, coherence, and personal, user-centric data sovereignty (“data self-sovereignty”) of educational data. The workshop will explore next generation user models to support migrant learners who move from educational experience to educational experience.

Players

The workshop will need to consider several players, some of which are listed here:

  • User: this is a lifelong learner, who carries his or her data from educational institution to educational institution, and who makes data selectively available to the other players.
  • Federated platform: federated systems in which users and content interact with each other as part of educational experiences.
  • Federated educational institution: a school, college, university, or training program, which would be member of some larger federation. On an administrative level, federation members acknowledge course credits and certifications (subject to mutually agreed-upon pairwise equivalency rules).  On a technical level, the federated institutions build on a common infrastructure.
  • External educational institution: an educational institution that is not federated, but which a user might want to apply to, and where a user might participate in educational experiences.
  • External stakeholder institution: a non-educational external organization as a “consumer” of educational data, for example a potential employer, a scholarship organization, or some other funding agency.
  • External stakeholder user: a person or system who contributes additional educational data or artefacts, such as letters of recommendation, internship evaluations, reviews, etc.
  • Service Providers: these may be external providers of data space, cloud providers running campus IT systems, etc. 

 

User Data

We will need to consider different kinds of education-relevant data, including:

  • Personal data: name, date-of-birth, basic demographics, student ID number or numbers (some countries have lifelong student IDs), etc. These data need to be disclosed or opened up in whole or in part to any other player that the user interacts with.
  • Certified transcript data: academic credentialling, for example course credits or degrees. Currently, these data need to be transferred between educational institutions, where “the next chapter” of the learner’s education is written (as evidenced by terms such as “transfer student” or “transfer credit”), but in principle, this is one continuous record of the learner’s accomplishments.
  • Transactional data: data routinely produced while interacting with learning platforms, which are potentially useful for personalization and guiding of learning, analytics, and content metrics. This is where the system “gets to know” the user.
  • Portfolio data: a collection of artefacts generated during educational experiences, such as presentations, posters, artwork, compositions, videos, CAD-files, etc., which may be useful for applying for admission to other educational institutions or employment. 
  • End-to-end confidential data: Letters of recommendation, reviews, and the like, which a user needs to hand over from the author to the recipient without him- or herself being able to see them or to switch them out.

 

 

All of these data will need agreed-upon data formats, which is going to be a challenge that is outside the scope of this workshop. It is clear, though, that these will need to be structured, clear-text data formats (which could be represented for example in JSON) with possible binary attachments (e.g., images, PDFs, etc.).

Transactions and Trust

A crucial ingredient in any new user model will be trust – during which transactions can we trust which play with which kind of data? A mantra will be “trust nobody”, and then to selectively establish who trusts whom for what. The workshop will construct necessary transaction scenarios and investigate which trust relationships are necessary to make them happen.

Technologies

There are some possibly enabling technologies, which we will consider – these will be used as examples of what is possible, not necessarily as the technologies of choice.

  • OpenID Connect: When dealing with different players, first of all their identities need to be verified. A highly promising technology is OpenID Connect, which builds on the popular OAuth.
  • SOLID: Social Linked Data (SOLID) is a concept of storing data with the user instead of the application or service, under the control of the user. The user gets to choose which data they release to which platforms, i.e., the user has self-sovereignty over his or her data.
  • Federated Blockchain: To establish trust, a key technology is that of a federated blockchain. Blockchains are usually associated with cryptocurrencies, energy-consuming Proofs-of-Work, and global entities like Ethereum, but none of that is needed here; likely, a federated blockchain, for example using Hyperledger Fabric, and simple Proof-of-Stake will do.
  • Machine Learning: in addition to being represented by their data pods, learners may also have AI-agents actively working within this new educational ecosystem, which provide learning support and recommendations, based on transactional data.

Workshop Program

The 4-hour workshop will be carried out in a hybrid format with English as working language to allow broad participation. We will use virtual collaboration tools, e.g., Miro, which will also be used to document the work products. On-site participants would need to bring their own laptops.


  • Hour 1

·      Introductory presentations, 3 in total, 20 minutes each – 60 min

  • Hour 2

·      Work session “Players” – breakout groups face-to-face and online; expanding, correcting, and refinement of “players” outlined above – 30 min

·      Work session “Data” – breakout groups face-to-face and online; expanding, correcting, and refinement of “data” outlined above – 30 min

  • Hour 3

·      Break – 10 min

·      Work session “Trust and Transactions” – breakout groups face-to-face and online; constructing transaction scenarios – 50 min

  • Hour 4

·      Reporting-out of breakout groups – 30 min

·      Closing Discussion – 30 min

Work products will be summarized based on the virtual collaboration tool content. They will be made available to workshop participants and added to the proceedings, if possible.