IDS Structure and Specifications

File Architecture

An IDS file has a clear hierarchical structure designed for both human readability and machine processing.

High-Level Components

An IDS file contains:

1. IDS Metadata

• General information describing the entire IDS
• Title, author, purpose, version, etc.
• Applies to all Specifications in the file
• Covered in detail in the metadata section

2. Specifications (one or more)

• Each addresses a specific information requirement
• Core functional components of the IDS
• Define rules about IFC model content

Examples of Specifications

• "Walls must have a fire rating property"
• "Doors cannot use specific classification codes"
• "Spaces must meet minimum area requirements"

Specification Structure

Each Specification follows a consistent three-part structure:

1. Description

Purpose: Human-readable explanation of the requirement

Contains:

• Why this requirement exists
• Instructions for compliance
• Context for stakeholders

Example: "Wall fire ratings are critical for building code compliance and safety analysis."

2. Applicability

Purpose: Defines which IFC elements the specification applies to

Function:

• Filters the model to relevant elements
• Defines the scope of checking

Examples:

• "All wall elements"
• "All door types"
• "Load-bearing structural elements"

3. Requirements

Purpose: States what information must (or must not) be present

Function:

• Defines the actual check to perform
• Specifies expected data

Examples:

• "Must have a FireRating property"
• "Cannot use classification X"
• "Area must be ≥ 10 m²"

Complete Example

Requirement: "All walls must have a fire rating property"

Description: "Wall fire ratings are critical for building code compliance"
Applicability: "This applies to all wall objects"
Requirements: "The wall objects must have a FireRating property"

Key Point:

• Applicability = WHERE to check
• Requirements = WHAT to check for
• Description = WHY it matters

In an IDS, the Applicability and Requirements parts are expressed using Facets – we will discuss Facets shortly. Importantly, a Specification’s Description can also document the rationale behind the chosen applicability criteria and requirements, giving guidance on how to comply . It’s good practice to fill in the Description so that anyone reading the IDS (or the report from an IDS check) understands the intent behind each requirement.

Using Facets to Define Requirements

What are Facets?

Facets are the building blocks used to precisely describe what to filter or check in an IFC model. Each facet represents one type of information that an IFC entity might have.

The Six Facet Types

Facet	Purpose	Example
Entity	Identifies IFC elements by type/class	IfcWall, IfcDoor
Attribute	Checks built-in IFC attributes	Name, Description
Classification	Verifies external classification codes	OmniClass, Uniclass
Property	Checks custom properties and values	FireRating, LoadBearing
Material	Validates material assignments	Concrete, Steel
PartOf	Verifies relationships/containment	Part of system, In space

How Facets Work

In Applicability (Filtering):

• Facets describe criteria elements must meet to be included
• Example: Entity=IfcWall + Property LoadBearing=True
• Result: Only load-bearing walls are selected

In Requirements (Checking):

• Facets state what information is required or prohibited
• Example: Property FireRating must exist
• Result: Each selected element must have this property

Combining Facets

You can combine multiple facets for precise criteria:

Applicability: 
  - Entity = IfcWall
  - Property LoadBearing = True

Requirements:
  - Property FireRating must exist

Result: Load-bearing walls must have fire rating properties

Design Principles

• Precise: Fixed parameters for unambiguous interpretation
• Flexible: Complex restrictions allow ranges, lists, patterns
• Combinable: Multiple facets work together for specific rules

Complex Restrictions Preview

Many requirements need flexibility beyond single values. IDS supports Complex Restrictions on facet parameters:

Types of Restrictions:

• Lists: Multiple acceptable values ("IFC4X3" OR "IFC4")
• Ranges: Numeric bounds (20 to 100)
• Patterns: Text matching (naming convention "WT##")

Example Uses:

Property Value: ["INSITU", "PRECAST"]  ← Either value acceptable
Area: 20 ≤ value ≤ 100              ← Range restriction  
Name: "WT[0-9]{2}"                    ← Pattern like WT01, WT02

Detailed coverage of Complex Restrictions comes later in this course.

Example Specifications: Let’s look at a few example specifications to cement these concepts :

• External load-bearing walls must have a fire rating property. – Applicability: Entity Facet (IFC Class is IfcWall), plus Property Facet (LoadBearing = TRUE in Pset_WallCommon) to single out load-bearing walls. Requirement: Property Facet (Pset_WallCommon – FireRating property must exist) . In effect, this Specification says: find all walls that are load-bearing, and ensure each has a FireRating property.
• Bedrooms should have a minimum area of 10 m². – Applicability: Entity Facet (IFC Class is IfcSpace for spaces) and Attribute Facet (the space’s Description contains “BEDROOM” to identify bedroom spaces) . Requirement: Property Facet (Qto_SpaceBaseQuantities – NetFloorArea property value ≥ 10) . This means: for any space labeled as a bedroom, its NetFloorArea must be at least 10.
• All brick wall types must be classified and follow a naming convention. – Applicability: Entity Facet (IFC Class is IfcWallType) and Material Facet (material is “brick”) . Requirements: Classification Facet (must have a classification in Uniclass 2015 with code starting “EF_25_10”) and Attribute Facet (Name must match pattern “WT##” like WT01, WT02, etc.) . In plain terms: any wall type made of brick must have a valid classification code and be named according to the WT01/WT02 scheme.

Each example above shows how multiple facets work together. By combining facets, IDS can express quite specific information requirements. If a single facet isn’t enough to capture a criterion, you simply add another facet.