Building a Domain-Specific NER Dataset for BIM & IFC

Bridging Text and BIM Data

Introduction

In the Architecture, Engineering, and Construction (AEC) industry, we work with highly structured data, especially when dealing with open standards like IFC.

Yet most of our communication still happens in plain natural language:

• “The wall is made of reinforced concrete.”
• “The door has a fire rating of 60 minutes.”
• “This space belongs to Level 2.”

Bridging the gap between natural language and structured BIM data is not trivial.

This article documents my first step in that direction:

👉 Building a custom Named Entity Recognition (NER) dataset tailored for BIM and IFC workflows.

Why Build a Custom NER Dataset?

General NLP models are not trained to understand:

• IFC entities like IfcWall, IfcDoor, IfcSpace
• BIM properties like FireRating, LoadBearing
• Materials such as ReinforcedConcrete
• Relationships like containment or aggregation

If you feed such sentences into a general-purpose NER model, it won’t properly classify domain-specific concepts.

So instead of trying to force a generic model to work, I decided to:

Create a small but structured domain-specific dataset focused on BIM semantics.

The long-term goal is simple:

Text → Structured BIM knowledge

For example:

“The external wall is load-bearing and made of concrete.”

Should become something like:

Entity: IfcWall
Property: LoadBearing = True
Material: Concrete

Defining the Scope

To keep the project focused and realistic, I limited the scope to:

• IFC entity names (Wall, Door, Slab, Space…)
• Properties (FireRating, LoadBearing, IsExternal…)
• Materials
• Basic relationships (part-of, belongs-to, contains)

This is not a general NLP dataset.

It is domain-focused and intentionally constrained.

Dataset Design Strategy

Instead of collecting random real-world text, I designed synthetic but structured sentences.

Why?

Because:

• It allows full control over labels.
• It ensures coverage of important IFC concepts.
• It avoids data privacy issues.
• It makes annotation consistent.

Sentence Variations

To avoid overfitting to a single sentence style, I generated multiple variations:

1. Standard declarative sentences: “The wall is load-bearing.”.
2. Alternative syntax: “Load-bearing wall in the building.”.
3. Passive voice: “The wall is constructed using concrete.”.
4. Question style: “Does the door have a fire rating?”.
5. Multi-property sentences: “The external wall is load-bearing and has a fire rating of 60 minutes.”.

This introduces linguistic diversity while preserving semantic clarity.

Annotation Format

The dataset follows a token classification structure suitable for transformer-based models.

Each token receives a label such as:

• B-IFC_ENTITY
• B-PROPERTY
• B-MATERIAL
• B-RELATION
• O (outside)

Each example looks like:

{
  "tokens": ["The", "wall", "has", "height", "3.0", "meters"],
  "bio": ["O", "B-IFC_ENTITY", "B-RELATION", "B-PROPERTY", "O", "O"]
}

This makes it directly usable for fine-tuning models like BERT-style token classifiers.

Why This Matters

In BIM workflows, structured data is everything.

If we can reliably extract structured meaning from text, we unlock:

• Text → IDS (Information Delivery Specification)
• Text → structured IFC constraints
• Natural language validation of BIM requirements
• BIM-aware chat assistants
• Rule generation from requirements documents

This is a small step, but potentially foundational.

Technical Stack

The dataset was generated programmatically using Python.

Dataset Release

The dataset has been published on Hugging Face for reproducibility and experimentation:

👉 https://huggingface.co/datasets/mazri24/ifc_ner_dataset

It is structured in a standard token-classification format and can be directly used with the Hugging Face Trainer API.

Future updates may include:

• Larger vocabulary coverage
• Real-world requirement documents
• Additional IFC relationship types