Australian Subject Gateways Forum

Requirements for Subject Gateway Software

The information below is not intended as an exhaustive or prescriptive list but rather a useful checklist of common and/or desirable features. The list is based on the experience of a number of the Australian subject gateways, particularly AVEL and Agrigate.

Suggestions for additions or updates are welcome - please contact the Library's Coordination Support Branch at: csb@nla.gov.au.

Repository

Features

  • The repository shall store metadata records and make them available for editing and searching.
  • It shall support the Dublin Core model of metadata, with qualifiers.
  • It shall be possible to extend the repository to include custom elements and custom qualifiers.
  • It shall be possible to specify constraints on the metadata records, which shall include mandatory.
  • The repository should support multiple schemas in the same repository.
  • Records shall have two possible states: active and inactive. Active records are visible and available to end users. Inactive records are not visible to end users.
  • Authentication shall be required before users are allowed to add records to or modify the repository.
  • Full support for A-Core metadata shall be possible.

Maintenance

  • The repository shall be able to perform link checking on URL values, to check that the URL resource is available.
  • The results of the link checking file should be generated as HTML report documents.
  • The administrator shall be able to grant access to the repository and manage users.
  • The repository shall indicate records that have not been modified after a given period of time. This feature is used to review records.
  • It shall be possible to identify which user was responsible for creating and modifying individual records.
  • The repository shall identify duplicate records.

Importing and exporting

  • It shall be possible to import metadata records from a text file.
  • Imported records shall be merged with the existing records in the repository.
  • It shall be possible to export the entire contents of the repository to a text file.
  • It may be possible to selectively export a subset of records from the repository.
  • The import and export file format should be in XML and be well documented.
  • The format of the export shall be the same as that used by the import function.

Statistics

  • The repository shall report statistics on the records it is holding.

Back to the top

Manual entry tool

General

  • A manual entry tool shall be provided for manually creating and editing metadata records.
  • Entry tool shall run on standard desktop computer environments. Minimally, the Win95 platform shall be supported.
  • Entry tool shall be easily deployed and should not be encumbered with licensing and per-seat royalty issues.
  • The tool shall support selection of values from a thesaurus for some elements (such as subject keywords).

Communications with repository

  • Entry tool shall be able to connect to the repository across the Internet.
  • The entry tool shall perform authentication before the user is allowed to retrieve records, create or change records.
  • Authentication shall be managed centrally by the repository administrators.

Schema

  • Entry tool shall be configurable to match the schema used by the repository.
  • Entry tool shall validate that records conform to the schema, and warn.
  • Authentication shall be performed on record editors and creators, and their identity shall be recorded in a log file.

Assistance

  • The entry tool should be configurable, before deployment, with default values for selected elements when a new metadata record is created.
  • The entry tool should be configurable, by the end user, with default values for selected elements when a new metadata record is created.
  • The entry tool should assist the user by extracting embedded metadata from HTML resources.
  • The entry tool should assist the user by automatically extracting information from HTML resources.
  • The manual entry tool should provide content sensitive help for record creators.

Back to the top

Automatic entry tool

  • No Web crawler requirements are specified, because at this stage the needs are not known.

Back to the top

Search interface

Search features

  • A Web search interface shall be provided, which allows any users with a standard Web browser to access the service.
  • A simple, keyword based search interface shall be provided.
  • An advanced, field based search interface shall be provided.
  • The search mechanism shall support phrases.
  • The search mechanism shall support stemming of words.
  • The search mechanism shall support truncation of words.
  • The search mechanism should support case sensitive and case insensitive searches.
  • The search mechanism should support date comparisons on date values.
  • The search interface shall support compound queries (AND, OR, and NOT).
  • A preprocessing mapping mechanism should be provided to allow automatic transformation of terms and queries. One use of this mechanism is to translate alternative spellings of words into the spelling used in the repository.
  • The search mechanism should provide context sensitive help for users.

Display

  • URLs shall be displayed as active links on the Web pages.
  • The elements displayed by the search results shall be configurable.
  • The look and design of the search entry and results display shall be configurable.

Statistics

  • The system shall be able to report statistics on the number of searches processed.

Back to the top

Browse interface

  • A Web based browsing interface shall be provided to allow users to browse through records in the repository.
  • The browse facility should allow limiting by resource type.
  • Browse headings shall be automatically generated from the subject field in the record template.

Customised interface

  • A customised interface shall be supported.

Back to the top

"What's New"

  • A "What's New" listings file including the ability to restrict the list generated to the last "x" resources added and resources added since a particular date shall be generated.
  • The "What's New" listings file shall be converted into a static HTML document for WWW display.
  • The entries that are listed in the "What's New" listing file shall be removed if added before a defined date or "x" resources added.

Back to the top

Document History

Barbara Rozmus, NLA
Initial Draft: November 2000, based on a document provided by Jan Whitaker

Date last verified: 14 January 2004

Back to the top