The interface to the RDB version 1.2 is currently provided via an ODBC connection direct to the database, using Microsoft Access as the client. This is because it is quick to set up and uses software which is easily available (the Postgres ODBC library needed to set this up can be downloaded free from the Postgres web site). Any client software which offers the facility of read/write access to a remote database could be used instead of Access if desired.
A minor disadvantage of this method of access is that it requires a considerable amount of configuration on the Postgres server. The client IP address - and, in the case of dynamic IP addresses, the entire range which is possible - needs to be given access. Similar configuration would need to be done for any database which is used to replace postgres, and this is something which could not be done with a standard method described in documentation. A customised interface which used access via a local script to the server would not have this problem, as the only IP address accessing Postgres would be the local one.
The main disadvantages of this method of access are due to the client chosen; without the opportunity to test other database integration tools (such as Lotus Notes) against the resource database, it is not possible to decide whether other clients would give an improved interface.
The main problem this causes is that it requires the database administrator to be familiar with the structure of the database, so that (for example) they can know that the way to add a new keyword to a resource is to add entries to the resource_keyword and keyword table. This means that far more detailed training - and documentation - is necessary for administrators than would be the case with an access method which hides the database structure. In addition, changes to the database structure require the updating of this information, and all the existing administrators need to be made aware of the alterations; if a field name is changed (for example), this would only require alterations to the back end of any interface which hid the actual database from the administrator. The current set of instructions is available from the HeadLine web site.
Some common editing tasks are obvious from the database structure, others need to be determined by observation of administrators of the database. In an ideal world, it would be possible to program the interface to the database in such a way that the tasks to be done are completely configurable, so that as an admistrator gradually develops their working practices, the interface could be amended to match what they do. However, such an approach would be extremely difficult to program, because of the highly interlinked nature of the database structure, and would probably run into many of the same problems as the use of Access (for the same reason: attempting to be too general).
A list will be made of the expected common functions, and then this is reviewed by the resource maintainers at several points until the end of the evaluation period.
This is a first attempt at a list of common administrative functions.
Some of these functions will not exactly be common, but will of necessity be present (e.g. deleting a resource).
The following functions will probably be needed, but will be mainly used when the RDB is being set up at an institution.
After authentication, the administrator will be given a list which corresponds to the list of functions above, with the common ones first. A list will be given of the existing entries in the database of the appropriate type (resources, keywords) - for locations, a list of resources will be given and then the locations which correspond to the selected resource. The user can then choose to edit an existing entry, create a new one like an existing one for the complex items (resources and locations), or create a new one from scratch. It may be that in some cases administrators will want to be able to select multiple resources, for example to enter a new keyword for many resources.
Most fields will have text boxes with free text, but there will be others which will have controlled lists (e.g. media type). These will give the list of the possible entries already in the database with the option of creating new ones. (It could be a configuration parameter whether this option is available or not; once an institution has created a controlled list, they may not wish to expand it.) The information that is entered will be displayed for confirmation (again, whether this is done could be configurable). When the user has edited a resource, they will be prompted as to whether they want to add locations, but some of the other linked tables from the database will be automatically present in the resource creation - such as keywords.
The detailed design of the interface will then basically amount to decisions as to which fields should be controlled lists.