search

OpenEnergyPlatform / oekg

Repository for the Open Energy Knowledge Graph (OEKG)
Creative Commons Zero v1.0 Universal
8 stars 0 forks source link

[SFS] Improve list of keywords / descriptors #19

Open stap-m opened 1 year ago

stap-m commented 1 year ago

Description of the issue

The current list of ~keywords~ descriptors in the study factsheet template ist a proposal and needs improvement.

Factsheet

Study / Scenario

Field

Keywords, see Documentation

Ideas of solution

Please add keywords that are missing to describe your study / scenario in the list below. Please comment on whether the keywords are helpful or not, and what your ideas for improvement are.

descriptor source factsheet oeo id/label or issue#
carbon neutrality ÖI study OEO_00360010 (climate neutrality criteria)
negative emissions ÖI study OEO_00000293 (negative emission)
study fulfills a legal obligation (e.g. it is the projection under the MMR or part of the NECP) ÖI study OEO_00020373 (study report due to legal obligation)
~Transformation~ decarbonization pathways RLI study OEO_00010212
~Share of renewables~ RLI study OEO_00140133 (RE-share), redundant to 100% renewables
Flexibility RLI study OEO_00360007 (flexibility)
Efficiency RLI study OEO_00140050 (efficiency value) or OEO_00140049 (energy conversion efficiency)
resilience oekg study OEO_00360015
life cycle analysis oekg study ~https://github.com/OpenEnergyPlatform/ontology/issues/1551~ OEO_00330023 (life cycle assessment)
CO2 emissions oekg study OEO_00260007 (CO2 emission)
Greenhouse gas emissions oekg study OEO_00000199 (greenhouse gas emission)
~Reallabor / living lab~ oekg study ~tbd~
100% renewables oekg study OEO_00140133 (RE-share)
acceptance oekg study OEO_00360000
sufficiency oekg study OEO_00010444
primary energy demand SIROP study OEO_00140146 (energy demand)
final energy demand SIROP study OEO_00140146 (energy demand)
degree of electrifiaction oekg study ~https://github.com/OpenEnergyPlatform/ontology/issues/1434~ OEO_00020254 (electrical energy share)
regionalisation oekg study OEO_00340006
total gross electricity generation oekg study OEO_00240012 (gross electricity generation)
total net electricity generation oekg study https://github.com/OpenEnergyPlatform/ontology/issues/1837
peak electricity generation oekg study https://github.com/OpenEnergyPlatform/ontology/issues/1837
supply grid subclasses oekg study OEO_00360004, OEO_00000143, OEO_00020004, OEO_00020005
~grid / infrastructure extension~ oekg study tbd
sector coupling oekg study https://github.com/OpenEnergyPlatform/ontology/issues/1521
scenario projection comparison oekg study OEO_00360003
model intercomparison study oekg study OEO_00360002
policies and measures SIROP study OEO_00140151 (policy instrument)
senario subclasses SIROP scenario done, see https://github.com/OpenEnergyPlatform/ontology/issues/1329
christian-rli commented 1 year ago

It's not entirely clear to me what the keywords refer to. I found it not straight forward to select the included technologies, i.e. should I select that in the:

It feels to me like the latter would be correct. Our scenario includes the following technologies: PV, wind, biomass, biogas, solar thermal, heat pump, gas, coal, oil, CHP, electricity, gas, heat. As the non expert user I am, I would expect all of those to be keywords for our study/scenario, but I found it difficult to map them all with clarity and the impression that I need to sort of split them into those categories is an additional factor of confusion for me.

I realize that this is a complex task, but ideally the interface would guide the user to differentiate the categories above or auto-suggestion related fields. Can anyone anyone describe a clear separation to me? Also, how accurate is my impression, that a list like the above mentioned categories should be a part of every scenario description? If it applies, then it may be worth putting some effort in a simple interface.

stap-m commented 1 year ago

It's not entirely clear to me what the keywords refer to.

Our scenario includes the following technologies: PV, wind, biomass, biogas, solar thermal, heat pump, gas, coal, oil, CHP, electricity, gas, heat. As the non expert user I am, I would expect all of those to be keywords for our study/scenario, but I found it difficult to map them all with clarity and the impression that I need to sort of split them into those categories is an additional factor of confusion for me.

Ok, thats an important point. The keywords are meant to add additional information to the factsheets, beyond what is selectable in sectors, energy carriers and energy transformation process.

I realize that this is a complex task, but ideally the interface would guide the user to differentiate the categories above or auto-suggestion related fields. Can anyone anyone describe a clear separation to me?

These categories are currently derived 1:1 from the OEO and I have the feeling that they need a better structuring anyway. Can you give some input here @han-f @l-emele @Ludee ?

EDIT: I opended a separate issue #28 for this discussion. Please let's focus on the list of keywords in this issue.

stap-m commented 1 year ago

Notes from the SIROP project meeting on 25th of april:

l-emele commented 1 year ago

Here is a short list with further descriptors:

