Conceptual Mappings

Every technical space has certain properties. First, information residing in such a space exposes some kind of structure. This structure follows certain rules, which are defined either formally or informally. Also, the information held in these structures is made of basic building blocks—primitive types. In addition, all valid structures have some meaning—they expose semantics. If we want to transfer information from one technical space to another, these aspects must be considered altogether. We call the entirety of this relationship between two spaces a conceptual mapping. The mapping is conceptual,

5 Bridging Technical Spaces

because it is not aware of the concrete types of data (i.e., languages). Rather, it es- tablishes a relation between the concepts—both structurally and semantically—of two spaces. In this section, we will discuss the nature of such conceptual mappings more deeply, as well as the requirements that should be met by them in general.

Every piece of data that resides in a particular technical space adheres to the restric- tions of this space. Typically, data is organized according some predefined structures. For example, object-oriented models use graphs as a structural paradigm. Other spaces (e.g., the XML space) use trees as an underlying formalism to arrange information. Structural concepts are typically used to construct complex units of information from smaller, less complex units. To establish a conceptual mapping between two techni- cal spaces, the structural concepts (i.e., the means to construct complex data) must be mapped. Such a mapping must preserve important properties (e.g., the hierarchical order of information). Even though most technical spaces exhibit means to express com- plex data structures, this is not the case for all spaces. Some artifacts (e.g., binary files containing test data) do not make use of structure. Rather, these are organized in a flat manner. Thus, the amount of structure employed in a technical space can vary.

Besides the conceptual gap between data structures employed by different technical spaces, primitive data types must also be considered. Here, mapping data types of one space to types in the other is required. Conversion of data values may also be needed. For example, if one space offers a primitive type to represent dates, but another one does not, a reasonable translation is needed. For example, dates may be represented as strings using some canonical format. For technical spaces that make use of common basic data types such as integers, strings and booleans, mapping primitive types is quite simple. It does not involve any conversion, if the ranges of all primitive types are equal. While mapping complex and primitive data types, one must always keep the seman- tics of the elements that are subject to the mapping in mind. For example, if tables (i.e., a structural concept of one space) must have unique names, the corresponding con- cept (e.g., XML complex types) should have a matching semantics. As the conceptual mapping is established on the level of the language concepts, only the semantics of the concepts is relevant here. The meaning of concrete languages does differ from language to language and must therefore be considered individually.

In general, semantics can be divided into its static and its dynamic aspects. While the former entails the properties that can be checked before execution, the latter describes the dynamic behavior of a software system, specified by an artifact. Thus, on the conceptual level, where we map the language concepts to each other, the dominating aspect is the static one. Dynamic semantics differs for concrete languages and must therefore be considered during the creation of the language mapping.

Depending on the concrete technical spaces to be mapped, there can be few seman- tic restrictions (e.g., for context-free grammars) or quite many constraints that must be taken care of (e.g., for ontologies). Unfortunately, few technical spaces have a for- mal definition for the static and dynamic semantics of their concepts. Even concrete

5.1 Technical Spaces - Definitions and Properties

languages within one space are rarely accompanied by a formal definition of their se- mantics. Languages in some spaces do at least capture the static aspects (e.g., using attribute grammars in combination with context-free grammars), but formal descriptions of dynamic semantics are rare.

As a consequence, the correctness of a mapping (both between spaces and concrete languages) is usually difficult to establish. Sometimes there might not even exist a mapping which preserves all semantic properties when transferring data to a different space. As long as the properties that are relevant to the concrete application of a bridge between two spaces are preserved, this is not problematic. But again, this requires the formalization of the relevant properties, which is often not present either.

In the following, we will explicitly look at the four categories of interest mentioned above (i.e., mapping structural concepts, mapping primitive types, mapping static and dynamic semantics). Each of them will form a separate subsection for the concrete bridges discussed in the next sections.

In general, conceptual mappings should strive for completeness. Both the structural concepts and the primitive types should be mapped to the best degree possible. If con- cepts are not mapped, information is potentially lost, or at least not available in the opposite space. With regard to correctness, we have already argued that the missing semantic formalization of many technical spaces renders proofs about mappings impos- sible. Nonetheless, if possible, conceptual mappings should preserve the semantics when bridging spaces. Additionally, conceptual mappings should be independent of particular applications to enable their reuse.