Can an IFC STEP file contain entities that are not in a direct or indirect relationship with the spatial structure?

Developers IFC (General Development)
1

A scientific article was just released, with the title:

“Cypher4BIM: Releasing the Power of Graph for Building Knowledge Discovery”

(I am not allowed to share the link in this forum)

This article gives some examples of how to use cypher to query IFC in a graph database.

The queries in this article assumes, there is only one building in the database. Of course it is possible to create several databases, one database for each building. But it could also make sense to allow multiple buildings in one graph database.

Not only multiple IfcBuilding-objects, but also multiple IfcSite-objects and multiple IfcProject-objects.

Then the next question is how to query the graph when there are multiple IfcProject-objects in the same database. If you for example only want results from a specific IfcProject-object or a specific IfcSite-object or only from a specific IfcBuilding-object.

This has to be done using Cypher.

One easy way to limit the query, would be to filter out a subgraph in a relationship directed FROM the IfcBuilding-object, IfcSite-object or IfcProject-object.

This is the reason why I would like to ask the following question:

Are all entitites/objects in an IFC step file connected somehow (directly or indirectly) to eachother, or to a specific node. For example to the root of the spatial structure: the IfcProject-object …?

When I write “indirectly” I mean relationships in many steps.

Or can an IFC STEP file contain information (i.e. entitites/objects) that are not somehow in a indirect (or direct) relationship to the spatial structure?

…?

2

There is only one IfcProject. This is why this is often the entry point into parsing a model.
Many entities are not linked into the Spatial Structure, but can be found via specific relationship objects.

Your question is very broad, so I can only give a very broad answer.

3

If an object can be found, by going from the IfcProject-object, and traversing one or more relationships, objects, relationship objects, etc… then this object has an indirect relationship to the IfcProject-object (via one or more other relationships and objects).

So this case was not what I was looking for.

I am looking for objects that are completely detached from the network of objects related to the IfcProject-object.

My questions is not that broad:

Can there be objects that are not related to the spatial structure at all, i.e. not related to an IfcProject-object at all, neither directly nor indirectly (via other objects, such as relationship objects).

I am talking about objects that are not linked in any way, no matter how many indirect links and relationship objects there are, between this object and the IfcProject-object

I am talking about obects that create a completely separate detached network, but are stored in the same STEP file.

It is a yes or no question. I assume the answer is no. But I am not sure, so I would like someone to prove that I am wrong.

4

I think there is no WR or validation check that prevents an orphaned subgraph. So the valid / invalid answer is probably “yes, it can contain orphaned entities”.

However, I strongly believe the intention is that everything is linked back to IfcProject.

I also believe there are usecases where this intention falls short, such as those using native IFC for material and profile libraries (which are non-rooted) which therefore are difficult to link back to the IfcProject.

I also know that there are lots of IFCs out there in the wild that violate this intention, but from what I’ve personally seen I’d say they’re almost always due to software bugs (except for those powerusers attempting to do partial exchanges and libraries of those unrooted element examples I just gave and whatnot).

5

I define “rooted class”, as a class that inherits from the IfcRoot class. But an inheritance relationship among classes in a schema… is not the same thing as relationships among instances/objects/entitites in IFC data.

So I don’t understand why objects belonging to non-rooted classes, would be more difficult to trace back to an IfcProject-object, then objects belonging to rooted classes.

I assume there are many non-rooted classes that can be traced back to the IfcProject object. For example an IfcInteger-object.

But in this case I am not talking about the Class hierarchy. I am talking about the relationships between objects/instances/entities.

Some of those relationships between instances, can be via “relationship objects”.

In BlenderBIM it seems like Types are sorted under an IfcProject-object (in the outliner). But I can’t se if there is some kind of indirect or direct relationship to the IfcProject-object in the IFC data → i.e. in the network of instances/objects/entitites.

6

The reason I distinguish between rooted and non-rooted is because IFC does define how to connect (almost?) every single rooted element back to the IfcProject. For example, you mention types, which is mentioned in the Project Declaration concept or IfcRelDeclares.

See 4.1.9.2.2 Project Type Definitions - IFC 4.3.2 Documentation

However, IFC does not define how to connect non-rooted elements (of which profile, material, and styles are debatably significant) back to the IfcProject in any documentation page that I am aware of. So for example if I want to have a project library of IfcMaterial and nothing else … how should I link that back to the IfcProject?

