Johns Hopkins University Use cases

As developers of PASS, which interacts with Fedora-backed JHU Institutional repository, we need to be informed of content required to make a "deposit", and how to organize that content, so that we can update PASS to send acceptable manuscript or data packages, and we can validate that has received what it needs. -- use cases for first class content modeling as part of Fedora 6

As a repository manager, I need the repository I use to be integratable with iiif viewer in a bidirectional way:

• use fedora content for populating the image server,
• get the served representation back into the repository (Fedora 3 disseminator used to serve this role)

 As a submission system which interacts with Fedora-backed JHU institutional repository,  PASS needs to be able to send manuscripts along with associated metadata to the repository and receive confirmation of a successful deposit.

As a submission system which interacts with Fedora-backed JHU institution repository, PASS needs to be able to send data packages to the repository. The data packages would contain the data files, associated metadata files. Sizes are currently unknown.

There are 3 scenarios regarding file size:

• Smaller files (less than 2GB in size) deposit by value: PASS needs to be able to deposit these files by value. Fedora needs to take custody of these files.
• Larger files (more than 2GB in size) deposit by value: PASS needs to be able to point to these files' location. Fedora would need to be able to retrieve the content of the files and take custody of them.
• Larger files (more than 2 GB in size) deposit by reference: PASS needs to be able to point to these files location as part of the data. Fedora does not need to retrieve the files content and take custody of them, but would need to preserve the references to the external files

• As a submission system which interacts with Fedora-backed JHU institutional repository, PASS would benefit from having persistent links to the deposited contents so it can provide the links to PASS users. This need exists for both synchronous and asynchronous deposits. Persistent links are useful for both content's frozen snapshots and living-changing content. For example some persistent links (e.g., DOI) points to cited datasets within an article that is not expected to change over time, while other persistent links (e.g., ARKs) may point to underlying data that may change over time.

• As an administrator, I want to share a persistent link to a digital asset to an end user so the end user has a durable and citable location for the digital asset to which they are referring.

• As an administrator, I want to select a digital collection and share a link to that digital collection to an end user so the end user can access a digital collection relevant to their research.
  

 The migration from 4/5 to 6 needs to preserve resource URIs. For example, if an application deposits submissions into /fcrepo/rest/jhu/submissions using Fedora 4, the application can continue, unchanged, depositing into /fcrepo/rest/jhu/submissions in Fedora 6.

• As a repository manager, I need the repository i use to support to relationships between deposited data “units” to existing “units” in the repository (e.g., data deposits from annual studies) The relationship needs to be expressed as resolvable HTTP URIs
• As an administrator, I want to select a group of digital assets and share a link to that group of digital assets to an end user so that it takes less effort to satisfy end-user requests.
   

 As a repository manager, I need the repository I use to support for restricted access to data (e.g., institution only). Access to data should be controllable by roles or groups.

 As an administrator, I want to restrict access to high-resolution digital assets but store them in the digital asset delivery platform and make them available by request so that I can ensure that high-resolution digital assets are used in accordance with applicable policies.

As an administrator, I want to provide access to restricted digital assets through the digital asset delivery platform so that end users who are permitted to access these digital assets do not need to be provided copies outside of the digital asset delivery platform to fulfill their research need.[3]

As an administrator, I want to bulk ingest digital assets and associated metadata into the digital asset delivery system, and have the digital asset delivery system associate the assets to their corresponding metadata, so that I can efficiently provide end-users with access to digital assets.

As an administrator, I want to ingest and replace individual digital assets so that I can make small edits to a digital collection.

 As an administrator, I want to gather relevant statistics on use of digital assets so that I can understand what collections are used, how they are used, who is using them, and other information relevant to inform service priorities.

 As an administrator, I want the digital asset delivery platform to integrate with other platforms for managing and providing access to library resources (such as the catalog and ArchivesSpace) so that the end user has a more seamless user experience and so that administrators can more efficiently manage and provide access to digital assets.