christian-rli commented 1 year ago

For completeness sake, here is the original list. The way I interpret this issue, all suggestions would add to them. If you feel like something needs to be removed, edit this comment and strike through words with double ~ around them and add your name, like so @christian-rli Scenario descriptors move into the study descriptors. I am crossing out duplicates here.

Study details:

scenarios:

christian-rli commented 1 year ago

I'm not a modeller, but I feel some relevant missing information are types of categorization that I keep hearing, but that I don't seem to find in the Factsheets so far:

l-emele commented 1 year ago

I'm not a modeller, but I feel some relevant missing information are types of categorization that I keep hearing, but that I don't seem to find in the Factsheets so far:

  • perfect foresight
  • linear optimization
  • mixed integer optimization

Do these really belong in the scenario factsheets? Looks more like things for the model factsheets.

christian-rli commented 1 year ago

Do these really belong in the scenario factsheets? Looks more like things for the model factsheets.

Good point, you're probably right. However, to be nitpicking, if I understand correctly, we're also talking about study factsheets, so one level above scenarios (but including those with a separate list of keys). I guess I felt that this warranted more context, but I agree that this is better located in the model factsheets.

I asked a modeler at the institute to add things to the current list. Without being given too much context, here are her suggestions:

stap-m commented 1 year ago
  • scenario fulfills a legal obligation (e.g. it is the projection under the MMR or part of the NECP)

@l-emele this sounds like a descriptor to a scenario, not a study. Right? For scenario descriptors, we agreed to only allow scenario subclasses. Can this be "translated" into a scenario subclass?

While searching the suggested descriptor terms in the OEO, I found the following terms that might suit as well. Can you please give feedback @l-emele @christian-rli @han-f @Ludee @u-mueller Thanks!

stap-m commented 1 year ago

I added the existing and newly suggested descriptors to the table above. Thus, we can keep overview of what we have already, and what not. Once, we agreed on a final-for-now list in this issue, I'll transfer the table to the OEO repo.

l-emele commented 1 year ago
  • scenario fulfills a legal obligation (e.g. it is the projection under the MMR or part of the NECP)

@l-emele this sounds like a descriptor to a scenario, not a study. Right? For scenario descriptors, we agreed to only allow scenario subclasses. Can this be "translated" into a scenario subclass?

Ok, then what about: study (report) fulfills a legal obligation?

  • CSS

What is CSS?

  • sensitivity analysis

Why do we need this as a descriptor when it is already a part of the scenario information?

stap-m commented 1 year ago

Sorry, typo. CCS

Why do we need this as a descriptor when it is already a part of the scenario information?

What do you mean by "scenario information"?

l-emele commented 1 year ago

Why do we need this as a descriptor when it is already a part of the scenario information?

What do you mean by "scenario information"?

As part of the scenario part of the factsheets it was foreseen to enter information on sensitivity analyses. So I don't think we should additionally have sensitivity analysis as descriptor.

l-emele commented 1 year ago

All of the following are processes that are modelled:

Maybe we need not only a selection field for energy transformation processes but also a field for something like: other processes modelled.

han-f commented 1 year ago

Jumping into this with some delay, I am not really sure I am up to speed. From an outsiders perspective I think it would be helpful for readers of factsheets to have some very broad keywords/tags that help them understand the overall context of a study / scenario. I was under the impression that this was, what the original "keywords" wanted to do.

Now we moved to a more detailed approach with connection to OEO. This is in my eyes helpful because it provides the mapping to the OEO and thus consistency, but at the same time it limits users to what is available in the OEO.

Would it maybe make sense to add these descriptors and additionally also allow users to provide their own set of (freely input) keywords to their factsheets? This may add flexibility. If the input field for such freely input keywords would also have the possibility to show already existing user-generated keywords, this may possibly help to limit the inputs as new users may orient themselves on what is already there and fits their context, too.

stap-m commented 1 year ago

Would it maybe make sense to add these descriptors and additionally also allow users to provide their own set of (freely input) keywords to their factsheets? This may add flexibility. If the input field for such freely input keywords would also have the possibility to show already existing user-generated keywords, this may possibly help to limit the inputs as new users may orient themselves on what is already there and fits their context, too.

Thanks for the input @han-f We discussed this during the project meeting. ovgu is quite reluctant regarding freetext entries. In the end we found that there is still the abstract field for freetext description where these terms could occur. If we see that this is not enough, we can still improve the descriptors at a later state. Is this a solution that you can go with?

l-emele commented 1 year ago

I discussed this topic on friday bilaterally with @u-mueller. We came to the conclusion, that currently on of the most important points, the research question(s) of the study and the scenarios, of the scenario are not properly depicted in the OEKG. I mention this here, because if we interpret the keywords as additional descriptors, then we need to find a way to depict the research question with ontology terms.

stap-m commented 1 year ago

Why do we need this as a descriptor when it is already a part of the scenario information?

What do you mean by "scenario information"?

