Table of Contents

Introduction

The Fedora Web Administrator provides a web-based user interface to perform repository administration. The application, which was built using Adobe Flex, uses a Flash plugin to run within a web browser. All coordination with the Fedora repository is performed using the Fedora REST API. The Fedora Web Administrator can be used to discover, display, ingest, modify, and purge objects and datastreams within a Fedora Repository.

The Fedora Web Administrator was first released as part of Fedora 3.2. This is considered the beta release of the Web Administrator, as it has yet to be tested thoroughly enough to be considered production ready. For more information on the Web Administrator in Fedora 3.2, consult the Fedora 3.2 documentation.

The goal of this page is to discuss the features and issues that should be addressed in future versions of the Web Administrator.

Web Administrator in the Fedora 3.2 Documentation
Original mockups for the Web Administator UI
Old Administrator Features Comparison

Considerations for new features

These are features which may be included in the new Administrator in the future. Some of these may also be significant enough to warrant a stand-alone interface.

  • User administration
  • Repository configuration (fedora.fcfg)
  • Statistics / Reporting / Validation
  • RELS search
  • Saved search queries
  • Saved search result sets
  • Search result count (with no returned result set)
  • Dublin Core editor
  • Relationship browser
  • Smart object builders (FCREPO-525)
  • Use rebuilder
  • Collection semantics
  • Plug-in manager
  • Security policy (XACML) editor
  • Ability to specify sort order on search results
  • I18N support
  • Copy Object function
  • Multiselect on search results to allow opening and/or purging multiple objects
  • Datastream version view
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels

2 Comments

  1. I thing the "smart object creation" aka object builders should be a separate application. The admin GUI needs to be generic and advanced object creation will likely be tied to the content model or at least a specific content modeling language. Functions which work over the fundamental Fedora Repository information model can arguably be supported since the Admin Interface is often used for new-user and repository administrator exploration and object repair. But I think the primary use case for the Admin Interface is repository Administration not data creation. Since you are not proposing adding this capability to the first version this point is moot, but I wanted to get it into the use case/requirements discussion trail.

  2. I'm not sure what you have in mind when speaking about plugins, but here goes a suggestion: The same way a Dublin Core editor is being considered, I think it would be great providing the possibility to develop specific editors for other kinds of datastream. What I have in mind is the development of an editor plugin for METS (not METS-fedora, just plain METS) which would allow to easily add a METS metadata datastream to a given digital object.