The Classification Facet

Overview

The Classification Facet handles external classification systems used to categorize BIM elements in standardized hierarchies. These systems provide consistent ways to organize and identify building components across projects and disciplines.

Why Classifications Matter

Classifications enable:

• Standardized Organization - Consistent element categorization
• Cost Estimation - Link to cost databases and pricing systems
• Specification Writing - Reference standard building products
• Regulatory Compliance - Meet building code requirements
• Data Exchange - Common vocabulary between stakeholders

Common Classification Systems

System	Region	Focus	Example Code
OmniClass	North America	Comprehensive	23-13 11 11 (Concrete Walls)
Uniclass 2015	UK	Construction	EF_25_10_25 (External walls)
MasterFormat	North America	Specifications	03 30 00 (Cast-in-Place Concrete)
Uniformat	North America	Cost estimation	B2010 (Exterior Walls)

IFC Classification Structure

Classifications in IFC consist of:

1. Classification System Name

• Examples: "Uniclass 2015", "OmniClass 2012", "MasterFormat"
• Must match exactly as stored in IFC

2. Classification Code/Value

• Hierarchical identifier within the system
• Example: "EF_25_10_25" for external walls in Uniclass

3. Classification URI (optional)

• Global reference link
• Links to authoritative definitions

Parameters

System (Required)

Purpose: Specifies the classification system name

Requirements:

• Must match exactly as stored in IFC
• Case-sensitive matching
• Supports multiple systems via restrictions

Examples:

System: "Uniclass 2015"          ← UK classification system
System: "OmniClass"               ← North American system
System: ["OmniClass", "Uniclass 2015"]  ← Accept either system

Value (Optional)

Purpose: Specifies the classification code or pattern

Options:

• Specific code: Exact classification required
• Pattern match: Regex for code families
• List of codes: Multiple acceptable codes
• Omitted: Any code in the system acceptable

Examples:

Value: "EF_25_10_25"          ← Specific external wall code
Value: "EF_25_10.*"           ← Any external wall subtype
Value: ["A", "B", "C"]        ← Multiple acceptable codes

URI (Optional)

Purpose: Reference link for precise identification (informational only)

Use Cases:

• buildingSMART Data Dictionary references
• Authoritative system documentation
• Unambiguous specification clarification

Note: Not used in model checking, documentation only

How Classification Checking Works

Multiple Classifications Support

IFC elements can have multiple classification references. The Classification facet searches through all of them.

Matching Logic

System = X, Value = Y → Element must have at least one classification where:
                        - System name matches X AND
                        - Classification code matches Y

System = X, (no Value) → Element must have any classification in system X

Checking Process

1. Find Classifications: Locate all classifications on element
2. Filter by System: Match specified system name(s)
3. Check Value: If specified, match code/pattern
4. Pass/Fail: At least one match = pass

Common Use Cases

1. System Compliance

Requirement: "Every element must have an OmniClass classification"

System: "OmniClass"
(no Value specified)

Result: Elements must have any OmniClass code assigned

2. Specific Classification

Requirement: "All wall types must be classified as External Wall"

System: "Uniclass 2015"
Value: "EF_25_10_25"

Result: Wall types must have this exact classification code

3. Classification Family

Requirement: "Walls must be classified in external wall category"

System: "Uniclass 2015"
Value: "EF_25_10.*"

Result: Accepts any external wall subtype (EF_25_10_01, EF_25_10_25, etc.)

4. Multiple Systems

Requirement: "Elements must use either Uniclass or OmniClass"

System: ["Uniclass 2015", "OmniClass"]
(no Value specified)

Result: Element must have classification in at least one system

Classification vs Entity Facet

Aspect	Classification Facet	Entity Facet
Purpose	External standardized codes	IFC internal types
Source	Published standards (OmniClass, etc.)	IFC schema definition
Example	"EF_25_10_25" (Uniclass wall)	"IfcWall" (IFC entity)
Use When	Need standard industry codes	Need IFC type checking

Key Principle: Use Classification facet for external tagging, Entity facet for internal IFC structure

Classification Facet parameters summary:

• System – Required. The classification system name. (Usually a string matching how it appears in IFC’s IfcClassification.Name for that system.) Supports multiple via list or patterns if needed. The element must have an associated classification from this system.
• Value – Optional. The classification code/value. Can be full code or partial via pattern/list. If omitted, any classification entry from the specified system will satisfy it .
• URI – Optional. A reference URI (e.g., from an authority like bSDD) identifying the class. Not checked in model; informational only . (No restrictions on this field.)

Practical Examples

1. Any Classification Required

Requirement: "All elements must be classified"

(no System, no Value)

Result: Element must have at least one classification from any system

2. System-Specific Classification

Requirement: "Elements must have OmniClass classification"

System: "OmniClass"
(no Value)

Result: Element must have any OmniClass code

3. Multiple System Options

Requirement: "Elements must use OmniClass or Uniclass"

System: ["OmniClass", "Uniclass 2015"]
(no Value)

Result: Element must have classification in at least one system

4. Specific Code Requirement

Requirement: "External walls must have Uniclass code EF_25_10_25"

System: "Uniclass 2015"
Value: "EF_25_10_25"

Result: Must have this exact classification

5. Code Family Requirement

Requirement: "Walls must be classified as external wall type"

System: "Uniclass 2015"
Value: "EF_25_10.*"

Result: Must have code starting with EF_25_10 (any external wall subtype)

Usage Summary

Use Case	System	Value	Result
Any classification	(none)	(none)	Has any classification
System compliance	"OmniClass"	(none)	Has OmniClass code
Multiple systems	["A", "B"]	(none)	Has code from A or B
Specific code	"Uniclass 2015"	"EF_25_10_25"	Has exact code
Code pattern	"Uniclass 2015"	"EF_25_10.*"	Has matching pattern

Best Practices

Always Specify System: When using Value, always specify System to avoid ambiguity

❌ Bad:  Value="EF_25_10_25" (which system?)
✅ Good: System="Uniclass 2015", Value="EF_25_10_25"

Use Patterns for Flexibility: Allow classification families rather than exact codes

Value: "EF_25_10.*"  ← Any external wall type

Consider Multiple Systems: Projects may use different standards

System: ["OmniClass", "MasterFormat"]  ← Accept either