The best part isn’t the design — it’s that the content updates itself. Publications (from Semantic Scholar and Zenodo), posts from Mastodon & Bluesky, GitHub repos, Strava runs, Spotify plays, even my Google Scholar metrics all sync automatically through GitHub Actions and API calls.

View original post

Check out the latest updates on the MSE KG homepage: 👉 https://nfdi.fiz-karlsruhe.de/matwerk/

@fizise @lysander07 @heikef #NFDIMatWerk #KnowledgeGraph #MaterialsScience #MSE #ResearchDataManagement

View original post

View original post

Why a Knowledge Graph?

Materials science data is incredibly heterogeneous. You have:

• Experimental data from tensile tests, SEM images, XRD spectra
• Simulation data from DFT, molecular dynamics, FEM
• Metadata — who did what, when, with which equipment
• Publications linking all of these together

The problem? This data lives in different formats, different databases, and different institutions. A researcher at KIT can’t easily find related experiments done at Fraunhofer, even if they’re studying the same material.

A knowledge graph solves this by creating a unified semantic layer — every entity (a material, a person, an experiment, a publication) becomes a node, and relationships between them become edges. All queryable via SPARQL.

Step 1: Choose Your Ontology Stack

The foundation of any knowledge graph is its ontology — the formal model that defines what types of things exist and how they relate.

We chose a layered approach:

BFO (Basic Formal Ontology)        ← Upper-level
  └── NFDIcore                     ← Mid-level (cross-domain NFDI)
       └── MWO (MatWerk Ontology)  ← Domain-level (materials science)

Why BFO? It’s the most widely adopted upper-level ontology in science. Using BFO means our ontology is inherently interoperable with hundreds of others in biology, chemistry, and engineering.

Why NFDIcore? It provides shared classes for research infrastructure (datasets, persons, organizations, software) that are common across all NFDI consortia. This means our materials science data can interoperate with cultural heritage, chemistry, and data science data.

Step 2: Model Your Domain

The hardest part isn’t the technology — it’s the modeling decisions. For materials science, we needed to represent:

• Materials with their composition, structure, and properties
• Processes — how a material is synthesized, tested, or simulated
• Measurements — what was measured, how, and what the results were
• Provenance — who did this work, at which institution, funded by whom

We used Ontology Design Patterns (ODPs) — modular, reusable modeling templates. For example, our “Process Pattern” captures:

Process → has_input → Material
Process → has_output → Material
Process → has_parameter → Parameter
Process → realized_by → Agent

This pattern works for everything from a tensile test to a DFT simulation.

Step 3: Ingest Data

We integrated data from multiple sources:

Each source required a custom ETL (Extract, Transform, Load) pipeline. We wrote these in Python, outputting RDF triples that conform to our ontology.

Step 4: Quality Assurance

A knowledge graph is only useful if its data is correct. We implemented:

• SHACL validation — shape constraints that check if the data conforms to the ontology
• Competency questions — SPARQL queries that the KG must be able to answer (e.g., “Find all tensile test results for steel alloys published after 2020”)
• Cross-referencing — checking that entity URIs resolve and that linked data is consistent

Step 5: Deploy and Query

The MSE-KG is served via a SPARQL endpoint backed by a triplestore. Researchers can:

1. Run SPARQL queries directly
2. Use our web interface for guided exploration
3. Access the data via a REST API

Example query — find all publications by researchers at FIZ Karlsruhe about knowledge graphs:

SELECT ?paper ?title ?author ?date WHERE {
  ?paper a nfdicore:Publication ;
         schema:name ?title ;
         schema:author ?author ;
         schema:datePublished ?date .
  ?author schema:affiliation ?org .
  ?org schema:name "FIZ Karlsruhe" .
  FILTER(CONTAINS(LCASE(?title), "knowledge graph"))
}
ORDER BY DESC(?date)

Lessons Learned

1. Start with competency questions, not the ontology. Define what questions the KG needs to answer before modeling. This keeps you focused.

2. Reuse before you create. For every class or property you want to add, check if BFO, Dublin Core, Schema.org, or another standard already defines it.

3. Ontology engineering is a social process. The hardest part was getting domain experts and ontology engineers to agree on modeling decisions. Regular workshops and working examples helped enormously.

4. Automate everything. Data integration, validation, deployment — if it’s manual, it won’t scale and it won’t be maintained.

5. Ontology Design Patterns save time. Instead of modeling from scratch, reusable patterns gave us a head start and ensured consistency.

What’s Next

We’re working on:

• Expanding the KG with more institutional data sources
• Building LLM-powered interfaces for natural language querying
• Federated SPARQL queries across NFDI consortia
• Automated ontology alignment using machine learning

If you’re building a knowledge graph for your domain, feel free to reach out. The MSE-KG tools and ontologies are all open source.

Explore the MSE-KG: https://nfdi.fiz-karlsruhe.de/matwerk/

Think of them as design patterns for knowledge representation — the same idea as the Gang of Four patterns in software engineering, but for ontologies.

The Problem

Imagine you need to model a tensile test in your materials science ontology. You need to capture:

• The material being tested
• The testing machine and its parameters
• The person performing the test
• The resulting stress-strain curve
• The date, location, and standard used

You could model this from scratch. But then your colleague modeling a hardness test faces the same decisions. And someone else modeling a chemical synthesis. Each reinvents the wheel, and their models are incompatible.

The Solution: Patterns

An Ontology Design Pattern is a small, self-contained ontology fragment that solves a recurring modeling problem. For the testing scenario above, you’d use a Process Pattern:

┌─────────────┐    has_input     ┌──────────┐
│   Process    │ ───────────────→│ Material  │
│ (TensileTest)│                 └──────────┘
└──────┬───────┘
       │ has_output
       ▼
┌──────────────┐    has_parameter  ┌───────────┐
│   Result     │ ←────────────────│ Parameter │
│(StressCurve) │                  │(LoadRate) │
└──────────────┘                  └───────────┘

This pattern works for any process — synthesis, characterization, simulation — because it captures the universal structure of “something transforms inputs into outputs using parameters.”

Types of ODPs

There are several categories:

1. Content Patterns

The most common type. They provide domain-independent modeling solutions:

2. Structural Patterns

These address ontology architecture:

• Modularity — how to split a large ontology into manageable modules
• Alignment — how to connect your ontology to upper-level ontologies (BFO, DOLCE)
• Naming conventions — IRI patterns, label standards

3. Reasoning Patterns

These leverage OWL reasoning:

• Closure axioms — ensuring completeness
• Value partitions — modeling categorical properties
• N-ary relations — representing complex relationships that aren’t simply binary

How We Use ODPs in Materials Science

In our work on the MSE Knowledge Graph, we surveyed 15+ materials science ontologies and found that most contain implicit patterns — recurring structures that were never formally documented as reusable patterns.

We developed a method to automatically extract these implicit patterns and published them as an open catalog: ODPs4MSE.

Key patterns we identified:

The Process-Flow Pattern

Process → has_input → MaterialEntity
Process → has_output → MaterialEntity
Process → has_participant → Agent
Process → occurs_in → SpatiotemporalRegion

Used by: PMDco, MatOnto, EMMO, BWMD

The Measurement Pattern

Measurement → measures_property → Quality
Measurement → has_value → ValueSpecification
ValueSpecification → has_numeric_value → xsd:float
ValueSpecification → has_unit → Unit

Used by: QUDT alignment, OM, EMMO

The Material Composition Pattern

Material → has_part → Constituent
Constituent → has_proportion → Proportion
Proportion → has_value → xsd:float

How to Use ODPs in Practice

Step 1: Identify Your Modeling Problem

Before reaching for Protege, write down competency questions — what should your ontology be able to answer?

Example: “What materials were tested using nanoindentation at temperatures above 500°C?”

Step 2: Search for Existing Patterns

Check these resources:

• Ontology Design Patterns portal
• ODPs4MSE catalog
• Existing domain ontologies (they often contain implicit patterns)

Step 3: Adapt and Compose

Patterns are building blocks. Combine the Process Pattern with the Measurement Pattern to model “a tensile test that produces a stress-strain measurement.”

Step 4: Validate with SHACL

Write SHACL shapes that enforce your patterns. This catches data that doesn’t conform:

ex:ProcessShape a sh:NodeShape ;
    sh:targetClass mwo:Process ;
    sh:property [
        sh:path mwo:has_input ;
        sh:minCount 1 ;
        sh:class mwo:MaterialEntity ;
    ] .

Why ODPs Matter

1. Consistency — Multiple teams model the same things the same way
2. Reusability — Don’t reinvent the wheel for every new project
3. Interoperability — Shared patterns make ontology alignment easier
4. Learnability — Newcomers have concrete examples to follow
5. Quality — Patterns encode best practices and avoid common pitfalls

Further Reading

• Gangemi, A. (2005). Ontology Design Patterns for Semantic Web Content
• Blomqvist, E. et al. (2016). Ontology Engineering with Ontology Design Patterns
• Our paper: Semantic Representation of Processes with Ontology Design Patterns

Working on an ontology and not sure how to model something? Check if there’s a pattern for it first. And if you create a new pattern, please share it — the community benefits from every documented solution.

Two intense days at the NFDI-MatWerk All-hands-on-Deck meeting in Siegburg! Huge kudos to the organising team for making it so fruitful. Loved connecting with the MatWerk community, reflecting on Phase 1 achievements and getting excited for Phase 2. Big shoutout to the @fizise team: @enorouzi @heikef Hossein Beygi Nasrabadi and Alsayed Algergawy!

@fiz_karlsruhe #NFDI @nfdi4culture @NFDI4DS #materialsscience #AI #ontologies #knowledgegraphs #semanticweb #researchdata

View original post

Yesterday, our colleague @enorouzi won the “Best Demo” award at the NFDI-MatWerk All-hands-on-Deck meeting in Siegburg with his presentation of the MSE Knowledge Graph. Congratuzlations 🎉

MSE-KG Webpage: https://nfdi.fiz-karlsruhe.de/matwerk/

#knowledgegraphs #ontologies #AI #materialsscience @NFDI @nfdi4culture @NFDI4Memory @NFDI4DS @fiz_karlsruhe @lysander07 @heikef #Siegburg

View original post

Today, at the NFDI-MatWerk AHoD Meeting in Siegburg: @enorouzi is giving a demo on out MSE-KG, the knowledge graph-based infrastructure for research data of the consortium.

The MatWerk KG: https://nfdi.fiz-karlsruhe.de/matwerk/

#ontologies #knowledgegraph @NFDI #NFDIMatWerk #researchdata #NFDIrocks #Siegburg #materialsscience @fiz_karlsruhe @nfdi4culture @NFDI4DS

View original post

🚀 PMD core ontology (PMDco) v3.0.0 Release

This release marks a major milestone for the #PMD working area Semantic Interoperability and reflects several years of joint conceptual work, implementation, discussion, and validation across projects and disciplines.

GitHub: https://github.com/materialdigital/core-ontology PMDco 3.0.0: https://materialdigital.github.io/core-ontology/index-en.html# Docs: https://materialdigital.github.io/core-ontology/docs/

#ontologies #materialsscience #materialdigital #AI #symbolicAI #knowledgerepresentation @fiz_karlsruhe @joerg @enorouzi @lysander07

View original post

We are happy that our new paper “NFDI MatWerk Ontology (MWO): A BFO-Compliant Ontology for Research Data Management in Materials Science and Engineering” is being published by Advanced Engineering Materials as #openaccess This is joint work with Hossein Nasrabadi, @enorouzi Kostiantyn Hubaiev, @joerg and @lysander07 https://advanced.onlinelibrary.wiley.com/doi/10.1002/adem.202502331

#ontologies #semanticweb #nfdimatwerk #BFO #knowledgegraphs @fiz_karlsruhe #nfdirocks @nfdi4culture @NFDI4DS @NFDI4Memory

View original post