Utilize a concept such as Generics.

[jmirtsch]

It seems that popular programming languages provide the mechanism to use generics.

https://en.wikipedia.org/wiki/Generic_programming

Lots of leaf classes inheriting from IfcTypeObject and IfcObject only add a single attribute PredefinedType. Here’s an example of IfcAirTerminalType showing many layers with no attributes.

Some details still need to be thought through, but potentially we could terminate the derived classes at IfcObjectType by taking advantage of the concept of generics. The PredefinedType attribute could be stored at the tier of IfcObject and IfcTypeObject, saving on a lot of children attributes.

A related refactor would be the direct reference of the relating type to the instance.

This can reduce the number of official classes and attributes significantly in the schema, allowing "Late Binding" of classification.

[EAzari]

@jmirtsch It seems that you've started the idea I introduced in IfcXtreme (https://github.com/IfcXtreme/IfcXtreme) which makes me happy

Also, one more time think about it, it will bring a "new data modeler" in the industry which will change everything

[jwouellette]

@jmirtsch In this particularly egregious case of class hierarchy gone mad (the Building Services domain and its elements), I propose we work on simplifying the schema and separate the object class hierarchy from the system class hierarchy, using the more generic (and appropriate) IfcSystem or IfcGroup usage with proper enumeration (could better utilize late binding classification in that way, as well).

[TLiebich]

support @jmirtsch here - yes this single decision would offer the highest return in regard to simplification. However I would strongly maintain, that is has to be resolved in conjunction with a late binding approach on taxonomy that is still an integral part of the overall IFC specification (and thereby ISO 16739), always noting that the IFC specification includes more then the IFC schema. The taxonomy needs to be published as part of each IFC Release, has proper version management and governance structure (who decides on any modification). It would be available as a downloadable configuration file (similarly to the PSD files for property set definitions). Most software systems have a fixed and configurable mapping structure (both! is needed) to map their internal types (families, libraries, ...) into specific IFC classes.

[TLiebich]

In particular, and derivating from @jmirtsch proposal I would argue, that the cut shall be done at either IfcProduct/IfcTypeProduct, or IfcElement/IfcElementType level.

• minimum IfcProduct, since it introduces the difference between objects having geometry (all products) and those that haven't (like processes, controls),
• eventually better IfcElement, since here the distinction between project/spatial structure (site/buillding/story) and physical elements (plus annotations, alignments, etc.) begins.

[EAzari]

Systems Engineering has this structure which I think will help IFC schema too: System --> Element --> Part

[SergejMuhic]

This would make #20 obsolete also.

[pbourreau]

I am not fully sure the use of generic-programming is the proper solution to this issue. The typical example for generic programming is that of some collection of elements: something like Collection<Object>that can later be instantiated as a collection of Strings, or Integers, or Spaces etc. The relation between IfcAirTerminal and one of the IfcAirTerminalTypeEnum is, conceptually speaking, a subtyping relation: I suggest to have every such enumerated type as a subclass of the parent type because:

• for specific projects, you may need to attach particular properties to your child concept (let's for a LouvreAirTerminal), that you do want to share with other sibling elements.
• I consider inheritance as the most basic concept to model data. Whenever we can restrict the modelling to the use of inheritance we shoud stick to it. ENUM, for instance, is not shared between all modelling languages.

[klacol]

A generic approach is good, but only, if the systems, that provides the late-binded-classes are existing in reality.

For me it stays unclear, why a class like IfcWall should be late binded, and a class like IfcSite not. In the end the most generic approach would be one single class called IfcGeneric.

I see, that the discussion mostly is about the classes derived from IfcProduct because different people have different thoughts on the structure of a building. But if everyone interprets the classes new, the meaningfull exchange will be a problem.

For me, it is more, to find a way to load the sub classes of IfcProduct from different sources and the today-subclasses of IfcProduct in ISO 16739 could be one (the primary?) source.

[pipauwel]

For me, it is more, to find a way to load the sub classes of IfcProduct from different sources and the today-subclasses of IfcProduct in ISO 16739 could be one (the primary?) source.

I think that makes sense.

Question then becomes: what are those different sources? Is this an EXPRESS subschema, an XSD schema, OWL ontology, and JSON schema (trying to be technology independent here)?

I would be in favour of separating those hierarchies under IfcElement out of the main schema, and making them available as separate vocabularies.

Do we do an effort in standardising those different sources? Or can anyone just write whichever (national) standard? I think we should maintain the ISO 16739 standard in this case.

Then, how to refer to those in the data files?

1. One option is to annotate objects with a string - string-based matching. Less elaborate and closer to the ENUM PredefinedType technique.
2. Another option is to load subschemas that can be used for classifying data. More elaborate and closer to the IfcWall example. In this case, there is no more need for ENUMs of strings - proper subclasses with properties can likely be used for making annotations.

Both seem to be late binding. @jmirtsch: not sure which one of these options comes closest to ´Generics´?

The same applies to the properties, I think.

[klacol]

This is also related to the discussion in #28:

to discuss the "how" we can define such a late binding approach to subtypes and enumerations (the element taxonomy) and to properties.

Perhaps, we look how other schema systems solve that. In JSON-Schema, they call it "schema extending": https://json-schema.org/understanding-json-schema/structuring.html#extending

We would need something like a meta-schema for the sub-schema under IfcElement/IfcProduct The meta-schema would define the structure of the sub-schemas that can be loaded (late-binded) from a different source.

The meta-schema would be a combination of a hierarchical list of classes and class-specific property sets.

But, is it so simple? Or is the existing schema under IfcElement much more complex and therefore not easy exchangeable?

[o314]

Beware that generic in cs/it has retrospectively been a killer in term of technology / language independance.

It could be very useful at the implementation level, but it is very wise to remove it at the interface level.

In practice, balancing soundly and quickly between both parts can become an art of wizardry ...