IFC5 Adequate complexity - maximum reliability 

About us High-end consultancy on open standards and open source solutions in the built environment. 

Complexity and scope (Schiphol Oct 2019) schema complexity intended scope coordination reference * ** *** An ever growing schema with a more precise (=good) scope statement (mismatch is not good) Clearly communicated cumulative implementation levels with narrow or ambitious scope 

From compromises to consistency IfcMaterialLayerSet IfcWall IfcWall IfcBuildingElementParts aggregation IfcCompositeProfileDef 

Decomposition on many levels ✓ ✓ :( :( semantic associations possible impossible Workarounds: IfcMaterialLayerSetUsage IfcMaterialLayerSet IfcMaterialLayer IfcMaterialList IfcMaterialConstituentSet IfcMaterialConstituent IfcMaterialProfileSet IfcMaterialProfile IfcShapeAspect IfcMaterialProperties (10 supertypes!) IfcProfileProperties (2 supertypes!) IfcStyledRepresentation IfcMaterialDefinitionRepresentation IfcComplexProperty Note: A reason why sub-product decomposition became so popular is probably because it’s simple to reinstantiate. 

Semantics Wall of text. No semantic markup. Ambivalent traits. 

Trait-based “latebound” hierarchy (latebinding from ifc5 taskforce paper) uml schema express data json/xml UML attribute = express attribute UML attribute = IFC property Unifies inheritance, psets and concepts into a comprehensive mechanism. Enforce schema semantics. potentially load- bearing Y/N space bounding Y/N Concept: IfcSpace - IfcRelSpaceBoundary - IfcElement - IfcRelSpaceBoundary - IfcSpace IfcWall IfcColumn nb: examples are illustrative could require multiple inheritance in late- bound part largely eliminates “usages” 

The problem of many roots IFC4 has 59 root classes: ['IfcActorRole', 'IfcAddress', 'IfcApplication', 'IfcAppliedValue', 'IfcApproval', 'IfcBoundaryCondition', 'IfcConnectionGeometry', 'IfcConstraint', 'IfcCoordinateOperation', 'IfcCoordinateReferenceSystem', 'IfcDerivedUnit', 'IfcDerivedUnitElement', 'IfcDimensionalExponents', 'IfcExternalInformation', 'IfcExternalReference', 'IfcGridAxis', 'IfcIrregularTimeSeriesValue', 'IfcLightDistributionData', 'IfcLightIntensityDistribution', 'IfcMaterialClassificationRelationship', 'IfcMaterialDefinition', 'IfcMaterialList', 'IfcMaterialUsageDefinition', 'IfcMeasureWithUnit', 'IfcMonetaryUnit', 'IfcNamedUnit', 'IfcObjectPlacement', 'IfcOrganization', 'IfcOwnerHistory', 'IfcPerson', 'IfcPersonAndOrganization', 'IfcPhysicalQuantity', 'IfcPresentationItem', 'IfcPresentationLayerAssignment', 'IfcPresentationStyle', 'IfcPresentationStyleAssignment', 'IfcProductRepresentation', 'IfcProfileDef', 'IfcPropertyAbstraction', 'IfcRecurrencePattern', 'IfcReference', 'IfcRepresentation', 'IfcRepresentationContext', 'IfcRepresentationItem', 'IfcRepresentationMap', 'IfcResourceLevelRelationship', 'IfcRoot', 'IfcSchedulingTime', 'IfcShapeAspect', 'IfcStructuralConnectionCondition', 'IfcStructuralLoad', 'IfcTable', 'IfcTableColumn', 'IfcTableRow', 'IfcTimePeriod', 'IfcTimeSeries', 'IfcTimeSeriesValue', 'IfcUnitAssignment', 'IfcVirtualGridIntersection’] Trim down to suitable “top-level” definitions: Objects, Types, Relationships, Properties, Representations, Resources For example for representation in SQLite or ArangoDB 

Objectified relationships, one to one Joining federated models Creating model subsets One to one pairs Containment node needs to be merged/recreated Containment node needs to be updated All good. Pure subset. 

Dependency hell Making changes in complex graph structures can have undesirable cascading effects. Create clearly compartmentalized structures: Tree: Type (geom + pset) -> Product (placement + pset) Graph: Element <-> Element (connections) Tree: Containment + Decomposition + Hosting Other than that: minimize dependencies, create self-contained definitions 

Self-contained elements with (schema-defined) parametric behaviour IfcPolyline IfcPolyline IfcLine IfcRel- Connects 

Semantic well-understood geometry Some procedural geometry definitions obfuscate semantics and are ambiguous and not universally understood. Case in point: - IfcCraneRailAShapeProfileDef (deleted in IFC4) - IfcTrapeziumProfileDef (deprecated in IFC4.3) - (more) 

Case in point (2): IfcExtruded/RevolvedAreaSolidTapered 1. The conventional name for this is a loft. An interpolation of cross sections (over an Axis). 2. Complex due to possibility of rotation 3. Revolution + scaling results in a non-primitive, non-ruled surface that’s hard to understand 4. “Given that the start and end section is provided by a polygon…” - no: could be any profile including curved 5. “The start profile is defined by an arbitrary bounded curve bounding a plane and …” - no: probably mistake in where rule: No blame here. Advocating the point that creating well-understood geometry definitions is very very hard. IF ('IFCPROFILERESOURCE.IfcDerivedProfileDef' IN TYPEOF(EndArea)) THEN Result := (StartArea :=: EndArea\IfcDerivedProfileDef.ParentProfile); ELSE Result := FALSE; END_IF; 

IfcRevolvedAreaSolidTapered The interoperable, flexible, semantic way Hint: Observe the similarity with IfcWall (Body + Axis) and infra alignment sweeps? IfcFlowFitting | IfcRelNests | IfcAnnotation (2) (or IfcPort) | IfcRelDefByProps | IfcPropertySet - IfcRepresentation (IfcCircle) - IfcRepresentation [Body] (explicit brep) + IfcRepresentation [Axis] - Radius=x nb: this is basically the transition from entity to “concept” the explicit body can act as shape validation 

migrate Our responsibility An intelligent, sustainable, circular built environment. Requires queryable, meaningful, well-understood, up-to-date content and long-term preservation. ifc migrate migrate export :) import :( time open native ? (community effort, project-specific) (individual responsibility) 

Conclusions Decomposition on element level as the generic mechanism. Uniform material and appearance means association of semantics can stay at element. Requires more intelligent instancing of types. Meaningful trait-based BuiltElement subtree informed by concepts Lower-dimensional geometric primitives to supplement interoperable, semantic and intelligent exchanges (as we have been doing since 2x) 

Conclusions IFC is a versatile and powerful basis Mainly shift in focus. Conceptualization of procedural definitions is meaningful, but don’t obscure in entity but brake down into universally understood primitives plus “concepts”. Necessary breaking changes are mostly: - latebound BuiltElement (paper) - intelligent types: geometry, decomposition, recursive (paper) - cleanup of non-element-level subdivision approaches - reorganization of resources into 5 or 6 top level facets - normalization of relationships (paper)