Prometheus-X Components & Services

Learning Object Metadata Crowd Tagging (LOMCT) BB – Design Document

Learning Object Metadata Crowd Tagging is a method for tagging and reviewing digital learning resources such as videos, courses, and documents using a crowd of individuals. The goal is to make these resources more discoverable and searchable by adding relevant keywords, descriptions, reviews and other useful metadata. This process is carried out via the combination of a browser (Chrome) extension and a Learning Record Store (LRS) that allows multiple users to submit review and metadata edit proposal of learning resources. All the reviews and metadata edit proposals are sent in xAPI format and stored in a LRS.

The LOMCT is a data service (browser extension) which facilitates the collection of feedback from teachers about LO (metadata, reviews). The LO index is a data source (LRS) for organizations which want to store metadata and reviews of LO submitted by their teachers or course designers.

Please note that the following visuals are intended as projections only. UX/UI work will be carried out later in the process. LOMCT1

Technical usage scenarios & Features

Key functionalities:

Value-added:

Features/main functionalities

Features:

Technical usage scenarios

Here is an example of how LOMCT is used by an university professor:

Here is an example of how LOMCT is used by an employee of company:

Requirements

Requirement ID Short description BB input format BB output format Any other constraints Verified by scenario Requirement type
BB-REQ_ID__1 LOMCT must request building block consent via the Prometheus-X Dataspace Connector API call API response      
BB-REQ_ID__1.1 Individuals must consent to the use of their data in LOMCT API call API response If the answer is no, the data cannot be used, nor transferred into or from the PLRS. If the answer is yer, the data can be used, and transferred into or from the PLRS. BB-SC-LOMCT-01 DEP
BB-REQ_ID__1.2 Consent must be asked and verified in less than 30s API call API response   BB-SC-LOMCT-02 PERF
BB-REQ_ID__2 LOMCT must request contracts from the building block consent via the Prometheus-X Dataspace Connector API call API response      
BB-REQ_ID__2.1 The LOMCT must check with the contract manager through the Dataspace connector if a contract for the corresponding organization exists API call API response If the answer is no, the data cannot be accessed, nor transferred into or from the PLRS. If the answer is yer, the data can be accessed, and transferred into or from the PLRS. BB-SC-LOMCT-03 DEP
BB-REQ_ID__2.2 Contract must be asked and verified in less than 30s API call API response   BB-SC-LOMCT-04 PERF
BB-REQ_ID__3 LOMCT must connect with BB Consent/contracts negotiating agent (EDGE-Skill)          
BB-REQ_ID__3.1 BB must send the individual’s consent profile when the LOMCT asks to adjust what and when they are tracked: all-time connection, only on weekends, certain keywords, etc. API call consent profile Request consent 1 time, then update if the profile is modified in the corresponding building bloc. Could be asynchronous BB-SC-LOMCT-05 DEP
BB-REQ_ID__3.2 BB must update the individual’s consent profile to LOMCT when there are changes consent profile / update if the profile is modified in the corresponding building bloc. Could be asynchronous BB-SC-LOMCT-06 DEP
BB-REQ_ID__4 LOMCT should connect with BB Data veracity assurance (EDGE-Skill) API call API response      
BB-REQ_ID__4.1 BB Data veracity assurance should check dataset is decent xAPI (DASES) dataset response   BB-SC-LOMCT-06 FUN
BB-REQ_ID__5 LOMCT should connect with BB EDGE translator (EDGE-Skill)          
BB-REQ_ID__5.1 expand the keywords of LOs call API xAPI   BB-SC-LOMCT-07 FUN
BB-REQ_ID__5.2 Exchange must be under 30s API call API response   BB-SC-LOMCT-08 PERF

Integrations

Direct Integrations with Other BBs

Interact with Edge translators

How?

Why?

Interact with consent/contract

Why?

Interact with Edge computing - AI training

How?

Why?

Interact with Data veracity assurance

How?

Why?

Integrations via Connector

Connection with connector

Why?

Connection with contract

Why?

What?

Connection with consent

Why?

What?

Connection with identity

Why?

What?

Relevant Standards

Data Format Standards

Data format:

Mapping to Data Space Reference Architecture Models


block-beta

columns 6
LearningObject:1 LOMCT:1 LRS:1 LRS_PDC:1

block:group1
columns 1
CC_PDC DVA_PDC ET_PDC EC_PDC
end

block:group2
columns 1
ConsentContracts DataVeracityAssurance EdgeTranslators EdgeComputing
end

