-
Notifications
You must be signed in to change notification settings - Fork 4
Ten principles for a future IFC
Use the technology that developers and end-users are already familiar with.
Example: Consider more standard hexadecimal encoding as opposed to the bespoke GlobalId base64 encoding
Example: Consider glTF as a standardized representation of triangulated geometry
Example: Consider UTF8 as the representation for internationalized character sets
Complexity and additional indirections have often been added for versatility, upwards compatibility or efficiency, but simplicity should be the foremost concern without a significant loss of expressiveness.
Example from schema:
ENTITY IfcStyledItem
Item : OPTIONAL IfcRepresentationItem;
Styles : SET [1:?] OF IfcStyleAssignmentSelect;
Name : OPTIONAL IfcLabel;
END_ENTITY;
ENTITY IfcPresentationStyleAssignment;
Styles : SET [1:?] OF IfcPresentationStyleSelect;
END_ENTITY;
TYPE IfcPresentationStyleSelect = SELECT
(IfcCurveStyle
,IfcFillAreaStyle
,IfcNullStyle
,IfcSurfaceStyle
,IfcTextStyle);
END_TYPE;
ENTITY IfcSurfaceStyle
Side : IfcSurfaceSide;
Styles : SET [1:5] OF IfcSurfaceStyleElementSelect;
END_ENTITY;
TYPE IfcSurfaceStyleElementSelect = SELECT
(IfcExternallyDefinedSurfaceStyle
,IfcSurfaceStyleLighting
,IfcSurfaceStyleRefraction
,IfcSurfaceStyleShading
,IfcSurfaceStyleWithTextures);
END_TYPE;
ENTITY IfcSurfaceStyleShading
SurfaceColour : IfcColourRgb;
Transparency : OPTIONAL IfcNormalisedRatioMeasure;
END_ENTITY;
Explanation: There are a lot of indirections in the styled item association, i.e. to colour an element. While understandable from the point of view of (a) assigning styles to wide variety of items, rendering surfaces, hatches, line styles and (b) inheritance of other step resources, the current approach impacts simplicity.
Example from schema:
TYPE IfcPropertySetDefinitionSet = SET [1:?] OF IfcPropertySetDefinition;
END_TYPE;
Explanation: This entity was added to associate multiple property sets to elements in the same relationship for performance reasons. Yet, to enforce backwards compatibility a SELECT had to be constructed to also allow the previous singular association.
Single purpose resources (analogous to the parts 4x, 5x in STEP) increase implementation effort without adding enough value. Single-purpose definitions should be prevented or eliminated when there are viable more versatile alternatives.
Example: IfcRevolvedAreaSolidTapered
Explanation: Geometrical entity specifically for tapered elbow flow segments
Multiple ways of modeling the same situtation hinders interoperability and increases implementation effort.
Example: IfcMaterialLayerSet and element decomposition are both used for compound material layers.
Example: IfcBooleanResult and IfcOpeningElement both are used to model voids.
Appropriate modeling constructs are used to implement data modeling principles.
Example of violation from schema:
Quote:
The differences between the 1st and 2nd level space boundaries is identified by:
- 1st level:
* SELF\IfcRoot.Name = "1stLevel"
* SELF\IfcRootDescription = NIL
- 2nd level:
* SELF\IfcRoot.Name = "2ndLevel"
* SELF\IfcRootDescription = "2a", or "2b"
Explanation: The name and description attributes of the space boundary relationships typify an specialization. While understandable to enforce upwards compatibility these kind of implicit semantics should be avoided and subtypes should have been used instead (as is the case now).
Modeling constructs are to be limited to a well-supported subset of concepts supported in programming languages (Java, C++, C#, Python), schema languages (OWL, XSD, JsonSchema), data formats (SPFF, XML, RDF, JSON, HDF5).
Question: What does this imply for "algebraic sum types" (SELECT) it seems rather well supported in all formats (maybe least in HDF5)
Question: What does this imply for ordered aggregates (LIST/ARRAY) it seems rather well supported in all formats (although not as efficient in RDF)
Using clear attribute and entity names will prevent confusion. Do not depend on extensive documentation necessary for an initial understanding.
A reduced amount of entities and geometric resources without loss of expressiveness will result in less implementation effort especially for related domains such as urban planning, facility management, geospatial systems.
Consistency reduces implementation effort and confusion.
Example: IfcConnectedFaceSet.CfsFaces (SET) IfcPolygonalFaceSet.Faces (LIST)
Explanation: In the example above two attributes with more or less identical meaning and intention have both a different name CfsFaces vs just Faces and a different type (ordered vs unordered aggregate), there is likely no valid reason for this distinction.
No one standard can/should rule all use-cases. IFC should have a clear focus and scope. Although use-cases cán be supported is does not mean they should be when there are alternative standards available. Modularity helps in pairings with other standards and reduces implementation effort when only relevant modules need to be implemented. This means that extensive relationships between distinct modules need to be minimized.