IFC Schemas

Overview

An IFC schema defines an entity-relationship model based on a file written using the EXPRESS modeling language specification (a file that has an .exp extension). The EXPRESS data specification language is described in the ISO 10303-11 standard. Currently ODA IFC SDK supports the following schemas:

The architecture of the most recent schema IFC4x3_RC4 is shown below:

This schema has four layers:

Domain layer — The highest layer includes entity definitions for concepts specific to certain disciplines that are grouped into domains such as structural analysis, architecture, electrical, rail, road, etc. For example, an IfcRailway (e.g., OdIfc4x3_rc4::IfcRailway) entity belongs to the rail domain and IfcStructuralItem (e.g., OdIfc4x3_rc4::IfcStructuralItem) belongs to the structural analysis domain.
Interoperability layer — This layer includes entity definitions that are specific to a general product, process or resource specialization and can be used across multiple domains. For example, the Shared Building Elements schema has entity definitions for a beam, column, wall, door, etc.
Core layer — This layer includes the Kernel schema and the core extensions schemas. The Kernel schema defines the most abstract part of the IFC architecture, such as actor, group, process, product and relationship. The extension schemas are dedicated to further group the Kernel and shared elements (on the interoperability layer). All entities that belong to the core layer, or above, have a globally unique ID (IfcGUID) and additionally can have owner and history information.
Resource layer — The lowest layer includes basic properties such as geometry, material, measurement, date and time, cost, constraint, measure, etc. These definitions do not have a globally unique identifier and should not be used independently of a definition that is part of a higher layer.

Each schema has its own entity-relationship model, which means that the number of entity definitions for each schema can be different; an entity definition's structure can vary and also some entities can be missing from new or old schemas. ODA IFC SDK allows you to create common schema-agnostic code using a late-binding C++ API or SDAI when access to an attribute is performed using its name. For more information, see Data Access Mechanisms. Overall, IFC schema entity definitions implement two important concepts described below.

Inheritance

All properties of base entities are inherited by specialization entities. Specialization means that an entity is a subtype of a generic (base) entity. For example, IFC has an IfcWallStandardCase (e.g., OdIfc4x3_rc4::IfcWallStandardCase) entity that is a specialization of a set of entity definitions. The inheritance graph for an IfcWallStandardCase entity according to schema is shown below:

IfcWallStandardCase derives from several entities, one of which is IfcRoot (e.g., OdIfc4x3_rc4::IfcRoot). IfcRoot is the most abstract definition of an identifiable entity. It has the following properties:

Global unique identifier
Owner history
Name
Description

IfcWallStandardCase inherits IfcRoot, therefore it also has IfcGUID (pay attention that IfcGUID format differs from standard GUID format), owner history, name and description properties plus other properties from base entities (properties of other base entities are not shown on the illustration).

Entities that belong to the resource layer do not inherit IfcRoot, so they are not identifiable by the IfcGUID. IfcMaterial is an example of such an entity:

Entities from the resource layer should be used only when they relate to actual identifiable IFC objects, i.e., objects that inherit the IfcRoot entity.

Object Relations

IFC uses objectified relations, which means that separate objects create relations between other objects. Entities use so-called "inverse" attributes to connect to a relation object to create a relation. The STEP Physical File (SPF) standard supports storage of explicit attributes only, so inverse attributes are calculated when opening a file using ODA IFC SDK. However, HDF5, for example, allows storage of inverse attributes.

The example of inheritance shows that IfcWallStandardCase inherits a set of entities, one of which is IfcObjectDefinition (e.g., OdIfc4x3_rc4::IfcObjectDefinition). According to the schema, there is an IfcRelAssociatesMaterial object (e.g., OdIfc4x3_rc4::IfcRelAssociatesMaterial) that defines a relation between IfcObjectDefinition and IFC materials. The Rel part of an IFC entity indicates that this entity is designed to make relations. The IfcObjectDefinition entity has an inverse attribute HasAssociations that connects to the IfcRelAssociatesMaterial object.

Because the IfcWallStandardCase inherits IfcObjectDefinition it also has the inverse attribute HasAssociations and you can relate a material to your wall.

Other entities in the illustration also have inverse attributes (but are not shown) that allow you to get information about entity openings or coverings, containment in a structure, etc. To get a list of functions that operate with attributes of a specific entity, refer to the API Reference and navigate to an entity for the desired schema. Each schema in the API Reference is represented as a separate namespace.

Overview

Inheritance

Object Relations

See Also