SOW for Dec. 2016 work
- Support user groups and roles within Collection Builder.
- This will require adding a server-side component to the architecture. As part of this effort the Consultant will work with Harvard to decide which technology stack to use, how much of the existing code to reuse (there is potential to reuse most of it), and how to split the functionality between the client and server. The Consultant would also evaluate whether and how to integrate with Harvard Key and/or the new Roles/Policies management application currently under development.
- Minor updates to import/export functionality within Collection Builder
- Upload a list of IDs to be added to a collection by selecting a local text file, not pasting into a form window in the browser (current functionality)
- Download the list of IDs within a collection to a local file on disk, rather than viewing on screen and copying pasting to a local file (current functionality)
- Select a subset of IDs to be downloaded, using text search of item names, descriptions, or IDs
- Deploy to production
- CollectionBuilder is currently running off of the test instance of LibraryCloud. The Consultant, with support from Harvard, will move it into to the production instance.
- Enhance the MODS to DC transformation within Library Cloud
- There is some data in the MODS data for OASIS EAD components that should be available in the DC version, but is not, due to how the transformation is being done between formats.
- Define a method for specifying the “object in context” URL for an item
- This would most likely involve an additional step in the LibraryCloud ingestion pipeline, that would build an “object in context” URL for an item based on LibraryCloud collections to which it belongs, and a URL pattern defined for that collection.
Please refer to https://jira.huit.harvard.edu/browse/LTSCLOUD-259 and https://jira.huit.harvard.edu/projects/LTSCLOUD/issues/LTSCLOUD-251 for details.
object in context
Here’s some background on the object in context question. Yes it is the mods url field with access=”object in context”; this is the link to the full record display in the context of its collection – Harvard Open collection, Omeka, Spotlight, etc. The primary use case for this is when DPLA harvests our mods, they use the object in context url to point back to our records in their native collection. Examples from our current MODS OAI:
<url usage="primary display" access="object in context">http://colonialnorthamerican.library.harvard.edu/cna/div00376c00007 </url>
<url usage="primary display" access="object in context"> http://ocp.hul.harvard.edu/dl/immigration/000069518 </url>
So the idea is that, per collection/set, the curator should be able to set the root url and path to precede the record id that will point to the external collection, and this (with the id) will be added as a mods field.