As part of the scenario part of the factsheets it was foreseen to enter information on sensitivity analyses. So I don't think we should additionally have sensitivity analysis as descriptor.

I am not aware that we've included it yet. If I am wrong please indicate where... The plan is, that the scenario part will just have the scenario subclasses as selectable options.

stap-m commented 1 year ago

@christian-rli @l-emele @u-mueller @han-f Thanks for checking. Is the list above ok for you for a first version? If yes, we have to open respective OEO issues for further development.

christian-rli commented 1 year ago

The above list looks like a good first version to me. I approve :)

u-mueller commented 1 year ago

Shall we also add

?

stap-m commented 1 year ago

network development

Is that the same as grid exteansion, see table?

u-mueller commented 1 year ago

Is that the same as grid exteansion, see table?

Yes, sorry, it is more or less the same, maybe we can use network development and also grid expansion as alternative labels.

stap-m commented 1 year ago

Ok, I updated the table above. Feel free to open issues in the oeo repo for the missing terms and link them above.

stap-m commented 10 months ago

@han-f @l-emele The descriptor "study fulfills a legal obligation (e.g. it is the projection under the MMR or part of the NECP)" came from you. Would a solution be to add a scenario subclass instead of a study descriptor, e.g. legal obligation scenario?

stap-m commented 10 months ago

@christian-rli @chrwm the descriptor "Transformation Pathways" came from RLI. Is decarbonisation pathway a feasible alternative, or do you want to include a separate concept?

l-emele commented 10 months ago

@han-f @l-emele The descriptor "study fulfills a legal obligation (e.g. it is the projection under the MMR or part of the NECP)" came from you. Would a solution be to add a scenario subclass instead of a study descriptor, e.g. legal obligation scenario?

I would rather see this as a subclass of study report. E.g. the projections reports are study reports that contain scenarios and fulfil legal obligations.

christian-rli commented 10 months ago

@christian-rli @chrwm the descriptor "Transformation Pathways" came from RLI. Is decarbonisation pathway a feasible alternative, or do you want to include a separate concept?

Thank you for looking this up @stap-m ! I would consider the current definition of decarbonisation pathway equivalent, so we don't need a new concept.

han-f commented 10 months ago

@han-f @l-emele The descriptor "study fulfills a legal obligation (e.g. it is the projection under the MMR or part of the NECP)" came from you. Would a solution be to add a scenario subclass instead of a study descriptor, e.g. legal obligation scenario?

I would rather see this as a subclass of study report. E.g. the projections reports are study reports that contain scenarios and fulfil legal obligations.

I agree with @l-emele

jh-RLI commented 2 weeks ago

Is it possible to add an oekg relationship like "is_descriptor"? This would help me to retrieve all current descriptors.

As it is currently, I think I need to keep a static list of all descriptors as defined in the table above. If the list changes, we have to update the list manually. This is not what we want to have. It would be better if we could "register" a new descriptor in the oekg / oeo and then provide a code that retrieves all descriptors.

Or am i missing something?

@adelmemariani @l-emele @stap-m

l-emele commented 2 weeks ago

How are the descriptors currently stored in the OEKG?

jh-RLI commented 2 weeks ago

As far as i can see they are only stored in the oekg once they have been selected by the user during scenario bundle creation. 

descriptor = URIRef(descriptor["class"])
bundle.add(
    (scenario_URI, OEO["has_scenario_descriptor"], descriptor)
)

The list of the availabe descriptors itself is currently hardcoded like this:

https://github.com/OpenEnergyPlatform/oeplatform/blob/9cc259248fa2708ed5ee3f8a7acfeab892499e20/factsheet/frontend/src/components/factsheet.js#L272-L311

jh-RLI commented 2 weeks ago

Hm okay, since the code isnt clear without some further investigation im not sure if the study factsheet (=scenario bundle) descriptor will be saved this way because the code mentions the scenario insted of the scneario bundle ID. I will have another look at it.

jh-RLI commented 2 weeks ago

There it is, its saved with relation to the scenario bundle as I thought once the user selects & saves it:

bundle.add((study_URI, OEO["has_study_keyword"], Literal(keyword)))
l-emele commented 2 weeks ago

We already had for a different use case to include oekg specific annotations (not relations) in the oeo, see https://github.com/OpenEnergyPlatform/ontology/issues/1529. We might use that.

jh-RLI commented 2 weeks ago

Sound intresting to make this more clear: then there would be an annotation like OEO_00020005:"study_factsheet_descriptor=true"? This would definately help to automatically create a list of all availabe descriptors from the oeo.

l-emele commented 2 weeks ago

What I head in mind with my latest proposal in the OEO issue would lead to:

Class: OEO_00020009
    Annotations: 
        oekg_annotation "descriptor"
jh-RLI commented 2 weeks ago

That sounds very good, as long as all "descriptors" are "study descriptors". I don't know if there are any other use cases for descriptors annotations in the oeo (I'm not sure what might apply here e.g. "scenario descriptors").