Restructuring individuals: boolean variable
Description of the issue
As described in https://github.com/OpenEnergyPlatform/ontology/issues/859 most of the individuals in the OEO are lacking a definition. In addition the upper classes are evaluated again.
Ideas of solution
| Type | Individual | Definition |
|---|---|---|
| boolean variable | false | False is a boolean variable which is intended to represent the truth value false (denoted by 0, by -, the falsum ⊥, or falsch (F) in German). |
| boolean variable | true | True is a boolean variable which is intended to represent the truth value true (denoted by 1, by +, the verum ⊤, or wahr (W) in German). |
l-emele commented yesterday:
The individuals true and false are fine to me.
Workflow checklist
- [x] I discussed the issue with someone else than me before working on a solution
- [x] I already read the latest version of the workflow for this repository
- [x] The goal of this ontology is clear to me
I am aware that
- [x] every entry in the ontology should have a definition
- [x] classes should arise from concepts rather than from words
I don't know why we need this issue, if we already found an agreement.
Mainly I created this issue for documentation. But I have minor improvements for the definitions and perhaps we need to discuss further aspects.
False is a Boolean variable which is intended to represent the truth value false, which means it is not true. It is denoted by 0, by -, the falsum ⊥, or in German falsch, FALSCH, or F.
True is a Boolean variable which is intended to represent the truth value true, which means it is right. It is denoted by 1, by +, the verum ⊤, or in German wahr, WAHR, or W.
One thumbs up and no further comment for more than a month, so I think this is ready to implement.
I would implement this as a first ticket. I couldn't find the individuals in a module. So I wanted to verify that I would do the change in the oeo.omn. Happy for your feedback.
@rue-l did you pull from the dev branch recently? The last PR added the annotation "belongs to module". boolean variable and its instances belong to oeo-model.
Looking again on this issue: Are true and false even instances/individuals of a boolean variable? Aren't these rather values of a boolean variable?
@OpenEnergyPlatform/oeo-general-expert-formal-ontology : Any thoughts on the question posed in my last comment?
Looking again on this issue: Are
trueandfalseeven instances/individuals of a boolean variable? Aren't these rather values of a boolean variable?
@fabianneuhaus : Any thoughts on this question?
OEO dev 44: The "most philosophic question" what is "true" => @fabianneuhaus will have a look on this
@fabianneuhaus : Any updates on this true/false question?
No further comments here fore a while. So here a proposal how to solve this.
We could distinguish between a boolean variable and a boolean value:
-
A boolean ~variable~ value is an ~variable~ information content entity that can only be true or false. (Alternative term maybe
truth value?) - A boolean variable is a variable that represents a boolean value.
And then make true and false instances of that boolean value:
- False is a boolean ~variable~ value which is intended to represent the truth value false (denoted by 0, by -, the falsum ⊥, or falsch (F) in German).
- True is a boolean ~variable~ value which is intended to represent the truth value true (denoted by 1, by +, the verum ⊤, or wahr (W) in German).
And of course, true and false should be explicitly axiomatised as being different.
This probably is not the perfect solution from a pure philosophical standpoint. But in my view it would be a viable solution to solve this longstanding issue. If at a later stage, this solution does show problems, we can discuss this again.
@stap-m @fabianneuhaus : In my last comment I proposed a potential solution regarding true and false. It is not perfect, but maybe at least good enough to move forward. What do you think about the proposal in my last comment?
Moved to next release 1.14.0
@stap-m : Please give a feedback whether my proposal in my comment above is a viable interim solution.
I am fine with your proposal as temporal solution.
Great! Then I will take over PR #1255 and implement this there.