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 inverseconcretized 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-processingis 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.

[madbkr]

@stap-m Now I see what you mean. As the imported definitions usually leave out the first part of the sentence (see pic) I assumed that it was implied. I will add it to the definitions.

[stap-m]

('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')

I see. Logically, this axiom states that any determination method for wind characteristics of a region. But I think this is not necessarily correct. My interpretation is that any of these action specifications may or may not be part of the methodology. Is that correct @tpelser ?

[stap-m]

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 inverseconcretized 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.

The important classes in this model are the subclasses of methodology, action specification, objective specification and process. The realizable entities and process endpoints are rather of theoretical value in this model. In case we find, that the definition of specific process endpoints will be a usefull and specifyable for some methods in this model, we can still integrate them later.

[madbkr]

Alright, then I will remove the relations and all axioms that include them. Of course now some of the new classes don't have any relationship with each other now.

I will update my previous comments accordingly.

[stap-m]

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.

The important classes in this model are the subclasses of methodology, action specification, objective specification and process. The realizable entities and process endpoints are rather of theoretical value in this model. In case we find, that the definition of specific process endpoints will be a usefull and specifyable for some methods in this model, we can still integrate them later.

I get your point that a relation between the methodological parts and the process would be important @madbkr . Maybe we can find a nice "shortcut" relation between processes and methods. E.g. subproperties of has participant/participates in. First brainstorming results: process 'structured by' / 'predefined by' / 'determined by' methodology ???

[madbkr]

@stap-m To be very honest, I am not sure if method realization potential is a class that really needs to be here. Especially if we want to use a shortcut. It currently has the realized in relationship to determination process for wind characteristics of a region. Could you explain what the class does for us?

First brainstorming results: process 'structured by' / 'predefined by' / 'determined by' methodology

All of these are also new relations, right? I feel like predefined by and structured by sound good. Some more ideas: planned by / established by / proposed by. It depends a bit in the question if the methodology is seen as a strict ruleset to follow or a more general guide.

I also looked at existing relations. Maybe is defined by? The definition is: A relation between a continuant (A) and a continuant or occurent (B) in which (A) determines the semantic of (B)

I feel like the connection between the objective specification - which describes the desire endpoint - and the actual endpoint is really missing. If we want to use an existing relationship, how about the existing is about? It is defined as: A (currently) primitive relation that relates an information artifact to an entity.

[stap-m]

To be very honest, I am not sure if method realization potential is a class that really needs to be here. Especially if we want to use a shortcut.

As I wrote above, I think they are of rather theoretical value. We don't actually need it.

[stap-m]

I also looked at existing relations. Maybe is defined by? The definition is: A relation between a continuant (A) and a continuant or occurent (B) in which (A) determines the semantic of (B)

I also looked at that one. But it doesn't really serve here: in our case, methodology would be A (the continuant) and the process would be B (the occurent). Hence, the methodology would be semantically defined by the process, which is wrong, obviously... we need a relation where the methodology "defines" the process.

[stap-m]

I feel like the connection between the objective specification - which describes the desire endpoint - and the actual endpoint is really missing. If we want to use an existing relationship, how about the existing is about? It is defined as: A (currently) primitive relation that relates an information artifact to an entity.

Sure, that would be a solution. However, I didn't put much thought into the characteristics of the "endpoint" yet, what is actually meant by that and whether it is needed at all...

I updated the figure to illustrate better where I see the focus for now.

[madbkr]

To be very honest, I am not sure if method realization potential is a class that really needs to be here. Especially if we want to use a shortcut.

As I wrote above, I think they are of rather theoretical value. We don't actually need it.

I'm sorry - I forgot about that previous comment. I remember reading it now... So I should remove both the endpoint classed and the realizable entity, correct?

[madbkr]

I also looked at existing relations. Maybe is defined by? The definition is: A relation between a continuant (A) and a continuant or occurent (B) in which (A) determines the semantic of (B)

I also looked at that one. But it doesn't really serve here: in our case, methodology would be A (the continuant) and the process would be B (the occurent). Hence, the methodology would be semantically defined by the process, which is wrong, obviously... we need a relation where the methodology "defines" the process.

How about participates in? The definition only states: a relation between a continuant and a process, in which the continuant is somehow involved in the process and we have a continuant and a process and they are "somehow" involved. I feel like this is usually more used as a physical thing that is used in a process but the definition doesn't seem to be strict about it.

[madbkr]

