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.
| 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. |
Core fields checklist
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.