predicated on the belief that information filtering can be more effective when humans are involved in the filtering process. Tapestry was designed to support both content-based filtering and collaborative filtering, which entails people collaborating to help each other perform filtering by recording their reactions to documents they read. The reactions are called annotations; they can be accessed by other people’s filters. Tapestry is intended to handle any incoming stream of electronic documents and serves both as a mail filter and repository; its components are the indexer, document store, annotation store, filterer, little box, remailer, appraiser and reader/browser. Tapestry’s client/server architecture, its various components, and the Tapestry query language are described.

A formal framework is introduced for studying the semantics and expressiveness of active databases. The power of various abstract trigger languages is characterized, and related to several major active database prototypes such as ARDL, HiPAC, Postgres, Starburst, and Sybase. This allows to formally compare the expressiveness of the prototypes. The results provide insight into the programming paradigm of active databases, the interplay of various features, and their impact on expressiveness and complexity.

This position paper provides a general description of the field of active databases, focusing on the main problems yet to be solved; suggests that deductive databases may contribute to understand some of these problems; and indicates classes of applications that can be specified in a declarative way. Premise The field of active databases has recently emerged as one of the most important directions of evolution of database technology. Significant progress has been achieved both in the research environment and in the commercial world; these are reflected on one side by the relative1 large number of recent articles on the subject (see [12]), and on the other side by the increas-ing number of research prototypes and commercial systems which provide active behavior (see [ 13,16,19]). In general, this behavior is supported through inte-grated, low-level production rule facilities allowing for the automatic execution of data manipulation opera-tions when certain events occur and/or certain condi-tions are met. In spite of the rapid development of this field, sev-eral problems remain to be solved in order for active databases to become widespread and fully accepted. A first problem concerns the understanding of the semantics of a collection of production rules. This amounts to underst anding precisely under which con-ditions rules are executed and the effect of their execu-tion. Difficulties are mostly due to the variety of pro-duction rules which have been proposed; differences are due to: 0 The event upon which a rule is triggered:- A database modification (through insert, delete, or update operations).- A retrieval operation.- A time-related event. 0 The rule consideration time with respect to transactions. Rules can be executed in the context of the transactions that update the database, or be executed asynchronously. In the former case, rule consideration can be:- After each update operation.- At user-defined rule execution points.

. The expressiveness and complexity of several active database prototypes are formally studied. First, a generic framework for the specification of active databases is developed. This factors out the common aspects of the prototypes considered, and allows studying various active database features independently of any specific prototype. Furthermore, each of the prototypes can be specified by specializing certain parameters of the framework. The prototypes considered are ARDL, HiPAC, Postgres, Starburst, and Sybase. Using their formal specifications, the prototypes are compared to each other with respect to expressive power. The results provide insight into the programming paradigm of active databases, the interplay of various features, and their impact on expressiveness and complexity. 1 Introduction The ability of a database to react to specified events is an increasingly common requirement in advanced database systems. This has led to the emergence of active databases, which provide...

This article presents an approach to build flexible active rule execution models. It introduces a framework that covers all phenomena associated with the behavior of active database systems. This framework is made up of a taxonomy that allows us to characterize execution models of existing active database systems and that has been used to provide the Flexible Active Rule Execution (Fl'ARE) model that is formally defined and implemented. The model is based on a set of constants and independent parameters that may take values within a set of predefined values. Those parameters and values have been identified from the dimensions of our taxonomy. These dimensions have been structured into two main classes: the dimensions of one rule execution and the dimensions on a module(set) of rules. Dimensions of one rule have been classified into intrinsic dimensions, dimensions related to the underlaying transaction model and dimensions related to the rule model. Having a flexible active rule execution model provides a support intended to design and develop new rule execution engines well-adapted to different uses of rules, to predict and understand the resulting behavior of active applications. Furthermore, the model is modular as it allows the integration of heterogeneous rule modules within the same application, each of them having its own semantics based on the service it is intended to support. Categories and Subject Descriptors: H.2.m [Information Systems]: Database management General Terms: Design, Theory, Experimentation Additional Key Words and Phrases: active databases, active rule systems, behavior, execution models A Parametric Active Rule Execution Model \Delta 1 1. INTRODUCTION 1.1 Context

) Philippe Picouet E.N.S.T. - Paris picouet@inf.enst.fr Victor Vianu U.C. San Diego vianu@cs.ucsd.edu Abstract A formal framework is introduced for studying the semantics and expressiveness of active databases. The power of various abstract trigger languages is characterized and related to several major active database prototypes such as ARDL, HiPAC, Postgres, Starburst, and Sybase. 1 Introduction In the past few years there has been tremendous interest in active database systems. Active databases provide "trigger systems" that execute actions in response to specified events. A wealth of active database models have been proposed and several major prototypes produced [CCCR + 90, Coh86, Han89, MD89, SKdM92, SJGP90, WF90] (see also [WCD95]). However, foundational work in this area is still scarce (e.g., see [AWH92, BM91, HJ91a]). The aim of the present paper is to develop a formal framework for active databases and use it to investigate several basic issues relating to their seman...

Machine Interface.............................................................................................. 26 3.2.3 Concurrency Control....................................................................................................... 27 3.3 VENUSDB LANGUAGE SEMANTICS: AN EVALUATION ............................................................ 28 3.3.1 Related Work.................................................................................................................... 30 3.3.2 The Mortgage Pool Allocation Problem .......................................................................... 33 3.3.3 Quantitative Results ......................................................................................................... 37 3.3.4 Discussion and Conclusions ............................................................................................ 43 CHAPTER 4 APPLICATION SEMANTICS FOR ACTIVE LOG MONITORING APPLICATIONS ............................................................................................45 4.1 MOTIVATION ........................................................................................................................... 46 4.1.1 Coupling Modes............................................................................................................... 47 4.1.2 Example 1 ........................................................................................................................ 48 4.2 BACKGROUND.......................................................................................................................... 50 4.2.1 LMAs, Datalog, and Confluence ..................................................................................... 50 4.2.2 Previous Work....................................................