@stap-m As discussed in the meeting I propose a new object property with it's inverse: structures as a subclass of participated in and structured by as a subclass of has participant. A definition of structures could be: A relationship between a continuant and a process, in which the continuant predefines or planns the process. A definition for structured by could be: A relationship between a process and a continuant, in which the process is predefined or planned by the process.

[madbkr]

Now determination process for wind characteristics can be subclass of: 'structured by' some 'determination method for wind characteristics of a region' and determination method for wind characteristics can be subclass of: structures some 'determination process for wind characteristics of a region'

[madbkr]

I made some new definitions for all the classes. They will likely need changes but they are an improvement over what I used before:
Data acquisition and pre-processingis an action specification that describes what steps the bearer takes to acquire data and how this data is prepared for further use.
Extrapolate wind speed vertically to hub height is an action specification that describes how the wind speed at the rotor’s height above ground is inferred.
Account for air density change is an action specification that describes how fluctuations in wind density are considered.
Determine wind speed frequency distribution is an action specification that describes how a distribution of wind speed classes per time unit is acquired.
Determine seasonal/diurnal variability is an action specification that describes how fluctuations during a day or a season are found out.
Determine the theoretical potential / WPD is an action specification that describes how the theoretical potential of wind power (= WPD) is calculated.
Determined wind characteristics of a region is an object specification that defines the goal of a process as a state of understanding the specific wind characteristics of a predefined region.
Determination method for wind characteristics of a region is a methodology with the goal to understand the specific wind characteristics of a predefined region.
Determination process for wind characteristics of a region is a process that follows some kind of methodology to gain knowledge of the specific wind characteristics of a predefined region.

[stap-m]

@stap-m As discussed in the meeting I propose a new object property with it's inverse: structures as a subclass of participated in and structured by as a subclass of has participant. A definition of structures could be: A relationship between a continuant and a process, in which the continuant predefines or planns the process. A definition for structured by could be: A relationship between a process and a continuant, in which the process is predefined or planned by the process.

I think we can specify the domain/range further to either plan specification or methodology on the continuant side.

Now determination process for wind characteristics can be subclass of: 'structured by' some 'determination method for wind characteristics of a region'

Ok 👍

and determination method for wind characteristics can be subclass of: structures some 'determination process for wind characteristics of a region'

There might exist methodologies that will never be realized in a process. For such cases the axiom would be false. Maybe the one above is sufficient.

[madbkr]

I specified it to "plan specification" now. I feel like other subclasses like "study design" would also make sense as the range.

I removed the false axiom. Maybe we should also remove the relation structures then as it is no longer used?

[stap-m]

@madbkr could you please document the definitions from @tpelser (sent via e-mail) here and integrate them into the PR?

[stap-m]

I removed the false axiom. Maybe we should also remove the relation structures then as it is no longer used?

Yes, sounds reasonable.

[madbkr]

Here are the definitions for the first task as updated by @tpelser. For clarity I will post one comment for each task. I will reflect those changes in the module in the next commit.

Determination method for wind characteristics of a region is a methodology with the goal to understand the specific wind characteristics of a predefined region, encompassing data acquisition, modelling, and analytical procedures
Data acquisition and pre-processing is an action specification that describes the steps the bearer takes to acquire raw data and how this data is cleaned, transformed, and structured for subsequent analysis.
Extrapolate wind speed vertically to hub height is an action specification that describes how wind speed at the hub height of a wind turbine is inferred from measurements taken at a different height.
Account for air density change is an action specification that describes how variations in air density due to changes in altitude, temperature, and pressure are incorporated into the wind resource calculations.
Determine wind speed frequency distribution is an action specification that describes the process of calculating the frequency of different wind speed intervals over a set period.
Determine seasonal/diurnal variability is an action specification that describes the process of identifying variations in wind characteristics across different seasons and times of day.
Determine the theoretical potential / WPD is an action specification that describes how Wind Power Density (WPD) is calculated to estimate the theoretical wind power potential based on wind speed and air density.

[madbkr]

Determination method for the available area for wind farm development is a methodology with the goal of identifying and quantifying the area suitable for wind farm development, based on topographical, environmental, and regulatory constraints
Interpolate wind data to greater resolution horizontally 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
Select exclusion criteria and buffer distancesis an action specification that describes the process of defining physical, environmental, and regulatory criteria that exclude areas from wind farm development, along with the application of buffer zones
Acquisition and processing datasets for exclusion criteria is an action specification that describes the steps involved in obtaining and preparing datasets that represent exclusion zones for wind farm development, based on predefined criteria.
Determine MCDA approach for soft exclusion criteria is an action specification that describes how a Multi-Criteria Decision Analysis (MCDA) method is applied to areas where exclusions are not absolute, allowing for weighted decision-making
Determine area for development is an action specification that describes the identification of potential areas where wind farm development is feasible, by iteratively excluding non-available areas based on the processed data and exclusion criteria
Determine geographical potential is an action specification that describes the calculation of the total geographical area available for wind farm development after applying exclusion criteria and considering spatial constraints

