Encode all PredefinedType ENUM values as SUBTYPES in EXPRESS

[pipauwel]

There is no good reason to not encode the ENUM values in PredefinedType as SUBTYPES.

For example:

TYPE IfcSensorTypeEnum = ENUMERATION OF
    (COSENSOR
    ,CO2SENSOR
    ,CONDUCTANCESENSOR
    ,CONTACTSENSOR
    ,FIRESENSOR
    ,FLOWSENSOR
    ,FROSTSENSOR
    ,GASSENSOR
    ,HEATSENSOR
    ,HUMIDITYSENSOR
    ,IDENTIFIERSENSOR
    ,IONCONCENTRATIONSENSOR
    ,LEVELSENSOR
    ,LIGHTSENSOR
    ,MOISTURESENSOR
    ,MOVEMENTSENSOR
    ,PHSENSOR
    ,PRESSURESENSOR
    ,RADIATIONSENSOR
    ,RADIOACTIVITYSENSOR
    ,SMOKESENSOR
    ,SOUNDSENSOR
    ,TEMPERATURESENSOR
    ,WINDSENSOR
    ,USERDEFINED
    ,NOTDEFINED);
END_TYPE;

Could / should be done as:

ENTITY IfcSensor
 SUBTYPE OF (IfcDistributionControlElement);
 SUPERTYPE  OF (ONEOF
    (COSensor, CO2Sensor, ConductanceSensor, ContactSensor, FireSensor, FlowSensor, FrostSensor, GasSensor, HeatSensor, HumiditySensor, IdentifierSensor, IonConcentrationSensor, LevelSensor, LightSensor, MoistureSensor, MovementSensor, PHSensor, PressureSensor, RadiationSensor, RadioActivitySensor, SmokeSensor, SoundSensor, TemperatureSensor, WindSensor));

This easily translate to quite common subclassing structures in other languages, allowing easier extensibility.

USERDEFINED and NOTDEFINED should not be included in a schema. If it is not defined, then it is simply not there in the data. If the user defines it, well, then he should define it - potentially/ideally as an extension to the schema.

[jmirtsch]

I have a very different point of view to this. We don't need thousands of classes in IFC simply for the point of classification. You can refer to this discussion to consider altering classification in IFC. https://github.com/buildingSMART/NextGen-IFC/issues/14

[berlotti]

Lets focus on the strategy: https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC

Does this suggestion contribute to that? Does it tick the boxes of what we try to achieve? This is not the open discussion forum, but a focussed activity with clear goals and objectives.

[pipauwel]

I have a very different point of view to this. We don't need thousands of classes in IFC simply for the point of classification. You can refer to this discussion to consider altering classification in IFC.

14

Okay. That sounds like a preference to late binding. Then... can we make that a clear choice, and remove those predefinedTypes (ENUMs) from the IFC schema? Maybe that is also what is suggested in #14? Is there then a reason why Wall, Window, and so on are not part of this late binding? It might make more sense to allow defining all sorts of hierarchies outside of the system schema, and instead move all these more user-specific hierarchies to a bSDD-like mechanism.

That seems to be also the suggestion by @jwouellette in #14:

@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).

Same strategy should be followed also for the PSETs (see #15).

[aothms]

Wall, Window, and so on are not part of this late binding

They will be most likely.

So we should probably rephrase the proposal here a bit:

• How do we model subtype relationships in the late binding approach?
• How do we provide a comprehensive view on the IFC schema including late-bound additions that enables an comprehensive mapping to other schema languages such as OWL?

[pbourreau]

Perhaps we need a revision of the different IfcXXXTypeEnum, for a given IfcXXX class.\ In the case of an IfcSensor there could be, at least, two kinds of subtypingd regarding:

• what is actually measured by the sensor
• how is the measure performed/transferred (at a regular frequency; when the value of the measure changes...)

Is there an agreement of what is type of sensor?

From a modelling point of view, I believe the question of using late binding or subtyping depends on the related additional information:

• if late binding is used to characterize the measure itself (for instance, temperature), I may need to attach the Unit (in a unit attribute of my IfcSensor)... late binding is not that great in this case. Alternatively, we can have a Measure class (just like in the SOSA ontology...) that encapsulate the type of measure (i.e. Temperature) and the Unit (i.e. degree celsius), and use this Measure in the late binding (sorry, I am bit diverging here...)
• similarly, if I want to describe a sensor that collects data at a given frequency,I may need to specify the frequency itself... But I do not want to have such attribute in IfcSensor, i.e. shared with all sensors, because this is not required for value-change sensors...

[HerbertDobernig]

My comments based on comments from @aothms @pbourreau:

"... comprehensive mapping to other schema languages such as OWL" I support the shift towards late binding and loose coupling because it corresponds to the peculiarity of engineering processes where projects start from uncertain assumptions and a first rough product model that is refined in several loops by adding more and more details.

The sensor example is helpful to reveal the challenge:

1. During a project the engineer recongnizes the need for a fluid-level-sensor. He adds an entity (with GUID) to the model and tags it as fluid-level-sensor
2. Later in the project the fluid level range = [lowLevel, highLevel] is attached to this entity
3. Finally a subcontractor decides to implement the fluid level sensor function using two capacitive sensors and a sensor measurement unit (instead of e.g. a floater)

Thus, the model evolves as a information network of loosely coupled entities with loosely coupled relations and property values attached to it (similar to the current trend of loose coupling in semantic web technologies like OWL).

=> I have a preference to late binding to facilitate successive model refinement.

[pipauwel]

So we should probably rephrase the proposal here a bit:

• How do we model subtype relationships in the late binding approach?
• How do we provide a comprehensive view on the IFC schema including late-bound additions that enables an comprehensive mapping to other schema languages such as OWL?

+1 - yes I think that is what we need to rethink.

Very well aligned with #14 - so topics should likely be merged.

[TLiebich]

actually this is why I created #28 - to discuss the "how" we can define such a late binding approach to subtypes and enumerations (the element taxonomy) and to properties. For now property definitions are pubished as psdxml files as part of the IFC specification and referenced by string "equal name". I would opt to discuss both together under #28.

I would opt to close this issue, and refer to #28. The original proposed resolution (create subtypes for all enums) is rejected, but the need for a late binding approach has been reconfirmed.