An Extensible Feature Management Engine for

An Extensible Feature Management Engine for Image Retrieval Simone Santini and Amarnath Gupta University of California, San Diego ABSTRACT In this paper we describe the general architecture and specific topics of a database system for multimedia (specifically, images) data. We analyze the conditions that must be met in order to achieve goals such as efficient schema design, query optimization, and extensibility. We assume that the engine uses the services of a traditional database (in the specific instance, a relational database), with the addition of user-defined indexing schemes. The paper presents general architectural issue and focuses on two problems: schema normalization using computational properties of the features, and the definition of feature algebras, in particular, the definition of a wavelets algebra for query expression.

1. INTRODUCTION In this paper we describe the data model and the functional design of a feature management subsystem that is meant to serve as a “backend engine” for an image database management system. The design goals of the engine are as follows. • The data model of the engine should be flexible enough to enable feature designers define their own features to the system • Once a schema of features has been defined for an image database application the engine would use its own algorithms to organize the features. However, system designers would have the ability to override the system’s algorithms and plug their own feature organization methods. • The system would use a library of well-known index structures during query processing, and for a specific query, choose appropriate access methods using a mixture of cost and rule-based optimization methods. The system designer would have the ability to define additional semantic hints to influence how the query is evaluated. • The system will implement a number of search strategies for similarity-based, pattern-based, attribute-based and traversal-based queries. However, if the designer wishes to implement her own search strategy for a specific class of search, she should be able to deselect the system’s strategy and replace it with the new scheme. • While result ranking based on relative feature weights is outside the scope of the feature management engine, the query evaluation strategy used by the system will be influenced by user-defined feature weights. The data model used for the engine is built upon an extension of our earlier work on feature algebras,1 and an algebraic-functional formalism established in the software-specification literature. Our data model is algebraic functional because a function is treated as a first-class object, and can be searched by its signature. Once a feature schema is designed, the engine would invoke a set of algorithms to organize the features. One aspect of the organization process is the ability to partition a feature into subfeatures that are stored separately to achieve an equivalent of the “normalization” effect in relational systems. It can be shown that in the presence of certain intra-feature dependencies and properties of the distance function, similarity queries perform more efficiently when the “feature normalization” is performed. We will describe how to use the algebraic functional description of a feature to determine some parameters of the normalization process. There are at least three different aspects that need to be combined for image retrieval: making the retrieval “semantic”, possibly by using additional annotations or image classifications2 ; making the feature-based search Simone Santini, Department of Electrical and Computer Engineering; University of California, San Diego; 9500 Gilman Drive; La Jolla, CA 92093-0407; USA; email: [email protected]; Amarnath Gupta, San Diego Supercomputer Center University of California, San Diego; 9500 Gilman Drive; La Jolla, CA 92093; USA; email: [email protected];

process efficient, by using database techniques; and, making a suitable user interaction environment where the user may navigate, change feature preferences, and use relevance feedback or perform other control functions to guide the retrieval process.3 The goal of our feature management system is mostly to achieve the second goal, while the environment that embeds the engine is responsible for the others. However, it is imperative that the execution plan of a query is deeply influenced by any pre-processing (such as query classification) and control process (such as relevance feedback and feature weigh adjustment). The query evaluation mechanism of our engine combines the algebraic and rule and cost based query optimization strategies for feature-based search, but can be made to execute in an incremental mode, where it maintains more states from prior queries so that queries generated from control mechanisms such as relevance feedback can be evaluated more efficiently. A significant feature of the engine design is that a system designer can configure and extend it for specific applications. As an example of configuration, the system processes a histogram query by first using a coarser number of bins and then refining the result set with finer set of bins. The system designer may configure the number of stages and the number of coarsening bins to be used at each stage, such that query performance is optimized based on the expected data distribution for a specific application. We have adapted techniques from object-relational systems and query optimizer generators to allow several “plug-in points” in the engine. Feature designers may not only program in new features and index structures, they can replace the cost function of an existing feature, and create new search strategies. In an advanced example the designer would specify how distance and range queries can be rewritten, and how additional temporary indexes can be maintained such that the engine produces a larger variety of candidate results for an initial query to reduce the search effort for the next iterative query.

