5. Applications of the Metadata Standards

The division of a knowledge base \(\mathcal {K}= (\mathcal {T}, \mathcal {A})\) into an ontology \(\mathcal {T}\) and a scenario \(\mathcal {A}\), as introduced in Sect. 3.​1, is not only formal, but also motivated by practice. Fulfilling the role of a schema, an ontology needs to be ingested into a data infrastructure, or implemented by it, only once; frequent updates are undesirable, since they require a reannotation of data. For the scenarios handled by digital platforms, obversely, data retrieval and ingest are routine operations, and so are updates, since they need to occur whenever the represented reality changes, e.g. a new service is offered or a new user is registered. Challenges related to I/O (or ingest and retrieval) mainly concern the scenarios, not the ontologies, and their standardized representation by files, streams or protocols is the main vehicle for syntactic interoperability.

Since the IRIs of resources on the semantic web can point to each other as freely as the URLs of sites on the World Wide Web, i.e. in a graph-like way, it is natural to visualize scenarios by graphs. These representations are referred to as knowledge graphs. In Sect. 3.​1, a scenario was defined as a tuple \(\mathcal {A}= (\mathbf {I}, A _\mathrm {c}, A _\mathrm {r}, H )\) with individual names \(\mathbf {I}\), conceptual assertions \( A _\mathrm {c}\), relational assertions \( A _\mathrm {r}\) and elementary datatype property assertions \( H \). The corresponding knowledge graph is a labelled graph \( G = (\mathbf {I}, E , \varLambda _\mathrm {v}, \varLambda _\mathrm {e})\) where the vertices are given by \(\mathbf {I}\) and the edges byVertices are labelled according to the function \( \varLambda _\mathrm {v}: \mathbf {I}\rightarrow 2^{\mathbf {C}\cup \mathbb {R}\cup \Sigma ^ \star }\) that maps¹ each individual name \( I \in \mathbf {I}\) to a set of labelswhile the edge labelling function \( \varLambda _\mathrm {e}: E \rightarrow 2^\mathbf {R}\) assigns the corresponding relation namesto an edge \(( I , J ) \in E \).

An example is given in Fig. 5.1; this knowledge graph might be read as follows: “There is a course labelled ‘CECAM SWiMM 2021’. This course has a syllabus, in which information is given on an instructor who is labelled ‘Jean-Pierre’ and ‘Minier’. The course has a training unit labelled ‘Salome/YACS’ for which event information is given,” etc. While this particular representation does not contain IRIs of datatype properties (to match the definition of the knowledge graph given above), it could easily be modified to incorporate this information as well, e.g. by using property graphs following Abad Navarro et al. [1]. The individual name IRIs are not shown in the figure to simplify the visualization; however, they are included in the definition of the knowledge graph.

The technical implementation of semantic interoperability requires a syntactic representation by which information can be extracted from (or ingested into) a digital platform including a knowledge base; cf. Fig. 5.2 for a typical multi-tier design approach. For this purpose, subject-predicate-object triples can be employed, e.g. in TTL format (cf. Sect. 3.​1), by which the scenario from Fig. 5.1 is rendered as follows:

Above, @prefix statements introduce the abbreviations employed for IRI prefixes, e.g. the datatype property https://w3id.org/ccso/ccso#csName is abbreviated by ccso:csName. The elementary datatypes follow the conventions for XML schemas, cf. Chapter 2.

TTL notation has the advantage that it can be employed consistently for the whole knowledge base, including both the ontology and the scenario. For many applications, however, this is more problematic than beneficial, because the expressive power of OWL and its various serializations (including TTL) goes far beyond what is needed to represent objects and their properties; consequently, it is harder to parse and to process. Moreover, it cannot be ensured at the syntax level that only information on the scenario is included. Instead, JavaScript Object Notation (JSON) is often preferred, particularly in its JSON Linked Data (JSON-LD) variety which was specifically designed for the purpose of exchanging semantically characterized information on objects and their relations. In JSON-LD format, the example scenario becomes

There, every pair of curly braces encloses the description of an object (except the value of @context, which includes the IRI prefix definitions), given as a sequence of key-value pairs. The individual names are provided as values corresponding to the key @id, while the instantiated concept names are indicated by the key @type. The other keys are relation names, and the associated values are the third elements of the respective triples, as can be seen from the direct correspondence between the TTL and JSON-LD examples given above.

