{"id":9912,"date":"2022-02-14T09:54:32","date_gmt":"2022-02-14T09:54:32","guid":{"rendered":"http:\/\/141.23.68.248\/wp\/?page_id=9912"},"modified":"2022-02-16T03:35:29","modified_gmt":"2022-02-16T03:35:29","slug":"development-of-the-combined-ontology","status":"publish","type":"page","link":"http:\/\/141.23.68.248\/wp\/?page_id=9912","title":{"rendered":"Development of the Combined Ontology"},"content":{"rendered":"
\n

STEP 1: Defining the Classes and Class Hierarchy<\/h2>\n
\n

For the integration context of the energy supply of a city, new classes such as \u201cEnergy Generation\u201d and \u201cEnergy Transportation\u201d are created and the Ontologies of the individual systems added as subclasses (s. Fig.1).<\/p>\n

\"220213_001\"<\/a><\/p>\n

Fig.1:\u00a0Extract of class hierarchy showing the integration of the three individual systems into one ontology for the energy supply of a city [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n

All three individual systems contain the concept of materials summarizing the used materials for the individual components of a particular system. Thus, a superclass \u201cMainMaterial\u201d is created including all used materials for the systems within the combined Ontology (s. Fig. 2).<\/p>\n

\"220213_002\"<\/p>\n

Fig.2: Extract of class hierarchy showing the superclass \u201cMainMaterial\u201d with its subclasses [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n

For the Updraft Tower and the Solar Power Tower Plant the concept of storing the surplus heat of the day correspond. Thus, a superclass \u201cIntermediateStorage\u201d is created containing a \u201cMoltenSaltStorage\u201d for the Solar Power Tower Plant and a \u201cWaterStorage\u201d for the Updraft Tower (s. Fig.3). Both storage types can be categorized as a thermal storage and different types for a chemical and mechanical storage are added. All types are commonly used in the context of sustainable energy technologies and provide design alternatives for the storage of different energy forms.<\/p>\n

\"220213_003\"<\/a><\/p>\n

Fig.3: Extract of class hierarchy showing the superclass \u201cIntermediateStorage\u201d with its subclasses\u00a0[taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n

Besides, all three individual systems contain the same concepts, such as \u201cTower\u201d, \u201cFoundation\u201d or \u201cStructuralComponents\u201d as subclasses of the individual systems. Here, it was considered to combine the intersecting concepts into one superordinate class. As a result, the ontologies for the individual systems would have been split apart, so that it would no longer be clear which component is needed for which particular system. Moreover, these concepts were already specified according to the requirements of each individual system by either naming the concept characteristically (e. g. \u201cIndividualFoundation\u201d for the Heliostats of the SPTP) or by describing the concept with certain design option as subclasses, which are eligible for this system (e. g. 8 design option for the foundation of a Transmission Tower). A breaking down of the individual ontologies would lead to a totally different overall ontology, which no longer would suit the integration context as well as the aforementioned purpose and scope of the combined Ontology. Therefore, only the names of the same concepts are adapted by adding an abbreviation, like \u201cTT\u201d for Transmission Tower, \u201cSUT\u201d for the Solar Updraft Tower and \u201cSPTP\u201d for the Solar Power Tower Plant (s. Fig.4). By this, concepts or components can be easily related to the individual system, they are part of, and confusions are prevented.<\/p>\n

\"220213_004\"<\/a><\/p>\n

Fig.4: Extract of class hierarchy showing the same concepts for the different individual systems, which were renamed for terms of validation [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n

The classes of the individual Ontologies are created in a bottom-up development process. Moreover, all classes at the same level are disjoint to make sure that an instance of one class cannot be an instance of another class. As this ontology only represents a section of a real entity, it can be extended and refined with much more data.<\/p>\n

\n

STEP 2: Defining the Object Properties of Classes<\/h2>\n
\n

Based on the developed class hierarchy, relations between the classes and their inverse are defined by implementing object properties. As Fig.5 shows, prefix \u201chas\u201d and the inverse \u201cis \u2026 of\u201d are added to the class names. In this way the following object property hierarchy develops.<\/p>\n

\"220213_005\"<\/a><\/p>\n

Fig.5: Taxonomic hierarchy of object properties [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n
\n

STEP 3: Defining the Domain and the Range of the Object Properties<\/h2>\n
\n

The domain of an object property describes the classes which can be related (input), while the range describes the class, as well as all it subclasses, which the object property is related to (output). For the inverse of the object properties the domain and range are reversed. In the following Fig.6, the defined domain and range for a few object properties and their inverse are represented exemplarily. They can be read as \u201c[Subclasses or Individuals of the class] EnergySupplyOfCity (domain) hasMainMaterial [from class] MainMaterial (Range)\u201d<\/em>.<\/p>\n

\"220214_006\"<\/a><\/p>\n

Fig.6: Summary of the defined domain and range for a few object properties [authors\u2019 table]<\/em><\/h6>\n
\n

STEP 4: Creating Instances and Design Options<\/h2>\n
\n

The existing design options of every individual system and the related individuals are integrated into the combined Ontology and extended to suit the integration context. This means, that data property assertions of certain individuals are changed in their value or replaced by another according to the predefined input parameters within the integration context. By this, three configurations for the Renewable Energy Park were implemented, each representing a virtual city with a different number of inhabitants and energy consumption per capita. All further input parameters for these virtual cities are summarized in Fig.7. Except the design options of the individual systems, these input parameters are implemented as data property assertions for each configuration (s. Fig.8).<\/p>\n

\"220215_008\"<\/a><\/p>\n

Fig.7: Summary of input parameters for the implementation of three Renewable Energy Park Configurations\u00a0[authors\u2019 table]<\/em><\/h6>\n

 <\/p>\n

\"220215_008\"<\/a><\/p>\n

Fig.8: Data property assertions for the individual \u201cREPOption1\u201d [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n
\n

STEP 5: Defining Properties Restrictions<\/h2>\n
\n

By the definition of property restrictions, differences and limitations as well as similarities between the individuals of certain classes are defined. As the afore defined domain and range do not provide any constraints (s. STEP 3), the definition of property restrictions are needed. To the existing property restrictions for the \u201cDesigned\u201d-classes of the individual systems (s. Fig.9), further restrictions are added or specified in order to suit to the integration context.<\/p>\n

\"220215_009\"<\/a><\/p>\n

Fig.9: Summary of properties restrictions for every individual system [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n

An example for a specification of a restriction is done for the SPTP by saying that a SPTP does not just have a tower from SPTower-class, but rather the specific type of a \u201cTubeTower\u201d. Thus, all other tower types are excluded for the defined design options.<\/p>\n

\"220215_009_01\"<\/a><\/p>\n

An addition is e. g. done for the SPTP and the SUT by determining a thermal storage type. The universal expression \u201conly\u201d implies that a SPTP or SUT does not have to have a thermal storage, but if they have a storage, then the SPTP comprises a molten salt storage, while the SUT comprises a water storage.<\/p>\n

\"220215_009_02\"<\/a><\/p>\n

Besides these general property restrictions, different individuals are assigned to each design option of the individual systems. These individuals define the characteristics of\u00a0the design options and make them distinguishable. To establish a connection between the MainMaterial-class and the certain components of the individual system different material types, such as steel or reinforced concrete, are implemented as individuals and related to the particular design option by nominal expressions (s. Fig.10).<\/p>\n

\"220215_010\"<\/a><\/p>\n

Fig. 10: Summary of nominal properties restrictions for one design option of every individual system [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n

Finally, existential restrictions as well as one negation are implemented for the configurations of the Renewable Energy Park (s. Fig.11). For each of this configuration one design option of the individual systems is related to by a nominal restriction (Fig.12).<\/p>\n

\"220215_011\"<\/a><\/p>\n

Fig. 11: Summary of properties restrictions for the Renewable Energy Park Configuration [taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n

\"220215_012\"<\/a><\/p>\n

Fig. 12: Summary of nominal properties restrictions for one design option of every individual system\u00a0[taken from Prot\u00e9g\u00e9]<\/em><\/h6>\n
\n

\u00a0See also:<\/strong><\/em><\/p>\n

Results of Ontology<\/a><\/em><\/p>\n

Introduction to Combined Ontology<\/em><\/a><\/p>\n

Or main topics:<\/strong><\/em><\/p>\n

Integration Context\u00a0and Individual Systems<\/a><\/em><\/p>\n

Combined Parametric Model<\/a><\/em><\/p>\n

\n","protected":false},"excerpt":{"rendered":"

STEP 1: Defining the Classes and Class Hierarchy For the integration context of the energy supply of a city, new classes such as \u201cEnergy Generation\u201d and \u201cEnergy Transportation\u201d are created and the Ontologies of theContinue reading<\/a><\/p>\n","protected":false},"author":73,"featured_media":0,"parent":8051,"menu_order":0,"comment_status":"closed","ping_status":"open","template":"page-templates\/page_fullwidth.php","meta":{"footnotes":""},"class_list":["post-9912","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=\/wp\/v2\/pages\/9912","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=\/wp\/v2\/users\/73"}],"replies":[{"embeddable":true,"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9912"}],"version-history":[{"count":44,"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=\/wp\/v2\/pages\/9912\/revisions"}],"predecessor-version":[{"id":11106,"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=\/wp\/v2\/pages\/9912\/revisions\/11106"}],"up":[{"embeddable":true,"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=\/wp\/v2\/pages\/8051"}],"wp:attachment":[{"href":"http:\/\/141.23.68.248\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9912"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}