2. A MULTIMEDIA DATABASE ENGINE ARCHITECTURE Our database engine is designed to use the services of some existing database. In particular, in the following, we will assume that the engine uses the services provided by a modern relational database, such as: • A complete query algebra for the specification of queries. • The possibility to extend the data types of the database using suitable programming modules. • The possibility to define special indexing methods and incorporate them into the database. • A query optimizer rewasonably robust to the definition of such database and indexing methods. On this database foundation, the image database engine superimposes services specifically designed for handling multimedia data. In this section, we will first consider the abstract model of a multimedia database, and then the architecture of a typical implementation.

2.1. Multimedia Database Model An image database is formed by one or more relations, or tables, of the form T (h : N, x1 : X1 , . . . , xn : Xn ), where h is a unique image handle, X1 , . . . , Xn are feature data types, and xi is the name of the ith field or column of the table. For the sake of simplicity, we will assume that every table contains only features. The signature of the table is the sequence of data types (N, X1 , . . . , Xn ), and its schema is the sequence of names (h, x1 , . . . , xn ) with their associated data types. The elements of a schema are called the explicit fields, or simply the fields, of the table. The k th row of the table is indicated as T [k] and contains the handle and all the features relative to one of the images stored in the database. T [k].h is the handle of the image, and T [k].x is the value of its ith feature descriptor. i

In addition to the explicit fields, each row of the table has a score field ς (of type R) such that T [k].ς is the distance between the image in the k th row and the current query. The value of the field ς is assigned by the scoring operator Σ introduced later on. If h0 is a handle, the notation T [h0 ] will be used to indicate the row k for which T [k].h = h0 . Many image queries are based on distance measures in feature spaces. Given a feature type X, let D(X) be the set of distance functions defined on X. All distance functions considered in this paper take values in the interval [0, 1] and are curried, that is, they are of type d : X → X → [0, 1].4 Given an element x : X, and d ∈ D(X), the function d(x) : X → [0, 1] assigns to every element of X its distance from x. Such a function is called a scoring function, and the set of all scoring functions for a feature type X is indicated as S(X). Each table T has associated

a distance, indicated as T.d, such that, if the signature of T is (N, X1 , . . . , Xn ), then T.d ∈ D(X1 × · · · × Xn ). Each row of the table has associated a scoring function T [k].d = T.d(T [k].x1 , . . . , T [k].xn ) ∈ S(X1 × · · · × Xn )

(1)

that measures scores with respect to the image described by the row. Moreover, a library of distance combination operators is defined. These are based on scoring combination operators 3 : [0, 1] × [0, 1] → [0, 1].5,6 Each one of these operators induces a distance combination as follows. Let d1 ∈ D(X) and d2 ∈ D(Y ), then the distance operator 3 : D(X) × D(Y ) → D(X × Y ) is the operator that makes the following diagram commute: 3 D(X) × D(Y ) −−−−→ D(X, Y )     (2) eval×evaly yeval 3

[0, 1] × [0, 1] −−−−→

[0, 1]

That is, for x : X and y : Y , it is (d1 3d2 )(x, y) = d1 (x)3d2 (y)

(3)

The combination operators will be assumed to be symmetric and Lipschitz, that is x3y = y3x |x3y − x3z| ≤ L|y − z|

(4)

for some constant L > 0.

Operators. Given a scoring function s, and a table T (N, X1 , X2 , . . . , Xn ) the scoring operator ΣT (s) assigns a score to all the rows of T using the scoring function s. That is, ΣT (s) is a table with the same signature as T and (ΣT (s))[k].ς = s(T [k].x1 , . . . , T [k].xn )

(5)

