You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current accessioning paradigm, we have two models:
objects that have only one file
objects that have many files
For case one, users have become accustomed to having a flat directory for the content, and then mapping the file to the druid in the manifest.csv ( | druid | filename | ).
For case two, users have become accustomed to having sub-directories for each object ( | druid | folder | ).
In our current implementation of the pre-assembly app, it is expected that all content (whether one-file-per-object or many-files-per-object) will be arranged in object-level sub-directories ( | druid | object | ).
This is a placeholder ticket to address whether or not we can add back in the functionality to map to either a single file or to a container in a future iteration of this app.
The text was updated successfully, but these errors were encountered:
In the current accessioning paradigm, we have two models:
For case one, users have become accustomed to having a flat directory for the content, and then mapping the file to the druid in the manifest.csv ( | druid | filename | ).
For case two, users have become accustomed to having sub-directories for each object ( | druid | folder | ).
In our current implementation of the pre-assembly app, it is expected that all content (whether one-file-per-object or many-files-per-object) will be arranged in object-level sub-directories ( | druid | object | ).
This is a placeholder ticket to address whether or not we can add back in the functionality to map to either a single file or to a container in a future iteration of this app.
The text was updated successfully, but these errors were encountered: