Differences

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

--- wiki:s1.0 [2025/09/01 11:29] – [Motivation for this Recommendation:] 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 elements - such as "variable" or "method" -  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 (i.e., different "components"): here the measurement context (air), and the unit (°C). Since for almost all metadata elements there is room for interpretation about which specific information about a dataset is expected to be described, it is important to establish binding standards for which information (components) belong to the given metadata element. The different components of a metadatum can either be listed in separated fields, or alternatively, be listed as subsequent text string within one field following a community agreed syntax.
-=====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====