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

Unit Representation #27

Closed
diatomsRcool opened this issue Dec 18, 2024 · 6 comments
Closed

Unit Representation #27

diatomsRcool opened this issue Dec 18, 2024 · 6 comments

Comments

@diatomsRcool
Copy link
Contributor

Right now Quantity.unit is a string. Should we consider making this a dynamic enum that pulls from Unit Ontology?

@bfurner
Copy link
Collaborator

bfurner commented Dec 18, 2024

that's a good idea. do you have a link to that ontology?

@diatomsRcool
Copy link
Contributor Author

@bfurner
Copy link
Collaborator

bfurner commented Dec 19, 2024

The unit representation i've seen used regularly is UCUM. This is what LOINC and FHIR use. Also LinkML has built-in support for UCUM as can be seenhere. This may be a better option than the Unit Ontology, but I am open to either.

@diatomsRcool
Copy link
Contributor Author

Let's use UCUM then.

@bfurner
Copy link
Collaborator

bfurner commented Dec 20, 2024

I created a PR that defines an enum for units of measurement using the UCUM-based Units of Measurement (UOM) ontology. If that looks good @diatomsRcool go ahead and merge the PR, or let me know and I can do so.

@diatomsRcool
Copy link
Contributor Author

Looks like you did it, so I'm closing this issue.

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

No branches or pull requests

2 participants