Given a table T (N, X1 , X2 , . . . , Xn ), the k lowest distances operator σk# returns a table with the k rows of T with the lowest scores. The operators σk# and ΣT are generally used together: the operator σk# (ΣT (s)) is called the k-nearest neighbors operator for the scoring function s. The operator σρ< returns all the rows of a table T with a score less than ρ. The operator σρ< (ΣT (s)) is called the range query operator for the scoring function s. The operator σP is the usual predicate selection operator on a table T . In the databases that we consider here, P has either the form h = h0 , where h0 ∈ N is a handle, or h ∈ H, where H is a set of handles. Note that the notation T [h0 ] introduced above is a shorthand for σh=h0 (T ) which, because of the unicity of the handles, always returns a single row. Finally, the 3-join operator

1 joins two tables T and Q on their handle field to form a new table W = T 1Q. 3 3

If T = T (h : N, x1 : X1 , . . . , xn : Xn ) and Q = Q(h : N, y1 : Y1 , . . . , yn : Yn ), then W = W (h : N, x1 : X1 , . . . , xn : Xn , y1 : Y1 , . . . , yn : Yn )

(6)

The row q such that W [q].h = h0 is obtained by collecting the features of the rows T [i] and Q[j] such that T [i].h = Q[j].h = h0 . The table W has a distance function W.d = T.d3Q.d

(7)

and, if the q th row of W was obtained by joining the ith row of T with the j th row of Q, it has score W [q].ς = T [i].ς3Q[j].ς

(8)

W [q].d = T [i].d3Q[j].d

(9)

and scoring function Note that the operators 3 used in the two previous equations have different dignatures: The operator in (8) is a score combination operator, while the operator in (9) is the corresponding scoring functions combination operator.


 

   

,'-.,/021435 -.6 7839135 7835 :87

x4y{z|~} €‚ ƒ„

‹ŒŽ Ž ‘’

 €‚|~y†…4Rz

“ Œ ”8•9 –4—‚˜

x4z€ˆ‡)y ‰Š|~y†…4Rz

’™–4—•Œ ‘ –

­®B¯°R±²

!" £¤'¥&¦ §¨£ ©.¤ ª

#

$&%'")(*&+ "$

;& 1 ⇒6 ∃q > 1 : y [|r ix ∀x, y, z x [|r iy ∧ y [|q iz ⇒ x [|rq iz ∀x xh0ix ∀x, y xh∆iy ⇒ yh∆ix xh∆iy ⇒ ∀Γ > ∆ xhΓiy ∀x, y, z xh∆iy ∧ yhΓiz ⇒ xh∆ + Γiz ∀x x [0|1 ix ∀x, y, z x [∆|r iy ∧ yhΓiqz ⇒ x [Ψ|s iz

Table 1.

3.2. Transitive Closure The three relations introduced in the previous section satisfy a form of transitive property, as well as certain symmetry properties, summatized in Table 1. These properties are used to derive transitive closures relative to a subset of the features that satisfy certain cost constraints. In particular, the transitive closures for the three relations are defined as follows. Definition 3.7. Let X = {x1 , x2 , . . . , xn } be a set of features computed on the same database (or a decomposition of a single feature computed on the database). Given a feature xi ∈ X, the r-transitive closure of xi is the set: st[xi ]r = {xk ∈ X : xi [|q ixk , q ≥ r}

(13)

Definition 3.8. Let X = {x1 , x2 , . . . , xn } be a set of features computed on the same database (or a decomposition of a single feature computed on the database). Given a feature xi ∈ X, the ∆-transitive closure of xi is the set: qf[xi ]∆ = {xk ∈ X : xi h∆ixk }

(14)

Definition 3.9. Let X = {x1 , x2 , . . . , xn } be a set of features computed on the same database (or a decomposition of a single feature computed on the database). Given a feature xi ∈ X, the (∆, r)-transitive closure of xi is the set: qs[xi ]∆,r = {xk ∈ X : xi [Γ|q ixk , Γ ≤ ∆, q ≥ r}

(15)

The values r and ∆ in the definitions of the transitive closures have a direct relation with the cost of the indexing algorithm.8 Therefore, given a cost objective, an acceptable value of r and ∆ can be derived. The goal of the designer is then to find the smallest feature x such that its transitive closure with the appropriate r, and ∆ equals the whole set of features, that is, such that qs[x]∆,r = X.

3.3. Cost-Based Schema Design The indexing algorithms for schema designed based on these relations work according to a similar scheme. Assume that the feature space X, of dimensionality d, is divided into two spaces X1 and X2 , of dimension d1 and d2 = d − d1 . The general scheme of the k-nearest neighbors algorithm is the following: 1. perform a k-nearest neighbor search in the feature space X1 , with dimensonality d1 ; 2. take the distance between the query nad the kth image, ρ; 3. increase the radius ρ applying to it a function that depends on the functional dependency between X1 and X2 : r = f (ρ), with f (x) > x for all x > 0;

Dependency x [|r iy xh∆iy x [∆|r iy σ1 x 99K y σ2

Function f (ρ) = ρ3Lρr f (ρ) = ρ + ∆ f (ρ) = (ρ + ∆)r f (ρ) = ρh , h = minarg psk,h (σ1 , σ2 ) < p0

Table 2. 4. do a range query in X1 with radius r, obtaining as a result a set of k 0 > k images; 5. compute the distance between the query and all these k 0 images using the full feature space X, and take the k images closest to the query. In order to determine the cost of this algorithm, let K(N, k, d) be the cost of a k-nearest neighbors and R(N, r, d) be the cost of a range search of radius r in a space of dimensionality d for a database of N images. Assuming that the last step of the algorithm requires a time linear in the number of images searched, the cost of the whole algorithm is C(N, k, d1 ) + R(N, f (rk ), d1 ) + k 0 (f (rk ), N, d1 )

(16)

where the notation k 0 (f (rk ), N, d1 ) serves to remind that the number of images returned by the range query is a function of the search radius. For a given database size and freature space dimension, this cost depends on two variables: the dimension d1 of the reduced feature space, and the radius-increasing function f . Consequently, we define the normalized cost of a database search as N (N, f, d) = C(N, k, d) + R(N, f (rk ), d) + k 0 (f (rk ), N, d)

(17)

If the original feature space has such high dimensionality that no indexing scheme works satisfactorily on it, no search is faster than a linear scan, which has a cost CN . In this case, normalizing the database leads to a gain N − N (f, m, d1 ). The function f depends on the dependency between the features that are being split and is given, for the four dependencies introduced previously, in Table 2. The cost of a search in a normalized database, N (f, m) decreases when m increases, and increases when f increases. The objective of cost-based reduction to normal form is to find a decomposition of the database tables such that N (f, m) is as small as possible. In order to formalize this problem we need a few more definitions. Let r be any of the previous four dependency r relations, and indicate with x −→ y a generic relation between x and y. Also, given a relation r, fr is the radius increasing function deriving from the relation, as in Table 2. Definition 3.10. Let x a feature from a database. The φ transitive closure of x is the set n o r [x]φ = y : ∃r x −→ y ∧ fr (ρ) ≤ φ(ρ)

(18)

The definition is extended immediately to sets of features Y = {x1 , . . . , xl } as [ [Y ]α = [x]α

(19)

x∈Y

In other words, the set [x]α is the set of all the features that depend on x through a relation whose cost-increasing function is bounded by a given function φ. Definition 3.11. Given a set of feature types X = {X1 , . . . , Xn } on a database, an α-key of the set X is a set Y ⊆ X such that [Y ]α = X

A key Y for a database of features X can be used to index the images in the database with a guaranteed bound on the cost of the algorithm using the methods illustrated in the previous sections. The general table decomposition problem can then be formulated in the following way: Given a database composed of a table T (N, X1 , . . . , Xm ), find a set of tables K(N, Y1 , . . . , Yp ), Ti (N, Wi,1 , . . . , Wi,pi ) such that S S 1. X = i Yi ∪ i,j Wi,j 2. Every Xi belongs either to K or to exactly one of the Ti ’s 3. K is an α-key for T 4. The cost N (f, d), where f is the function induced by the dependency of the Ti ’s on K, and d is the dimension of the feature space of K, is minimized.

4. FEATURE ALGEBRAS The second important component of the architecture of Figure 1 is the feature algebra. A feature algebra defines the operations that are possible on a features, their semantics, and their interactions. In order to be implemented efficiently, the operations of a query algebra must be cognizant of teh structure of a particular feature. For this reason, the definition of a feature algebra depends on the structural characteristics of a specific features. Feature algebras were considered in the literature for certain classes of features.1,9,10 Here, we will consider briefly the definition of an algebra of wavelet features.9

4.1. A Wavelet Algebra Our wavelet data model is based upon the concept of complex object, extensively studied in the database literature.11 If T is an uninterpreted data type (which can be either a basic type like integer or boolean, or an abstract data type created by a type constructor function), the common complex data types built on T are sets {T }, lists, [T ] and tuples ×ti where ti is of some type Ti . Arrays are usually considered as a special case of lists. As Libkin and Wong12 observed, though, in applications that make heavy use of arrays, it is convenient to define them as an independent complex data type. In their definition, a k-dimensional array is a function from a rectangular subset of Nk (the index set) to a data type T . Such an array is indicated as |[ T ]|k . If U k ⊂ Nk is the data type of all k dimensional index rectangles aligned with the origin of Nk , then |[ T ]|k is equivalent to the function type U k → T . In addition to the elementwise application of all the operations defined for the data type T , Libkin and Wong define four functions in their array algebra: 1. |[ e|i1 < e1 , . . . , in < en ]| builds a k dimensional array with index limits e1 , . . . , ek such that the element of indices i1 , . . . , ik has the value λe.i1 . . . ik ; 2. the indexing function e[i], with i ∈ Nk , which evaluates the array for a particular value of the subscript; 3. the function dim(e) ∈ Nk , which returns the dimension of an array; and 4. the function indexk (e) : {Nk × T } → |[ T ]|k , which converts an indexed set into an array. A Wavelet transform can be seen as a list of two-dimensional arrays of varying dimensions, with the following additional structural constraints: 1. All the arrays in the transform have dimension 2k for some k and, for all k < k0 , there is at least one array with dimension 2k ; 2. the arrays are index-constrained.

Two arrays A and B are index constrained if there is a function f that maps subsets of indices of B to indices of A. In other words, let IA ⊆ N2 be the set of indices of A, and IB ⊆ N2 the set of indices of B, then the function f is defined as f : 2IB → IA . The idea of this function is that it encodes the structural relationship whereby a pixel in a coarser scale of a wavelet transform represents the same spatial location as a set of pixels at a finer scale. The function map(R, Ai , Aj ), given a sub-array of Ai returns the corresponding sub-array of Aj . Note that the index-constraint relation is transitive and (trivially) reflexive. If P is a set of arrays such that any pair of members is index-constrained by some index mapping function, then P is an index-constrained set. A wavelet transform is an index-constrained set W of arrays such that: 1. There is a single array A such that every array in W index-constrains A, and 2. there are no loops in the index-constraint relation (that is, it is never the case that A constrains B, B constrains C, and C constrains A). The operations defined on the wavelet data type are the same defined on its constituent arrays, the function map, and its inverse imap. All the operations introduced in the following for the wavelet data type can be defined in terms of these basic operations. In the following, the wavelet data type will be indicated as W, regions (whose definition is standard) as (R), and shapes as (S). The multi-band operator M() is defined as follows: given a region r and a wavelet w, the operator m : Rm = M(w, r)

(20)

creates a multi-band region with the same structure as the wavelet w. The multi-band region thus created has components in all the bands of the wavelet transform. It is sometimes necessary to restrict a region to only certain bands of the wavelets. This can be done using the slice operator S, which extracts the region component on a single band of the transform (regions composed of multiple bands can be defined as a partially ordered composition of single-band regions). The form of the operator is r1 : Rm = S(r : Rm , i1 , i2 )

(21)

where i1 and i2 are the indices of the band that will be extracted from the region. 4.1.1. Operations on wavelets As mentioned above, a wavelet transform is created from an image using a constructor W(). The arguments of the constructor specify the image to be transformed, the type of the transform, the number of resolution levels of the transform, and any other necessary parameter depending on the particular transform. For example, the constructor w = W(img, GABOR, 8, 16) creates a gabor transform with 8 resolution levels and 16 direction at every level. A special form of the constructor is used in order to create an empty wavelet, in which every coefficient is the null value of the type µ: w = W(µ, p, GABOR, 8, 16), where the null image from which the transform is derived has size 2p × 2p . Two wavelets w1 and w2 are said isomorphic if they have the same dimension, number of bands and coefficients data type. The slicing operator extract a band from the wavelet transform given its band indices. The result is a matrix of suitable size with elements of type µ: m : [µ] = S(w : W, i1 , i2 ). (22) Note that this operator is identified by the same symbol as the similar operator defined for regions. There is however no ambiguity, since the signature of the operator is different in the two cases. The inverse of the slicing operator replaces a band in a given wavelet transform with the data of a matrix of suitable size: w = S −1 (w : W, m : µ, i1 , i2 )

(23)

Given a function f : µ → λ and a wavelet w, the apply operator [] returns a wavelet isomorphic to w, with elements of type λ obtained applying the function f to all its coefficients. The operation is written [f ]w. Given a function f : µ × µ → λ and two isomorphic wavelets w1 , w2 , the apply operator will return a wavelet isomorphic to w1

and w2 but with elements of type λ in which coefficients are obtained by applying the function f to the corresponding coefficients of w1 and w2 ; the operation is written w1 [f ]w2 . The map operator takes an associative and commutative function f : µ×µ → µ and makes a “running application” of the function between all coefficients of the wavelet. The operator is written f \w The mask operator takes a multi-band region and a wavelet and restricts all operations on the wavelet to the portion included in the region. Masking the wavelet w with the region q is indicated as q w. 4.1.2. Comparison Operators One of the most important operations in a database is to compare two features to determine the degree to which they match. The comparison operator “=” determines the degree by which two wavelet transforms match. The syntax of the operator is w1 = w2 , which returns the similarity between the two wavelets in the interval [0, 1]. This general operator does, in practice, take three different form depending whether a mask is applied to one of the two wavelets. Let r : Rm be a region and s : Sm be a shape. Then the semantics of the comparison operator is the following: w1 = w2 returns the similarity between the wavelet transforms w1 and w2 . r

w1 = w2 returns the similarity between the region r of w1 and the same region of w2 .

r

w1 = s w2 returns the similarity between the region s of w1 and the corresponding region of w2 that better matches it, independently of its location.

4.1.3. Examples The following simple examples should give a general idea of the behavior of the operations introduced so far. • w = w1 [+]w2 : The wavelet w is the sum of the wavelets w1 and w2 . • v = +\w: Computes the sum of all coefficients of a wavelet. • v = +\[norm](w1 [−]w2 ): Computes the Euclidean distance between two wavelets (norm is the function that computes the norm of a coefficient of type µ). • v = +\[norm]q (w1 [−]w2 ): Computes the Euclidean distance between the portion of the wavlets w1 and w2 included into the region q. • w = w1 [+]q w2 : w is equal to w1 outside of the region q, and equal to w1 [+]w2 inside the region q. For examples of queries, assume that the database is composed of a single table T (id : int, w : W). The simplest query possible in this database involving image contents is query by example: given a wavelet transform w, find the k images closest to w. This is written as σk# (ΣT (w = T.w)) (24) The following query finds the images that are similar to a given image in the region r: σk# (ΣT (r w = T.w)).

(25)

Some queries require, in order to be executed, the definition of logic operator on scores. We will not consider such operators here: we will just assume that they are defined as in Fagin’s paper5 or as in.10 Some of the following queries will also require the definition of auxiliary functions, which are included into the query language using a syntax derived from that of the ML programming language.4 The query itself is created as the body of an implicit function query which returns an ordered table. For example, the query (25) is translated into the function fun query (w, r) = σk# (ΣT (r w = T.w))

Note that all the free variables in the query will be mae into arguments of the query function. It is possible to use variables in a query by inserting them in the body of a function with a let statement. The following query retrieves the images similar to a given image in general shape (that is, in the content of the lowest resolution bands) and in the high frequency component taken in a given fixed rectangle: let r1 : R; w : W; m1 , m2 , m, mt : Rm r1 = rectangle(100, 100, 50, 20) w1 = W(int, 8, GABOR, 8, 16) mt = M(w1 , r1 ) m1 = S(mt , 8, ∗) ∪ S(mt , 7, ∗) m2 = S(M(w1 , all), 0) in σk# (ΣT (m1 w = T.w ∧m2 w = T.w)) end The definition of the region is the most cumbersome part of this function definition but, in practice, libraries of macros are available to make such definition easier.

5. CONCLUSION The transformation of content based multimedia retrieval in a database discipline requires the solution of typical database problems such as data description, query rewriting and optimization, and indexing. The challenge posed by multimedia data is that some of the properties of the data are, in a very general sense, semantic, that is, they describe the behavior of features or other functions when applied to the data. Activities like schema normalization or query optimization must work on a suitable description of the semantic behavior of features and distance functions. We have proposed a general architecture by which these goals can be achieved, and some specific solutions for data description and manipulation and for schema design.

REFERENCES 1. A. Gupta and S. Santini, “Towards feature algebras in visual databases: The case for a histogram algebra,” in Proceedings of the IFIP Working Conference on Visual Databases (VDB5), Fukuoka (Japan), May 2000. 2. S. Santini, “A query paradigm to discover the relation between text and images,” in Proceedings of SPIE Vol. 4315, Storage and Retrieval for Media Databases, 2001. 3. S. Santini, A. Gupta, and R. Jain, “Emergent semantics through interaction in image databases,” IEEE Transactions on Knowledge and Data Engineering , 2001. 4. J. Ullman, Elements of ML Programming, Prentice Hall, 1994. 5. R. Fagin, “Combining fuzzy information from multiple systems,” in Proceedings of the 15th ACM Symposium on Principles of Database Systems, Montreal, pp. 216–226, 1996. 6. D. Dubois and H. Prade, “A review of fuzzy set aggregation connectives,” Information Sciences 36, pp. 85–121, 1985. 7. K. Didrich, A. Fett, C. Gerke, W. Grieskamp, and P. Pepper, “OPAL: Design and implementation of an algebraic programming language,” Lecture Notes in Computer Science 782, 1994. 8. S. Santini and A. Gupta, “Principles of schema design for multimedia databases,” IEEE Transactions on Multimedia , 2002. (in press). 9. S. Santini and A. Gupta, “An algebra of wavelet features,” in ICME 2001, IEEE International Conference on Multimedia and Expo, Tokyo, Japan, 2001. 10. S. Santini, Exploratory Image Databases; Content Based Retrieval, Academic Press, 2001. 11. P. L. Wadler, “Comprehending monads,” in Proceedings of the 1990 ACM Conference on Lisp and Functional Programming, Nice, France, 1990. 12. L. Libkin, R. Machlin, and L. Wong, “A query language for multidimensional arrays: design, implementation and optimization techniques,” in Proceedings of SIGMOD ’96, Montreal, Canada, pp. 228–239, 1996.