---
title: 'MatInf RDMS: Open-Source Data Management'
url: https://www.emergentmind.com/topics/matinf-research-data-management-system-rdms
type: topic
---

# MatInf RDMS: Open-Source Data Management

MatInf Research Data Management System (RDMS) is an extensible, open-source solution for research digitalisation in materials science based on an adaptive, flexible information management system for heterogeneous data sources. In the literature, it is presented both as a modular web-based platform for acquisition, storage, processing, and linking of research objects, and as a system that can evolve stepwise from document-oriented repositories to fully factographic environments. Across these descriptions, MatInf is characterized by multi-tenant deployment, programmable APIs, graph-based linking of experimental objects, and, in later formulations, ontology representations and Knowledge Graph construction for reproducible data-driven workflows [2404.13722; 2510.17840; 2601.09359].

## 1. Scope and design aims

MatInf was introduced to address a recurring problem in materials science: the coexistence of raw binary detector dumps, CSV, XML, images, simulation outputs, and lab-specific file formats within a single research program. Its stated design objectives are to provide an open-source, vendor-neutral RDMS tailored to experimental and theoretical materials researchers, to support true extensibility in data types, to enable collaborative, multi-tenant deployment, and to lay the groundwork for high-throughput and, ultimately, autonomous experimentation by supporting programmable APIs that can feed data directly from instruments into MatInf [2404.13722].

The target usage scenarios span individual research groups, consortia of labs sharing a SaaS instance, and national or international initiatives that require custom interfaces. Later work recasts the same problem more explicitly as a transition between “document-oriented repositories” and “fully factographic environments,” arguing that digitalisation requires systems capable of supporting a broad spectrum of usage scenarios rather than a single fixed data model. This suggests that MatInf is best understood not as one immutable software package, but as a configurable RDMS family whose core concern is the controlled evolution of heterogeneous research data into reusable, queryable structures [2510.17840].

A persistent theme is that extensibility is not limited to file import. It also includes dynamic definition of new object types and properties without code redeployment, fine-grained access control across public, protected, NDA-bound, and private data, and the ability to assemble directed graphs of interrelated objects such as materials libraries, compositional analyses, spectra, plans, and reports [2404.13722].

## 2. Architecture and extensibility mechanisms

One published architecture presents MatInf as a modular, web-based solution built on Microsoft’s ASP.NET Core MVC framework backed by a relational SQL Server database. The layers are the Web User Interface, API & Controllers, Application Services, and a Data Access Layer using Dapper with file-system or S3 storage for large binary payloads. A shared tenant registry supports multi-tenant deployment, while late binding to external services is handled through interfaces such as `IFileValidator` and HTTP(S)-addressable validation, import, and visualization endpoints [2404.13722].

A later system description preserves the relational core but generalizes the storage model. Core storage is described as a modern relational database extended with graph (object-link) and document (JSON/XML) types. The principal metadata tables are `TypeInfo`, `RubricInfo`, and `ObjectInfo`; graph tables include `ObjectLinkObject` and `Handover`; factographic tables are realized as `Property*` tables such as `PropertyFloat` and `PropertyString`; and external SET-services expose REST endpoints for validation, extraction, and HTML-based visualization. Access is provided through a browser UI and REST-API with multi-tenant, role-based access control [2510.17840].

The extensibility mechanism is metadata-driven. `TypeInfo` specifies the root table, whether a file is required, and the validation, import, and visualization schema or endpoint. New object types can therefore be added at runtime by inserting a row into `TypeInfo`, and property schemas can be created via the UI or API. The explicit intention is that laboratories can introduce novel instruments or file formats without database migrations or code redeployments [2404.13722].

In the CRC 1625 deployment, this relational architecture is coupled to an ontology module and a Knowledge Graph layer. The three interacting layers are a relational back-end storing samples, measurements, files, and metadata; an ontology module aligned with PMDco and other ontologies; and a Knowledge Graph exposing RDF triples and SPARQL endpoints built from the relational data via RML mappings. Measurements are uploaded via GUI or REST calls, normalized through user-defined types, and then transformed periodically or on demand into RDF [2601.09359].

## 3. Object model, graph structure, and factographic evolution

At the relational level, MatInf stores strongly typed objects around a root type `ObjectInfo`, with fields such as `ObjectId`, `TenantId`, `TypeId`, `Name`, `AccessLevel`, timestamps, optional external identifiers, file path, file hash, and description. For materials science, dedicated derived tables such as `Sample` and `Composition` complement the generic root type, while sparse extension tables `PropertyInt`, `PropertyFloat`, and `PropertyString` hold arbitrary key-value pairs and optional row indices. Directed semantic relationships are recorded in `ObjectLinkObject` [2404.13722].

