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

Rename storage capacity to energy storage capacity #1466

Closed
5 tasks
lumi321 opened this issue Feb 1, 2023 · 10 comments · Fixed by #1486
Closed
5 tasks

Rename storage capacity to energy storage capacity #1466

lumi321 opened this issue Feb 1, 2023 · 10 comments · Fixed by #1486
Labels
[C] definition update Update an ontology definition oeo-physical changes the oeo-physical module ready for implementation

Comments

@lumi321
Copy link
Contributor

lumi321 commented Feb 1, 2023

Description of the issue

The capacity to store energy is currently called storage capacity, which can be missleading and may be overseen, when searching for energy storage capacity. Therefore, I suggest to rename storage capacity to energy storage capacity.
Furthermore, storage capacity is currently just a quantity value, although the definition already refers to a maximum value1. Hence, I suggest to make it a subclass of maximum value.

Ideas of solution

Rename storage capacity to energy storage capacity.
Then, make energy storage capacity a subclass of maximum value.

Workflow checklist

  • I discussed the issue with someone else than me before working on a solution
  • I already read the latest version of the workflow for this repository
  • The goal of this ontology is clear to me

I am aware that

  • every entry in the ontology should have a definition
  • classes should arise from concepts rather than from words

Footnotes

  1. "Storage capacity is the quantity value stating the maximum energy an energy storage object can store."

@lumi321 lumi321 added [C] definition update Update an ontology definition oeo-physical changes the oeo-physical module To do Issues that haven't got discussed yet labels Feb 1, 2023
@lumi321 lumi321 added this to the oeo-release-1.14.0 milestone Feb 1, 2023
@l-emele
Copy link
Contributor

l-emele commented Feb 1, 2023

I agree. The existing class describes an energy storage capacity and there are other storage capacities like the water storage capacity of an water tank.

@chrwm
Copy link
Member

chrwm commented Feb 2, 2023

I also fully agree with your proposal - changing the label and making it a subclass of maximum value.

I then would miss a concept for energy storage content/level that does not refer exclusively to the theoretical maximum energy capacity of an energy storage, but also to an energy storage value between 0 and 100% of the max possible energy storage capacity.
E.g. if I'd like to annotate the energy storage content/level in context of modelling outputs, which will be between 0 and 100% of its energy storage capacity

@l-emele
Copy link
Contributor

l-emele commented Feb 2, 2023

I like your idea. However, I think can distinguish between two concepts:

  • How much energy is actually stored, so a value in an energy unit. So the battery has a storage capacity of 10 kWh, but the current energy storage content is only 5 kWh. I would label this energy storage content.
  • A value between 0 and 100% indicating the storage level (like the battery level indicator on the smartphone). I would label this energy storage level.

@github-actions github-actions bot removed the To do Issues that haven't got discussed yet label Feb 2, 2023
@chrwm
Copy link
Member

chrwm commented Feb 2, 2023

So then: energy storage content would be connected to energy -> has some energy amount value ?
And energy storage level would be without unit, e.g. referring to a relative value %?
If yes, one could name it storage level so that it is more universal, e.g. could be used in the context of storage level of water tank, grain silo, ...

@l-emele
Copy link
Contributor

l-emele commented Feb 2, 2023

If yes, one could name it storage level so that it is more universal, e.g. could be used in the context of storage level of water tank, grain silo, ...

That is true, but this brings a problem: A quantity value is always a quantity value of something and this something is in this case very broad. This probably requires something like an object with an storage function.

So I suggest, that we keep it for the moment narrow and define only the one that are related to energy storage. Proposals:

  • An storage level is an utilisation value that measures how much of an energy storage capacity is currently utilised.
  • An energy storage content is an energy amount value that measures the quantity of energy stored in an energy storage object.

This implies the axioms:

  • energy storage content' SubClassOf: 'energy amount value'
  • energy storage content' SubClassOf: 'quantity value of' some 'energy storage object
  • energy storage level' SubClassOf: 'utilisation value'
  • energy storage level' SubClassOf: 'quantity value of' some 'energy storage object'

Via their parent classes, energy storage content and energy storage level will also inherit the following axioms:

  • energy storage content' SubClassOf: 'has unit' some 'energy unit'
  • energy storage level' SubClassOf: 'has unit' some fraction 1

Footnotes

  1. Or at least it should inherit this. However, the axiom 'fraction value' SubClassOf: 'has unit' some fraction is missing despite the very obvious definition: A fraction value is a quantity value that has a fraction as it's unit. fraction value is the parent class of utilisation value.

@chrwm
Copy link
Member

chrwm commented Feb 7, 2023

Can we make it more concise, such as:

  • An storage level is an utilisation value that measures the utilisation/usage/exploitation how much of an energy storage capacity is currently utilised.

The temporal dimension of "currently" is implied in utilisation value with "instantaneous share".

With the proposed definition of 'energy storage content' and the axioms, I agree.

@l-emele
Copy link
Contributor

l-emele commented Feb 7, 2023

Okay, then I think we are ready to implement. Who will implement? @lumi321? Or maybe @u-mueller?

@u-mueller
Copy link
Contributor

  • An storage level is an utilisation value that measures the utilisation/usage/exploitation how much of an energy storage capacity is currently utilised.

Following your discussion and considering its starting point, shouldn't the definition be:

  • An engergy storage level is a utilisation value that measures the utilisation/usage/exploitation of energy storage capacity.

If so, should we think of renaming the class storage capacity to energy storage capacity and storage unit to energy storage unit since the definitions also only refer to engery storage?

Later on we could add superclasses storage capacity, storage object, storage capacity etc. with more general definitions if needed.

@l-emele
Copy link
Contributor

l-emele commented Feb 22, 2023

Following your discussion and considering its starting point, shouldn't the definition be:

* _An **engergy** storage level is a utilisation value that measures the utilisation/usage/exploitation of energy storage capacity._

If so, should we think of renaming the class storage capacity to energy storage capacity and storage unit to energy storage unit since the definitions also only refer to engery storage?

I agree.

@u-mueller
Copy link
Contributor

Ok, then I'll implement.

u-mueller added a commit that referenced this issue Feb 22, 2023
@u-mueller u-mueller mentioned this issue Feb 22, 2023
5 tasks
u-mueller added a commit that referenced this issue Feb 22, 2023
git commit -m Added
u-mueller added a commit that referenced this issue Feb 23, 2023
u-mueller added a commit that referenced this issue Feb 23, 2023
u-mueller added a commit that referenced this issue Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C] definition update Update an ontology definition oeo-physical changes the oeo-physical module ready for implementation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants