buildingSMART Forums

What would you like to see most in the "modernization" of IFC?

@ReD_CoDE, @yorik - are you guys serious? Exactly because of complex concepts and relationships (with inheritance so that attributes are not redundant) that everyone can agree on (ISG and certification) we can even come close to start exchanging data. A 200MB model can have all kinds of different geometry representations for various objects. Your " IFCCLOSED2DPROFILECOMPACT" is broken with an arc already, let alone something “fancy”. :slight_smile: Have you taken a look at IfcIndexedPolyCurve?
Your owner history example goes away from the concept of object oriented models. You want to parse strings where you should have structures and types that allow you to get away from compliance errors. You could go all the way with simplification -> go back to PDFs. In the end, an IFC SPF does not need to be human readable. Isn¨t that the whole point? Digitization and automation.

Dear Sergej,

IFCCLOSED2DPROFILECOMPACT” concept represents a familiar structure we see in the world, especially related to 2D and 3D Javascript geometries:

You know, and all we know, with current IFC structure we won’t achieve “a real” digitization and automation

It’s like building a beautiful building on a “weak” foundation and I ensure that “all” countries that work on national digital projects have felt this

Why don’t build IFC based on modern things that are available today? Instead of “insist” on ideas and technologies which were good 20 years ago?

Take a look at the majority of resources on buildingSMART, most of them are for “10” years ago

Relax, not trying to push a standard change here, just playing with the idea, which is what this topic proposes… In any case, providing alternative, compact ways to “reduce” (maybe REDUX is cooler than COMPACT :thinking: ) some “bunches” of data does not mean everybody would be forced to use it…

1 Like

I was referring you to existing possibilities. I think IfcIndexedPolyCurve does what you ask and more. Why would you need another redundant definition in a schema that is already quite substantial. Just means less implementers will support it.

yes, the IfcIndexedPolyCurve provides you with this capability. See attached a document that was created to justify the addition of a new class. And please have in mind, that IFC is currently used by >250 software applications worldwide, with millions of IFC files around - so one can’t just “do and change”.

see: IFC4_Add1_IndexedPolyCurve_Definition.pdf (314.2 KB)

Nevertheless - thinking about a new generation of IFC using modern, web-based technology is needed, while maintaining the existing technology stack to guarantee compatibility.


A new generation of IFC tools that are cross platform (I’m looking at ya, IfcDoc!) Is good! A new generation that relies on an entire web stack as an application platform ? Not a good idea! Feel free to provide a web UI, but don’t couple the code to the web. Even web devs don’t do this anymore for serious applications.

1 Like

Dear friends,

Your feedback is highly appreciated and will help us to improve IFC and build a new interactive IfcDoc

Thomas, I want to be super clear that I’m not proposing breaking existing implementations. And it’s possible that I’m conflating two discussions: the improvement of the IFC schema, and the development of new technologies around bringing the standard to cloud workflows. These can be separate discussions, but like any lazy programmer, I’m trying to figure out if we can make improvements that advance the standard in both contexts so we don’t end up with the “IFC for the desktop” and the “IFC for the cloud.”

1 Like

I say let’s drop IfcRoot, IfcOwnerHistory, and IfcObjectDefinition, …, and just have the end one
For instance an IfcWindow is just an entity --> We can with “CLASSIFICATIONS” say that a window is an object, a product, an element, a building element

I appreciate your energy in suggesting to reduce the number of types in the schema. But I think you don’t understand that many of those types are “abstract”. They represent levels in the inheritance hierarchy but are not the types that are stored in IFC. For example, you won’t find an instance of IFCROOT written to an IFC file. But The IFCROOT Entity has properties which are inherited by all of its derived types. You CANNOT remove those entities from the schema without breaking the dependency tree.

1 Like

Dear Ian,

My suggestion is clear: I say in output, Ifc file (SPF) the output is this:

#1=IFCPERSON($,$,'Yorik van Havre',$,$,$,$,$);
#4=IFCAPPLICATION(#2,'0.19 build 16944 (Git)','FreeCAD','118df2cf_ed21_438e_a41');

So, let’s redesign the schema like this too
Instead of having 4-11 layers tree, let’s have a 1-4 layers tree which is so close to the output file

I get it. And like I said, you can’t. Unless you want to duplicate the attributes belonging to all parent entities across all of the derived types, which would do the opposite of simplifying the schema.


Yes, I understand what you say, atomic approach

However, I think if “schema” be easy to use (especially in automation and control systems) with less “entities” and “types”, but the size of it increases, this is not a problem

Especially when the majority of them are “Optional” which I see this as a weakness inside the existing schema

If you reduce many things, and move all relationships and instances in just 1-4 layers (entities), in the final schema the consequent of things dropped and things duplicated would be nothing more than existing schema in structure and in size

For instance in IfcWindow example, we easily can drop IfcObjectDefinition, IfcObject, IfcProduct, IfcElement, IfcBuildingElement, and with classifications control the sitatuion


As said before we can reduce IFC schema layers and instead use classifications to say a window is an object, a product, an element, a building element

Also, ISO 19650 naming approach can help us develop a better way than just GUID/UUID (in 128-bit approach) for identification

For the past few months, there has been discussion within the bSI technical community to look forward at the architecture of IFC. As part of this discussion, it is important to understand that there are different components, such as:

  • Description Method - including the Definition Language (UML vs. EXPRESS, etc.) and Data Formats (STEP, XML, JSON, etc.)
  • Specification - including the structure and content of the schema and possible extensions like Taxonomy and Data Dictionary
  • Implementation Methods - including File-based (P21-STEP, XML), Database (Relational-SQL or Triplestore-SPARQL) and even Web-based (openAPI or GraphQL).

I think to make any headway on many of the discussions recently launched in this Forum, it also helps to have everyone step back and take a broader view before launching into “…well I can make it better if you all just do it this way instead…”, especially when jumping into implementations/executions before understanding many other points of view.

There are many requirements that must be fulfilled in any case of moving the development forward. This includes, but is not limited to:

  • Legacy compatibility (versioning, STEP/XML, file-based workflows, etc.) which is VERY important to existing and long time users with existing IFC files;
  • Posterity, where any long-term vision (25-50-75+ years?) of development and deployment must be viable and accessible;
  • Ease of use, not necessarily for everyday BIM end users, but considering modern and best practice methods for development now and debugging by completely new actors in the future, some large, some small, some less sophisticated than others;
  • Flexibility, enabling schema content to expand and/or contract based on needs that have been evaluated at critical times. This may include “modularization” which helps specific stakeholders create tailored semantics, context, and content for specific market needs while still having a valid overall relationship to the general scope, semantic structure, and transactional capability of the data;
  • Industry-specific, the data that the building and infrastructure domains generate is much different than much of general manufacturing, commerce, and services. There are complex relationships and many attributes that are important to capture and enable many types of transactions;

So, I ask that everyone take a deep breath and maybe step back for a moment and look at this from a higher-level before diving too deep into the debates that appear to be heating up.


I would like to clarify the below misunderstandings of IFC’s capabilities.

In IFC, you are able to describe multiple sites, and multiple buildings.

In more concrete terms, an IfcProject can contain through IfcRelAggregates multiple IfcSite objects. Each IfcSite, can have its CompositionType parameter set to COMPLEX, for instance. Each IfcSite can then have another IfcRelAggregates to decompose itself into another IfcSite object, which also has a CompositionType parameter set to ELEMENT or PARTIAL. The spec currently allows up to 3 levels of IfcSite nesting (COMPLEX -> ELEMENT -> PARTIAL). This arbitrary limitation of 3 levels deep may be removed in a future IFC version.

Similarly, each IfcSite, seemingly at any level of CompositionType, can contain one or more IfcBuilding objects. Each IfcBuilding object has the same 3 levels of CompositionType. (COMPLEX -> ELEMENT -> PARTIAL) The spec is a little bit more specific here, nominating that the COMPLEX type refers to a “building complex”, like a group of buildings, and an ELEMENT type is a single building. This creates a bit of ambiguity whether or not a group of buildings is a one to many IfcBuilding (COMPLEX) -> IfcBuilding (ELEMENT) or if a group of buildings is a one to many IfcSite -> IfcBuilding (ELEMENT).

This page about IfcSpatialStructureElement describes how it works, and shows that it applies to any spatial structure. So my description applies to things like IfcSpace too, and now maybe even IfcFacility in the new spec.

In short, despite the ambiguity, which hopefully somebody (@TLiebich ? @jonm ? ) can clarify, it is clear that IFC supports more than one site and building.

1 Like

In COBie, instead of Building we have “Facility
So, I think Facility was/is a good choice, but I don’t know why it didn’t nominate to be in IFC, maybe @TLiebich know.

All in all, in the near future, all other IFCs like Infrastructure, … all will merge with current IFC and from now it’s better choose better definitions and structures to have a coherent as well as accurate IFC schema

Some insights:

Spatial/project structure in IFC is inherently connected. As you have established, there is a 3 level decomposition currently in place for every single spatial structure element of a particular type (as you have explained). This limitation is not really embedded into the schema and is mainly bound to MVDs. There is no rule preventing you from having an IfcBuilding decomposed into 5 levels.

That being said, I am not familiar with software that allows decomposition of a particular spatial structure element into spatial structure elements of the same type. So, use of CompositionType is not really widespread. :slight_smile:

Talking about more than one IfcSite or more than one IfcBuilding in one IFC file is another matter. An IfcSite is able to contain more than one IfcBuilding as well as an IfcProject can be composed of more than one IfcSite. For this issue, there are no limitations either in the schema nor in the Reference View MVD. I am not familiar with Implementer agreements on this matter. Maybe they restrict it.