Eine Bridge, 14 ELN/LIMS-Systeme — plus der gesamte Open-Source-Material-Stack rundherum
OCO bridget nicht jedes ELN/LIMS-Vendor-System einzeln, sondern den ELN-Filetype-Standard — den RO-Crate-basierten Cross-Vendor-Export, den derzeit 14 ELN/LIMS-Systeme adoptieren. Eine Bridge deckt damit den ganzen Pool ab. Zusätzlich verbindet die L0-Schicht OCO direkt mit dem Open-Source-Material-Stack, der in der MSE-Community ohnehin der Backbone ist: PMDco, EMMO-Crystallography, BattINFO, CHMO, OBI, schema.org, RO-Crate, Materials Project, OPTIMADE, Croissant.
Was Sie davon haben
- Cross-Vendor-Bridge statt 14 Einzel-Mappings: Anbindung über den ELN-Filetype-Standard (RO-Crate-basiert) — was Sie heute in eLabFTW oder Chemotion oder Kadi4Mat exportieren, landet als ABox-fähiges Material in OCO.
- L1 als direkt importierbare LIMS/ELN-Grundausstattung: Sample, Equipment, Measurement, Identifier, Provenance — die material-agnostische Schicht der Architektur, CC-BY-SA 4.0 freigegeben, kein Klassen-Doppelmodellieren mehr.
- SIPOC-Fragment-ABox-Modell: OCO erwartet nicht, dass jede Mess-Position vollständig ist. Reale Lab-Daten und Literatur-Extraktion sind nie komplett — die SIPOC-Granularität plus die Drei-Stufen-Identifier-Hierarchie (mandatory/recommended/optional) akzeptiert das, statt Lücken-Daten abzulehnen.
- Reuse-before-invention-Disziplin: in der letzten Interop-Welle wurden 18 Kandidaten-Properties auf 0 reduziert und 15 Kandidaten-Klassen auf 5, weil sie schon im Open-Stack existierten. Sie ziehen sich nichts neu in den Stack, was schon woanders steht.
Die 14-System-Bridge über den ELN-Filetype-Standard
Der ELN-Filetype-Standard (geführt von The ELN Consortium) ist ein RO-Crate-basiertes Export-Format, das Cross-Vendor-Interoperabilität für Electronic Lab Notebooks und Lab Information Management Systems herstellt. OCO bridget einmal an dieses Format — und deckt damit den gesamten Adopters-Pool ab, ohne pro Vendor eine eigene Mapping-Datei pflegen zu müssen.
Stand 2026: 14 produktive ELN/LIMS-Systeme adoptieren den Standard. Bekannte Vertreter:
| System | Herkunft / Fokus | Adopter-Status |
|---|---|---|
| eLabFTW | Open-Source ELN, Pasteur Institut / weitverbreitet in EU-Forschung | RO-Crate-Export produktiv |
| Chemotion ELN | NFDI4Chem-Backbone, KIT, Chemie-fokussiert | RO-Crate-Export produktiv |
| openBIS | ETH Zürich, breit eingesetzt in Life-Sciences und Materials | RO-Crate-Export produktiv |
| Kadi4Mat | KIT, Materials-Engineering-fokussiert, Teil von NFDI-MatWerk | RO-Crate-Export produktiv |
| PASTA-ELN | FZJ, Materials-Science-orientiert | RO-Crate-Export produktiv |
| Herbie | RWTH Aachen / IEHK, Stahl-/Werkstoff-Daten | RO-Crate-Export produktiv |
| LabIMotion | NFDI4Chem, ELN-Add-on | RO-Crate-Export produktiv |
| Sample DB | PTB, Mess-zentrierte ELN-Variante | RO-Crate-Export produktiv |
| … weitere im aktuellen ELN-Filetype-Konsortium (Gesamtzahl: 14 systemseitig produktiv). | ||
Statt 14 Vendor-Mappings hat OCO eine Bridge, plus ein Thin Application Profile, das die typischerweise benötigten Module bündelt (Sample, Equipment, Measurement, Process, Identifier, Provenance, Format), ohne dass eine extrahierte Subset-Distribution gepflegt werden müsste.
L1 als LIMS/ELN-Grundausstattung
Die material-agnostische L1-Schicht ist genau das Vokabular, das in jeder LIMS/ELN-Installation ohnehin existiert — nur diesmal als geteilte Definition, nicht als pro-Projekt nachgebaute Kopie. Stand v0.94:
| L1-Modul | Inhalt | Bridge-Targets |
|---|---|---|
| oco-sample | Probe, Probenahme, Probenzustand, Probenbehandlung | PMDco, OBI |
| oco-equipment | Laborequipment, Messgeräte, Anlagen, Kalibrier-Status | PMDco, CHMO, OBI, schema.org |
| oco-measurement | Messung, Mess-Workflow, Mess-Parameter, Mess-Ergebnis | PMDco, QUDT (Einheiten), PROV-O |
| oco-identifier | Identifier-Hierarchie (mandatory/recommended/optional), externe IDs | schema.org, ROR, ORCID |
| oco-investigation | Investigation/Study/Assay-Struktur, Akteure, Roles | PROV-O, PMDco, OBI |
| oco-process | Prozess-Schritte, Process-Inputs/Outputs, Process-Provenance | PMDco, PROV-O |
Diese L1-Module sind öffentlich unter CC-BY-SA 4.0 verfügbar (siehe Ontologie-Architektur für die Lizenz-Matrix). Sie können direkt in einen LIMS/ELN-Workflow importiert werden, ohne dass die material-spezifische L2-Tiefe mitgezogen wird.
Der Open-Source-Material-Stack — was alles eingebunden ist
„Eine Bridge, 14 Systeme” ist die ELN-Seite. Die Tooling- und Daten-Welt rundherum ist ebenfalls als L0-Bridge-Topologie eingebunden. Zwei Schichten, beide produktiv:
PMD-Konsortium und Materials-Ontologien
| Standard / Tool | Domäne | Bridge-Status in OCO |
|---|---|---|
| PMDco | Platform MaterialDigital Core Ontology (Mid-Level, BFO-aligned) | volle Sektion, primärer L0-Anker |
| EMMO-Crystallography | European Materials & Modelling Ontology, Kristallographie-Sub-Modul | eigene Bridge-Sektion, Sub-Modul-versionierbar |
| BattINFO | Batterie-Materials-Ontologie | Bridge zu allen Klassen, die in der Keramik-Domäne wiederkehren |
| EMMO-Chemistry / Materials | EMMO Sub-Module Chemistry, Materials | eigene Bridge-Sektionen pro Sub-Modul |
| EMMO-ISQ | ISO/IEC 80000 Quantity Vocabulary (93 Mappings) | vollständig gemappt |
| CHMO | Chemical Methods Ontology | Equipment-Anker-Bridge |
| ChEBI | Chemical Entities of Biological Interest | Substanz-Anker-Bridge |
| OBI | Ontology for Biomedical Investigations | Investigation-Anker-Bridge |
| MADO / MWO | Materials Acquisition Description Ontology / Materials Workflow Ontology | eigene Bridge-Sektionen |
| KnowNow | PMD-Vorgänger-Ontologie | 14 Prozess-/Property-Mappings (LTCC-Spezifika bewusst ausgenommen) |
| SmaDi | Smart-Materials-Discovery-Ontologie | 15 Mappings, Piezo-Keramik-Subset (Shape-Memory bewusst ausgenommen) |
| Mieller-Ferrit | Ferrit-spezifische PMD-Ontologie | Bridge-Vorbereitung für Ferrit-Pilot |
FAIR / Data-Infrastructure-Stack
| Standard / Tool | Rolle | OCO-Anwendung |
|---|---|---|
| RO-Crate | Research-Object-Crate Format (FAIR-Datenpaketierung) | ELN-Filetype basiert auf RO-Crate; Anker in oco-investigation |
| Materials Project | DFT-Datenkorpus, LBNL | externer Cache mit ~155 000 Einträgen (Schicht 2 Energie/DFT) |
| OPTIMADE | Cross-Datenbank-API für Material-Struktur-Suche | Lookup-Bridge für Struktur-Search-API-Felder |
| Croissant (MLCommons) | ML-ready Dataset-Metadata-Standard | Bridge für ML-Anwendungs-Sicht über Materials-Daten |
| QUDT | Quantity/Unit/Dimension/Type-Ontologie | L0-Anker für alle physikalischen Einheiten und Mess-Parameter |
| PROV-O | W3C Provenance Ontology | L0-Anker für jegliche Provenance-Annotation |
| schema.org | strukturierte Daten-Web-Standard | Equipment-, Identifier-, Organisation-Bridge |
| ROR / ORCID | Research Organisation Registry / Open Researcher ID | Akteur-Identifier-Bridge |
| NFDIcore | NFDI Common Ontology | Cross-NFDI-Konsortium-Bridge |
829 explizite Cross-Ontology-Mappings in 40 Sektionen sind in bridge_mappings.yaml und mwo_mappings.yaml als Single Sources of Truth gepflegt. Jede Bridge-Sektion ist unabhängig versionierbar — wenn PMDco ein Versions-Bump kriegt, ändert sich genau eine Bridge-Datei.
SIPOC-Fragment-ABox-Modell — Realität-Toleranz statt Schema-Tyrannei
Reale Experiment-Daten sind nie vollständig. Bei eigenen Experimenten kann Vollständigkeit angestrebt werden, bei Literatur- und Patent-Extraktion ist Unvollständigkeit oft absichtlich (Wettbewerbs- oder Patent-Strategie). Ein Schema, das vollständige Felder verlangt, würde entweder die meisten Real-World-Daten ablehnen oder Platzhalter-Werte erzwingen — beides unakzeptabel.
OCO ingestiert ABox-Daten als SIPOC-Fragmente (Suppliers / Inputs / Process / Outputs / Customers). Die SIPOC-Granularität kombiniert mit der Drei-Stufen-Identifier-Hierarchie (mandatory / recommended / optional) akkommodiert unvollständige Daten, ohne das Schema zu brechen. Das macht OCO praktisch nutzbar für die zwei dominanten Datenquellen — eigene Lab-Daten und Literatur-Extraktion.
Konkret: eine Sinter-Versuchs-Charge muss nicht alle 47 möglichen Parameter ausgefüllt haben. Ein SIPOC-Fragment mit Process-Schritt + zwei Output-Identifiern reicht für eine valide ABox-Position. Die fehlenden Felder werden nicht imputiert, nicht halluziniert, sondern als „nicht erhoben” annotiert.
Reuse-before-Invention — die Disziplin in Zahlen
Bevor irgendeine neue Klasse oder Property in OCO neu modelliert wird, läuft eine Checkliste:
- Gibt es schon eine passende OCO-Klasse?
- Externer Identifier? → Sub-Klasse von
oco-identifier:Identifier. - Provenance? → PROV-O.
- Einheit? → QUDT
QuantityValue.
In der jüngsten Interop-Welle hat diese Checkliste 18 Kandidaten-Properties auf 0 reduziert und 15 Kandidaten-Klassen auf 5. Das ist nicht Spar-Programm — das ist Vermeidung von Schein-Innovation, die später Cross-Mapping-Aufwand verursacht.
In der Praxis bedeutet das: wenn Sie OCO in eine LIMS/ELN-Pipeline einziehen, ist die Wahrscheinlichkeit hoch, dass jede Klasse, die Sie ohnehin schon kennen (sample, sensor, measurement, person), bereits ihre OCO-Bridge auf den Standard hat, mit dem Sie arbeiten.
Der PMD-Konsortium-Kontext — warum OCO die Duplizierung beendet
Im PMD-Konsortium (Platform MaterialDigital) sind über ein Dutzend Projekte aktiv, jedes mit seiner eigenen material-spezifischen Ontologie: KupferDigital, GlasDigital, StahlDigital, DiProMag, iBain, KnowNow, Mieller-Ferrit, SmaDi und weitere. Das Problem: nur ein Bruchteil der modellierten Inhalte ist tatsächlich material-spezifisch (die Material-Klassen-Hierarchie). Der grösste Teil — Workflow-Provenance, Equipment, Methoden, Identifier-Schemata — ist material-agnostisch und teilbar.
OCO ist gebaut, um diese Duplizierung strukturell zu beenden: L0+L1 sind das gemeinsame Vokabular, L2 ist die material-spezifische Schicht, die Schwesterprojekte ersetzen können (Polymere, Metallurgie, Batterien) ohne L0+L1 neu zu modellieren. Eine Polymer-L2 ersetzt die Keramik-L2 — die Equipment-, Sample-, Provenance-, Identifier-Klassen bleiben unverändert geteilt.
Beispiel-Competency-Questions
Sechs aus den 163 publizierten CQs, die für LIMS/ELN-Integratoren besonders relevant sind. Tag-Spalte = OCO-Modul, das die Frage beantwortet.
Welche ELN-Filetype-Felder lassen sich automatisch auf OCO-L1 abbilden, und welche müssen pro Vendor angereichert werden?
oco_eln_profile · bridge/eln_filetypeWelche minimal-vollständige SIPOC-Fragment-Vorlage gilt für einen Sinter-Versuch (Stage 1: mandatory only)?
oco-process · oco-identifierWelche PMDco-Klasse entspricht „Probe” in unserem Chemotion-ELN-Export?
oco-sample · PMDco-bridgeWelche Provenance-Kette dokumentiert die Charge X von der Pulver-Lieferung bis zum gesinterten Probekörper?
oco-investigation · PROV-O · executable SPARQLWelche Equipment-Anker ergeben sich für ein Differential-Scanning-Calorimeter aus CHMO und PMDco?
oco-equipment · CHMO-bridge · PMDco-bridgeWelche QUDT-Einheit ist für die Mess-Position „Curie-Temperatur” zu verwenden, und wie wird die Unsicherheit annotiert?
oco-measurement · QUDT-bridgeBezug zur OCO-Distribution
Die LIMS/ELN-Grundausstattung — L1-Skelette (Sample, Equipment, Measurement, Identifier, Process, Investigation) plus Tensor-Wurzeln, Role-Individuals und Cross-Axiome — ist öffentlich unter CC-BY-SA 4.0 verfügbar. Die L0-Bridges zu PMDco, CHMO, OBI, schema.org, QUDT, PROV-O, ELN-Filetype, RO-Crate, Croissant, OPTIMADE stehen unter CC-BY 4.0 frei zur Verfügung. oco-supplier, das Material-Detail-L2 und die Compliance-Module sind proprietär — Sie können aber den vollen LIMS/ELN-Stack ohne diese betreiben. Bundle „LIMS/ELN-Ready” (L0+L1 ohne supplier) ist mit Registrierung downloadbar. → Distribution & Lizenz-Architektur