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.

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

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-processing is 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?