Please add energy-related task definitions in the OEO

[tpelser]

We (researchers from Jülich Systems Analysis) would like to use energy-related task definitions to describe research data (e.g. in knowledge graphs such as the ORKG or the OEKG), and to allow task/problem-oriented search and discovery of research data.

What are "task definitions":

These refer to tasks within a workflow for analysing aspects of energy systems.
As an example, the spreedsheet "workflow" in this Excel file contains an overview of the workflow tasks for literature looking at wind power potentials: https://data.fz-juelich.de/dataset.xhtml?persistentId=doi:10.26165/JUELICH-DATA/FXM9CB

These tasks include:
Tasks
1 Determine wind speed characteristics of the region
Definition: The tasks related to understanding the meteorological conditions of the study region and the theoretical wind potential.
1.1 Select appropriate wind data
1.2 Download & process wind data
1.3 *Extrapolate wind speed vertically to hub height
1.4 *Account for air density change
1.5 *Determine wind speed frequency distribution
1.6 Determine theoretical potential / WPD
2 Determine available area for wind farm development
Definition: The tasks related to estimating the areas which are available for development of wind parks, and the areas which are ineligible.
2.1 Download and process topographical data
2.2 …
3 Determine technical wind potential of the available land area
3.1 …
4 Determine economic potential of the available region
4.1 …
5 Determine feasible potential
5.1 …
() -> optional task

Our aims

Our aim is to first have task definitions which are agreed upon in the domain (for referencing research data to it). Second step would be to introduce relationships between tasks (which can be used for knowledge transfer and data exploration/navigation). A relationship could be “sub/super task”. A third step could be the numbering of tasks within processes/(software)workflows to transparently describe, what data processing steps were performed in a study.

As an example of how a task could look like in an ontology, the BioAssay Ontology and the task "mitochondrial membrane potential assessment" can be used: https://terminology.tib.eu/ts/ontologies/bao/terms?iri=http%3A%2F%2Fwww.bioassayontology.org%2Fbao%23BAO_0000423&obsoletes=false

This task includes a definition, an IRI and a task hierarchy with “mitrochondrial…” being a SubClass Of “viability measurement method”.

[tpelser]

I would prefer to change the label from "[A] new term" to "enhancement" but do not have access to that.

[stap-m]

As an example of how a task could look like in an ontology, the BioAssay Ontology and the task "mitochondrial membrane potential assessment" can be used: https://terminology.tib.eu/ts/ontologies/bao/terms?iri=http%3A%2F%2Fwww.bioassayontology.org%2Fbao%23BAO_0000423&obsoletes=false

Hi @tpelser I looked at the example from BAO. There, the tasks are classified as subclasses of some kind of method. A method would correspond to oeo's methodology. Is this what you intend?
To continue with this issue, I suggest to have a call and discuss the idea of the issue in more detail.

[tpelser]

Hi @stap-m, as discussed, here is the full list of tasks:

1. Determine the wind characteristics of the region
   1.1 Data acquisition and pre-processing
   1.2 Extrapolate wind speed vertically to hub height
   1.3 Account for air density change
   1.4 Determine wind speed frequency distribution
   1.5 Determine seasonal/diurnal variability
   1.6 Determine the theoretical potential / WPD

2. Determine available area for wind farm development
   2.1 Download and process topographical data
   2.2 Interpolate wind data to greater resolution horizontally
   2.3 Select exclusion criteria and buffer distances
   2.4 Acquisition and processing datasets for exclusion criteria
   2.5 * If soft exlusion criteria: determine MCDA approach
   2.6 Determine area/hotspots for development
   2.7 Determine geographical potential

3. Determine technical wind potential of the available area
   3.1 Select appropriate turbine type(s)
   3.2 *Place turbines in area or determine capacity density
   3.3 * Evaluate for single turbine
   3.4 Account for wake losses
   3.5 Use power curve with wind distribution function to determine annual energy yield
   3.6 Determine capacity factor CF
   3.7 Calculate technical potential

4. Determine economic potential of the available region
   4.1 Determine WT lifetime
   4.2 Determine investment costs
   4.3 Determine operating and maintenance costs
   4.4 Determine discount & interest rate
   4.5 Calculate LCOE for each turbine
   4.6 Calculate economic potential for LCOE range

5. Determine the feasible potential
   5.1 Apply additional social/market constraints
   5.2 Calculate feasible potential for the region

[stap-m]

