IfcMaterialConstituent / IfcShapeAspect - Optional NAME Attributes

[gmn3DS]

Description

Hello,

The following diagram describes the identification mechanism regarding material constituents:

In order to identify a material set's constituent, both Name attributes from IfcMaterialConstituent and IfcShapeAspect need to be defined and matching.

However these Name attributes are both OPTIONAL :

IfcMaterialConstituent Express

IfcShapeAspect Express

Hence, the identification mechanism is made optional and defeats the purpose of the material constituents concept.

First Proposal

Adding a rule making both attribute mandatory

• IfcMaterialConstituent.Name shall not be OPTIONAL
• IfcShapeAspect.Name shall not be OPTIONAL

Second Proposal

Adding a rule checking that if any of the following entities (+subtypes); IfcElement, IfcElementType, IfcStructuralMember, IfcPort have association to IfcMaterialConstituent and instances of IfcShapeAspect pointing to their IfcProductDefinitionShape then:

• All IfcMaterialConstituent.Name shall have a keyword defined by at least one IfcShapeAspect.Name

I don't really know about the flexibility of gherking-rules or the best way to write this concept. Feel free to correct the previous proposals, formulate a new one or simply participate.

[aothms]

There are also voices in the community that we should rather deprecate this (https://forums.buildingsmart.org/t/ifcmaterialconstituentset-ifcshapeaspect-ifcphysicalcomplexproperty/2164). It is a lot of complexity, indirection and backwards compatibility for something that could be expressed simpler by means of simple element-level decomposition.

I think the rule you propose (or some variant of which we can agree on) makes sense, but before investing effort in it (especially from your side) I think it's maybe beneficial to first look at the big picture.

What's your use case, what are you planning to exchange with this, and do other vendors agree that this is a good modelling paradigm for that use case?

[gmn3DS]

Thanks for your answer Thomas.

As of today, I don't have any information regarding the big picture. I guess it was purely a question regarding schema implementation. I was reviewing the different ways of handling materials in IFC and stumbled across this one which seemed fuzzy :D.

I'm fine with closing the issue now and coming back to it when more information arise.

[aothms]

I see. There are some dark corners in the IFC schema. Especially for materials there are also not always perfect solutions in the schema and it's a tradeoff between expressiveness, level of detail, verboseness and implementation support in other tools. For me it's not necessary to close the issue, we can keep it open to see if other vendors chime in. I'll leave it to @evandroAlfieri.

[evandroAlfieri]

5 months, no one else chimed in. I'm closing this. Will re open if required