Partial ontology model

Despite of all the advantages which have been enumerated above. Semantic Web technologies also have certain shortcomings as discussed in the previous sections. The partial ontology models and the complementary software procedures, which are needed to compensate these shortcomings are described in this subchapter. 

There was little to be found in literature regarding this ambitious problem of a comprehensive, uniform, and layered process/product model. There were some ontology approaches [540, 617] or some coarse partial models [14] on the application level. Also, there were some internal models available for tool construction, e.g. to formalize tool behavior [334, 350]. So, setting the ambitious goal of a process/product model is another key message of IMPROVE. This general model must have a tight connection from application models down to the realization of tools. 

In the formal specification of version 2.0, ontology modules are manifested through different XML namespaces [1060], each of which is stored in a single OWL file connections between the modules are realized by using the import mechanism provided by OWL. The partial models correspond to identically named directories in the formal specification. That way, they establish a directory structure for managing the OWL files. 

The implementation of computer support for design processes requires formal representations of the work processes. To this end, the conceptual data model CLiP (cf. Subsect. 2.2.3) has been extended with a partial model covering design processes. The experiences gained with this model have led to its revision and re-implementation in form of a Process Ontology. Structure, content, and usage of both approaches are described in Subsect. 2.4.6. 

Integrating the work process and the decision model allows to remedy the difficulties in defining subclasses of Activity as they were encountered for the partial model Process Models of CLiP (called sub-activites there see Sect. 2.4.6). The relation class OutputInformationFlow defined in the Process Ontology does not impose any restrictions on the type of Information created in an Activity (see Fig. 2.31), whereas a DecisionActivity is required to produce at least one DecisionObject. Subclasses of DecisionActivity are characterized by... 

To date (as of 2007), a detailed documentation of the POPE ontologies has not been published, but from the available information it can be concluded that there is no common model framework for the different ontologies. Instead, the ontologies are being developed independently and are only partially integrated. Thus, consistency between the different ontologies is not guaranteed. 

The various partial models of the Process Data Warehouse are interconnected through the Core Ontology which consists of four primary areas of conceptualization products, processes, descriptions, and storage. This central model comprises the concepts of process modeling and enactment, of products and documents, dependencies, decision support and documentation, for the description of content and categorizations, and other integration models. 

Around these fundamental and domain-independent models, extension points are placed that can be used to add the models of a specific application domain or other specializations. The concrete data are then stored as instances of the appropriate ontological concepts. This allows modifications and extensions of the partial models used, even during project execution. 

The transition as described above relies on a representation of process templates using the partial model Process Models of CLiP. Substituting Process Models with its recently developed successor, the Process Ontology described in Subsect. 2.4.6, is straightforward. Similarly, the other partial models of CLiP can be replaced with OntoCAPE (cf. Subsect. 2.2.4). In contrast, the integration of the Decision Ontology (see Subsect. 2.5), which replaces the simple IBIS-based rationale model inside Process Models with a more expressive variant of DRL, is still an open issue. 

For each document type, a document contents model determines which entities from the partial models ontologies can be contained in a corresponding document instance. For instance, the PFD document can contain arbitrary process steps defined in the partial model process as well as substances defined in the partial model chemical process material. Fine-grained interdocument relationships that are not already included in the ontologies are added. Furthermore, the document structure can be refined, indicating the order or the type of structural entities (such as heading, text block, or table) that have to be contained in the document (cf. Subsect. 2.3.4). 

First, document contents models for any of the documents to be integrated have to be refined and formalized, providing enough details for the tool building process (see a) of Fig. 6.5). A basis for that are the application document contents models (see upper part of Fig. 6.5) that specify which entities of partial models are relevant for which document. The definition of the corresponding entities and some of their relationships can be extracted from the ontologies. 

This MErKoFer ontology is partially shown in Fig. 7.14. In the area of descriptions, the most important aspects can be found profile and material definitions, and the aforementioned categories for phase changes and other tasks, process states, and errors. In the product area, the plant and its elements are modeled as producing products, in addition to profile and material batches as produced products. The process area contains the production process itself as primary center for state and material changes, and the transport orders of the material batches which are read from the company s ERP system (SAP R/3) that is part of the storage area. 

Biahmou et al. [42] have developed an approach for deriving behavior models from 3D models in MATLAB/SimMechanics that have been created with CATIA V5. After updating the geometrical model, the behavioral model is to be updated by the user. In order to free the user from this task and achieve a structured and right synchronization of changes in partial models of a system, the application of ontologies has been addressed to identify the update sequence of models [43]. 

Running Example For the remainder of this chapter, we consider the development and maintenance of a multi-viewpoint system model within the realm of computer networks as our running example. This fictitious system is based on three individual system components/tools that all rely on partially different but overlapping conceptualizations of the domain of interest, which are expressed as ontologies as depicted in Fig. 13.2. 

---