do we need to enumerate all applicableUnit?

[VladimirAlexiev]

Do we need to enumerate all applicableUnit, or are they "inherited" from the parent QuantityKind?

• I had the same question to Artur@bSI re BSDD property definitions,
• now I asked QUDT: https://github.com/qudt/qudt-public-repo/issues/720. It seems no inheritance happens in QUDT, so we do need

https://github.com/Accord-Project/aec3po/blob/5fb6f7e2b8b9f0f208caeeab68461aa8b3c0dfcd/src/quantity_kinds.ttl#L52-L57

[beachtom]

I know Passi made the point that the ontology should assume SI unit and it is the responsibility of UI to translate to/from that unit.

[VladimirAlexiev]

For the Ramp example, I looked up the relevant IFC property: https://github.com/Accord-Project/bcrl/blob/62a0b32fcc13d3b0839f44f940078aaca9bcc2b9/FI-accessibility.yaml#L279-L284

- $id: quantity/FI/accessibility/ramp/gradient
  ifcProperty: ifc:requiredSlope_IfcRamp # not sure about name
  rdfs:range: ifc:IfcPlaneAngleMeasure

That's measured in radian in IFC, so when comparing we have to use that unit:

            - $id: regulation/FI/accessibility/2.2.3.4.2
              $type: Clause
              clauseType: regulation/clauseType/Phrase
              identifier: 2.2.3.4.2
              text: the ramp may have a gradient of more than five per cent only if 
              quantity: quantity/FI/accessibility/ramp/gradient
              comparison: comparison/GT
              value: 0.049958 # radians = 5% = 2.86 degrees
              unit: radian # needs to be mapped to QUDT

But even if we limit to SI, a property will have a choice of apllicableUnit, eg m, cm, mm.

[beachtom]

Agree we should have choice - but my view is the choice should be based on what the regulation says, and it is a processing engine's job to translate that to what is in the IFC

[VladimirAlexiev]

Agreed, we should be true to the regulation text. Ok, so you mean something like this:

- $id: quantity/FI/accessibility/ramp/gradient
  ifcProperty: ifc:requiredSlope_IfcRamp # not sure about name
  rdfs:range: ifc:IfcPlaneAngleMeasure
  unit: unit:RAD # from QUDT

- $id: regulation/FI/accessibility/2.2.3.4.2
  quantity: quantity/FI/accessibility/ramp/gradient
  comparison: comparison/GT
  value: 5
  unit: unit:GR # from QUDT "Grade: the tangent of an angle of inclination multiplied by 100"

Then the engine needs to:

• figure out that RAD and GR are compatible (how? they're quantitykind:Angle vs quantitykind:DimensionlessRatio)
• figure out how to convert (in this case qudt:conversionMultiplier doesn't apply because you need some trigonometry)

[VladimirAlexiev]

The original question has been answered: https://github.com/qudt/qudt-public-repo/issues/720 and https://github.com/qudt/qudt-public-repo/wiki/Advanced-User-Guide#4-computing-applicable-units-for-a-quantitykind. So @maximelefrancois86:

• we don't need to enumerate all qudt:hasQuantityKind: if a QuantityKind doesn't have such, they are inherited from its parent
• then qudt:applicableUnit are calculated as inverse of qudt:hasQuantityKind, taking into account the above point

I think we should describe this in prop documentation. I've suggested some edits in https://github.com/qudt/qudt-public-repo/issues/720

[maximelefrancois86]

aec3po:ModularRoomHeight and aec3po:WidthOfAngledCorridor only list a small set of S.I. applicable units. this restricts the set of units from quantitykind:Length.

However currently aec3po:CompressiveForce just defines the same set of applicable units as the broader quantitykind:Force, so it may be omitted.

solved in commit 96d0f6f

Am I right to assume the DimensionVector of a quantity kind should also be computable from the broader quantity kind ?

[VladimirAlexiev]

The dimension vector should be the same, yes

[maximelefrancois86]

So can we avoid expliciting this metadata ?