So when one is going to change everything, where does one start?
Fortunately we have a ready-made starting point with the Open Archival Information System (OAIS) reference model. While this does not give us a blue print of what to build, it does give us a model to use as we construct our blueprints. I believe this is very much what the folks at Archivematica have done.
So the question becomes: How do we translate a high-level reference model that contains functions such as Receive Submission to the low-level blue prints one needs to reconfigure process and build software? What kind of web applications do I need for Receive Submission? What should they do? Should that box that contains the submitter's identity be an email address? A text string? An ORCID?
So how to start?
One of my colleagues, Nancy McGovern, suggested we brainstorm 6-12 medium-level statements for each of the functions in the OAIS reference model. We started with Receive Submission, and indeed generated 12 statements. (The analogue at Archivematica is Receipt of SIP.) One example is:
The producer provided basic provenance information at deposit
If the metaphor for building FLAME is building a house, then OAIS plays the role of high-level best practices. The statements (like above) play the role of floor plans and elevations; those things to which most people can relate and make decisions. So this is moving in the right direction, but we're still lacking the blueprints.
The next step is to take a statement like the one above and turn it into requirements for software (and for process). One example requirement that flows from the statement above is:
FLAME should capture the following provenance information from the files after each content transfer:
i. Date and time at which each file is received
ii. Checksum of each file
iii. MIME type of each file
iv. Original name of each file
v. Packaging information (e.g., file was part of a Zip archive)
Right now we are working through the details of Receive Submission, and the next few stops on the roadmap will likely be in Ingest as well. We're documenting both the high-level statements and the low-level requirements in a Drupal CMS that we use as our Intranet.