Após os metadados mapeados eles deveriam aparecer no código da página do item?
1 curtida
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
2 curtidas
mateus.m.luna:
Issue
Oi pessoal, só pra comentar que me interesso bastante sobre essa funcionalidade de “Como citar”. Abraços!
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…
opened 07:23PM - 05 Jun 19 UTC
aggregation
Acervo em Rede
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_
