Suggestion to add units and quantitykinds from IFC

[fkleedorfer]

I am working on an alignment between QUDT and IFC, a schema for building information modelling. The purpose is to define different 'standards' for building models (think: CompanyA's standard and CompanyB's standard), and to translate models from one standard to the other. Here is an Overview of units/measurements in IFC

I can map most of the IFC 'Measures' directly to QUDT QuantityKinds, but not all.

Here are the problematic ones (using the IfcDerivedUnitEnum enum; each has a corresponding Measure, such as IfcIsothermalMoistureCapacityMeasure):

• IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: qk:SpecificVolume is a more general QK that should fit
• IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: qk:VolumeFlowRate might be ok
• IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: qk:ThermalConductivity might fit
• IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: qk:ThermalConductance might fit
• IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: not in QUDT, no replacement found, and no unit either. Maybe https://en.wikipedia.org/wiki/Perm_(unit)?
• IfcDerivedUnitEnum.LINEARFORCEUNIT: QUDT has qk:Force - the restriction to linear is not in QUDT.
• IfcDerivedUnitEnum.PLANARFORCEUNIT: QUDT has qk:Force - the restriction to planar is not in QUDT.
• IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: qk:ForcePerLength might be ok, I am unsure though.
• IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: not in QUDT, and the common unit, N-PER-M3 has no QuantityKind. There is a Quantitykind with the same dimension vector, SpectralRadiantEnergyDensity, but that seems far off
• IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: QUDT has qk:ForcePerArea that might be ok, based on the unit, N-PER-M2
• IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: not in QUDT, qk:ForcePerAngle might be ok, based on the unit, N-PER-RAD
• IfcDerivedUnitEnum.HEATINGVALUEUNIT: qk:SpecificEnergy could fit
• IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: not in QUDT. qk:IonDensity is a close match, but it may not be ok, as in IFC, it is associated with count per volume, but the derivation for ionconcentrationunit is g/l.
• IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: not in QUDT. The derivation, cd / lm does not exist as a unit in QUDT
• IfcDerivedUnitEnum.PHUNIT: not in QUDT as a QuantityKind, but there is unit:PH (no quantity kind)
• IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: not in QUDT, and not sure what it is. The unit, m^5 is not in QUDT
• IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: not in QUDT, but the unit, K/m is
• IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: not in QUDT, nor is the unit, M^6
• IfcDerivedUnitEnum.WARPINGMOMENTUNIT: not in QUDT, but NM^2 is

I would like to achieve bijective mappings between QUDT QuantityKinds and IFC Measures(UnitTypes)
Thus,

• mapping multiple IFC measures to qk:Force is a problem for me
• having no mapping for an IFC measure (such as the warping measures) is a problem, too.

Adding the missing units/quantitykinds would fix the problem for me, so I suggest to provide a PR with the following additions:

• IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: add qk:IsothermalMoustureCapacity skos:broader qk:SpecificVolume
• IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: add qk:MoistureDiffusivity skos:broader qk:VolumeFlowRate
• IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: add qk:ThermalAdmittance skos:broader qk:ThermalConductivity
• IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: add qk:TermalTransmittance skos:broader qk:ThermalConductance
• IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: add the different https://en.wikipedia.org/wiki/Perm_(unit) units and qk:VaporPermeability (not sure of a more general concept to link to/from), and associate them
• IfcDerivedUnitEnum.LINEARFORCEUNIT: add qk:LinearForce skos:broader qk:Force
• IfcDerivedUnitEnum.PLANARFORCEUNIT: add qk:PlanarForce skos:broader qk:Force
• IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: add qk:LinearStiffness skos:broader qk:ForcePerLength
• IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: add qk:ModulusOfSubgradeReaction, link to and use qkdv of N-PER-M3
• IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: add qk:ModulusOfLinearSubgradeReaction skos:broader qk:ForcePerArea
• IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: add qk:ModulusOfRotationalSubgradeReaction skos:broader qk:ForcePerAngle
• IfcDerivedUnitEnum.HEATINGVALUEUNIT: add qk:HeatingValue skos:broader qk:SpecificEnergy
• IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: do nothing (I'll use qk:IonDensity)
• IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: Not sure what that is, but I would still add unit:CD-PER-LM and qk:LuminousIntensityDistribution and associate them
• IfcDerivedUnitEnum.PHUNIT: add qk:Acidity, associate with unit:PH
• IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: and not sure what it is, but I would add unit:M5 and qk:SectionAreaIntegral and associate them
• IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: add qk:TemperatureGradient, associate with unit:K-PER-M
• IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: add qk:WarpingConstant and unit:M6, and associate them
• IfcDerivedUnitEnum.WARPINGMOMENTUNIT: add qk:WarpingMoment and unit:N-M2 and associate them

I am grateful for any corrections or suggestions for the problems listed above.

If there is interest, I could also contribute a mapping from QUDT units to IFC units, and from QUDT quantitykinds to IFC unit types/measures.

[steveraysteveray]

@fkleedorfer, I really like what you are proposing, and look forward to your PR. A few items to keep in mind:

1. We enforce the rule that quantity kinds that are related via skos:broader must either:
   a. Have the same dimension vector, or
   b. The broader one has no dimension vector (for example, Viscosity is broader than both DynamicViscosity and MolecularViscosity, and (eventually) KinematicViscosity, which have different dimension vectors). Lack of a dimension vector is an indication that the subject quantity kind is an abstract concept.
2. I know you know this, but remember that you should only manually populate the hasQuantityKind relation between a Unit and a QuantityKind, and let our algorithm populate the applicableUnit relation going back the other way.
3. I suggest using the relation qudt:ifcCode for the QUDT-to-IFC mappings (which will need to be defined in the schema files (OWL and SHACL). I can take care of that if you are unsure.
4. We are still discussing how best to characterize nonlinear units and quantity kinds, but there are some already in QUDT. At present, they have no conversionmultiplier.

That's all I can think of right now. Thanks for doing this!

[fkleedorfer]

We are still discussing how best to characterize nonlinear units and quantity kinds, but there are some already in QUDT. At present, they have no conversionmultiplier.

This comment is about the PH unit/qk - or do you see others?

[steveraysteveray]

Indeed, PH is what I was thinking of.

[fkleedorfer]

3. I suggest using the relation qudt:ifcCode for the QUDT-to-IFC mappings (which will need to be defined in the schema files (OWL and SHACL). I can take care of that if you are unsure.

IFC is not so easy to reference:

• SI Base Unit names are defined in an enum, IfcSIUnitName, e.g. IfcSIUnitName.AMPERE
• SI Base units also have a unit type (=quantity kind) from another enum, IfcUnitEnum, e.g. IfcUnitEnum.ELECTRICCURRENTUNIT
• Derived Units do not (necessarily) have a name, but they always have a unit type (=quantity kind) - from a different enum IfcDerivedUnitEnum, e.g. IfcDerivedUnitEnum.AREADENSITYUNIT
• So-Called conversion based unitsIfcConversionBasedUnit are defined using SI units and conversion multiplier / offset, and they get their 'measure' (quantity kind) from how they are derived from the SI unit. These units have recommended labels, such as INCH (see this example)
• IfcContextDependentUnit, which are separate from SI.

See also Section 3.3 of the IFC 2x3 implementation guide.

The question is: how do we link from QUDT to IFC?

• QuantityKinds always have one IFC unit type and corresponding measure that can be identified. However, depending on whether the quantity kind is basic or derived, the type lives in a different enum. The corresponding measure is always a distinct type, e.g. IfcElectricCurrentMeasure
• Basic SI Units in QUDT can link to a distinct enum, but all other units are anonymous complex structures (you can't link to them, you have to build them). It would be helpful for instantiating an IFC unit for a given QUDT unit to know which of the IFC unit systems (basic SI, derived SI, conversion based, or context dependent) it belongs to... and I believe that QUDT contains all the information we need for that. However, making this explicit would make the mapping more tractable (ie easier to replicate for independent developers).

So, to wrap this up, the easiest would be to have the following properties for QuantityKind:

• qudt:ifcUnitEnumValue if the quantity kind is non- derived. e.g qk:ElectricCharge qudt:ifcUnitEnum "ELECTRICCHARGEUNIT" .
• qudt:ifcDerivedUnitEnumValue if the quantitykind is derived, e.g.qk:MassDensity qudt:ifcDerivedUnitEnumValue "MASSDENSITYUNIT" .,

for Unit:

• qudt:ifcSIUnitName if the unit is SI base, e.g. unit:M qudt:IfcSIUnitName "METRE" .
• qudt:ifcUnitClass (values "IfcSIUnit"|"IfcDerivedUnit"|"IfcConversionBasedUnit"|"IfcContextDependentUnit"), e.g., unit:FT qudt:ifcUnitClass "IfcConversionBasedUnit".

We could consider minting IRIs for these constants, otherwise strings are ok, too.

[jhodgesatmb]

The mapping I was referring to in the EPIC project is titled: SCHEMA_KP_IFC_2_QUDT-v1.0.ttl and is discussed in some detail in the EPIC final report.

…

On Tue, Nov 8, 2022 at 3:11 PM Jack Hodges ***@***.***> wrote: Steve and I worked on a CEC EPIC project together (with UC Berkeley) where we were constructing mappings between ontologies, and IFC was one of them. The problem here is that you cannot realistically integrate every single adhoc unit model with QUDT, especially if there are model conflicts. Rather, what you seek is a mapping ontology that maintains the autonomy and integrity of (in this case) IFC and BIM and QUDT but allows them to change and grow on their own with time. QUDT has committed to integrating with known unit standards, but when you get to a domain-generic or domain-specific model like IFC it makes more sense to create, share, and manage a mapping model. Steve and I published a paper with Computer (attached) outlining the mechanism of mapping standards, and in a paper I was part of writing for the IEC on semantic interoperability we talked about how standards bodies might take on the responsibility of managing model mappings of standards they own/manage (attached). On Tue, Nov 8, 2022 at 5:43 AM Florian Kleedorfer < ***@***.***> wrote: > I am working on an alignment between QUDT and IFC, a schema for building > information modelling. The purpose is to define different 'standards' for > building models (think: CompanyA's standard and CompanyB's standard), and > to translate models from one standard to the other. Here is an Overview > <https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/link/ifcmeasureresource.htm> > of units/measurements in IFC > > I can map most of the IFC 'Measures' directly to QUDT QuantityKinds, but > not all. > > Here are the problematic ones (using the IfcDerivedUnitEnum enum; each > has a corresponding Measure, such as IfcIsothermalMoistureCapacityMeasure > ): > > - IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: qk:SpecificVolume > is a more general QK that should fit > - IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: qk:VolumeFlowRate might > be ok > - IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: qk:ThermalConductivity > might fit > - IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: qk:ThermalConductance > might fit > - IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: not in QUDT, no > replacement found, and no unit either. Maybe > https://en.wikipedia.org/wiki/Perm_(unit)? > - IfcDerivedUnitEnum.LINEARFORCEUNIT: QUDT has qk:Force - the > restriction to linear is not in QUDT. > - IfcDerivedUnitEnum.PLANARFORCEUNIT: QUDT has qk:Force - the > restriction to planar is not in QUDT. > - IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: qk:ForcePerLength might be > ok, I am unsure though. > - IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: not in QUDT, and > the common unit, N-PER-M3 has no QuantityKind. There is a Quantitykind with > the same dimension vector, SpectralRadiantEnergyDensity, but that seems far > off > - IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: QUDT has > qk:ForcePerArea that might be ok, based on the unit, N-PER-M2 > - IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: not in > QUDT, qk:ForcePerAngle might be ok, based on the unit, N-PER-RAD > - IfcDerivedUnitEnum.HEATINGVALUEUNIT: qk:SpecificEnergy could fit > - IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: not in QUDT. qk:IonDensity > is a close match, but it may not be ok, as in IFC, it is associated with > count per volume, but the derivation for ionconcentrationunit is g/l. > - IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: not in QUDT. > The derivation, cd / lm does not exist as a unit in QUDT > - IfcDerivedUnitEnum.PHUNIT: not in QUDT as a QuantityKind, but there > is unit:PH (no quantity kind) > - IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: not in QUDT, and not > sure what it is. The unit, m^5 is not in QUDT > - IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: not in QUDT, but the > unit, K/m is > - IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: not in QUDT, nor is the > unit, M^6 > - IfcDerivedUnitEnum.WARPINGMOMENTUNIT: not in QUDT, but NM^2 is > > I would like to achieve bijective mappings between QUDT QuantityKinds and > IFC Measures(UnitTypes) > Thus, > > - mapping multiple IFC measures to qk:Force is a problem for me > - having no mapping for an IFC measure (such as the warping measures) > is a problem, too. > > Adding the missing units/quantitykinds would fix the problem for me, so I > suggest to provide a PR with the following additions: > > - IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: add > qk:IsothermalMoustureCapacity skos:broader qk:SpecificVolume > - IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: add > qk:MoistureDiffusivity skos:broader qk:VolumeFlowRate > - IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: add qk:ThermalAdmittance > skos:broader qk:ThermalConductivity > - IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: add > qk:TermalTransmittance skos:broader qk:ThermalConductance > - IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: add the different > https://en.wikipedia.org/wiki/Perm_(unit) units and > qk:VaporPermeability (not sure of a more general concept to link > to/from), and associate them > - IfcDerivedUnitEnum.LINEARFORCEUNIT: add qk:LinearForce skos:broader > qk:Force > - IfcDerivedUnitEnum.PLANARFORCEUNIT: add qk:PlanarForce skos:broader > qk:Force > - IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: add qk:LinearStiffness > skos:broader qk:ForcePerLength > - IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: add > qk:ModulusOfSubgradeReaction, link to and use qkdv of N-PER-M3 > - IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: add > qk:ModulusOfLinearSubgradeReaction skos:broader qk:ForcePerArea > - IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: add > qk:ModulusOfRotationalSubgradeReaction skos:broader qk:ForcePerAngle > - IfcDerivedUnitEnum.HEATINGVALUEUNIT: add qk:HeatingValue > skos:broader qk:SpecificEnergy > - IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: do nothing (I'll use > qk:IonDensity) > - IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: Not sure what > that is, but I would still add unit:CD-PER-LM and > qk:LuminousIntensityDistribution and associate them > - IfcDerivedUnitEnum.PHUNIT: add qk:Acidity, associate with unit:PH > - IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: and not sure what it > is, but I would add unit:M5 and qk:SectionAreaIntegral and associate > them > - IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: add > qk:TemperatureGradient, associate with unit:K-PER-M > - IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: add qk:WarpingConstant and > unit:M6, and associate them > - IfcDerivedUnitEnum.WARPINGMOMENTUNIT: add qk:WarpingMoment and > unit:N-M2 and associate them > > I am grateful for any corrections or suggestions for the problems listed > above. > > If there is interest, I could also contribute a mapping from QUDT units > to IFC units, and from QUDT quantitykinds to IFC unit types/measures. > > — > Reply to this email directly, view it on GitHub > <#599>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AATQRWJRTIVXEBODZOVCPHDWHJKI7ANCNFSM6AAAAAAR2KVZ2I> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > -- Jack

-- Jack

[jhodgesatmb]

Trying again but with only 1 file at a time: Steve and I worked on a CEC EPIC project together (with UC Berkeley) where we were constructing mappings between ontologies, and IFC was one of them. The problem here is that you cannot realistically integrate every single adhoc unit model with QUDT, especially if there are model conflicts. Rather, what you seek is a mapping ontology that maintains the autonomy and integrity of (in this case) IFC and BIM and QUDT but allows them to change and grow on their own with time. QUDT has committed to integrating with known unit standards, but when you get to a domain-generic or domain-specific model like IFC it makes more sense to create, share, and manage a mapping model. Steve and I published a paper with Computer (attached) outlining the mechanism of mapping standards.

…

On Tue, Nov 8, 2022 at 5:43 AM Florian Kleedorfer ***@***.***> wrote: I am working on an alignment between QUDT and IFC, a schema for building information modelling. The purpose is to define different 'standards' for building models (think: CompanyA's standard and CompanyB's standard), and to translate models from one standard to the other. Here is an Overview <https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/link/ifcmeasureresource.htm> of units/measurements in IFC I can map most of the IFC 'Measures' directly to QUDT QuantityKinds, but not all. Here are the problematic ones (using the IfcDerivedUnitEnum enum; each has a corresponding Measure, such as IfcIsothermalMoistureCapacityMeasure): - IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: qk:SpecificVolume is a more general QK that should fit - IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: qk:VolumeFlowRate might be ok - IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: qk:ThermalConductivity might fit - IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: qk:ThermalConductance might fit - IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: not in QUDT, no replacement found, and no unit either. Maybe https://en.wikipedia.org/wiki/Perm_(unit)? - IfcDerivedUnitEnum.LINEARFORCEUNIT: QUDT has qk:Force - the restriction to linear is not in QUDT. - IfcDerivedUnitEnum.PLANARFORCEUNIT: QUDT has qk:Force - the restriction to planar is not in QUDT. - IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: qk:ForcePerLength might be ok, I am unsure though. - IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: not in QUDT, and the common unit, N-PER-M3 has no QuantityKind. There is a Quantitykind with the same dimension vector, SpectralRadiantEnergyDensity, but that seems far off - IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: QUDT has qk:ForcePerArea that might be ok, based on the unit, N-PER-M2 - IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: not in QUDT, qk:ForcePerAngle might be ok, based on the unit, N-PER-RAD - IfcDerivedUnitEnum.HEATINGVALUEUNIT: qk:SpecificEnergy could fit - IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: not in QUDT. qk:IonDensity is a close match, but it may not be ok, as in IFC, it is associated with count per volume, but the derivation for ionconcentrationunit is g/l. - IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: not in QUDT. The derivation, cd / lm does not exist as a unit in QUDT - IfcDerivedUnitEnum.PHUNIT: not in QUDT as a QuantityKind, but there is unit:PH (no quantity kind) - IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: not in QUDT, and not sure what it is. The unit, m^5 is not in QUDT - IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: not in QUDT, but the unit, K/m is - IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: not in QUDT, nor is the unit, M^6 - IfcDerivedUnitEnum.WARPINGMOMENTUNIT: not in QUDT, but NM^2 is I would like to achieve bijective mappings between QUDT QuantityKinds and IFC Measures(UnitTypes) Thus, - mapping multiple IFC measures to qk:Force is a problem for me - having no mapping for an IFC measure (such as the warping measures) is a problem, too. Adding the missing units/quantitykinds would fix the problem for me, so I suggest to provide a PR with the following additions: - IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: add qk:IsothermalMoustureCapacity skos:broader qk:SpecificVolume - IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: add qk:MoistureDiffusivity skos:broader qk:VolumeFlowRate - IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: add qk:ThermalAdmittance skos:broader qk:ThermalConductivity - IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: add qk:TermalTransmittance skos:broader qk:ThermalConductance - IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: add the different https://en.wikipedia.org/wiki/Perm_(unit) units and qk:VaporPermeability (not sure of a more general concept to link to/from), and associate them - IfcDerivedUnitEnum.LINEARFORCEUNIT: add qk:LinearForce skos:broader qk:Force - IfcDerivedUnitEnum.PLANARFORCEUNIT: add qk:PlanarForce skos:broader qk:Force - IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: add qk:LinearStiffness skos:broader qk:ForcePerLength - IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: add qk:ModulusOfSubgradeReaction, link to and use qkdv of N-PER-M3 - IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: add qk:ModulusOfLinearSubgradeReaction skos:broader qk:ForcePerArea - IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: add qk:ModulusOfRotationalSubgradeReaction skos:broader qk:ForcePerAngle - IfcDerivedUnitEnum.HEATINGVALUEUNIT: add qk:HeatingValue skos:broader qk:SpecificEnergy - IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: do nothing (I'll use qk:IonDensity) - IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: Not sure what that is, but I would still add unit:CD-PER-LM and qk:LuminousIntensityDistribution and associate them - IfcDerivedUnitEnum.PHUNIT: add qk:Acidity, associate with unit:PH - IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: and not sure what it is, but I would add unit:M5 and qk:SectionAreaIntegral and associate them - IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: add qk:TemperatureGradient, associate with unit:K-PER-M - IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: add qk:WarpingConstant and unit:M6, and associate them - IfcDerivedUnitEnum.WARPINGMOMENTUNIT: add qk:WarpingMoment and unit:N-M2 and associate them I am grateful for any corrections or suggestions for the problems listed above. If there is interest, I could also contribute a mapping from QUDT units to IFC units, and from QUDT quantitykinds to IFC unit types/measures. — Reply to this email directly, view it on GitHub <#599>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQRWJRTIVXEBODZOVCPHDWHJKI7ANCNFSM6AAAAAAR2KVZ2I> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Jack

[jhodgesatmb]

I was not able to attach a paper pdf that was less than 5 mb so here is the link to it. I hope I don't have to do this again. https://basecamp.iec.ch/download/iec -white-paper-semantic-interoperability-challenges-in-the-digital-transformation-age-en/ <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbasecamp.iec.ch%2Fdownload%2Fiec-white-paper-semantic-interoperability-challenges-in-the-digital-transformation-age-en%2F&data=02%7C01%7Cjack.hodges%40siemens.com%7Cdbcb606cd23542b14af908d785597be9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637124491691534213&sdata=WkPoqLGgEVyA3b1XJQI55XfhOSot3Pkfx9mILLS1olg%3D&reserved=0>

…

On Tue, Nov 8, 2022 at 5:43 AM Florian Kleedorfer ***@***.***> wrote: I am working on an alignment between QUDT and IFC, a schema for building information modelling. The purpose is to define different 'standards' for building models (think: CompanyA's standard and CompanyB's standard), and to translate models from one standard to the other. Here is an Overview <https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/link/ifcmeasureresource.htm> of units/measurements in IFC I can map most of the IFC 'Measures' directly to QUDT QuantityKinds, but not all. Here are the problematic ones (using the IfcDerivedUnitEnum enum; each has a corresponding Measure, such as IfcIsothermalMoistureCapacityMeasure): - IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: qk:SpecificVolume is a more general QK that should fit - IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: qk:VolumeFlowRate might be ok - IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: qk:ThermalConductivity might fit - IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: qk:ThermalConductance might fit - IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: not in QUDT, no replacement found, and no unit either. Maybe https://en.wikipedia.org/wiki/Perm_(unit)? - IfcDerivedUnitEnum.LINEARFORCEUNIT: QUDT has qk:Force - the restriction to linear is not in QUDT. - IfcDerivedUnitEnum.PLANARFORCEUNIT: QUDT has qk:Force - the restriction to planar is not in QUDT. - IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: qk:ForcePerLength might be ok, I am unsure though. - IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: not in QUDT, and the common unit, N-PER-M3 has no QuantityKind. There is a Quantitykind with the same dimension vector, SpectralRadiantEnergyDensity, but that seems far off - IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: QUDT has qk:ForcePerArea that might be ok, based on the unit, N-PER-M2 - IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: not in QUDT, qk:ForcePerAngle might be ok, based on the unit, N-PER-RAD - IfcDerivedUnitEnum.HEATINGVALUEUNIT: qk:SpecificEnergy could fit - IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: not in QUDT. qk:IonDensity is a close match, but it may not be ok, as in IFC, it is associated with count per volume, but the derivation for ionconcentrationunit is g/l. - IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: not in QUDT. The derivation, cd / lm does not exist as a unit in QUDT - IfcDerivedUnitEnum.PHUNIT: not in QUDT as a QuantityKind, but there is unit:PH (no quantity kind) - IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: not in QUDT, and not sure what it is. The unit, m^5 is not in QUDT - IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: not in QUDT, but the unit, K/m is - IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: not in QUDT, nor is the unit, M^6 - IfcDerivedUnitEnum.WARPINGMOMENTUNIT: not in QUDT, but NM^2 is I would like to achieve bijective mappings between QUDT QuantityKinds and IFC Measures(UnitTypes) Thus, - mapping multiple IFC measures to qk:Force is a problem for me - having no mapping for an IFC measure (such as the warping measures) is a problem, too. Adding the missing units/quantitykinds would fix the problem for me, so I suggest to provide a PR with the following additions: - IfcDerivedUnitEnum.ISOTHERMALMOISTURECAPACITYUNIT: add qk:IsothermalMoustureCapacity skos:broader qk:SpecificVolume - IfcDerivedUnitEnum.MOISTUREDIFFUSIVITYUNIT: add qk:MoistureDiffusivity skos:broader qk:VolumeFlowRate - IfcDerivedUnitEnum.THERMALADMITTANCEUNIT: add qk:ThermalAdmittance skos:broader qk:ThermalConductivity - IfcDerivedUnitEnum.THERMALTRANSMITTANCEUNIT: add qk:TermalTransmittance skos:broader qk:ThermalConductance - IfcDerivedUnitEnum.VAPORPERMEABILITYUNIT: add the different https://en.wikipedia.org/wiki/Perm_(unit) units and qk:VaporPermeability (not sure of a more general concept to link to/from), and associate them - IfcDerivedUnitEnum.LINEARFORCEUNIT: add qk:LinearForce skos:broader qk:Force - IfcDerivedUnitEnum.PLANARFORCEUNIT: add qk:PlanarForce skos:broader qk:Force - IfcDerivedUnitEnum.LINEARSTIFFNESSUNIT: add qk:LinearStiffness skos:broader qk:ForcePerLength - IfcDerivedUnitEnum.MODULUSOFSUBGRADEREACTIONUNIT: add qk:ModulusOfSubgradeReaction, link to and use qkdv of N-PER-M3 - IfcDerivedUnitEnum.MODULUSOFLINEARSUBGRADEREACTIONUNIT: add qk:ModulusOfLinearSubgradeReaction skos:broader qk:ForcePerArea - IfcDerivedUnitEnum.MODULUSOFROTATIONALSUBGRADEREACTIONUNIT: add qk:ModulusOfRotationalSubgradeReaction skos:broader qk:ForcePerAngle - IfcDerivedUnitEnum.HEATINGVALUEUNIT: add qk:HeatingValue skos:broader qk:SpecificEnergy - IfcDerivedUnitEnum.IONCONCENTRATIONUNIT: do nothing (I'll use qk:IonDensity) - IfcDerivedUnitEnum.LUMINOUSINTENSITYDISTRIBUTIONUNIT: Not sure what that is, but I would still add unit:CD-PER-LM and qk:LuminousIntensityDistribution and associate them - IfcDerivedUnitEnum.PHUNIT: add qk:Acidity, associate with unit:PH - IfcDerivedUnitEnum.SECTIONAREAINTEGRALUNIT: and not sure what it is, but I would add unit:M5 and qk:SectionAreaIntegral and associate them - IfcDerivedUnitEnum.TEMPERATUREGRADIENTUNIT: add qk:TemperatureGradient, associate with unit:K-PER-M - IfcDerivedUnitEnum.WARPINGCONSTANTUNIT: add qk:WarpingConstant and unit:M6, and associate them - IfcDerivedUnitEnum.WARPINGMOMENTUNIT: add qk:WarpingMoment and unit:N-M2 and associate them I am grateful for any corrections or suggestions for the problems listed above. If there is interest, I could also contribute a mapping from QUDT units to IFC units, and from QUDT quantitykinds to IFC unit types/measures. — Reply to this email directly, view it on GitHub <#599>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQRWJRTIVXEBODZOVCPHDWHJKI7ANCNFSM6AAAAAAR2KVZ2I> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Jack

[dr-shorthair]

@jhodgesatmb how about https://mapping-commons.github.io/sssom/ ?

[fkleedorfer]

@jhodgesatmb found your report here: https://www.iec.ch/basecamp/semantic-interoperability-challenges-digital-transformation-age - for future reference

[fkleedorfer]

@jhodgesatmb I cannot find anything on CEC project EPIC (every page I find on google denies access). I'd be interested to see that TTL you mention. Much appreciated if you find a direct, plublicly accessible link to it!

[fkleedorfer]

I'll try to sum up the state of the discussion at this point:

• Adding the QuantityKinds and Units to QUDT as suggested seems to be ok with everyone (given that QUDT conventions are respected)
• Adding the mappings from QUDT to IFC directly to QUDT is discouraged because IFC is not a pure units/measurements system. A separate mapping ontology/vocabulary/resource would be preferred.
• It has been suggested to use SSSOM to represent the mappings.

Pressed for time as always, I'll go ahead and prepare the data for adding the QuantityKinds and units, because that's on my critical path anyway.

Concerning the mappings: I am fine with keeping the mappings on my side of the fence, at least for now. Not knowing much about QUDT and its goals and governance model, I am unsure as to how they should be represented. My suggestion, based on this discussion, would be to add a folder /mappings with a README.md explaining how mappings should be expressed ( using SSSOM, for example), and this is how we'll map IFC/QUDT, eventually.

[fkleedorfer]

Moving forward, I am trying to figure out how to model things the QUDT way. I've read #272 and am wondering about qudt:appropriateUnit, (which, I am guessing, has never been added, instead qudt:applicableUnit has taken its place, right?)

Anyway, the situation I have is the following:
existing data:

unit:M3-PER-KiloGM qudt:hasQuantityKind qk:SpecificVolume .

want to add

qk:IsothermalMoistureCapacity skos:broader qk:SpecificVolume .

where the appropriate unit for qk:IsothermalMoistureCapacity is unit:M3-PER-KiloGM, like for the broader quantity kind.
should I explicitly add the association

unit:M3-PER-KiloGM qudt:hasQuantityKind qk:IsothermalMoistureCapacity .

or will the algorithm determine this information for me via qudt:applicableUnit?

Also, where is this algorithm executed? I don't see anything (OWL constructs, RDFS stuff, or SHACL rules) in the release zip, so I assume that the release zip contains the triples inferred by the algorithm. Is that correct?

[steveraysteveray]

@fkleedorfer, you got everything right.

1. Yes, we replaced qudt:appropriateUnit with qudt:applicableUnit when we automated the generation.
2. As per the algorithm, if you want only unit:M3-PER-KiloGM as the applicable unit for qk:IsothermalMoistureCapacity, then you would add the qudt:hasQuantityKind association you list. However, it seems more appropriate to not add that association, in which case qk:IsothermalMoistureCapacity will "inherit" all the applicable units from its skos:broader quantity kind, qk:SpecificVolume. In other words, if no units point specifically to a given quantity kind, the algorithm navigates up the skos:broader hierarchy until it finds a quantity kind that does have at least one unit pointing to it.
3. And to answer your question about where the algorithm is executed, it is done off-line each time we publish a new release, and the inferences are explicitly asserted to the quantity kind vocabulary. The algorithm is based on the recursive "magic property" qudt:inferredApplicableUnit found in qudt-public-repo/schema/extensions/FUNCTIONS_QUDT-v2.1.ttl. (At some point, I'll incorporate it into the publication script, but right now the following query is used:)

DELETE {
GRAPH <http://qudt.org/2.1/vocab/quantitykind> {
    ?qk qudt:applicableUnit ?unit .
}}
INSERT {
GRAPH <http://qudt.org/2.1/vocab/quantitykind> {
    ?newqk qudt:applicableUnit ?newunit .
}}
WHERE {
{
    ?qk a qudt:QuantityKind .
    ?qk qudt:applicableUnit ?unit .
}
UNION
{
    ?newqk a qudt:QuantityKind .
    ?newqk qudt:inferredApplicableUnit ?newunit .
} .
} 

[jhodgesatmb]

I can send that report to you but since github wouldn't let me share a <5mb paper I am sure it won't let me share this at 10mb. Please send me a note at: ***@***.*** and I'll forward it to you. Title: EPIC_TechnicalSpecification, Chapter 5, Building Model Integrations Section, Page 70. Jack

…

On Wed, Nov 9, 2022 at 12:15 AM Florian Kleedorfer ***@***.***> wrote: @jhodgesatmb <https://github.com/jhodgesatmb> I cannot find anything on CEC project EPIC (every page I find on google denies access). I'd be interested to see that TTL you mention. Much appreciated if you find a direct, plublicly accessible link to it! — Reply to this email directly, view it on GitHub <#599 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQRWNKG62S7IFA6LOASU3WHNMTJANCNFSM6AAAAAAR2KVZ2I> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Jack