hortus:fair:metadata
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| hortus:fair:metadata [2026/04/01 17:11] – created savino.frisardi | hortus:fair:metadata [2026/04/08 12:27] (current) – savino.frisardi | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Metadata is the engine of FAIR ===== | + | ===== Understanding HORTUS metadata management |
| - | Metadata describes your research objects. | + | **Core metadata: minimum required quality for every Marketplace resource** |
| - | Without metadata: | + | HORTUS already enforces some mandatory fields when creating a new Marketplace resource (First step of the catalogue resource creation: Define MAIN INFORMATION). The checklist below recommends a minimum quality bar for ITSERR-wide consistency. |
| - | | + | **Core fields checklist** |
| - | | + | |
| - | | + | |
| - | With good metadata: | + | ^ Field ^ Required in HORTUS? ^ ITSERR guideline ^ Notes / examples ^ |
| + | | **Title** | Yes | Mandatory | Use a descriptive title; avoid acronyms-only unless widely recognised. | | ||
| + | | **Abstract / Description** | Yes | Mandatory | 2–8 lines. Explain what it is, why it exists, and how to reuse it. | | ||
| + | | **Publication location** | Yes | Recommended | Use the real release/ | ||
| + | | **Publication date** | Yes | Mandatory | Use the real release/ | ||
| + | | **Language** | Yes | Recommended | Add all relevant languages (content language, transcription language, etc.). | | ||
| + | | **Authors / Creators** | Yes | Mandatory | Include contributors and, when relevant, corporate authorship. | | ||
| + | | **License** | Yes | Mandatory | Choose an explicit reuse license (e.g., CC BY, CC BY-SA) when possible. | | ||
| + | | **Resource type** | Yes | Mandatory | Choose from the agreed taxonomy (Publication, | ||
| + | | **Keywords** | Yes | Mandatory | Use consistent vocabulary (discipline + method + corpus + geography/ | ||
| + | | **Project link** | Optional in UI | Strongly recommended | Link the resource to the correct Project/ | ||
| + | | **Identifiers (DOI/URL)** | Optional | Recommended | Add a DOI if it exists; otherwise, a stable URL/handle. | | ||
| - | * search becomes effective | ||
| - | * systems can exchange information | ||
| - | * content becomes reusable | ||
| ---- | ---- | ||
| - | ===== Understanding HORTUS | + | **Standard, Community, and Personal |
| - | HORTUS provides a structured | + | Metadata formats (also called |
| - | Users can: | + | * **Standard metadata**: common reference formats intended for the whole platform. They promote interoperability and consistent indexing. |
| + | * **Community metadata**: formats shared publicly by users with the community. They can capture discipline-specific needs (e.g., manuscript description) without necessarily becoming platform-wide standards. | ||
| + | * **Personal metadata**: formats you create for your own needs (private). Personal formats | ||
| + | |||
| + | ---- | ||
| + | |||
| + | **Which type of metadata format should I choose?** | ||
| + | |||
| + | Use the questions below as a quick decision guide: | ||
| + | * Do you plan to export this resource to another repository (e.g., Zenodo) or to exchange metadata with external systems? → Start from a Standard metadata format (or duplicate a standard format and extend it). | ||
| + | * Is your research community using discipline-specific description practices (e.g., manuscript cataloguing, | ||
| + | * Do you need local project fields that are not relevant for everyone (e.g., internal IDs, digitisation batch, workflow status)? → Use a Personal metadata format (ideally created by duplicating a standard/ | ||
| - | * fill predefined metadata fields | ||
| - | * use standard schemas | ||
| - | * create custom metadata sets (advanced) | ||
| ---- | ---- | ||
| + | |||
| + | **Typical use cases** | ||
| + | |||
| + | The table below provides simple examples of when each governance level is the best fit. | ||
| + | |||
| + | ^ Example scenario ^ Recommended type ^ Why ^ | ||
| + | | **Publishing a dataset or paper that you want to deposit on Zenodo or cite via DOI** | Standard | Maximises interoperability and eases export/ | ||
| + | | **Creating a shared metadata template for a discipline (e.g., archaeological finds, manuscript description) to be reused by multiple teams** | Community | Captures domain-specific fields while remaining public and reusable. | | ||
| + | | **Adding internal project management fields (e.g., " | ||
| + | | **Extending Zenodo metadata set with 2–3 extra fields needed for your project, while keeping standard field names** | Personal (duplicated from Standard) | Keeps compatibility while allowing controlled customisation. | | ||
| + | | **Proposing a project-developed template to become a wider reference once tested** | Personal → Community | Start Personal, iterate, then submit a new Community version to moderation for adoption. | | ||
| + | |||
| + | ---- | ||
| + | |||
| + | **Example: viewing metadata on a published resource** | ||
| + | |||
| + | Once a resource is published (or even while it is a draft), you can open its detail page and use the “Metadata” tab to review the values that were entered using the selected metadata format. | ||
| + | |||
| + | |||
| + | {{: | ||
| + | |||
| + | ---- | ||
| + | |||
| + | **Pre-defined object types in HORTUS** | ||
| + | |||
| + | HORTUS provides a **predefined list of object types** to organise the first version of the catalogue and ensure that resources are described consistently from the start. The initial set of object types includes: | ||
| + | |||
| + | * **Publications** | ||
| + | * **Datasets** | ||
| + | * **Images (2D)** | ||
| + | * **Audio and video** | ||
| + | * **3D models** | ||
| + | * **Software / tools** | ||
| + | |||
| + | |||
| + | This list is **not fixed**. As the HORTUS community grows and new research practices emerge, the catalogue can be **expanded with additional object types**. Users can propose new object types when they identify a recurring need (e.g., a specific kind of research output that does not fit well in the existing categories). | ||
| + | |||
| + | |||
| + | ==== Pre-defined object types in HORTUS | ||
| + | |||
| + | **Standard metadata sets** | ||
| + | |||
| + | HORTUS includes a first group of Standard metadata sets that are designed for interoperability with well-known external platforms and infrastructures. These formats provide a stable “common language” for describing resources in a way that can be more easily mapped, exported, or re-used outside HORTUS (e.g., when depositing or aligning records with external catalogues). The initial standard formats include Zenodo, SSHOC, and CLARIN VLO. This list is not fixed: additional standard sets can be introduced over time, but to preserve consistency and trust, new standard formats are added through a moderated process, typically based on community needs and technical feasibility. | ||
| + | |||
| + | **Community metadata sets** | ||
| + | |||
| + | In addition to standards, HORTUS foresees Community metadata sets that provide practical templates aligned with the types of resources commonly managed in the platform. These formats are intended to support discipline-oriented or project-oriented practices, offering field structures that are meaningful for researchers while still encouraging consistency across the community. The initial set includes a Generic template and dedicated community templates for major resource categories: Publications, | ||
| + | |||
| + | |||
| + | |||
hortus/fair/metadata.1775056310.txt.gz · Last modified: by savino.frisardi