The later graph-based formulation makes this structure explicit. Every research workflow is organized as a directed multigraph
$$
G=(V,E),
$$
with admissible edge types specified by a relation
$$
R \subseteq T_E \times T_V \times T_V.
$$
Here, \(T_E\) is the set of edge types and \(T_V\) the set of vertex or object types; a triple \((t_E,t_{v1},t_{v2}) \in R\) permits an edge of type \(t_E\) from an object of type \(t_{v1}\) to one of type \(t_{v2}\) [2510.17840].

This graph formalism is summarized by the STAR paradigm: Statefulness, Traceability, Aim, and Result. Statefulness means that every change of a physical sample’s state is captured by a new node; measurements attach to the correct state node. Traceability includes both sample handovers linked to user IDs and plan-versus-actual progress tracking. Aim is represented by an “Idea” or “Experiment Plan” node defining the scientific question and sequence of required object types. Result is represented by a “Report” node summarizing positive and negative outcomes and potentially spawning new Idea nodes. The formal constraint
$$
|E| + 1 \ge |V|
$$
is used to express that STAR graphs should remain meaningfully connected [2510.17840].

The same work describes a three-stage transition. Stage 1 is document-oriented, where objects are opaque files plus minimal metadata. Stage 2 is graph-based, enabling `ObjectLinkObject` edges, Idea/Plan and Report types, and handover registration. Stage 3 is factographic, where selected object types such as EDX result, XRD result, and resistance measurement are standardized and their extracted values are stored in `Property*` tables for downstream analysis. A plausible implication is that MatInf is designed to preserve document-level flexibility while selectively converting stable, high-value object classes into query-optimized fact tables [2510.17840].

## 4. Ingestion, validation, provenance, and FAIR operationalisation

MatInf does not normalize every binary format in its core. Instead, each object type that carries a file can register an external or embedded validator and importer through `TypeInfo`. On upload, the system applies the uniqueness constraint on `(TenantId, ObjectFileHash)`, dispatches the file to custom validation either through an ASP.NET interface or an external REST endpoint, and, if validation succeeds, invokes extraction of metadata and extended properties. The returned metadata is mapped into `Property*` tables or linked objects, while provenance is preserved through the stored file path and file hash [2404.13722].

The stepwise evolution paper formalizes this process as SET: Standardisation, Extraction, and Testing. Standardisation defines a JSON-Schema for each file format in `TypeInfo.DataSchema`. Testing invokes `validate(doc, schema) → Boolean` on upload. Extraction produces a JSON payload and tabular blocks, maps them to `ObjectInfo` properties and `Property*` tables, and stores the original document with a SHA-256 link in `FileStorage`. The same description emphasizes that extraction can be context-sensitive: for example, substrate-signal subtraction in EDX can be performed by traversing the STAR graph to parent sample nodes during extraction [2510.17840].

FAIR is treated as an operational property rather than a slogan. In MatInf, findability is implemented through globally unique `ObjectID`s and URLs, indexed `TypeInfo`, `RubricInfo`, and `Property*` tables, and, in some deployments, chemical composition search via a composition-range index. Accessibility is provided by an HTTPS-based Web GUI and REST API. Interoperability is addressed through standard JSON-LD payloads for extraction, typed vertices and typed edges in the graph model, and, in the knowledge-graph deployment, RDF/SPARQL interfaces. Reusability is grounded in full provenance: every upload, validation, extraction, and handover is timestamped and linked to users, while STAR ensures that sample history, plan, and result are explicit rather than implicit [2510.17840].

A related deployment for defect phase diagrams extends these principles through an openBIS ELN/LIMS and a Streamlit-based companion application using pyBIS and S3 APIs. In that system, the companion application handles large-object upload/download to DataStorage.nrw, metadata extraction, thumbnail and preview generation, federated data access, and an extended provenance viewer, while automated Python jobs compute derived datasets and register them back into the ELN/LIMS. Although architecturally distinct, it exemplifies the same RDMS priorities: low-friction capture, traceability, and automated reuse of heterogeneous datasets [2511.01942].

## 5. Ontology representations, Knowledge Graphs, and spatial semantics

