IDS Learn

Overview

The Attribute Facet targets built-in IFC attributes that are part of every entity's core definition. These are fundamental properties like names, descriptions, and IDs that are defined by the IFC schema itself.

Why Attributes Matter

Attributes provide essential element information:

Identification - Unique IDs and names for tracking
Documentation - Descriptions and labels for clarity
Coordination - Tags linking to authoring software
Organization - Object types and classifications
Quality Control - Ensuring complete basic information

Attributes vs Properties

Aspect	Attributes	Properties
Definition	Fixed by IFC schema	Extensible by users
Number	Limited (typically <10)	Unlimited
Purpose	Fundamental information	Extended/specialized data
Examples	Name, Description, GlobalId	FireRating, LoadBearing
Modification	Cannot add new ones	Can create custom ones

Common IFC Attributes

Attribute	Purpose	Example	Usage
GlobalId	Globally unique identifier	"2O2Fr$t4X7Zf8NOew3FNr2"	Software tracking
Name	Short identifier/code	"D-101", "W-001"	Schedules, drawings
Description	Human-readable description	"Main entrance door"	Documentation
ObjectType	Additional type information	"Fire Door", "Load Bearing"	Classification
Tag	Software-specific ID	Revit Element ID	Round-trip coordination
Status	Workflow status	"NOTSTARTED", "COMPLETED"	Project management

Entity-Specific Attributes

Some entities have specialized attributes:

IfcDoor: OverallHeight, OverallWidth
IfcMapConversion: Easting, Northing (coordinates)
IfcTask: Status, DurationType
IfcGrid: UAxes, VAxes

When to Use Attribute Facet

Attribute facets are ideal for:

Naming Conventions:

Enforce consistent naming patterns
Require specific prefixes or formats
Validate code structures

Completeness Checking:

Ensure all elements have names/descriptions
Verify required identification fields
Check for empty or missing basic info

Status Validation:

Verify workflow states (tasks, approvals)
Check enumeration values
Validate process compliance

Coordination Requirements:

Ensure geolocation data is present
Verify software-specific tags
Check round-trip identifiers

Parameters

Name (Required)

Purpose: Specifies which attribute to check

Requirements:

Must be a valid IFC attribute for the target entity
Only direct attributes allowed (not relationships or derived values)
Must be explicitly defined in IFC schema

Common Values:

"Name"           ← Element identifier
"Description"    ← Human-readable description
"Status"         ← Workflow status (for tasks)
"ObjectType"     ← Additional type information
"Tag"            ← Software-specific identifier
"GlobalId"       ← Unique identifier

Value (Optional)

Purpose: Specifies expected value or criteria

Options:

Specific value: Exact match required
Pattern match: Regex for naming conventions
List of values: Multiple acceptable options
Omitted: Attribute must exist and be non-empty

Data Type Matching:

*Text attributes (Name, Description)*: String values or regex patterns
*Numeric attributes (Easting, Height)*: Numeric values or ranges
*Enumeration attributes (Status)*: Valid enumeration values
Boolean attributes: true/false values

How Attribute Checking Works

Existence Check (No Value)

Name: "Description"
(no Value specified)

→ Element must have non-empty Description attribute

Exact Value Match

Name: "Name"
Value: "ABC123"

→ Element's Name attribute must equal "ABC123"

Pattern Matching

Name: "Name"
Value: "WT[0-9]{2}"

→ Element's Name must match pattern (WT01, WT02, etc.)

Multiple Values

Name: "Status"
Value: ["NOTSTARTED", "STARTED", "COMPLETED"]

→ Status must be one of the listed values

Practical Examples

1. Attribute Existence Check

Requirement: "All elements must have a description"

Name: "Description"
(no Value specified)

Result: Every element must have non-empty Description attribute

2. Specific Name Requirement

Requirement: "Project must be named 'ABC123'"

Name: "Name"
Value: "ABC123"

Result: IfcProject Name attribute must equal "ABC123"

3. Naming Convention

Requirement: "Wall types must follow WT## naming pattern"

Name: "Name"
Value: "WT[0-9]{2}"

Result: Names like "WT01", "WT02", "WT15" are valid

4. Status Validation

Requirement: "Tasks must have valid status"

Name: "Status"
Value: ["NOTSTARTED", "STARTED", "COMPLETED"]

Result: Task Status must be one of the listed values

5. Geolocation Check

Requirement: "Model must be geolocated at specific coordinate"

Name: "Easting"
Value: "312345"

Result: IfcMapConversion Easting coordinate must equal 312345

6. Description Pattern

Applicability: "Spaces labeled as bedrooms"

Name: "Description"
Value: ".*BEDROOM.*"

Result: Finds spaces with "BEDROOM" in their description

Usage Summary

Use Case	Name	Value	Result
Completeness	"Description"	(none)	Must have description
Specific name	"Name"	"ABC123"	Name equals ABC123
Naming pattern	"Name"	"WT[0-9]{2}"	Follows WT## pattern
Status check	"Status"	["A", "B", "C"]	Status is A, B, or C
Coordinate	"Easting"	"312345"	Easting equals 312345
Content search	"Description"	".BEDROOM."	Contains "BEDROOM"

Combining with Other Facets

Attribute facets work powerfully with other facet types:

Applicability:
  - **Entity**: "IFCSPACE"
  - **Attribute**: Name="Name", Value="OFFICE.*"

Requirements:
  - **Property**: PropertySet="Qto_SpaceBaseQuantities", Name="NetFloorArea", Value=">= 20"

Result: Office spaces (by name pattern) must have minimum 20 m² area

Important Limitations

Allowed Attributes Only:

Must be explicitly defined in IFC schema
Cannot use derived or inverse attributes
Cannot use relationship attributes
Tools typically filter available options

Data Type Compatibility:

Value must match attribute's data type
Text for Name/Description
Numbers for coordinates/measurements
Enumerations for Status/Type fields

IFC Documentation Reference:

Check IFC docs for valid attributes per entity
Attributes in italics are typically not usable
Numbered attributes in normal font are generally supported

Best Practices