|
The ADL middleware server mediates between digital library clients
and digital library collections. This document describes the
middleware's three client interfaces; a companion document describes
the middleware's collection
interface.
Contents
Here's an architecture diagram
that shows the client interfaces in context. Don't get boggled;
concentrate on the upper half of the diagram.
The middleware's client interfaces are partitioned into eleven
independent, stateless services. The services are:
- properties
<-
configuration()
Returns middleware configuration properties. The property of
most interest to clients is the list of available
collections. - metadata
<-
collection(collection-name)
Returns collection-level metadata for a collection; see Metadata
below. - query-id
<-
query(query)
Asynchronously queries one or more collections. query
is a query expressed in the middleware's query language; see Query language
below. Results are stored in a "result set" on the server.
query-id identifies both the running query and the result
set. cancel(query-id)Cancels a running query. - result-set-reference
<-
results(query-id)
Returns a reference to a result set. A result set is a
server-side object that holds the results of a query in the form of a
single merged, ranked list of collection items, where each collection
item is represented by a triplet of the item's three standard ADL
metadata views; see Metadata below. Result
sets carry sundry other properties such as elapsed time, total number
of results processed, etc. - item-identifiers
<-
identifiers(collection-name)
Returns the identifiers of all items in a collection. - metadata
<-
metadata(view,
collection-name,
item-identifier)
Returns a view of the metadata for an item within a collection;
see Metadata
below. - document
<-
status()
Returns the middleware's status as an HTML document. reference(base-url,
remote-collection-name [,
local-name])References a remote collection so that the collection appears
and functions as a local collection. base-url is the remote
middleware server's HTTP or RMI base URL. The collection is known
locally as local-name, if specified, and otherwise by its
name on the remote server, remote-collection-name. unreference(collection-name)Removes the reference to a remote collection. unload(collection-name)Unloads the driver for a collection. (Drivers are
automatically loaded on demand.)
There are three client interfaces to the middleware: fundamental,
HTTP, and RMI.
The ADL middleware server is implemented in Java, and the
fundamental client interface consists of Java objects and object
methods. For example, the metadata service is implemented by class MetadataService
and is invoked by calling that class's performMetadataService
method. The exact semantics of the services are ultimately defined by
the fundamental interface.
The HTTP interface is layered on top of the fundamental interface.
It accepts HTTP GET and POST requests, converting URL-encoded
parameters into service method arguments and returning service results
as MIME-typed content. Service exceptions are returned as HTTP
failure codes.
The RMI interface is... just that.
The table below correlates the classes implementing the three
interfaces.
The middleware's query language is a generic, XML-encoded language
that supports boolean combinations of typed constraints against
abstract metadata fields, or "search buckets." Its syntax and
semantics are defined by the DTD ADL-query.dtd.
ADL has defined a set of nine standard search buckets. These
buckets are defined conventionally, not architecturally.
Nevertheless, clients can assume that all collections support all of
the following buckets:
- Geographic locations
-
| Internal name |
|
adl:geographic-locations |
| Type |
|
spatial |
| Operators |
|
contains, is-contained-in,
overlaps |
| Content |
|
The item's spatial footprint, i.e., an approximation of the subset
of the Earth's surface to which the item is relevant, expressed as any
of several types of geometric regions defined in WGS84
latitude/longitude coordinates. |
- Dates
-
| Internal name |
|
adl:dates |
| Type |
|
temporal |
| Operators |
|
contains, is-contained-in,
overlaps |
| Content |
|
The item's temporal footprint, i.e., the range of calendar dates
to which the item is relevant. |
- Types
-
| Internal name |
|
adl:types |
| Type |
|
hierarchical |
| Operators |
|
is-a |
| Content |
|
Terms drawn from the ADL Object Type Thesaurus identifying the
meaning or content of the item. |
- Formats
-
| Internal name |
|
adl:formats |
| Type |
|
hierarchical |
| Operators |
|
is-a |
| Content |
|
Terms drawn from the ADL Object Format Thesaurus identifying the
form or representation of the item. |
- Titles
-
| Internal name |
|
adl:titles |
| Type |
|
textual |
| Operators |
|
contains-all-words, contains-any-words,
contains-phrase |
| Content |
|
The item's title. This bucket is a subset of the "Subject-related
text" bucket. |
- Originators
-
| Internal name |
|
adl:originators |
| Type |
|
textual |
| Operators |
|
contains-all-words, contains-any-words,
contains-phrase |
| Content |
|
Names of entities related to the origination of the item (authors,
publishers, distributors, etc.). |
- Assigned terms
-
| Internal name |
|
adl:assigned-terms |
| Type |
|
textual |
| Operators |
|
contains-all-words, contains-any-words,
contains-phrase |
| Content |
|
Subject-related terms from controlled vocabularies. This bucket
is a subset of the "Subject-related text" bucket. |
- Subject-related text
-
| Internal name |
|
adl:subject-related-text |
| Type |
|
textual |
| Operators |
|
contains-all-words, contains-any-words,
contains-phrase |
| Content |
|
Text indicative of the subject of the item, not necessarily from
controlled vocabularies. This bucket is a superset of the "Titles"
and "Assigned terms" buckets. |
- Identifiers
-
| Internal name |
|
adl:identifiers |
| Type |
|
identification |
| Operators |
|
matches |
| Content |
|
Item names and codes that serve as unique identifiers. |
All metadata returned by the middleware is encoded in XML and
adheres to publicly-defined, external DTDs. The DTDs listed below
contain human-readable documentation, and define both syntactic form
and semantic content.
For collection-level metadata see ADL-collection-metadata.dtd.
The collection-level metadata for a collection contains a number of
items of interest to clients: the buckets supported by the collection;
the thesauri used to categorize the collection; the number of items in
the collection both overall and broken down by type and format; the
spatiotemporal distribution of the items; and so on. Examples of
collection-level metadata in XML and rendered as HTML can be found here.
Item-level metadata is packaged into "views," with the views
differing in size, content, encoding style, and intended usage.
Collections and even individual items within collections may define
and return arbitrary views. ADL defines three standard views which
all collections and items must support:
- bucket
-
| DTD |
|
ADL-bucket-report.dtd |
| Content |
|
Describes mappings from the item's native metadata to
high-level, searchable buckets. |
- browse
-
| DTD |
|
ADL-browse-report.dtd |
| Content |
|
Describes the browse-size representations of the item that are
available. |
- access
-
| DTD |
|
ADL-access-report.dtd |
| Content |
|
Provides the information necessary to download or otherwise access
the item's content. |
Perhaps the easiest way to understand what the middleware does is
to try it out. Here are some interactive test forms. Or, consult the servlet-URL mapping to see how
to point your HTTP client at a running ADL middleware server. RMI
clients should consult the corresponding RMI registry names and download
the RMI client package,
which contains the necessary interface classes and some sample source
code.
|
