buildingSMART Forums

Industry Foundation Classes are a Data Schema, not a file format

Often a discussion topic seems to divert to the topic of IFC being STEP/Express and it’s evident that many involved would like to see more modern exchange formats.

Here’s a discussion thread particularly on this topic.
Let’s start here:

The Industry Foundation Classes specify a data schema and an exchange file format structure

This data schema is then officially published into Express data model definitions, and the vast majority of implementations use STEP formatting of project data to exchange this. An XSD is also published, permitting xml to be used for the exchange in a reliable manner.

You can also note this statement within the scope

Alternative exchange file formats may be used if they conform to the data schemas.

There is no obligation to use EXPRESS for Industry Foundation Classes (which is an object oriented data schema independent of the programming language they are represented in and independent of the exchange format used to pass the data model from one process to another).

You can of course utilize a service to convert from one format to another if your implementation needs to receive or transmit models in formats not directly supported.

Already there have been efforts within buildingSMART to extend the documentation to offer other data exchange formats including Turtle and json. Others can be proposed and tested, and if they are popular then and effective then it might be that STEP is retired from common use at some point in the future (but for legacy I expect will still be recognized and supported).

As discussed in the summit at Dusseldorf, there have been changes implemented for IfcDoc ( the editor of the definition of IFC) and the IFC data schema should soon be published and available in a user friendly way that can have version control applied. I believe this will make it much clearer that whilst IFC is founded in express, it actually is isolated.

I would note that Express is a very efficient means to define the data model, and part of the challenge with other schema formats is how to nominate aspects such as Rules, Functions etc (for that reason many would like to see them removed).

I would also note that there is a lot of improvements to make to the data schema (including simplification). I do believe that this ability to apply version control to the data schema will make a huge difference in allowing a larger group to work on improvements and test proposals etc in a faster and more efficient manner.


Dear Jon,

The situation in the industry is like this: “All want a Formula 1 car, but have the technology of a normal car, for instance Peugeot technology”

With current technologies and methodologies in the industry talking about Industry 4.0 or Digital Twin(s) are just a joke

I shared a bunch of my insights on LinkedIn and hope you read it.

There are more obstacles than just IFC file format and for sure some will work on them and will solve them, especially Americans

Digital Twins seems to be far ahead of us, still, but at the same time I would say a Peugeot also does have the ability to serve us with fast technology… :wink:

In Persian we have a proverb says: “Everything that is round is not walnut”

Few in the world work on Industry 4.0 and Digital Twin and clearly know obstacles
Others just talk about and have waited others solve the issues

For sure, few know what have I said?

the more i think of a digital twin the more i see it as a new (higher) level of information structuring due to its personalisation.

the second reason is twin’s handling of big data, scaling it down to the personal, narrow channel.

what will be the next information exchange format for this? sql derivates?

For sure it would be based on SQLite/SQL plus JSON

Like always I see two different approaches in the world:
When Europeans mostly have focused on Graphs and XML(XMI), Americans have focused on SQL-based plus JSON approaches

And my experience says, count on Americans more, because they always think “long-term” and choose better technologies/metodologies

Also, today I strongly believe that “A real Digital Twin in Digital Built Environment has not born yet” :wink:

tesla cars by elon musk… although hacked by chinese in april this year :wink:

Thanks Jon, for making this very good point here. I would read the Industry Foundation Classes documentation the same way, as an object oriented data model to describe AEC industry data (or possibly other fields as well). There shouldn’t be any obligation to use a specific file format as long as it can represent the data schema. A modern and more widely adopted file format could be very beneficial for IFC adoption in my opinion and I think it’s something we should discuss.

1 Like

I think Jon @jonm clearly knows where’re the “Gordian knots” today?

I explained one of the important ones some months ago as:

… the logic behind the IfcDoc tool makes the IFC schema and the IFC schema development more dependent on its data modeling tool which today has issues and buildingSMART International has started to develop it again based on UML, but in reality, UML will not solve the dependency barrier, likewise. - Source

Personally, have waited to see what would be IFC after redesigning it based on UML

The second vitally important part is related to new IDM called IDM Configurator/Toolkit
I saw some good improvements which come from ISO19650

The third vital part for me is a schema and also .ifc file that is federated/separated
For instance, IfcControl is a separated schema that integrated with other schema parts

It seems that STEP 2017 lets we have a lot of .ifc files and integrate them together