[madbkr]

Determination method for the technical wind potential of the available area is a methodology with the goal of calculating the technical wind energy potential within the identified suitable area, considering turbine technology, placement, and energy yield factors.
Select appropriate turbine type(s) is an action specification that describes the process of choosing wind turbine models based on site-specific wind characteristics, hub height, and rotor diameter.
Place turbines in area or determine capacity density is an action specification that describes how turbines are spatially distributed within the available area, or how the capacity density (MW per unit area) is calculated.
Account for wake losses is an action specification that describes the inclusion of losses due to wind turbine wake effects, which reduce wind speed and energy yield behind turbines.
Use power curve with wind distribution function to determine annual energy yield is an action specification that describes how a turbine's power curve is combined with the wind speed distribution to calculate the expected annual energy production.
Determine capacity factor (CF) is an action specification that describes the calculation of the capacity factor, which represents the ratio of actual energy output to the maximum possible output over a given time period.
Calculate technical potential is an action specification that describes how the total energy production capability of the available area is determined, factoring in turbine placement, capacity density, and wake losses.

[madbkr]

Determination method for the techno-economic potential of the available region is a methodology with the goal of assessing the economic viability of wind energy projects within the available area, based on the technical potential and incorporating cost factors and economic metrics.
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.
Determine investment costs is an action specification that describes the calculation of capital expenditures (CAPEX) required for the installation of wind turbines and associated infrastructure.
Determine operating and maintenance costsis an action specification that describes the estimation of ongoing operational expenditures (OPEX) for wind turbines, including routine maintenance and operational management.
Determine discount & interest rate is an action specification that describes the selection of financial discount and interest rates, which are used in the economic analysis to account for the time value of money.
Calculate Levelized Cost of Energyis 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.
Calculate economic potential for LCOE range is an action specification that describes the determination of the total economic potential of the available area under a maximum threshold LCOE value.

[madbkr]

Determination method for the feasible potential is a methodology with the goal of calculating the wind energy potential that remains after applying additional social, regulatory, or market constraints to the available region.
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.
Calculate feasible potential for the region is an action specification that describes the calculation of the feasible wind energy potential, considering both technical and socio-economic constraints.

[madbkr]

@stap-m Should I implement the other tasks now that we have definitions or wait until after the next dev meeting?

[stap-m]

@stap-m Should I implement the other tasks now that we have definitions or wait until after the next dev meeting?

Go ahead! :rocket:

[madbkr]

@stap-m I am noticing that the list of action specifications becomes very crowded and confusing if all of those are just thrown in there. I think it would be good if the ones that relate to a task would have a parent class. For the first task that could be action specification for wind characteristics very simply defined as Action specification for wind characteristics is an action specification that deals with wind characteristics

I am adding them for now, if only to make implementation more readable for me. I can remove them if they are unwanted.

[madbkr]

There were some missing definitions. I preliminarily defined them as:

Determination process for the available area for wind farm development is a process that follows some kind of methodology to gain knowledge of the available area for wind farm development.

Determination process for the feasible potential is a process that follows some kind of methodology to gain knowledge of the feasible potential of something

Determination process for the technical wind potential of the available area is a process that follows some kind of methodology to gain knowledge of the technical wind potential of the available area

Determination process for the techno-economic potential of the available regiont is a process that follows some kind of methodology to gain knowledge of the techno-economic potential of the available region

Determined available area for wind farm development is an object specification that defines the goal of a process as a state of understanding the available area for wind farm development.

Determined the feasible potential is an object specification that defines the goal of a process as a state of understanding the the feasible potential of something

Determined the techno-economic potential of the available region is an object specification that defines the goal of a process as a state of understanding the techno-economic potential of the available region

Determined wind characteristics of a region is an object specification that defines the goal of a process as a state of understanding the specific wind characteristics of a predefined region.

[stap-m]

@stap-m I am noticing that the list of action specifications becomes very crowded and confusing if all of those are just thrown in there. I think it would be good if the ones that relate to a task would have a parent class. For the first task that could be action specification for wind characteristics very simply defined as Action specification for wind characteristics is an action specification that deals with wind characteristics

