modern workflows, identity of objects highly domain specific, little tooling -> 20y in, still no database, query language, efficient serialization, etc. rigidity of spf -> challenging backwards compatibility and extensibility complex and anachronistic JSON flatter, more self-contained structure ubiquitous flexible
named children (the same, as there is always the pseudo-root that wraps the roots in the data exchange) Class - Creates a generic set of traits to be inherited from (IfcTypeObject) - Used as an indirection in the spatial composition tree for compartmentalization Over - Assigns attributes/components (or additional children in a different layer)
opinions authored on one prim to every other prim that inherits the “source” prim; not only do property opinions broadcast over inherits arcs - all scene description, hierarchically from the source, inherits” Source: https:/ /openusd.org/release/glossary.html#usdglossary-inherits Contrast this with IFC4.x IfcTypeObjects: a specific-purpose, implemented in prose, mechanism that only governs how properties can be inherited/overriden. No mechanism for inheriting *hierarchies*.
opinions on primitives and write to a layer Conflicting opinions get resolved based on strength Strength is based on layer order (configurable at import time) and information locallity (inheritance)
override mechanisms) IfcPropertySet objectified relationships (contains, nests, aggregates, …) inheritance inheritance properties can be grouped in a prim, which is inherited by the occurence subprims (children) Reduce dependency on natural language text Align with industry practices Composed data with fewer indirection IfcMaterialList, ConstituentSet, LayerSet, …