# Importing Alternative Metadata standards/cores **URL:** \ **Category:** Suporte\ **Tags:** metadados, importadores\ **Created:** [Fevereiro 19, 2022, 11:35pm UTC](https://tainacan.discourse.group/t/importing-alternative-metadata-standards-cores/744 "2022-02-19T23:35:58Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![snachodog](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/snachodog/32/678_2.png) [@snachodog](https://tainacan.discourse.group/u/snachodog)\ **Post date:** [Fevereiro 19, 2022, 11:35pm UTC](https://tainacan.discourse.group/t/importing-alternative-metadata-standards-cores/744/1 "2022-02-19T23:35:58Z")
Hello, I am configuring Tainacan for a paleontology museum - specifically for the fossil collection. When creating a collection, I see the option to use Dublin Core for default metadata types. Is it possible to import other “Cores” or metadata standards to Tainacan so I can use it as a template for new collections? If so, is there a template or process I can refer to (perhaps from the Dublin Core) to properly import the new one? I’m specifically hoping to implement the [Darwin Core](https://dwc.tdwg.org/) for the collection. Thanks/Obrigado, Steve ---
**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\ **Post date:** [Fevereiro 21, 2022, 12:02pm UTC](https://tainacan.discourse.group/t/importing-alternative-metadata-standards-cores/744/2 "2022-02-21T12:02:16Z")
Hey @snachodog, welcome to our forum! Dublin core is the default available from “core” and the idea is that others should be able to implement via _plugins for the plugin_. While we certainly need to improve documentation for this, we have some basic instruction here: > **[Tainacan Wiki](https://tainacan.github.io/tainacan-wiki/#/dev/mapping-standards)** > > Home for Tainacan's Documentation You cal also check out this plugin, which does a similar job for a standard that is used in Brazilian museums: > **[GitHub - tainacan/tainacan-mappers-ibram-inbcm: Tainacan Mappers IBRAM INBCM](https://github.com/tainacan/tainacan-mappers-ibram-inbcm/)** > > Tainacan Mappers IBRAM INBCM. Contribute to tainacan/tainacan-mappers-ibram-inbcm development by creating an account on GitHub. Of course in the future this should be easier. There are some features that need some work regarding mappers, we actually have an issue opened for it: > > > This issue holds the discussion for improvements in the way we deal with mappers… on Tainacan. More specific issues will be created for each step of the refactor and new implementations needed. > > The current implementation is presented here in the docs: https://github.com/tainacan/tainacan/blob/develop/docs/exporting-and-exposing.md > > \## Overview > > Today Tainacan mappers only support a 1 to 1 mapping. This means that each metadatum in can only point to one metadatum in a mapping standard. Also, only one metadatum will be pointing to a metadatum in the mapping standard. > > We need to have more flexibility on this and, also, some additional features that we dont have yet. > > We are going to list all the features here, even though some of them will not be prioritized, because we will need to refactor the way this mappings are saved in the database, so it is a good idea to do this refactor with everything we want to support in the future in mind > > \### Many to many mapping > > First of all, we need the freedom to map many metadata to many metadata in the standard. > > For example, if I have in my collection a \`author\` and a \`co-author\`, I should be able to map these 2 metadata to the same \`dc:creator\` field in DublinCore. When exposed, this item would have 2 entries for this field. > > Also, I should be able to map the same metadatum to 2 or more different fields in the mapping standard > > Examples: > > \`\`\` > \[My field\] ----- mapped to ---\> \[dc:creator\] > ----- also mapped to ---\> \[dc:publisher\] > \`\`\` > > \`\`\` > \[My field 1\] ----- mapped to ---\> \[dc:creator\] > \[My field 2\] ----- mapped to ---\> \[dc:creator\] > \`\`\` > > \### Qualifiers > > Some standards implement qualifiers for their fields. For example, DublinCore: http://www.dublincore.org/specifications/dublin-core/dcmes-qualifiers/ > > It's important that we give users the ability to also choose a qualifier, along with the target field in the standard, when mapping to a standard. > > Example: > > \`\`\` > \[My field\] ----- mapped to ---\> \[dc:relation\] \[qualifier: Is Part Of\] > \`\`\` > > \### Concatenation > > Users should also be able to concatenate 2 or more metadata into one single value to map them to a field in the standard. > > Example: > > \`\`\` > \[My field 1\] ----- all mapped to ---\> \[dc:creator\] > AND \[My field 2\] > concatenated with "," > \`\`\` > > \### Extraction > > Users should also be able to extract part of the value of a metadatum and map only this fraction. > > They would then have to write a regular expression that would capture part of the value. Frontend could have a button "test expression" that would load sample values from the database (using the facet endpoint) and apply the regexp to display the result of the extraction. > > \`\`\` > \[My field 1\] ----- mapped to ---\> \[dc:creator\] > extractated only characters before first comma > \`\`\` > > \### Transformations > > Last, it would be great to give users the ability to write transformations to the mappings. This would allow them to transform the values, for example, converting all characters to lower case, formatting dates, etc. > > This could be done writing a replace regular expression or a simple script... > > We could also have pre-defined transformations (such as toLowerCase) and add new ones via plugins. > > \`\`\` > \[My field 1\] ----- mapped to (transform to lowercase) ---\> \[dc:creator\] > \`\`\` > > \## Roadmap > > Now we can prioritize everything and start with the most simple and necessary features. > > \## First: Refactor > > First of all, even for the most simple new feature, we need to refactor the way Mapping Standards are declared, to support qualifiers for example, and the way the mappings are saved in the database. > > \_When issue is created, link it here\_ > > \## Second: Many to many > > \_When issue is created, link it here\_ > > \## Third: Qualifiers > > \_When issue is created, link it here\_ That said, while mappers are a useful path to start with a collection preset or later map the collections metadata to a certain standard, nothing prevents you from creating your collection metadata following the rules of the Darwin Core from scratch, for example 😉 ---
**Author:** ![snachodog](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/snachodog/32/678_2.png) [@snachodog](https://tainacan.discourse.group/u/snachodog)\ **Post date:** [Fevereiro 21, 2022, 6:05pm UTC](https://tainacan.discourse.group/t/importing-alternative-metadata-standards-cores/744/3 "2022-02-21T18:05:03Z")
Perfect! Thank you for guiding me to the right resources. I am excited for the implementation of Tainacan for my organization! ---
**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\ **Post date:** [Fevereiro 21, 2022, 7:53pm UTC](https://tainacan.discourse.group/t/importing-alternative-metadata-standards-cores/744/4 "2022-02-21T19:53:37Z")
Nice! Let us know if you find any other challenge. We’re curious to hear about your project, if you wish to put it as a Use Case once its ready, we have a page for it: [Tainacan Showcase – Tainacan](https://tainacan.org/en/tainacan-showcase/) Good luck 👋🏼