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 https://github.com/buildingSMART/IFC4.3.x-development/issues/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.

[MatthiasWeise]

I don't see a big difference between the IFC5 proposal and IFC2x3. It is maybe more consistent, but actually leading to the same technical problem:

How to specify a check for occurrences of IfcAirTerminalType?

• Can we use IfcAirTerminal even if such entity does not exist in the schema (look-up table solution)?

• Or shall we use IfcAirTerminalType limiting the scope of IDS to check of occurrences (or how to differentate from checking the type object instead of occurrence if type object checks should be in scope of IDS)?

Possible solutions are more less on the table, we just have to make a decision!

1. Lookup table being maybe more easy for IDS creators (and to some extend allows to be IFC agnostic as supported by IDS). Disadvantabe is to split IDS specification into several documents (although having it already with our unit/measurement table).

2. Make suggested changes to the IDS schema and be more close to the IFC schema (release). I guess this is the preferred solution for model checking implementations.

[TLiebich]

good summary by @aothms and @MatthiasWeise

please decide whether solution 1 or 2 should be chosen, personally I would opt for solution 2 - add "typedBy" which gets $entityName . "Type" as default value but can be overriden by the explicit type as in case of IFC2x3 MEP classes. But also the lookup table seems fine for me.

Not addressing the issue, meanwhile well explained, introduces the risk, that IDS 1.0 is of far less practical value to satisfy todays ifc2x3 validation needs in construction projects.

[Moult]

I'm still struggling to see what the practical information requirement is. It sounds a bit academic so far.

[TLiebich]

here the user story:

The user would like to validate the required properties associated to an air terminal and a socket. Both requirements are different (different required properties exists for air terminal and an outlet). Therefore in IDS the applicable IFC class needs to be addressed.

In IFC4 there is a (mainly) 1 to 1 synchronization of IFC occurrence and IFC type classes - here IfcAirTerminal > IfcAirTerminalType, IfcOutlet > IfcOutletType - plus the WHERE rules to ensure a consistent instantiation. Selecting IfcAirTerminal or IfcOutlet supports the validation of different required properties.

In IFC2x3 within the sub tree of IfcDistrubutionElement this synchronization does not exists. here IfcFlowTerminal > IfcAirTerminalType, IfcFlowTerminal > IfcOutletType. If IDS only allows to select the IFC occurrence class - here IfcFlowTerminal, how to validate that the air terminal requires other properties as the outlet?

does this makes the issue clear?

[Moult]

Yes that makes sense. To a small degree specifying the predefined type (which is inherited) may help. Thanks for clarifying :)

[TLiebich]

unfortunately not - in IFC2x3 MEP elements, the predefinedType was only defined for the types, the occurrence class IfcFlowElement has no way to express the predefined type.

[Moult]

@TLiebich yes but in IFC the rule is that the predefined type is "inherited" from the type.

[TLiebich]

@Moult - correct (I might have written this rule in the past ;-))

my point was, that if in IDS 1.0 we cannot address the type, if it is different to $entityName . "Type", then we can also not use the predefined type inherited from the type object.

[MatthiasWeise]

@Moult Relying on PredefinedType could indeed help to some degree, but not in all cases and most likely less efficient.

Possible scenario from my point of view:

• use entity name of the occurrence or may even leave it empty (entity facet seems to be optional in IDS for applicability, right?)
• define PredefineType, which seems to be mandatory in IFC for all instantiable IfcTypeObjects: -> This enables to find the proper IfcTypeObject unless it is USERDEFINED or NOTDEFINED (also assuming that enumeration values are unique across different enums).
• in case of USERDEFINED: -> use attribute facet for checking ObjectType attribute
• in case of NOTDEFINED: -> edge case without solution

There is another important "edge case" without solution: If users do not care about PredefinedType and thus leave it empty on purpose (i.e. define requirements for all options).

[aothms]

Let's try and wrap this up.

With IDS we chose on purpose some level of abstraction over IFC classes directly. We have material targetting all subtypes of material definition. We have property targeting a variety properties and quantities. The abstraction over direct usage of IFC classes causes a need for increased clarity in docs and test cases, resulting in ease of use for end-users and improved compatibility between IFC releases.

If we take that as a starting point, to me, solving this issue in documentation (extra lookup table, to convert IfcAirTerminal to IfcFlowTerminal+IfcAirTerminalType) is most in line with these guiding principles. Adding an attribute for something that is in day to day usage already constrained in the schema is a recipe for error and confusion.

If we decide against supplementary table, I prefer to leave this as a limitation of IDS+IFC2X3. I.e that end-users will either have to specify constraints on the more general IfcFlowTerminal or require them on the IfcAirTerminalType or upgrade to IFC4.

[Moult]

I'm fine with either solution. I have a small personal bias to encourage people to upgrade to IFC4. IFC2X3 is ancient. Get a move on, or this will hurt IFC in the long term as it will get a reputation for being decades out of date.

[TLiebich]

I opt for an extra lookup table and the ability to create an IDS file for IFC2x3 with IfcAirTerminal.

PS: while I would be more then happy when the industry moves faster to IFC4, I think it is the wrong approach to push it via an in scope of IFC2x3 incomplete IDS specification in scope of IFC2x3.

[MatthiasWeise]

@CBenghi If we agree on a lookup table (i.e. enable to use IFCAIRTERMINAL in IFC2x3), the checking tool must be extended to include those IfcXxx[Type] entities as well.

[andyward]

Agreed, feels like the audit tool should warn when using an entity type this is 'inferable' this way. At the moment this IDS will throw an error in the Audit tool, but meets the proposal to handle via a mapping table

<ids xmlns="http://standards.buildingsmart.org/IDS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://standards.buildingsmart.org/IDS/ids_05.xsd">
    <info>
        <title>Pass-IFC2x3 doesn't have AirTerminal instance, but does have AirTerminalType which can be used to infer instance</title>
    </info>
    <specifications>
        <specification name="IFC2x3 doesn't have AirTerminal instance, but does have AirTerminalType which can be used to infer instance" ifcVersion="IFC2X3" minOccurs="1" maxOccurs="unbounded">
            <applicability>
                <entity>
                    <name>
                        <simpleValue>IFCAIRTERMINAL</simpleValue>
                    </name>
                </entity>
            </applicability>
            <requirements>
                <entity>
                    <name>
                        <simpleValue>IFCFLOWTERMINAL</simpleValue>
                    </name>
                    <predefinedType>
                        <simpleValue>GRILLE</simpleValue>
                    </predefinedType>
                </entity>
            </requirements>
        </specification>
    </specifications>
</ids>

Test IFC for reference

ISO-10303-21;
HEADER;
FILE_DESCRIPTION (('ViewDefinition [CoordinationView]'), '2;1');
FILE_NAME ('pass-ifc2x3-air_terminal_edge_case.ifc', '2023-05-03T18:17:26', ('AW'), ('xbim Ltd'), 'xbim Toolkit', 'xbim IDS Unit tests', 'n/a');
FILE_SCHEMA (('IFC2X3'));
ENDSEC;
DATA;
#1=IFCAIRTERMINALTYPE($,$,'AirTerminalType',$,$,$,$,$,$,.GRILLE.);
#2=IFCFLOWTERMINAL($,$,'AirTerminal',$,$,$,$,$);
#3=IFCRELDEFINESBYTYPE($,$,$,$,(#2),#1);
ENDSEC;
END-ISO-10303-21;

This does raise a question about "forward mapping" of types from newer schemas to older ones where the type did not exist - and how the audit tools should treat these. I see a few categories of this:

1. New entities that may be inferable in old schemas via a Type relationship. i.e. the topic being discussed IFCAIRTERMINAL, IFCELECTRICAPPLIANCE, IFCBOILER etc

2. New entities which replaced an obsolete item in an older schema IFCDOORSTYLE => IFCDOORTYPE, IFCBUILDINGELEMENT=>IFCBUILTELEMENT

Should a user be able to use the newer DoorType in IFC2x3, or a DoorStyle in IFC4.3? Obviously they could split the specifications by IfcVersion as a work around?

3. New entities with no obvious map in a older schema (except for an super type) IFCROAD, IFCKERB, IFCTRACKELEMENT etc

I don't see a way for these to be handled. They are exclusive to the newer schema.

When thinking about the auding, I'd propose 1) is a warning and 2) & 3) probably errors unless we have some implementors agreements?

[MatthiasWeise]

@andyward I am not sure if I understand the "forward mapping" proposal: in each specification we have the ifcVersion attribute allowing to specify the IFC version(s) to which the requirement rules apply. So, I am not sure if we need an agreement for mapping between IFC versions.

For the lookup table for IFC2x3: For missing occurrence entities I was actually thinking about a simple rule: check if either the given entity name or entity name + TYPE exists in the specified schema (IFCAIRTERMINAL or IFCAIRTERMINALTYPE). If yes, the IDS file is valid. Then we do not need a fixed lookup table. If I am not wrong we do not need to take care about STYLE, because occurrence entities for IfcWindow(Style) and IfcDoor(Style) exists in IFC2x3 (the issue is only with HVAC entities).