7

I remember an issue on BlenderBIM github about where to put library objects. Under IfcProjectLibrary or under IfcProject.

I remember that library types originaly were sorted under IfcProjectLibary, but that they also could be sorted under IfcProject. And this was the choice.

And now I see in BlenderBIM, that library objects (Types, Materials et.c.) are sorted under IfcProject in the outliner. The IfcProjectLibrary-object is not used anymore.

However.

If there is an object. An object that is part of the network of objects that are indirectly linked to the spatial structure, i.e. to the IfcProject-object.

And if this object uses a type or a material detached from the spatial structure network. Then maybe there will be a relationship to that type or to that material.

For example. Every IfcWall-object, that belongs to an IfcWallType-object will have an IfcRelDefinesByType-object-relationship to that IfcWallType-object.

IfcRelDefinesByType (buildingsmart.org)

This would mean that all types and materials that are used in a project will be part of the network originating from the IfcProject-object. And no types and no materials that are used in a project will be detached/orphaned from the project.

I also have a memory that if an IfcProjectLibary-object is used for an IfcProject-object. Then the IfcProject-object should link to the IfcProjectLibrary-object used.

This means that no types or materials that are used in the IfcProject-object will be completely detached from the network of objects that are indirectly related to IfcProject-object.

See “Project declaration” for the IfcProject class, in the building smart schema.

IfcProject (buildingsmart.org)

Project Declaration (buildingsmart.org)

However, if more then one IfcProject uses library objects from the same IfcProjectLibrary. Then the IfcProject networks will be merged via that IfcProjectLibrary.

I.e. there will be relationships to traverse between multiple IfcProject-objects.

8

Yes, if there are physical objects (e.g. wall occurrences) that use types and materials and so on, then it is easy to describe everything going back to the IfcProject.

However I am talking specifically about the scenario of when there are no physical objects. For example:

IFC explicitly allows you to do this:

IfcProject ← IfcRelDeclares → IfcWallType

The IfcWallType is not used anywhere else. It is simply declared. You can do this for all sorts of stuff, like WorkSchedules and whatever.

However, specifically for non-rooted things of significance, IFC does not explicitly say what to do if you want to have:

IfcProject ← ??? → IfcMaterial

Does that help clarify?

9

Aha.

An IfcRelDeclares-object links an object that inherits IfcContext, with one or more objects that inherits IfcDefinitionSelect.

IfcRelDeclares (buildingsmart.org)

Every object that inherits IfcDefinitionSelect, is a rooted object. Because IfcDefinitionSelect inherits IfcRoot.

IfcObjectDefinition (buildingsmart.org)

IfcMaterial does not inherit IfcDefinitionSelect, and should thus not be linked from an IfcProject-object via an IfcRelDeclares-object

This means that IfcMaterial-objects that are defined in the STEP file, but not used in the project, will be detached from the network of the spatial structure originating at the IfcProject-object.

However, all materials that ARE used by any object in the project, WILL be part of the spatial network of the project. Via an IfcRelAssociatesMaterial-object relationship.

5.4.3.46 IfcRelAssociatesMaterial - IFC4.3.2.0 Documentation (buildingsmart.org)

I think it might often not be a problem to strip of materials that are not used in a project. They are not used, and deleting them can save some space.

However, It is useful to know that unused IfcMaterial-objects would not appear if using a graph database query that originates from the IfcProject-object. And good to know that such unused IfcMaterial-objects might be orphaned when inserting data.

On the other hand. An alternative method could be to have all objects in all projects link to the same IfcMaterial. Then you don’t need to declare the same IfcMaterial multiple times in the database. And it will be easy to find all objects in all projects that uses the same material.

The problem with this approach is that a lot of projects will then form merged networks. It might be one big network everything. And then it might be difficult to sort out information belonging to particular projects - in Cypher queries.

For example using Cypher you can return all nodes that are linked to a particular node. This means that you might search through multiple projects by accident.

10

Maybe it is helpful to recall the four layers of the schema. Every entity type in the upper three layers (domain, interop and core layer) is meant for identifiable entities in the building model, hence they are all of type IfcRoot (or a subtype) and have an ID. The lowest layer (resource layer) contains all other entity types like IfcMaterial. By definition they “shall not be used independently of a definition declared at a higher layer”. This means in theory, they can not exist in isolation (or as orphans), but only associated to entities of the upper layers.

