Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Prepared by: Repository Management FRG

Date: March 2018

Reviewed by: Repository Management FRG, DLP Steering

Overview

The charter for the Repository Management Functional Requirements Group (FRG) includes the following deliverable: 

Develop requirements for search and display of repository entities within a management system context

This work intersected with other work within the Repository Management FRG and other DLP Working Groups. This document supplements those separate deliverables and reiterates some specific requirements in this area.

Work Process

The Repository Management FRG previously collected and analyzed reporting requirements, some of which related directly to advanced search needs to be performed by staff. The Permissions Analysis Matrix artifact also contains additional indications of staff-only activities for viewing, creating, and modifying repository entities. The Versioning User Interface Needsdocument also delineates some information which is presented to end users vs. staff.

The group also reviewed the DLP Metadata Implementation Working Group’s metadata specifications for staff-only metadata and reviewed fields which have been recommended for indexing. This includes metadata identified in the areas of Rights, Preservation Workflows and Events, Administrative, and Technical metadata. 

Summary Requirements

Requirements scoped to “Library staff users” include multiple Repository Management User Profiles(Collection Manager and Preservation Curator in particular), with the exception of Self Depositor.

  • The DLP repository should provide the general capability to delineate staff-only view of selected metadata fields from public/end-userfacing metadata. 
  • While submitter users (such as those outlined in the Deposit FRG’s user profiles) may have access to the repository through self-deposit workflows, submitters should not see full Administrative, Rights or Preservation Events and Workflows metadata, because those areas of metadata may contain sensitive internal information. End users may instead see an abbreviated version history for the digital object.
  • To support advanced, ad-hoc internal staff search needs, the DLP implementation team should investigate the use of the underlying SOLR interfaceand provide staff with appropriate training and access.
  • The repository solution should provide the ability to export advanced search results to CSV(either via SOLR or Blacklight).
  • As indicated in the larger Permissions Matrix deliverable, selected repository entities should be visible to Library staff only, in addition to the metadata-related visibility noted above.
    • Selected supplemental preservation files may be hidden/embargoed on a per-file basis if they contain sensitive or confidential information.
    • Agreements and Deeds, whether stored as supplemental files attached to an object or as re-usable standalone objects, should be restricted to viewing by the Repository Administrator and selected Collection Manager users only. These assets should generally not be edited, but may be versioned if the contents of the agreements change over time.
    • To adhere to the 2018 Retention Policy, selectedmetadata for objects that have been decommissioned or deleted should still remain visible to Library staff users.
      • Descriptive metadata (to enable staff discovery of objects made dark)
      • Administrative metadata (to inform staff about the provenance of the object and reasons why it was decommissioned or deleted)
      • Content and supplemental files (for decommissioned objects: deleted objects will be purged of attached files)

 

 

  • No labels