You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rec 20 uses a level/category scheme to break UOM codes into core SI,
Level 1 - normative = SI normative units, standard and commonly used multiples. NOTE: standard multiples are identified with "S" and commonly used multiples with "M" e.g. "1 metre", "1S centimetre", "1M hectometre").
Level 2 – normative equivalent = SI normative equivalent units (UK, US, etc.) and commonly used multiples.
Level 3 – informative = 9 categories of informative units (units of count and other miscellaneous units), invariably with no comprehensive conversion factor to SI. These units are provided for information and to facilitate the assignment and usage of a common code value to represent such units.
3.1 Qualified base units from levels 1 and 2
3.2 Sales units
3.3 Packing units
3.4 Shipping and transportation units
3.5 Industry specific units (various)
3.6 Information technology units
3.7 Integers/Numbers/Ratios
3.8 Multiples/Fractions/Decimals
3.9 Miscellaneous
I'd suggest that this is a means to merge annex I and annex II into one resource. Also perhaps the API should split level & category into two properties that can be used in the query.
The text was updated successfully, but these errors were encountered:
@onthebreeze i had a discussion with Sue on this code list today to find out some history etc. I think it would be acceptable to merge these, she mentioned the common code is important for linking but it could be a property in #21 (searchable if required) and if we move some other detail out to JSON-LD then no reason why not merge. I would support doing that for sure..
Rec 20 uses a level/category scheme to break UOM codes into core SI,
3.2 Sales units
3.3 Packing units
3.4 Shipping and transportation units
3.5 Industry specific units (various)
3.6 Information technology units
3.7 Integers/Numbers/Ratios
3.8 Multiples/Fractions/Decimals
3.9 Miscellaneous
I'd suggest that this is a means to merge annex I and annex II into one resource. Also perhaps the API should split level & category into two properties that can be used in the query.
The text was updated successfully, but these errors were encountered: