Testcase "[FAIL] Subclasses are not considered as matching"

[hesrah]

[FAIL] Subclasses are not considered as matching We still have a open discussion in SLACK about this testcase or more generally about inheritance in IFC.

I still believe IDS should support IFC/EXPRESS inheritance model and this testcase should be PASS. Why shouldn't IDS support IFC inheritance?

[Moult]

Yeah this is a debatable one. I'm personally in support of inheritance.

The logic I've heard against it is that if you ask for "IFCELEMENT" and someone who doesn't know IFC might say "My model has IfcWalls, not IfcElements". Therefore it makes it clearer to explicitly say "IFCWALL, IFCSLAB, IFCDOOR, IFCWINDOW, IFC...insert the 50 other classes here"

I personally don't agree with this logic, but there it is.

[hesrah]

Hm, this argumentation - I know it's not yours @Moult - is exactly what I called "CAD/drawing perspective" in SLACK. I reject this. The model of someone who doesn't know IFC has IfcElement, whether he/she sees it is irrelevant. "Ignorance does not protect against punishment." ;-)

Which entities do we see and which do we not? Those that the authoring tool has features for? What are the criteria? Where do we draw the line?

[Moult]

I agree. In my opinion there are implicit understandings about IFC baked into IDS and the whole concept of OpenBIM. Like the concept of inheritance, material sets, multiple classification systems, classifications being different from properties, properties being different from attributes, attributes needing to be valid from the schema ...

My biggest personal practical gripe is that very often I do want to specify tests to IfcElement or IfcElementType, or IfcSpatialElement. Inheritance makes that easy, without inheritance means I need to copy paste a list of 50 objects that I reckon occlude the intention of the specification.

[CBenghi]

I agree that inheritance should be fully dealt with by the IDS specification. It might take some careful consideration for us to define clearly what IDS expects in each scenario, but avoiding to do so, seems like a significant rejection of a fundamental concept at the base of IFC.

Over the months IDS has morphed from a specification that tried remain on construction abstraction levels to something that is much more coupled with IFC concepts (e.g. see the changes in the partOf facet with the introduction of the explicit IFC relation).

Ignoring inheritance was perhaps ok in the first paradigm, but I think it's a miscalculation at this stage.

[TLiebich]

• 1 from my side, IDS is now based on IFC structure in so many aspects (also occurrence/type, override by occurrence, bounded/list/table values, material, etc.) so that it seems wrong to not also use IFC inheritance.

(lets leave it to EN ISO 7817 (former EN 17412) to handle the IFC specification independent defintion of LOIN for verification purposes)

[berlotti]

This is an ongoing/returning debate. It can be argued both ways.

As @Moult concluded, the use-cases that require this are minimal, while the risk of invalid behaviour in implementations grows exponentially. The project made the decision in the beginning to not support it and that still seems the correct decision.

We can always reevaluate after 1.0