Generic Query Metadata for Geospatial Digital Libraries

ABSTRACT

The Alexandria Digital Library (ADL) is a distributed digital library for geographically-referenced information. Two primary goals of ADL are to make it as easy as possible for (a) new information collections to be added to the library, and (b) users of the library to issue a single query against multiple heterogeneous collections. While problem (a) requires ADL to be as accepting as possible of existing, collection-specific metadata schemata, problem (b) requires all collections to appear to the user to support identical searchable metadata.

ADL has resolved this conflict by developing search buckets, a small set of high-level metadata attributes. All holdings accessible through ADL are queryable according to these attributes, which currently comprise:

• geographic location: "footprint" (point, bounding box, polygon, etc.) in geographic coordinates;
• type: form (e.g., map, aerial photograph, etc.) or content (e.g., hydrographic feature, airport, etc.);
• format: format(s) in which the holding can be delivered, both online and offline;
• topical text: text gleaned from any attributes that might indicate topics or themes;
• assigned term: subject headings, index terms, keywords, etc. (i.e. topic or theme terms specifically assigned by catalogers);
• originator: author, agency, publisher, etc.;
• date range: beginning and ending dates of coverage, publication, etc.; and
• identifier: ISBN, report number, image ID, etc.

Each ADL collection must provide mappings between the search bucket attributes and its own specific metadata. Facilitating this mapping (and thus encouraging the growth of ADL) has been the prime instigation for keeping the buckets few and simple. Conversely, the buckets are the only searchable attributes that an ADL user can be guaranteed will address the entire universe of ADL holdings. Facilitating expressive queries has been the prime instigation for giving the buckets fairly precise semantics (more so than similar high-level metadata schemes such as the Dublin Core.)

This paper discusses our development and use of the search bucket concept. After a brief introduction to ADL, we discuss the tension between simple, library-wide retrieval metadata and rich collection-specific descriptive metadata, and why its resolution is critical for a distributed, heterogeneous library like ADL. We then present the current ADL search buckets in detail, including their types, operations, population rules, and pending issues. We describe how the search buckets are implemented in the current ADL architecture, specifically how they are supported by ADL's server (collection) and client (user) interfaces. We compare the ADL search buckets to other high-level metadata designs. Finally, we discuss possible future developments of the search bucket concept.

1.0 THE ADL CONTEXT

The Alexandria Digital Library Project [1] is a consortium of researchers, developers, and educators, spanning the academic, public, and private sectors, exploring a variety of problems related to distributed digital libraries for georeferenced information. The centerpiece of the Project is the Alexandria Digital Library (ADL) [2], an online information system inspired by the Map and Imagery Laboratory [3] in the Davidson Library at the University of California, Santa Barbara (UCSB). The ADL installation at UCSB currently provides access over the World Wide Web to a subset of the MIL's holdings, as well as other georeferenced datasets.

Our approach to query metadata is best understood in the context of two properties of ADL:

1. ADL is distributed: its components may be spread across the Internet, as well as coexisting on a single desktop. An ADL installation may contain multiple collections, each with its own unique metadata schema. An ADL installation may also support multiple clients; for example, graphical interfaces, analysis environments, and gateways to other library systems.
2. ADL's holdings are georeferenced: each is associated with one or more regions (footprints) on the surface of the Earth. This enables geographic searches of ADL's contents, which is a fundamental capability of ADL.

We are therefore strongly motivated to support query metadata that are generic enough to reflect and exploit a wide variety of distributed, heterogeneous collections, yet are expressive enough to reflect and exploit ADL's special capabilities.

2.0 THE GENERIC SEARCH PROBLEM

A heterogeneous digital library requires a search mechanism that:

• applies uniformly to all its collections;
• allows querying of specific parameters;
• is intuitive enough that most users will correctly anticipate the behavior of its parameters and options, without having to consult documentation;
• is easy for catalogers to map into specific object-level metadata schemata;
• exploits appropriate controlled vocabularies (e.g., thesauri, valid terms, classifications, subject heading lists, etc.), both to guide searches, and to aid cataloging; and
• is extensible.

Our overriding design philosophy has been to provide a set of generic parameters for initial searching that is both small enough to be manageable and rich enough to ensure that a given query retrieves a collection's most relevant items. In other words, our generic search supports recall at the expense of precision, but with field-specific searching's advantage over undifferentiated full-text searching, such as is provided by typical Web search engines.

Earlier versions of ADL gave users search access to each of the hundreds of attributes in the ADL metadata schema, many of which were not populated for any particular object. There were two major problems with this approach:

1. The user had to know a lot about the ADL metadata schema and what attributes existed for particular types of information; and
2. A search of any particular attribute would miss finding items that were relevant but lacked data in that attribute.

Generic query metadata ameliorate (but do not fully eliminate) both of these concerns. Users need not know the structure of the underlying metadata, and a search against generic parameters is more likely to access all of the objects in a particular collection. In a multi-collection digital library system, where the underlying metadata for each collection can be based on dramatically different standards and schemata (e.g., USMARC, Dublin Core, GILS, ADL Gazetteer Content Standard, FGDC Content Standard, etc.), searching object-level metadata attributes directly is unworkable.

The loss of precision inherent in generic search parameters can be mitigated in two ways. First, queries can be carefully specified in terms of more restrictive predicates (e.g., "contains" instead of "overlaps", "and" instead of "or", controlled vocabularies instead of arbitrary text, etc.) Second, the generic query user interface can support a rich array of post-processing operations on a query's retrieval set: sorting, plotting (e.g., footprints on a map), visualization (e.g., "thumbnails" of image data), and winnowing or combination into user-defined sets. Note that both of these approaches are contingent on generic searches being part of an iterative query process.

Experienced searchers will notice an additional side effect of the generic search parameters' level of aggregation. For example, consider personal author names. When these are treated as distinct search parameters, a personal author index can be scanned to pick out variations in name form (e.g., "Frew, J.", "Frew, James", and "Frew, Jim"). But when personal names are lumped with organizational names into a generic search parameter, personal name searching degenerates to word-based search. Scanning a word index will only show that "Frew" and "James" exist as words, as well as some "Jim" and "J" entries, but the full author name will not appear. Of course, phrase searching, adjacency searching, and other text searching techniques can allow users to find instances of "Frew, James" and its variants if the users know how to apply them, but the tradeoff for generic queries is more effort on the part of the user to construct precise ones.

From a cataloger's or collection developer's point of view, generic search parameters are a classification of object-level metadata attributes. Effectively, each attribute is classified as "searchable," "for evaluation purposes," or "for administrative purposes." Each "searchable" attribute is mapped to one or more of the generic search parameters. It is therefore critical that the search parameter semantics are clear and unambiguous, so that this mapping can be done easily and correctly. The documentation of these mappings then becomes useful information for searchers.

A critical factor in implementing generic search parameters is the availability of controlled vocabularies to describe collection object attributes. Controlled vocabularies are either lists of possible attribute values (sometimes called "valids"), or thesauri giving the relationships (hierarchical, synonymous, or related) between terms. Catalogers use controlled vocabularies to guide the process of populating the search parameters. Controlled vocabularies also help users assemble more precise and reliable queries.

Ideally, the controlled vocabularies associated with a generic search parameter will be the same as those used to catalog the underlying collection. However, we cannot assume that this 1:1 association can be maintained across multiple collections. There are two possible solutions to this problem. One is to associate a single "master" vocabulary with a search parameter. The other is to use external tools and methods to infer or evaluate the mappings between different vocabularies. The former solution requires an authority to compile and maintain the master vocabulary and its mappings to object-level metadata, while the latter solution is an area of active research [4].

3.0 THE ADL SEARCH BUCKETS

In response to the generic criteria outlined above, and to the particular needs of a geospatial digital library, we have designed and implemented a set of generic search parameters for ADL. We call these parameters search buckets, to emphasize that:

1. They are intended primarily for querying (as opposed to description); and
2. They are high-level containers for metadata from multiple underlying sources.

The ADL search bucket scheme currently comprises the following attributes:

• geographic location
• type
• format
• topical text
• assigned terms
• originator
• date range
• identifier

In the remainder of this section we describe each bucket in detail.

3.1 geographic location

The geographic location bucket contains the footprints of library objects. Recall that each object in an ADL collection should be associated with at least one footprint (region on the surface of the Earth). The geographic location bucket contains the geographic coordinates (latitude and longitude) of the vertices of the geographic polygons bounding the object's footprint. Note that a single object may have multiple disjoint footprints.

ADL uses the geographic location bucket to support its geographic search capability. Two query operations are defined on the bucket, contains (the footprint in the bucket is wholly contained in a query footprint) and overlaps (the footprint in the bucket at least partially overlaps a query footprint). Note that contains is a proper subset of overlaps.

In practice, the footprints assigned to the geographic location bucket usually fall into one of two special cases: points (single vertices) and "bounding boxes" (rectangles). Points are often the only footprint information available for relatively small features (e.g., cities on a world map). Bounding boxes have two advantages. If a feature does not have a polygon associated with it, but is associated with more than one point, then the bounding box may be trivially computed. Moreover, even if polygonal footprints are available, a bounding box may be preferable to search on, for reasons of index efficiency.

3.2 type

The type bucket contains terms that precisely specify an object's form or content. In general, a type is the target of an "is-a" relationship; i.e., a type can be applied to an object if the assertion "object is a type" makes sense. Valid terms for the type bucket are drawn from an ADL-controlled hierarchical vocabulary. The single query operation defined on the type bucket is thus an exact match against nodes or leaves in the type hierarchy.

The type and format buckets are the only buckets for which we currently mandate specific sets of valid terms. This is a difficult decision, for it means that we (or somebody) must serve as the controlling authority for these term lists. In the particular cases of the type and format buckets, the need for program-level interoperability is strong enough, and the scope of the term spaces constrained enough, to make controlled vocabularies both useful and feasible. In the specific case of the type bucket, for example, we are growing the type schemes for catalogs and gazetteers by merging existing domain-specific vocabularies.

3.3 format

The format bucket contains terms, drawn from an ADL-controlled vocabulary, that indicate the mechanisms by which a copy of the object can be delivered to a library user. In general, a format is the target of an "is-available-as" relationship; i.e., a format can be applied to an object if the assertion "object is available as format" makes sense. The distinction between type and format can be subtle (e.g., "aerial photograph" -- a type, versus "9x9 inch monochrome film positive" -- a format), which is a further argument in favor of their controlled vocabularies.

Where possible, the controlled vocabulary for the format bucket exploits standard terminology, such as MIME type specifiers for digital data. These have the advantage of being directly intelligible to programs accessing ADL holdings.

Since digital data can often be trivially and losslessly translated from one format to another, it can make sense to assign multiple formats to a single digital object. On the other hand, an analog object (e.g. a paper map) is generally cast into a single format upon creation, and can only be re-formatted imperfectly and with substantial effort (e.g. photographic enlargement.)

3.4 topical text

The topical text bucket contains text gleaned or derived from the object's detailed (i.e. collection-specific) metadata, that indicates any topics or themes associated with the object.

Topical text is the most loosely specified of the buckets. It is an an aggregation of words and phrases, from any underlying attribute, that indicate the object's topic or theme (e.g., title, abstract, subject, etc.) (As a limiting case, the topical text bucket could be populated with textual representations of all an object's metadata, although we don't recommend this.)

The topical text, assigned term, originator, and identifier buckets are all searchable with the standard ADL text operators:

• any word: true if the target bucket contains any of the query words, anywhere and in any order.
• all words: true only if the target bucket contains all of the query words, anywhere and in any order.
• exact phrase: true only if the target bucket contains the query phrase as a proper substring.

This set of operators was selected as a reasonable tradeoff between query power and ease of efficient implementation on a variety of platforms.

3.5 assigned term

The assigned term bucket is a proper subset of the topical text bucket. Text should only be placed in the assigned term bucket if it was specifically marked as significant by the object's original catalogers (i.e. the creators of the object's detailed metadata). If the assigned terms are selected from a controlled vocabulary (e.g., a thesaurus or a subject heading list), then a link can be made from this bucket to that vocabulary. We encourage this practice, but do not assume it in the semantics of the bucket.

The assigned term bucket's relationship to the topical text bucket is exploited by ADL's current implementation; for example, one ADL collection implementation reduces the assigned term bucket to a boolean flag on the topical text bucket (see section 4.7).

3.6 originator

The originator bucket contains any text describing people or institutions responsible for the object's creation or dissemination (i.e., any entity that could be an object's source). In addition to authors and publishers, this could include funding agencies, curators, technical support personnel, etc.

As was noted in section 2, the level of aggregation in the originator bucket tends to complicate some kinds of searches, since the bucket doesn't include semantics for personal or corporate names, nor does it require a particular kind of normalization when names are entered. As a result, queries for specific personal names will necessarily be approximate.

3.7 date range

The date range bucket may contain any dates or date ranges (beginning and ending date) associated with the object; such as its date of creation or period of validity. Date ranges are specified by pairs of beginning and ending dates, formatted as SQL-92 TIMESTAMPs [5].

The date range bucket may be thought of as the temporal analog of the geographic location bucket (i.e., date ranges are "time footprints"). Searches against the date range bucket may likewise specify overlap or containment, although the mechanism is somewhat different. Instead of specifying a target "time footprint", a date range search is specified in terms of "on or before" a beginning date, and/or "on or after" an ending date.

3.8 identifier

The identifier bucket may contain any labels for the object that are defined with respect to an externally-controlled vocabulary or production rule (e.g. ISBNs, technical report numbers, satellite image identifiers, etc.). These kinds of labels are useful for finding "known objects" for which the user knows the particular identifier. Digital data are often assigned identifiers as a function of their creation; published items often have ISBNs or ISSNs; "gray literature" often has unique technical report numbers.

In effect, the identifier bucket provides a "trap door" into alternative cataloging schemes. A nomenclature that is well-defined elsewhere can be accessed through the identifier bucket, and often provides the simplest and most precise means of locating an object, assuming one is familiar with the nomenclature. (Of course, there is always a risk of false hits from multiple nomenclatures that use similar encoding rules; for example, an arbitrary 10-digit numeric identifier could be mistaken for an ISBN code).

We assume that identifiers are normalized upon entry into the buckets (e.g., dashes are removed from ISBNs), and that the search terms are likewise normalized prior to issuing a query. The identifier bucket has no knowledge of the structure or semantics of specific identifier types.

4.0 IMPLEMENTING THE SEARCH BUCKETS

The ADL architecture [6] is centered around a middleware server that provides multiple clients with a uniform view of multiple heterogeneous collection servers. The ADL search buckets are the principal mechanism by which this uniform view is achieved:

• Clients formulate queries in terms of collection-neutral search buckets.
• The middleware server translates and forwards queries to the collection servers.
• Collections servers are responsible for evaluating the queries in ways that are meaningful for their respective collections.

We describe ADL's implementation of the search buckets in each of these architectural components: in JIGI (the Java Interface to Geospatial Information), ADL's standard graphical client; in the middleware server; and in one particular collection server, the ADL bucket database.

4.1 Overall implementation characteristics

In the current ADL implementation (and using the geographic location bucket as an example), a search bucket is the union of:

1. A conceptual set of contents (e.g., "any geographic locations or regions associated with collection items");
2. A set of allowable representations for the contents (e.g., geographic bounding boxes, points, and polygons);
3. A set of query operators (e.g., overlaps and contains); and
4. A name (e.g., geographic location) that uniquely identifies the bucket and its conceptual contents, allowable representations, and query operators. Uniqueness guarantees that identically-named buckets behave identically, regardless of the underlying collection.

Search bucket semantics, and in particular query operators, are loosely defined in the current implementation. For example, the geographic location bucket does not specify whether overlaps and contains operate on spherical or planar regions. This choice can affect query results, and thus a single geographic location query sent to multiple collection servers may produce inconsistent or confusing results. However, mandating precise semantics can incur prohibitive performance penalties, and we believe it is more important to give collection servers the flexibility to support query operators in the most natural and efficient ways available to them.

In addition to allowing collection servers considerable leeway to interpret bucket semantics, we currently do not require any more than a "best effort" from collection servers to support search bucket query operators. There are no mechanisms in the current implementation by which a collection server can formally communicate the level of its support (full, partial, or none) for a given query operator.

The remainder of this section roughly follows the flow of data within the system. A collection server's support for search buckets is described by collection-level metadata, passed from the middleware server to JIGI, which uses the metadata to customize search bucket query forms and to properly formulate queries. Queries are sent from JIGI to the middleware server expressed in a collection-neutral syntax. The middleware server translates the queries to collection-specific forms (typically, SQL) and sends them on to the appropriate collection servers. Finally, collection servers process the queries.

4.2 Description of search buckets

Each collection server registered with the middleware server is described by collection-level metadata, structured in XML according to an ADL-defined standard. The metadata includes a set of XML bucket elements that describe the search bucket(s) supported by the collection. There is no requirement that collection servers support every bucket, but all collection servers are required (as a matter of ADL policy, not architecture) to support the geographic location bucket.

The bucket element in the collection-level metadata has the following structure:

<!ELEMENT bucket (name, description?, metadata-mapping?, notes?,
domain?)>
    <!ATTLIST bucket
        id ID #REQUIRED
        input-type (date | map | text | tree) #REQUIRED>
    <!ELEMENT name (#PCDATA)>
    <!ELEMENT description (#PCDATA)>
    <!ELEMENT metadata-mapping (#PCDATA)>
    <!ELEMENT notes (#PCDATA)>
    <!ELEMENT domain EMPTY>
        <!ATTLIST domain
            type (hierarchical | other) #REQUIRED
            hierarchy IDREF #IMPLIED>

The bucket element's id attribute identifies the bucket.

The input-type attribute describes the type of query interface required to specify constraint values for the bucket. This attribute is discussed in more detail in the next subsection.

Within the bucket element, the name element is the canonical name of the bucket (e.g., geographic location) and the description element is a brief, abstract description of the bucket's contents (e.g., "any geographic locations or regions associated with collection items"). (Strictly speaking, these elements, and the input-type attribute, describe characteristics of the bucket, not of the collection or of the collection's support for the bucket. This will be corrected by having the collection-level metadata refer to separate, independent bucket metadata.)

The metadata-mapping element describes which of the collection's item-level metadata is mapped to the bucket, and how. For example, a collection that utilizes the MARC metadata content standard might document with this element that MARC field "100a" ("main entry -- personal name") is mapped to the originator bucket.

The notes element gives any additional notes on how the collection populates the bucket and supports its semantics. For example, ADL's Catalog collection server uses this element to document that its implementation of geographic location has certain limitations such as the inability to handle query regions that include a pole.

The domain element describes the semantic domain associated with the bucket. Currently, this element is used only for the type and format buckets, each of which requires that the collection provide a hierarchical thesaurus of terms for use with the bucket's query operators. The thesaurus referenced by the domain element is actually a hierarchically nested set of XML elements elsewhere in the collection-level metadata.

In the current implementation, only the id and input-type attributes and the domain element have any programmatic value; the remaining elements are all unstructured textual descriptions, and hence are useful only for direct inspection by a collection's user. We plan to add programmatically-accessible information about bucket query operators and how the collection supports them.

4.3 Construction of the user interface

JIGI loads collection-level metadata from the middleware server for three purposes:

• presenting the metadata to the user;
• constructing the windows and other user interface elements with which the user assembles queries; and
• constructing properly-formed queries to pass to the middleware server.

For user interface construction, JIGI consults the input-type attributes of the bucket elements. These attributes indicate the types of input interfaces the buckets require:

The use of input-type attributes makes JIGI more modular and independent of specific search buckets, as long as input-type is restricted to the domain of interface types known to JIGI. Eventually we hope to extend this mechanism to support the complete and detailed specification of a user interface from a library of primitive interface elements, as elements that support geospatial information become more widely available.

4.4 Creation of queries

Once the user has constructed a query, JIGI passes it to the middleware server for evaluation. The middleware server accepts queries expressed in KNF ("Kevin's Normal Form"), a simple, collection-neutral query language based on the LISP programming language. KNF clauses are directly derived from the search buckets and their query operators, and the language supports both inter- and intra-bucket boolean constraints. A sample KNF query is shown below:

(and
    (date
        (and
            (on-or-after 1980 01 01)
            (on-or-before 1997 06 25)))
    (geographic-location
        (and
            (contains
                (rectangle
                    (coord -133.1262 31.9119)
                    (coord -110.6262 40.0369)))
            (or
                (overlaps
                    (rectangle
                        (coord -122.7626 38.3006)
                        (coord -121.4461 37.3357)))
                (overlaps
                    (polygon
                        (coord -113.12 31.91)
                        (coord -110.62 31.91)
                        (coord -110.62 40.03)
                        (coord -113.12 40.03)
                        (coord -113.12 31.91)))))))

4.6 Query translation

The middleware server translates queries from KNF to collection server-specific syntaxes, which are typically based on SQL. The translation tends to be quite different for each collection server and for each bucket, even among otherwise similar SQL-based servers, because of differences in collection server schemata, indexing options, and the use of platform- and vendor-specific constructs.

In addition, the translation from KNF can be quite complex. Clauses that are expressed easily and succinctly in KNF can necessitate complex SQL operations such as multi-way joins. And clauses that appear independently in KNF can require globally-coordinated access to database indexes.

4.7 The ADL search bucket database

Figure 1 is an entity-relationship (ER) diagram of a simple relational database schema implementing the search buckets:

Figure 1. Search bucket schema.

In the diagram, oblique type denotes attributes that directly support bucket search; the other attributes are used by other parts of the ADL system, or by the schema itself. The attribute_id attribute identifies the bucket value's source attribute in the object-level metadata (e.g., whether a date range bucket value is a publication date or a measurement date.)

The schema assumes that holdings (objects) and buckets have "one-to-many" relationships; e.g., each holding may have multiple formats, types, originators, etc. We also assume that there are no dependencies between buckets (see section 6.2.), save in the case of the assigned term bucket, which is represented as a qualifier to the topical text bucket (the is_assigned and text attributes, respectively.)

The schema is implemented in Informix Dynamic Server with Universal Data Option (UDO) [7], an object-relational database that can be extended with "datablades" supporting custom data types. We make specific use of the MapInfo Spatial DataBlade [8], to support R-tree indexed searching of the geographic location bucket, and the Excalibur Text Search DataBlade [9], to support fast searching of the assigned term, identifier, originator, and topical text buckets.

As an example of how the schema is accessed, consider a query for any holdings that satisfy all the following constraints:

• format "gif" or "jpeg"
• type "airphoto"
• originator "Tom Smith"
• description includes "digital elevation model"
• location between (130 W, 32 N) and (129.5 W, 34 N)

The SQL implementation of this query would be:

select holding.*
from   holding, holding_types, types, holding_formats, format, originator, text
where  (format.name = "gif" or format.name = "jpeg")
and    types.name = "airphoto"
and    etx_contains(
           originator.name,
           row('Tom & Smith', 'SEARCH_TYPE=BOOLEAN_SEARCH')
       )
and    etx_contains(
           text.text,
           row('digital elevation model', 'SEARCH_TYPE=PHRASE_EXACT')
       )
and    Contain(HG_Box(-130.00,32.00, -129.50,34.00), footprint)
and    holding.holding_id = holding_types.holding_id
and    holding.holding_id = holding_formats.holding_id
and    holding.holding_id = originator.holding_id
and    holding.holding_id = text.holding_id
and    holding.holding_id = text.holding_id
and    holding_types.type_id = types.type_id
and    holding_formats.format_id = format.format_id;

(The functions etx_contains and Contain invoke the Excalibur and MapInfo DataBlades, respectively.)

5.0 COMPARISONS TO OTHER APPROACHES

ADL's search buckets are similar to several other schemes to support information discovery via "core" metadata. In this section we will briefly compare our search bucket approach to library online catalogs and to the Dublin Core.

Library Online Public Access Catalogs (OPACS) generally provide a reduced set of search parameters, which aggregate USMARC fields for searching. Typically, these include author, title, keyword, and subject. Each of these search indexes is built from several USMARC fields. For example, the USMARC format has attributes (fields) for both personal and corporate author fields as either primary or secondary authors, as well as fields for publishers and conference names (which are treated as a type of corporate author). There are at least seven fields available to record the various forms of authorship found in published materials. The author search through an OPAC hides this complexity from the user while still giving access through an "author key" known to the user. The ADL Search Buckets are an extension of this approach to a digital library environment where the diverse collections can be described by a wide variety of metadata formats.

The Dublin Core [10] is a set of fifteen metadata elements designed to enhance the ability of users to find information on the Web. Originally, the Dublin Core was intended for author-generated descriptions of Web resources, and was thus kept simple so that it could be widely used without specialized training in cataloging. Increasingly, though, it is also being adopted by non-Web-based access organizations, such as traditional libraries, professional associations, and data centers. The ongoing development of the Dublin Core aims to produce and support an element set for resource description that is characterized by simplicity, semantic interoperability, international consensus, and extensibility, to support information discovery and use.

The DC elements are designed for description, in contrast to the ADL search buckets that are designed to support searching. The difference this makes can be seen by comparing the DC element set approach to the ADL search buckets:

1. The ADL search bucket set aggregates descriptive elements for searching and includes: (1) a "Topical Text" bucket to which more specific DC elements would be mapped (i.e., "Title," "Subject and Keywords," and "Description"); and (2) an "Originator" bucket to which the DC elements "Author or Creator," "Publisher," and "Other Creator" would be mapped.
2. Search bucket semantics specify more precisely the data type of each bucket because this is needed for search operations. The DC "Coverage" element illustrates this difference. It was designed as an element where both temporal and geographic coverage would be described, in either text or numeric format. The actual application of the element is still under discussion; its use requires agreement on ways to qualify instances of "Coverage" elements to show what type of coverage is being described. In contrast, ADL has a "Geographic Location" bucket specified to contain bounding coordinate values, an "Assigned Term" bucket which can contain place names, and a "Date" bucket with beginning and ending dates specified in a particular format.
3. DC includes elements necessary for description but infrequently searched: "Source" (a string or number used to uniquely identify the work from which the resource was derived), "Relation" (links to related resources), and "Rights Management" (links to copyright notices, for example). The DC element "Language" could be a search parameter but is not currently included in the ADL search buckets.

It is true, however, that the DC effort and the ADL search buckets are similar in that they have both identified a core set of descriptive elements or searchable parameters as generic approaches to information discovery. Some of the DC elements and the ADL search buckets are direct matches ("Type," "Format," and "Identifier") with the difference that for search purposes the bucket semantics are more specific.

6.0 FURTHER WORK

We conclude with some speculation on the possible short- and long-term evolution of the search bucket concept.

6.1 Extending the buckets

In the short run, there are two possible avenues for extending the current set of search buckets:

1. Add new buckets that complement the existing ones.
2. Subdivide existing buckets into more specific components.

Adding a new bucket should be straightforward, as long as it uses an existing operator set (see section 4.3), since the current ADL architecture essentially tailors itself to whatever search buckets are announced by a particular collection. With only eight buckets defined so far, one could even argue that the current scheme is ripe for at least a few additional buckets without incurring undesirable complexity.

An example of an additional bucket that we have considered is a generic "technical details" bucket, that would hold collection-specific quantitative information (e.g., percent cloud cover for remotely sensed images). Implementing such a bucket would require specifying (1) the types of quantitative data available to be searched; (2) the units of measure (e.g., feet or meters); and (3) arithmetic comparison operators (e.g., equals, greater than, less than).

Subdividing buckets is arguably less desirable, since it introduces a fundamental complication into a scheme whose chief attraction is its simplicity. There is also no direct support elsewhere in the ADL architecture for "split" buckets. However, there are some clear current situations where slight additional precision in a bucket query would pay large dividends in usability. The most obvious example is the topical text bucket, into which title and abstract text will be lumped if present. Although less significant for digital than for hardcopy information, a work's title is nonetheless one of the most familiar search criteria, and one that could be readily supported by a subdivision of the topical text bucket.

6.2 Towards a bucket object model

As ADL moves into its next stage of development, where object processing support will be provided, there will be a further fundamental need to associate methods and attributes with classes of objects. At present, ADL simply delivers sets of library items as query results; it provides no tools to display, interpret or process them in any way. In future, our vision is to develop a full computational modeling environment, as a higher operational layer above that of (distributed) digital libraries themselves. In this vision, the library collection items are first-class objects with associated methods which provide processing tools to the users along with (data) query results. The library thus becomes a true object repository, and in order to support this functionality, ADL will need a full object model.

A rigorous object model would recognize dependencies between the characteristics of the search buckets. There is clearly a dependency between an object's type and format (the representation in which the object exists and can be delivered); yet, for example, it is currently possible to formulate a legal ADL query asking for only those aerial photographs which are available in ASCII text form. The null result -- absence of information -- is in fact misinformation, since the user is not made aware that the query implies a non-existent dependency between type and format. Clearly it would be much better if the system made it impossible to specify such non-existent dependencies. The problem is caused at present because type and format are defined independently, as part of the metadata associated with each individual collection. Apart from the weakness illustrated above, this means that there is also no common definition of types between collections, which is a serious barrier to semantic interoperability.

What is needed is the addition of dependency relationships at two levels:

1. Common to a set of collections:
   1. An authority list of all known types;
   2. An authority list of all known formats;
   3. A dependency relationship determining all the possible formats of each type in the authority list.

   (There might be several such sets of collections, each with its own authorized common types and formats.)

2. Within each collection:
   1. A list of all types in the collection, as a subset of the authority type list;
   2. A dependency relationship associating each existing type in the collection with its existing format, as a subset of those allowed by the authority dependency relationship.

This schema would inform both description (ingest) and searching. A cataloger would be guided in the assignment of type and format terms; and queries would be restricted to allowed and existing formats of allowed and existing types.

7.0 REFERENCES

[1] Alexandria Project, URL http://www.alexandria.ucsb.edu

[2] Smith, T., Andresen, D., Carver, L., Dolin, R., Fischer, C., Frew, J., Goodchild, M., Ibarra, O., Kemp, R., Kothuri, R., Larsgaard, M., Manjunath, B., Nebert, D., Simpson, J., Wells, A., Yang, T., and Zheng, Q. A digital library for geographically referenced materials. IEEE Computer, vol. 29, no. 5, pp. 54-60 (1996)

[3] UCSB Davidson Library Map and Imagery Laboratory, URL http://www.sdc.ucsb.edu

[4] Networked Knowledge Organization Systems/Services (NKOS), URL http://nkos.slis.kent.edu/

[5] Melton, J. and Simon, A.R. Understanding the New SQL: A Complete Guide. Morgan Kaufmann Publishers, Inc. San Mateo, CA. (1993)

[6] Frew, J., Freeston, M., Freitas, N., Hill, L.L., Janee, G., Lovette, K., Nideffer, R., Smith, T.R., and Zheng, Q. The Alexandria Digital Library architecture. In Research and Advanced Technology for Digital Libraries: Second European Conference (ECDL'98), Heraklion, Crete, Greece. Springer-Verlag Lecture Notes in Computer Science, vol. 1513, pp. 19-23. (1998)

[7] Informix Dynamic Server Universal Data Option overview, URL http://www.informix.com/informix/products/options/udo/

[8] MapInfo SpatialWare, URL http://www.mapinfo.com/spatialware

[9] Excalibur Text DataBlade Module, URL http://www.informix.com/informix/products/options/udo/datablade/dbmodule/excalibur1.htm

[10] Dublin Core Metadata Initiative, URL http://www.purl.org/dc/

ACKNOWLEDGEMENTS

The work described herein was supported by the NSF-DARPA-NASA Digital Libraries Initiative, under cooperative agreement NSF IR94-11330. We thank the staff of UCSB's Davidson Library Map and Imagery Laboratory for their support of the ADL testbed system.