The CRC 1625 deployment adds a semantic layer in which MatInf’s relational data are mapped into an ontology-aligned Knowledge Graph. The ontology reuses and extends PMDco, aligning classes such as `pmdco:ValueObject` and `pmdco:Process`. Reported classes include `crc:SampleLibrary`, `crc:MeasurementArea`, `crc:MicroArea`, `crc:MeasurementProcess`, and `crc:HandoverEvent`; object properties include `crc:hasSubArea`, `crc:wasPerformedBy`, and `crc:nextProcess`; data properties include `crc:gridX`, `crc:gridY`, and `crc:hasValue`. RDF triples are generated from SQL rows through declarative RML mappings using RMLStreamer or RMLMapper, and the resulting graph is exposed through SPARQL [2601.09359].

This semantic layer is tightly coupled to the spatial organization of high-throughput materials libraries. The relational model is sample-centric, proceeding from `Sample` to `MeasurementArea` to `MicroArea` to `Measurement`. For thin-film combinatorial libraries, each MeasurementArea \((i,j)\) maps to physical coordinates
$$
x_{ij} = x_0 + (i-1)\,\Delta x,\quad y_{ij} = y_0 + (j-1)\,\Delta y,
$$
with \(\Delta x=\Delta y=4.5\,\mathrm{mm}/18\) for an \(18\times18\) grid; MicroAreas refine these coordinates by sub-pixel offsets. This representation allows heterogeneous data modalities to be mapped to the correct spatial locations on physical samples [2601.09359].

The semantic layer is also intended for federation. The KG can be queried through SPARQL, and federated SPARQL queries may link to external EMMO or OPTIMADE endpoints. The paper presents this as a means of combining different data modalities in different formats and resolutions from different labs, while still supporting a graphical user interface and an application programming interface for reproducible data-driven workflows [2601.09359].

A common misconception is that MatInf is exclusively a document store with optional metadata. The graph and ontology work contradicts that view: documents remain first-class objects, but they can be embedded in typed object graphs, transformed into factographic properties, and exported into ontology-aligned RDF. Conversely, it is also inaccurate to describe MatInf as purely graph-native; the semantic layer is built from a relational back-end rather than replacing it [2510.17840].

## 6. Representative use cases, performance, and open issues

A central use case is high-throughput experimentation. In the original case study, a quaternary materials library such as V–Mn–Co–Ni is deposited as a single 2D combinatorial thin-film sample, registered as a `Sample` object, and then scanned to produce thousands of point analyses. An external importer creates `Composition` objects for each grid point, links them to the parent sample through `ObjectLinkObject` with predicate “point-of,” and populates `PropertyFloat` rows for derived values such as \(E_g\) and \(\sigma\). Visualization is performed either through a built-in heatmap or an external service plotting a quaternary phase diagram. The same report notes that native `Sample` and `Composition` tables were introduced once extended properties surpassed ~100 000 records, and that sub-second range queries on \(10^5\) objects were achieved on commodity hardware [2404.13722].

The stepwise STAR/SET formulation adds project-management and traceability use cases. In the TRR 247 example, an Idea node defines a plan requiring photograph, EDX, XRD, resistance, and SECCM measurements for Ag–Au–Pd and Pt–Rh–Ru libraries on sapphire; dynamic reports highlight missing measurements in red; factographic tables store band-gap versus temperature; and a composition-range search finds samples within \(\pm 1\) at.% of a target. Reported performance figures are sub-100 ms query times on \(10^5\) objects and graph traversals in less than 200 ms for typical subgraphs [2510.17840].

The CRC 1625 deployment emphasizes cross-modality and machine-learning workflows. Reported system figures are 11.3 GB of data, 19 888 MeasurementAreas, more than 100 data types, and a relational size of approximately 2 million rows. Query performance is reported as less than 200 ms for single-sample metadata queries and less than 1 s for wafer-wide value heatmaps with proper indexing on `gridX` and `gridY`; full-scale RDF generation takes about 5 min and incremental updates less than 30 s. Use cases include direct EDX–SECCM Pearson correlation maps, active learning that reduces required SECCM measurements from 342 to 52, approximately 85% reduction, and composition-property extrapolation via text mining with \(r^2=0.65\) on held-out compositions [2601.09359].

The literature also reports implementation frictions and unresolved issues. Ontology alignment with PMDco and EMMO required manually mapping about 50 classes and properties. User-defined-type flexibility was necessary to ingest 26 EDX formats without schema changes. In the broader defect-phase-diagram infrastructure, parsing and registration of large EBSD datasets of 100 GB completes within minutes, but the paper explicitly notes that formal benchmarking numbers are not reported. These details indicate that MatInf’s central challenge is not only storage scale, but the continuous accommodation of heterogeneous file formats, semantic vocabularies, and collaborative workflows across institutions [2601.09359; 2511.01942].

Source: https://www.emergentmind.com/topics/matinf-research-data-management-system-rdms