Revert IfcCountMeasure to number and introduce a new IfcIntegerCountMeasure instead

[SergejMuhic]

Definition is wrong. Should be 'NUMBER'.

[peterrdf]

Used to be correct, not sure why it was reduced into INTEGER. I agree, should be NUMBER like it used to be.

[pjanck]

Related: #167

[SergejMuhic]

Sorry, but I do not see a requirement in @czapplitec saying "we do not use it".

There is IfcInteger as well as IfcIntegerCountRateMeasure available. I do not see any solid reasoning in that thread other than some feelings.

[Moult]

@SergejMuhic there is a solid reason that IfcQuantityCount is used in cost items for the costing discipline, and their domain requirement requires that counts are always integers. Allowing numbers would be incorrect from a costing perspective.

I think @aothms had a reason of improving interoperability between props and quants, but he is the best person to elaborate on that.

[aothms]

Guys, this was discussed a year ago and after consensus with the people involved has been proposed and accepted as a schema change in the reviewing process by the people involved in the iso ratification.

Sorry, but I do not see a requirement in @czapplitec saying "we do not use it".

It is not about who is using what, the aim should be to work towards an internally consistent standard: we have count-related properties and a data type for measuring counts, but were not using it because its underlying type being too flexible. This is one of those many cases where we're very clearly violating the principle of least astonishment.

What is your reasoning to come to the conclusion this is "wrong"?

[SergejMuhic]

First of all, I do not think I have to explain quotations/references. We are all adults here. We also all know that the standard is not standalone, it is built on standards that are built on standards.

A couple of things to unpack here though:

1. Two people participating in a Github thread is not where schema changes take place. There is a process and it should be followed. For any schema change in the Infraroom there were huge projects setup that followed the bSI process with all the phases (requirements analysis, development, deployment all accompanied by expert panels).
2. I completely agree, we need a consistent and stable standard. In order to do that, a lot of existing work has been incorporated. IfcCountMeasure is directly transferred from ISO 10303-41 that takes its quantity definitions from ISO 31. Unless we want to fix the reference to "I just checked with a professional cost planner - 3011902-83" instead of "ISO 10303-41" (I hope you are not considering this! 😄 ) I stick to my statement that the data type is wrong.
3. If anyone wants to restrict measures (looking at @Moult ), please do so but use the mechanisms in the standard that have been designed for it. The IFC specification is and has been one of the more flexible standards around with mechanisms in place to extend, restrict and focus it.
4. If I want to count money, why would I want an INTEGER? If I want to count hours, years, again same issue.
5. Even in the standard, you have properties NaturalVentilationRate or quantities NetSurfaceArea which I see as not being integers.

[aothms]

Maybe this is going to be somewhat reassuring, we have a lot of dedicated measures for these already:

If I want to count money

IfcMonetaryMeasure (is a real - but actually in software you would never use floating point math, but a scaled integer approach)

If I want to count hours, years, again same issue.

IfcTimeMeasure / IfcDuration

NetSurfaceArea

IfcQuantityArea

NaturalVentilationRate

You have a point there, but in my view that should never have been a count measure, that has dimensional exponents (0,0,-1,0,0,0,0), it's number / hour after all. We need a dedicated measure for that if it doesn't exist yet. Somewhat ironically we only seem to have IfcIntegerCountRateMeasure (which is an... integer 😄) or you use the IfcVolumetricFlowRateMeasure but it's a different property.

[SergejMuhic]

You made my point though. If you want to count integers, by all means IfcCountMeasure does it since it is a generalization. If you want something more specific, you have others. There are enough options. Focusing on one and changing it based on personal opinions is a bit erratic. IfcCountMeasure is a generic count that can be used for anything.

I did not want to go through all the possible measures one by one. I just wanted to convey the notion of what one might want to do. Another example, significant digits; I might just want to count in millions and have one decimal space for hundred thousand. Or from the schema IfcReinforcementBarProperties.BarCount. Sure we can go down a rabbit hole again whether it should have decimal place or not but I can definitely think of a scenario where it would be plausible. Since the specification has options of restricting concepts, I do not see a point in changing a properly defined and referenced one.

What you have missed in my post is the statement that we are referencing another standard with it. Unless you want to go and change it there, you should not take the right to do it here. If absolutely necessary which I do not see in this case, introduce a new measure? Changing this existing one is just wrong in any perspective.

[aothms]

Ok, but now we do indeed get to the two core underlying difference in understanding.

1.

Since the specification has options of restricting concepts, I do not see a point in changing a properly defined and referenced one.

I think it's near-universally accepted now that (while flexibility helped earlier in reaching consensus) it is now time to consolidate the fragmented usage of IFC to a more compatible and interoperable (and hence more constrained) core set of definitions. If you don't agree with that aim I think it has to be discussed elsewhere. We can't keep dancing around this in every individual issue.

If you want to count integers

I hate to be citing Wikipedia here, but the first sentence on counting is:

Counting is the process of determining the number of elements of a finite set of objects

https://en.wikipedia.org/wiki/Counting

It's not a matter of if you count in integers. The area of a wall is not a finite set so measuring the area of a wall is not an act of counting, it's an act of measuring.

The only few cases I can imagine where non-integer 'counts' make sense are when a division is applied (and you get a different measure or ratio), such as:

• the ventilation rate where a count is divided by a time measure, so $n⋅t^{-1}$ or
• in statistics, where I'm supposed to have 1.8 children on average.

we are referencing another standard with it

We have made adaptations to concepts bothered from other standards as well, I'm not saying it's not a thing to consider, but it's clearly not a universal decisive factor in all cases. I could have lived with an integer_count_measure assigned to all properties where it makes sense. Not my preference though (again, standardization is sometimes about making choices).

[SergejMuhic]

1. It is? Where is that stated. Apparently it is not universally accepted as clearly you have more diverging than agreeing opinions in this thread vs the one where you made the decision to change it. I am sorry that I do not see a "Needs identification", "Solution creation" and "Deployment" (see bSI process) phases in a Github issue where there were two active participants and one who had no opinion. If you are the authority on such matters now, I would love to see a bSI official statement, otherwise, I will keep raising these kinds of questions / pointing out wrong definitions when I encounter an issue.
2. Right, I read that before posting as a matter of fact and I cannot see where it does not confirm what I have said. There are many other sources talking about counting in a bit more detail (Wiki just says by twos or by fives but clearly it is possible also after the decimal point) i. e. act of measuring and I cannot see a restriction to integer counts anywhere e. g. https://chem.libretexts.org/Courses/University_of_Kentucky/UK%3A_General_Chemistry/01%3A_Essential_Ideas/1.5%3A_Measurement_Uncertainty_Accuracy_and_Precision. It is merely a matter of significant digits (as stated in my previous post) which are not bound to a whole number notation. 2.7 barrels of crude, 83.2 million of people etc. Why are we even still discussing this? I do not think we will reach consensus here and it is also not important that we do. We can keep throwing around sources but apparently I see the act of counting on the basis of significant digits and you do not. I propose we do not go down this rabbit hole.
3. Again, just make a new one. Changing a definition that is referencing an existing definition makes no sense because you would have to go to the other standards that defined it or cut the cord to the base definition. It does not hurt anyone if the existing one is there and a more restricted one IfcIntegerWhateverMeasure can do exactly what you want it to. I think here it is much easier to reach consensus. Let's focus on this point?