I am adding them for now, if only to make implementation more readable for me. I can remove them if they are unwanted.

That's fine for now. I'll take a look. We might have to remove them once the PR is ready, for all of the action specification might be usable in any plan specification.

[madbkr]

We have decided to get the first pull request ready with 3 more questions remaining:

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?

[madbkr]

Some things that we may want to do for the new module:

• add study region/region of relevance and use the chosen term in all the definitions that refer to a region
• add axioms for concepts that relate to theoretical potential maybe wind power density as these are already in the OEO (OEO_00140063: theoretical stock potential). and check for all classes that are about potential as well
• add MCDA as separate concept

[madbkr]

As the lables of the new classes are really long now I have tried to come up with shorter lables and add missing information from the old lables to the definitions. Maybe those would look a bit better?

Wind characteristics determination method is a methodology with the goal to understand the specific wind characteristics of a predefined region, encompassing data acquisition, modelling, and analytical procedures.

Data preparation is an action specification that describes the steps the bearer takes to acquire raw data and how this data is cleaned, transformed, and structured for subsequent analysis. So it includes the acquisition and pre-processing of data.

Wind speed calculation is an action specification that describes how wind speed at the hub height of a wind turbine is inferred from measurements taken at a different height. It is extrapolated vertically to the hub height.

Air density adjustment is an action specification that describes how variations in air density due to changes in altitude, temperature, and pressure are incorporated into the wind resource calculations.

Wind speed frequency analysis is an action specification that describes the process of calculating the frequency of different wind speed intervals over a set period giving a wind speed frequency distribution.

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

Wind Power Density calculation is an action specification that describes how Wind Power Density (WPD) is calculated to estimate the theoretical wind power potential based on wind speed and air density.

[tpelser]

From my perspective, ie in defining the wind assessment tasks, these look good. I would only suggest to rather stick with "wind variability identification". In this case we are specifically looking at the variability of the wind resource on different timescales (and possibly spatial variability as well). "Periodic/cyclic/intermittent variability" would be a tautology.

[madbkr]

@tpelser Thank you for your feedback! I edited the lable.

[madbkr]

Wind farm area determination method is a methodology with the goal of identifying and quantifying the area suitable for wind farm development, based on topographical, environmental, and regulatory constraints.

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.

Select exclusion criteria is an action specification that describes the process of defining physical, environmental, and regulatory criteria that exclude areas from wind farm development, along with the application of buffer zones.

Prepare exclusion criteria datasets is an action specification that describes the steps involved in obtaining and preparing datasets that represent exclusion zones for wind farm development, based on predefined criteria. That includes acquiring and processing the data.

Run Multi-Criteria Decision Analysis is an action specification that describes how a Multi-Criteria Decision Analysis (MCDA) method is applied to areas where exclusions are not absolute (soft exclusion criteria), allowing for weighted decision-making.

Determine development area is an action specification that describes the identification of potential areas where wind farm development is feasible, by iteratively excluding non-available areas based on the processed data and exclusion criteria.

Unchanged:

Determine geographical potential is an action specification that describes the calculation of the total geographical area available for wind farm development after applying exclusion criteria and considering spatial constraints.

[madbkr]

@tpelser @stap-m

I have a problem with this task:

Place turbines in area or determine capacity density is an action specification that describes how turbines are spatially distributed within the available area, or how the capacity density (MW per unit area) is calculated.

To me it seems like these are two different tasks on a forked path. I don't think this should be one class if this is the case.

[madbkr]

Wind potential determination method is a methodology with the goal of calculating the technical wind energy potential within the identified suitable area, considering turbine technology, placement, and energy yield factors.

Select appropriate turbine types is an action specification that describes the process of choosing wind turbine models based on site-specific wind characteristics, hub height, and rotor diameter.

Determine annual energy yield is an action specification that describes how a turbine's power curve is combined with the wind speed distribution to calculate the expected annual energy production.

Determine capacity factor is an action specification that describes the calculation of the capacity factor (CF), which represents the ratio of actual energy output to the maximum possible output over a given time period.

Unchanged:

Account for wake losses is an action specification that describes the inclusion of losses due to wind turbine wake effects, which reduce wind speed and energy yield behind turbines.

Calculate technical potential is an action specification that describes how the total energy production capability of the available area is determined, factoring in turbine placement, capacity density, and wake losses.

To be edited:

Place turbines in area or determine capacity densityis an action specification that describes how turbines are spatially distributed within the available area, or how the capacity density (MW per unit area) is calculated.