David Giaretta argues that the success of OAIS is in "how widely it has been adopted to facilitate comparisons of archival implementations and issue." The OAIS Functional Model has been an essential part in sharing the language and concepts of the Framework. It's familiar arrangement of shapes has become a shorthand to refer to the entire standard.
However useful it may be as a commonly understood representation of the standard, the 4.1 Functional Entities Model also limits our understanding of the framework. For example, critics of OAIS frequently request adding a Pre-Ingest process to the framework, citing the need for work to transform a SIP into an AIP before storing it. The simplified workflow in the 4.1 Model appears to show a direct flow of SIPs to AIPs. On the other hand, the full text of the Functional Entity defines Functions that receive the SIP, perform quality assurance, generate an AIP or AIPs, generate descriptive information, and coordinate updates with data management and storage.
Some critiques rightfully point out that the definitions of these functions do not fully accommodate typical workflows. For example, the Quality Assurance function emphasizes bit fixity but does not mention other checks, like validating metadata or file formats. Archivists find much of archival processing represented in the Generate AIP and Generate Descriptive Information functions for documenting, arranging, rehousing, and describing objects for long-term preservation. But no function in Ingest explicitly defines other parts of archival processing like appraisal, purposefully selecting records for preservation from a submission, or destruction, obliterating submitted records that are not selected for preservation.
When critiques are leveled at individual Functions, they point out the need for updating their definitions. When I hear the the same critiques leveled at a Functional Entity like Ingest, I think it points out that the 4.1 Model has oversimplified OAIS. If the community used a model of all of the defined Functions, I believe it would produce more productive critiques of the framework. Such a model is available in Appendix A-1
Unfortunately, the A-1 Model appears to be visually unrelated to the 4.1 Model, and it can be very difficult to read. Gone is the familiar arrangement of the Ingest-Data Management-Storage-Access diamond hugged by Preservation Planning and Administration. In its place we have six boxes positioned in ambiguous relations to each other and connected by a tangle of lines that can intersect multiple times (see the connection between Coordinate Access Activities and Activate Requests) or run behind Functions (see Monitor Designated Communities). Eld Zeirau has addressed some of these problems, but I believe we can improve this further by matching the Functional Entity positioning of the 4.1 Model. I have attempted this below.
While this visualization has it flaws as well, I think it does a better job illustrating the Functions that underlie the 4.1 Model. The greatest flaws of this diagram are the groups of lines flowing between Administration and Preservation Planning. In the 4.1 Model, these 7 relationships have been abstracted to a single dotted line. In the A-1 Model, they are the likely reason that Preservation Planning has been moved to the bottom of the diagram. Preservation Planning actually has no direct interactions with the Ingest, Data Management, Storage, or Access Functional Entities, so I drafted another revised model that places Preservation Planning at the very bottom of the diagram.
Admittedly, this diagram is less legible than my first diagram for at least 2 reasons. First, I've lost the positional relationships from the 4.1 Model. Second, diagramming 30+ Functions, Entities, and Devices and their relationship is extremely difficult and time-consuming. My first diagram has taken well over forty hours, spread across three different revisions. This diagram is an experiment that took 30 minutes to prototype. The full OAIS standard contains many more diagrams than just the 4.1 and A-1 Models, which is a testament to how much work is required to maintain and update just the visual portions of the standard.
Regardless of the shortcoming of this second diagram, I think it has some value, mainly in how we should look at the 4.1 Model. As I mentioned previously, Preservation Planning only interacts with Producers, Administration, and Consumers, so it makes sense to reflect this in the layout of the model.
This diagram more accurately reflects the Functions defined in OAIS and how organizations operate. Long-term preservation rests on a foundation of planning, in consultation with donors, users, and administration. Putting plans into action requires administration to properly fund, staff, and manage a range of activities that take in material, store, and then provide access to it. Because those activities at the top of the diagram directly help users access collections, they are the most visible, but they would also be impossible with the support of administration and preservation planning.
I argue that our visualizations of OAIS shape our understanding of it. They require as much attention as the words of the framework. The proposed revisions included with this post are drafts and could use improvement. I'm happy to discuss making additional changes or taking entirely new strategies to visualize OAIS Functions (@nkrabben, email@example.com). I've created all my diagrams as SVGs and am happy to share them.
Nick Krabbenhoeft, Head of Digital Preservation, NYPL