6 Miscellaneous Requirements

This section describes requirements that are not covered in other sections.

6.1 Agency and Service Lists

Some NZGLS elements require value selection from a controlled list that is derived internally from other metadata records. This will occur when the value is the name of an agency or the name of a service. The agency list will contain the Title elements of all valid metadata records where type.category='agency' and will be used to populate elements such as Creator and Publisher. The service list will contain the Title elements of all valid metadata records where type.category='service' and will be used to populate the Relation element. More information on the usage of these types can be found in appendix IV.

The Metadata Management Facility will provide a mechanism for the agency and service controlled lists (NZGLS-AN and NZGLS-SN) to be generated automatically, based on the current content of the metadata repository. This should be a dynamic (real-time) process but could be performed as a regularly scheduled process.

If a directory is being provided by the vendor, then an alternative means of validating agencies may be provided using the directory instead of a controlled list.

6.2 Additional Thesauri Requirements

The requirements in this section are relevant only if the vendor is proposing to supply a thesaurus rather than interfacing with the existing tool.

6.2.1 Publishing on the Web

There is a requirement for NZGLS thesauri to be published on the web for public access. The publishing process will be fully automated so that a single action, initiated by an authorised person, updates or replaces the web version of a thesaurus with the latest information. The requirements of the web version are as follows.

Presentation options	Users will have a choice of Alphabetical or Hierarchical display.
Alphabetic display	This will be a straight alphabetic listing of terms, with entry points for each letter of the alphabet.
Hierarchical display	This will show the hierarchical relationships between terms. It should have two options for ordering terms within nodes: alphabetic, or based on the value of a nominated field in the thesaurus. Users will have the ability to collapse and expand individual nodes. There should also be a 'collapse all'/'expand all' function.
Term display	When the user selects a term, all the term's family relationships will be displayed. Relationships include broader terms, narrower terms, preferred terms, non-preferred terms and other related terms. Every related term will have a hot link which causes information about that term to be fully displayed. A term's Description and Scope Notes will be included in the display. Terms will be displayed in a case-sensitive manner, showing the case that was used in the source thesaurus. Upper case is used to denote a preferred term and lower case to denote a non-preferred term. Candidate terms will not be displayed. These are terms that an indexer has suggested for addition to the thesaurus but which have not yet been formally approved or declined.
Search	All thesaurus web pages will contain a search function to assist users find the term they are looking for. All words in the Terms, Definitions, and Scope Notes will be included in the search. The search will be case-insensitive. A Boolean search will be available for advanced searchers.
Help	All thesaurus web pages will provide access to context-sensitive help. These pages will include text explaining the purpose of thesauri in general (for beginners), how they work, what the various term types mean, etc. Sector-based examples may be provided to provide information in a more relevant context. A KWOC (Key Words Out of Context) report will be provided in HTML format for users to download and print. This will be created by the Portal Business Group.
Customisation	The template (look and feel) of all web pages will be customisable by an experienced web developer. Field captions should be automatically customised, if necessary, to be more user friendly. For example 'BT' could be customised to 'Broader Term'.
Feedback	All web pages will provide access to two types of feedback form. A general purpose feedback form is required for users to communicate with the Portal Business Group about any issue they choose. A more structured form is required for users to submit candidate terms to the Portal Business Group. This form could include the following fields: The user's contact information; The thesaurus, or element, in question; The candidate term; The suggested level in the thesaurus; The Broader Term; Preferred and non-preferred terms; Other relationships; A Description; Scope Notes; The reason for suggesting the term.
Printing	Users will not be expected to print the full thesaurus from their browser. Instead, a facility will be provided on the web for users to download a latest, print-formatted version of the thesaurus (probably as a PDF file). This file will be generated by the Portal Business Group by exporting the thesaurus to a tool such as Microsoft Word, where formatting will be applied.

6.2.2 Integration with the Cataloguing Tool

The web-based metadata cataloguing tool provided by the Portal Business Group will require full integration with thesauri. The web version of the thesaurus will therefore be capable of integration into a cataloguing tool. Cataloguers will require the full functionality of the web product, in addition to the ability to click on a term in the thesaurus and have it automatically populate the appropriate element in the cataloguing tool.

6.2.3 Thesaurus Standards

The thesaurus tool will fully support the following standards.

1. ISO 2788-1986 - Guidelines for the establishment and development of monolingual thesauri.

2. Zthes: A Z39.50 profile for thesaurus navigation. (http://www.loc.gov/z3950/agency/profiles/zthes-04.html)

MultiTes already meets the requirement of these standards.

6.2.4 Thesaurus Export

Many agencies will prefer to create metadata using their own cataloguing tools. To facilitate integration of NZGLS thesauri with these tools, a thesaurus export facility will be provided. This will be accessed through the web version of the thesaurus, available to anyone who wants it. Initiating an export will cause an XML-based Zthes representation of the thesaurus to be delivered to the client's computer.

6.3 Maori Language Thesaurus

All software will be capable of handling text in the Maori language, particularly the macron character over vowels. This applies to the thesaurus itself, its display on the web, its printable version, its search feature, and all other text on the web site.

Maori thesauri have yet to be developed. When the time arrives, the suitability of the existing MultiTes product will be reviewed.

6.4 Security

The most significant data captured by the system will be metadata. None of this information will be confidential and the metadata is likely to be fully discoverable by the public through the portal, with the possible exception of the NZA-Core administrative elements. Security is required for the following reasons:

1. to guarantee the integrity of the data by preventing accidental or deliberate physical corruption;

2. to make the data manageable by grouping it by agency or user;

3. to prevent external or agency users accidentally or deliberately editing data belonging to other agencies or users;

4. to control access to system functions depending on the user's role.

The Metadata Management Facility will have a security system that meets the requirements specified below.

6.4.1 Data Integrity

The system will be managed in a secure environment in a manner that prevents unauthorised access. This issue will be addressed by the hosting agency, the availability of a sufficient level of security being one of the contributing factors to their selection as host. Effective backup and restore procedures will ensure that the effects of any corruption are minimised. A front-end security system will restrict access to those having a valid User Id and Password.

6.4.2 Data Manageability

Because across-government metadata is being stored in a single repository, a means is needed to identify the source agency of each record, so that an agency can access its records independently of those belonging to other agencies. The NZA-Core administrative elements will be the primary means for achieving this.

Once a user has logged in, access requests will be filtered to return records associated with the user's own agency only. Central administration staff with higher access levels will be granted access to all records regardless of the agency.

6.4.3 Restricted Access

Access to online tools will be obtained by supplying a User Id and Password on the web site. The User Id will enable the system to identify the user's Agency and their Role, and through the Role determine what functions they are allowed to access. A central System Administrator will be responsible for adding, changing and deleting user-level security information.

Access to various functions of the system will be determined by a User's Role. A central System Administrator will be responsible for assigning Users to a Role and unassigning them. It is acceptable for roles to be permanently created in the system and not be user maintainable.

A maintenance function will be provided to allow a central System Administrator to maintain agency and user details and assign roles to users.

6.5 Workflow

A workflow process is required to manage the various stages of a metadata record's life-cycle, from creation, to public discoverability, and then its eventually archiving. The NZA-Core element metadataStatus will be the means for controlling this. The ability to modify this element will depend on the user's role, defined in the Security System. The following tables describe how the workflow process will function.

Roles

Role	Description
Agency Cataloguer	A person at an agency who creates or maintains metadata.
Agency QA	A person at an agency who has been authorised to quality assure metadata, prior to it being passed to the Portal Business Group for completion and/or approval. In many instances, a single person will perform both the cataloguing and QA roles.
Central Cataloguer	A Portal Business Group officer who performs additional cataloguing, completing elements that are not applicable at the agency level.
Central QA	A Portal Business Group officer who has been authorised to quality assure the entire metadata record, with the right to determine when the record should be made discoverable by the public. The flexibility exists for central cataloguing and QA to be performed by the same person.
System Administrator	A Portal Business Group officer with access to all areas of the system, including Cataloguing, Thesaurus Maintenance, and Security System Maintenance.

Metadata Status

metadataStatus	Purpose
agencyWIP	Indicates that a record is in the process of being modified by the Agency Cataloguer and is incomplete.
invalidImport	Indicates that a record (always from a harvest or import) has failed the automatic validation. Once it is edited, if it is valid it become awaitingAgencyQA, if it is still invalid it becomes agencyWIP.
awaitingAgencyQA	Indicates that a record has been completed by the Agency Cataloguer, or was input from an input file or a harvest and is valid, and is waiting to be checked by the Agency QA.
passedAgencyQA	Indicates that the Agency QA has checked the record and it is complete as far as the agency is concerned. It is now ready for the Central Cataloguer to apply the finishing touches.
awaitingFinalQA	Indicates that the Central Cataloguer has completed their work and the record is now complete and ready for final QA.
public	Indicates that the record is now discoverable by the public.
archived	Indicates that the record is no longer relevant, except for historical purposes.

The granting of editing authority to a user will be based on their role and the metadata record's current status, as shown in the table below:

From Metadata Status	To Metadata Status	Authorised Roles
Agency WIP	Awaiting Agency QA	All
InvalidImport	Awaiting Agency QA	All
InvalidImport	Agency WIP	All
Awaiting Agency QA	Agency WIP	All
Awaiting Agency QA	Passed Agency QA	Agency QA Central Cataloguer Central QA System Administrator
Passed Agency QA	Awaiting Agency QA	Agency QA Central Cataloguer Central QA System Administrator
Passed Agency QA	Agency WIP	All
Passed Agency QA	Awaiting Final QA	Central Cataloguer Central QA System Administrator
Awaiting Final QA	Passed Agency QA	Central Cataloguer Central QA System Administrator
Awaiting Final QA	Awaiting Agency QA	Agency QA Central Cataloguer Central QA System Administrator
Awaiting Final QA	Agency WIP	All
Awaiting Final QA	Public	Central QA System Administrator
Public	Awaiting Final QA	Central QA System Administrator
Public	Passed Agency QA	Central Cataloguer Central QA System Administrator
Public	Agency WIP	All
Public	Archive	Central QA System Administrator
Archive	Public	Central QA System Administrator

The default metadataStatus for a new metadata record will be 'agencyWIP'.

Public queries will always include a filter to retrieve only records with a metadataStatus of 'public'.

Users with agency roles will only be allowed to edit records belonging to their own Agency.

Users with central roles will be able to edit all records.

Users without editing authority will be presented with a read-only screen.

6.5.1 Life-Cycle Diagram for metadataStatus

The diagram on the left is for manually entered metadata. The diagram on the right is for harvested or imported metadata.

6.6 Feedback Form

Online tools will include a web-based feedback function, allowing users to communicate with the Portal Business Group to:

• provide feedback;

• ask questions;

• report problems.

6.7 Configurability

It is desirable, although not essential, that the system should be configurable by the system administrator.

Validation rules, element refinements and control lists should be able to be added, changed and removed without recourse to the vendor. Element should also be able to be added, although the removal of elements is a less important requirement.

Both the database and the input screens need to be configurable.

[ Previous | Next ]