How to ask for occurrences of IfcAirTerminal(Type) in case of IFC2x3?

[MatthiasWeise]

From IFC2x3 specification: “The occurrences of the IfcAirTerminalType are represented by instances of IfcFlowTerminal or its subtypes.”

Current IDS entity facet does not allow to restrict IfcTypeObject, which would be needed in case of above example for IFC2x3.
Or is there another way to handle this case?

Proposed extension (adding optional typeObject restriction to entity facet) is also relevant for #88.

[aothms]

At some point it was discussed to make, what is currently, partOf more general, so that you'd be able to say something like:

applicability
  entity
    IfcFlowTerminal
  relates
    relationship: IfcRelDefinesByType
    entity: IfcAirTerminalType

or

applicability
  entity
    IfcFlowTerminal
  relates
    attribute: IsDefinedBy
    entity: IfcAirTerminalType

The concern was the introduced complexity for authoring and checking in non-ifc environments, etc.

Therefore this is indeed currently a limitation. typeObject on entity sounds reasonable, but indeed is a bit messy on non-object entities.

One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType. We encode this in a table as part of the spec. Which is also nasty, but would make the IDS compatible with IFC4 and doesn't require a schema change.

[MatthiasWeise]

Using IfcAirTerminal is most likely the most convenient solution for IDS users (IFC schema version independent). However, I do not like agreements captured in additional tables.

Using the PartOf facet might work as well, although "PartOf" suggests a different semantic meaning. Technicaly, this comes close to the typeObject setting in the entity facet.

Another potential type of confusion is the predefinedType setting: in above example it need to be checked on IfcAirTerminalType (maybe not that critical, but worth to point out).

[dro007]

This is a critical issue. IFC2x3 needs to be supported in IDS v1.0

[Moult]

This is a fundamental problem in IFC, not in IDS, I believe. IFC2X3 did not have the EXPRESS rules that restricted the class-pairs to be used for types and occurrences. I'm not sure it's up to IDS to make up for this shortcoming.

[MatthiasWeise]

We cannot change IFC2x3 and somehow have to deal with this issue. Not sure what will be the best solution or maybe a proper workaround. The alternative proposed by @aothms might be such workaround without touching the schema. Just have to be agreed and documented.

(One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType.)

[TLiebich]

as an additional thought - about 95% of all IFC file running around in the moment in industry are IFC2x3 files (whether we like it or not), so without a solutiion here and now for IDS 1.0 it will be rather useless for checking MEP models in the moment.

[CBenghi]

We cannot change IFC2x3 and somehow have to deal with this issue. Not sure what will be the best solution or maybe a proper workaround. The alternative proposed by @aothms might be such workaround without touching the schema. Just have to be agreed and documented.

(One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType.)

I truly dislike this idea.

When we started to develop IDS we tried to define information requirements remaining relatively IFC agnostic, but we have recently moved in closer alignment to the schema.
Injecting mapping behaviours to make an IDS work for multiple schemas seems like something that will complicate implementation a lot.

The way I see it, we are doing all this to make it simple to write code elsewhere in the supply chain to go and get the information in a robust way; if we inject custom behaviours by type this will impact the entire industry when they go and search for this information in models, as they will have to replicate our maps.

I think this is would not be beneficial to the industry.

[MatthiasWeise]

I guess there are two sides of the coin here, make it easy for (1) users = IFC agnostic or (2) software implementation = closer to the IFC schema. I was orginally thinking about a new attribute typeObject (more towards 2).
@CBenghi What are you proposing?

[berlotti]

There seem to be two sides of the coin, but I see a different coin.
1- create a standard that is symmetric, predictable and therefore easy to implement
2- create a thing that hangs together from exceptions just to support some kind of use-case
I opt for option 1. That choice has consequences. We need to accept the consequences.

We had a seperation between Typeobjects and instances (and where to put property sets) in a previous version of IDS (version 0.5 had it for example). That has been removed by group consensus to keep IDS predictable. I remember there were too many unclarities and questions about how the overruling of IFC would work when defining these things in IDS.
The reasoning back then was to use the rules of IFC when it comes to typing.

For the example of IfcAirTerminalType and IfcFlowTerminal it would mean that requiring one would mean the requirement is according to the IFC schema.
Good documentation and some examples of this would be needed indeed.

[aothms]

The coin I see here is:

• Implicit solution (supplementary lookup table that nobody likes)
• Explicit solution (new attribute solely for a very specific case, also not desirable).

I say for devs it's roughly the same, just a bit more work. We'll have comprehensive test cases in both options, so I don't see a big disadvantage or advantage in both solution directions. It's more a conceptual question for me.

But great work on noticing this issue @MatthiasWeise

It's annoying that ifc2x3 has these exceptions and I don't think there is a particular clean solution possible in IDS. But for me, the implicit solution at least keeps the IDS schema itself a bit cleaner. Knowing that 2x3 is a 15 year old version, when 2x3 is finally obsolete, we can remove the lookup table from the documentation, but the attribute cannot be removed in a backwards compatible fashion.

[Moult]

If anybody is after a computer map of 2X3 elements to types I produced this after coming across the same problem in IFC2X3: https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/util/entity_to_type_map_2x3.json

[aothms]

@Moult

This is a fundamental problem in IFC, not in IDS, I believe. IFC2X3 did not have the EXPRESS rules that restricted the class-pairs to be used for types and occurrences. I'm not sure it's up to IDS to make up for this shortcoming.

I think the issue is a different one. It's not about enforcing relationship between Object and TypeObject, but rather the ability to select an IfcAirTerminal Object which only exists as a IfcFlowTerminal - IfcAirTerminalType pair in 2x3.

[Moult]

Oh right I see, that's a bit of a weird requirement then. What's the original requirement in plain English?

[MatthiasWeise]

I really wonder about this discussion, in particular about this statement:

It's annoying that ifc2x3 has these exceptions and I don't think there is a particular clean solution possible in IDS. But for me, the implicit solution at least keeps the IDS schema itself a bit cleaner. Knowing that 2x3 is a 15 year old version, when 2x3 is finally obsolete, we can remove the lookup table from the documentation, but the attribute cannot be removed in a backwards compatible fashion.

I wonder, because you (Léon, Thomas, ..) are proposing exactly this for IFC5 as an improvement!
Citation from your publication (if I remember well it was ECPPM): "Future of the Industry Foundation Classes: towards IFC 5"

We propose to make the element type mandatory, such that the specialization of IfcElement is no longer necessary. A door will become an IfcElement of an IfcDoorType. As a result, more than hundred entities can be removed from the schema.

[aothms]

If it's done consistently it's not an exception anymore.

I think there's two things here for IFC5 we need to remember. Exceptions are painful. That's what we're seeing in this thread. But also, laborious modelling efforts (the complete replication of occurrence and type trees) will make people desperate enough to come up with exceptions (we had a similar discussion in 4.3 with the selects of predefined types, which in the end was rewritten to the more laborious explicit entity types equivalent buildingSMART/IFC4.3.x-development#90).

We'll have to see how well this IFC5 paper ages, but combined with the latebinding (built element type as string) and pset'ification (favouring psets over direct built element attributes) already happening since IFC4, I don't think this is particular statement is very contentious.

Let's go back on topic.