Keywords: Schema Mapping, Information Integration, Schema Heterogeneity, Schema Matching, Machine Learning, Self-Tuning System
Astract: Information integration has a long history in computer science.
It has started with the integration of database schemas in the early eighties. With the rise of the semantic web and the emerging abundance of ontologies, the need for an automatic information integration increased further.
Information integration in general and automatic information integration in particular is a huge and challenging research area. One of the main problems is handling semantic heterogeneity and schema heterogeneity.
Manually finding the semantically overlapping parts of schemas is a tedious problem. Furthermore, writing integration code is a labor intensive, error-prone, and cumbersome task. A lot of approaches have already been developed to automate this work. Nevertheless, not all integration problems have been solved so far.
Matching tools are used to automatically find similarities between schemas. The results of these tools are simple correspondences. Based on these correspondences, one is able to write integration code. However, the simple correspondences are just suggestions and must be verified manually. Hence, the completeness and correctness of the resulting correspondences may not be assured. Furthermore, it is not possible to automatically derive transformation code for all found simple correspondences.
In order to write transformation code, different kinds of transformation languages have been developed. The produced code is too customized for a specific type of schema to be easily reused for other integration problems. Hence, to the best of our knowledge, there exists no transformation language to develop reusable transformation patterns for different kinds of heterogeneity problems.
This thesis addresses the heterogeneity problems, as well as the lack of reusable transformation code, and the need for establishing correct and complete correspondences between schemas.
The first two problems are tackled by developing an executable declarative mapping language, which is able to cope with the core of schema heterogeneity problems. In contrast to simple correspondences, this mapping language is able to express more constraints. Based on these more expressive mappings, the execution code is automatically derived.
The third problem is tackled by a self-tuning, iterative matching approach. This approach is based on the developed mapping language.
Mapping strategies are responsible for the application of mapping operators. Based on the executable mapping suggestion, completeness and correctness are achieved for a provided set of instance models by a test-driven approach. These instance models are used to evaluate the produced mapping model. The prototype of this self-tuning approach is called SmartMatcher.

Keywords:
Astract: In 1999 UN/CEFACT and OASIS started the ebXML Initiative which delivered its first set of specifications 2 years later. This book chapter discusses the goals and the results of ebXML. The core of the book chapter addresses a critical evaluation of ebXML. It discusses why ebXML was succesful in some parts, but failed in market acceptance for major parts.

Keywords:
Astract: Inter-organizational systems have significantly been affected by Service-oriented Architectures (SOA) andWeb Services - the state-of-the-art technology to implement SOA. SOA is said to enable quick and inexpensive changes of the IT in order to establish new business partnerships or to reflect changes in existing partnerships. However, current approaches to inter-organizational systems focus too much on existing Web Services standards and, thus, on the technology layer. In such an approach the technology drives the business. In this paper we analyze the shortcomings of this bottom-up approach. As an alternative we suggest a top-down methodology where the business requirements drive the technology. This methodology starts off with the business value perspective, leading to a business process perspective and resulting in an IT execution perspective. We do not invent any new approaches on each of these layers, rather we outline how existing approaches are used and combined into a business requirements driven approach to inter-organizational systems.

Keywords:
Astract: Shorter life cycles of products and services require faster changing business models. Information systems must quickly adjust to the adapted business models. Business models are usually described by their own proprietary notation, which is incompatible with UML - the de-facto modeling standard in software engineering. In order to allow a straight-through modeling approach from business models over business process models to software artifacts, it is desirable to use a common modeling approach. Thus, we suggest to map existing concepts to describe business models onto the UML notation. In our work we mainly focus on inter-organizational systems. A promising approach describing a business model for an inter-organizational network of actors is delivered by e3-Value. In this paper, we present a discussion of different approaches to represent the e3-Value concepts by means of UML. A UML notation for e3-Value is a precondition to future work on aligning e3-Value to UML-based approaches specifying inter-organizational business processes.

Keywords:
Astract: Business partners willing to do business electronically with each other must reach an agreement (1) on the economic level, (2) on the inter-organizational process choreography, and (3) on the services implementing the choreography. In order to search for a potential business partner, one will first look for a partner who offers a required service on the economic level and who supports a complementary role in a choreography, before binding to its IT services. Inasmuch, a registry for inter-organizational systems should cover all three levels and maintain the dependencies between them. In this paper we set up on well accepted approaches on the different levels, i.e. (1) the e3value ontology, (2) the UN/CEFACT modeling methodology (UMM), and (3) the business process execution language (BPEL). We specify a registry meta model on top of ebRIM registering the artifacts on the different levels and defining their inter-dependencies.