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.
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.
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 (notably IfcClassificationReference or IfcLibraryReference) with the profile.
IfcClassificationReference 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 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.
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
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.