Metadata in agrosystem research practice

Metadaten in der agrarwissenschaftlichen Praxis Autor*innen Sophie Boße, Elena Rey Mazón, Anne Sennhenn, Lucia Vedder, Gabriel Schneider Abstract Dieser Praxisleitfaden zur Erhebung von Metadaten in der agrarwissenschaftlichen Forschung zielt darauf ab, einen leichten und praxisorientierten Einstieg in die Welt der Datendokumentation zu geben. Ein Entscheidungsbaum leitet den oder die Forschende mit einfachen praxisnahen Fragen durch die Themen: 1 Warum Daten dokumentiert werden sollten; 2 Welche Formen und Formate für eine Datendokumentation im eigenen Projekt sinnvoll sind; 3 Welche Metadaten für die eigenen Forschungsdaten erhoben werden sollten; 4 Wie die Metadaten erstellt werden können; 5 Welche Formen der Speicherung und Verknüpfung mit den Forschungsdaten in Betracht gezogen werden sollten; und 6 Wie die Qualität der Metadaten sichergestellt werden kann. Neben dem Entscheidungsbaum enthält dieses Dokument auch kurze Erklärungen einiger Begriffe (Anhang I), die zur sinnvollen Beantwortung der Fragen im Entscheidungsbaum verstanden werden sollten. Zudem gibt ein Metadaten-Guide (Anhang II) mit vielen agrarwissenschaftlichen Beispielen einen Überblick über Metadaten, Metadatenschemata, Terminologien und verschiedene Formen der Erhebung und Speicherung von Metadaten. Der Guide ist nur in englischer Sprache verfügbar. Mithilfe von internen Links wird aus dem Entscheidungsbaum heraus gezielt zu Begriffserklärungen oder weiteren Erläuterungen im Metadaten-Guide verwiesen. Eine interaktive Version des Entscheidungsbaumes wurde von Justus Schneider erstellt. Der Metadaten-Guide ist adaptiert von Australian Research Data Commons (ARDC), „ARDC Metadata Guide“, 1. März 2020, Zenodo. doi: 10.5281/ZENODO.6459832, lizensiert unter CC BY 4.0 FAIRagro FAIRagro baut als Konsortium der Nationalen Forschungsdateninfrastruktur (NFDI) ein FAIRes Forschungsdatenmanagement für die Community der Agrosystemforschung auf. Es entwickelt passende Tools und Workflows und schafft so die Grundlage für eine nachhaltige Pflanzenproduktion – jetzt und in Zukunft. Weitere Informationen finden Sie auf der FAIRagro Website. Helpdesk Bei Unterstützungsbedarf bei der Erstellung einer geeigneten Datendokumentation oder bei weiterführenden Fragen zu allen Themen des Forschungsdatenmanagements wenden Sie sich gerne über das Kontaktformular oder die Mailadresse: [email protected] an den FAIRagro Helpdesk. Lizenz “Metadaten in der agrarwissenschaftlichen Praxis” von Sophie Boße, Elena Rey Mazón, Gabriel Schneider, Anne Sennhenn, Lucia Vedder ist lizenziert unter CC BY 4.0 Zitation Diese Publikation kann zitiert werden als: Boße, S., Rey Mazón, E., Sennhenn, A., Vedder, L., Schneider, G.; Metadaten in der agrarwissenschaftlichen Praxis, 2025, Fachrepositorium Lebenswissenschaften, doi: 10.4126/FRL01-006490238 Förderung Diese Arbeit ist im Rahmen des NFDI-Konsortiums FAIRagro entstanden (www.fairagro.net). Wir danken der Deutschen Forschungsgemeinschaft (DFG) für die finanzielle Unterstützung – Projektnummer 501899475. Entscheidungsbaum Motivation der Datendokumentation 1. Möchten Sie Ihre Daten organisiert und verständlich halten? ☐ Ja → Weiter mit Schritt 2 ☐ Nein → Ihre Daten sind nicht langfristig nutzbar. → Weiter mit der Exitfrage * Exitfrage: Ohne verständliche Daten ist eine Nachnutzung durch Sie selbst oder Dritte kaum möglich, zudem sind Metadaten zentral für die FAIR-Prinzipien (Auffindbarkeit, Zugänglichkeit, Interoperabilität, Wiederverwendbarkeit). Möchten Sie daher doch, wie empfohlen, eine Datendokumentation anlegen? ☐ Ja → Weiter mit Schritt 2 ☐ Nein → Ende 2. Sind Ihre Daten für andere relevant (z.B. bei Zusammenarbeit mit Kolleg:innen, Projektpartner:innen, Nachnutzung von Dritten)? ☐ Ja → Weiter mit Schritt 4 ☐ Nein → Weiter mit Schritt 3 3. Möchten Sie Ihre Daten zu einem späteren Zeitpunkt noch nachvollziehen und verstehen? ☐ Ja → Weiter mit Schritt 4 ☐ Nein → Eine umfangreiche Datendokumentation ist nicht notwendig, legen Sie bestenfalls trotzdem eine grundlegende README-Datei an. → Ende Formen und Formate der Datendokumentation 4. Enthalten Ihre Daten Quellcode? ☐ Ja → Kommentieren Sie den Quellcode, um eine bessere Nachvollziehbarkeit zu erreichen. → Weiter mit Schritt 5 ☐ Nein → Weiter mit Schritt 5 5. Verwenden Sie Daten mit nicht selbsterklärenden Variablennamen oder auch vielen Abkürzungen oder Codierungen? ☐ Ja → Erstellen Sie ein Data Dictionary bzw. Codebook, um Ihre Daten besser verständlich zu machen. → Weiter mit Schritt 6 ☐ Nein → Weiter mit Schritt 6 6. Folgen Sie routinemäßig einem standardisierten Arbeitsablauf zur Datenerhebung bzw. -verarbeitung? ☐ Ja → Verwenden Sie bereits bestehende Standard Operating Procedures (SOP) oder erstellen Sie ggf. eine neue SOP, um einheitliche Arbeitsabläufe und die Reproduzierbarkeit sicherzustellen. → Weiter mit Schritt 7 ☐ Nein → Weiter mit Schritt 7 7. Möchten Sie Ihre Daten veröffentlichen oder anderweitig auffindbar und nachnutzbar machen? ☐ Ja → Erfassen Sie Metadaten. Legen Sie bestenfalls zudem eine zusätzliche Datendokumentation (z.B. in Form einer grundlegenden README-Datei oder als Teil eines Datenmanagementplans) an, um Ihre Daten leicht verständlich zu halten und somit die richtige Interpretation sicherzustellen. → Weiter mit Schritt 8 ☐ Nein → Eine strukturierte Erfassung von Metadaten ist für Sie nicht zwingend erforderlich. → Weiter mit der Exitfrage *Exitfrage: Eine gute Datendokumentation kann auch für Ihre eigene Arbeit innerhalb des Projektes oder an Ihrer Institution hilfreich sein. Möchten Sie dafür strukturierte Metadaten erfassen? ☐ Ja → Weiter mit Schritt 8 ☐ Nein → Ende Zu erhebende Metadaten auswählen 8. Gibt es ein konkretes Repositorium, in dem Sie veröffentlichen möchten? ☐ Ja → Weiter mit Schritt 9 ☐ Nein → Recherchieren Sie geeignete Repositorien, um die Sichtbarkeit und Auffindbarkeit Ihrer Daten bei einer Veröffentlichung zu maximieren. → Weiter mit Schritt 9 9. Gibt es Vorgaben zum Metadatenschema durch dieses Repositorium? ☐ Ja → Legen Sie anhand dieses Metadatenschemas fest, welche Metadaten Sie erheben müssen (alle Pflichtfelder oder mandatory Metadatenelemente), und welche Metadaten Sie erheben können und wollen (aus den empfohlenen und optionalen Metadatenelementen). Stellen Sie sicher, dass Sie alle relevanten Metadaten erfassen. → Weiter mit Schritt 12 ☐ Nein / Unsicher → Weiter mit Schritt 10 10. Gibt es im Rahmen Ihres Projektes Vorgaben zum Metadatenschema (z.B. im Datenmanagementplan festgehalten)? ☐ Ja → Legen Sie anhand dieses Metadatenschemas fest, welche Metadaten Sie erheben müssen (alle Pflichtfelder oder mandatory Metadatenelemente), und welche Metadaten Sie erheben können und wollen (aus den empfohlenen und optionalen Metadatenelementen). Stellen Sie sicher, dass Sie alle relevanten Metadaten erfassen. → Weiter mit Schritt 12 ☐ Nein / Unsicher → Weiter mit Schritt 11 11. Gibt es ein etabliertes Metadatenschema (Metadatenstandard) für Ihre Disziplin oder Datentyp? ☐ Ja, eines → Verwenden Sie das gewählte Schema und passen Sie dieses ggf. an, um festzulegen, welche Metadaten Sie erheben müssen (alle Pflichtfelder oder mandatory Metadatenelemente), und welche Metadaten Sie erheben können und wollen (aus den empfohlenen und optionalen Metadatenelementen). Stellen Sie sicher, dass Sie alle relevanten Metadaten erfassen. → Weiter mit Schritt 12 ☐ Ja, mehrere → Überprüfen Sie, welches Schema am besten zu Ihren Daten passt, und verwenden Sie dieses, um festzulegen, welche Metadaten Sie erheben müssen (alle Pflichtfelder oder mandatory Metadatenelemente), und welche Metadaten Sie erheben können und wollen (aus den empfohlenen und optionalen Metadatenelementen). Stellen Sie sicher, dass Sie alle relevanten Metadaten erfassen. Kombinieren Sie ggf. bei Bedarf mehrere passende Schemata. Ein Austausch mit Fachkolleg*innen oder eine kompetente Beratung (z.B. über den FAIRagro Helpdesk) kann hilfreich sein. → Weiter mit Schritt 12 ☐ Nein / Unsicher → Ein Austausch mit Fachkolleg*innen oder eine kompetente Beratung (z.B. über den FAIRagro Helpdesk) kann hilfreich sein, um ein passendes Schema zu finden bzw. selbst (weiter-) zu entwickeln. → Weiter mit Schritt 12 12. Gibt es hinsichtlich der Metadaten Richtlinien (z.B. Forschungsdatenpolicy) oder Vorgaben Ihrer Einrichtung, Ihrer Förderorganisation oder von Zeitschriften/Journals? ☐ Ja → Prüfen Sie, ob die Vorgaben durch das gewählte Metadatenschema abgedeckt werden. Passen Sie das Schema ggf. an und dokumentieren Sie dies. → Weiter mit Schritt 13 ☐ Nein → Weiter mit Schritt 13 Metadaten erfassen 13. In welcher Projektphase (siehe Datenlebenszyklus) befinden Sie sich? ☐ Planung oder Datenerhebung → Beachten Sie, dass die Datendokumentation direkt bei der Datenerhebung erfolgen und dafür in der Planungsphase (z.B. im Datenmanagementplan) bereits berücksichtigt werden sollte. → Weiter mit Schritt 14 ☐ Datenveröffentlichung → Nutzen Sie die Erfassungsmaske Ihres ausgewählten Repositoriums zur Speicherung der Metadaten. → Weiter mit Schritt 22 14. Werden Metadaten automatisch erfasst (z.B. Dateigröße, Datum, ISOWert etc. bei Fotos)? ☐ Ja → Stellen Sie sicher, dass die relevanten Metadaten gespeichert werden, und überprüfen Sie die Vollständigkeit. Erfassen Sie ggf. weitere relevante Metadaten. → Weiter mit Schritt 15 ☐ Nein → Weiter mit Schritt 15 15. Können Metadaten aus anderen Systemen übernommen werden (z.B. ELNs, DMPs, Geräte-Software, Labordokumentation)? ☐ Ja → Stellen Sie sicher, dass die relevanten Metadaten übernommen und gespeichert werden, und überprüfen Sie die Vollständigkeit. Erfassen Sie ggf. weitere relevanten Metadaten. → Weiter mit Schritt 16 ☐ Nein → Weiter mit Schritt 16 16. Müssen (weitere) Metadaten manuell erhoben werden? ☐ Ja → Erheben Sie alle relevanten Metadaten und tauschen Sie sich ggf. mit Fachkolleg*innen über die Vollständigkeit aus. → Weiter mit Schritt 17 ☐ Nein → Weiter mit Schritt 17 Metadaten speichern und verknüpfen 17. Nutzen Sie bereits Tools zur Metadatenspeicherung (z.B. Datenmanagementtools, ELNs, digitale Feldbücher)? ☐ Ja → Nutzen Sie diese Tools weiter → Weiter mit Schritt 22 ☐ Nein → Prüfen Sie, ob eine Installation von Datenmanagementtools, elektronischen Laborbüchern oder digitalen Feldbüchern für Sie sinnvoll ist. ☐ Wenn ja → Nutzen Sie diese. → Weiter mit Schritt 22 ☐ Wenn nein / unsicher → Weiter mit Schritt 18 18. Ist Ihr Datensatz umfangreich und komplex strukturiert? ☐ Ja → Eine klare Zuordnung von zentral gespeicherten Metadaten zur jeweiligen Datendatei kann bei komplexen Datensätzen schwierig sein, daher wird eine dezentrale Speicherung der Metadaten empfohlen. Soll eine zentrale Metadatenspeicherung trotzdem in Betracht gezogen werden? ☐ Wenn ja → Weiter mit Schritt 19 ☐ Wenn nein → Weiter mit Schritt 20 ☐ Nein → Prüfen Sie, ob eine einfache Begleitdatei (z.B. README-Datei) sinnvoll ist, um die Metadaten zu Ihrem Datensatz zentral zu sammeln und auf einen Blick verfügbar zu machen. ☐ Wenn ja → Stellen Sie sicher, dass die Metadatendatei klar mit dem Datensatz verknüpft ist (z.B. durch eindeutige Namensgebung) und die Metadaten den einzelnen Datensätzen eindeutig zugeordnet werden können, um Datenverluste zu vermeiden. → Weiter mit Schritt 21 ☐ Wenn nein → Weiter mit Schritt 19 19. Werden Ihre Datendateien häufig verschoben oder kopiert? ☐ Ja → Eine zentrale Metadatendatei wird nicht empfohlen. → Weiter mit Schritt 20 ☐ Nein → Prüfen Sie, ob eine zentrale Metadatendatei für den gesamten Datensatz sinnvoll ist. ☐ Wenn ja → Stellen Sie sicher, dass die Metadatendatei klar mit dem Datensatz verknüpft ist (z.B. durch eindeutige Namensgebung) und die Metadaten den einzelnen Datensätzen eindeutig zugeordnet werden können, um Datenverluste zu vermeiden. → Weiter mit Schritt 21 ☐ Wenn nein → prüfen Sie, ob dezentrale Metadatendateien sinnvoll sind. ☐ Wenn ja → Stellen Sie sicher, dass die einzelnen Metadatendateien klar mit den jeweiligen Datendateien verknüpft sind, sodass Datenverluste beim Verschieben oder Kopieren der Daten vermieden werden. → Weiter mit Schritt 21 ☐ Wenn nein → Weiter mit Schritt 20 20. Ist es technisch möglich, dass relevante Metadaten innerhalb der Datendateien gespeichert werden? ☐ Ja, vollständig → Prüfen Sie, ob Sie Ihre Metadaten direkt in den Datendateien speichern möchten, um Datenverluste durch Kopieren oder Verschieben der Datendateien zu verhindern. → Weiter mit Schritt 21 ☐ Nein → Prüfen Sie, ob Sie dezentrale Metadatendateien neben den Datendateien anlegen, um umfangreiche Metadaten zu einzelnen Datendateien speichern zu können. Achten Sie darauf, diese Dateien gut mit den Datendateien zu verknüpfen, sodass Datenverluste bei Verschieben oder Kopieren der Daten vermieden werden. → Weiter mit Schritt 21 ☐ Ja, teilweise → Prüfen Sie, ob Sie die technisch möglichen Metadaten direkt in der Datendatei speichern möchten, und ergänzen Sie diese mit dezentralen Metadatendateien oder einer zentralen Metadatendatei. → Weiter mit Schritt 21 21. Ist Ihnen ein automatisiertes Durchsuchen der Metadaten wichtig? ☐ Ja → Ziehen Sie maschinenlesbare Formate (z.B. XML, JSON) zur Speicherung der Metadaten in Erwägung. → Weiter mit Schritt 22 ☐ Nein → Sie können einfache Textdateien oder Tabellen als Alternative zu maschinenlesbaren Formaten (z.B. XML, JSON) nutzen. → Weiter mit Schritt 22 Qualität der Metadaten sicherstellen 22. Haben Sie die Struktur der Metadaten geprüft? ☐ Ja → Weiter mit Schritt 23 ☐ Nein → Je nach Dateiformat Ihrer Metadaten-Datei(en) können Sie automatisch überprüfen, ob sie konform zu Ihrem gewählten Metadatenschema sind. Verwenden Sie dafür ggf. existierende Tools zur Validierung.→ Weiter mit Schritt 23 23. Haben Sie die inhaltliche Korrektheit der Metadaten geprüft? ☐ Ja → Weiter mit Schritt 24 ☐ Nein → Prüfen Sie die Metadaten und passen Sie sie ggf. an. → Weiter mit Schritt 24 24. Verwenden Sie kontrollierte Vokabulare oder Terminologien? ☐ Ja → Weiter mit Schritt 25 ☐ Nein → Nutzen Sie Begriffe aus kontrollierten Vokabularen, um die Metadaten verständlicher zu machen. Reichern Sie die Metadaten ggf. mit TerminologieKonzepten an. Dadurch werden sie eindeutig und können leichter für automatisierte Prozesse genutzt werden. → Weiter mit Schritt 25 25. Sind die Metadaten mit den Daten verknüpft und dokumentiert? ☐ Ja → Herzlichen Glückwunsch! Sie haben erfolgreich Metadaten für Ihr Forschungsprojekt erstellt und verwaltet. → Ende ☐ Nein → Stellen Sie sicher, dass Sie die Metadaten mit den entsprechenden Daten verknüpfen und alle verwendeten Namenskonventionen, Abkürzungen und Definitionen von Metadatenfeldern dokumentieren. → Ende ● relates to a specific crop species/variety of interest, a specific phenotypic trait of interest (e.g. root architecture, biomass growth), a specific environmental impact or field management aspect of interest ( e.g. fertilisation, crop rotation, erosion control) or a specific soil class of interest via descriptive and discipline-specific metadata. ● Is generated using a specific method of interest (e.g. a specific sensor used, a specific depth of measurement, a specific software/analysis method used) via process metadata [8]. Determining the value of data To assess the usefulness, value and quality of a data set, researchers need to understand the context around the data. This is given in metadata that: ● describes why the data were collected, the experimental design and data collection methods ● links to the researchers and institution(s) involved ● identifies the research program or grant ● points to publications that have flowed from the research data ● explicitly provides provenance, licensing, rights, and technical information [8]. Accessing data Access to research data requires: ● a direct download link to online data for open access, or ● contact information metadata for the data manager for mediated access [8]. Using and reusing data To make use of any data set, researchers need metadata on: ● how the data is structured (e.g. table structure, time units, measurement series) ● what it describes (e.g. nutrient content, disease infestation, yield data) ● how to read it (e.g. column headings, units of measurement, coding) ● how the data was collected - including methodological details such as device types, calibrations, weather conditions, instrument settings or survey questions ● What can be done with the data? (e.g. about licence information, rights of use, public domain mark) ● how to acknowledge the original creators by citing the data. Proper recording of this information is important for the producers of the data as well as future users [8]. In agricultural field trials, it is common practice to take soil samples under standardised conditions and evaluate them using specific analysis methods. If important metadata such as the exact location of the samples (GPS coordinates), the sampling date, the sampling depth, the soil moisture at the time of sampling or the analysis methods used (e.g. potassium determination using the CAL method) are not documented, the data cannot be reliably interpreted later or compared with other data sets. Satellite or drone images also lose their informative value if metadata on the time of recording, sensor parameters or weather conditions are missing. Levels of metadata There are three levels of data groupings: data objects (Datasets and Components) can be collected into groups (Collections): 1. Collection level metadata describes the collection as a whole. For example, the BonaRes database (https://maps.bonares.de) collects soil data from various longterm experiments (LTEs). The collection-level metadata describe, among other things, the objective, geographical coverage, participating institutes, licensing and interfaces for subsequent use (e.g. via APIs or download formats). 2. Dataset level metadata describes individual objects. For example, within an LTE, the metadata describing the soil measurements of a specific year are on dataset level. 3. Component level metadata - sometimes single objects can be made up of component parts: For example, a soil dataset can consist of several layer measurements per soil profile (e.g. 0-10 cm, 10-30 cm, 30-60 cm). Each layer represents a component and requires its own metadata - such as sample depth, analysis type or storage. The collection approach and subsequent level of description impacts on discoverability, and cost and effort of management. Metadata ideally should be based on the needs of those for whom the collection is created [8]. EXAMPLE: Collection, dataset and component metadata An agricultural research institute operates a central archive with data from multi-year field trials on crop rotation. To enable effective use and targeted reuse of this data, the data sets are described at several levels: ● Collection level: The data is organized in collections according to trial type - e.g. “Crop rotation trials under conservation tillage”, “Soil monitoring on organically farmed land” or “Long-term trials on nitrogen fertilization in winter wheat”. The collection level describes overarching metadata such as the locations of the trial sites, duration of the trial series, objectives, participating institutes and available data types (e.g. soil data, yield data, climate data). ● Dataset level: This level describes a specific trial year at a location, e.g. “Groß Kreutz long-term trial - year 2020”. Metadata such as tillage method, cultivated crop rotation element (e.g. spring barley), sowing date, fertilization strategy, weather pattern and harvest date are documented here. ● Component level: Within a trial year, the data consists of several individual measurements, e.g. per plot or measurement time. For each plot, for example, yield data, disease infestation, nutrient analyses or drone images are recorded - each with specific metadata such as plot ID, GPS coordinates, measurement date, sensor parameters, laboratory methods used or scoring criteria. This hierarchical structure makes it possible to find specific data - e.g. all plot yields of spring barley in 2020 under reduced tillage - without having to manually search through countless individual files. It also supports automatic linking with other data sets, such as weather or soil condition [8]. Types of metadata Metadata types are often grouped into functional types, but note that some elements will provide multiple functions. The most common types are: ● Descriptive metadata. Information required for discovery and assessment of the collection ○ e.g. title, contributors, subject or keywords, study description, and the location and dates of the study. ● Provenance metadata. This relates to the origins and processing of the data, and enables interpretation and reuse of the data. It ranges from the easily human readable to the highly technical, and usually requires some knowledge of the domain to create. ○ e.g. Where did the data come from? Why was it collected? Who collected it, when and where? What instruments/ technologies were used to collect the data, and how were they set up? How has the data been processed? ● Technical metadata. Fundamental information for a person or a computer application to read the data. ○ e.g. How is the data set up? What formats, and versions of formats, are used? How is the database configured? How does it relate to other data? ● Rights and access metadata. Information to enable access, and licensing or usage rules. ○ e.g. How can someone access the data? Who is allowed to view or modify the data, or the metadata, and under what conditions? Who has some kind of authority over the data? Are there costs associated with access? Under what licence is the data being made available? ● Preservation metadata. This builds on the history from the Provenance, Rights and Technical metadata, and also includes information to allow the data to be managed for long-term accessibility. ○ e.g. Has there been any restructuring or other changes to the files, e.g. due to migration to new file formats? What software has been used to access the data? ● Citation metadata. information required for someone to cite the data e.g. Creator(s), Publication Year, Title, Publisher, Identifier [8]. Metadata language Understanding commonly used metadata terminology will help you better plan, collect and apply metadata [8]. Elements and schemas Metadata schemas are an overall structure for metadata about a particular information resource or for a specific domain. A schema specifies a set of metadata concepts or terms (called elements), and their associated definitions (semantics) and relationships. The value given to each element is the content. Metadata schemas often emerge from a single community group (e.g. the agrosystem science community) or can be developed to describe a specific type of experiment or domain. For example, MIAPPE (https://www.miappe.org) is a standard for describing plant phenotyping experiments and ISO 19115 (http://www.dcc.ac.uk/resources/metadatastandards/iso-19115) is an international standard for describing geographic information and services. A schema may also specify: ● content rules e.g. required formats and controlled vocabularies ● the syntax in which elements must be encoded (or expressed), such as XML (Extensible Markup Language) [8]. EXAMPLE One of the most common generic schemas is the Dublin Core Metadata Initiative (http://dublincore.org), which is the most widely adopted schema for descriptive metadata to date. It is simple and generic, with just 15 elements in the original Dublin Core Metadata Element Set, including Title, Date, Type, Format, Creator, Coverage and Rights. Dublin Core has since been extended to 55 terms in the DCMI terms (http://dublincore.org/documents/dcmiterms) namespace. Each field can be basically free-form text, with some restrictions. Dublin Core is used a lot on web pages, with the “dc” namespace – so you will often see things like “dc.Title” as a metadata tag inside a webpage’s HTML headers. If you are working with video, you may use Dublin Core and the MPe.g. 7 standard for video archives, and so get the “dc.Title” and the “MPe.g.7.Title” fields. Each has its own rules for how you can use them, found in the schema’s namespace (see below) [8]. Content rules and controlled vocabularies Specifying rules around the allowable content and format of values in each metadata element improves accuracy and machine-readability of metadata, and hence discoverability of collections. Free-form text entry can lead to ambiguous data, for example, the date 3/10/15 could refer to 3 October or 10 March, in either 1915 or 2015. Having a specific set of terms that can be used in a field, i.e. a controlled vocabulary, allows filtering and faceting of the data, improving search function. Controlled vocabularies can be: ● locally defined (e.g. only allowing names to be selected from a list of employees), or an established standard (e.g. AGROVOC (https://agrovoc.fao.org/browse/agrovoc/en) as a thesaurus for agriculture related terms, including terms for crop species) or soil textures Likewise, formats can be: ● specified locally (i.e. names will be entered Firstname Lastname), or ● use an international standard (i.e. recommended best practice for the Dublin Core date (http://purl.org/dc/elements/1.1/ date) element is to use an encoding scheme, such as the W3CDTF (https://www.w3.org/ TR/NOTE-datetime) profile of ISO 8601 (http://www.iso.org/iso/home/standards/iso8601.htm) [8]. Namespaces A metadata schema’s ‘namespace’ declares a unique set of elements and definitions. By specifying the namespace(s) of the metadata schema(s) you are using, you can define which schema each element belongs to, and point people to the accepted definition of that element. For example, the term “date” appears in many schemas. However, the way a “date” is defined or recorded may be different depending on the schema; “date” might refer variously to the date the data were published in one schema, or the date the data were collected in another schema [8]. Finding and choosing a metadata schema Schemas range from the very generic to extremely discipline or resource-specific: ● Generic schemas such as DCMI Metadata Terms (https://www.dublincore.org/specifications/dublin-core/dcmi-term) and the DataCite Metadata Schema (https://schema.datacite.org) are widely adopted and easy to use - but it is so generic that everyone can use them in quite different ways, as the description becomes more specialised. ● Discipline-specific schemas provide a richer and more targeted structure and vocabulary that allows detailed information to be provided in a more structured, granular format. Finding these can be as simple as searching the internet for “[discipline] metadata schema”, from a very high level to start with (e.g. “agriculture metadata schema”) and then getting steadily more specific (e.g. “crop yield metadata schema”) if required. You can also search metadata schema registries such as the Data Curation Centre’s List of Metadata Standards (http://www.dcc.ac.uk/resources/metadata-standards/list); or the Research Data Alliance’s Metadata Standards Directory (http://rd-alliance.github.io/metadatadirectory) and FAIRsharing Registry (https://fairsharing.org) [8]. Schemas that are often used within the agrosystem science community include the following: ● ISO 19115 - international standard for geographic information ● INSPIRE - European standard for geographic information ● Darwin Core - standard for information about biological diversity ● ABCD (Access to Biological Collection Data) - for data about specimens and observations ● MIAPPE - Minimum Information About Plant Phenotyping Experiments ● MCPD (Multi-Crop Passport Descriptor) - plant genetics ● BonaRes Metadata scheme - for the BonaRes Repository Adopt, adapt, or create your schema? Although it is possible to develop a metadata schema from scratch, it is preferable to use or adapt existing standards and/or widely-established schemas, as they offer: ● Cost savings – the schema and its usage guidelines have been developed, thus saving time and effort. ● Access to help and advice – a standard is likely to have a community of users. ● Usability – users are likely to be familiar with a standard and its terminology. ● Interoperability – information can be easily shared between systems. ● Sustainability – schemas need maintenance and updating if they are to remain usable. Your choices are: 1. If there is just one obvious metadata standard, and it meets your needs, use it. 2. If there are several obvious schemas that meet your needs, follow models of ‘good practice’ within your community. 3. Where you can find no single appropriate schema: a. Adapt or extend an existing schema to better fit your needs, and document the changes you make very carefully using the documentation methods and mappings deployed by existing standards as a guide. Contact the ‘owners’ of the schema and attempt to work with them, as others may benefit from your changes. b. Alternatively, develop a new ‘application profile’, where various metadata elements (and the elements’ guidelines and documentation) are taken from different metadata schemas and mixed together. If there is absolutely no schema you can use, check again; it’s a rare situation nowadays. If there is still no schema to be found, then you may have to develop one. However, it takes a fair bit of work, and you should bring together as many interested people in your discipline as you can [8]. Collecting and linking Metadata Collecting metadata Automatic metadata collection A lot of metadata can be created automatically during the data collection process. Many scientific instruments generate metadata alongside the data itself. An obvious example is digital cameras, where some provenance metadata is written at the same time as the photo is taken, e.g. location, time and date. The same is also true for UAV images or sensor data. Automatic metadata collection avoids data entry errors and reduces the effort required. You can also set up an automated process to sanity-check the metadata when the data comes in. Extracted metadata collection Some metadata can be extracted from other systems. For example, a university’s human resource management, grant management or research management systems may be the best sources of information regarding researchers, research grants, or research projects. Manual metadata collection Some metadata requires human participation to create, and the process used depends a lot on the tools used to collect the data, for example, metadata captured in electronic lab notebooks (ELNs) or digital field books. It is also possible to build tools such as forms, which can present the metadata fields (and even pre-populate some if connected to other institutional systems) and automatically enforce the right vocabularies and data structures for each metadata record. Metadata records can be created as the data is being collected, which is preferable, or can be done later on when the researcher organises the data they have collected over some period of time, e.g. after a field trip. Metadata is often hidden away in specification statements, database structures, data models, program code or master data reference structures. This metadata needs to be made explicit and human-readable to be useful [8]. Linking metadata and data There is a range of options for storing metadata, and not all metadata may end up in one place. However, searching and managing the metadata is a lot easier if you take a structured approach [8]. Metadata within the data file The first place that metadata can go is inside the file with the data itself. There are many digital file formats that include a range of metadata fields, and some can be extended to hold almost anything. These include: ● text formats e.g. DOCX and PDF ● tabular formats e.g. XLSX ● image formats e.g. TIFF and JPEG ● video formats e.g. MPEG ● audio formats e.g. WAV ● specialist discipline formats e.g. HDF (Remote sensing). A benefit of storing metadata inside the file is that it moves with the file; the association between the data and its metadata is easy to maintain. However, the downsides are: ● Not every metadata field you want may be able to be added. ● Searching the collection is slow, as the computer has to open every single file for every single query, especially as the number of files and queries grows. ● Collection-level metadata is not easily managed. If you write a collection reference into each file and then decide to make a change to it, you have to edit every single affected file [8]. Metadata as separate files This solution will give you infinite flexibility for storing any and all kinds of metadata without restriction: write the metadata into a separate, well-structured file, (perhaps using XML or JSON), and associate that with the data file. A common approach to strengthen the filemetadata file association is to use the same filename stem, e.g. cat1.tiff is the image and cat1.xml is the metadata. This can improve the performance for searching and metadata modifications slightly. A well-organized folder structure and naming conventions are essential here! However, the downsides are: ● the data is still on the same storage medium, and you still have to open the same number of files to make queries or changes ● it increases the risk of separating the data and the metadata when files are moved [8]. Spreadsheets and databases Aggregating metadata for multiple datasets into a single spreadsheet or database gives you a lot more flexibility in searching, making changes, and in the metadata fields recorded. Collection-level changes are very easy to make in a database, as datasets that belong to a certain collection are just flagged and pointed to the collection-level record. Only one record (the collection-level record) in the database has to be changed for every dataset in that collection to be changed. The metadata is associated with the data by recording the filename and location (or URI) for the data within the metadata record, and updating this anytime the data location is changed [8]. Literaturverzeichnis [1] Longwood Research Data Management, „Data Dictionary“. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://datamanagement.hms.harvard.edu/collectanalyze/documentation-metadata/data-dictionary [2] Data Documentation Initiative Alliance, „Create a Codebook“. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://ddialliance.org/create-a-codebook [3] Bibliothek der Universität Zürich, „Daten dokumentieren“. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://www.ub.uzh.ch/de/wissenschaftlich-arbeiten/mitdaten-arbeiten/daten-dokumentieren.html [4] „Datendokumentation - Warum, was und wie?“, forschungsdaten.info. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://forschungsdaten.info/themen/beschreiben-unddokumentieren/datendokumentation/ [5] „Glossar“, forschungsdaten.info. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://forschungsdaten.info/praxis-kompakt/glossar/ [6] „Elektronische Laborbücher“, forschungsdaten.info. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://forschungsdaten.info/themen/beschreiben-unddokumentieren/elektronische-laborbuecher/ [7] Wilkinson, M., Dumontier, M., Aalbersberg, I. et al., „The FAIR Guiding Principles for scientific data management and stewardship“, 2016, Sci Data 3, 160018. doi: 10.1038/sdata.2016.18 [8] Australian Research Data Commons (ARDC), „ARDC Metadata Guide“, 1. März 2020, Zenodo. doi: 10.5281/ZENODO.6459832. [9] „Metadaten und Metadatenstandards“, forschungsdaten.info. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://forschungsdaten.info/themen/beschreibenund-dokumentieren/metadaten-und-metadatenstandards/ [10] D. Faria, K. Bösl, und M. Englund, „Data life cycle - Reusing“, RDMkit Elixir Europe. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://rdmkit.elixireurope.org/reusing#what-is-data-reuse [11] „standard operating procedure“, Merriam-Webster. Zugegriffen: 18. August 2025. [Online]. Verfügbar unter: https://www.merriamwebster.com/dictionary/standard%20operating%20procedure