Marketplace-Level Domain Ontologies

To enable semantic interoperability with external services and platforms, the Virtual Materials Marketplace (VIMMP) project has developed a system of marketplace-level domain ontologies, supporting the ingest and retrieval of data and metadata at the VIMMP marketplace front end; these ontologies are expressed in OWL2 using TTL notation [1]. Internally, VIMMP uses the marketplace-level domain ontologies as a part of its approach to data management, underlying the interactions with users. This chapter and the subsequent two chapters present ontologies from the VIMMP project and their relation to other work, including other ontologies.

names, A c is a function representing conceptual assertions, such that an individual name I ∈ I is mapped to a set of concepts A c (I ) and A r ⊆ I × R × I is a set of relational assertions. The function H maps individuals I ∈ I to sets of elementary datatype property assertions H (I ) = {η 1 , . . . , η n } where 1 each elementary datatype property assertion η i = (k i , v i ) consists of a textual key k i ∈ and a textual or numerical value v i ∈ R ∪ , with representing the employed alphabet and the free monoid over .
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 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 IRI respectively, where I, J ∈ I are individuals, C is a concept and R is a relation (in OWL, an owl:ObjectProperty) 2 ; the assertions above state that C ∈ A c (I ) and (I, R, J ) ∈ A 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:" ex:D a vov:electric_dipole_moment; vov:shares_value_with osmo:ZERO_VECTOR_3D.
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.4) where C and C are concepts; R is a relation; and , and ¬ denote the intersection, union and complement of concepts, respectively, and R − denotes the inverse relation to R. For an individual I ∈ I, the assertion I : ∃R.C entails that there is a J ∈ I with J :C and (I, J ) : R, whether explicitly asserted or not, while I : ∀R.C entails J :C for all J ∈ I with (I, J ) : R, whether explicitly asserted or not. The relation C • holds whenever its subject (i.e. its first argument) is an individual that instantiates C, i.e. C • relates all C individuals to all individuals; • C holds whenever its object (i.e. its second argument) instantiates C, i.e. • C relates all individuals to all C individuals. Rules can include subsumption and equivalence for concepts and relations 4 3 In the last two rows, for C • and • C, the TTL version is an approximation, since in OWL, the use of domain and range composites is restricted to what would best be represented formally as a subsumption rule, cf. Expression (3.5). The subsumption R C • then becomes R rdfs:domain C, and R • C becomes R rdfs:range C. However, it is impossible to use this construction for any other purpose, e.g. to state R ≡ C • . 4 The use of the article "a" is a possible source of misunderstandings between communities due to the way in which it is treated by two different notations, namely, TTL, which is used for the VIMMP ontologies and throughout this book, as opposed to the Open Biomedical Ontologies (OBO) format [9]. TTL uses a for instantiation (rdfs:type) such as in macro:VIMMP_MARKETPLACE a macro:digital_marketplace, signifying "the VIMMP Marketplace is a digital marketplace." OBO format denotes conceptual subsumption (rdfs:subClassOf) by the keyword is_a, such as in id: macro:digital_marketplace […] is_a: macro:bidirectional_channel, signifying "every digital marketplace is a bidirectional channel," since macro:digital_marketplace macro:bidirectional_channel.
Motivated by that standard, the OWLViz tool [10] automatically labels all arrows with "is-a" when visualizing a taxonomy. where 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, osmo:is_governing_equation_in where 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 as Other 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 R , etc.) cannot be included as such 5 in OWL DL; however, indirect constructions can often be devised. Chain relations of the type R 1 • R 2 , with the usual meaning may 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.

European Virtual Marketplace Framework
To enable semantic interoperability and FAIR data management, 6 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 transpar-  [14]. Triangle: EMMO, the employed toplevel ontology [15,16], used here in combination with VIPRS (cf. Sect. 5.2). An arrow signifies that an ontology refers to concepts or relations from another ontology ent 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. 7 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: 1. evmpo:assessment: a proposition on the accuracy or performance of an entity or an a expression of trust in an entity. Corresponding domain ontology: VIVO, cf. Sect. 3.4. 2. evmpo:calendar_event: a meeting or activity which is scheduled or can be scheduled; this is defined to be equivalent with Vevent from the W3C iCalendar ontology (iCal) with time zones as datatypes, cf. Connolly and Miller [21]. Corresponding domain ontology: OTRAS, cf. Sect. 3.5. 3. evmpo:communication: any message (or an attachment or part of a message) that is communicated. Corresponding domain ontology: VICO, cf. Sect. 3.5. 4. evmpo:information_content_entity: a journal article, a dataset or a graph. This concept is defined to be equivalent with IAO_0000030, labelled "information content entity" through rdfs:label, from the Information Artifact Ontology (IAO), cf. Ceusters [22]. Corresponding domain ontologies: OTRAS and VISO, cf. Sect. 3.5 and Chap. 4. 5. evmpo:infrastructure: infrastructure of an EVMF-interoperable platform (e.g. related to data, hardware and software). Corresponding domain ontologies: MACRO and VISO, cf. Sect. 3.3 and Chap. 4. 6. evmpo:interpreter: this concept is defined to be the same as emmo-semiotics:Interpreter from the nominalist revision of Peirce's semiotics, based on the semiotic triad sign-object-interpretant, as included in the EMMO [15,16]; therein, for any given triad, the interpreter is the entity that carries out the semiosis, taking the sign (a representamen) as an input and producing the interpretant (another representamen) as an output [16,23,24]. Therefore, any potential agent or communicating entity at EVMF-interoperable infrastructures is an interpreter. Corresponding domain ontology: VICO, cf. Sect. 3.5. 7. evmpo:material: an amount of a physical substance (or mixture of substances) that is part of a more comprehensive real-world object; this concept is defined to be the same as emmo-physicalistic:Material from the EMMO [15,16]. Corresponding domain ontologies: OSMO and VIVO, cf. Sects. 3.3 and 3.4. 8. evmpo:model: a sign that represents a physical object or process by direct similitude and/or within a mathematical framework; this concept is defined to be the same as emmo-models:Model from the EMMO [15,16] 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.

Modelling, Simulation and Computational Resources
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, 8 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  [10]; arrows labelled "is-a" denote subsumption ( ) machine processable, 9 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): 1. Use case (osmo:use_case)-MODA Sect. 3.1. The physical system to be simulated, including information on the given and desired physical properties. In OSMO, the application case (osmo:application_case) is introduced as a more general concept, permitting the description of applications of the simulation outcome that go beyond the immediate simulation scenario [28]. 2. Model-MODA Sect. 3.2. The system of GEs, with one or multiple PEs and MRs; here, this is referred to as a materials model (osmo:materials_model). Following the EMMO approach, implemented by the EVMPO, a model (evmpo: model) is conceptualized, substantially more broadly, as an icon (representamen) providing a simplified representation of a physical object that is suitable for predicting its behaviour [15,16].
3. Solver (osmo:solver)-MODA Sect. 3.3. The numerical solution of the modeldefined with a strict limitation to considering exactly the variables that occur in the GEs explicitly (and nothing else). 4. Processor (osmo:processor)-MODA Sect. 3.4. Any computational operation beyond the above; in particular, this includes and processing activity done by a simulation code that goes beyond the immediate solution of underlying governing equations, e.g. to produce aggregated output. MODA is-strictly speaking-limited to postprocessors. Depending on the role in the simulation workflow, OSMO distinguishes between preprocessor, postprocessor, coupled (i.e. synchronous) and data processor elements.
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: • macro:channel: a data infrastructure which, in its evolution as a process, contains communication events (semioses).   [27,29] • macro:provides_access_to points to a service that can be accessed through the given infrastructure. Domain: macro:infrastructure; range: macro:infrastructure_ service.
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 rela-tions 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.

Engineering Applications and Validation
The Materials Modelling Translation Ontology (MMTO) deals with the process of "translating" a problem from engineering practice to modelling and simulationand 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, 10 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][32][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, 11 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_assessment) 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: • vivo:assertion: a claim or proposition (e.g. as part of an assessment). Subclasses include vivo:accuracy_assertion, evmpo:material_property_information and vivo: requirement_assertion.
• vivo:certificate: a validation statement by which an assessment is stated.
• vivo:computational_time_requirement: a requirement assessment concerning the computational (CPU time) requirements of a simulation workflow.
• vivo:material_property_information: an assertion referring to a material property.
• mmto:objective_kpi: a KPI that can be determined by a standardized process, the outcome of which is expected not to depend on the interpreter. • vivo:relative_deviation: an accuracy assertion in which the relative magnitude of an error or uncertainty is given, normalized by the absolute magnitude of the value to which the assertion refers. Analogous: vivo:absolute_deviation. • mmto:translation_case: an application case that can be described as specified by the ETCT [18]. • vivo:unit: a unit that can be expressed as a scalar multiple of an algebraic combination of SI units. This concept is the same as emmo-metrology:ReferenceUnit and qudt:Unit [15,16,34].
Selected relations from the MMTO and from VIVO: • mmto:considers_business_case points to a business case considered within translation stage no. 1, "good understanding of the business case," as specified in the ETG [19]. Domain: mmto:translation_step_bc; range: mmto:business_case. Analogous: mmto:considers_industrial_case, corresponding to the translation stage no. 2, "good understanding of the industrial case" [19].
• mmto:has_tca_pe_type points to a TC aspect (as included in the ETCT) containing information on PE types employed during modelling. Domain: mmto:translation_case; range: mmto:tca_pe_type. • vivo:has_unit points to the unit in which any numerical contents of an assertion are given. Domain: vivo:assertion; range: vivo:unit. • vivo:is_quantity_kind points to the physical property characterization following QUDT [34]. Domain: vivo:assertion; range: qudt:QuantityKind. • vivo:states_assessment points to an assessment contained within a certificate.

