Ontology The communication among tenants relies on the compliance to the commonly agreed exchange syntax underlying the structure of the requests and results posted for each method. As the number of tenants grows and their functions diversify, the data they exchange becomes structurally complex and susceptible to ambiguities. JSON keys might repeat but refer to different concepts depending on their location in the schema. E.g., temperature within a conductivity measurement might mean the internal temperature of an electrolyte solution, surface temperature of the cell, ambient temperature for the chamber, etc. In addition to ambiguity, the data exchanged by tenants might not be readily accessible. The exchange schemas are designed to support communication between tenants, but such flexibility comes at the expense of syntactic complexity. For instance, retrieving a conductivity result requires knowing the full data structure (albeit this can be retrieved and investigated directly from FINALES) to locate the relevant fields and values. A remedy to ambiguity and accessibility is mapping data to controlled vocabularies of concepts. Such mapping effectively upgrades a syntactic data model into a semantic data model, where data fields are attributed an unambiguous meaning. As a tempera-ture key in the schema is mapped to the concept of SurfaceTemperature in a controlled vocabulary, the intended meaning of the field becomes explicit and distinct to, e.g., SampleTemperature. Moreover, the association between a measurement (uniquely identified with a UUID), a vocabulary concept (e.g. Schema.org concept dateCreated), and a value (e.g. 2024-02-16) can be represented as a Node-Edge-Node connection in a network. Representing results as these Triples in a Graph Database makes data accessible irrespective of how it is syntactically encoded in the data model.