Conceptual models are a common way of documenting requirements and system design in projects addressing the reorganization and development of information systems (IS) (Kottemann & Konsynski 1984). As IS projects are often large-scaled, the required models are increasingly developed in a distributed way in order to increase the efficiency of modeling (vom Brocke & Thomas, 2006). In such cases, different modelers participate in the modeling process developing sub-models – potentially at different places and at a different time. Empirical studies show that such models can vary heavily concerning naming and structure (Hadar & Soffer, 2006). However, even models developed by a single person might include semantic and structural ambiguities if s/he does not follow any explicit modeling conventions (Delfmann, Herwig & Lis, 2009b). Trying to analyze such models, comparison conflicts can occur, which are commonly divided into naming (semantic) conflicts and structural conflicts (Batini & Lenzerini 1984).
In Figure 1, we present examples of a semantic and a structural conflict as well as a combination of both of them. (1a) depicts two structurally equivalent models, which include different vocabulary and phrasing. Two interpretations are possible. On the one hand, both models might depict the same real-life situation with structurally corresponding element names being semantically equivalent. The differences could result from the lack of semantic standardization. In this case, the terms “bill” and “o.k.” would be synonyms of “invoice” and “valid” correspondingly. On the other hand, the two models could depict different issues and the structurally corresponding names could represent semantically different things. The only chance to find out which situation is the case is to discuss the differing semantics with the modeler(s) involved. Thus, an automated analysis is not possible. (1b) depicts two models, which already apply standardized corporate vocabulary disallowing for naming conflicts. However, although these models potentially represent the same real-life issue, they involve different but in this case synonymous modeling structures. When trying to analyze (and compare) these models, we need to take account of the relation between synonymous structural patterns, such as the two depicted here. In (1c), two models involving both semantic and structural conflicts are presented. Besides using proprietary vocabulary (e.g., “component” vs. “part”), the model on the right-hand side has a higher level of detail than the left one, although both depict the same real-life situation. To sum up, due to semantic and structural conflicts performing a consistent analysis might pose an extremely laborious task.
Examples of semantic and/or structural conflicts in conceptual models