From IFC 4 to IFC 5 - UICrail/CDM-IFC GitHub Wiki
IFC5 (as of June 2024) is published by buildingSMART International under the IFC5 development GitHub. It is an alpha version.
The IFC5 scheme is expressed in TypeSpec (IFC4: EXPRESS). Serialisation uses JSON (IFC4: STEP). The JSON schema against which the JSON files can be checked is generated from the TypeSpec scheme.
The IFC5 metamodel is expressed in the TypeSpec file currently located at IFC5-development/schema/ifcx.tsp.
IFC5 data are fundamentally represented as graphs, the node structure being:
model IfcxNode {
path: path;
children?: Record<string | null>;
inherits?: Record<string | null>;
attributes?: Record<unknown>;
}Here, path is a regular expression defined by:
@pattern("</[A-Za-z0-9_/.:]+>")This pattern is compatible with UUIDs (currently used by IFC5) but not with URIs such as <https://w3id.org/ifc/IFC4X3_ADD2#isNestedBy_IfcObjectDefinition>.
note: the angle brackets are not part of the URI; they are the RDF convention for delimiting URIs.
While the RFC3986 pattern specification for URIs is complex and not expressible in a single regular expression, hyphens - and fragment identifiers # are most common, and these are not allowed by the path regex.
In IFC4, the semantics are encoded by the EXPRESS schema, the bSDD repository, and IFC documentation
- Types (simple types, enumerations...); IFC 4.3 ADD2 has 436 such types;
- Entities (roughly equivalent to UML or OWL classes), e.g.
ENTITY IfcAlignment
SUBTYPE OF (IfcLinearPositioningElement);
PredefinedType : OPTIONAL IfcAlignmentTypeEnum;
END_ENTITY;
bSDD (buildingSMART Data Dictionary) is
buildingSMART’s service for sharing definitions for describing the built environment to help everyone use agreed and consistent terms. bSDD provides access to information relating to other dictionaries, such as Uniclass.
Information stored in bSDD can be downloaded as JSON snippets. Third parties provide the possibility to download the whole bSDD contents in various formats; see for instance Semantic bSDD by Ontotext.
The bSDD entry for IfcAlignment for instance provides:
{
"classType": "Class",
"referenceCode": "IfcAlignment",
"parentClassReference": {
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcLinearPositioningElement",
"name": "Linear Positioning Element",
"code": "IfcLinearPositioningElement"
},
"hierarchy": [
{
"level": 1,
"name": "Root",
"code": "IfcRoot",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcRoot"
},
{
"level": 2,
"name": "Object Definition",
"code": "IfcObjectDefinition",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcObjectDefinition"
},
{
"level": 3,
"name": "Object",
"code": "IfcObject",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcObject"
},
{
"level": 4,
"name": "Product",
"code": "IfcProduct",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcProduct"
},
{
"level": 5,
"name": "Positioning Element",
"code": "IfcPositioningElement",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcPositioningElement"
},
{
"level": 6,
"name": "Linear Positioning Element",
"code": "IfcLinearPositioningElement",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcLinearPositioningElement"
},
{
"level": 7,
"name": "Alignment",
"code": "IfcAlignment",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcAlignment"
}
],
"dictionaryUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3",
"activationDateUtc": "2024-01-12T00:00:00Z",
"code": "IfcAlignment",
"countriesOfUse": [],
"definition": "For the purposes of IFC the English term 'alignment' defines three separate but closely interconnected concepts.",
"name": "Alignment",
"uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcAlignment",
"replacedObjectCodes": [],
"replacingObjectCodes": [],
"status": "Active",
"subdivisionsOfUse": [],
"uid": "f0f46021-4b22-4e3c-9d17-8854d90a4457",
"versionDateUtc": "2024-01-12T00:00:00Z"
}Thus we see that bSDD:
- has a scope overlapping with EXPRESS (no types, but additional dictionaries)
- works as a tree-like taxonomy for EXPRESS entities (with single parents)
The schema is under development (as of June 2025). The following snippet is published under bSI's ifcx.dev GitHub, and used in the IFC5 dev GitHub.
"bsi::ifc::alignment": {
"value": {
"dataType": "Object",
"objectRestrictions": {
"values": {
"segments": {
"dataType": "Array",
"arrayRestrictions": {
"value": {
"dataType": "Object",
"objectRestrictions": {
"values": {
"ref": {
"dataType": "String"(closing brackets omitted)
{
"path": "2d4f6572-b27c-4870-bf9e-e5811127b85e",
"children": {
"Axis": "73f71c77-a6cb-54b1-8bcb-8eccdf80cf35",
"H1": "a68c1a97-c8af-41f0-bbb1-ec1e38efb8c4",
"V1": "859d71aa-e812-48ad-a5c0-4aa05cabf3ba",
"C1": "2eebcf4c-03c9-48a2-b9a2-3d87f3cd2649",
"StaStation": "f7fa0fb5-8eae-4ca5-affd-d825422f8fc9",
"End": "1bed3e86-ecf8-4553-b89d-33a596f1cad9",
"Referent_001": "2ef5faa4-6e25-4491-8183-22dad1a43c7a",
"Referent_002": "4bf56217-7e6d-43e5-bab9-5fc6b3324840",
"Referent_003": "cebe215d-2cd7-4486-8c07-44df6ce38c61",
"Referent_004": "c3f68346-9fc2-482f-adaa-a3b36cca9a7d",
"Referent_005": "738fafa5-0a56-42a8-b8a0-66496f4ea7c1",
"Referent_006": "4a10b33d-c6cb-4fe8-bf45-7f01a476e54c",
"Referent_007": "3587a835-0f68-4d98-9021-6792fdbf1c38",
"Referent_008": "aa2a04f2-66ed-44bf-9db2-255bb6523fff",
"Referent_009": "b49072de-3e21-44f6-bc78-015fd1c8c01f",
"Referent_010": "ad35a1b5-8f68-4cbd-9336-861e2ef397b7",
"Referent_011": "36fdcb46-4e00-4920-b36c-0c636cc7c12f",
"Referent_012": "81fe4ead-e59b-48e3-95f2-3645a3fb6648",
"Referent_013": "df0ea44e-c850-4891-8315-16ac3ff2a051",
"Referent_014": "fbb4b9a2-3126-45d3-999d-133c194f8afc",
"Referent_015": "aced08ae-90fe-4abc-b415-5e59ae5060ef",
"Referent_016": "7923cb07-f23e-44d3-9f86-5d58fb2ae9ea",
"Referent_017": "c29be2ef-7443-475f-841e-a77200f1b219",
"Referent_018": "6e885b02-f7a9-4298-9439-492fb95b1a5e",
"Referent_019": "5b1cf5e2-c10a-4fef-aae9-efc301dfe7ed",
"Referent_020": "c040c20e-18e6-4f4a-911e-e213fa18806f",
"Referent_021": "255aa8b8-9216-4ef5-a921-d78907718e6e",
"Route_Indicator_01": "37f90dfa-40f7-40c5-9dbd-8f6b7c289e84",
"Route_Indicator_02": "6ac4e64b-1b4e-4e88-827a-6804cb5a6166"
}
(to be continued)
At this early stage, we can already identify some significant evolutions compared to IFC4:
- where IFC4 uses association entities (such as IfcRelNests), which is the equivalent of property reification in OWL, IFC5 would use direct inclusions without predefined semantics (parent-child relation), the meaning of which is provided by the context;
- in IFC4, object identifiers are the row numbers in the STEP file; IFC5 uses UUIDs instead, "path" denoting the key to the parent object;
- in IFC4, each row in the STEP serialization provides complete information about an object, including the values of its attributes, complemented by some general information (e.g. base coordinate reference system) applying to the whole STEP file; in IFC5, data about any object can be scattered in several files, the UUID values being the basis for reconciling the information;
- in IFC4, types and entity definitions (in EXPRESS) are strictly separated from their instances (STEP files); in IFC5, any object X can be referred to by any other object by means of the key-value pair "inherits":, in which case X acts as a type. This inheritance can be propagated recursively.
This on-the-fly extensibility of the IFC5 schema seems to raise interest. A typical, realistic use case would consist in defining a window X as an instance of IfcWindow, setting its frame, glazing and materials, and then having windows Y, Z, ... "inheriting" from X with only their coordinate system shifted. "Inheriting" is much more than simple cloning, as incomplete specifications could be envisaged (e.g. not stipulating materials, in our example) and any attribute can be overridden if desired, not just the position.
The more conventional alternative to "inherits" would consist in declaring a subtype of IfcWindow; it should remain available (to be checked).
The evolutions listed above do not compromize the generation of matching IfcOWL versions:
- the adoption of UUIDs gets IFC5 closer to ontologies; UUIDs however do not provide discoverability as URIs would do;
- the "inherits" functionality can also be provided in OWL with some precautions, see below.
OWL allows to treat any resource as both an individual and a class, a feature known as "punning". Example: an eagle (individual) is a Bird (class), these two birds in the cage (two individuals of class Bird) are Eagles (class, subclass of Bird). OWL allows to use the same URI for denoting both the class and the individual, but these are treated separately: if the individual eagle is assigned the color "red", this has no effect on the eagle class nor on the individuals of that class - they will not be "red".
Going back to IFC-inspired examples, if you assign the property "material"= "wood" to a particular window individual and want all other individuals to also be wooden, the proper OWL construct is to create another class with a restriction:
:Window a owl:Class .
:Wooden_window rdfs:subClassOf :Window, [
a owl:Restriction ;
owl:onProperty :material ;
owl:hasValue "wood"
] .OWL imposes the explicit declaration of a subclass, but otherwise provides the same cloning capabilities as IFC5 "inherits". Unlike IFC5 that requires bespoke code to interpret the effects of "inherits", this OWL restriction is a standard OWL feature that will be interpreted by any reasoner (inference engine). owl:hasValue is available for the OWL DL and OWL RL profiles. Due to possible limitations of some reasoners, it is recommended to use the alternative, equivalent syntax:
:Window a owl:Class .
:Wooden_window rdfs:subClassOf :Window, [
a owl:Restriction ;
owl:onProperty :material ;
owl:someValuesFrom [owl:oneOf ("wood")]
] .