IfcFacilityPart.PredefinedType

[NickNisbet]

IfcFacilityPart.PredefinedType is unlike any other PredefinedType. The exceptional representation of IfcFacilityPart.PredefinedType is so disruptive to implementation that, although 'correctly' specified, it should count as a significant Bug.

The majority of my programming time over the last three months has been devoted to correctly implementing this and then finding that other tools do not handle it properly.

Surely it is not beyond the collaborative working of the different infrastructure sub-projects to consolidate the allowed values of the enum into a single list, bringing this PredefiendType back into line with ALL others.?

[aothms]

I agree it's somewhat unfortunate. 1. Within the group of implementers there appears to be quite a few that want to work towards minimizing the use of "sum types". So it's somewhat odd that we're introducing a whole new use of them (union of enum). 2. Furthermore, it's only temporary as in IFC5 all of the predefined type stuff will be eliminated in favour of purely latebound element typing. 3. Conceptually, a union of enum is in my point of view problematic. An enum is a union of unit types, so we're creating here a union of unions of unit types and depend on the fact that in the express modelling language these enumerations are "namespaced" (i.e enum elements with the same name are not considered unique). In most programming languages and conceptual models though enums are not namespaces and then union of unions of unit types is equal to just a union of unit types.

At this time I doubt something can still be done though?

[SergejMuhic]

it's only temporary as in IFC5 all of the predefined type stuff will be eliminated in favour of purely latebound element typing

Sorry, of topic but I am not sure where else to put this. Why not just use classification and publish an IFC late bound classification system on bSDD? This would be an awesome bSDD advertisement and showcase. Wherever the cut off takes place, just add a direct Classification attribute to IfcClassificationReference. This would also enable to not have any typing if it is not needed. If I just want to see my "331 Tragende Wand" I don't really need to know anything other than that it is an IfcElement. Why type it at all in this case since classification does everything?

FYI, reasoning for the various type enums in IfcFacilityPart was a compromise between domains on how to handle their own types in their own domain. Don't shot the messenger please. I proposed it as sort of a joke because the discussions just did not go anywhere as ditches were dug deep. I had no clue that anyone would go for this. I need to learn how to keep my mouth shut.

[Moult]

This is marked as decided, but it wasn't clear what the conclusion was? Is the decision to leave it as is for the moment as a temporary measure?

[aothms]

Note this also applies to:

• IfcImpactProtectionDevice (IfcImpactProtectionDeviceType)
• IfcTransportElement (IfcTransportElementType)

[Moult]

To clarify, the decision to solve this is to split out the class into subclasses. Each subclass would have one enumtype. No more select of enums.

[TLiebich]

or to flatten it into a single list - could we look into the three occasions one-by-one? e.g. IfcImpactProtectionDevice might already be so specialized that it would be rather unbalanced to add another level of sub classes. Why not adding the means of impact protection as an own property?

Whereas IfcTransportElement is best split into two - the existing IfcTransportElement being fixed and IfcVehicle (or similar) non fixed.

[aothms]

@TLiebich we did that this morning and for several reasons in all cases we found subtyping the best option e.g closest to semantics from the projects, separation of concerns in terms of responsibilities and subschemas (IIRC IfcImpactProtectionDevice had different enums coming from HVAC vs infra)

I must say I really like the suggestion of IfcVehicle instead of the IfcTransportElementNonFixed we had planned.

[TLiebich]

if there are good semantic reasons, I am fine.

note bene: I found other inconsistencies in handling PredefinedType

• leaf note classes of IfcProduct / IfcTypeProduct missing PredefinedType
• PredefinedType at non-leaf-node class

to 1st.

• IfcSolidStratum, IfcVoidStratum, IfcWaterStratum - all not having a predefined type and only differing be pset
• could be predefined types of IfcGeotechnicalStratum

to 2nd.

• IfcGeographicElement has predefinedType and subtype IfcVegetation

[aothms]

See below for some screenshots of the modifications.

Questions and comments:

• Predefined type made non-optional. What's the significance of an optional predefined type when there is NOTDEFINED? (easy to change let me know)
• The association classes in the new version are the object-objectype associations from general usage. I still need to spend some time to convert these into the where rules on the fly for CorrectTypeAssigned. That way, the rules on other entities can be eliminated as express definitions from the UML, and all be automatically derived from associations. Currently the generated exp doesn't have the rules for these entities.
• I need to double check the pset associations, but I think this goes automatically ok, since they are either associated to the parent type, or to the predefined type. In case of the latter the relevant entity is looked up automatically when psd xml is serialized
• I made the parent types abstract. Thoughts?
• Not all names are nice i.e IfcFacilityPartCommon IfcImpactProtectionDeviceCommon IfcTransportElementFixed. Any ideas?

