-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please add energy-related task definitions in the OEO #1891
Comments
I would prefer to change the label from "[A] new term" to "enhancement" but do not have access to that. |
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? |
Hi @stap-m, as discussed, here is the full list of tasks:
|
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. |
@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 |
On relations: So I's propose adding the new relations: I tried to make definitions similar to those in existing relations. Edit: These are removed now. |
According to the scheme I would add all the subtask of a task as a subclasses of Since I have no information in the nature of these tasks, I would use preliminary definitions like: Edit: Definition outdated, see below. |
According to the scheme I would add tasks headline as a subclasses of Edit: Definition outdated, see below, Removed axiom. |
According to the scheme I would add a method with the task's headline as a subclasses of
This is the one I feel most unsure about. Edit: Definition outdated, see below, removed axiom. Added axiom |
According to the scheme I would add And it would be a subclass of: 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 |
According to the scheme I would add Edit: Definition outdated, see below Added axiom |
Lastly I would add As a subclass of this 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 |
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 |
I see. Logically, this axiom states that any |
The important classes in this model are the subclasses of |
Alright, then I will remove the relations and all axioms that include them. I will update my previous comments accordingly. |
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 |
@stap-m
All of these are also new relations, right? I feel like I also looked at existing relations. Maybe 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 |
As I wrote above, I think they are of rather theoretical value. We don't actually need it. |
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. |
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. |
I'm sorry - I forgot about that previous comment. I remember reading it now... |
How about |
@stap-m |
Now |
I made some new definitions for all the classes. They will likely need changes but they are an improvement over what I used before: |
I think we can specify the domain/range further to either
Ok 👍
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. |
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 |
Yes, sounds reasonable. |
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.
|
|
|
|
|
@stap-m |
Go ahead! 🚀 |
@stap-m I am adding them for now, if only to make implementation more readable for me. I can remove them if they are unwanted. |
There were some missing definitions. I preliminarily defined them as:
|
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. |
We have decided to get the first pull request ready with 3 more questions remaining:
|
Some things that we may want to do for the new module:
|
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 bot better?
|
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. |
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”.
The text was updated successfully, but these errors were encountered: