Feature request: Generic Graph Facet for navigating and validating IFC relationships

Summary

I would like to propose discussing a generic Graph Facet for a future version of IDS.

The purpose is to enable IDS to express validation requirements involving relationships between IFC entities, including indirect references, inverse relationships, geometric representations, and properties of related objects.

Rather than introducing a separate facet for each new relationship or validation scenario, a generic graph-based mechanism could provide a reusable and extensible solution.

This proposal is intended as a starting point for discussion, not as a complete specification.

Motivation

The current IDS facets cover many common information requirements, but some validation scenarios require navigating the IFC entity graph beyond the capabilities of existing facets.

Examples include:

• HasPart: Verify that an IFC object contains or aggregates specific types of objects.
• ShapeRepresentation: Verify that a product uses a specific geometric representation entity, as discussed in Feature request: ShapeRepresentatation Facet #448.
• Conditional relationships: Validate properties of an object depending on its relationships with other objects.
• Presentation styles: Verify an explicitly assigned surface colour or other presentation attributes.
• Nested structures: Navigate multiple levels of IFC decomposition or other relationships.

Several of these requirements are already being discussed separately. A generic graph mechanism could potentially address them using a consistent approach.

Proposed concept

A Graph Facet would define:

1. Starting context: The IFC entity selected by the existing IDS applicability mechanism.
2. Graph path: A sequence of explicit or inverse IFC attribute references.
3. Target constraint: A condition applied to the entities or values reached by the path.
4. Cardinality: The required number of matching target entities.
5. Quantification: Whether one, all, or a specified number of target entities must satisfy the condition.

The existing IDS facets could potentially be reused to validate the target entities, avoiding unnecessary duplication of validation logic.

Example 1: Shape representation

Requirement: Every IfcReinforcingBar must have a body representation containing an IfcSweptDiskSolid.

Illustrative YAML syntax:

applicability:
  entity: IfcReinforcingBar

requirements:
  graph:
    path:
      - attribute: Representation
      - attribute: Representations
        filter:
          RepresentationIdentifier: Body
      - attribute: Items

    target:
      entity: IfcSweptDiskSolid

    cardinality:
      minCount: 1

Example 2: HasPart

Requirement: Every IfcBuildingStorey must directly aggregate at least one IfcSpace.

applicability:
  entity: IfcBuildingStorey

requirements:
  graph:
    path:
      - inverse:
          entity: IfcRelAggregates
          attribute: RelatingObject
      - attribute: RelatedObjects

    target:
      entity: IfcSpace

    cardinality:
      minCount: 1

Example 3: Surface colour

Requirement: An IfcDoor must have an explicitly assigned red surface colour.

The graph path would navigate from the product representation through its geometric items and associated presentation styles to IfcColourRgb.

The target constraint could verify:

target:
  entity: IfcColourRgb
  attributes:
    Red: 1.0
    Green: 0.0
    Blue: 0.0

tolerance: 0.001

This example would validate explicit colour assignments, not necessarily the final rendered appearance. The exact traversal and handling of alternative presentation-style structures would need to be defined.

All examples are conceptual and do not represent valid IDS 1.0 syntax.

Automatic path discovery from EXPRESS

An additional advantage is that valid graph paths could potentially be derived automatically from the IFC EXPRESS schema.

The schema provides information about:

• Entity definitions and inheritance
• Explicit and inverse attributes
• SELECT types
• Collections and cardinalities
• Attribute types and references

This would allow software implementations to offer schema-aware path discovery and editing.

For example, an IDS authoring tool could suggest structurally valid paths between IfcDoor and IfcColourRgb without requiring the user to understand the entire IFC relationship structure.

Path discovery would be version-specific, while actual validation would still depend on the IFC model and the semantics of the selected path.

Design considerations

To preserve interoperability and predictable validation results, several aspects would require precise definitions:

A deliberately restricted declarative language may be preferable to supporting arbitrary graph queries.

Relationship to existing IDS facets

Two architectural approaches could be considered:

Option A – Independent Graph Facet

Introduce a new facet that combines graph navigation and target validation.

Option B – Graph navigation as a reusable mechanism

Introduce graph navigation as an extension that allows existing IDS facets, such as entity, attribute, property, classification, and material, to be evaluated against related entities.

Option B could offer better reuse of existing IDS semantics and reduce duplication, although it may require more significant changes to the IDS data structure.

Suggested initial scope

I would suggest starting with a limited proof of concept covering:

1. Forward and inverse IFC attribute navigation
2. Entity type filtering
3. Target cardinality
4. Reuse of existing facet constraints where possible
5. Validation against IFC4 and IFC4x3 example models

The initial test cases could focus on HasPart, ShapeRepresentation, and presentation-style validation.

More advanced functionality, such as recursive traversal, conditional relationships, or semantic graph integration, could be evaluated separately.

Questions for discussion

1. Would a generic graph navigation mechanism be preferable to introducing additional specialised facets?
2. Should graph navigation be a standalone facet or a reusable extension of existing facets?
3. What is the minimum set of graph operations needed to cover the most common use cases?
4. Could IFC EXPRESS schema introspection provide a reliable basis for path validation and authoring tools?
5. Should this concept be considered for IDS 2.0 or another future extension?

I would welcome feedback on the usefulness, feasibility, and potential impact of this approach on IDS interoperability and implementation complexity.

Related issues

• Feature request: ShapeRepresentatation Facet #448 – ShapeRepresentation Facet
• Usage of the Attribute facet for referencing attributes #424 – Attribute facet and references to other entities