classDef colorA fill:#D22FF7,color:#fff
classDef colorEx fill:#01D1D1,color:#fff
classDef colorED fill:#6E7176,color:#fff
class LearningObject colorEx
class LRS colorEx
class LOMCT colorED
class EdgeComputing colorED
class ConsentContracts colorED
class DataVeracityAssurance colorED
class EdgeTranslators colorED
class LRS_PDC colorA
class EC_PDC colorA
class CC_PDC colorA
class ET_PDC colorA
class DVA_PDC colorA

PDC : Prometheus-X Dataspace Connector

Input / Output Data

Input and output data are in the same format: xAPI.

Example 1: Review

A user want to write a review about this video:

https://www.youtube.com/watch?v=hLE-5ElGlPM

His review is:

Here is the corresponding xAPI statement:


{

"statement": {

"authority": {

"objectType": "Agent",

"name": "University A LOMCT",

"mbox": "mailto:contact@universitya.com"

},

"stored": "2024-03-11T14:17:43.686Z",

"context": {

"contextActivities": {

"parent": [

{

"id": "https://universitya.com/home",

"objectType": "Activity"

}

],

"category": [

{

"id": "https://w3id.org/xapi/dod-isd/verbs/categories/history",

"objectType": "Activity"

}

]

},

"language": "en"

},

"actor": {

"account": {

"homePage": "https://universitya.com/users",

"name": "123456789"

},

"objectType": "Agent"

},

"timestamp": "2024-03-11T14:17:32.814Z",

"version": "1.0.0",

"id": "8f5e30f6-312e-4ec6-bc60-a37bcb1811ec",

"verb": {

"id": "http://id.tincanapi.com/verb/reviewed",

"display": {

"en-US": "reviewed"

}

},

"object": {

"id": "https://www.youtube.com/watch?v=hLE-5ElGlPM",

"definition": {

"name": {

"en": "What is History for?"

},

"description": {

"en": "The fundamentals about History and why we need it."

},

"type": "http://activitystrea.ms/schema/1.0/video"

},

"objectType": "Activity"

},

"result": {

"score": {

"scaled": 1.0, // Representing a 5/5 score

"raw": 5,

"min": 0,

"max": 5

},

"response": "Fantastic video for every history student in the Bachelor of Medieval History."

}

}

}

Example 2: Metadata Edit Proposal

A user want to propose metadata edit about this video:

https://www.youtube.com/watch?v=hLE-5ElGlPM

His proposals are:

Here is the corresponding xAPI statement:


{

"statement": {

"authority": {

"objectType": "Agent",

"name": "University A LOMCT",

"mbox": "mailto:contact@universitya.com"

},

"stored": "2024-03-11T14:17:43.686Z",

"context": {

"extensions": {

"http://id.tincanapi.com/extension/bloom": "discover",

"http://id.tincanapi.com/extension/provider": "YouTube"

},

"contextActivities": {

"parent": [

{

"id": "https://universitya.com/home",

"objectType": "Activity"

}

],

"category": [

{

"id": "https://w3id.org/xapi/dod-isd/verbs/categories/history",

"objectType": "Activity"

}

]

},

"language": "en"

},

"actor": {

"account": {

"homePage": "https://universitya.com/users",

"name": "123456789"

},

"objectType": "Agent"

},

"timestamp": "2024-03-11T14:17:32.814Z",

"version": "1.0.0",

"id": "8f5e30f6-312e-4ec6-bc60-a37bcb1811ec",

"verb": {

"id": "https://w3id.org/xapi/dod-isd/verbs/proposed",

"display": {

"en-US": "proposed"

}

},

"object": {

"id": "https://www.youtube.com/watch?v=hLE-5ElGlPM",

"definition": {

"name": {

"en": "What is History for?"

},

"description": {

"en": "The fundamentals about History and why we need it."

},

"type": "http://activitystrea.ms/schema/1.0/video"

},

"objectType": "Activity"

}

}

}

Architecture

classDiagram
   LOMCT <|-- LRS
   LRS <|-- LRS_PDC
   LRS_PDC <|-- LRS
   LRS_PDC <|-- CC_PDC
   CC_PDC <|-- LRS_PDC
   CC_PDC <|-- Consent_Contracts
   Consent_Contracts <|-- CC_PDC
   LRS_PDC <|-- DVA_PDC
   DVA_PDC <|-- LRS_PDC
   DVA_PDC <|-- Data_veracity_assurance
   Data_veracity_assurance <|-- DVA_PDC
   LRS_PDC <|-- ET_PDC
   ET_PDC <|-- LRS_PDC
   ET_PDC <|-- EDGE_translator
   EDGE_translator <|-- ET_PDC
   class LRS_PDC{
     identity()
     catalog()
     contract()
     consent()
   }
   class CC_PDC{
     identity()
     catalog()
     contract()
     consent()
   }
   class DVA_PDC{
     identity()
     catalog()
     contract()
     consent()
   }
   class ET_PDC{
     identity()
     catalog()
     contract()
     consent()
   }
   class Consent_Contracts{
     bool week[7]
     int begin[7]
     int end[7]
     string trigger_keywords[]
     add_trigger_keyword(string)
     change_track()
   }
   class Data_veracity_assurance{
     bool decent
     metadata_decent()
   }
   class EDGE_translator{
     String lo_keywords[]
     add_lo_keyword()
   }

PDC : Prometheus-X Dataspace Connector

Dynamic Behaviour Behavior to display a resource :

sequenceDiagram
   actor User as User
   User->>LOMCT: Open LOMCT extension
   LOMCT->>LRS: Request LO metadata
   LRS->>LOMCT: Send LO metadata
   LOMCT->>User: Display the extension with metadata

PDC : Prometheus-X Dataspace Connector

Behavior to edit the metadata of a resource (the identification, consent and contract steps have already been completed when the extension is displayed) :

sequenceDiagram
   actor User as User
   User->>LOMCT: Select modification of resource metadata
   LOMCT->>User: Display editing form
   User->>LOMCT: Return the edition form
   LOMCT->>LOMCT: Convert edition form into xAPI
   LOMCT->>LRS: Send trace

Configuration and deployment settings

Deployment and installation:

Error scenarios defined

The idea of the risk table is to define the probable causes of failure in order to estimate the probability of encountering this failure, to evaluate its secondary effects and therefore to plan preventive or corrective actions.

We will assign 3 scores on a scale of 1 to 10 to potential failures:

Criticality is calculated as follows: criticality = detection x occurrence x severity

If criticality is greater than 10, then preventive action must be taken. If not, no. | ID | Function involved | Description of risk | Effect of failure | Cause of failure | Evaluation - Detection | Evaluation - Occurrence | Evaluation - Severity | Evaluation - Criticality | Preventive actions | | — | —————————————————————————————————— | ————————————————————— | —————————————————————————————————— | —————————————————————————————————- | ———————- | ———————– | ——————— | ———————— | ————————————————————————————————————————————————————————————– | | 1 | Submit metadata edit proposal and write a review of a Learning object (LO) by an individual | Data may be lost during migration | The organization doesn’t receive the complete statements about the reviews or the metadata edit proposals. | Incorrect connection between LOMCT and LRS | 2 | 2 | 7 | 28 | Set up recurring connection tests | | 3 | | Data could be transmitted to other non-targeted LRSs | Exported data may be accessible to unauthorized persons | They are not properly secured | 6 | 1 | 9 | 54 | Set up recurring connection tests
Test the cloud service’s scalability | | 4 | | The LRS doesn’t have enough storage space for all statements | No more statement import | Too little storage | 1 | 3 | 9 | 24 | Test the cloud service’s scalability
Can be connected to BB Data veracity assurance (EDGE-Skill) | | 5 | | The system may require downtime for large imports/exports | Disrupting normal operations | Low-performance servers | 1 | 3 | 4 | 12 | Test the cloud service’s scalability
Send statement to various LRS | | 6 | | User posts vulgar or insulting words | Unnecessary comment | Space for expression | 1 | 2 | 6 | 12 | Can be connected to BB Data veracity assurance (EDGE-Skill) | | 7 | | The user is linked to several schools | Connection required with several LRS | Implementation | 3 | 5 | 2 | 10 | Send statement to various LRS | | 8 | | Personal information is sent to LRS | Non-compliance with RGPD | Implementation | 4 | 2 | 9 | 54 | All these data are stored locally in the user browser/desktop. | | 9 | Visualize all metadata edit proposals and reviews associated to a LO | The user proposes a false edition | False metadata | Space for expression | 1 | 3 | 7 | 84 | A unique user id is used to distinguish users contributions from the admin statements, seen as the truth. | | 10 | | Metadatas don’t update | Poor visualization of the metadata | Slow update due to servers | 4 | 3 | 8 | 16 | The data proposed by the user is not posted as truthful but in a space that states that it is an editing proposal | | 11 | | Inadequate user interface | No use of the platform | UI design is misleading | 4 | 9 | 8 | 96 | Optimize extension | | 12 | | Wrong design choices: colors, shapes, … | No use of the platform | Visual choices such as colors and graphics can subliminally influence the perception of data. Graphs are non-inclusive | 1 | 7 | 5 | 96 | Conduct pre-development workshops to ascertain user requirements | | 13 | | Identical statements in the same or several LRS | Duplicated information | Several sources of LRS | 1 | 7 | 5 | 45 | Conduct pre-development workshops to ascertain user requirements and use accessibility tools | | 14 | | The user is linked to several organizations | Too much information on the front page, information conflict | Implementation | 1 | 7 | 5 | 35 | Only the most recent statement from the primary LRS is visible. | | 15 | | Several reviews from the same author are detected | Obsolete reviews visible | Implementation | 2 | 7 | 6 | 35 | All statements are displayed chronologically | | 16 | | Several metadata edit proposal from the same author are detected (simple user) | Metadata in several statements | Implementation | 2 | 7 | 6 | 84 | Display the organization’s most recent statement and ignore the others | | 17 | Submit metadata edit proposal and write a review of a Learning object (LO) by the organization | The organization may decide to change its LRS | Complication in determining the source of truth | Change of LRS | 1 | 2 | 1 | 2 | | | 18 | | The organization’s statements are not differentiated from others | Reconnecting the LOMCT and the new LRS | Implementation | 5 | 5 | 5 | 125 | Detect when username = authority.name it is organization. | | 19 | Other | Content Fragmentation | No valorization of the organization’s statements | The same LO is available on multiple sites and platforms with different URLs. | 1 | 7 | 5 | 35 | Assign a Global Unique Identifier (GUID) to each LO. |

Third Party Components & Licenses

External components and licenses:

OpenAPI Specification

In the future: link your OpenAPI spec here.


openapi: 3.0.0 \
info: \
     version: 0.0.1 \
     title: Learning object metadata crowd tagging \
   description: Learning Object Metadata Crowd Tagging is a service to easily review or tag digital learning resources such as videos, presentations, and documents by a crowd of individuals. The goal is to make these resources more discoverable and searchable by adding/changing relevant keywords, descriptions, and other metadata or by attaching them a review. Users interacts with this service using a browser extension. \
paths: \
     /list: \
          get: \
               description: Returns a list of stuff \
                    responses: \
                         '200': \
                              description: Successful response

Test specification

The Learning Object Metadata Crowd Tagging tests ensure that:

Test plan

The LOMCT testing strategy will focus on ensuring the accuracy, reliability, and performance of its functionality. We will use a combination of unit testing, integration testing, and user interface testing. The test environment will reproduce conditions similar to those in production in order to accurately validate BB behavior. Acceptance criteria will be defined based on user stories, functional requirements, and performance criteria.

Methodology

We will run manual tests.

Manual Scenario

Using the personas, user stories, user flow, and data flow from the Wiki LOM use case, we established several test scenarios.

Persona 1: mmegauss (1 LRS)

First time install with 1 LRS

Validation:

Persona 2: mcgonagall (2 LRS)

First time install with 2 LRSs

Validation:

Persona 3: the authority

First install of authority

Validation:

Test scenarios

Test scenario 1

mmegauss (persona 1) writes a review:

Validation:

Test scenario 2

mmegauss (persona 1) writes a review:

Validation:

Test scenario 3

mcgonagall (persona 2) writes a review:

Validation:

Test scenario 4

mmegauss (persona 1) submits a metadata edit proposal:

Validation:

Test scenario 5

mmegauss (persona 1) submits a metadata edit proposal:

Validation:

Test scenario 6

mcgonagall (persona 2) submits a metadata proposal:

Validation:

Test scenario 7

The authority (Persona 3) submits metadata edit proposals:

Validation:

Test scenario 8

mmegauss (persona 1) writes a review on a previously reviewed learning object:

Validation:

Test scenario 9

mcgonagall (persona 2) writes a review on a previously reviewed learning object:

Validation:

Test scenario 10

mmegauss (persona 1) submits several metadata edit proposals:

Validation:

UI test (where relevant)

Please note that the following visuals are intended as projections only. UX/UI work will be carried out later in the process.

LOMCT1 LOMCT1 LOMCT1

Partners & roles

Inokufu (BB leader):

edtake

Usage in the dataspace

The LOMCT will be used as a potential source of data for a LRS and thus be part of the service chains:

Diagram of service chain Sharing LMS/Moodle Data for Visualization PDC : Prometheus-X Dataspace Connector