<li><ahref="#general-best-practice">General Best Practice</a>
<ul>
<li><ahref="#what-do-the-metadata-describe">What do the metadata describe?</a></li>
<li><ahref="#what-is-the-language-of-the-metadata">What is the language of the metadata?</a></li>
<li><ahref="#how-should-i-specify-an-institution">How should I specify an institution?</a></li>
<li><ahref="#how-should-i-specify-a-person">How should I specify a person?</a></li>
<li><ahref="#how-should-i-handle-different-versions-of-the-same-research-data">How should I handle different versions of the same research data?</a></li>
</ul></li>
<li><ahref="#best-practice-for-specific-fields">Best practice for specific fields</a>
<p>This document is a guideline to use the <ahref="https://schema.datacite.org">DataCite Metadata Schema [external link]</a>, version 4.3.</p>
<p>It is meant for researchers, IT and library support staff in the context of the following institutions:</p>
<ul>
<li>Ludwig-Maximilians-Universität München</li>
<li>Leibniz Supercomputing Centre</li>
</ul>
<p>If you wish to publish your research data in one of these institutions, this guide helps to make your submission compliant to best practices in the context of research data management.</p>
<p>This guide is also designed to be reused by other institutions as well.</p>
<p>To create the DataCite-XML file for the project you want to describe, we recommend to you to use our <ahref="https://dhvlab.gwi.uni-muenchen.de/datacite-generator/">DataCite-Generator [external link]</a>. This tool is kept in sync with this guideline, safe for transmission times inbetween versions. If you want to create metadata for research data on a scale that is too large for manual procedures, please contact one of the institutions named above.</p>
<h1id="overview">Overview</h1>
<p>The first part, <ahref="#general-best-practice">General Best Practice</a>, is a selection of recommendations and obligations when using DataCite in general. It has been written in an FAQ-style (Frequently Asked Questions).</p>
<p>The second part, <ahref="#best-practice-for-specific-fields">Best Practice for specific fields</a>, gives more details for each of the 19 metadata fields of the DataCite metadata standard. Note that the following fields are optional/recommended in the DataCite standard, but mandatory according to this guide: <ahref="#subject">Subject</a>, <ahref="#description">Description</a>, and <ahref="#rights">Rights</a>.</p>
<p>The third part consists of four complete examples.</p>
<h1id="general-best-practice">General Best Practice</h1>
<h2id="what-do-the-metadata-describe">What do the metadata describe?</h2>
<p>Unless otherwise specified all information in the metadata concerns the research data (also denoted as "resource"), neither the project in whose context the data have been created or collected nor the metadata themselves.</p>
<h2id="what-is-the-language-of-the-metadata">What is the language of the metadata?</h2>
<ul>
<li>The default language of the metadata is English. If another language is used, the same information must additionally be specified in English.</li>
<li>Where language variations are possible (e.g. title, description, affiliations), the language should be specified by xml:lang attributes:</li>
<li>Use standardized data (e.g. controlled vocabularies) when possible. This might allow data aggregators to display the information in the language most suitable to the use case at hand.</li>
</ul>
<h2id="how-should-i-specify-an-institution">How should I specify an institution?</h2>
<ul>
<li>Follow the policy of the institution (as local as possible).</li>
<li>If no policy is findable or multiple names in multiple languages are given, use the English name in doubt.</li>
<li>In any case specify the language in which the name is given as <em>xml:lang</em> tag:</li>
<li>Affiliations are specified as appropriate at the time of creation of the resource.</li>
<li>When possible, specify a persistent identifier (PID) for the institution (Research Organization Registry (<ahref="https://ror.org/">ROR [external link]</a>), if there is no entry in ROR: International Standard Name Identifier (<ahref="http://www.isni.org/search">ISNI [external link]</a>)).</li>
<li>Add a persistent identifier for persons (Gemeinsame Normdatei (GND) and Open Researcher and Contributor iD (ORCiD)). This will make attributions robust to changes of names or affiliations:</li>
<li>Recommendation for GND-entries: Only use PF/PS GND-entries. PF/PS entries are for a specific individual (e.g. <em>the</em> Thomas Müller); PN entries could include all people with a name (e.g. all persons called Thomas Müller).</li>
<li>It is recommended to not use titles in names (as they can change).</li>
<li>If a person has multiple affiliations:
<ul>
<li>It is recommended to state only one institution (the context of the resource determines the affiliation).</li>
<li>If unavoidable, multiple affiliations can be specified in the order of importance for the dataset published.</li>
<li>An affiliation is an institution, not a project (see <ahref="#how-should-i-Specify-an-Institution">How should I specify an institution</a>).</li>
</ul></li>
</ul>
<h2id="how-should-i-handle-different-versions-of-the-same-research-data">How should I handle different versions of the same research data?</h2>
<p>Metadata can be updated without releasing a new version of the research data, but not vice versa; if the research data change, you need to update the metadata to reflect these changes.</p>
<p>If you want to publish several versions of the research data, but also want to have a point of reference for all of these publications together, we recommend to use a form of <ahref="https://help.zenodo.org/#versioning">DOI-versioning [external link]</a>:</p>
<ul>
<li>Specify a set of metadata that is valid for all versions.</li>
<li>Specify a set of metadata for each version.</li>
<li>Update all these metadata with the according references (e.g. <em>isNewVersionOf</em>, see <ahref="#relatedIdentifier">RelatedIdentifier</a> for details).</li>
</ul>
<h1id="best-practice-for-specific-fields">Best practice for specific fields</h1>
<h2id="identifier">Identifier</h2>
<ul>
<li>This field can be omitted on submission: it is mandatory according to the DataCite standard, but it will be set by the data publisher.</li>
<li>The assigned Digital Object Identifier (DOI) will be reported to you by the data publisher.</li>
<li>Consult section on <ahref="#how-should-i-specify-a-person">how to specify a person</a>.</li>
<li>Always prefer natural persons over institutions. If no natural person can be identified, you must set the attribute <em>nameType</em> to "Organizational".</li>
<li>This field can be omitted on submission: it is mandatory according to the DataCite standard, but it will be set by the data publisher, i.e. the institution that hosts the (meta)data.</li>
<li>Decision tree to pick the right <em>resourceTypeGeneral</em>:
<ol>
<li>If the data submission contains heterogeneous data, consider publishing it in separate data publications or (less preferred) use "Collection". If the data are homogeneous, proceed with 2.</li>
<li>If the data are movies, images or sound files use "Audiovisual", "Image" or "Sound", respectively. If not, proceed with 3.</li>
<li>If the data are a digital, interactive representations of some real-world phenomena (e.g. trained models in the context of machine learning) use "Model". If not, proceed with 4.</li>
<li>If the data are descriptions of a workflow (e.g. in the common workflow language), use "Workflow". If not, proceed with 5.</li>
<li>If the data are source code files (incl. configuration and built artefacts), use "Software". If not, proceed with 6.</li>
<li>If the data have a fixed structure (e.g. table-like), use "Dataset". If not, proceed with 7.</li>
<li>If the data are text files, use "Text". If not, proceed with 8.</li>
<li>Use "Other".</li>
</ol></li>
<li>As a consequence, only use these values for <em>resourceTypeGeneral</em>:
<ul>
<li>Audiovisual</li>
<li>Collection</li>
<li>Dataset</li>
<li>Image</li>
<li>Model</li>
<li>Software</li>
<li>Sound</li>
<li>Text</li>
<li>Workflow</li>
<li>Other</li>
</ul></li>
<li>These <em>ResourceTypes</em> should <strong>not</strong> be used:
<ul>
<li>DataPaper</li>
<li>Event</li>
<li>InteractiveResource</li>
<li>PhysicalObject</li>
<li>Service</li>
</ul></li>
<li>Note: Only items with the <em>resourceTypeGeneral</em> "Dataset" will be included in the Google Dataset Search. All other types are currently not supported.</li>
<li>The following subject annotations are mandatory (must occur at least once):</li>
</ul>
<table>
<colgroup>
<colstyle="width: 12%"/>
<colstyle="width: 18%"/>
<colstyle="width: 20%"/>
<colstyle="width: 48%"/>
</colgroup>
<thead>
<trclass="header">
<th>Type of Subject</th>
<th>Standard</th>
<th>Type of standard</th>
<th>Usage hint</th>
</tr>
</thead>
<tbody>
<trclass="odd">
<td>Discipline</td>
<td>DDC</td>
<td>Classification</td>
<td>Add 3 digits DDC as specific as possible followed by the English term for the discipline (<ahref="https://www.oclc.org/content/dam/oclc/dewey/resources/summaries/deweysummaries.pdf">Canonical Source [external link]</a>)</td>
</tr>
<trclass="even">
<td>Keywords</td>
<td>Wikidata Q-ID and GND</td>
<td>Keyword</td>
<td>Wikidata and GND terms are both mandatory, including redundancy (if an appropriate entry does not exist contact the ITG). Use <ahref="https://www.wikidata.org">Wikidata-Search [external link]</a> and <ahref="http://swb.bsz-bw.de/DB=2.104/LNG=EN/">GND-Search [external link]</a> to find the appropriate identifiers.</td>
</tr>
</tbody>
</table>
<p>There should be no overlap between the discipline specifier(s) and the keywords.</p>
<h3id="geotagging">Geotagging</h3>
<p>Specifying the location via subject is mandatory, if applicable to the resource:</p>
<ul>
<li>Canonical source for geonames is the <ahref="http://www.geonames.org/export/web-services.html">GeoNames Service [external link]</a> (a registration for API access is necessary).</li>
<li>See <ahref="#geolocation">GeoLocation section</a> for a more detailed specification.</li>
<li>It is recommended to always qualify subjects by URL or scheme name. A good starting point to research existing schemes is <ahref="http://www.bartoc.org/de">Bartoc.org [external link]</a> - Basel Register of Thesauri, Ontologies & Classifications. Unqualified subjects (not controlled by a controlled vocabulary, ontology or any other standard for the subject terms) are often useless for research data aggregators due to ambiguities.</li>
<li>This field is recommended if the data are published with a free license.</li>
<li>If the license specified via the <ahref="#rights">Rights</a> field restricts the usage in a way, that possibly necessitates interaction with the rightsholder, contributor of type "RightsHolder" must be specified. Examples of free licenses are CC-0, CC-BY, or CC-SA; non-free licenses are for example CC-NC or CC-ND.</li>
<li>Consult the section on <ahref="#how-should-i-specify-a-person">how to specify a person</a>.</li>
<li>If contributors change over versions, the version metadata should only include the actual contributors of the updated version. A metadata set representing all versions of the dataset (including links to the versions) can include all contributors with the dates of participation, see <ahref="#how-should-i-handle-different-versions-of-the-same-research-data">how to handle different versions of the research data</a>.</li>
<li>Duplicate mentions between Creator and Contributor are unproblematic.</li>
<li>If a person has multiple roles, it is recommended to identify the most important role of that person and select only one.</li>
<li>Be as specific as possible (a "ProjectLeader" is also considered to be a "ProjectMember", but "ProjectLeader" carries more information). Use generic role descriptions only when nothing else fits.</li>
<li>The following roles are recommended:</li>
</ul>
<table>
<colgroup>
<colstyle="width: 18%"/>
<colstyle="width: 81%"/>
</colgroup>
<thead>
<trclass="header">
<th>Option</th>
<th>Description from DataCite standard (italics) and usage hints</th>
</tr>
</thead>
<tbody>
<trclass="odd">
<td>ContactPerson</td>
<td><em>Person with knowledge of how to access, troubleshoot, or otherwise field issues related to the resource.</em></td>
</tr>
<trclass="even">
<td>DataCollector</td>
<td><em>Person/institution responsible for finding, gathering/collecting data under the guidelines of the author(s) or Principal Investigator (PI).</em></td>
</tr>
<trclass="odd">
<td>DataCurator</td>
<td><em>Person tasked with reviewing, enhancing, cleaning, or standardizing metadata and the associated data submitted for storage, use, and maintenance within a data centre or repository.</em></td>
</tr>
<trclass="even">
<td>HostingInstitution</td>
<td><em>Typically, the organisation allowing the resource to be available on the internet through the provision of its hardware/software/operating support.</em></td>
</tr>
<trclass="odd">
<td>ProjectLeader</td>
<td><em>Person officially designated as head of project team or sub-project team instrumental in the work necessary to development of the resource.</em></td>
</tr>
<trclass="even">
<td>ProjectManager</td>
<td><em>Person officially designated as manager of a project. Project may consist of one or many project teams and sub-teams.</em></td>
</tr>
<trclass="odd">
<td>ProjectMember</td>
<td><em>Person on the membership list of a designated project/project team.</em> All persons with a contract in the context of the project which produced the resource.</td>
</tr>
<trclass="even">
<td>Researcher</td>
<td><em>A person involved in analyzing data or the results of an experiment or formal study. May indicate an intern or assistant to one of the authors who helped with research but who was not so “key” as to be listed as an author.</em></td>
</tr>
<trclass="odd">
<td>RightsHolder</td>
<td><em>Person or institution owning or managing property rights, including intellectual property rights over the resource.</em> Mandatory for non-free licenses; person or institution that owns the rights listed in field <ahref="#rights">Rights</a>.</td>
</tr>
<trclass="even">
<td>WorkPackageLeader</td>
<td><em>The Work Package Leader is responsible for ensuring the comprehensive contents, versioning, and availability of the Work Package during the development of the resource.</em></td>
<li>Time periods can be specified by specifying the start date and the end date separated by a slash.</li>
<li>The following types should be filled-out by the data producer:
<ul>
<li>Collected: Time range when the resource was arranged (not necessarily identical to the time range when the resource was created).</li>
<li>Created: First version of a resource, cannot be identical with updated.</li>
<li>Updated: If the resource is a newer version, cannot be identical with created.</li>
</ul></li>
<li>The following types are set by the publisher:
<ul>
<li>Submitted: point in time when the data were recieved by the data publisher.</li>
<li>Accepted: point in time when the data publisher decides to publish the data.</li>
<li>Issued: long format of the field <ahref="#publicationyear">PublicationYear</a>, point in time when a publisher publishes the data; should be set.</li>
<li>Available: only use in the context of embargo periods (this is not recommended).</li>
<li>Withdrawn: point in time when the publisher retracts the data publication.</li>
</ul></li>
<li>For dates describing the period the resource covers use "Other" and add "Coverage" as a description.</li>
<li>It is recommended to use the attribute <em>dateInformation</em> for disambiguation, if multiple dates with the same type are specified.</li>
<li>"CopyRighted" as a <em>dateType</em> will not be used.</li>
<li>The relations are always specified from the perspective of the described resource (if the metadata describe a publication A and this publication cites another publication B, the relation is A cites B and not B IsCitedBy A).</li>
<li>Only use these <em>relationTypes</em>:</li>
</ul>
<tablestyle="width:100%;">
<colgroup>
<colstyle="width: 21%"/>
<colstyle="width: 23%"/>
<colstyle="width: 31%"/>
<colstyle="width: 22%"/>
</colgroup>
<thead>
<trclass="header">
<th>relationType</th>
<th>Definition (Derived from DataCite Metadata Schema v4.3)</th>
<th>Example</th>
<th>Usage</th>
</tr>
</thead>
<tbody>
<trclass="odd">
<td>Describes</td>
<td>indicates A describes B</td>
<td>a README "describes" a dataset</td>
<td></td>
</tr>
<trclass="even">
<td>IsDescribedBy</td>
<td>indicates A is described by B</td>
<td>a dataset "IsDescribedBy" a README</td>
<td></td>
</tr>
<trclass="odd">
<td>HasPart</td>
<td>indicates A is a portion of B; may be used for elements of a series</td>
<td>a container "HasPart" a dataset</td>
<td>use to create hierarchical structures</td>
</tr>
<trclass="even">
<td>IsPartOf</td>
<td>indicates A includes the part B</td>
<td>a dataset "IsPartOf" a container</td>
<td>use to create hierarchical structures</td>
</tr>
<trclass="odd">
<td>HasMetadata</td>
<td>indicates resource A has additional metadata B</td>
<td>a dataset "HasMetadata"</td>
<td>use to add additional metadata to a dataset e.g. domain-specific metadata</td>
</tr>
<trclass="even">
<td>IsMetadataFor</td>
<td>indicates additional metadata A for a resource B</td>
<td>a metadata file "IsMetadataFor" a dataset</td>
<td>use to add additional metadata to a dataset e.g. domain-specific metadata</td>
</tr>
<trclass="odd">
<td>HasVersion</td>
<td>indicates A has a version B</td>
<td>a dataset "HasVersion"</td>
<td>use for relating a non-versioned or abstract resource to a versioned resource e.g. a snapshot; alternative usage: Use if exact order of the versions is not known</td>
</tr>
<trclass="even">
<td>IsVersionOf</td>
<td>indicates B is a version of A</td>
<td>a dataset "IsVersionOf" of a dataset</td>
<td>use for relating a versioned resource (e.g. a snapshot) to a non-versioned or abstract resource; alternative Usage: Use if exact order of the versions is not known</td>
</tr>
<trclass="odd">
<td>IsNewVersionOf</td>
<td>indicates A is a new edition of B, where the new edition has been modified or updated</td>
<td>a dataset "IsNewVersionOf" a dataset</td>
<td>use to order versions</td>
</tr>
<trclass="even">
<td>IsPreviousVersionOf</td>
<td>indicates B is a previous edition of A</td>
<td>a dataset "IsPreviousVersionOf" a dataset</td>
<td>use to order versions</td>
</tr>
<trclass="odd">
<td>IsSourceOf</td>
<td>indicates A is a source upon which B is based</td>
<td>a dataset A "IsSourceOf" a dataset B</td>
<td>use to express that A has been refined or modified by B</td>
</tr>
<trclass="even">
<td>IsDerivedFrom</td>
<td>indicates B is a source upon which A is based</td>
<td>a dataset B "IsDerivedFrom" a dataset A</td>
<td>use to express that B is the result of refining or modifying the content of A</td>
</tr>
<trclass="odd">
<td>References</td>
<td>indicates B is used as a source of information for A</td>
<td>an article "References" a dataset</td>
<td></td>
</tr>
<trclass="even">
<td>IsReferencedBy</td>
<td>indicates A is used as a source of information by B</td>
<td>a dataset "IsReferencedBy" an article</td>
<td></td>
</tr>
<trclass="odd">
<td>IsVariantFormOf</td>
<td>indicates A is a variant or different form of B</td>
<td>a dataset (xml-file) "IsVariantFormOf" a dataset (csv-file) with the same content</td>
<td></td>
</tr>
<trclass="even">
<td>IsIdenticalTo</td>
<td>indicates that A is identical to B, for use when there is a need to register two separate instances of the same resource</td>
<td>a dataset in location A "IsIdenticalTo" a dataset in location B</td>
<td>use for a resource that is the same as the registered resource but is saved in another location, maybe another institution</td>
</tr>
<trclass="odd">
<td>IsSupplementTo</td>
<td>indicates that A is a supplement to B</td>
<td>a dataset "IsSupplementTo" an article</td>
<td></td>
</tr>
<trclass="even">
<td>IsSupplementedBy</td>
<td>indicates that B is a supplement to A</td>
<td>an article "IsSupplementedBy" a dataset</td>
<td></td>
</tr>
<trclass="odd">
<td>Documents</td>
<td>indicates A is documentation about B; e.g. points to software documentation</td>
<td>a data management plan (DMP) "Documents" a dataset</td>
<td></td>
</tr>
<trclass="even">
<td>IsDocumentedBy</td>
<td>indicates B is documentation about/explaining A; e.g. points to software documentation</td>
<td>a dataset "IsDocumentedBy" a data management plan (DMP)</td>
<td></td>
</tr>
</tbody>
</table>
<ul>
<li>Make sure, that links from the described resource are mirrored in in the referenced resource. For example, make sure that a paper referencing the data includes a formal link to the data set (and vice versa). This also applies to all reciprocal <em>relationTypes</em> (e.g. "IsNewVersionOf" and "IsPreviousVersionOf").</li>
<li>The <em>relationIdentifierType</em> offers a list containing the most important identifier types to specify the relation (e.g. DOI, ISSN, PURL, URN).</li>
<li>If <em>relationType</em> "HasMetadata" is chosen, please specify additionally the <em>relatedMetadataSchema</em>, <em>schemeURI</em> and <em>schemeType</em> (e.g. XSD, DDT) of the related identifier.</li>
<li>The publisher may curate the list of <em>relatedIdentifiers</em> (e.g. adding relevant related resources over time on a best effort basis).</li>
<li>This field is mandatory, whereas the DataCite standard only recommends it: There has to be at least one entry of type "Abstract" in English.</li>
<li>Always specify the used language (<em>xml:lang attribute</em>) of each description.</li>
<li>If there are descriptions in more than one language, the content may be different (no literal translation required).</li>
<li>Each description has a limit of 300 words.</li>
<li>Description of <em>descriptionType</em> "Methods" is optional. Best practice: use keywords from <ahref="https://github.com/UB-LMU/DataCite_BestPracticeGuide/blob/master/Description_Methods.md">this controlled list</a>, separated by comma. This list will either be extended in the future or replaced by a controlled vocabulary (in this case mappings will be provided).</li>
<li>Description of <em>descriptionType</em> "TechnicalInfo" is optional. Best practice: use keywords from <ahref="https://github.com/UB-LMU/DataCite_BestPracticeGuide/blob/master/Description_TechnicalInfo.md">this controlled list</a>, separated by comma. This list will either be extended in the future or replaced by a controlled vocabulary (in this case mappings will be provided). Additionally, data producers could consider creating a README and link it via the <ahref="#relatedIdentifier">RelatedIdentifier</a> field.</li>
<li>Describes the resource (e.g. where an image has been taken or where a sensor is located), <em>not</em> the related project or institute, if the former is not applicable, do <em>not</em> use it for the latter.</li>
<li><em>geoLocationPlace</em> must be identical to payload of the according GeoNames field in the subjects, consult the <ahref="#geotagging">geotagging</a> subsection.</li>
<li>Canonical source for coordinates is the <ahref="http://www.geonames.org/export/web-services.html">GeoNames Service [external link]</a>.</li>
<spanid="cb20-3"><ahref="#cb20-3"aria-hidden="true"></a><spanclass="kw"><geoLocationPlace></span>Hall in Tirol<spanclass="kw"></geoLocationPlace></span></span>
<li>Use MimeType format as specified in <ahref="https://tools.ietf.org/html/rfc2046">RFC 2646 [external link]</a>, possible values should be taken from <ahref="https://www.iana.org/assignments/media-types/media-types.xhtml">the IANA list of MediaTypes [external link]</a>.</li>
<li>Specify in this order (skip if it does not imply):</li>
</ul>
<ol>
<li>If files are compressed, specify the mime type of the compression first as an suffix to the mimetype (e.g. text/xml+zip).</li>
<li>If files are in an archive, specify the mime type of the archive format.</li>
<li>Specify each mime-type in an own field in alphabetical order, do not repeat mime-types.</li>
<li>This field is mandatory, whereas the DataCite standard specifies it as optional.</li>
<li><em>RightsURI</em> must be set.</li>
<li>Use only ONE license for data and code each (to avoid inconsistencies).</li>
<li>Use <ahref="https://spdx.org/license-list/">SPDX [external link]</a> to unambiguously specify the license used.</li>
</ul>
<p>Guidance for using a license:</p>
<ul>
<li>Recommendation: <ahref="https://creativecommons.org/">Creative Commons (CC) [external link]</a> as license for data and <ahref="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 license [external link]</a> for software.</li>
<li>You should not use CC licenses with the NC or ND extension (although submissions with these extensions are accepted).</li>
<li>It is recommend to use only one type of licence, not several at the same time.</li>
<li>In case both research data and software code need to be licensed in one publication (which is not recommended, consider two data publications, see <ahref="#resourcetype">ResourceType</a>), specify the licenses in the order data, software.</li>
<li>For further license options consult <ahref="https://choosealicense.com/">Choose a license [external link]</a> or the <ahref="https://creativecommons.org/choose/">CC license helper [external link]</a>.</li>
<p>The Digital Encyclopedia of Bavarian Musicians (Bayerisches Musiker-Lexikon Online, short BMLO) refers as a musicological model project. The BMLO offers a digital biographical dictionary focussing on music science, furthermore it enriches the presented personalities of Bavarian history of music by implementing further information, gathered from biographical literature, archives, libraries and digital collections. In this way, the BMLO constitutes the core of an interconnected, virtual cluster for history of music. Currently, 24621 out of a total of 27818 records is presented on the web. As parts of this semantic network should also be mentioned the Munich Dictionary of Musik (Münchner Musiklexikon, short MUK), which serves since 2010 as a encyclopedia for music corporations with a linkage to Munich, as well as LOCI, a geographic database for music, culture and history, founded in 2012.</p>
<p>The project VerbaAlpina seeks to investigate the Alpine region in its cultural and historical linguistic unity from a transnational perspective through selective analyses. For this purpose, a comprehensive, multilingual research environment will be set up using up-to-date media technology (database, georeferenced cartography, internet, data collection with social software). The guiding intention is to analyze already existing data from linguistic atlases and dictionaries (partly difficult of access) which is first structured and linguistically annotated according to certain principles to fit the database of VerbaAlpina.</p>
<p><ahref="https://github.com/UB-LMU/DataCite_BestPracticeGuide/blob/master/examples/example_2_va.xml">Verba Alpina metadata example 1</a><ahref="https://github.com/UB-LMU/DataCite_BestPracticeGuide/blob/master/examples/example_3_va.xml">Verba Alpina metadata example 2</a></p>
<h2id="climex">ClimEx</h2>
<p>The ClimEx project investigates the effects of climate change on meteorological and hydrological extreme events and implications for water management in Bavaria and Québec. It especially consists of two new aspects:</p>
<ul>
<li><p>An ensemble of 50 transient runs of the canadian general circulation model CanESM2 (~200km resolution) from 1950 to 2100, resulting in 7500 years of modelled climate. As each of these runs is initialized with only slightly altered starting conditions, this ensemble can be interpreted as (modelled) natural variability. The CanESM2 then drives the regional climate model CRCM5 (~11km resolution) for a domain that covers most of central Europe. Both models are internationally established and widely used in the climate science community.</p></li>
<li><p>A physically based hydrological model (WaSiM) is driven by this climate input for the entire hydrological Bavaria at very high temporal and spatial resolution of 3 hours and 500m to investigate both climate change impacts and natural variability of extreme events, especially floods.</p></li>
</ul>
<p>ClimEx further strengthens the international collaboration between Bavaria and Québec as research facilities, universities and public water agencies intensify their former cooperation approaches.</p>
<p><ahref="https://github.com/UB-LMU/DataCite_BestPracticeGuide/blob/master/examples/example_4_climex.xml">ClimEx metadata example [external link]</a></p>