Motivation for Weak Sets

Suppose you are browsing the World Wide Web (WWW) and want to display the .face les of all people listed on Carnegie Mellon's home page. Or, suppose through the on-line library information system (LIS) you want to get a list of papers by a particular author. Or, suppose you are a tourist in Pittsburgh and want to look at the on-line menus of all Chinese restaurants before choosing where to eat for dinner. Each of these kinds of queries returns a set of objects (.face les, card catalog entries, menus). What properties should we expect these sets to have? We claim that some standard properties of mathematical sets are desired, but others are not. In particular, we expect that: { Membership of an element is determined at some time between starting the query and nishing the query. Membership may not necessarily hold before the query, continuously throughout the run of the query, or even after the query completes. For example, if the LIS database is not up-to-date, we would not be surprised if an author's most recent paper is not listed; we would not go hungry if our restaurant search missed some (but not all) Chinese restaurants in Pittsburgh. { Order among elements does not matter. Hence retrieval of elements can be optimized. { There are no duplicates. (Though we probably would not be overly annoyed if there were.) { Elements in the set change infrequently. A restaurant's menu may change weekly or seasonally; a .face le, annually; an LIS entry, never. Because of the nature of the information repositories over which we run these queries, we would not expect concurrent reads and writes on the repository to be serializable. In particular, user A may be updating the information repository concurrently with user B who is reading from it. User B may see partial writes of A. This non-serializable behavior implies that: { Two people running the same query at the same time may obtain diierent sets of elements. { Running the same query twice in a row may return diierent sets of elements. Thus these sets provide weaker guarantees to the user than traditional set semantics or traditional distributed databases. However, for the kinds of wide area systems we consider, clients do not expect strong consistency properties, and implementations that provide stronger guarantees may prove ineecient. The key diierence, of course, is that unlike transaction-oriented databases (e.g., a bank's …