Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 21 Next »

STATUS: IN DEVELOPMENT

Short description 

As already mentioned across many of these chapters, metadata refers to contextual information about a resource, such as dataset. This metadata may come in many formats, the most familiar type of metadata is generic metadata may include details about what the data is about (e.g., patient health records, imaging data), who created it (e.g., a research team at Radboudumc) and when (e.g., collected in 2023) and also disclose information about how can the data be used (e.g., available for public use, restricted access). But there are other types of information that can be useful to include in the metadata:

  • Content metadata: Refers to what elements are included in the dataset and the possible values (e.g., Imagine questionnaire data is collected it may be relevant to specify in the metadata which questions are being asked and the possible answer choices).

  • Provenance metadata: Refers to how this metadata came to be. What protocols were followed, for the same example above this might be a specific questionnaire already published (e.g., COVID data collection form).

Metadata is data about data. It comes in many types, such as descriptive metadata, provenance metadata, etc [cb_metadata]. Metadata helps people to locate the data and allows it to be reused and cited [GoFAIR]. Furthermore, metadata can be machine-actionable, allowing for automation of data handling and validation [RDMKit_MachineActionable]. Findability, accessibility and reusability of data can be improved by providing metadata with details about license, copyright, etc., as well as description of use conditions and access of data [Generic]. 

Maybe more how to:

Check whether metadata regarding regarding findability, accessibility, and reusability is already available and whether this metadata is already being collected using standardized vocabularies [Generic, FAIRopoly]. What metadata should be gathered may depend on the stakeholder community [Generic]. 

[FAIRopoly] Identify what metadata is already being collected by your registry (e.g., provenance, creation date, file type and size, timestamp). The result of this step will support defining the metadata model of your registry. Also, check if your metadata is already being collected using standardized vocabularies.

Why is this step important 

Generally:

To be able to register resource level metadata you need to make sure you have/collect it.

with respect to HRI:

Health-RI is in the process of defining a metadata scheme for onboarding in the Health-RI metadata portal. To allow for onboarding of a dataset, the minimal metadata set must be provided. It is therefore essential that you assess whether this minimal set is collected/available or whether additional metadata needs to be collected. 

How to 

[FAIRopoly] → Doesn’t really sound like “assess” though?

Usually, terms from upper ontologies can be used to describe metadata. For example, use dcat:Dataset from Data Catalog Vocabulary (DCAT) [DCAT] to describe the type of any rare disease dataset and dct:creator from DCMI Metadata Terms (DCT) to indicate the relationship between a dataset and its creator. 

The How to section should:

  • be split into easy to follow steps;

    • Step 1

    • Step 2

    • etc.

  • help the reader to complete the step;

  • aspire to be readable for everyone, but, depending on the topic, may require specialised knowledge;

  • be a general, widely applicable approach;

  • if possible / applicable, add (links to) the solution necessary for onboarding in the Health-RI National Catalogue;

  • aim to be practical and simple, while keeping in mind: if I would come to this page looking for a solution to this problem, would this How-to actually help me solve this problem;

  • contain references to solutions such as those provided by FAIR Cookbook, RMDkit, Turing way and FAIR Sharing;

  • contain custom recipes/best-practices written by/together with experts from the field if necessary. 

Expertise requirements for this step 

This section could describe the expertise required. Perhaps the Build Your Team step could then be an aggregation of all the “Expertise requirements for this step” steps that someone needs to fulfill his/her FAIRification goals.  

Practical examples from the community 

This section should show the step applied in a real project. Links to demonstrator projects. 

Training

Add links to training resources relevant for this step. Since the training aspect is still under development, currently many steps have “Relevant training will be added in the future if available.”

Suggestions

Visit our How to contribute page for information on how to get in touch if you have any suggestions about this page.

 

  • No labels