Training and Communication
The Ontology for Training Services (OTRAS) can be employed to annotate any training resources in the field of materials modelling [14], i.e. 12 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:

Fig. 3.7
Fragment of the OTRAS class hierarchy, version 1.0.5. The OWLViz protégé plugin was used to visualize the ontology [10]; solid lines and arrows labelled "is-a" denote subsumption ( ). Here, ICALTZD refers to the iCal ontology with time zones as datatypes [21] "Upon successfully completing σ 1 , participants can σ 2 with respect to σ 3 by doing σ 4 ; for example, σ 5 . (3.9) Therein, σ 1 is the course or training material (carrier) for which a learning outcome is stated. The individuals σ 2 , σ 3 , σ 4 and σ 5 are specifiers (otras:specifier) of the learning outcome: • σ 2 specifies the operator of the learning outcome (concept otras:operator_specifier); a catalogue of operators with three-digit operator codes is included. • σ 3 specifies the operand of the learning outcome (concept otras:operand_specifier); the operand can be formulated in terms of one or multiple topics, for which fourdigit topic codes are given in OTRAS. • σ 4 specifies the implementation (concept otras:implementation_specifier), describing how the competency is carried out in practice (e.g. "by writing C++ codes" or "by carrying out appropriate series of MD simulations"); this specifier is optional. • σ 5 specifies an example (concept otras:example_specifier), illustrating how the competency might be applied to a particular special case (e.g. "if asked to develop a molecular model for caffeine, one might choose to parameterize a rigid coarsegrained model consisting of multiple Mie interaction sites"). This specifier is also optional.
The operator specifier σ 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), inter-mediate (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 σ 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 ccso:aimsToLO. If a competency is asserted as such, irrespective of how it has been acquired, σ 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. 13 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_SOFTWARE_OWNER. The communication branch of the class hierarchy is visualized in Fig. 3.8.
Selected concepts from OTRAS and VICO: • vico:academic_title: a titular rank that corresponds to an academic degree.
• otras:focus: a studied object, topic, training objective or an aspect or constitutive part thereof. Subclasses include otras:learning_outcome, otras:operator_level, otras:specifier and otras:topic. • vico:interlocutor_tag: a descriptor that specifies properties of an interlocutor which may co-determine ability/suitability for trading with certain partners at a digital marketplace-indicating the country of residence/registration, whether the described interlocutor is engaged in military or nuclear research, etc. • vico:message: a stand-alone communication (rather than an appendix).
• otras:mm_topic (materials modelling topic): a topic related to the subject area of materials modelling, understood broadly. • vico:has_author points to an agent that has issued a communication. Domain: evmpo:communication; range: evmpo:agent.
• otras:has_offered_course points to a course that is offered as part of the activities carried out as a training service. Domain: otras:training_service; range: otras:course.
• vico:is_certifier_of points to a certificate for which a certifier is (co-)responsible, having either issued the certificate or formally approved of its content. Domain: vico:certifier; range: vivo:certificate. • otras:is_narrower_than; (:A is narrower than :B) ⇐⇒ :A and :B are topics such that if :A is a sign for an object, :B is also a sign for that object. This relation is defined to be a subproperty of skos:broader, cf. Isaac and Summers [40]; n.b., in SKOS, the relation is defined the other way around, i.e. (:A broader :B) ⇐⇒ :B is broader than :A. Domain: otras:topic; range: otras:topic. Analogous: otras:is_broader_than skos:narrower.
• otras:is_part_of_course points to the course to which the given training unit belongs. Domain: otras:training_unit; range: otras:course.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.