APPENDIX 3
Handles
Test
1. Timing and background
1.1 Initial difficulties
The handles test took a much longer elapsed time than originally expected for a number of reasons unrelated to the basic functionality of the system. They related mainly to:
- Obtaining and installing desktop software (X-windows and Java RTE)
- Problems associated with the accidental loading of an outdated version of the software.
The Handles software was downloaded at the end of November and installed a few days later with relative ease. At the beginning of the test, X-windows software was required to enable DD to directly access the server the system from her PC. This required the installation of X-vision. The only licences for X-vision in the Library are for CJK use and are installed via PCMan. The version loaded via PC man requires the loading of CJK fonts.
The most time consuming initial hurdle was the inability of DD to authenticate herself on the system to initiate testing. Peter Newman was able to authenticate himself intermittently, but never on Dianas machine. Many frustrating hours were spent on this. Eventually Peter traced the transactions and discovered that whenever requests were going to a particular IP address, authentication failed. When this information was forwarded to CNRI, they realised that we were operating with an old version of the software that was addressing a server that was no longer operational. In the few days between the time the software was downloaded and the time it was installed, a new version of the software had been issued. Unfortunately, this was discovered just before Xmas. After Xmas DD was involved in writing and delivering a paper at the Information Online conference in Sydney. No further work was done on the system until the end of January.
In the meantime, the Helpdesk had installed Java runtime environment on PCman so that the Java client could be run on the desktop. Peter installed the client on Dianas PC and she began functional testing of the administration client at the beginning of February. After familiarisation, Julie Whiting also had a look at the system.
1.2 The Handle system
A Handle System operation has two basic components, resolution and administration.
- Handle resolution is achieved by a software client submitting a handle query to a handle service and receiving back the set of handle values from the responsible handle server. These can be displayed or used to access a resource if a URI is one of the values returned.
- Handle administration allows users to manage handles, including adding and deleting handles, or updating their values, over the public Internet. It also deals with naming authority administration via naming authority handles.
Both types of operations may require authentication of the user via the handle system authentication protocol
2. Aims of the testing
The aims of the testing were to assess the functionality and the installation, support and maintenance requirements of the system.
Aspects of the functionality which were considered included
- The administration and change function
- Ease of use
- Adequacy of documentation
- Management and reporting functions
Aspects of the installation and support requirements of the system that were considered included:
- The level of experience needed to install
- The adequacy of the documentation to support the process and enable problem resolution
- The level of support required from CNRI
- The level of support that may be required from the NLA if the system is adopted and offered to others.
- Compatibility with existing systems and skills
- Efficiency of the caching software
- Ease of use of the API to facilitate the development of ancillary services such as batch loading procedures
- Performance (including, unusual or excessive resource requirements, platform requirements, disk and memory use)
3. Administration and change functions
The administrative and change functions were carried out using the Java client on a standard NLA desktop PC and using X-windows on the server. Java RTE (Run Time Environment) was incorporated into the PCman suite by the Helpdesk staff and loaded via PCman. Since the Java client is what users would be supplied with in an operating environment, the comments on the functionality that follow are based on use of that client.
3.1 Authentication
Each handle established requires at least one administrator. In order to create, modify or delete a handle, a user must first establish that (s)he is authorised to perform those functions under the naming authority.
The authentication system is not intuitive, and the available documentation on the authentication process is minimal. An element of confusion is introduced by the fact that administrators are identified by a handle. The exact procedures to be undertaken were not therefore immediately obvious. This led to the creation of a batch of handles that could not be changed because they had invalid administrators. The first handles created manually also had invalid administrators for a different reason (See 3.2). Unfortunately, handles with invalid administrators, cannot be deleted or amended, since the authentication process is dependent on the presence of a valid admin type to authenticate against.
Once worked out and understood, however the authentication and administration process is not a difficult one. With improved documentation and a small amount of training, these problems could be avoided in a production implementation. A suggestion will be forwarded to CNRI that a check be made for an invalid handle used as an administrator value.
3.1.1 Creating a vlist
Administration and authentication can be managed by way of vlists or groups of people identified as having a given set of privileges for a particular naming authority. This is the most sensible way to manage the administration function, since people can be assigned to the group or removed from the group and immediately acquire or lose the authority to administer the handles for which that group has administrator privileges. This is an extremely useful feature, as the creation of large numbers of handles with individuals designated as administrators would be impossible to manage.
3.1.2 Security
The administration of the system is secure and relies on the use of private keys that remain on the site, on the desktop of the user.
3.2 Creating, Modifying, deleting handles
The tasks associated with the creation, modification and deletion of Handles were straightforward once the administration and authentication issues were sorted out and the syntax of the HS-ADMIN field understood.
The system prevents the creation of duplicate handles and responds with the message Handle already exists. It is possible; however, to recreate a handle after it has been deleted. It would therefore be better not to delete handles that are withdrawn.
It is also possible to use an invalid handle for an administrator and thus create a handle that cannot be changed or deleted. This happened in the case of the first handles created because the high level 1703.test was used without inserting the 0.NA prefix required for the top level naming authority when used without the Namespace Specific String (NSS)
3.2 Querying
Querying the attributes and values of handles is straightforward with correct authentication. Public read values can be queried without authentication.
3.4 Batch loading
A batch of handles for Pandora items was loaded with no problems other than that mentioned above relating to authentication. Because of a misinterpretation of the documentation, they were inadvertently created with their own handle as the administrator and could not be modified or deleted. This is not a problem that is likely to be repeated.
3.5 Listing Handles
The administration client has a function for listing handles, but in its present form it is very basic. It allows the listing of handles assigned under a particular naming authority and gives two options for output; output to the window on the screen, or output to a text file. There is no facility to sort the output and the list appears to be a random arrangement neither alphabetical nor arranged in date order. (Possibly the order stored on the disk?)
The only data output is the handle name, with no associated information. When output as a file, it is presented as a text file in a single string.
To be useful as an administrative tool, the listing would require, as a minimum, the ability to extract other associated information from the database (URLs, date, etc.) and the development of some formatting and processing software.
4. Documentation
The documentation is minimal and could be improved. It would be necessary to supplement it and an expanded set of user documentation with examples would have to be written.
5. Ease of use
We were looking at the system with no training and minimal documentation but after a few mistakes with authentication, managed to understand and operate the system. If a decision were made to install the system in house, it would be advisable to provide a training course such as those run by CNRI and IDF for DOI participants. This would avoid a few of the traps for young players which could be better documented.
There are a few minor irritants with the user interface which do not affect the functionality of the system but which can be frustrating and detract from the ease of use of the Java client. For example, before entering data it is necessary to click with the mouse in the box; using the browse option to locate the private key wipes out the text input into the handle box and it has to be rekeyed.
Use of the high level naming authority name without prefixing 0.NA/ results in an invalid handle and therefore unchangeable handles when it is used in the administrator field. There is no error message warning that the handle is invalid, even though the syntax could be easily validated on input.
6. Installation, support and maintenance requirements.
6.1 Loading the software
Installation was relatively straightforward with the exception of the initial difficulties relating to the outdated version of the software outlined above. Peter is a very experienced Unix programmer and is familiar with Java. A basic understanding of Unix and Java would be necessary for a system administrator.
6.2 Support
CNRI response to questions was good. They were prompt and informative. The software is straightforward and would be relatively easy to support in organisations with appropriate skills. It would, however, need improved documentation and some training to enable users to avoid or minimise errors and questions when starting out.
6.3 System requirements
An estimate of system requirements is as follows:
- 10Mb of disk storage for the application
- 6Mb of RAM to run the server process plus a further 32Mb in swap space
- Approximately 3Mb of disk storage for every 1000 handles put into the system and tapes needed to backup this data (Pandora currently there are approximately 600,000 to 1 million individual files. 1 million items would use approximately 3Gb of disk storage. Images 1 has 50,000 files requiring 50 Mb of disk storage)
- The java runtime 1.1.7 or 1.1.8 environment would be required
Staff resources needed for batch loading:
Once the standard format of NLA handles are decided it would take 2-5 days to write the batch file to load into the system and plus a further week to load them. For newly archived sites within Pandora it would be feasible to automatically load the details into the handle service as a part of the Pandora Collecting System post gathering process.
Similar times would be required to develop scripts for the batch loading of pictorial images and other digital surrogates.
7. General observations
The system has the basic functionality required for a PI system for a digital library and is perfectly adequate as a building block in a total system architecture. It is the only system available that currently offers resolution and multiple resolution capabilities.
It would however need a number of software developments, and considerable work to integrate it into processes, procedures, and organisational arrangements to make it a complete and useable system. This is especially true if identifiers are to be assigned automatically in batch mode for Pandora items and for digital surrogates. Handles for web documents would be allocated individually as they are created and mounted on the server.
Management reporting is very basic and the development of routines for the extraction of reporting information would be necessary.
Many of the NLA requirements are the same as those required by the IDF for the DOI system and may also be of interest to LC. For this reason, it is possible that NLA will be able to take advantage of these as they are developed, e.g. multiple resolution, association with metadata and reverse look up.
LC has indicated that they would, if the NLA decides to use the Handle system, be interested in cooperation in the development of some of the functionality required and in improving the user interface.
8. Conclusions
The system is straightforward and well supported. There is no doubt that the Library could support it either as a straightforward PI resolver system or as part of the business processes of a DOI registration agency. It is the best option currently available.
However, there are a number of factors that make it inadvisable at this time
- Investment required for the establishment of the systems and procedures and the extent of system modifications, including reporting mechanisms, that would be required.
- Many agencies that might be partners in a distributed system may not be ready at this time. UNIX and Java skills of a high order are needed.
- Still need proxy server to use with standard browsers.
Recommendations
That the Library not proceed with the implementation of the Handles System at this time for the reasons outlined above.
That the developments with DOIs use of handles for multiple resolution and the association of metadata with handles continue to be monitored.
| Return to Table of Contents | Proceed to Appendix 4 |
| About This Site | Copyright | Privacy | Accessibility | Site Map | Site Search | Content A-Z | Contact Us |