Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of level / category information #20

Open
onthebreeze opened this issue Jul 16, 2019 · 1 comment
Open

Use of level / category information #20

onthebreeze opened this issue Jul 16, 2019 · 1 comment
Labels
question Further information is requested

Comments

@onthebreeze
Copy link
Contributor

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.

@onthebreeze onthebreeze added the question Further information is requested label Jul 16, 2019
@cmsdroff
Copy link
Contributor

cmsdroff commented Aug 1, 2019

@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..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants