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
Our application of quantityKind is not internally consistent yet. Some of us attach many (based on dimension vector), some of attach only one, high level. We need a better understanding of
a. relationships between existing quantityKinds(parent-child?, common dimension vector)
b. potential use of quantityKind for sorting/grouping a list of units (e.g., in a web application for choosing units)
The text was updated successfully, but these errors were encountered:
Basically, all quantity kinds related by skos:broader must have the same dimension vector.
The example given by the link demonstrates how different quantity kinds in the skos:broader hierarchy might have more or fewer applicable units.
All of the applicableUnit relations are (statically) computed from the hasQuantityKind relations from Units pointing to QuantityKinds, according to the algorithm shown at the link. This is refreshed with each Release.
Our application of quantityKind is not internally consistent yet. Some of us attach many (based on dimension vector), some of attach only one, high level. We need a better understanding of
a. relationships between existing quantityKinds(parent-child?, common dimension vector)
b. potential use of quantityKind for sorting/grouping a list of units (e.g., in a web application for choosing units)
The text was updated successfully, but these errors were encountered: