In this page, the user flow related to three main functionalities of the Training Catalogue will be presented.

To illustrate the user flows, a narrative description of each use case will be specified. In particular, the description of the scenario will include: the name of the use case; the involved actor(s); the detailed description; what happens in case of successful completion (the default scenario) broken down into steps that illustrate the interaction between the actor(s) and the system; the potential alternatives; the list of pre and post conditions necessary for the scenario completion; the list of potential assumptions.

Functional Specification 3.1 - Definition and management of a metadata set for Learning Resources, courses and/or curricula.

  • Use case: definition and management of the metadata set for learning resources.
  • Actor: administrator.
  • Description: the administrator defines and manages the metadata schema by using the GUI with the possibility to configure all aspects (title, tooltip, data type, accepted values, if it is multi-value, if it is optional/mandatory, etc.).
  • Successful completion:
  1. The administrator, starting from the list of the already identified metadata fields (see Appendix 1), defines and manages the structure of the metadata set by specifying all the required information (title, tooltip, data type, accepted values, if it is multi-value, if it is optional/mandatory, etc.).
  2. The system validates the input for any errors in data entry.
  3. The system approves the metadata set submission and the metadata set is correctly updated.
  • Alternative: The system rejects the metadata set submission, citing all the potential errors.
  • Pre-condition: The administrator has to be logged in and has to have the admin role in order to define and manage the metadata schema.
  • Post-condition: The administrator receives a success message.
  • Assumptions: None.


Figure 1. User flow: Definition and management of a metadata set for Learning Resources, courses and/or curricula.


Functional Specification 4 - Aggregation mechanism (automatic harvesting)

  • Use case: aggregation mechanism (automatic harvesting).
  • Actor: administrator.
  • Description: the administrator manages the list of harvested sources by using the GUI with the possibility to configure and set the different fields (node name, authoring info, protocol to be used, URL – endpoint of the node, possible search filters to be used during the harvesting, privileges for harvested records, possible validation to be performed before importing, possible transformation to be applied after the record import, etc.)
  • Successful completion:
  1. The administrator creates a new harvesting source (or updates an existing harvesting source) by specifying all the mandatory fields.
  2. The system performs a quick test by harvesting maximum 10 records that follow the information/criteria provided by the administrator (validation procedure).
  3. The system approves the new harvesting source (or the updated harvesting source) and adds it to the list of available sources.
  4. The administrator can decide to perform a manual harvesting (only after clicking on a specific button the harvesting procedure for a specific node is run) or to schedule it with a given frequency and at a given time (in order to automatically gather new and updated metadata records about training resources).
  • Alternatives:
    • If the system rejects the newly created/updated harvesting source, the validation procedure fails and the list of encountered errors is provided.
    • If no records are found with the information provided by the administrator, the system notifies “0 records found”.
  • Pre-condition: The administrator has to be logged in and has to have the admin role in order to manage the harvesting sources.
  • Post-conditions:
    • The administrator receives a success message after the test and can continue with the setting.
    • The (manual/scheduled) harvesting is performed and a report is generated/updated by the system that includes the main info of the source, the date of the run, and the corresponding harvested record. The user can download the report (export in CSV, PDF, etc.)
    • The system is correctly synchronized with the list of the harvesting sources.
  • Assumptions:
    • The list of harvested sources comes from the list of validated providers that have followed the onboarding rules (See Chapter 4 Alignment with the EOSC Rules of Participation and EOSC Marketplace).
    • According to the source metadata application profile, an ad-hoc transformation that allows to perform the mapping should be implemented.


Figure 2. User flow: Aggregation mechanism (automatic harvesting)

Functional Specification 7.1 - Manual content creation

  • Use case: manual creation of training metadata record.
  • Actor: EOSC provider.
  • Description: the EOSC providers that do not have a training catalogue to perform the automatic harvesting of the training resources can create new metadata records in a manual fashion. The metadata fields included and listed in the metadata editor of the Training Catalogue will be combined with appropriate tooltips in order to provide examples and guidelines for correct data entry. The created metadata records will be subject to a validation procedure before being published and discoverable within the EOSC Training Catalogue.
  • Successful completion:
  1. The provider creates a new training metadata record (or updates an existing metadata record) by specifying at least the mandatory metadata fields.
  2. The system validates the submission and approves in case of zero errors.
  3. The metadata record is added as draft in the Catalogue.

  4. The administrator contacts the reviewer(s) to revise the content. 

  • Alternatives:
    • If the system rejects the newly created/updated metadata record, the validation procedure fails and the list of encountered errors is provided.
    • If the review is not positive, the validation procedure fails and the list of encountered errors is provided. 
  • Pre-condition: The provider has to be logged in and has to have the editor role in order to manage the metadata records related to the training resources that she/he provided.
  • Post-conditions:
    • The provider receives a success message after the record submission.
    • The provider is notified about the successful review. 
    • The metadata record is added to the list of available and discoverable training resources.
  • Assumptions: None.


Figure 3. User flow: Manual content creation.


  • No labels