Additionally, domain-specific solutions on the basis of the hierarchical data format HDF5 facilitate combining a greater volume of data, including binary data, with the corresponding semantic annotation [3], e.g. the H5MD format [4] for semantically enriched data in molecular modelling and simulation. The VIMMP marketplace platform API and its Zontal Space back end permit handling annotated digital objects through the HDF5-based Allotrope Data Format (ADF) [5‐7].

For a fundamental philosophical underpinning, the European Materials and Modelling Ontology [8, 9] relies on a combination of physicalist mereotopology following Varzi [10] and a nominalist reinterpretation of Peirce’s semiotics [11]. Therein, physicalist mereotopology primarily addresses the description of materials, which is extended by nominalist semiotics to describe modelling, simulation and experiments. For a discussion of nominalism, cf. Lewis [12], more specific implications of the approach of the EMMO on representing modelling and simulation of physical systems have been discussed elsewhere [13].

To facilitate the top-level ontology alignment of the VIMMP ontologies, a module with a scaled-down EMMO in TTL format is included, EMMO version 1 simplified (EMMO1s), which at the present stage (version 1.0.4) is based on EMMO version 1.0.0 alpha 2 (April 2020). EMMO1s provides user-friendly IRIs for EMMO concepts,² retaining the labels, e.g. the IRI of the EMMO concept with rdfs:label “Semiosis” is given in the original EMMO as emmo-semiotics:EMMO_008fd3b2_ 4013_451f_8827_52bceab11841. For these entities, EMMO1s specifies aliases that can be accessed directly through the label, such as emmo1s:Semiosis. In the interest of notational clarity, to indicate the origin of the concept definitions and the respective EMMO modules, these entities will here be denoted by the EMMO prefix followed by the EMMO1s suffix, e.g. by emmo-semiotics:Semiosis, even though internally, for VIMMP, it is actually emmo1s:Semiosis.

The VIMMP Primitives (VIPRS) module amplifies the ways in which the EMMO-based top-level semantic interoperability architecture can be applied to the relations characterizing metadata from the VIMMP marketplace-level domain ontologies.³ With this aim, VIPRS extends the EMMO system of top-level relations by three features:

While the EMMO can be used to describe materials and models as such, statements on necessity and possibility anchored in modal logic are metaontological, i.e. beyond the ontology, from the point of view of the EMMO [9], e.g. within the framework of the EMMO, an event can be described as a physical process, but the statement that “this process can possibly occur, but it will not necessarily occur” cannot be expressed. The present domain ontologies, however, make ample use of relations that are ultimately modal to specify capabilities (it is possible that :X will be used to do :Y) or requirements (if is necessary that if :X occurs, :Y also occurs).

To provide a top-level structure for modal relations, VIPRS includes modal squares of opposition,⁴ cf. Fig. 5.3, by which the presence of individuals in a knowledge base can be associated with statements on whether their occurrence is possible, necessary, factual or fictional [16]. The modal operators can be given a variety of interpretations, depending on the precise use that is made of the ideas of necessity (\( \Box \)) and possibility (\( \Diamond \)), respectively [17]; similarly, the definition of “occurrence” depends on the use that is made of the ontology and may depend on context—VIPRS accepts this ambiguity in order to be applicable to diverse types of knowledge bases and infrastructures. The term “to occur” in , “:X may occur,” and similar, is employed to refer to the (possible or necessary) appearance of an individual :X in a certain type of environment, e.g. as an element of a valid simulation workflow. On this basis, relations concerning the possible or necessary co-occurrence of multiple individuals are defined, e.g. viprs:n_loc_or_rnoc (and others following the same pattern, cf. Fig. 5.3), where the IRI is to be read as “necessarily, the left occurs or the right does not occur”cf. Fig. 5.3. Thereby, “occurrence” (by appearing in a certain type of environment) is not the same as “existence,” i.e. presence in a knowledge base. It is in this sense that VIPRS can be employed as an implementation of possible-world semantics, Kripke semantics and/or ontological Meinongianism [16], even though it does not necessarily presuppose the use of any of these paradigms. The conceptualization relationwith \( K _ I \,\mathsf {C}\, I \) to be read as “\( K _ I \) conceptualizes \( I \),” relates a more (or equally⁵) generic individual to a more (or equally) specific one; it is used to introduce a step of abstraction into the modal co-occurrence relations, e.g. “necessarily, the left occurs conceptual-or the right does not occur”Relations from the EMMO are mereological (or, more properly, mereotopological [10, 18, 19]), represented here at the highest level by proper parthoodand semiotic, represented at the highest level by the sign-to-object reference relation⁶ cf. Expressions (3.​6) and (3.​7). To facilitate ontology alignment, which is discussed in Sects. 5.3 and 5.4, VIPRS also contains mereosemiotic chain products of these fundamental relations, i.e. elements of the free semigroup \(\mathbf {R}_\mathrm {ms}^+\) over \(\mathbf {R}_\mathrm {ms}= \{\mathsf {P}, \mathsf {S}, {\mathsf {P}}^ - , {\mathsf {S}}^ - \}\), with the product defined by concatenation. The mereosemiotic relations for which there is an explicit definition in VIPRS are limited to \(\mathbf {R}_\mathrm {ms}\, \cup \, \mathbf {R}_\mathrm {ms}^2 \, \cup \, \mathbf {R}_\mathrm {ms}^3\), i.e. relations generated by a sequence of up to three fundamental relations which are not redundant (\(\mathsf {P}\circ \,\mathsf {P}\) and its inverse),⁷ complete (or almost complete), i.e. relating everything to everything, except possibly for a single “universe” entity,⁸ as it is the case for \(\mathsf {P}\circ {\mathsf {P}}^ - \), or consist of three elements from the same category, e.g. \({\mathsf {S}}^ - \circ \,\mathsf {S}\,\circ \,{\mathsf {S}}^ - \) is excluded, because all three constituent elements are semiotic. In the nomenclature employed by VIPRS, the IRI elements ip, hp, is and hs stand for “is proper part,” “has proper part,” “is sign” and “has sign,” respectively. Accordingly, the binary chain relations includewhile the ternary chain relations includeWith minor exceptions, datatype properties (owl:DatatypeProperty) are absent from the EMMO [9]; by the domain ontologies, however, datatype properties are amply employed to associate objects with textual (xs:string), numerical (xs:decimal) attributes and xs:boolean flags. Figure 5.4 visualizes the hierarchy of top-level datatype properties introduced in VIPRS. At the highest level, VIPRS categorizes datatype properties according to their role:

At the second level, the datatypes are distinguished (string, decimal or Boolean). Further below, at the third level, the textual datatype properties are further split into subproperties according to their function (cf. Fig. 5.4).

A major design goal for a top-level ontology consists in achieving the desired level of expressivity with a minimal repertoire of basic terms and relations. Obversely, to ensure interoperability for services and tools interoperating at the level of a specific digital platform, the employed ontologies need to capture detailed characteristics of data pertaining to a particular domain of knowledge. Accordingly, the structure of the corresponding semantic space at the lower level is comparably complex, e.g. the ontologies from VIMMP contain about 1000 concepts, 550 relations (object properties) and 180 elementary datatype properties. Therefore, by design, the EMMO needs to have a structure that is substantially different from that of the marketplace-level ontologies [7]. To ensure that the EMMO is consistently employed at all levels, so that it can contribute to platform and service interoperability as far as possible, the marketplace-level ontologies need to be aligned with the EMMO. Before returning to this specific problem, the present section summarizes some of the related theoretical concepts.

In principle, semantic assets are designed to allow data integration and overcome the data heterogeneity problem; in reality, semantic heterogeneity does arise, and it grows over time as resources are added to the semantic web. This is known as the Tower of Babel problem [22, 23]. While some authors regard any presence of semantic heterogeneity as a failure of semantic interoperability and hope for universal agreements, others think that it is unavoidable and look for strategies to deal with it. This may involve a standardized way of documenting semantic assets; basic agreements on the approach to ontology design; and the formalizations of roles, procedures and good practices (or best practices), aiming at pragmatic interoperability [24‐27]. For this approach, the challenge consists in agreeing and specifying how the semantic space is structured, documented and employed in practice; by raising the domain for which universal agreements are pursued from the ontological level to the metaontological level, “the Tower of Babel becomes a Meta-Tower of Babel” [28].