In the figure, I visualized the (from IAO imported) structure that we use in OEO to relate methodologies to processes. I added the definitions (green) for explanation, and applied the structure to the first task of your list (blue).

The specification of the tasks raises (again) the question whether this is really within the scope of OEO. I put it on the next meeting's agenda.

[stap-m]

Hi @stap-m, as discussed, here is the full list of tasks:

1. Determine the wind characteristics of the region
   1.1	Data acquisition and pre-processing
   1.2	Extrapolate wind speed vertically to hub height
   1.3	Account for air density change
   1.4	Determine wind speed frequency distribution
   1.5	Determine seasonal/diurnal variability
   1.6	Determine the theoretical potential / WPD

@tpelser to proceed with the mapping of your tasks to the concept proposed, could you please draft definitions for the first subset of tasks, e.g. 1.-1.6? Ideally condensed to 1-2 sentences. We may have to adjust them to the OEO terminology, and in the following we can use them as templates for the other subsets.

EDIT: As shown in the figure above, "1. Determine the wind characteristics of the region" will probably become determination method for wind characteristics of a region.
We usually start definitions like this: A determination method for wind characteristics of a region is a methodology that ...

[stap-m]

@madbkr you drafted some definitions and axioms in #1940. Please describe them here first for discussing. Thanks.

[madbkr]

On relations:
@stap-m used "concretized" and "describes" in that scheme. Whle you already commented that you were unsure if these relations should be in the ontology, I found them rather helpful. When someone looks at these terms in the future and never saw the scheme I feel like the relations would help them understand how the classes interact.
However if people disagree I will remove them from the draft, I have no strong feeling that they absolutely need to be in there.

So I's propose adding the new relations:
concretizes with the inverse concretized by and the definition:
A relation which holds between a plan specification and a realizable entity.
and
describes with the inverse described by and the definition:
A relation which holds between a objective spezification and a process endpoint.

I tried to make definitions similar to those in existing relations.

Edit: These are removed now.

[madbkr]

According to the scheme I would add all the subtask of a task as a subclasses of action specification. So the classes:
data acquisition and pre-processing
extrapolate wind speed vertically to hub height
account for air density change
determine wind speed frequency distribution
determine seasonal/diurnal variability
determine the theoretical potential / WPD

Since I have no information in the nature of these tasks, I would use preliminary definitions like:
Data acquisition and pre-processing is an action specification that describes acquisition and pre-processing of data.
I am aware that these don't really add anything right now. I will try to come up with better definitions but would appreciate any input.

Edit: Definition outdated, see below.

[madbkr]

According to the scheme I would add tasks headline as a subclasses of objective specification. So the class:
determined wind characteristics of a region
I stuck to the preliminary definition:
Determined wind characteristics of a region is an object specification that defines the goal of a process as being the determination of wind characteristics of a region.

Edit: Definition outdated, see below, Removed axiom.

[madbkr]

According to the scheme I would add a method with the task's headline as a subclasses of methodology. So the class:
determination method for wind characteristics of a region
with the preliminary definition:
Determination method for wind characteristics of a region is a methodology with the goal to determine the wind characteristics of a region
and I would have it be a subclass of:
'has part' some 'determined wind characteristics of a region'

('has part' some 'data acquisition and pre-processing')
 and ('has part' some 'extrapolate wind speed vertically to hub height')
 and ('has part' some 'account for air density change')
 and ('has part' some 'determine wind speed frequency distribution')
 and ('has part' some 'determine seasonal/diurnal variability')
 and ('has part' some 'determine the theoretical potential / WPD')

This is the one I feel most unsure about.

Edit: Definition outdated, see below, removed axiom.

Added axiom
structures some 'determination process for wind characteristics of a region'

[madbkr]

According to the scheme I would add method realization potential as a subclass of realizable entity.
The preliminary definition is:
Method realization potential is a realizable entity that describes the potential unleashable by employing a method.

And it would be a subclass of:
realized in' some 'determination process for wind characteristics of a region

This may be problematic as we would have to add axioms for all the other tasks like this as axioms here. So maybe this should get a set of subclasses instead?

Edit: Definition outdated, see below, removed axiom.

This class is now removed

[madbkr]

According to the scheme I would add determination process for wind characteristics of a region as a subclass of process.
The preliminary definitions is:
Determination process for wind characteristics of a region is a process that is used to determine the wind characteristics of a region.
And it would be subclass of:
has part' some 'determine wind characteristics of a region endpoint

Edit: Definition outdated, see below

Added axiom
'structured by' some 'determination method for wind characteristics of a region'

