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 - AWoods: As noted in the description, this is a capability that logically would sit over the core Fedora service. Ideally, we could gather a group of institutions with the same basic need for a generic admin interface, detail the requirements and address the use case within the most appropriate framework, Hydra or the like.
- 2019-02: AWoods, Texas A&M's CAP may be a good starting point for fulfilling these requirements (James Silas Creel?)
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 |
|
Usecase 2 - A streamlined and secure way of distinguishing open from closed data
Title (goal) | A streamlined and secure way of distinguishing open from closed data |
|---|---|
| Primary Actor | curator |
| Scope | |
| Level | |
| Story | the curator manages three collections: a completely open one, a mixed access collection (e.g. password-access to copyrighted materials), and a completely dark one (e.g. personally identifiable information). The cost to the institution of anything dark accidentally being made public is high. However, materials do sometimes intentionally move back and forth (bidirectionally) between open, mixed, and dark. The curator needs this process streamlined.
Explanation: right now there are really two ways of distinguishing between a dark and an open Fedora collection. The wholly secure way to have entirely segregated Fedora instances on entirely different systems; This solution has minimal convenience. The wholly convenient way is to trust to XACML, FESL, or something higher level such as Hydra access controls; this solution relies on the shifting landscape of Fedora access controls for something with a high risk cost. Is there a middle ground between the two models? |
Other Use Cases of Interest
The following top level use cases are also of great interest to us:
