Updating digital objects metadata and the relation to the AIP

[dju...@gmail.com]

Hi 

I have a question about what happens when you have uploaded a DIP to Atom from Archivematica and then add or remove metadata from Atom? 

-When you do an a metadata update through Atom on a digital object, where is that data stored? From what I understand it does not write this new metadata to the AIP package METS-file or adds or update a file to the AIP with new metadata?

-When clicking on a digital object you can se the AIP UUID, which I guess would be the way of linking the digital object back to it's AIP? However when clicking export either as Dublin Core or EAD XML the UUID is not present within those files? When exporting metadata from Atom how do you keep the connection to the AIP? 

-What happens if I delete a digital object from Atom? Does this change/ update the AIP or DIP?

Best regards 

Mattias

[Dan Gillean]

Hi Mattias,

Those are great questions! At this time however, the answers are not all we'd like them to be.

Once the DIP is passed to AtoM, no relationship is maintained with the original AIP. Archivematica's Access tab should have an entry indicating that you've performed a DIP upload to AtoM, and as you've noted, AtoM will list the File UUID and the AIP UUID in the user interface, but at this time there is not any ongoing two-way communication between the applications. If you delete an object from AtoM, the AIP in Archivematica is unaffected. Archivematica 1.5 will allow you to keep a stored copy of your DIP even after uploading to AtoM if you wish, but again, deletions in AtoM do not affect the stored DIP. Since AtoM is considered an access system in this use case while Archivematica is part of your preservation environment, we think this makes sense - you should be able to delete your entire AtoM installation without worrying about whether or not it will alter your preserved objects.

That said, we are interested in seeing communication between Archivematica and AtoM become more proactive and bi-directional in the future. AtoM has its own set of internal rules for access copy generation (when it makes a reference display copy and a thumbnail from a digital object upload, for example), when instead it should be able to share the FPR rules of an Archivematica instance for access derivatives. Some users do upload master images (such as TIFFs) directly to AtoM, and may start using Archivematica at a later date, or may prefer to perform some arrangement and description prior to preservation - so it might be interesting if one could send an AtoM archival hierarchy over to Archivematica as a transfer, to produce an AIP - essentially offering users a way to reverse the current workflow. With full AIP re-ingest coming in Archivematica 1.6 and re-ingest for DIP creation already included in 1.5, it's also interesting to imagine automating the process of replacing existing DIP objects in AtoM with updated ones generated from Archivematica. There are certainly many other situations where updates and notifications between the two applications would be very useful.

At this time, however, development of further integration between the two applications to support this kind of bi-directional communication has not been prioritized and sponsored by any of our users, so it is not currently on the roadmap.

The question of the UUIDs in the export metadata (EAD and DC XML, for example) is an interesting one, which would be much easier to implement. I would be curious to know if you have any thoughts on the best mapping in EAD  - what elements and attributes should we use to capture this information in a consistent and valid way? Do you know of any other examples of EAD XML that include UUIDs? Without consulting the tag library, my first thought would be to include 2 additional <unitid> elements with a @type attribute to identify them as "fileUUID" and "aipUUID" or something. The <unitid> element is described as being used to capture "any alpha-numeric text string that serves as a unique reference point or control number for the described material" - though I would be very interested in hearing alternative suggestions on how best to capture this information in EAD XML.

This same logic could easily be extended to import as well - and to CSV import and export. By adding the ability to import file and AIP UUIDs, it would allow users to maintain relationships to master preservation objects and AIPs that were produced by other digital preservation systems.

I've filed the following wish-list ticket to capture this idea, here:

• https://projects.artefactual.com/issues/10218

It's likely this will still require sponsorship for Artefactual to be able to implement, but the development involved would be far less significant that adding further support for 2-way communication and automation with Archivematica.

Cheers,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/484dddda-bb27-4f1f-89a0-61fae49b885b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dju...@gmail.com]

Hi 

Thanks for your reply. Sorry I havent answerd earlier. 

AtoM will list the File UUID and the AIP UUID in the user interface, but at this time there is not any ongoing two-way communication between the applications

Yes, ok in what database is the File UUD and AIP UUID stored? If we have those then there is a connection back to the AIP.

There are certainly many other situations where updates and notifications between the two applications would be very useful.

Yes I think so to. I think it is crucial that there is not a missmatch of metadata between the AIP and the DIP. They should both have the same metadata. Metadata added either in Archivematica or Atom should update both the AIP and DIP.

Im not an expert in the EAD XML but I think your solution sounds like a good one. :)  

[Dan Gillean]

Hi Mattias,

I've added a few responses in-line below:

 

Yes, ok in what database is the File UUD and AIP UUID stored? If we have those then there is a connection back to the AIP.

They are stored in AtoM's database - I'm not sure exactly where as I'm not fully familiar with the internal data model, but I believe they are stored in a properties table, associated with the information object (e.g. description) to which the digital objects are linked. If you are exploring the database, try looking in the property or property_i18n tables. The code which captures them is here:

• https://github.com/artefactual/atom/blob/stable/2.3.x/plugins/qtSwordPlugin/lib/qtPackageExtractorMETSArchivematicaDIP.class.php#L228-L229

I hope that helps!

 

Yes I think so to. I think it is crucial that there is not a missmatch of metadata between the AIP and the DIP. They should both have the same metadata. Metadata added either in Archivematica or Atom should update both the AIP and DIP.

This is something we debate with the Archivematica team often. On one hand I agree completely with you - on the other hand, it is important to remember that AIPs are supposed to be stable, long-term preservation objects, unlikely to change, and containing the required information to be able to preserve and access them in the future. Descriptive metadata can undergo many changes throughout its life - intellectual arrangements can be changed or imposed in a way that does not match the original ordering of the objects, holdings can be deaccessioned or culled, transferred, etc. For this reason, one possible compromise is to capture the descriptive metadata in a separate SIP, and link the resulting AIP to the objects AIP via a pointer. This way the descriptive metadata AIP can be versioned as needed without altering the original AIP of objects; alternatively you can wait to generate it until such time as the description and arrangement is complete and unlikely to change often.

Either way, I think this is a fascinating subject worth exploring further. If you are interested in discussing it with other users, I might suggest starting a thread in the Archivematica User Forum, with a link to this thread - it would be good to hear how other Archivematica users are handling this, even in description/access environments that do not rely on AtoM. 

 

I'm not an expert in the EAD XML but I think your solution sounds like a good one. :) 

Glad to hear it! For both this wish-list item, and other more elaborate changes to enhance 2-way communication between Archivematica and AtoM, we rely on community-sponsored development, or code contributions. If you are interested in learning more about our development philosophy and Artefactual's business model in relation to open-source development, I've tried to capture some of this information on our wiki, for context:

• https://wiki.accesstomemory.org/Development/Philosophy
   

Regards,