# Metadados publicados no código do item **URL:** \ **Category:** Novas features e melhorias\ **Tags:** metadados, mapeadores\ **Created:** [Junho 6, 2022, 2:29pm UTC](https://tainacan.discourse.group/t/metadados-publicados-no-codigo-do-item/885 "2022-06-06T14:29:48Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![marcos.sigismundo](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/marcos.sigismundo/32/1924_2.png) [@marcos.sigismundo](https://tainacan.discourse.group/u/marcos.sigismundo)\ **Post date:** [Junho 6, 2022, 2:29pm UTC](https://tainacan.discourse.group/t/metadados-publicados-no-codigo-do-item/885/1 "2022-06-06T14:29:48Z")
Após os metadados mapeados eles deveriam aparecer no código da página do item? Para servir de exemplo, abaixo um print do Dspace do repositório da UnB. Com os metadados no código, o Zotero consegue catalogá-los. ![image](https://global.discourse-cdn.com/free1/uploads/tainacan/original/1X/551234fa9648faaac979547a2b22dd4a579fb88b.png) ---
**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:** [Junho 6, 2022, 2:34pm UTC](https://tainacan.discourse.group/t/metadados-publicados-no-codigo-do-item/885/2 "2022-06-06T14:34:46Z")
Issue criada! > > > We could to this here: > https://github.com/tainacan/tainacan/blob/aa1077b8262e74…cedde606048dcf32b0181f221a/src/classes/theme-helper/class-tainacan-theme-helper.php#L811 > > As suggested in this topic: > https://tainacan.discourse.group/t/metadados-publicados-no-codigo-do-item/885 > > Just need to think if there should be any kind of standard so it could be valid for other mappers. ---
**Author:** ![marcos.sigismundo](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/marcos.sigismundo/32/1924_2.png) [@marcos.sigismundo](https://tainacan.discourse.group/u/marcos.sigismundo)\ **Post date:** [Junho 6, 2022, 3:00pm UTC](https://tainacan.discourse.group/t/metadados-publicados-no-codigo-do-item/885/3 "2022-06-06T15:00:56Z")
Obrigado Mateus, apenas complementando, estou sugerindo que todos os metadados públicos do item estejam publicados no código da página do item. Na imagem ilustro a ideia com um print do código do Dspace que estrutura os metadados Dublin Core na ordem em que estão no registro do item. Esse comportamento também é seguido por outros repositórios, como o Omeka. Dessa maneira, softwares como o Zotero conseguem catalogar os itens. Suponho ainda que pode ser um caminho para criar a funcionalidade “Como citar”. Muito obrigado ---
**Author:** ![elias.machado](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/elias.machado/32/130_2.png) [@elias.machado](https://tainacan.discourse.group/u/elias.machado)\ **Post date:** [Junho 6, 2022, 6:11pm UTC](https://tainacan.discourse.group/t/metadados-publicados-no-codigo-do-item/885/4 "2022-06-06T18:11:09Z")
> [@mateus.m.luna](#): > > Issue Oi pessoal, só pra comentar que me interesso bastante sobre essa funcionalidade de “Como citar”. Abraços! ---
**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:** [Junho 6, 2022, 6:22pm UTC](https://tainacan.discourse.group/t/metadados-publicados-no-codigo-do-item/885/5 "2022-06-06T18:22:38Z")
Sim, boto fé @marcos.sigismundo. O que precisamos pensar é em como descrever estas tags para os metadados que não forem mapeados ou para padrões diferentes. Talvez isso deva ser algo definido pelo próprio “padrão”. Vale lembrar que tem toda uma gama de melhorias que podemos fazer para estes mapeadores também… > > > 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\_