IFC5: The Complete Guide
IFC5: The Complete Guide
What changes, what it means technically, why it matters for digital twins, AI, and the entire global BIM ecosystem — and what your organisation needs to do before 2028
By The AEC Intelligence Editorial Team · AI Workflow Blog · Published May 2026 · Last Updated May 2026 · 35 min read
Editorial Note: IFC5 is under active development by buildingSMART International as of May 2026. The specification has not been finalised. All technical details in this article are based on buildingSMART’s published working drafts, IFC5 Roadmap documentation, Technical Room meeting notes, and presentations at buildingSMART summits through Q1 2026. Details are subject to change before final publication. Expected finalisation: 2027–2028.
Why You Need to Read This Now
IFC4.3 has been the global standard for less than two years. Yet IFC5 is already reshaping how BIM vendors, government agencies, and AI developers plan their next generation of products. IFC5 is not an incremental update. It is a fundamental rearchitecting of the standard — from a file-exchange format for buildings into a semantic, linked-data, real-time-capable platform for the entire built environment. The transition will affect every software product, every government mandate, and every BIM workflow on the planet. The window to understand it and prepare is now.
Contents
1 — What Is IFC5? The 30-Second Version
IFC (Industry Foundation Classes) is the open, vendor-neutral standard for exchanging building information between software applications. It is maintained by buildingSMART International and published as ISO 16739. Every time a Revit model is exported to ArchiCAD, every time a contractor runs a federated model in Navisworks, every time a government requires an open BIM deliverable — IFC is the language in use.
IFC5 is the next major version, currently in development. Here is the clearest one-sentence summary of what makes it different from every previous version:
IFC4 and earlier: a file format for exchanging a snapshot of a building model.
IFC5: a semantic web-based, living knowledge graph of the built and natural environment, capable of real-time updates, AI queries, and integration with IoT, GIS, and urban-scale digital twins.
IFC5 changes not just what data is described but how data is structured, linked, and accessed. It replaces the 30-year-old STEP physical file serialisation with a linked data model based on W3C Semantic Web standards (OWL, RDF, SHACL). This is not a cosmetic change. It is a replatforming of the entire standard onto a modern, web-native foundation.
2 — The Problem IFC5 Is Solving: Why IFC4.3 Hits a Ceiling
To understand what IFC5 brings, you first need to understand the specific limitations of IFC4.3 that make a new version necessary — not merely desirable.
| IFC4.3 Limitation | Technical Detail | Real-World Consequence |
| Static file format only | IFC files are snapshots: export once, file is frozen. There is no native concept of partial model update, version delta, or streaming update. | Digital twins require continuously updated data. Connecting a live IFC4.3 file to real-time sensor data requires complex custom middleware on every implementation. No standard exists. |
| Closed vocabulary | IFC4.3 has a fixed schema. Adding a new concept (e.g., carbon embodiment data, acoustic performance, wildfire risk score) requires a schema change — a multi-year standards process. | Vendors use non-standard property sets (Psets) for everything the schema doesn't cover. These Psets are inconsistent across vendors and incompatible with automated data exchange. |
| No native GIS/urban scale | IFC4.3 has IfcSite and geographic reference points, but it is fundamentally a building-scale data model. Large infrastructure corridors, city-scale urban models, and landscape ecology are awkward or impossible to represent properly. | Smart cities, national infrastructure programmes, and urban digital twins must use GIS (CityGML, LandXML, Shapefile) alongside IFC, with no standard linkage between them. |
| Machine-unfriendly structure | STEP physical file format requires full graph traversal to reconstruct any entity. Partial queries ("give me all fire-rated walls above 50m elevation") are impossible without loading the entire file and parsing all relationships. | AI training and inference over BIM data requires enormous preprocessing. No standard query language exists for IFC data. SPARQL cannot be used without converting to RDF first. |
| No provenance or versioning | IFC4.3 has no native mechanism to track who changed what, when, and why within a model. | The UK Building Safety Act's "Golden Thread" requirement — a continuous audit trail of building changes — cannot be natively satisfied by IFC4.3. Custom tracking systems are required. |
3 — IFC5 Core Architecture: The Technical Shift from STEP to Linked Data
The most consequential change in IFC5 is invisible to most users but fundamental to every technical integration: the move from a STEP-based physical file model to a Web Ontology Language (OWL) / Resource Description Framework (RDF) semantic web model.
IFC4.3 Data Model (STEP / EXPRESS)
/* IFC4.3: Everything is an entity reference in a STEP file */ /* To find a wall's fire rating: parse entire file → traverse 15-20 entity hops */ #100 = IFCWALL('GUID-abc123', #2, 'Wall-001', $, $, #101, #110, $, .STANDARD.); #101 = IFCLOCALPLACEMENT(#5, #102); /* ... 40-200 more entity records to reconstruct this wall's geometry + properties */ #310 = IFCPROPERTYSINGLEVALUE('FireRating', $, IFCLABEL('2HR'), $); #311 = IFCPROPERTYSET('GUID-pset01', #2, 'Pset_WallCommon', $, (#310,...)); /* FireRating is buried 4 relationship hops from the wall entity */ /* No standard query to retrieve it without loading the whole file */
IFC5 Data Model (OWL / RDF / SPARQL-queryable)
/* IFC5: Every concept is a URI-identified node in a knowledge graph */ /* Entities are directly queryable via SPARQL from any endpoint */ @prefix ifc5: <https://standards.buildingsmart.org/IFC/DEV/IFC5/FINAL/OWL#> . @prefix bsdd: <https://bsdd.buildingsmart.org/> . <urn:ifc5:wall:abc123> a ifc5:IfcWall ; ifc5:name "Wall-001" ; ifc5:predefinedType ifc5:STANDARD ; ifc5:fireRating <bsdd:FireRating/2HR> ; /* linked to bSDD dictionary */ ifc5:containedIn <urn:ifc5:storey:level02> ; ifc5:geometry <urn:ifc5:geom:brep-abc123> ; ifc5:modifiedBy <urn:agent:engineer-kim> ; /* provenance built in */ ifc5:modifiedAt "2026-03-15T09:22:00Z"^^xsd:dateTime . /* SPARQL query: find all fire-rated walls above 50m elevation — in ONE query */ SELECT ?wall ?rating WHERE { ?wall a ifc5:IfcWall ; ifc5:fireRating ?rating ; ifc5:elevation ?elev . FILTER(?elev > 50.0) }
The architectural implications of this shift are profound:
| Capability | IFC4.3 (STEP) | IFC5 (OWL/RDF) |
| Query language | None (parse whole file) | SPARQL 1.1 — standard W3C query language |
| Partial model access | No — must load entire file | Yes — query any subset via HTTP endpoint |
| Real-time updates | No native mechanism | Yes — linked data nodes updatable independently |
| External data linking | Custom Psets only | Native URI linking to bSDD, GIS, IoT, weather, financial data |
| Extensibility | Requires schema change (years) | Add new classes/properties via OWL extension without breaking existing data |
| Provenance / audit trail | Not in schema | Built-in via RDF named graphs — who changed what, when, why |
| Web-native access | File download only | SPARQL endpoint, REST API, GraphQL adapter all possible |
| Scale | Building / campus scale | Building → city → national infrastructure — same model, same queries |
4 — What’s New in IFC5: Feature-by-Feature Breakdown
1. OWL Ontology as the Primary Schema
The entire IFC schema is being rewritten as a Web Ontology Language (OWL) ontology. Each IFC concept (IfcWall, IfcDoor, IfcBuildingStorey) becomes an OWL class with formally defined properties, restrictions, and relationships. This means:
Logical reasoning over the schema becomes possible. A reasoner can infer that if an element has the property ifc5:isExternalFacing true and ifc5:hasFireRating is not set, it must flag a compliance warning — without a human writing that rule. This is the foundation of automated regulatory checking at scale.
2. Native Urban and Infrastructure Scale
IFC5 introduces a formal territorial/urban spatial structure above the building level. The hierarchy extends from IfcSpace → IfcBuildingStorey → IfcBuilding → IfcSite to include IfcUrbanDistrict → IfcCity → IfcRegion → IfcNation, with native support for geospatial coordinate reference systems (CRS) at every level.
Critical: IFC5 natively bridges with GeoSPARQL, the W3C standard for geospatial linked data. A building element in IFC5 can be queried alongside GIS datasets, OpenStreetMap data, satellite imagery metadata, and climate science data — in a single SPARQL query, without custom connectors.
3. Dynamic / Time-Series Data Support
IFC4.3 is fundamentally static: it describes the intended state of a building at a point in time. IFC5 introduces native support for temporal data — properties that change over time and are tracked with timestamps.
/* IFC5: Time-series sensor data linked directly to building element */ <urn:ifc5:hvac:ahu-23> a ifc5:IfcAirHandlingUnit ; ifc5:hasTimeSeries <urn:sensor:ahu23-temp> . <urn:sensor:ahu23-temp> a ifc5:IfcTimeSeries ; ifc5:seriesType ifc5:CONTINUOUS ; ifc5:unit <bsdd:Unit/DegCelsius> ; ifc5:endpoint "https://api.bms.example.com/sensors/ahu23/temp" ; ifc5:lastReading "22.4"^^xsd:float ; ifc5:lastReadingTime "2026-05-15T14:32:00Z"^^xsd:dateTime .
This allows the same IFC model to simultaneously describe the as-designed state (from construction), the as-built state (from commissioning), and the as-operated state (from live sensors) — in a single, coherent data structure.
4. Native Provenance and Change Tracking
IFC5 uses RDF named graphs to provide native provenance. Every triple (subject–predicate–object) can be annotated with: who asserted it, when, with what level of certainty, and from what source. This directly enables the UK Building Safety Act’s Golden Thread requirement and ISO 19650’s information management audit requirements — not as a custom extension, but as a core feature of the standard.
5. Open Extensibility via OWL
One of the most significant practitioner benefits: in IFC5, any organisation can publish an OWL extension ontology that adds new classes and properties to the IFC vocabulary without touching the core schema and without waiting for a buildingSMART schema revision cycle. A construction firm that needs to track embodied carbon at the product level can publish ext:embodiedCarbon as an OWL property linked to IFC5’s IfcProduct and immediately use it in any IFC5-compliant tool. This collapses the current multi-year standards-change process into a day’s work.
6. SHACL-Based Validation (Machine-Readable Rules)
IFC5 uses SHACL (Shapes Constraint Language) as a standard replacement for the current IDS (Information Delivery Specification) approach. SHACL constraints are OWL-native, meaning the same tooling that processes IFC5 data can directly validate it against project requirements, building codes, and LOD standards — no separate validator required. This is the technical foundation for fully automated BIM compliance checking.
5 — IFC5 and Digital Twins: The Integration Layer That Changes Everything
Digital twin platforms — Bentley iTwin, Autodesk Tandem, Azure Digital Twins, AWS IoT TwinMaker, the UK National Digital Twin Programme — all currently require custom connectors to bridge their live data models with static IFC files. This connector problem is the single biggest technical bottleneck in digital twin adoption. IFC5 eliminates it structurally.
The Integration Stack IFC5 Enables
| Layer | Technology | IFC5 Bridge |
| Physical sensors / IoT | MQTT, REST, OPC-UA | ifc5:IfcTimeSeries + ifc5:endpoint links sensor stream to building element |
| GIS / geospatial | GeoSPARQL, WFS, CityGML | Native GeoSPARQL integration; IFC5 URIs are GIS-queryable |
| Product data / specifications | bSDD, EU EPREL, Madaster | URI references link directly to bSDD product definitions and EU material passports |
| Energy / climate systems | EnergyPlus, IDA ICE, TRNSYS | Simulation results stored as IFC5 time series and linked back to model geometry |
| Maintenance / FM systems | IBM Maximo, Archibus, FAMIS | Maintenance records as RDF triples linked to IfcAsset; no COBie export required |
| Urban / city platforms | Smart City OS, Virtual Singapore | Building IFC5 model is a node in the urban knowledge graph; SPARQL queries span city |
What This Means in Practice
A hospital building described in IFC5 can simultaneously expose: its structural model to a structural analysis tool via SPARQL query, its energy consumption to a BMS via linked time series, its maintenance records to a CAFM system via linked RDF, its geographic footprint to a city GIS via GeoSPARQL, and its fire rating compliance status to a building safety regulator via SHACL validation — all from the same underlying knowledge graph, in real time, without a single custom connector or data export. This is what IFC5 makes structurally possible.
6 — IFC5 and AI: Why the New Format Is Built for Machine Reasoning
Every major limitation of IFC4.3 for AI training and inference — which we covered in our previous article on why AI cannot generate BIM models — is directly addressed by IFC5’s architecture. Here is a precise mapping:
| AI Barrier in IFC4.3 | How IFC5 Addresses It | Remaining Challenge |
| No standard query language | SPARQL 1.1 natively supported. AI agents can query building data without full file parsing. | SPARQL endpoints must be implemented by each software vendor. Adoption lag expected. |
| Training data inconsistency (vendor Psets differ) | All properties link to bSDD URIs — standard vocabulary across all vendors. Training data is semantically consistent regardless of authoring tool. | bSDD coverage must expand. Proprietary properties still possible as OWL extensions. |
| Context window size (whole file required) | Subgraph queries retrieve only the relevant triples. An LLM can ask "give me the MEP elements within 2 metres of grid line A-3" and receive only those elements. | 3D spatial SPARQL queries require GeoSPARQL extensions; not all spatial relationships are natively queryable. |
| No schema for temporal / operational data | Native time series support. AI models can train on design + as-built + operational data in a unified representation. | Real-time inference at building scale still requires low-latency SPARQL infrastructure that most firms don’t yet have. |
| No provenance for training data quality | Built-in RDF named graph provenance. AI training pipelines can filter data by certainty level, data source, and modification timestamp. | Depends on upstream discipline in populating provenance metadata correctly. |
The Big Picture for AI-BIM Developers
IFC5 does not solve the constraint-satisfaction and 3D geometric reasoning problems that prevent AI from generating building models. Those remain fundamental research problems. What IFC5 does is remove the data infrastructure barriers that make training good AI models on building data so difficult today. A world where building knowledge is queryable via SPARQL, semantically consistent via bSDD, and temporally tracked via time series is a world where AI-BIM research can make much faster progress.
7 — IFC5 Serialisation Formats: Beyond the .ifc File
One of the most immediate practical changes in IFC5 is the serialisation layer. The familiar .ifc STEP file is not being abandoned, but it becomes one of several supported formats. RDF-native formats become primary.
| Format | Extension | Based On | Use Case | IFC5 Status |
| Turtle | .ttl | W3C RDF Turtle serialisation | Human-readable RDF; developer tooling; version control | Primary IFC5 format |
| JSON-LD | .jsonld | W3C JSON-LD (RDF in JSON) | Web APIs, REST endpoints, web app integration | Primary IFC5 format |
| N-Triples | .nt | W3C RDF N-Triples | Bulk data exchange, AI training datasets, database loading | Supported |
| STEP (.ifc) | .ifc | ISO 10303-21 (legacy) | Backward compatibility with IFC4.3 tooling | Legacy / compatibility |
| SPARQL Endpoint | HTTP / REST | W3C SPARQL 1.1 Protocol | Live digital twin, real-time queries, IoT integration | Native IFC5 access method |
8 — Global Adoption Timeline and Government Mandate Impact
| Timeline | Milestone | Impact |
| 2024–2026 | IFC5 working draft finalisation; buildingSMART Technical Room development sprints; early implementer programme | Pioneer vendors (Autodesk, Bentley, Trimble, Nemetschek) participating in IFC5 Technical Rooms. First experimental implementations appearing. |
| 2027 (est.) | IFC5 published as buildingSMART standard; ISO 16739-2 process initiated | Certification programme opens. Early-adopter government pilots (Singapore CORENET X upgrade, UK NDT Programme, Netherlands BIM Loket) begin testing IFC5 workflows. |
| 2027–2029 | Major BIM software vendors ship IFC5 export/import; dual IFC4.3 / IFC5 period | Revit, ArchiCAD, Tekla, Civil 3D expected to ship IFC5 support 12–24 months after standard publication. IFC4.3 and IFC5 will coexist for a 5–7 year transition. |
| 2028–2030 | First government mandates begin specifying IFC5 deliverables for new projects | Singapore, Netherlands, and UK expected to be first movers. South Korea K-BIM 2030 programme may target IFC5 as the national standard for its 2030 full public sector expansion. |
| 2030–2035 | IFC5 becomes the primary standard; IFC4.3 enters legacy status | Major government mandates reference IFC5. IFC4.3-only tools face the same market pressure that IFC2x3-only tools faced after 2016. EU Construction Products Regulation digital passport requirements align with IFC5 bSDD linking. |
9 — IFC4.x to IFC5: Migration, Backward Compatibility, and the Real Cost
The shift from STEP to OWL/RDF is not a simple version upgrade. The data model is genuinely different. Here is an honest assessment of what migration will involve.
| Migration Task | Complexity | Who Bears the Cost | Tooling Available |
| IFC4.3 file → IFC5 Turtle conversion | Medium | buildingSMART will provide reference converter; vendors will ship migration tools | Reference converter in development (bSI) |
| Vendor-specific Psets → bSDD-linked properties | High | Software vendors must map their proprietary property sets to bSDD URIs. No automation possible; requires manual semantic mapping. | Partially (bSDD API) |
| Existing IFC4.3 archive models | Medium | Asset owners and archives. Conversion tools will exist; full semantic migration (provenance, bSDD linking) will be manual. | Geometry conversion: yes. Semantics: no. |
| BIM validation rules (IDS) → SHACL | Medium–High | EIR authors, BIM managers, government procurement teams | IDS→SHACL migration tools expected |
| BIM software IFC export engines | Very High | Software vendors. Requires re-engineering export pipeline from STEP serialisation to RDF graph generation. Multi-year project per vendor. | No; each vendor builds their own |
| SPARQL endpoint infrastructure | Medium (for IT teams) | CDE vendors, FM platform vendors, enterprise IT | Apache Jena, Blazegraph, Stardog, GraphDB (all mature) |
The Honest Reality of Migration Cost
The transition from IFC4.3 to IFC5 will be more disruptive than the IFC2x3 to IFC4 transition — because the underlying data model paradigm changes, not just the schema version. For software vendors, this is a 2–4 year re-engineering project. For government procurement, it means rewriting EIR templates, updating BIM guidelines, and retraining assessment staff. The organisations that start engaging with IFC5 in 2026 will have a significant advantage over those that wait until mandates force action.
10 — What Vendors, Governments, and AEC Firms Should Do Right Now
Software Vendors
Join the IFC5 Technical Rooms now. The schema is still being shaped. The vendors participating in Technical Room meetings today are the ones whose use cases will be reflected in the final standard. Joining buildingSMART as a Vendor Member and attending Technical Room sessions is the single most effective way to influence the outcome.
Begin OWL/RDF evaluation. Assess whether your internal data model can be expressed as an OWL ontology. Start with a proof-of-concept: convert a small IFC4.3 dataset to Turtle format and load it into Apache Jena. Run SPARQL queries. Understand what the developer experience will look like.
Map your Psets to bSDD. Begin the semantic mapping of your proprietary property sets to bSDD URIs now. This is the most labour-intensive part of the IFC5 migration and the one most vulnerable to delays if started late.
Government Agencies and Procurement Bodies
Participate in buildingSMART Government Member programmes. National standards bodies (KATS in Korea, BSI in UK, NEN in Netherlands, DIN in Germany) need to engage with IFC5 development now so that national mandate updates are aligned with the final standard, not racing to catch up after it publishes.
Begin pilot projects using IFC5 features. The National Digital Twin Programme in the UK, Singapore’s CORENET X, and Korea’s K-BIM 2030 should each be running IFC5 proof-of-concept projects in 2026–2027, before mandates need to reference it.
Plan EIR transition timelines. Procurement teams that currently write IFC4.3-specific EIRs should begin drafting the transition to SHACL-based requirement specifications and IFC5-compatible data requirements, targeting pilot deployments in 2027–2028.
AEC Design and Construction Firms
Do not panic, but do not ignore it. IFC5 will not replace IFC4.3 in your procurement requirements before 2028 at the earliest. You have time, but the time to understand it is now — not when your next EIR arrives with IFC5 requirements and you have no idea what Turtle format is.
Invest in semantic data literacy. The transition to IFC5 is also a transition toward RDF/OWL/SPARQL tooling. BIM managers who understand linked data concepts will be dramatically more valuable in the IFC5 era. Identify 1–2 people in your BIM team to begin learning these technologies now.
Audit your Pset hygiene. Every non-standard, vendor-specific, or inconsistently named property set in your current models will need to be mapped to bSDD in the IFC5 transition. The firms with clean, consistently attributed models will migrate orders of magnitude more easily than those with years of accumulated Pset debt.
Key Takeaways
| › | IFC5 is not a schema update — it is a platform change. The move from STEP to OWL/RDF/SPARQL is as fundamental a shift as the move from paper drawings to CAD was in the 1980s |
| › | IFC5 enables real-time digital twin integration, AI-queryable building data, urban-scale data models, and native provenance tracking — none of which are possible with IFC4.3 |
| › | The transition will take 5–10 years. IFC4.3 and IFC5 will coexist. But the competitive advantage for early-moving vendors, governments, and firms is substantial |
| › | For AI-BIM developers: IFC5 removes the data infrastructure barriers that make training on building data so difficult. It does not solve geometric reasoning — but it makes better AI-BIM research much more tractable |
| › | Korea’s K-BIM 2030 national programme, Singapore’s CORENET X, and the UK’s National Digital Twin are the three government programmes most likely to be early IFC5 adopters. These are the markets to watch first. |
About This Article
Part of The AEC Intelligence Report on the AI Workflow Blog. Based on buildingSMART IFC5 working draft documentation and Technical Room publications through Q1 2026. IFC5 specification details are subject to change before final publication.
By The AEC Intelligence Editorial Team · AI Workflow Blog · May 2026
Sources / References
› buildingSMART International — IFC5 Roadmap and Technical Room documentation — buildingsmart.org/IFC5
› buildingSMART International — IFC5 GitHub repository (working draft) — github.com/buildingSMART/IFC5-development
› W3C — OWL 2 Web Ontology Language Primer — w3.org/TR/owl2-primer
› W3C — SPARQL 1.1 Query Language — w3.org/TR/sparql11-query
› W3C — SHACL Shapes Constraint Language — w3.org/TR/shacl
› W3C — GeoSPARQL 1.1 (OGC/W3C) — ogc.org/standard/geosparql
› buildingSMART — IFC5 Technical Rooms: Infrastructure Room, bSDD Room, Digital Twin Working Group meeting notes (2024–2026) — buildingsmart.org/rooms
› buildingSMART — bSDD (buildingSMART Data Dictionary) API documentation — buildingsmart.org/bsdd
› ISO 16739-1:2024 (IFC4.3) — current standard reference — iso.org/standard/84123
› UK Centre for Digital Built Britain (CDBB) — National Digital Twin Programme: Principles — cdbb.cam.ac.uk
› Pauwels, P. et al. — Linked Building Data and the Semantic Web for the AEC Industry (Journal of Building Engineering, 2024) — sciencedirect.com
› Beetz, J. — ifcOWL: An OWL ontology for the IFC schema (Open Geospatial Consortium, 2023) — ogc.org
댓글
댓글 쓰기