Consider removing IfcComplexProperty

[KnutHelland]

Description of the proposal:

IfcComplexProperty complicates the property system by turning properties into a tree structure. In the official psets, it looks like this is only used for Pset_MaterialWoodBasedPanel::InPlane and Pset_MaterialWoodBasedBeam::InPlane.

This really complicates user interfaces. (is there any existing software that supports them?) Couldn't these two properties instead be separate psets? For example Pset_MaterialWoodBasedPanelInPlane and Pset_MaterialWoodBasedBeamInPlane

Describe how it contributes to the objectives:

This would simplify the data model for properties significantly. I guess that this is one such feature that is not well supported in existing software.

Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one):

remove

What do we win:

Simpler modelling of properties. For example, it makes it easier to efficiently fit properties into a rational database and to quickly search for and to make reports of properties.

What do we lose:

Probably a lot of flexibility, but it doesn't seem to be much used. Properties can today be a deeply nested tree structure by using complex properties. But I've never seen this in use.

Schema impact:

Remove entities: IfcComplexProperty, Remove inverse attributes: IfcProperty::PartOfComplex Can also remove the abstract class IfcSimpleProperty since all properties will now be simple.

Instance model impact:

Backwards compatible:

No. Existing use of complex property will not be valid. A few existing pset definitions will have to be changed.

Automatic migration possible:

No. Must change the very few psets that use this feature today. The two existing standard complex properties must be moved out from their psets into separate psets.

[berlotti]

Awesome suggestion. Exactly what this repository is for. Thank you!

[NickNisbet]

Lets not make 'has it been used by brand X or brand Y?' the criteria. Does a complex property have meaning? Yes, because some properties have meta-properties surrounding it (like value and source or value and is-requirement/is-claimed).

[KnutHelland]

Lets not make 'has it been used by brand X or brand Y?' the criteria.

No brands were mentioned. But one of the bullet points from this document https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC is:

• Many of the advanced structures in IFC have been proven to be too complex for software vendors to implement. The time that vendors need to implement IFC is too long, and for vendors that have lower commercial interest in supporting IFC the threshold becomes too high. This results in half-baked implementations that cause problems for end-users.

So if features that have existed for a long time in the schema still remain unimplemented at vendors, it is a valid indication that the feature may be either too complex to implement or that it isn't needed.

Please also note that I don't know if it is implemented in different software out there. I am just guessing, based on the marginal use in the standard psets.

Does a complex property have meaning? Yes, because some properties have meta-properties surrounding it (like value and source or value and is-requirement/is-claimed).

Good example. But this does not require tree-structured properties, so I would still prefer to simplify the property system a bit. This leads me to:

Alternative proposal:

To change the type of the attribute IfcComplexProperty::HasProperties from IfcProperty to IfcSimpleProperty so that tree-structured properties aren't supported.

Because I agree that there can be valid use cases for complex properties. Today we have the IfcPropertyReferenceValue which can hold a lot of different "complex" values (IfcMaterial, IfcPerson, IfcOrganization, IfcTimeSeries etc). And many of these are used by standard psets. So the need for storing "complex" data on a property is definitely there.

If IfcComplexProperty is kept in the next generation of IFC, it could instead be considered to remove IfcPropertyReferenceValue since they can be represented as IfcComplexProperty properties instead. That would make the property system more generic, and software that deals with properties without knowing about all these special case properties.

[stefkeB]

Did you check with domain experts from e.g. acoustics where non simple properties are being applied?