As ontology development becomes a more ubiquitous and collaborative process, the developers face the problem of maintaining versions of ontologies akin to maintaining versions of software code in large software projects. Versioning systems for software code provide mechanisms for tracking versions, checking out versions for editing, comparing different versions, and so on. We can directly reuse many of these mechanisms for ontology versioning. However, version comparison for code is based on comparing text files---an approach that does not work for comparing ontologies. Two ontologies can be identical but have different text representation. We have

A language for databases with sets, tuples, lists, object identity and structural inheritance is proposed. The core language is logic-based with a fixpoint semantics. Methods with overloading and methods evaluated externally providing extensibility of the language are considered. Other important issues such as updates and the introduction of explicit control are discussed. 1 INTRODUCTION The success of the relational database model [19, 38, 27] is certainly due to technological advances such as fast query processing or reliable concurrency control. However, we believe that a major factor in that success has been the existence of simple-to-use languages allowing the definition and manipulation of data. This has to be remembered while considering future generations of database systems. Object-oriented database systems are now being developed, e.g., [15, 12, 22, 39, 36]. An object-oriented approach [24] is used to answer the needs of a much wider variety of applications. Most of th...

Making software reliable is one of the most important technological challenges facing our society today. This thesis presents a new type system that addresses this problem by statically preventing several important classes of programming errors. If a program type checks, we guarantee at compile time that the program does not contain any of those errors. We designed our type system in the context of a Java-like object-oriented language; we call the resulting system SafeJava. The SafeJava type system offers significant software engineering benefits. Specifically, it provides a statically enforceable way of specifying object encapsulation and enables local reasoning about program correctness; it combines effects clauses with encapsulation to enable modular checking of methods in the presence of subtyping; it statically prevents data races and deadlocks in multithreaded programs, which are known to be some of the most difficult programming errors to detect, reproduce, and

Achieving correct changes is the dominant activity in the application software industry. Modification of database schemata is one kind of change which may have severe consequences for database applications. The paper presents a method for measuring modifications to database schemata and their consequences, by using a thesaurus tool. Measurements of the evolution of a large-scale database application currently running in several hospitals in the UK are presented and interpreted. The kind of measurements provided by this in-depth study is useful input to the design of change management tools. Keywords: Schema evolution, change statistics, change management tools. * Published in: Information and Software Technology, Vol. 35, No. 1, pp. 35-44, January 1 1 Introduction One of the most challenging problems of building and maintaining large, long-lived application systems is to cope with all the changes that inevitably will be imposed on the systems over time. Many large application systems...

Persistent object stores require a way to automatically upgrade persistent objects, to change their code and storage representation. Automatic upgrades are a challenge for such systems. Upgrades must be performed in a way that is efficient both in space and time, and that does not stop application access to the store. In addition, however, the approach must be modular: it must allow programmers to reason locally about the correctness of their upgrades similar to the way they would reason about regular code. This paper provides solutions to both problems. The paper first defines upgrade...

To achieve interoperability, modern information systems and e-commerce applications use mappings to translate data from one representation to another. In dynamic environments like the Web, data sources may change not only their data but also their schemas, their semantics, and their query capabilities. Such changes must be reflected in the mappings. Mappings left inconsistent by a schema change have to be detected and updated. As large, complicated schemas become more prevalent, and as data is reused in more applications, manually maintaining mappings (even simple mappings like view definitions) is becoming impractical. We present a novel framework and a tool (ToMAS) for automatically adapting mappings as schemas evolve. Our approach considers not only local changes to a schema, but also changes that may affect and transform many components of a schema. We consider a comprehensive class of mappings for relational and XML schemas with choice types and (nested) constraints...

When a database is shared by many users, updates to the database schema are almost always prohibited because there is a risk of making existing application programs obsolete when they run against the modified schema. This paper addresses the problem by integrating schema evolution with view facilities. Each user is assigned his or her own database view, and develops application programs against the view. When new requirements necessitate schema updates for a particular user, then the user specifies schema changes to his personal view rather than to the shared base schema. Our view schema evolution approach then computes a new view schema that reflects the semantics of the desired schema change, and replaces the old view with the new one. This approach provides the means for schema change without affecting other views (and thus without affecting existing application programs). The persistent data is shared by different views of the schema, i.e. by both old as well as newly developed app...

Current object database management systems support user-defined conversion functions to update the database once the schema has been modified. Two main strategies are possible when implementing such database conversion functions: immediate or lazy database updates. In this paper, we concentrate our attention to the definition of implementation strategies for conversion functions implemented as lazy database updates.

Schema evolution is a problem that is faced by long-lived data. When a schema changes, existing persistent data can become inaccessible unless the database system provides mechanisms to access data created with previous versions of the schema. Most existing systems that support schema evolution focus on changes local to individual types within the schema, thereby limiting the changes that the database maintainer can perform. We have developed a model of type changes incorporating changes local to individual types as well as compound changes involving multiple types. The model describes both type changes and their impact on data by defining derivation rules to initialize new data based on the existing data. The derivation rules can describe local and nonlocal changes to types to capture the intent of a large class of type change operations. We have built a system called Tess (Type Evolution Software System) that uses this model to recognize type changes by comparing schemas and then produces a transformer that can update data in a database to correspond to a newer version of the schema.

this paper, we propose a sound and complete axiomatic model for DSE in OBSs. The main benefit of the model is the formalization of DSE characteristics into a welldefined set of axioms. The axioms automatically maintain complex schema relationships and properties from two input sets associated with each type in a schema. The elements of these sets can be provided by the user, schema designer, system, or a combination of sources. One set is called the essential supertypes and contains the types that must be maintained as supertypes of a type for as long as it is consistently possible. The other set is called the essential properties and contains the properties that must be maintained in the type for as long as it is consistently possible. The correct properties and relationships within the schema are automatically derived by the axiomatic model using the essential supertypes and essential properties as a basis. The derivations performed by the axiomatic model have a proven soundness, completeness, and termination. The inclusion/exclusion of axioms in the model leads to a design space that categorizes OBSs into object-based, type-based, and object-oriented systems. The last category is further refined into several distinct subcategories that vary in functionality and expressiveness. To illustrate the power and practical usefulness of the model, the DSE operations of several existing OBSs are reduced to the axiomatic model and compared within this common framework. In recent years, researchers have addressed the problem of defining DSE policies for OBSs. These studies approach the issue from the perspective of individual systems. The axiomatic model is unique in this respect in that it captures and formalizes the salient features of DSE in OBSs and can be adopted as a commo...