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

Issue #71 - Allow Relating units together with Multipliers #146

Merged
merged 4 commits into from
Aug 26, 2021
Merged

Conversation

robons
Copy link
Contributor

@robons robons commented Aug 20, 2021

This PR serves to close Issue #71.

However, instead of allowing the user to specify a multiplier against each observations, we are allowing the user to define a new unit which is related to an existing one by a multiplying factor. This has the same effect of allowing us to define the inter-relationships between units which vary only by their magnitude.

See here for an example of how the new units can be defined relative to existing units.

See here for an example of the RDF which is output.

Uses some qudt along with the om2 ontology since the qudt ontology itself isn't sufficient to specify the multiplying factor relationship between two units in a low-maintenance way.

Rob Barry added 2 commits August 20, 2021 14:59
@robons robons changed the title Robons 71 Issue #71 - Allow Relating units together with Multipliers Aug 20, 2021
@robons robons marked this pull request as ready for review August 24, 2021 14:02
@rossbowen
Copy link

I don't see that we need to choose between OM2 and QUDT, it seems reasonable we could make use of both.

For units like MillionGBP I'd still like to specify a qudt:converstionFactor. It feels inconvenient to have to go via the base unit. (Though MillionGBP is one we'd end up defining centrally anyway).

How would a user specify something like "megalitres per day"?

@robons
Copy link
Contributor Author

robons commented Aug 25, 2021

I don't see that we need to choose between OM2 and QUDT, it seems reasonable we could make use of both.

I'm not entirely sure what you're suggesting here... I think we are using both.

For units like MillionGBP I'd still like to specify a qudt:converstionFactor. It feels inconvenient to have to go via the base unit. (Though MillionGBP is one we'd end up defining centrally anyway).

I think if we take this approach we might want to take a more organised and systematic approach to the QUDT ontology and ensure we define all the related quantityKinds, etc. that we think we should be doing. It's probably something we would want to do more thoroughly than the quick-and-dirty approach that we're taking here to make it easy for users to do something as expressive as possible quite quickly.

How would a user specify something like "megalitres per day"?

i think they'd base it off the m^3 per day qudt unit (http://qudt.org/vocab/unit/M3-PER-DAY) and provide the conversion factor of 10^3.

1 megalitre = 10^6 litres = 10^6 * 10^-3 m^3 = 10^3 m^3

Copy link
Contributor

@CharlesRendle CharlesRendle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@santhosh-thangavel and I have worked through the changes made by this PR and have come up with some questions regarding the gaps in our combined knowledge.

@santhosh-thangavel
Copy link
Contributor

@ Rob, Thanks for the answers.

@rossbowen
Copy link

Cheers @robons, would be good to get qudt:conversionMultiplier as an optional attribute on NewQbUnit.

…nd dependency) as a result of PR comments.
@robons
Copy link
Contributor Author

robons commented Aug 26, 2021

Cheers @robons, would be good to get qudt:conversionMultiplier as an optional attribute on NewQbUnit.

@rossbowen I've added the qudt:conversionMultiplier functionality there. I've made it codependent on providing the quantity kind that the unit is part of since the qudt:conversionMultiplier only allows automated conversion between units when part of a quantityKind family.

Happy with the changes?

@robons robons merged commit 7c44c2b into main Aug 26, 2021
@robons robons deleted the robons-71 branch August 26, 2021 13:04
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

Successfully merging this pull request may close these issues.

4 participants