EXPRESS

Introduction

Let's take a look a very basic EXPRESS data model.

SCHEMA Family;

ENTITY Person
     name: STRING;
END_ENTITY;

We have defined a custom schema called Family. We have a Person class within this schema. The person has one attribute: name. The name is represented as a string.

Schema

Family

Class Name

Person

Class Attribute

Name

If you are familiar with object oriented programming, then this should feel very straight forward. If not, check out:

Window Example

Let's take a look at our previous example, the window:

We can see that we each "object" (window, wall, door, roof, etc.) is an ENTITY. Again, notice how we use the following format to specify an "object":

Here's a list of some common building elements. These are defined in IFC2x Edition 3 Technical Corrigendum 1 schema, SCHEMA IFC2X3;. Again, notice how each building element ("object") is its own ENTITY.

Let's go back to our window. This is a Window class defined using the EXPRESS data model format.

Take a look at line 5 and 6. We can see that we have two attributes:

  1. Overall Height

  2. Overall Width

Missing Attributes?

Let's continue with our Window example. We saw that the windows has two attrbitues. However, according to the documentation, we're missing some attributes:

We can verify this by looking at the STEP-file. This has clearly more than two attributes:

We have 10 different attributes. Notice that we don't understand what any of these attributes mean.

Attribute

Value

#1

2cXV28XOjE6f6irgi0CO$D

#2

#42

#3

M_Fixed:0915 x 1830mm:353953

#4

$

#5

M_Fixed:0915 x 1830mm:353953

#6

#35337

#7

#13061

#8

353953

#9

1830.

#10

914.999999999999999

Let's dive deep into EXPRESS

How does this work? How can we have more than two attributes?

Well, the answer lies within the EXPRESS definition. Take a close look at the 4th line above. We can see that IfcWindow is an subtype of an IfcBuildingElement. Here's the EXPRESS data model forIfcBuildingElement:

Notice how the IfcBuildingElement itself is a subtype of IfcElement (see line 25 above). Let's continue down the rabbit hole...

Again, notice how our IfcElement is a subtype of IfcProduct (see line 13 above). Let's continue...

Our IfcProduct is a subtype of IfcObject (see line 11 above).

Our IfcObject is a subtype of IfcObjectDefinition (see line 10 above). Let's continue...

Our IfcObjectDefinition is a subtype of IfcRoot (see line 5 above). We are almost done...

Finally, we have reached the end!

Inheritance

We call this behaivor inheritance.

  • IfcWindow

    • IfcBuildingElement

      • IfcProduct

        • IfcObject

          • IfcObjectDefinition

            • IfcRoot

Let's flip this "graph". This will make things a bit easier to explain.

  • IfcRoot

    • IfcObjectDefinition

      • IfcObject

        • IfcProduct

          • IfcBuildingElement

            • IfcWindow

We can see that IfcRoot has four different attributes; GlobalId, OwnerHistory, Name, Description. The IfcObjectDefinition will inherit these attributes. This means that the IfcWindow will inherit these attributes.

The IfcWindow will inherit all attributes from its parent entities.

Summary

If we use inheritance, we can see what each attribute in the STEP-file actually mean:

Inhertited from

Attribute

Value

IfcRoot

GlobalId

2cXV28XOjE6f6irgi0CO$D

IfcRoot

Own

#42

IfcRoot

Name

M_Fixed:0915 x 1830mm:353953

IfcRoot

Description

$

IfcObject

ObectType

M_Fixed:0915 x 1830mm:353953

IfcProduct

ObectPlacement

#35337

IfcProduct

Representation

#13061

IfcElement

Tag

353953

IfcWindow

OverallHeight

1830.

IfcWindow

OverallWidth

914.999999999999999

Or, we can simply look at the inheritance graph in the documentation:

PreviousWhat is IFC?NextSTEP

Last updated