3. Marketplace-Level Domain Ontologies

This chapter and the subsequent two chapters present ontologies from the VIMMP project, their relation to other work (including other ontologies) and examples for their use in practice. While this is not a theoretical work, we begin with a brief introduction to the usual formal notation, on the one hand to support certain arguments, e.g. concerning ontology alignment, and on the other hand to make related literature, where such notation is employed, more accessible. For a dedicated presentation of Description Logic (DL), the logical formalism is employed for ontologies from the point of view of theoretical computer science, which exists in a great variety of versions, the reader is referred to Baader et al. [1] as well as Schneider and Šimkus [2]; the present work partly adheres to the notation used by the DL community, but deviates from it on occasion. Formal ontology also has philosophical aspects—which is natural given its origin in that discipline—that we do not address here; for this purpose, the reader is pointed to Berto and Plebani [3], whereas an easily accessible introduction to semantic technology from the point of view of ontology engineering is provided by Allemang and Hendler [4].

The formal representation of what is known in any given context is called a knowledge base; it is defined as a pair \(\mathcal {K}= (\mathcal {T}, \mathcal {A})\), where \(\mathcal {T}\) is the ontology and \(\mathcal {A}\) is the scenario. In the DL community, \(\mathcal {T}\) is called the TBox (terminological box) and \(\mathcal {A}\) is called the ABox (assertional box)—hence the notation—while in model theory, \(\mathcal {A}\) is referred to as a model. The ontology describes how we formalize a domain of knowledge, in general, irrespective of the circumstances, whereas the scenario contains statements that are contingent; depending on context this may be the meaning of the content of a database or a file. The ontology is given by a tuple \(\mathcal {T}= (\mathbf {C}, \mathbf {R}, \Gamma )\), where \(\mathbf {C}\) is a set of elementary concept (also “class” or “universal”) names, \(\mathbf {R}\) is a set of elementary relation (also “role”) names, and \( \Gamma \) is a set of rules (also “general inclusions” or “axioms”). The scenario, in turn, is a tuple \(\mathcal {A}= (\mathbf {I}, A _\mathrm {c}, A _\mathrm {r}, H )\), where \(\mathbf {I}\) is a set of individual (also “object” or “particular”) names, \( A _\mathrm {c}\) is a function representing conceptual assertions, such that an individual name \( I \in \mathbf {I}\) is mapped to a set of concepts \( A _\mathrm {c}( I )\) and \( A _\mathrm {r}\,\subseteq \, \mathbf {I}\times \mathbf {R}\times \mathbf {I}\) is a set of relational assertions. The function \( H \) maps individuals \( I \in \mathbf {I}\) to sets of elementary datatype property assertions \( H ( I ) = \{ \eta _1, \dots , \eta _ n \}\) where¹ each elementary datatype property assertion \( \eta _ i = ( k _ i , v _ i )\) consists of a textual key \( k _ i \in \Sigma ^ \star \) and a textual or numerical value \( v _ i \in \mathbb {R}\cup \Sigma ^ \star \), with \( \Sigma \) representing the employed alphabet and \( \Sigma ^ \star \) the free monoid over \( \Sigma \).

On the semantic web, using the Web Ontology Language (OWL), elementary names correspond to Internationalized Resource Identifiers (IRIs), and anything referred to by an IRI, including concepts, relations and individuals, is accordingly also called a “resource”. An IRI consists of a prefix and a suffix, where the alphabet \( \Sigma \) is the Unicode/ISO10646 universal coded character set. For the prefix, the same well-known syntax applies as for a URL, and indeed, resolvable locators can be used as IRIs; however, it is equally allowed to use non-resolvable identifiers, which cannot be directly looked up on the web. Most notations permit an abbreviation of the prefix so that osmo:workflow_graph can be written instead of the full IRIfor the concept name with the suffix workflow_graph from the ontology OSMO, cf. Sect. 3.3. Conceptual and relational assertions are of the typerespectively, where \( I , J \in \mathbf {I}\) are individuals, \( C \) is a concept and \( R \) is a relation (in OWL, an owl:ObjectProperty)²; the assertions above state that \( C \in A _\mathrm {c}( I )\) and \(( I , R , J ) \in A _\mathrm {r}\). DL notation [1] is given on the left side and Terse Triple Language (TTL) notation [4] on the right side; “triple” here refers to the sequence of a subject (e.g. \( I \)), a predicate (e.g. \( C \)) and an object (e.g. \( J \)). The predicate “a” in TTL notation is an abbreviation for rdf:type, referring to the Resource Description Framework (RDF), so that \( I \) a \( C \) indicates that \( C \) is the type of \( I \), i.e. that \( I \) is an individual that instantiates the concept \( C \).

Examples for triples corresponding to conceptual and relational assertions, using OSMO (Sect. 3.3) and VOV (Chap. 4), would be the following rendering of “ex:D is a dipole moment vector and its value is zero:”In TTL notation, ending the first triple with a semicolon implies that the subject (here, ex:D) is reused for the second triple, the full representation of which would therefore be ex:D vov:shares_value_with osmo:ZERO_VECTOR_3D. The DL notation for Expression (3.2) isOperators can be applied to elementary names, yielding composites such as³ where \( C \) and \( C '\) are concepts; \( R \) is a relation; and \( \sqcap \), \( \sqcup \) and \( \lnot \) denote the intersection, union and complement of concepts, respectively, and \({ R }^ - \) denotes the inverse relation to \( R \). For an individual \( I \in \mathbf {I}\), the assertion \( I \, : \, \exists R . C \) entails that there is a \( J \in \mathbf {I}\) with \( J : C '\) and \(( I , J ) \, : \, R \), whether explicitly asserted or not, while \( I \, : \, \forall R . C \) entails \( J : C '\) for all \( J \in \mathbf {I}\) with \(( I , J ) \, : \, R \), whether explicitly asserted or not. The relation \({ C }^ \bullet \) holds whenever its subject (i.e. its first argument) is an individual that instantiates \( C \), i.e. \({ C }^ \bullet \) relates all \( C \) individuals to all individuals; \(^ \bullet { C }\) holds whenever its object (i.e. its second argument) instantiates \( C \), i.e. \(^ \bullet { C }\) relates all individuals to all \( C \) individuals.

Rules can include subsumption and equivalence for concepts and relations⁴ such aswhere \(\mathsf {S}\) is an abbreviation for the relation “is sign for” (viprs:is_sign_for, cf. Sect. 5.​2). Accordingly, Expression (3.6) states that “every simulation workflow is a workflow graph that is a sign for a simulation”, relating the concept of a simulation workflow to those of a workflow graph and a simulation.

Similarly,where \(\mathsf {P}\) denotes “is proper part of” (viprs:is_proper_part_of) states that “if \( I \) is a governing equation in \( J \), then \( I \) is a governing equation, \( J \) is a materials model and \( I \) is a proper part of \( J \).” In TTL notation, this is expressed asOther types of rules concern the disjointness of concepts and algebraic properties of relations such as symmetry, transitivity and reflexivity.

Different types and fragments of DL restrict composites and rules that can be included in a knowledge base in various ways to avoid computational undecidability, and beyond this, to limit the complexity of reasoning tasks [1]. This is also the case for OWL DL, the description logic associated with OWL as well as the DL language profile of OWL2, which is the main standard for ontology engineering [11]. Adherence to the expressivity restrictions of this logic is prescribed by reasoners such as FaCT++ and other widespread tools such as protégé. Relational composites (\( R ~ \sqcap ~ R '\), etc.) cannot be included as such⁵ in OWL DL; however, indirect constructions can often be devised. Chain relations of the type \( R _1 \,\circ \, R _2\), with the usual meaningmay be used for rules, but only under a relatively complex set of constraints; for details, cf. the reference manual on OWL2 language profiles [12] as well as the textbooks mentioned above [1, 4].

The present discussion of ontologies in materials modelling will generally limit itself to the minimum required level of theoretical detail. Section 3.2 introduces the European Virtual Marketplace Framework, constituted by multiple Horizon 2020 projects, and its (comparably small and abstract) ontology EVMPO; on this basis, Sects. 3.3 to 3.5 introduce the modelling service-oriented marketplace-level domain ontologies MACRO, MMTO, OSMO, OTRAS, VICO and VIVO, and Chap. 4 introduces the marketplace-level domain ontologies VISO and VOV that permit the description of simulation codes, materials models and associated quantities such as model parameters and thermodynamic properties or boundary conditions. Section 5 discusses top-level ontologies, which are at the highest level of abstraction (and therefore rather formal and philosophical), the alignment between top-level and domain ontologies, and practical applications from CME/ICME-based process data technology.

To enable semantic interoperability and FAIR data management,⁶ the VIMMP project has developed a system of marketplace-level domain ontologies, cf. Fig. 3.1, supporting the ingest and retrieval of data and metadata at the VIMMP marketplace front end [14]; these ontologies are expressed in OWL2 using TTL notation [4]. Internally, VIMMP uses the marketplace-level domain ontologies as a part of its approach to data management, underlying the interactions with users at its front end [14]. VIMMP contributes to the activities of the EMMC to coordinate these developments with the community and the ecosystem of platforms developed from related projects funded from the Horizon 2020 research and innovation programme.

The European Virtual Marketplace Framework (EVMF) establishes an ecosystem of interoperable environments that builds on previous EMMC standardization efforts, including RoMM [17], the EMMC Translation Case Template [18], the EMMC Translators’ Guide [19] and the MODA metadata standard for simulation workflows [20]. Within this interoperability framework, any provider will have the possibility to choose the depth at which any provided services and tools implement jointly agreed semantics: the deeper the adherence, the deeper the capability to interoperate with other platforms and services. While the EVMF was established by a collaboration between the VIMMP and MarketPlace consortia in coordination with the EMMC, it is open to participation by all developers, providers, translators and end users of services in materials modelling. The EVMF is entirely based on transparent and openly accessible specifications, relying on the EMMO at the top level [15, 16]; the present ontologies are accordingly released as free software under the GNU Lesser General Public License (LGPL). By creating an open framework on the basis of community-governed interoperability standards, a variety of projects, several of which (including VIMMP, MarketPlace and OntoCommons) are funded from Horizon 2020—or prospectively may be funded from the Horizon Europe programme in the future, contribute to a system of platforms and infrastructures that will support the uptake of materials modelling solutions by industrial research and development practice.

The European Virtual Marketplace Ontology (EVMPO) was developed by the VIMMP, MarketPlace and EMMC-CSA projects as a common point of departure for the standardization of service-oriented semantics, with a focus on digital marketplace platforms in materials modelling.⁷ By defining 11 fundamental paradigmatic categories, which correspond to irreducible terms that are constitutive to the paradigm underlying materials modelling marketplaces, the EVMPO provides a basic structure for the development of marketplace-level domain ontologies. The fundamental paradigmatic categories are defined as follows:

These categories need not be disjoint, e.g. evmpo:material and evmpo:product overlap, since a material can be manufactured with the intent of selling it as a commodity, by which it becomes a good, and hence a product.

The common superclass of the paradigmatic categories is evmpo:paradigma tic_entity. Below the fundamental level, the EVMPO also includes non-fundamental entites as subclasses, e.g. evmpo:simulation as a subclass of evmpo:process and evmpo:service as a subclass of evmpo:product. Terms which are not closely related to the materials modelling marketplace paradigm itself, but may occur within a related knowledge base, are defined to be non-paradigmatic. For this purpose, the EVMPO includes evmpo:annotation as a twelfth, non-paradigmatic fundamental category; the EVMPO top relation, parent to both evmpo:paradigmatic_entity and evmpo:annotation, is evmpo:marketplace_ related_entity. The relation evmpo:has_ annotation can connect any marketplace-related entity to an annotation. Below this, 12 subproperties are defined, corresponding to the fundamental categories, i.e. evmpo:has_assessment_annotation pointing to annotations of an assessment, etc., and evmpo:has_meta_annotation for annotations of an annotation.

Consistency with the EVMPO, and by implication consistency with the EMMO, is a requirement for all components and infrastructures that aim at interoperating within the EVMF. This design ensures that while EVMF-interoperable infrastructures need to agree on the definition of the most important entities, any platform retains the option to extend its own semantic base as required. To remain interoperable within the EVMF, any additional concepts need to be subsumed under fundamental categories from the EVMPO; cf. Sect. 5.​4 for a summary on how the EVMPO and the marketplace-level domain ontologies are aligned with the EMMO.

The Marketplace-Accessible Computational Resource Ontology (MACRO) deals with data and hardware-related resources and infrastructures [14]. In particular, MACRO contains classes and individuals representing file formats expected to occur on the VIMMP marketplace platform,⁸ many of which are obtained by connecting to the EDAM ontology [25]. High-level concepts from MACRO and their relation to EVMPO concepts (evmpo:agent, evmpo:annotation, etc.) are shown in Fig. 3.2. Complementing MACRO, the PaaSPort ontology [26] can be used to describe Platforms as a Service (PaaS).

The Ontology for Simulation, Modelling and Optimization (OSMO) was developed as the ontology version of MODA [20], making workflow representations machine processable,⁹ semantically interoperable with community platforms and amenable to automated reasoning [27]. Where a physics-based modelling approach is followed, Physical Equations (PEs) are employed jointly with Materials Relations (MRs) that parameterize and complement the PEs, e.g. for a particular substance. The combination of PEs and MRs is referred to as the system of governing equations; on the basis of RoMM [17], common PE types are subdivided into four groups according to their granularity level: electronic, atomistic, mesoscopic and continuum [17, 20, 27]. In MODA graphs, there are four types of vertices (corresponding to Sects. 3.1–3.4 of the MODA form), which are in OSMO referred to as sections (osmo:section):

For each section, the MODA standard contains a list of text fields, which are here referred to as section aspects, through which detailed information can be provided. In OSMO, the detailed description of section individuals by section aspects and their textual, numerical or object content is closely aligned with the corresponding textual and numerical entries from MODA; by using the relation osmo:has_aspect_object_content, it becomes possible to point to content provided anywhere on the semantic web, including individuals and classes from the VIMMP marketplace-level domain ontologies. Providing a common semantic basis for workflows, cf. Fig. 3.3, OSMO can be employed to consistently integrate data provenance descriptions for materials modelling data from diverse sources [27].

Selected concepts from MACRO and OSMO:

Selected relations from MACRO and OSMO:Logical Data Transfer (LDT) notation [27] builds on the workflow graph representations from MODA [20]; it clarifies how exactly the use case, model, solver and processor entities relate to each other, e.g. where iterations and user interactions take place and how variables are exchanged. In LDT notation, cf. Fig. 3.4, ellipses represent sections; green circles and green arrows represent coupling and linking of elements, dependencies concerning the order of execution and aspects related to concurrency and synchronization. Blue arrows point from use cases and models to the part of the workflow to which these elements apply. Triangles are logical resources, describing how information is transferred between the sections, pointing from the source to the destination; if a triangle is filled, this denotes that a user interaction can occur.

The visualization elements from LDT notation have a direct correspondence with concepts and relations from OSMO [27], e.g. coupling and linking symbolized by green arrows correspond to the relations osmo:is_coupled_with and osmo:is_linked_to, and flow of information, represented by lines between triangles ellipses, corresponds to osmo:logical_access entities that relate to a logical resource by osmo:has_resource and to a section by osmo:has_access_ point, cf. Fig. 3.3. The LDT representation, therefore, corresponds to an enriched version of a MODA graph; by removing logical resources, details on iterations (represented in OSMO by relations between “virtual graphs” and “concrete graphs”), etc., a conventional MODA description can be obtained. Similarly, the usual human-readable MODA forms can be obtained by reducing all OSMO aspects to an elementary numerical or textual description.

The Materials Modelling Translation Ontology (MMTO) deals with the process of “translating” a problem from engineering practice to modelling and simulation—and from the simulation outcome back to an actionable decision [28]. The role of the materials modelling translator is specified in detail by the EMMC Translators’ Guide (ETG), cf. Hristova et al. [19]; accordingly, a translator needs to be able to bridge the “language gap” between industrial end users and academic model providers and software owners. The work of a translator aims at delivering not just modelling results, but a solution for an industrial engineering problem, understood more holistically. In business administration and management, such problems are usually addressed in terms of Key Performance Indicators (KPIs), where a KPI is understood to be a descriptor (indicator) underlying process and product opimization, ultimately characterizing some feature or property that can serve as a selling argument. The underlying orientation towards marketing reflects a point of view corresponding to organizational roles that are comparably distant from research and development. In scenarios that arise in such a context, it necessarily appears to be most crucial to address concerns that are immediately relevant to Business-to-Administration (B2A), Business-to-Business (B2B) and Business-to-Customer (B2C) relations [30].

In the MMTO,¹⁰ which predominantly targets communities of users in engineering practice (rather than industrial business administration), the concept mmto:key_performance_indicator is reserved for scalar quantities that are relevant for characterizing, modelling or optimizing processes and products by CME/ICME methods. On this basis, two major distinctions are to be made from the point of view of a materials modelling translator [28]:

The distinction between subjective and objective KPIs is similar to that between Critical-to-Customer (CTC) and Critical-to-Quality (CTQ) measures [31‐33]. The formulation given above, however, is more closely related to concepts from the EMMO. Due to the underlying approach to semiotics [15, 16, 23, 24], it is straightforward in the EMMO to categorize signs by the way in which their interpretation depends on the subjective impression of an interpreter or observer: in particular, the same distinction between “subjective properties” and “objective properties” is made in the EMMO; accordingly, the present approach supports a straightforward alignment of the MMTO with the EMMO and the approach to interoperability guided by the EMMC and implemented within VIMMP.

An instance of the materials modelling translation process, some agreed features of which are codified by the ETG and the EMMC Translation Case Template (ETCT) [18], is referred to as a Translation Case (TC). According to these specifications, a materials modelling translation project begins with exploring and understanding the Business Case (BC) and the Industrial Case (IC), or multiple relevant BCs and/or ICs, which characterize socioeconomic objectives and boundary conditions [28]. Universals for BCs (mmto:business_case), ICs (mmto:industrial_case) and TCs (mmto:translation_ case) are defined to be subclasses of (osmo:application_ case), by which they can be dealt with in a similar way as the sections from OSMO; the class hierarchy of the section branch of the MMTO and OSMO is visualized in Fig. 3.5. In this way, the MMTO generalizes this approach from MODA to also cover the translation-related concepts from the ETCT and the ETG [18, 19, 28]. The TC aspects directly correspond to the ETCT text fields [18], except that as an ontology, the MMTO permits the incorporation of semantically characterized content from the semantic web. A business case can represent any purely economic consideration or an optimization problem at the management level, whereas an IC refers to an industrial engineering problem or an optimization problem at the technical or research and development level. Within the translation process, a suitable approach based on modelling and simulation is identified and carried out; subsequently, the outcome is translated back to support an actionable decision at the BC and IC levels. Thus, the MMTO is also a tool for representing exchange of information during translation processes (e.g. employing KPIs as logical variables), which may be represented by workflow graphs following the MODA and/or LDT workflow notations [20, 27].

The VIMMP Validation Ontology (VIVO) categorizes assessments (i.e. evaluations) of computational resource requirements and benchmarking as well as customer feedback on various kinds of entities,¹¹ which can be provided subsequent to transactions at the VIMMP marketplace [14]. Thereby, users support each other mututally, evaluating contents and providers, while the marketplace platform itself remains neutral and equally open and accessible to everybody. A matrix with subclasses of evmpo:assessment, indicating how marketplace users can evaluate what sort of objects, is shown in Fig. 3.11. Rows correspond to classes of entities that are subjected to an assessment such that a vivo:data_infrastructure_assessment is an evmpo:assessment that vivo:evaluates an evmpo:data_infrastructure, and a vivo:meta_assessment is an evmpo:assessment that vivo:evaluates an evmpo:assessment. Columns correspond to different ways in which entities can be evaluated, e.g. by reporting an observation on the relative quantitative accuracy (vivo:relative_accuracy_as sessment) or by issuing a recommendation (evmpo:endorsement_assessment). Not all theoretically conceivable combinations are allowed—e.g. memory requirements can be stated for software, but not for projects. Using VIVO, in particular, error analyses and estimates can be attributed to models, simulation workflows and to data items obtained from repositories or other platforms (Fig. 3.6).

Selected concepts from the MMTO and from VIVO:

Selected relations from the MMTO and from VIVO:

The Ontology for Training Services (OTRAS) can be employed to annotate any training resources in the field of materials modelling [14], i.e. ¹² both training documents (such as manuals or videos) and training events (lectures, seminars, summer schools, workshops, etc.). In OTRAS, such resources are referred to as carriers. For information on training courses, syllabi, etc., the Course Curriculum and Syllabus Ontology (CCSO) is employed [35]. Furthermore, the IAO is applied to documents [22], in accordance with the EVMPO. The high-level structure of OTRAS is shown in Fig. 3.7. While the CCSO covers much of the required domain at an abstract level, a dedicated standardization effort is required to characterize the semantic space with respect to training contents specifically in the field of materials modelling. For this purpose, OTRAS includes a formalism by which learning outcomes and expert competencies can be described and a taxonomy of topics in materials modelling. Concerning didactics, the normal form of a learning outcome description to be used with OTRAS is given as follows:Therein, \( \sigma _1\) is the course or training material (carrier) for which a learning outcome is stated. The individuals \( \sigma _2\), \( \sigma _3\), \( \sigma _4\) and \( \sigma _5\) are specifiers (otras:spe cifier) of the learning outcome:

The operator specifier \( \sigma _2\) indicates what sort of activity is enabled by possessing a certain competency. Learning outcomes in course syllabi are typically formulated concisely, e.g. “the students will be able to apply statistical mechanics to problems from fluid phase thermodynamics.” In this example, the operator is expressed by the predicate “apply.” In the interest of the legibility of a syllabus (and the work involved in writing it), a precise definition of the meaning of the operator specifier is usually not provided, and the interpretation is left to the intuition of the reader.

In the interest of platform and institutional interoperability between training providers, it can nonetheless be helpful to reach an agreement on a more precise specification of the semantics associated with a learning outcome formulation. This has aspects of both semantic and pragmatic interoperabilities, such as where multiple instructors are expected to abide by the same syllabus and/or conduct exams that confirm the success of the learning effort at a specified level. It may also support the automated rendition of a syllabus in multiple languages. For this task, OTRAS relies on a catalogue of operators disseminated by the German Kultusministerkonferenz (KMK), facilitating the specification of learning outcomes in the natural sciences in a consistent way [36]. In OTRAS, each operator has a three-digit topic code (e.g. 235) and otras:is_expressed_by a concise predicate (e.g. “apply”), while otras:is_defined_by gives a more detailed explanation of its meaning; in the given case, “use a known idea, equation, principle, theory or law in a new situation” [36]. The KMK operators roughly correspond to elementary (operator codes 1xx), intermediate (2xx) and advanced (3xx) levels of learning; they are complemented here by additional operator individuals (operator codes 4xx) that are expected to be more adequate for expressing certain competencies that are typically attributed to expert personnel.

The operand specifier \( \sigma _3\) may be taken from a taxonomy of materials modelling topics (subclasses of otras:mm_topic) that are included in OTRAS. The first hierarchy level (and part of the second level) of this taxonomy is shown in Fig. 3.7. This is widely used within VIMMP beyond the specification of competencies, e.g. to sort and retrieve documents by identifying the addressed topics and to indicate relevant areas of interest and fields of knowledge to be used to matchmaking by the translation router [14] app of the VIMMP marketplace platform. OTRAS also permits the specification of topics via CCS, a taxonomy developed by the Association for Computing Machinery [37], and PhySH, developed by the American Physical Society [38]. Syllabi can be associated with learning outcomes by means of the relation otras:aims_to \( \sqsubseteq \) ccso:aimsToLO. If a competency is asserted as such, irrespective of how it has been acquired, \( \sigma _1\) can be absent, in particular, wherever the relation vico:has_competency from VICO, see below, is used to characterize the background of an evmpo:expert.

The VIMMP Communication Ontology (VICO) covers metadata on messages exchanged at the digital marketplace platform and participants that interact at an EVMF-interoperable platform [14]. Through the LCC ontology, VICO incorporates the ISO 3166 standard for referring to countries and regions [39]. Types of interlocutors (subclasses of vico:interlocutor) are referred to—in accordance with the usual EMMC nomenclature—as consultants, data providers, end users, manufacturers, model providers, software owners, training providers, translators and guests.¹³ The concept vico:interlocutor_group is instantiated by individuals associated with each of these groups, e.g. vico:software_owner individuals belong to the vico:interlocutor_group individual vico:IG_SOFT WARE_OWNER. The communication branch of the class hierarchy is visualized in Fig. 3.8.

Selected concepts from OTRAS and VICO:

Selected relations from OTRAS and VICO: