This is an old revision of the document!
Understanding HORTUS metadata management
Core metadata: minimum required quality for every Marketplace resource
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
| 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 (not only upload date). |
| Publication date | Yes | Mandatory | Use the real release/publication date (not only upload date). |
| 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, Dataset, Image, …). |
| Keywords | Yes | Mandatory | Use consistent vocabulary (discipline + method + corpus + geography/time). |
| Project link | Optional in UI | Strongly recommended | Link the resource to the correct Project/sub-project page. |
| Identifiers (DOI/URL) | Optional | Recommended | Add a DOI if it exists; otherwise, a stable URL/handle. |
Standard, Community, and Personal metadata sets
Metadata formats (also called metadata sets) define which fields appear when you describe a resource. In HORTUS they are organised in three governance levels:
- 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 can combine standard/community fields with project-specific additions.
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, archaeological objects, epigraphy)? → Look for (or propose) a Community metadata format.
- 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/community format).
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/mapping. |
| 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., “digitisation_batch”, “transcription_status”) that only your team needs | Personal | Keeps local needs private; you can still align with standards by duplicating. |
| 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, Datasets, Images (2D), Audio and video, 3D models, and Software/tools. Like object types, this collection is expandable: HORTUS users can propose new community metadata sets (or improvements to existing ones), and the moderator board reviews and approves them to keep the catalogue coherent and avoid fragmented or incompatible formats.