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

Criteria for submission of new units to UCUM #200

Open
dr-shorthair opened this issue Oct 3, 2022 · 2 comments
Open

Criteria for submission of new units to UCUM #200

dr-shorthair opened this issue Oct 3, 2022 · 2 comments
Assignees

Comments

@dr-shorthair
Copy link

Proposals for the addition of new code for units of measure in UCUM must meet certain requirements

  1. Submitters should explain why a new code is required
  2. The factor (and offset if needed) for conversion to the SI unit MUST be provided

If conversion to SI is not possible, then there must be a strong justification, which should refer to the importance of the unit, and the size of the community or application on behalf of whom the request is made.

@ehafeza
Copy link

ehafeza commented Oct 4, 2022 via email

@gschadow
Copy link

gschadow commented Oct 9, 2022

I do not agree to the following wording:

  1. The factor (and offset if needed) for conversion to the SI unit MUST be provided

there is no such thing called "offset" in the UCUM specification. This is done more generically with §21 special units where any transformation function is there, e.g., for logarithmic scale transformation, etc.

What this point 2 should say that the submitter is encouraged to provide a full mathematic definition. Many people will be turned off by that, because they believe it's rocket science, but actually it would help their own understanding if they tried and certainly allows these things to close faster.

Music intervals is one such example. Wire gauges is another. People who propose units should try to wrap their head around what they actually want to do with them.

That said, you cannot require it from everyone.

So, point 2 is really optional. We could say that items that have point 2 are given priority.

What is often more important is references to scientific articles or other documents that define the unit. This might include that companies provide an excerpt of internal documentations which they might consider confidential. But it is really necessary if you come to a public place wanting a public code.

A good example about this is pharma companies who want new units for strength (potency) of their products. These units are usually homegrown, and they reveal their metrological definitions (procedures, reference standards, etc.) to their regulating agency under broad confidentiality. (In Module 3 documents / PQ-CMC these things are found.)

We need to put policy in place that tells these companies to provide an abstract of their proposed unit for the public record, not just words, but metrological details. Since they don't want to release their PC-CMC spec to the public, they need to sit down and abstract all the relevant details to make their unit publicly reproducible.

By the way, there were policy text on the old site which I cannot find any more. I ask that the full text from the Trac site be restored here and used as a basis for all such questions, rather than just eradicating it all and start over from scratch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants