Alexandria will contain both textual and spatial information, which users will need to access selectively. The most common way of accessing information from a spatial database is through a spatial query language. Spatial query languages extend textual query languages with operations pertaining to particular properties of spatial data. While spatial query languages are useful if users have already identified some properties of the data they require, browsing is needed if they want to locate spatial data sets and explore them for interesting features. The two access methods, querying and browsing, are complementary; browsing is inductive, whereas querying supports more deductive analysis and scientific research. Alexandria's users will need both methods.
Textual-based interfacing schemes by themselves are not suitable for collections of images and maps, where data sets possess multi-dimensional characteristics and graphical contents. For example, map data typically contains information about a certain geographic location and can be indexed using coordinates such as latitude and longitude in some master map [22]. Hence browsing geographically-indexed items simulates a guided tour through the master map. This mode of operation suggests that textural indices should be augmented with a graphic context for efficient browsing of map data. Image data and video clips present a more serious challenge. It is unnatural to assume that the vast amount of information embedded in an image can be summarized in a few words to enable adequate indexing. A picture is indeed worth more than a thousand words, and it clear that browsing based on the ``graphic contents'' plays as essential a role in managing pictorial data as browsing based on textual indices. For example, a content-based retrieval scheme can have immediate applications in criminology where face images and finger prints are routinely matched and searched.
Hence a user interface to a library of spatially-indexed data must involve at least two query languages: a text-based language and a visual language. The text-based language must be capable of representing a wide range of queries that describe the nature of the required item, its spatial attributes and certain aspects of its ``content''. We have been developing extensions of SQL as well as other languages, such as MDBL [62][63], for similar applications, and would propose that such languages provide the basis for the textual query language in the testbed. The semantics of both the textual and visual query languages will be formally defined in terms of a uniform computational model and the expressiveness of the languages will be determined. Different syntactic versions of the languages permit different styles of user interaction and accomodate varying levels of expertise. For example, the naive user might create simple temporal queries by filling in textual templates; more complex temporal queries can be expressed graphically, using a timing diagram-like notation, such as the Graphical Interval Logic [19], or, in the case of a more sophisticated user, using textual temporal logics [21]. Both the visual and textual languages will provide ``browsing'' instructions.
In the case of a traditional library, one browses books by quickly scanning them while standing in the stacks, or perhaps carrying them to a table. Volumes that appear to be suitable are ``retrieved'' by formally checking them out and carrying them away from the library. We may extend this analogy to digital data, even though on first consideration it might appear that in order to browse it we must first retrieve it, and in so doing have not saved any time or effort. The key lies in the ability to substitute a reduced-resolution representation of the data. If the system knows that a retrieval is for browse purposes, then instead of retrieving the full-resolution version of the data, a more economical (in size, time to transfer, or complexity of retrieval) representation can be substituted, as long as it preserves sufficient resolution to resolve the attributes being browsed.
There are three key points to emphasize here. First, a given data object may have multiple browse representations, depending on the feature being searched for or the application for which it is being evaluated. Second, these browse representations are heterogeneous: they may include degradation, selection, summarization, or other forms of abstraction. Third, all possible browse representations cannot be specified a priori, nor should they be. Some browse representations may be both sufficiently common and compute-intensive (e.g., JPEG image compression) to merit precomputation, becoming, in effect, metadata. Other representations will likely be sufficiently idiosyncratic that they must be evaluated ``on-the-fly'', in which case the level of abstraction they supply must be great enough to warrant such complexity. The system must support both extremes.