# Proposal for IfcMaterial to become rooted

**URL:** <https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721>\
**Category:** Developers\
**Created:** [May 21, 2020, 10:35am UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721 "2020-05-21T10:35:28Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\
**Post date:** [May 21, 2020, 10:35am UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/1 "2020-05-21T10:35:28Z")

</div>

Rooted elements, in my opinion, should represent highly identifiable, first-class domain-specific objects. I believe `IfcMaterial` fits this criteria. In addition, materials are usually represented as their own user manipulatable, export/importable, object in most authoring applications - not just a mere property, but an object in its own right.

Materials also have significance in LCA analysis, modern slavery tracking, warranty and certification for facility management.

I am also painfully aware of the current poor vendor support for IfcMaterial, leading to confusion between material and colours, which are related, but separate concepts. Hopefully, with an upgrade of IfcMaterial to a rooted entity, it will also gain more widespread and proper usage instead of being lost on imports and exports.

Therefore, I propose for IfcMaterial to become rooted, and therefore have a GlobalId associated with it.

Thoughts?

---

<div class="post-metadata">

**Author:** ![Jesusbill](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jesusbill/32/1122_2.png) [@Jesusbill](https://forums.buildingsmart.org/u/Jesusbill)\
**Post date:** [May 21, 2020, 12:38pm UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/2 "2020-05-21T12:38:47Z")

</div>

I absolutely agree with this. I would actually add in the same conversation IfcProfileDef, I believe one can make similar considerations.

---

<div class="post-metadata">

**Author:** ![stefkeB](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/stefkeb/32/1755_2.png) [@stefkeB](https://forums.buildingsmart.org/u/stefkeB)\
**Post date:** [May 22, 2020, 7:40am UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/3 "2020-05-22T07:40:34Z")

</div>

I agree that Materials are a first class citizen in the construction industry. Most of our cost and impact analysis evolves around materials, a whole segment of our industry evolves around materials.

If a manufacturer of a material wants to deliver their “product” in an open format, in IFC, they now have to somehow make a very convoluted IFC-file, including a project, a building and possibly even another objects in which this material may be applied.

I’ve seen product libraries of brick manufacturers which actually have to share walls to be able to include their material. Imagine you are a manufacturer of “sand” or other basic resources…

It may also push some vendors of BIM software to spend some more attention to sharing materials and their properties into IFC. Right now, most software and viewers show little more than the “name” of a material.

---

<div class="post-metadata">

**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\
**Post date:** [June 3, 2020, 11:51pm UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/4 "2020-06-03T23:51:40Z")

</div>

Just to add to the record on IfcProfileDef, there are some conventions on relating profile definitions to trackable standards. I’m not versed well enough in this to judge if this is appropriate or not, but just an FYI. The next question for me is, if an `IfcClassificationReference` is the solution, is anybody distributing or standardising canonicalised lists of manufactured profiles in different countries?

> If the profile is standardized by a norm or a catalogue, a reference to this norm or catalogue should be provided by means of _HasExternalReference_ . This inverse relationship is used to associate an [IfcExternalReference](https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcexternalreferenceresource/lexical/ifcexternalreference.htm) (notably [IfcClassificationReference](https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcexternalreferenceresource/lexical/ifcclassificationreference.htm) or [IfcLibraryReference](https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcexternalreferenceresource/lexical/ifclibraryreference.htm)) with the profile.
> 
> [IfcClassificationReference](https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcexternalreferenceresource/lexical/ifcclassificationreference.htm) is used to refer to a profile norm (a common standard or manufacturer’s standard). In this case,
> 
> - _IfcClassificationReference.ItemReference_ contains the formal profile designation from the norm. (On the other hand, _IfcProfileDef.ProfileName_ contains a displayable name which may not necessarily be the same as the formal designation.)
> - _IfcClassificationReference.Name_ carries the short name of the profile norm.
> - Optionally, the norm can be further described by _IfcClassificationReference.ReferencedSource_ .
> 
> [IfcLibraryReference](https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcexternalreferenceresource/lexical/ifclibraryreference.htm) is used to refer to a library which contains profile definitions. In this case,
> 
> - _IfcLibraryReference.ItemReference_ contains the identifier of the profile within the library and is meant to be machine-readable (in contrast to _IfcProfileDef.ProfileName_ which should be human-readable).
> - _IfcLibraryReference.Location_ and . _Name_ or . _ReferencedLibrary_ further describe the library.
> 
> If an external reference is provided, sending systems shall ensure that the shape of the profile definition object agrees with the definitions in the referenced classification or library.

---

<div class="post-metadata">

**Author:** ![Jesusbill](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jesusbill/32/1122_2.png) [@Jesusbill](https://forums.buildingsmart.org/u/Jesusbill)\
**Post date:** [June 8, 2020, 3:27pm UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/5 "2020-06-08T15:27:20Z")

</div>

This is an interesting piece of information that I did not know of.  
There are official documents that reference profile properties like for example `EN 10365 – The European Norm for Structural Sections in Steel`. But similar documents exist also for structural materials like for example steel (EN 10025), concrete (EN 206) and so on.

What happens though for general profiles not part of these documents?

In any case, my idea suggesting to put profile in the conversation is perhaps conditioned by the work I do on structural analysis (for a column or a beam, material and profile are two equally important metadata handled similarly in my experience). I was a bit surprised to see that materials and profiles did not have their own global identifiers which I could directly use to reference them when parsing an ifc file in a json format, the same way as elements and connections can be referenced.

That said materials are indeed more important in general and my suggestion could be slightly out of scope

---

<div class="post-metadata">

**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\
**Post date:** [October 6, 2020, 7:24am UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/6 "2020-10-06T07:24:54Z")

</div>

Bump bump?

---

<div class="post-metadata">

**Author:** ![Theoryshaw](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/theoryshaw/32/362_2.png) [@Theoryshaw](https://forums.buildingsmart.org/u/Theoryshaw)\
**Post date:** [December 7, 2020, 2:53am UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/7 "2020-12-07T02:53:34Z")

</div>

+1

I had recommended this many moons ago as well.

> <https://github.com/buildingSMART/IFC4-CV/issues/18>
>
> For IFC5, would it be possible for an IFCMaterial to have a GUID associated with it?
> Didn't know where to place this...

---

<div class="post-metadata">

**Author:** ![PaulBurrows](https://avatars.discourse-cdn.com/v4/letter/p/ecd19e/32.png) [@PaulBurrows](https://forums.buildingsmart.org/u/PaulBurrows)\
**Post date:** [December 12, 2020, 10:17pm UTC](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721/8 "2020-12-12T22:17:58Z")

</div>

The GUID would surely help Materials manufacturers and suppliers to identify and version their products in Ifc. I’m very much in favour of this idea.
