1
...
Template
To add a Use Case for your institution, copy the template form and paste it
...
into a subpage with the name of your organization. Or feel free to comment on other Use Cases.
Title (goal) | |
---|---|
Primary Actor | |
Scope | |
Level | |
Story |
|
Sponsors
Arizona State University
...
Brown University
...
Case Western Reserve University
...
Columbia University
...
Cornell University
...
Duke University
...
Durham University
...
Emory University
...
ICPSR
...
Johns Hopkins University
...
Microsoft Reasearch
Monash University
...
National Library of Medicine
...
Northeastern University
...
Northwestern University
North Carolina State University
...
Oxford University
...
Penn State
...
Smithsonian Institution
Stanford University
...
State and University Library, Aarhus, Denmark
...
...
...
...
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.
...
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? |
The following top level use cases are also of great interest to us:
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.
University of Illinois
...
...
University of Hull
...
University of Maryland
...
...
Use Case 1
Title | Data management plan ingest and storage |
Primary Actor | Researcher |
Scope | - |
Level | - |
Story | Researcher A creates a data management plan and stores in Fedora via Fedora User Interface or API. Note: Improve SOAP/REST API to handle deposit, edit and query final research data outputs. |
Use Case 2
...
Title
...
Deposit interim data in RDF format and search using SPAQRL
...
Primary Actor
...
Researcher
...
Scope
...
...
Level
...
...
Story
...
Use Case 3
Title | Versioning interim data and accessible through ”Cool” URL format |
Primary Actor | Researcher |
Scope |
|
Level |
|
Story | Researcher C joins the project and improves the interim data. The improved data needs to be stored in Fedora as a new version of the previously stored record. So, the items deposited in Fedora are:
So, the URL of the new version becomes: http://www.domain.com/resoure/metadata/1/version2136 which has links to the previous version, Researchers A, B and C, the project record, and the new version of the data. Note: Improve SOAP/REST API to handle deposit, edit and query final research data outputs. |
Use Case 4
Title | Generate final data output for fedora storage in ”Cool” URL format |
Primary Actor | Researcher |
Scope |
|
Level |
|
Story | The research project is complete and has produced some final data that needs to be stored in Fedora. Notably, the final data has been produced from the interim data mentioned in Use case 3. The items to be stored in Fedora are:
The URLs of the final data output: Metadata: http://www.domain.com/resoure/metadata/2137 Data: http://www.domain.com/resoure/data/2138 Note: Improve SOAP/REST API to handle deposit, edit and query final research data outputs.
|
Use Case 5
Title | Updating/Editing multiple fedora records |
Primary Actor | Researcher |
Scope |
|
Level |
|
Story | Researcher A is interested in editing multiple Fedora records. Using a SPARQL query or simple search the researcher has the ability to locate and update metadata fields for multiple fedora records. This is of particular interest for large collections of related objects that require periodic updates. Note: Improve SOAP/REST API to handle deposit, edit and query final research data outputs. |
- An RDF-based metadata record describing any source data from which the “interim” data was derived (Item 1)
- RDF-based Metadata records about Researchers A and B (Items 2 and 3)
- An RDF-based metadata record about their research project (item 4). This includes relationship between the project (Item 4) and the data management plan created in Use case 1.
- The actual data object (item 5).
- An RDF-based metadata record describing their “interim” data and the research methodology (Item 6). This includes relationships between item 6 and items 1,2,3,4 and 5
Note: It is not necessary for item 5 to be stored in Fedora with the rest of the items. Item 5 can be stored on external storage such as another Fedora or other storage system with a resolvable URL to item 5.
Once stored in Fedora, the researchers are provided with URLs to the items stored. The URL of an item resolves to that item, which also contains URLs to the other related items. For example, item 6 will have URLs to items 1, 2, 3, 4 and 5, while item 4 will have a link to the data management plan.
In addition, the URLs to the items are human readable, providing meaningful information about the corresponding resources. For example, the URL for item 1 could be http://www.domain.com/resoure/metadata/1135, which implies that this URL represents a metadata record.
Additionally, Researcher A is interested in using SPARQL queries to find patterns in Fedora metadata records across multiple grant projects.
Note: Improve SOAP/REST API to handle deposit, edit and query final research data outputs.
University of Prince Edward Island
...
University of York
University of Connecticut
...
University of Delaware
...
University of Massachusetts Amherst
...
...
...
Title (goal) | |
---|---|
Primary Actor | Repository Manager |
Scope | |
Level | |
Story | As a repository manager, I need to delegate repository work to other library staff. I need a way to create separate spans of control within which sets users have the ability for perform work. |
...
As a creator of many front-end repository applications, I want to use the Fedora web api while enforcing the same authorization as other front-ends. Without this I cannot connect to a repository containing protected objects unless I duplicate authorization in front-end applications.
University of Notre Dame
...