As a consequence, semantic heterogeneity is seen as a necessary property of the semantic web, and ontology matching and integration become basic features of its successful mode of operation, rather than an expression of incompleteness. Options for implementing such a mode of operation have been extensively discussed in the literature, first for schemas and then for ontologies, cf. Noy [29] as well as Euzenat and Shvaiko [30]. The common challenge is how to make use of the knowledge represented in two ontologies, which can differ at various levels (language used, expressivity, modelling paradigm, etc.). Typically, such challenges arise if there is an overlap in the domains of knowledge addressed by multiple ontologies, such that data annotated in diverse ways need to be combined and processed together, or if a platform employs multiple domain ontologies that are based on different top-level ontologies. Typical applications include, e.g. simultaneous querying of multiple knowledge bases [31‐34] or, as addressed here, the mapping of semantic content from a source ontology \(\mathcal {S}\) to a target ontology \(\mathcal {T}\).

Such a mapping \( \alpha \), by which a scenario \(\mathcal {A}_\mathcal {S}\) expressed in the source ontology is mapped to a \(\mathcal {A}_\mathcal {T}\) expressed in the target ontology, is an ontology alignment. Equivalently, this can be applied to the corresponding knowledge graphs, \( \alpha : G _\mathcal {S}\mapsto G _\mathcal {T}\). The process by which an alignment is constructed is known as ontology matching [35]. Alignments can be probabilistic or deterministic, e.g. in a probabilistic formalism, it might be stated that “an osmo:condition that osmo:contains_variable an evmpo:material_property has a 40% probability of being an emmo-models:Physics BasedModel”, cf. Suchanek et al. [36]. For the present purpose, we restrict ourselves to deterministic alignments, based on rules that are asserted to be valid in general. If such an alignment is formulated coherently and correctly, the source and target scenarios need to be semantically consistent, i.e. the assertions from the target scenario may not contradict the assertions from the source scenario, which can be checked in multiple ways:

Under the constraint of consistency, it is the main challenge to preserve as much of the originally given information as possible. Test scenarios, for which the desired target representation is known, can be used to validate the alignment [34]. Moreover, alignment rules, whether probabilistic or deterministic, can be obtained by evaluating corpora of data that are annotated in both the source and target ontologies [35, 37]; in the probabilistic case, however, the outcome can be assumed to apply only as long as the population or corpus underlying the statistical analysis from which the probabilities were determined is representative of a class of scenarios to which \(\mathcal {A}_\mathcal {S}\) belongs. Simple alignment correspondences [38] can be specified by categorically subsuming concepts and relations from \(\mathcal {S}\) under those from \(\mathcal {T}\), yielding relabelling rules [39] that do not affect the graph structure (only the labels) and that are context free, i.e. independent of adjacent vertices and edges, such asstating that whatever evaluates an object, by implication, always also is a sign for that object. Besides, qualified subsumptions can be formulated, such asi.e. that which is evaluated by an assertion is an “object” in the sense of Peircean semiotics; this is a context-sensitive rule, since the relabelling of the vertex (individual) is contingent on one of the edges, namely, an incoming edge with the label vivo:evaluates. Beyond this, more complex graph transformation rules [40] can be applied in the case that the transformation goes beyond relabelling, i.e. if vertices or edges in the knowledge graph need to be eliminated or created by applying m : n property chain correspondences [38].

To permit the transformation of a knowledge graph from the way in which it appears to the VIMMP marketplace platform to the more abstract representation required for interoperability within a heterogeneous ecosystem of platforms mediated through the EMMO, both concepts and relations need to be aligned between the (VIMMP marketplace) domain level and the (EMMO) top level. This is realized by an ontology module for EMMO-VIMMP Integration (EVI). For the present purpose, accordingly, \(\mathcal {S}\) is the VIMMP system of ontologies, including the EVMPO (but excluding VIPRS), and \(\mathcal {T}\) is the EMMO, in the case of concepts, and the EMMO in combination with VIPRS, in the case of relations. In the absence of co-annotated corpora that can be analysed automatically, the correspondences were all specified explicitly, by evaluating the concept and relation definitions from the EMMO alpha version in comparison with the respective definitions from the VIMMP ontologies.

