IDS Metadata – Describing the IDS and Specifications

Overview

Metadata provides essential context for IDS files, describing their purpose, scope, and usage. Good metadata transforms an IDS from a simple checking tool into a comprehensive documentation system for project BIM requirements.

Why Metadata Matters

Metadata enables:

• Clear Communication - Stakeholders understand IDS purpose and scope
• Version Control - Track changes and evolution over time
• Accountability - Identify authors and responsibilities
• Context - Link requirements to project phases and objectives
• Compliance - Document rationale for audit trails

Two Levels of Metadata

Level	Scope	Purpose
IDS File Metadata	Entire IDS document	Overall context and information
Specification Metadata	Individual specifications	Specific requirement details

IDS File Metadata

Core Fields

Field	Purpose	Example
Title	Short name for the IDS	"Minimum Delivery Requirements"
Version	Document version tracking	"1.2" (semantic versioning)
Author	Creator identification	"jane.doe@company.com"
Date	Publication date	"2024-03-15"
Copyright	Rights and ownership	"ACME Architecture Ltd."

Descriptive Fields

Field	Purpose	Example
Description	Detailed scope and context	"Specifies minimum information for openBIM coordination and scheduling"
Purpose	Why information is needed	"clash detection", "cost estimation"
Milestone	Project phase/delivery stage	"Design Development", "LOD 350"

Version Control Best Practices

Semantic Versioning:

• *Major version (1.0 → 2.0)*: Requirements changed (affects pass/fail)
• *Minor version (1.0 → 1.1)*: Metadata/wording only (no functional impact)
• *Patch version (1.1 → 1.1.1)*: Bug fixes, clarifications

Complete Example

Title: "Hospital Project – Accessibility Requirements"
Version: "1.0"
Author: "accessibility.team@hospital-project.com"
Date: "2024-03-15"
Purpose: "accessibility analysis"
Milestone: "Design Development"
Description: "Ensures all doors, corridors, and spaces meet accessibility 
             standards as required by local code, including clear widths 
             and signage requirements."

Specification Metadata

Individual Specification Fields

Field	Purpose	Example
Name	Short specification label	"Wall Type Naming Convention"
Identifier	Unique tracking ID	"SP-001", "REQ-WALL-001"
IFC Version	Applicable schema versions	"IFC4X3_ADD2", "IFC4"
Description	Rationale and importance	"LoadBearing property critical for structural analysis"
Instructions	Compliance guidance	"Architects: Use Section 5 guidelines for values"

Specification Example

Name: "Wall Fire Rating Requirements"
Identifier: "SP-003"
IFC Version: ["IFC4", "IFC4X3"]
Description: "Fire ratings are mandatory for building code compliance 
             and emergency egress planning. Missing ratings prevent 
             proper fire safety analysis."
Instructions: "Structural engineers must specify fire ratings for all 
              load-bearing walls. Use 1HR, 2HR, 3HR format. 
              Refer to local building code requirements."

Benefits of Good Metadata

For Model Authors:

• Understand why requirements exist
• Get clear guidance on compliance
• Know who to contact for questions

For Model Recipients:

• Validate appropriate IDS usage
• Understand requirement context
• Generate meaningful compliance reports

For Project Management:

• Track requirement evolution
• Assign responsibilities clearly
• Link to project phases and deliverables

Best Practices

Always Include:

• Title, Author, Date, Version for every IDS
• Name and Description for every Specification
• Instructions for complex requirements

Version Management:

• Use semantic versioning consistently
• Document changes in version notes
• Maintain backward compatibility when possible

Clear Communication:

• Write descriptions for human readers
• Explain the "why" not just the "what"
• Provide actionable instructions
• Use consistent terminology throughout