Properties and quantities not differentiated

[SergejMuhic]

These are different definitions / entities and cannot be referenced in both an IfcPropertySet and IfcElementQuantity. The spec should take that into account:

[berlotti]

In IFC 4.3 the properties are normalized. In your example the property 'length' is the same in every Pset. Properties have unique names throughout the full spec of IFC.

[SergejMuhic]

We are not talking about the same thing. In quantity sets, there are: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcPhysicalSimpleQuantity.htm

In property sets: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcSimpleProperty.htm

These are two different types that do are not part of the same inheritance branch. I suggest re-opening the issue.

[berlotti]

Ah; I see your point now. Indeed this needs to be clarified.

[aothms]

This is a valid point for discussion, but I think the conclusion is premature:

cannot be referenced in both an IfcPropertySet and IfcElementQuantity

In my view the distinction between properties and quantities does not need to be maintained in newer versions of the spec. We already don't handle them differently in newer bsi specs such as bsdd or ids.

In current releases there is no clear rationale on whether something constitutes a property or quantity. It seems to be either legacy or personal opinion.

The concept of what constitutes e.g length to me does not change whether it's part of a quantity set or property set. But specific measuring instructions can be added as part of the "usage" of a property as part of the quantity or property set.

These three points considered I would opt to keep the unified definitions the same across props and quants.

[SergejMuhic]

These two definitions are treated completely differently in software. Where props can be manually edited, quants cannot and are automatically generated. I think this kind of a distinction (at this point in time) is good to have but this is another discussion.

IMHO (for the future), quants should be removed from the schema and replaced by geometry validation. This would be more future proof. Quants feature the Formula attribute where local authorities could have their specs on how e. g. Length should be calculated. But this kind of an approach is a bit outdated. A Length is a Length.

But specific measuring instructions can be added as part of the "usage" of a property as part of the quantity or property set.

Just yes. This way (and geometry validation) there should be no distinction. A bit problematic for things such as windows, but we are talking about standardising, so I see a good base for an international approach related to software implementations. Makes it much easier and still leaves room for local implementations because the international validation would supply a common geometry interpretation.

[Moult]

Just a reminder that quantities currently have special status in the costing, scheduling, and resource management aspects of IFC. E.g. this parametric cost item relationship: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcCostItem.htm#Figure-6.5.3.2.A-Cost-assignment

[SergejMuhic]

Just a reminder that quantities currently have special status in the costing, scheduling, and resource management aspects of IFC. E.g. this parametric cost item relationship: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcCostItem.htm#Figure-6.5.3.2.A-Cost-assignment

Right, two discussion, what currently is, what should be.