Concerning the conceptual alignment, Fig. 5.5 shows how the categories from the EVMPO, cf. Sect. 3.​2, are mapped to EMMO concepts. The red arrows and double lines in Fig. 5.5 represent this alignment, which is itself expressed as an ontology and implemented in the EVI module. This part of the alignment guarantees that all VIMMP domain-ontology concepts are subsumed under EMMO concepts (where they are all situated below emmo-physical:Physical taxonomically), since all of these concepts are either subclasses of one of the fundamental paradigmatic categories from the EVMPO or of the fundamental non-paradigmatic category evmpo:annotation.

Beyond this, the concepts from the domain ontologies are aligned with the EMMO down to a comparably fine-grained level; this is also implemented in EVI.⁹ Table  5.1 contains the EVI statements corresponding to the concepts that were listed as examples in Chap. 3.

The relational alignment, which is shown for the MMTO in Fig. 5.6 and for the examples from Chap. 3 in Table  5.2, is implemented directly in the domain ontology TTL files, which contain statements by which the domain ontology relations are subsumed under VIPRS relations. Property chain correspondences are applied when the mereosemiotic chain relations from VIPRS are unfolded, cf. Fig. 5.7, yielding series of elementary parthood and reference relations from the EMMO, so that the graph grows both in terms of vertices and edges; in TTL notation, this corresponds to the introduction of blank nodes (individuals without an IRI [41]) by which, e.g. 

which encodes becomes

For documenting molecular models and exchanging them between platforms, a semantic interoperability standard on the basis of the VIMMP system of ontologies as well as MODA [20] was agreed between VIMMP and the Molecular Model Database (MolMod DB) of the Boltzmann-Zuse Society [43]; the associated environment of interoperable platforms will prospectively also include Bottled SAFT [44].

The structure of the knowledge graph representing a molecular model is illustrated by Fig. 5.8, which corresponds to a two-centre Lennard-Jones plus point-quadrupole model (2CLJQ) where a molecule (in this case, acetylene) is represented by a rigid unit (viso-am:rigid_object), consisting of two Lennard-Jones interaction sites (viso-am:lj_site), a point-quadrupole site (viso-am:charge_quadrupole_site) as well as a viso-am:structureless_object, representing the molecular centre of mass, which is used the initial point of vov:relative_position vectors that indicate the coordinates of the interaction sites. The relation vov:has_attached_variable and subproperties of it are used to connect the interaction sites with the non-geometrical model parameters, i.e. the mass associated with each of the two LJ sites (half the molecular mass), the \(\sigma \) and \(\epsilon \) site and energy parameters of the LJ potential, and a second-order tensor characterizing the quadrupole moment. Other rigid molecular models are described analogously.

The platform interoperability implementation developed on this basis employs JSON-LD to exchange information on molecular models. Therefore, the knowledge graph needs to be connected (i.e. it may not consist of multiple connected components), and its topology needs to be simplified to a tree structure such that each object is subordinate to exactly one object, except for a single root node at the top. For the present example, an osmo:workflow_graph with two sections, a use case (MODA Sect. 5.1) and a model (MODA Sect. 5.2), is selected as the root of the tree. In this way, e.g. one of the site coordinates is included in the rigid unit description as follows:

The hierarchy by which objects are embedded in other objects in JSON is obtained from a subset of the relations from the knowledge graph, shown in Fig. 5.8 as solid arrows in blue colour, while references to IRIs are used to represent the other relations (dashed black arrows) in JSON-LD. The relations vov:involves_object and vov:involves_variable are part of the JSON-LD tree structure (solid blue arrows), so that COM, SITE_LJ_A, and LJ_A_POS are all hierarchically subordinate to RIGID_UNIT. The relations vov:has_initial_point and vov:has_final_point, however, are sideways connections between nodes from multiple branches of the tree (dashed black arrows); therefore, their JSON-LD representation only points to the IRI of the referenced object, using the "@id" keyword.