Differences

This shows you the differences between two versions of the page.

--- wiki:s1.0 [2025/09/01 10:26] – dkottmeier
+++ wiki:s1.0 [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-**Recommendation **
-======Recommendation to decompose metadata according to community-recognized frameworks======
-=====Description=====
-Status: Under development, Date: 2025/07/07 10:18, Version: 001
-=====Motivation for this Recommendation: =====
-Many metadata categories consist of several **components**. A variable such as “air temperature (°C)”, for example, does not only describe the measured quantity (temperature) itself but also contains additional information: the measurement context (air), and the unit (°C). Since for almost all metadata categories - such as Variable or Method - there is room for interpretation about which specific information about the dataset is meant, it is important to establish binding standards for their structure. It is crucial to define which elements should be included in a data description (i.e., in a given metadata categorie) and to provide a clear specification of what exactly is meant in each case.
-Furthermore, if consistent naming is to be ensured, for example in a data portal, a **syntax** should be defined that specifies the order and phrasing in which the individual components of a given metadata category are combined. For instance, one could decide that the metadata category Measurement Instrument must always include the device type, manufacturer, and model as fundamental components of the data description. When naming the Measurement Instrument, these three attributes should consistently be listed in the order Type, Manufacturer, Model (comma-separated). This would ensure that identical models are always represented in the same way.
-ISO_ Metadatenelement
-Feld
-=====Recommendation ====
-[shortened from below]
-[Format: Wer! macht was! wo! wann! unter welchen Voraussetzungen!]
-=====Binding Convention: =====
-^                         ^ mandatory  ^ conditional	          ^ optional ^
-^ Helmholtz FAIR Principle|            |      |          |
-=====Precondition for Implementation: =====
-=====Related Recommendations =====
-Parent:
-Dependent:
-Other: none
-=====Contributors=====
-Names of contributors to this recommendation
-=====Content=====
-====1. Explanation of the Background and Benefits of the Recommendation ====
-__About__
-__History and structure__
-__Current Use of ...__
-__Motivation__
-====2. Possible alternative solutions====
-====3. Consideration of the advantages and disadvantages of implementing the recommendation====
-(quality of content, limitations, interoperability, sustainability:
-expected future dissemination / technical availability / funding)
-====4. The Recommendation====
-**Instruments/Devices**
-**Manufacturers’ names** should always be reported as they were //valid at the time of production//. In practice, this means using the name that appears on the instrument label or in the official manual.
-  * If an instrument is marketed under a brand name, the brand (e.g., Thermo Scientific) not the parent company name (Thermo Fisher Scientific) should be used. If no brand is indicated, the official company name should be given.
-  * If the instrument was produced by a subsidiary company, use the subsidiary’s name at the time of production (e.g., Spectra GmbH), not the later acquirer (X Corp.). Subsequent changes, such as company sales, mergers, or renamings, should //not// be reflected in the metadata.
-  * In general, the most granular level available (e.g., the concrete brand or subsidiary rather than only the corporate group) should be recorded to ensure precision and avoid ambiguity.
-**Instrument model names** and numbers should be reproduced exactly as they are written on the instrument label or in the accompanying manual, including spaces, special characters, and capitalization. This ensures consistency and guarantees that identical instruments are always represented in the same way across datasets.
-====5. Naming of communities that have already implemented the recommendation====
-====6. Documentation of the test to validate correct implementation====
-====7. Examples of Instances====
-Comment: HIER ERLÄUTERN, WIE in XML oder JSON dokumentiert werden; Beispiel.. V´Wie verpackt, um im Protokoll zu packen. unterschiedlich je nach Metadatenschemata; z.B. PANGAEA "kommaseparariert in einem Feld" vs SMS or Registry"
-====8. Further Information====
-===References===
-===Relevant Community Recommendations===
-====9. History of this document====