[madbkr]

Lastly I would add process endpoint as a subclass of process boundary . Am am very surprised this was not already in there to be honest. A definition could be:
A process endpoint is a process boundary describing the endpoint of a process.

As a subclass of this process endpoint I add determine wind characteristics of a region endpoint with the preliminary definition:
Determine wind characteristics of a region endpoint is a process endpoint that marks the end of the 'determine the characteristics of a region' process.

All of these proposed changes can be seen in the draft pull request #1940

Edit: Definition outdated, see below, removed axiom

These classed are now removed

[stap-m]

Since I have no information in the nature of these tasks, I would use preliminary definitions like:
An action specification that describes acquisition and pre-processing of data.
I am aware that these don't really add anything right now. I will try to come up with better definitions but would appreciate any input.

That's ok for now. We use Aristotelian definitions, i.e. for your example it would be: Data aquisition ... is an action specification that describes.... This is best practise and important for the readability of the ontology and review process.

[stap-m]

Apply constraints is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.

This label is too generic, since constraints could be applied in any context. Apply constraints for potential assessment?

[madbkr]

@stap-m
The old definition read like this:
Apply additional social/market constraints is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.

If we wanted to stay as close to this as possible I would go with apply social/market constraintsinstead. If however that is still too generic - and I feel like it might be - then I am also fine with your proposition.

[madbkr]

Updated pending questions:

1. How should the subtasks relate to the task? Do all of them need to be done or just some of them? For now the axioms guessing the right appoach have been removed.

2. Will subtasks be reused in other tasks? Depending on this we could have parent classes for better readability or not.

3. Should the oeo always import this new module?

4. Should we add to the definitions or implement new classes to explain what things like "wind characteristics" even mean? Because there are goals of several object specifications now that don't really get elaborated on.

5. Should we generalize the definition or make some labels more specific?

[tpelser]

Wind variability identification is an action specification that describes the process of identifying variations in wind characteristics across different seasons and times of day.

I'd like at add a specification (e.g. a second sentence) what is meant by "wind characteristics". Wind speed and air desity at different hights? Something else? @tpelser

I would update this to:

Wind variability identification is an action specification that describes the process of identifying variations in wind characteristics—such as speed, direction, frequency, turbulence, and seasonal or diurnal patterns—across temporal scales.”

[tpelser]

Apply constraints is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.

This label is too generic, since constraints could be applied in any context. Apply constraints for potential assessment?

An answer to this could be:

"Integrate non-technical constraints in potential assessments is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.”

[madbkr]

"Integrate non-technical constraints in potential assessments is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.”

This label is even longer than the old one though and the goal was to make it more compact.

Thank you for the updated definition for wind variability. I updated it.

[tpelser]

Improve spatial resolution is an action specification that describes the process of increasing the spatial resolution of wind data across a region to provide finer detail for wind resource assessment. This is done by horizontal interpolation.

I guess such a method would be applicable to other data as well, e.g. PV. @tpelser? Souldn't we generalize the definition in that sense? Else, we should refer to (meteorological?) wind data in the label.

EDIT:

Determine capital expenditures is an action specification that describes the calculation of capital expenditures (CAPEX) required for the installation of wind turbines and associated infrastructure.
Determine operational expenditures is an action specification that describes the estimation of ongoing operational expenditures (OPEX) for wind turbines, including routine maintenance and operational management. These include operating and maintenance costs.

Determine wind turbine lifetime is an action specification that describes the process of estimating the operational lifespan of a wind turbine, based on design and site-specific conditions.
Calculate Levelized Cost of Energy is an action specification that describes the computation of the Levelized Cost of Energy (LCOE) either for individual turbines or for sub-regions within the study area by applying a cost model based on the previously calculated economic parameters and the capacity factors.

I think these could also be generalized. Maybe both, a generalized and a wind specific classs (as subclass?) are sensible.

For the first one, I agree it would make sense to generalize and we could update to:
Interpolate data horizontally is an action specification that describes the process of increasing the spatial resolution of geospatial data across a region to provide finer detail for resource assessments. This is done through horizontal interpolation.

For the next ones I am not sure if generalizing makes sense because as I understand it this is describing a workflow that is specific to wind resource assessments? Therefore these cost calculations are always to do with wind. Or maybe I do not understand properly

[tpelser]

"Integrate non-technical constraints in potential assessments is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.”

This label is even longer than the old one though and the goal was to make it more compact.

Okay, I did not see that the goal was to shorten this, I thought it was "too generic"?