1 Like
11

Thanks,

…so IfcMaterial, and objects of other non-rooted classes, should never exist in isolation, because they belong to the resource layer, and can then be non-rooted.

This means that there are no objects of a project, that are not in any direct or indirect relationship to the IfcProject-object, at least not simply because they are non-rooted.

12

In theory, yes. This is also specified with the IfcRoot type, which states that “IfcRoot is the most abstract and root class for all entity definitions that roots in the kernel or in subsequent layers of the IFC specification. It is therefore the common supertype of all IFC entities, beside those defined in an IFC resource schema. All entities that are subtypes of IfcRoot can be used independently, whereas resource schema entities, that are not subtypes of IfcRoot, are not supposed to be independent entities.”

“Independent entity” in this context means an entity is not referred to from any other entity. Hence it stands on its own as opposed to being referred to and contributing to the information about of the referring entity. An independent entity can, of course, refer to other dependent entities.

About everything being connected to an IfcProject I am not so sure where this is defined - in an MVD or implementers agreement. I would have to look it up. Ultimately, there can be at most one instance of a project in a data set. The project provides context (like units etc.) to the entities in the data set and I believe, much information would be useless without such context.

13

I also agree with @tauscher but I want to emphasize that this is in theory and inline with what I believe is the intention.

The unfortunate reality is that I think there is no current validation check for this or expressed in the schema. And there are minor edge cases (like material and profile) which some might propose (there are a few topics about this and bugs already filed) that are misplaced in the four layers of the schema.

14

So if:

  1. In project A that uses units in meter there is an independent entity X.
  2. In project B that uses units in inches there is an independent entity Y.

Now you want to use data from both project A and project B at the same time.

How do you make sure that entity X uses meters and entity Y uses inches… if there is no relationship from entity X to project A and no relationship from entity Y to project B?

How can we make sure that independent entities always use the context of the right project when we mix data from various projects?

When we serialize IFC into a STEP file. Then each STEP file is a dataset. And this is fine as long as we only use one STEP file at a time.

But as soon as we mix data from several STEP files and several projects, then we need to make sure that each rooted entity, can be related to the context of the correct project.

And we might want to mix data from several projects in a dataset, in order to perform a query over multiple projects.

Or should we instead always only have one project. So if we merge data from several STEP files we will instead add all sites from all projects to a single project?

15

As I understand… the answer to the question is:

It is valid IFC to create a dataset that contains orphaned detached rooted entitites neither attached to the spatial structure, nor to any other entitites.

Such orphaned detached entitites cannot be traced back to any specific entity of class IfcProject, via a relationship. However, since there only is one entity of class IfcProject within a dataset, this is not a problem.

The entity of class IfcProject within the given dataset, must thus be found independently from orphaned entitites. There are no direct or indirect relationships between the orphaned entitites and the entity of class IfcProject.

This means that it is not possible to mix datasets (for example from several STEP-files), because there will be two entitites of class IfcProject. And for detached orphaned entitites it will not be possible to know which entity of class IfcProject they belong to.

One example of a possible orphaned detached entity is an entity of class IfcTask. This entity can be created without any relationships to any other entity.

In reality such an entity of class IfcTask without any relationships to any other entity, might not be very useful. But it is still valid IFC, and this scenario must be considered in applications.

Non rooted entitites on the other hand (such as entitites of class IfcMaterial) will allways be in a relationship with an entity of a rooted class.

This is a citation from the IFC-specifikation for IfcRoot:

“All entities that are subtypes of IfcRoot can be used independently, whereas resource schema entities, that are not subtypes of IfcRoot , are not supposed to be independent entities.”

16

Hi Martin,
Sorry if my answer is not aligned with all replies and ideas proposed by others.

I published in 2017 a paper “Application of graph databases and graph theory concepts for advanced
analyzing of BIM models based on IFC standard” ( https://ifcwebserver.org/doc/ifc2gdb_eg-ice2017_ismail.pdf)" , the simple solution at that time to enable storing and querying multiple models was done by adding an additional attribute “model_id” to all nodes.
In this way you can group, query and filter all nodes per model easily.

Ali Ismail