The Minimal Metadata for Learning Resources presented on this page was a result of a first discussions about the metadata set to be used for the training catalogue started from the definition of the overall approach that the project intended to design for the EOSC Catalogue. At a later stage it was adapted to the EOSC Portal Profiles, resulting in the definition of the EOSC Training Resource Profile Data Model, which will be considered for the onboarding of Learning Resourses in the EOSC catalogue. Please consider the EOSC Training Resource Profile Data Model as the final version of the metadata set for Learning Resourses to be onboarded in EOSC Catalogue. |
|---|
The discussions about the metadata set to be used for the training catalogue started from the definition of the overall approach that the project intended to design for the EOSC Catalogue. In this sense, three elements were taken into strong consideration: the objective of establishing the EOSC Catalogue as a reference point and an aggregator of all existing catalogues; the intent to combine and develop resources in a way that could generate an added value in the form of learning paths; and the focus on providing end users with the all relevant information while at the same time favoring training resources onboarding making the process as smooth as possible for training resources providers.
The combination of these three elements made evident the need to find a balance between the list of mandatory fields requested to providers to onboard resources; the need to ensure the highest quality standards possible for the resources included in the EOSC catalogue and the possibility to generate value services; and the minimal information to provide to end users for proper selection of learning resources. And this balance therefore called for a level of flexibility in the chosen metadata set, especially concerning the mandatory fields for onboarding.
The reflections on the metadata set started from the solid basis created by the work of RDA Group. The RDA minimal metadata set - considered the most relevant set currently available - was then taken as an initial reference and an EOSC-customized version of that set was created. This set is included at the end of this page (Table 3).
However, this EOSC-customized set soon appeared not to address in full the concerns highlighted above. In particular, it proved to be quite restrictive with regard to the onboarding of existing resources, that often do not include all the fields listed in the RDA metadata set. A series of meetings with the identified Pilot Catalogues (ELIXIR TeSS, SSH Training Discovery Toolkit, DARIAH Campus, EOSC-Pillar) were therefore organized to validate the initial metadata set and compare the solutions adopted by various projects.
The reflections generated after these meetings led to the definition of two different metadata sets that provide for two different lists of requested mandatory fields: the first one aimed at the aggregation of existing resources (Table 1) and the second one for the registration of new resources (Table 2). The different lists of mandatory fields identified in these two tables reflects all the considerations and discussions held in the design phase and seems to be the best solution in order to address the three crucial elements identified as part of the overall EOSC Catalogue approach.
The metadata set for existing resources (Table 1) includes a very limited number of mandatory fields in favor of recommended fields. In this case, the training resources providers will be informed via alert messages that not providing info for the recommended fields will result in a limited re-usability of their resources. This should encourage providers to curate their resources in order to ensure their full use while at the same time not prevent those resources from being onboarded in the EOSC Catalogue.
Note: In this phase, two issues will have to be carefully addressed: properly communicating the meaning of "recommended" metadata fields and the consequences of missing information; internal curation of resources in order to ensure potential re-use once onboarded.
The metadata set for new resources (Table 2) follows the same approach of mandatory vs. recommended fields (with alert messages) but includes a much wider list of mandatory fields that matches almost entirely the list fo mandatory fields that is defined by the RDA group.
It is hoped that, with the time, more and more training resources providers will embrace the RDA approach for a complete list of mandatory fields therefore contributing to progressively provide fully detailed training resources.
Table 1. Metadata Set for Existing Resources (for the first harvesting process)
Metadata Field | Mandatory | Recommended (info that if not provided will limit the use of the resource) | Optional |
Title | Y |
|
|
Description |
| Y |
|
Author (s) | Y It must be filled with something. It will come prefilled with the name of the training service provider and it can be updated adding the name of the author |
|
|
Language (different resources for different languages) |
| Y |
|
Keywords |
| Y |
|
License |
| Y Extremely relevant for us. Not mandatory field but if the training provider misses on this information will make hard to have further uses of the resources |
|
Access Rights (open, closed, restricted, with a cost, etc.) |
| Y Extremely relevant for us. Not mandatory field but if the training provider misses on this information will make hard to have further uses of the resources (with a vocabulary? Check RDA suggestions) |
|
Version Date(s) |
| Y (red alert!) |
|
URL to resource | Y |
|
|
Resource URL type |
|
| Y |
Target Group (Audience) |
| Y |
|
Learning Resource Type |
|
| Y |
Learning Outcome |
| Y |
|
Expertise Level |
| Y |
|
Table 2. New materials (for registrations directly in the catalogue)
Metadata Field | Mandatory | Recommended (info that if not provided will limit the use of the resource) | Optional |
Title | Y |
|
|
Description |
| Y |
|
Author (s) | Y It must be filled with something. It will come prefilled with the name of the training service provider and it can be updated adding the name of the author |
|
|
Language (different resources for different languages) | Y |
|
|
Keywords |
| Y (alert) |
|
License |
| Y Extremely relevant for us. Not mandatory field but if the training provider misses on this information will make hard to have further uses of the resources |
|
Access Rights (open, closed, restricted, with a cost, etc.) | Y |
|
|
Version Date(s) | Y |
|
|
URL to resource | Y |
|
|
Resource URL type |
|
| Y |
Target Group (Audience) | Y (controlled vocabulary) |
|
|
Learning Resource Type |
| Y (Use controlled vocabulary provided by DCMI on the LRMI innitiative: https://www.dublincore.org/specifications/lrmi/concept_schemes/learningResourceType/) By learning resource we mean a persistent resource that has one or more physical or digital representation, and that explicitly involves, specifies or entails a learning activity or learning experience). |
|
Learning Outcome | Y (controlled vocabulary) |
|
|
Expertise Level | Y (controlled vocabulary) |
|
|
Table 3. RDA Minimal Metadata for Learning Resources customized for the EOSC training resources
Name | Definition | Usage notes, allowed values, examples, other constraints | |
Title | The human readable name of the learning resource. | TEXT (1000) | Notes: It should be transcribed from the learning resource itself or the descriptive metadata found on the resource landing page. If no title exists, the provider should create it. If the resource exists in more than one language, a separate record should be created for that version. Allowed values: Should be Unicode and allow for diacritics. Example: "CESSDA Data Management Expert Guide" Constraints: Not repeatable |
Abstract/ | A brief synopsis about or | TEXT (2000) | Notes: The description can include the relationship of this resource to others, if applicable, e.g., a part within a series or collection, and the existence of translations of the resource into other languages. Allowed values: Should be Unicode and allow for diacritics Example: “A guide designed by European experts to help social science researchers make their research data Findable, Accessible, Interoperable and Reusable (FAIR).” Constraints: Not repeatable |
Author(s) | The name of entity(ies) authoring the resource. | TEXT | Notes: Authors should be listed in the order presented on the resource or on the descriptive metadata on the landing page of the resource. Multiple authors should be listed with commas between the names. Names should include given or first name and family or surname, and a personal identifier such as an ORCID, if available. Some input systems may offer separate fields for each of these identifying items. Allowed values: Should be Unicode and allow for diacritics Example: "CESSDA Training Team" Constraints: Repeatable |
Primary Language | The language in which the resource was originally published or made available. | TEXT (2) | Notes: If the resource exists in more than one language, that information can be included in the Abstract/Description term. A second record should be created, if possible, for the other language versions of the resource. Allowed values: String composed by a code as defined by the code set ISO 639-1:2002 Example: "en" Constraints: Not repeatable |
Keyword(s) | The keyword(s) or tag(s) used to describe the resource. | TEXT (100) | Notes: Keywords may be single words or phrases that characterize what the resource is about. Ideally, the keywords come from a controlled vocabulary of terms that are curated and structured to represent the specific nature of the collection of learning resources, e.g., by subject domain, data format and/or data type. In a web or searchable catalogue / web environment for learning resources, keywords are important to the search engine optimization (SEO) strategy of the environment, and are used in conjunction with resource titles, descriptions and other educational information such as target audience to improve the findability of the resource on the web or within the catalogue / registry. Keywords are sometimes called "tags" in non-academic environments. Allowed values: Free text or keywords from a given vocabulary. Example: data management, data preservation, data discover Constraints: Repeatable |
License | A license document that applies to this content, typically indicated by URL. | TEXT (100) | Notes: The license is used to represent and classify data access policies related to the training resource. It can be a short label indicating the license (e.g., CC BY 4.0) or a full label (e.g., Creative Commons Attribution 4.0 International) or the complete definition (e.g., The data are available under the Creative Commons Attribution 4.0 International Public License (https://creativecommons.org/licenses/by/4.0/). Allowed values: Free text or keywords from a given vocabulary, e.g., the NERC Vocabulary Server (NVS), http://vocab.nerc.ac.uk/collection/L08/current/ Example: "Creative Commons Attribution 4.0 International" Constraints: Not repeatable |
Version Date | The version date for the most recently published or broadcast resource. | DATE | Notes: This date may relate to either the publication of a new version of a resource or the modification date of an original version. If the original version of a resource is changed significantly, it may be better to create a new description of the newer version rather than change the version date, especially if the older version of the resource will continue to be made available (similar to a new "edition" of a published entity). Allowed values: Date Format: YYYY-MM-DD IETF RFC3339 | ISO 8601; To indicate a date range, follow the RKMS-ISO8601 standard for depicting date ranges. Example: "2020-11-12" Constraints: Not repeatable |
URL to Resource | The URL that resolves to the learning resource or to a "landing page" for the resource that contains important contextual information including the direct resolvable link to the resource, if applicable. | TEXT (1000) | Notes: As this value is intended to at least specify where a resource exists and the mechanism for retrieving it at a resolvable location, it should follow the syntax of URL: http://www.domainname.com/folder-name/web page-file-name.htm. The URL could also point to a "landing page" for the resource that could include other contextual information, especially if the resource is related to others such as a member of a set or collection of resources. Ideally, the URL would also be a persistent identifier (PID) that provides a long-lasting reference to the resource such as those created and supported by PID systems such as Digital Object Identifiers (DOIs) or Archival Resource Keys (ARKs). Allowed values: URL syntax Example: “https://www.cessda.eu/Training/Training-Resources" Constraints: Not repeatable |
Resource URL Type | The designation of identifier scheme used for the resource URL. | TEXT (40) | Notes: It represents the type of the URL of the resource, that is the used scheme (e.g., Web Address URL, DOI, ARK, etc.). Allowed values: Ideally the values used will come from a controlled vocabulary, e.g., the related IdentifierType from DataCite at: https://schema.datacite.org/meta/kernel-4.2/doc/DataCite-MetadataKernel_v4.2.pdf Example: “DOI” Constraints: Not repeatable |
Target Group (Audience) | The principal users(s) for which the learning resource was designed. | TEXT (40) | Notes: It indicates the target group(s) for which the training resource has been designed and implemented. Allowed values: free text (or codes from an existing vocabulary) Example: “Data centre staff” Constraints: Repeatable |
Learning | The predominant type or kind that characterizes the learning resource. | TEXT (40) | Notes: Different metadata schemes employ this element to indicate other factors regarding the learning resource type. For instance, LOM indicates the potential educational use(s) or type(s) of content associated with the LR, see example below. LRMI uses a concept scheme Other values are indeed relevant only to its format or genre (diagram, figure, graph, index, slide, table, narrative text). The vocabulary terms are defined as in the OED: 1989 and as used by educational communities of practice. Allowed values: Ideally, this list of types should come from a controlled vocabulary that is actively maintained and curated. Example: "Narrative text" Constraints: Not repeatable |
Learning Outcome(s) | The descriptions of what knowledge, skills or abilities students should acquire on completion of the resource. | TEXT (1000) | Notes: It indicates the learning outcomes after the completion of the training resource. Allowed values: free text Example: “At the end of this course the participants will be able to make their research data Findable, Accessible, Interoperable and Reusable (FAIR).” Constraints: Repeatable |
Access Cost | The potential cost associated to the learning resource. | TEXT (8) | Notes: It indicates if the learning resource has an access cost. Allowed values: yes, no, maybe with recommendation that further explanation of “Maybe” goes in the Description field for “It depends” or “It changes” explanations). Example: “no” Constraints: Not repeatable |
Expertise Level | Target skill level in the topic being taught. | TEXT (40) | Notes: It indicates the expertise level required for the specific learning resource. Allowed values: free text (or codes from an existing vocabulary e.g., beginner, intermediate, advanced, etc.) Example: “beginner” Constraints: Not repeatable |