I am not quite sure how we could possibly shorten it more than the original which was Apply constraints. Maybe just Integrate non-technical constraints or Apply non-technical constraints ?

We could shorten the entire description to something like:

“Integrate non-technical constraints is an action specification that describes the inclusion of factors like social acceptance, land use regulations, and market conditions into potential assessments.”

[madbkr]

@tpelser
The original labels were very long. In some cases almost whole sentences. The label should be more compact with specifics reserved for the definition. However apply constraints was so short that it became too generic. This is why apply constraints for assessment of potential came up as an option.
What do you think of the proposed integrate non-technical constraints or apply non-technical constraints, @stap-m ? I think they both sound reasonable.

[stap-m]

What do you think of the proposed integrate non-technical constraints or apply non-technical constraints, @stap-m ? I think they both sound reasonable.

I still think, the "assessment of potential" is a relevant part in this label that we should not drop, despite the length.

[madbkr]

In that case I think apply constraints for assessment of potential is the best solution so far. Unless @tpelser would say that the non-technical aspect is so important that it needs to be in the label. In that case:
apply non-technical constraints for assessment of potential is the still long but shortest version.

I don't think the definition needs to be shortened. I'd curently favor:
Apply constraints for assessment of potential is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.

[madbkr]

For the first one, I agree it would make sense to generalize and we could update to:
Interpolate data horizontally is an action specification that describes the process of increasing the spatial resolution of geospatial data across a region to provide finer detail for resource assessments. This is done through horizontal interpolation.

@stap-m
Should I implement this change or do you see a problem? I am fine with how it sounds.

[tpelser]

In that case I think apply constraints for assessment of potential is the best solution so far. Unless @tpelser would say that the non-technical aspect is so important that it needs to be in the label. In that case: apply non-technical constraints for assessment of potential is the still long but shortest version.

I don't think the definition needs to be shortened. I'd curently favor: Apply constraints for assessment of potential is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.

Actually, yes, since this is part of the feasible potential , it would be important to specify here that these are "non-technical" constraints:
Determine the feasible potential
5.1 Apply additional social/market constraints
5.2 Calculate feasible potential for the region

The original was apply additional social/market constraints. This could also be:
Apply additional socio-economic constraints

[madbkr]

Updated pending questions:

1. How should the subtasks relate to the task? Do all of them need to be done or just some of them? For now the axioms guessing the right appoach have been removed.

2. Will subtasks be reused in other tasks? Depending on this we could have parent classes for better readability or not. Right now we have that parent class.

3. Should we generalize the definition or make some labels more specific?

4. Should the oeo always import this new module?

5. Should we add to the definitions or implement new classes to explain what things like "wind characteristics" even mean? Because there are goals of several object specifications now that don't really get elaborated on.

To Do:

• for LCOE (OEO OEO_00020127) add axiom later
• decide constaints label

In progress

• 5

[madbkr]

@stap-m
In the pull request you commented:

The addition for wind characteristics seems to be still missing.

I added that to the To Do list but I am not sure what you are referring to. Do you possibly mean the change from:

apply constraints for assessment of potential
to either
apply non-technical constraints for assessment of potential
or
apply socio-economic constraints for assessment of potential

If so I don't think we agreed on one of them yet and that might be a thing wort doing.

[madbkr]

@tpelser
Could you comment on the relationship between a task and its subtasks? For example if we look at
determine wind characteristics of a region:
Do all the subtasks like wind speed calculation need to be taken? Do some specific ones need to be taken or maybe a certain number of them? With that answered we could craft new axioms for the relationship of the action specifications and the objective specification (or maybe the methodology).

[madbkr]

From the dev meeting:

• levelized cost of energy as an alternative label for levelized cost of electricity (which is already in the oeo) since both are well used -> no because the "of energy" version includes electricity and heat so it is not the same

• capacity factor and CF as alternative labels for net capacity factor -> capacity factor is already in there but CF can be added

• wind power density (WPD) is a quantity vale of the power wind has in a specific area. It is calculated as 0.5 * air density * (wind speed to the power of 3) -> Could be subclass of areal power density * (not entirely sure), should have its own issue.

• multi-criteria decision analysis (MCDA) is a methodology to help with decision making by defining goals, priorities and weights. -> should have its own issue

• wake loss is a loss in power output of turbines that occur due to speed reduction of wind that already passed another turbine. -> issue with losses is not ready

• social-economic is better than not-technical in the apply ? constraints for assessment of potential

• tasks should not be imported as it is too specific