sromkey
commented
1 month ago Hello @marceloalencar and @tatycs , thanks for this detailed report. For importing the metadata into Archivematica, have you considered this methodology? It may not be perfect for your situation but worth experimenting with: https://archivematica.org/en/docs/archivematica-1.15/user-manual/transfer/import-metadata/#metadata-xml-validation If the main goal is having the metadata transferred to AtoM it's actually more an issue on the AtoM side of the workflow, and its ability to interpret what it receives in an Archivematica METS file during DIP upload. Otherwise some kind of middleware to do a transformation might be a solution. Because Archivematica does have the capability to accept non-DC metadata in XML formats, as described in the link above, and the ability for AtoM to interpret it is really an AtoM limitation, I'm going to close the issue with this comment but feel free to re-open if you feel there is something that Archivematica needs to be able to do in this situation.
Please describe the problem you'd like to be solved A common question from institutions in Brazil has been about the ability to integrate ISAD(G) metadata support into metadata.csv.
Currently, Archivematica supports the import and manual entry of Dublin Core descriptive metadata (DCMI Metadata Terms), which are transposed to the METS file. Each METS file includes two descriptive metadata sections (dmdSec), containing the Dublin Core metadata parsed from the metadata.csv and marked with an MDTYPE of "DC". While non-Dublin Core metadata can be included, it is marked with an MDTYPE of "OTHER" and is not integrated or utilized effectively within Archivematica or when sending DIPs to AtoM.
When a DIP is sent to AtoM, only Dublin Core metadata is parsed into the appropriate fields in the AtoM descriptive template, and descriptive metadata is indexed in the Archival Storage tab in Archivematica. However, this system does not adequately support the use of ISAD(G) or NOBRADE (a similar standard used in Brazil), particularly in creating levels of description which are essential for organizing archival records. Additionally, ISAD(G) offers a broader array of descriptive elements compared to Dublin Core, which facilitates more detailed representation of documents, enhances search and retrieval capabilities, and provides richer contextual information.
This current limitation affects the detailed representation of archival documents, especially when more comprehensive metadata standards such as ISAD(G) or NOBRADE (widely used in Brazil) are required. These standards are crucial for creating hierarchical levels of description, enhancing search and retrieval functionalities, and providing richer contextual information.
Describe the solution you'd like to see implemented Adding ISAD(G) support in metadata.csv would greatly enhance metadata management capabilities, allowing for better structuring and easier integration with systems like AtoM, particularly for regions like Brazil where ISAD(G) and NOBRADE are more commonly used. This enhancement will allow Archivematica to recognize and utilize ISAD(G) metadata similarly to how it handles Dublin Core, facilitating broader and more effective metadata management.
Describe alternatives you've considered Parallel solutions being developed using other software, could potentially lead to a fragmented ecosystem. Integrating ISAD(G) directly into Archivematica and AtoM would resolve these limitations and significantly enhance the platform's metadata management capabilities, ensuring a unified and efficient approach without the need for third-party software.
Additional context Related: #1531 Co-authored-by: @tatycs
For Artefactual use:
Before you close this issue, you must check off the following: