Usecase 1 - Reasonable curator's administrative interface
Title (goal) | Reasonable curator's administrative interface |
|---|---|
| Primary Actor | Librarian/archivist/curator |
| Scope | |
| Level | User goal |
| Story | The curator of Fedora data wants to be able to discover, modify, and ingest all data in the Fedora repository before the curator's organization has had the resources to put into building a personalized, user-friendly special administrative interface. That is, without any bells and whistles, but with more usability than the existing developer-focused Fedora administrative interface, the (non-programming, non-XML expert) curator wants to be able to add one or many items to the Fedora repository, discover one or many items via search, purge one or many items, and modify one or a batch of items. They want to be able to handle new datastreams without necessarily writing special code. They want to be able to at least see a simple field-based editor for in-line XML datastreams, and an upload/view tool for external/managed datastreams. They want to be able to crosswalk metadata fields in those XML datastreams to each other, so, for example, when they are editing the title of an object they do not need to make the same edit in oai_dc:title, local_dc:title, local_vra:title, etc, as you currently have to do in the existing developer-focused administrative interface.
Explanation: The number one roadblock that we see when talking to members of our community asking if they want to be partners in our Fedora venture is the lack of an out-of-the-box curator-focused administrative interface for Fedora data. While the response from the Fedora community has persistently been that Fedora is a framework, and user facing interfaces are to be designed by the outside community, the reality is that every single existing administrative tool is designed for specific institutional use cases, usually specific metadata formats (cf. sufia), and don't provide an out-of-the-box view of the data. Right now we are working with one potential Fedora user who is currently spending an enormous amount of money and time to create a minimal user interface before they find out if Fedora is even something that will work for them, because that minimal view of the data and ability to have non-technical people work with it is necessary for them to make an informed decision. |
| Comments |
|
3 Comments
David Wilcox
Deborah Kaplan is this your use case?
David Chandek-Stark
This is a fascinating case for me personally. I spent some significant time working on a Hydra-based repository admin tool, fcrepo_admin: https://github.com/projecthydra/fcrepo-admin. While a number of institutions indicated initial interest in such a tool (this started at LibDevConX^4 2013 – where it was suggested that Fedora 4 might ship with no admin app at all), no one followed through to work with me. Ultimately I myself abandoned the effort, in part due to lack of interest from the community, and in part because it became a maintenance burden that I couldn't support with other time commitments.
Features such as a field-based editor are incredibly complicated, and I wouldn't describe an app that had it as "without bells and whistles". I still think there is potential for the Hydra community to develop something along the lines of what you are imagining (Curate/Hydramata?), but I'm not sure that it makes sense to include such an application in Fedora itself.
James Silas Creel
Andrew Woods I would definitely recommend Texas A&M's CAP as a starting point for meeting this set of requirements. DuraSpace made a blog post on it here recently: https://duraspace.org/introducing-cap-curators-administrative-platform-from-texas-am-university-libraries/. We are running a sprint on it presently that will improve the documentation and will make deployment simpler.