buildingSMART Forums

IFC Modernization : Relationships


I suspect relationships were adopted due to the strong dependency on EXPRESS and STEP in design. Having a class serialized to STEP with lots of direct attributes isn’t ideal as every single attribute needs to be noted (even if null/empty).

I’d like to see many relationships made obsolete, although it might be that xml (or something similar) should be a dominant serialization format for this to happen.

Minimum I’d like to see the class they inherit from be changed from IfcRoot particularly so that Global Ids aren’t manufactured in many authoring applications.

1 Like


Step one is to take them out of IfcRoot.

Is it possible to develop a new IFC based on just end entity? I mean a much shallower tree.

For instance, IFC just has end entities like

So on

And drop all behind entities and just end entities (single entities) have types, rules, functions, and “simplified relationships”

Kind regards,

What if I want to track the changes in a relationship?

1 Like

Relationships will modernize and will be part of the “end single entity”

I’m thinking to a hybrid IFC schema which would be based on SQL and NoSQL.

In SQL part, I think we can use SQLite, but its “DATA TYPEs” has limitation and for geometries I’m looking for an alternative

@ReD_CoDE, what would be the benefit to only have such leaf-node classes? Isn’t it the purpose of object-orientation to use inheritance to share common relationships and functionality?

Agree to @jonm, that many of the relationships could be combined and simplified, e.g why having specific relationships to attach classification, documentation and library references - it should be only one to expand the definition of a class by additional alphanumeric content. But it needs to be discussed also in line with backward compatibility issues. And such relationships don’t require a persistent guid, since they are created for serialisation, and do not hold own and persistent information.


I’m not a programmer, but because of our existing startup I have to learn the existing solution as much as I can, at least general things

So, as I know generally, if a data structure has a “structured form” it’s better use “relational databases” --> SQL
If the data structure is “complex and unstructured” form then is better use “Object-Oriented database”

So, the IFC data structure is complex? Unstructured?
If not, why was it originally developed based on Object-Oriented approach?

So I think “SQL” would be a better choice for schema (It’s fast, has better performance, is clear and doesn’t cause headache and lot of mistakes, etc)

But all “information systems” would be “Object-Relational Systems” which have a “Relational database” and “Object-Oriented frameworks”

"While object-oriented and relational design share some common characteristics (an objects attributes is conceptually similar to an entities columns), " - So, what this means that IFC is possible to be modelled both ways, the EXPRESS schema allows it. For exchange a file format makes sense as you can generate a physical file that you exchange. For archiving data, databases make sense (SQLite being one of them). It all depends on (as always) context. If you read the IFC formats page on the bSI technical site, it even mentions SQLite as a possible format.
This statement “So I think “SQL” would be a better choice for schema” is not in context though. The schema is in EXPRESS (as of late also UML). These are data modelling languages. One of their representations is SPF, another one can be SQLite or others …

As I have asked @jonm above, what if I want to track changes of a particular relationship? In that case an ID and owner history suddenly make sense. As we are talking about IFC representing a the entire life cycle, I think we should not be to hasty with removing this.

So, who will build IFC SQLite? As we know, it’s “an unfinished project” inside the buildingSMART

Also, as you say an ID, but that ID should be GUID/UUID?
It seems that GUID/UUID is an old-fashioned approach today

“So, who will build IFC SQLite?” - Whoever needs it. The same as SPF. Companies who wanted to exchange data got themselves certified and are now using it.

“Also, as you say an ID, but that ID should be GUID/UUID?” - Yes. Could be anything else from my point of view, but as UUID ensure universal uniqueness, I think it is quite well suited for the task.

“It seems that GUID/UUID is an old-fashioned approach today” - GUID/UUID is not an approach, it is a " A universally unique identifier ( UUID ) is a 128-bit number used to identify information in computer systems. The term globally unique identifier ( GUID ) is also used, typically in software created by Microsoft." - Wiki
Also, the discussion is not about dropping UUID as the problem lies in that they are not unique. Relationships might not even need them.
If you say old-fashioned, any proposals on how do uniquely identify an instance?

Hi @sergej - I did not argue to remove the capability of holding a UUID for relationships - but it should not be enforced in any case and thereby leading to “fake” UUID. I think it is better to keep UUID for relationships optional on schema level and only impose it to be mandatory, if a particular implementation/exchange scenario requires it