Facility part

Impact protection

old

new

Transport

old

new

[TLiebich]

a few objections ;-)

• PredefinedType mandatory - the general modeling convention in IFC4 is, that the PredefinedType at a type object is mandatory but the PredefinedType at occurrence object is everywhere optional. We should stick to it.
• where rules - strictly speaking, we could drop all where rules regarding CorrectTypeAssigned if we would foster the use of general usage in validation / certification. Essentially it is a dublicate (and existed, before the mechanism of concept templated and General Usage had been introduced in IFC development)
• names and subtyping - we need to observe the compatibility rules here. E.g. IfcTransportElement is available since IFC2.0 and used in certified official MVD's - if we make it now an abstract supertype, we break compatibility rules - valid IFC4 RV files become invalid. Same for IfcImpactProtectionDevice.
• proposal: add a new abstract intermediate supertype - say IfcTransportationDevice and subtype IfcTransportElement and IfcVehicle from it - similar for IfcImpactProtectionDevice - IfcFacilityPart is new in IFC4.3 and should not be affected.

a related question (or better open a new issue) -road, rail and port&waterway part is defined in own sub schemas, bridge part not - isn't it inconsistent?

[aothms]

Thanks @TLiebich for the insightful and quick comments

• PredefinedType mandatory.

  Ok will change it

• That's the plan, but with the addition to re-serialize them to express for compatibility
• It seems your third point is fixed by your 4th.
• I agree, it's a reasonable. I tried to do something similar but couldn't figure out the naming.

So

• ABS IfcTransportationDevice > { IfcTransportElement, IfcVehicle }
• But what naming can we figure out for IfcImpactProtectionDevice? Currently it's: IfcImpactProtectionDevice > { IfcVibrationDamper, IfcImpactProtectionDevice, IfcVibrationIsolator }. We can also remove the intermediate type and immediately inherit from IfcElementComponent.

[aothms]

Ok, just to put in something, I now have

IfcAbstractImpactProtectionDevice > { IfcVibrationDamper, IfcImpactProtectionDevice, IfcVibrationIsolator }.

I tried to look up a shared hyperonym of vibration and impact, protection and isolation, but didn't find clues. Didn't want to invent my own thing such as a IfcKineticEnergyHandlingDevice.

My current preference is to actually remove the intermediate supertype and have them directly under IfcElementComponent. When i don't hear objections I will move on with that in the coming days.

IfcElementComponent -> {IfcBuildingElementPart, IfcDiscreteAccessory, IfcFastener, IfcVibrationDamper, IfcImpactProtectionDevice, IfcVibrationIsolator, IfcMechanicalFastener, IfcReinforcingElement, IfcSign}

As for example I don't think the { IfcFastener IfcMechanicalFastener } concepts are any less disjoint than { IfcVibrationDamper, IfcImpactProtectionDevice, IfcVibrationIsolator }

Edit: it looks like that was the case in RC2.

[aothms]

[TLiebich]

would second to skip the intermediate abstract supertype

[Moult]

It looks as though this is now implemented. Can I close this?

[evandroAlfieri]

Notes for railway stakeholders - as requested:

Context Some railway stakeholders are considering to reuse the material produced during the IFC Rail Project for next projects and for internal purposes.

Warning The decision made with this issue results in a change of schema (i.e., the one delivered to ISO is different from the one used for the tests). Please, note that the following material for the topics and tests involving spatial structure is to be considered invalid and cannot be reused as it is:

1. dataset
2. unit test cases
3. storyline tests
4. test instructions
5. reference IFC files provided by TS
6. proof of implementation (IFC files) provided by vendors

Based on project's deliverables, the affected stakeholders are:

• RFI
• SBB
• Trafikverket and Finnish Transport Agency
• MINnD

A quick estimation shows that this change affects 20%-25% of the IFC 4.3 files delivered by the Project during Unit Test and Storyline phase.

Additional note At the time of writing, it is not clear if tests or reference files for the newly proposed solution are available - or were produced and made available, and reviewed, before issuing the change.

@czapplitec @larswik

[aothms]

@evandroAlfieri note that several other issues have been incorporated that also affect schema. Most of them are building domain related and often compatible additions, but at the very least issues such as https://github.com/buildingSMART/IFC4.3.x-development/issues/397 might directly affect some data?

[evandroAlfieri]

Thanks @aothms. The Rail project haven't run a proper check, against all changes. I'm confident that building-related changes do not affect our work, and that changes like the one you flagged (#397) impacts maybe 3 or 4 files. At a quick look, this spatial structure change appears to be the most critical (for the project's work)