-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
Resolve semantic integrity issues related to Unit
records
#389
Comments
In terms of IDs, we can use the OM2 semantic web reference, which looks like (for example): If we don't want to include the whole URL, We currently have Expanding this issue a little bit: Without getting into the longer range solution where networks can pick their own set of units from a useful facility (which is a big deal, see #223), there is one other thing we could add to make units more functional right now. That is to add a label override, like an alternative label, but without using OM2 alternative labels and without asking them to add alternatives. This would default to the label, but be changeable by the network, without changing anything from OM2. This would (temporarily?) solve problems with language and custom, and also solve the "one" problem, where mostly the terms used in "business" are not included in unit ontologies because they come from scientific communities. ("one" means one dimensional unit, which people might call "each", "piece", "count", etc., or just leave blank on the UI.) Side note: There are a lot of possible things to include in the data for each unit from OM2, some of which are multiples, like language support for label and symbol, or support for alternate labels. It's a bit difficult to pick a sweet spot for enough functionality vs too much complexity. Other attributes/properties that would be useful are: Lots of data derived from OM2 here. |
Moving discussion over to #387. I somehow missed this before my comment yesterday (above). Apologies.
Also noting that I was wrong that OM2 calls it |
Well-known units should be retrievable by well-known IDs. See also vf-graphql#104.
See #387 as a WIP which would be reimplemented via semantic indexing lib after resolving the upstream protocol decision.
The text was updated successfully, but these errors were encountered: