 |
 |
Hi Randy, This is a good question! Thanks for pointing out to Scholars Portal, Kari. I think that the hospitable concept of the SIP/AIP/DIP sort of precludes a perfect or ideal version in real life – the decision always in relation to the content and the preserving organization’s context, resources and needs. I agree with Kari that for many contexts, SIPs/AIPs are best aggregated on some functional basis. For us, the consideration is definitely related to how we provide access to DIPs and want to manage our metadata. We’re still very much in the pilot phase regarding using Archivematica for processing larger numbers of files. There’s definitely lots of interest in this out there - consulting the Archivematica forum<https://groups.google.com/forum/?fromgroups#!forum/archivematica> is a good place to start. I’d also point to institutions such as Simon Fraser University and the University of British Columbia (and there are definitely others out there too I’m forgetting!) who have developed great automated workflows for the ingest of theses and other materials through Archivematica. For context: Scholars Portal<http://scholarsportal.info/> hosts a number of content platforms consisting of shared collections of published research materials and data (geospatial, micro-data etc.) that we load from multiple sources to serve to the members of the Ontario Council of University Libraries and the general public. Our preservation services are most fully developed for our journals platform<https://journals.scholarsportal.info/> and the books project is in progress. All of our documentation for the preservation of journals is online here: https://spotdocs.scholarsportal.info/display/OAIS/Home and you might find some of the definitions of SIP/AIP/DIP and details on fixity checking relevant. An important thing to note for us on this scale is that the DIP is generated on demand from the stored AIP. This is also why there’s a 1 article – 1 SIP/AIP model. For our books platform, we’re looking at a different workflow where the AIPs and DIPs are created separately, so the Archivematica workflow is concentrated on creating AIPs only, but whose metadata links back to the access platform. It’s also notable that in both of these cases, the SIP/AIP is not just the article or book – it can also include supplementary files and materials such as images – so its not as atomistic as it initially appears. Hope this helps! Best, Grant Grant Hurley | MA, MAS, MLIS Digital Preservation Librarian Scholars Portal, Ontario Council of University Libraries 416-978-5648 | [log in to unmask]<mailto:[log in to unmask]> | www.scholarsportal.info<http://www.scholarsportal.info> | www.granthurley.ca<http://www.granthurley.ca> On 2017-06-02, 10:25 AM, "Code for Libraries on behalf of Andrew Weidner" <[log in to unmask]<mailto:[log in to unmask]> on behalf of [log in to unmask]<mailto:[log in to unmask]>> wrote: Thanks for the advice, Kari. I'll take a look at those resources. It's the management burden of having thousands upon thousands of AIPs that will become the bottleneck / digital management problem in the future. This is the pushback that I often hear from digital preservationists when talking about the single object AIP approach, and I'd like to learn more about these concerns. Any clarification of the long term management burden posed by single object AIPs would be most helpful. Andy On Fri, Jun 2, 2017 at 9:17 AM, Kari R Smith <[log in to unmask]<mailto:[log in to unmask]>> wrote: Hi Randy, I suggest that you post this question to digipres list (ALA list) where many digital archivists and digital preservation folks will see you message and can respond from that perspective. Also, don't forget the concept of the AIC (archival information collection) which is an aggregate of AIPs. I would recommend connecting with Scholar's Portal in Canada. They have an Archivematica workflow that is very item level (article = 1 SIP) and have experience and many lessons learned about the issues regarding performance, management, and scale of having one item in a SIP/AIP. Grant and Kate from SP recently did a presentation on their approach: http://charlotteinitiative.uncc.edu/sites/default/files/ users/2477/presentations/davis-hurley-charlotteslides.pdf Also keep in mind that the purpose of the AIP is for long-term preservation that accumulates both metadata and changes to file formats over time. The DIP (Dissemination information package) is the xIP for which you may want to have a 1 xIP = 1 item relationship. The DIP is created from that AIP (in the ideal workflow) so you can have 100 DIPs generated from a single AIP (that contains the 100 image files, etc.) It's the management burden of having thousands upon thousands of AIPs that will become the bottleneck / digital management problem in the future. Aggregate solutions for digital files, even and especially for digitized material are more the norm than individual xIPs. Good luck, Kari Kari R. Smith Digital Archivist and Program Head for Born-digital Archives Institute Archives and Special Collections Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts 617.253.5690 smithkr at mit.edu http://libraries.mit.edu/archives/ @karirene69 -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Andrew Weidner Sent: Friday, June 02, 2017 9:57 AM To: [log in to unmask]<mailto:[log in to unmask]> Subject: [CODE4LIB] SIP/AIP Content Guidelines Hi all, Can anyone point me to guidelines or best practices documentation around creating SIPs for transfer to archival storage? What does an ideal AIP look like for digitized cultural heritage materials? I'd like to set up a pipeline that sends single object (e.g. one photograph, one book) SIPs from our digitization workflow to Archivematica for automated transfer to archival storage. Here's a brief slide deck outlining the approach I'm envisioning: https://docs.google.com/presentation/d/19F5seismyBdhgIWk7Kt0jmJjqis-- FCpOwNr3v6Iu-w/edit?usp=sharing I welcome any thoughts that you all may have on this, especially about pitfalls to avoid. Thanks, Andy