search

buildingSMART / IFC4.3.x-development

Repository to collect updates to the IFC4.3 Specification
Other
161 stars 83 forks source link

Proposal for IfcMaterial to have an inverse HasContext #67

Open Moult opened 3 years ago

Moult commented 3 years ago

A missing "HasContext" inverse attribute implies that an IfcMaterial may not be declared back to the IfcContext. This then creates the assumption that you cannot directly distribute an IfcProjectLibrary of pure IfcMaterials.

Naturally, everybody expects the ability to share a material library, so I propose to add this inverse attribute.

Note that this issue may also be part of a bigger solution to make rooted materials.

TLiebich commented 3 years ago

I agree to the expressed need by I would disagree to the propsed solution. As said, it is a bigger issue to align rooted and non-rooted definitions. Just adding not-rooted material to IfcRelDeclares (which on the other side would also mean to change IfcRelDeclares.RelatedDefinitions) is in my view too much of a quick-and-dirty solution.

One idea - out of my brain without much time spended to think about the ramifications: consider adding an IfcLibraryTemplate (naming completely unreflected for now) as subtype of IfcPropertyTemplateDefinition (which has the "HasContext") and then create a possibility to link IfcMaterial (by also IfcProfileDef and eventually others) as an Item of an IfcLibraryTemplate. An instance of IfcLibraryTemplate would then include all IfcMaterial Definitions you want to share as a material library for your project.

Moult commented 3 years ago

I've heard through the grapevine that IfcMaterial may be getting a revamp for IFC5. Should this issue be marked on hold?

TLiebich commented 3 years ago

depends on the urge of the original request - is the need to exchange a library of material (and similar) under IfcProject urgent, so that it cannot wait for a full resolution in IFC5 (which would mean "big guess" more then 5 years from now for practical use), or does users require it earlier (then have an in between solution).

Moult commented 3 years ago

Well, there is a workaround already, given that I have already implemented IfcProjectLibrary and the ability to import from them. I simply treat any IFC as a project library (the vast majority of the industry do not have the capability to create libraries, so I support "regular" projects as libraries too), and let them browse any IfcMaterial defined in there. Even for stuff which can be declared, like IfcWallType, I let them browse all types, though I do highlight declared ones. So no, not a huge issue.