TESTBED TEAM

T1

DEVELOPMENT TASK: World Wide Web access to testbed

PLANNED ACTIVITY

We will make a credible subset of the testbed's capabilities accessible to the general public via the World Wide Web. The general strategy is to maintain a public testbed interface that is a proper subset of, and is significantly more stable than, the private interfaces used by project researchers.

Current testbed team activities directed toward this goal include:

1. specifying the public subset of the testbed's web interface, placing it under configuration control, and instrumenting it to capture user feedback;
2. creating extensive online documentation, tutorials, and assistance for new users;
3. loading additional data and metadata of general interest;
4. upgrading our web server to prepare for the anticipated load increase.
   

ACTUAL ACTIVITY

This task is still a very high priority but has been delayed for three reasons:

1. A web/database server of sufficient capacity to support a fully-public ADL was not delivered until November 1996.
2. We lost our chief programmer in July 1996, and it took several months for the new programmer to get up to speed on the ADL software.
3. User evaluations from our limited-access test period indicate that our Web user interface needs a substantial redesign to be usable by nonspecialists.
   

T2

DEVELOPMENT TASK: Characterization of DBMS performance

PLANNED ACTIVITY

The Alexandria catalog is designed around RDBMS technology but is intended to be DBMS-independent. The current catalog, however, stresses existing database technology in such areas as table size, join complexity, text search, and spatial search. Our extensive experience with Illustra and Sybase, and an initial evaluation of Oracle, lead us to believe that each DBMS product will have a different set of idiosyncrasies that the Alexandria catalog system must accommodate in order to achieve acceptable performance. We are taking the following steps toward identifying these idiosyncrasies and their work-arounds:

1. set up reference installations of Illustra, Oracle, and Sybase, on the same hardware/ software platform;
2. list known DBMS idiosyncrasies, with example queries;
3. refine (2) into an "alexandria benchmark";
4. run the benchmark against current and new database systems.
   

ACTUAL ACTIVITY

The rationale for this task has evaporated. Since Sybase does not support spatial data, we have little interest in benchmarking it. Illustra's acquisition by Informix has mooted the issue of benchmarking the Illustra server, we are instead attempting to gain access to a beta relase of the Informix "Universal Server", which incorporates most of the Illustra extensions. We also do not yet have a single platform on which Oracle and Informix both run.

T3

DEVELOPMENT TASK: Explore executable-content web user interfaces

PLANNED ACTIVITY

The current testbed web interface assumes a minimal browser (an HTTP client supporting HTML 2.0 plus tables). The testbed's web server thus assumes the considerable burden of supporting a stateful, graphically rich interface under a stateless, graphically sparse protocol. The advent of web browsers supporting executable content, typified by sun microsystem's Java language, allows us to rethink our division of labor between web client and server, and also to support client graphical metaphors impossible in HTML. We will migrate the testbed towards an executable-content environment (probably Java) by concentrating initially on image-based applications:

1. add top-level image content search component to web UI;
2. build an inverse wavelet transform applet to support progressive retrieval of wavelet images;
3. build a map browser applet (replaces current map server);
4. replace other interface components with applets, depending on user feedback.

ACTUAL ACTIVITY

Task (a) is completed. Tasks (b) and (c) are underway but have been delayed by the poor performance of interpreted Java in most Web browsers. Task (d) awaits the pending redesign of our user interface.

T4

DEVELOPMENT TASK: participate in national spatial data infrastructure

PLANNED ACTIVITY

The national spatial data infrastructure (NSDI) is a collection of spatial data providers who agree to make standard metadata (FGDC) available via a standard network protocol (Z39.50). Since the Alexandria catalog schema is based on the FGDC geospatial metadata content standard, the Alexandria project is well-positioned to participate in this effort. We will start by offering simple full-text weighted searches (analogous to WAIS) against a structured text dump of the catalog, and migrate to direct database queries using the proposed GEO-1 spatial data attribute set.

1. install a Z39.50 server and full-text search engine in the testbed.
2. dump a snapshot of the alexandria catalog in a form usable by the full-text search engine.
3. add database query capability to the Z39.50 server.
4. adopt GEO-1 attribute set (when finalized) for Z39.50 queries.

ACTUAL ACTIVITY

This task is still a priority but has been delayed by late delivery and poor performance of the Isite Z39.50 server software. Since the Isite developers are committed to supporting database gateways and the GEO-1 attribute set, we are willing to wait for a usable version of their product, we do not have the resources to develop a Z39.50 server from scratch.

T5

DEVELOPMENT TASK: Infobus (CORBA) catalog proxy

PLANNED ACTIVITY

The Infobus is the inter-library communication mechanism being developed by the Stanford DLI project. We are working with Stanford to develop an Infobus "proxy" (object interface) for the Alexandria catalog. The proxy will be implemented in ILU, a portable, freely-available implementation of the CORBA distributed object standard. Stanford will provide a corresponding Infobus client that can act as a Z39.50 server (see previous project). We will proceed as follows:

1. set up Infobus infrastructure (ILU, development tools, etc.);
2. build a ``dumb'' infobus proxy (e.g. only implementing fulltext search);
3. build a ``smart'' infobus proxy (i.e. can issue catalog queries).

ACTUAL ACTIVITY

This task has been delayed for 2 reason:

1. The most recent supported release of ILU was found to have major backward incompatibilities, leading Stanford to re-evaluate the use of ILU as the basis for the InfoBus.
2. As part of another project, ADL was required to bring up a fully-compliant CORBA 2.0 environment, for which ILU was found to be unsuitable.
   

T6

DEVELOPMENT TASK: Instrumentation for user interface evaluation

PLANNED ACTIVITY

The Alexandria user interface evaluation team is conducting extensive, systematic evaluations of the efficacy and usability of the testbed user interface. The testbed team supports these evaluations by providing appropriate ``hooks'' in the testbed to log user interface events for subsequent analysis, specifically:

1. add passive monitoring (per-session mouse click and page visit logs) to the public testbed interface;
2. add active monitoring (positive/negative feedback buttons and comment forms) to the public testbed interface;
3. help ui evaluation team digest monitoring data.

ACTUAL ACTIVITY

These tasks have all been completed.

T7

DEVELOPMENT TASK: Integration of credit payment mechanism

PLANNED ACTIVITY

We are cooperating with CMU to implement NetBill as a mechanism to pay for library services. We plan to have a beta test version running for UCSB students by 05/30/96 and to develop agreements with various third party vendors of map products. These mechanisms and ranges of purchasable items will be extended throughout the 12-month period.

ACTUAL ACTIVITY

This task was delayed until the coming year because of delays in the availability of the NetBill software package from CMU.

T8

DEVELOPMENT TASK: Catalog quality assessment and control

PLANNED ACTIVITY

The Testbed Team, as the custodian of the catalog database, has primary responsibility for ensuring the consistency and accuracy of catalog records. We necessarily gave quality control only minimal attention during the initial construction of the testbed, but now that (portions of) the catalog will be publicly available, we must impose rigorous quality assessment and control procedures. We will:

1. perform an initial QA of the public portions of the catalog;
2. specify precise domains and/or thesauri for all currently unconstrained (``free text'') catalog fields;
3. prepare an Alexandria metadata standard to guide further cataloging;
4. implement metadata standard as database rules and/or other automatic integrity constraints.

ACTUAL ACTIVITY

These tasks are completed.

T9

DEVELOPMENT TASK: Metadata exchange and ingest standards

PLANNED ACTIVITY

The Alexandria catalog is currently loaded entirely by Alexandria personnel, using ad-hoc metadata extraction, formatting, and verification procedures for each dataset. Since this approach will not scale into an operational digital library, we are developing mechanisms for loading and sharing metadata with emerging standard formats and protocols. Specifically, we will:

1. develop an open database connectivity (ODBC) catalog interface for ingesting manually-entered metadata using forms-builder tools (e.g. microsoft access);
2. participate in the FGDC working groups defining new versions of the geospatial metadata standard;
3. work with the California Environmental Resource Evaluation System (CERES) to support their SGML-based metadata exchange mechanism;
4. work with the national spatial data infrastructure (NSDI) to support the Z39.50 query protocol and the GEO-1 attribute set;
5. work with the EOSDIS core system (ECS) to support their parameter-value (PVL) metadata format and hierarchical data format (HDF).

ACTUAL ACTIVITY

Tasks (a) is completed. Tasks (b) through (d) are in progress. Task (e) awaits the availability of ADL-appropriate datasets in these formats.

T10

DEVELOPMENT TASK: Security for special collections and transactions

PLANNED ACTIVITY

The agreement with the Mojave Desert Ecosystem Project (see ADL Annual Progress Report) involves datasets that may require varying degrees of control on access. Hence security is an issue of some importance. Furthermore, the use of a system like NetBill also has security implications. R. Kemmerer will examine these issues and suggest approaches for implementing the appropriate degree of security for both collections and transactions.

ACTUAL ACTIVITY

This task is currently underway.