Open Philipp-Liedl opened 3 months ago
The concept of units is independent of whether they are physical or non-physical. It is preferable to define your property with its corresponding value, for example, 'height' with a 'value=5' and to use the DataSpecificationIec61360. The DataSpecificationIec61360 provides additional properties including 'unit' (e.g. "km") and 'unitID' (e.g. 0173-1#05-AAA595#004). The unitID allows to find the definition of the unit. Multiple international catalogs for Units of Measure exist, e.g. ECLASS, IEC CDD, UNECE. The UNECE catalog includes e.g. "dozen piece", "pallet". An updated version of a DataSpecification for Units of Measure is underway and will be published shortly. This will provide additional attributes for describing units. Alternatively, a separate property for the unit can be created, e.g. "height_unit" This modelling approach can be commonly found in solutions that are not based on the IEC 61360. It is also used in some Submodel Templates. While this gives the author more modelling freedom, it has a poorer semantic quality. In the latter approach, the tools require implicit knowledge that the value of Property A is the unit of Property B.
Is there a best practice approach to define units for properties which are not a physical or SI unit?
For example in an purchase order in which five pallets of a product are ordered, there is a property "OrderQuantity"=5 and the unit would be "pallet".
Should the unit in such cases be defined in the IEC61360, even if SI-based units are recommended to use, or rather in a separate property of type string called e.g. "OrderQuantityUnit"?