ontology
ontology copied to clipboard
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
true
andfalse
even 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.