RH Batch 1 Retrospective

General observations

Arrived at a really good place with everything
Built sustainable practices and functionality for modeling related items.
All customization was performed with sustainability in mind, which means the new functionality can be extended to other collections / admin sets. Additionally RH functionality not “one-offs” that could be difficult to maintain eventually.

Having mock ups helped set expectations, however it took several meetings to arrive at a mutual understanding of the metadata profile, item display and functionality. There was a lot of discussions and expectation setting. Ideally this would be accomplished in fewer meetings for other projects.
As DC in DDR is still new, ITS didn’t really know how different our expectations were for our handling the project at the time of the grant proposal and metadata planning.
Takeaways for next time:
- Metadata Architect should be involved at the beginning of the description planning process.
- Share metadata application profile w/ stakeholders as they are writing grants and setting up goals.
- Share baseline repository functionality and set expectations from grant proposal phase more proactively.

Might have been the easiest part of this whole project. Jim C provided training for DPC folder ingest for Susan and Moira. The ingest itself took 2 hours 40 minutes.
Jim handled the derivatives, but is working on a mechanism for Moira and Susan to do that, so subsequent batches will work well for Moira and Susan. This work should be available in September. Jim C can do any one off derivative work needed for batches before September
Susan and Moira didn’t have access to CIFs, which was frustrating.
There were questions about what we were ingesting:
- Check in w/ Craig: are you going to want to preserve more than one derivative? Note, currently we do not have a way of associating more than one derivative with the master file.
- What about Duke users - would you ever want to provide higher bandwidth derivatives to researchers on campus. Talk to Craig about this.
Moving forward: Jim C. asks that Craig name the batch folders consistently.
Moira and Susan can work with larger batches: same amount of work regardless of the size of the batch (it is not a substantial amount of work). The duration of the ingest varies depending on many factors (other ingests, machine speed, etc), so there are no recommendations for ideal ingest batch size.
- Jim C can restart large ingests if they get interrupted.
Note: do not ingest things that should not be publicly accessible until the very end.
- When we get to that point, we should discuss the need for special permissions for these items.

Prepping metadata batches for ingest is a lot of work for Maggie.
There are some issues with exporting the metadata from DDR - delimiter issues - there is a JIRA w/ Jim C.
Laura is still working on the metadata, which makes the ingest complicated. Ideally there would be a clear point where Laura is “done” before Maggie manages the ingest into DDR.
To discuss w/ Craig and Laura:
- When will metadata be “done”?
- If not 100% "done" are there good stopping points we can use for planning hand-off points?
- How does the grant planning effect this?
Post ingest - it is helpful that Laura will be editing the metadata herself.
Small (hopefully small) changes moving forward:
- Maggie would prefer to grab metadata directly from the Google sheet (moving from Google sheet to excel is error prone)
- Is it possible to remove empty columns from the Google sheet, for example the first batch included 36 empty columns.
Metadata Versioning notes for Laura and Craig:
- If we (Laura, Craig and Maggie) are making changes to the metadata in DDR, then DDR becomes the master version of the metadata - not the google sheet.
- We cannot re-ingest the whole google sheet more than once, as it will overwrite what is in DDR.
- An exception is ingesting new content, ex: French translations. In this case we would ONLY ingest the French and not the whole sheet.
High Level Takeaway moving forward: metadata ingest must happen in larger batches - ideally 1000 records or more

Ideally we would like to de-couple data ingest from metadata ingest. However currently the workflow for publish / unpublished will make this work really complicated.
- Newly ingested batches will automatically be published because the collection is published - no bulk way to manage the publication status of a group of items - Moira and Susan to talk to Jim C.
Development Need: ability to edit access controls in bulk this is a repository wide need. Could be its own R/D.
Workflow for now will require ingest work be coupled with Maggie setting the timing around her metadata remediation work:
1. Maggie will work with metadata
2. Susan and Moira ingest data
3. Right after data ingest, Maggie will ingest metadata
The goal in coupling the batches in the workflow above is to limit the amount of time recordings are available w/ out metadata. Maggie, Susan and Moira will have to coordinate their work closely.

Collection Rights - we need a better place for this information w/ collection level metadata (DCIT)
- Also need French and Haitian translations of copyright statement
- The next big coupled release will be in September - any changes to about page should be in by end of August
Unknown around the time coded descriptions - there will be a PR in development this quarter (Sean and Molly)
- Wait to do development of the PR and the feature to begin in earnest
Embed A/V: http://people.duke.edu/~seanaery/embedtest/av.html (Sean)
- Will be deployed in September, but could be released sooner
- Need feedback from Craig and Laura
Access considerations from Haiti (Laura and Craig)
- Can Laura and Craig get some data from folks in Haiti about access the files via DDR. Have they done that?
Do you want ASpace identifiers in DDR to enable “view in context” features? (Craig and Maggie)