restructure Matter

[akleinau]

solve the matter problems by creating a "phase_description" bfo:quality and a "PortionOfMatter" bfo:object_aggregate where its subclasses are defined through phase_description.

The individuals gaseous, liquid, plasmatic and solid are instances of phase_description now.

I also added "has_part some Person" as superclass of organisation, this is unrelated but such a small change that I hope it doesnt hurt the readability of this pull request.

Sidenote: These are also the last remaining changes from #50.

[akleinau]

I dont know how common the term "defined class" is. I mean a class where it's members dont have to be explicitely declared but just have to fulfill some requirement like in this case have a specific normal state of matter.
Link

[akleinau]

Solves part of #45

[fabianneuhaus]

I dont know how common the term "defined class" is. I mean a class where it's members dont have to be explicitely declared but just have to fulfill some requirement like in this case have a specific normal state of matter.

There are three different answers to the role of "Defined Classes": a logical, a philosophical, and a ontology engineering answer. (All of which are interconnected.) It's a bit too complicated to put all of this into a ticket. If there is interest, I can meet with you or join a OEO developers meeting and explain it.

[Bachibouzouk]

#45

Do you mean this PR solves this issue? Or you just wanted to reference them?

For the first choice, it is better to edit the PR description and use these keywords in front of the issue number :)

[akleinau]

it partly solves the issue. Is there a keyword for that?

[Bachibouzouk]

it partly solves the issue. Is there a keyword for that?

No, I would just say it explicitly, like "Solves part of #45"

[stap-m]

I guess, 'phase_description' means something equivalent to 'state_of_matter', but there is a definition missing: https://github.com/OpenEnergyPlatform/ontology/wiki/Best-Practice-Principles
Is there a reason why not 'state_of_matter'? This is more precise in my opinion.

"PortionOfMatter" has the wrong definition (state of matter).
Why the subclasses 'PortionOfLiquid' ect? Their 'equivalent_to'-relations are wrong: e.g. in reality a PortionOfGas 'has_current_state_of_matter' gaseous, not necessarily 'normal_state_of_matter'.
Wouldn't it be sufficient to have a structure like this:

• 'water' is_a (direct child of) 'portion_of_matter'
• 'water' has_quality / has_phase / has_state_of_matter 'liquid'
• respectively for other portions of matter

Further, I would like to discuss whether we need the subclass of flourinated gases at all?

[akleinau]

all material entities (apart from flourinated gas) are classified right now as subclasses of EnergyCarrier. So I'll implement the changes of #52 (make EnergyCarrier a disposition) here to preserve the monohierarchy and not leave the matter entities superclass-less between those two changes.

Which leaves the question of the new superclass of those matter entities. I'm reluctant to make for example water a subclass of PortionOfMatter as a portion of water is a PortionOfMatter, not water itself.

[akleinau]

or is water a portion of matter? In the sense of "all the water in the universe" as a subclass of "all the matter in the universe"? I'll make them a direct subclass now of portion of matter to implement #52 as I wrote before

[stap-m]

Thank you.

or is water a portion of matter?

I am not sure about that either. @fabianneuhaus Can you please help with the portion_of_matter issue?

[akleinau]

making EnergyCarrier a disposition to get Air, Fuel and Water to be subclasses of PortionOfMatter raised the question which other subclasses of EnergyCarrier are also not proper subclasses:

• ElectricalEnergy (do we need a new superclass called Energy here?)
• Heat
• Hydropower
• Nuclear (with subclasses Fusion and Fission, aren't they processes and with that bfo:occurent?
• Solar
• SolarEnergy (see ElectricalEnergy)

[akleinau]

So, the remaining subclasses of EnergyCarrier as seen in my last comment and their subclasses are either energy or processes to produce energy. I would separate them into those categories.

Energy - 'bfo: generically dependent continuant' as it depends on a carrier but that carrier can change (but does that energy conserve its identity when it's carrier changes?)

• ElectricalEnergy
• Heat
• SolarEnergy

EnergyProduction - 'bfo:process'

• Hydropower
• Nuclear
• Solar

[Bachibouzouk]

@akleinau - As mentioned in the CONTRIBUTE.md We should merge to dev as soon as possible to avoid potential merge conflicts. I see that you have 3 open PRs (fortunately not with a very large diff on the oeo.omn file). Fortunately also, not many other people are working on the ontology right now. I would suggest that you merge the commits in dev at the end of every working day (note this would be an atypical git workflow). We'll use the issue you'll solve as a place to gather the references to the different PR's. You can also keep the same branch name (ie, no need to delete the branch as long as the issue is not fully closed)

[akleinau]

@Bachibouzouk I got explicitly asked by @MGlauer and @gnn to let my changes undergo a review process before I merge so I‘m in conflict right now.

[Bachibouzouk]

@Bachibouzouk I got explicitly asked by @MGlauer and @gnn to let my changes undergo a review process before I merge so I‘m in conflict right now.

@akleinau - No you're not in conflict :) : I am not giving you the order to merge without asking for a review, I am suggesting we do not let a PR open for too long. Therefore suggesting you should soon ask for someone to review your PR so we can merge it and you can keep working on the issue in a subsequent PR :)

My point is that we should keep each PR as small work packages (all the changes you commit should nevertheless not be dependent of changes to come). For example, it seems to me that the commit 693b450 could perfectly be merged into devregardless of the other commits of this PR.

To recap : @MGlauer and @gnn are right that changes need review before merging and one should merge as often as possible (because all developers will modify oeo.omn and it can create merge conflicts). "As often as possible" is to be evaluated by the developer and the exact time span can vary. For small things it can be hours, for larger ones days. If longer than a week, maybe the work can be spitted in smaller independent packages?

[akleinau]

Then I‘d appreciate some suggestions/ volunteers who can review fast.

[Bachibouzouk]

Then I‘d appreciate some suggestions/ volunteers who can review fast.

@MGlauer , @gnn : who would you design to be abilitated as reviewer for this repo? On the RLI side I could suggest @solar-c and @Izzet91 (both students)

[fabianneuhaus]

@Bachibouzouk @akleinau
I haven't looked at the specific changes Anna is working on. Thus, I am not talking about specifics, but responding in general terms to the following:

I would suggest that you merge the commits in dev at the end of every working day
...
My point is that we should keep each PR as small work packages (all the changes you commit should nevertheless not be dependent of changes to come).
...
If longer than a week, maybe the work can be spitted in smaller independent packages?

I appreciate that your goal to avoid merge conflicts by committing often, but this sounds like a very dangerous strategy, because it would involve merging untested content into dev.

In the ontology world there is no such thing as "local variable" or "encapsulation". Thus, any change you make to an ontology may interact with anything else (via logical inferences). For this reason, if you make significant changes to the structure of an ontology, it is usually not possible to break that down into smaller steps. In my experience you need to finish the task, ensure consistency, and check whether the ontology is able to prove its intended consequences (aka competency questions), and then you make the pull request.

[fabianneuhaus]

Concerning Water. The easy way out -- that I hope you will be able to take -- is to fudge the treatment of mass terms in your ontology. Hence, there is no term for water or wine or wisdom. Instead you only have terms for portions of stuff (a portion of wine, water or wisdom). That does not necessarily mean that the name of the class should be "Portion of Water" but rather that the definition of "Water" should make clear that the instances of this class are portions of stuff. Thus, the ontology does not make a distinction of Water and Portion of Water, but rather treats the label "Water" as the name of the second.

Most of the time that strategy works. If not, we would have to come up with something better.

You probably wonder why I suggest to avoid mass terms at almost all cost: its because they are fiendishly complicated. Its just unclear what the term "water" denotes. In case you are interested: here is a good overview article: https://plato.stanford.edu/entries/logic-massexpress/

[stap-m]

Energy - 'bfo: generically dependent continuant' ...
EnergyProduction - 'bfo:process'

I agree with you @akleinau.
'Nuclear' should be named 'NuclearPower'. Same with 'Solar' (which has already the same definition like 'solarEnergy', so let's just dismiss 'solar'?!). I would also say that Hydropower and NucelarPower are subclasses of Energy.

[stap-m]

Thus, the ontology does not make a distinction of Water and Portion of Water, but rather treats the label "Water" as the name of the second.

Thank you, I think that helps. But are 'PortionOfMatter' and its subclasses bfo:objects or bfo:objectAggregates?

Besides the definitions of the PortionOfMatter-subclasses, we should take a closer look on all of the definitions. Many of them are imprecise at the moment! But maybe in a second step after the restructuring, to get the current PRs into the dev soon.

[akleinau]

Thank you, I think that helps. But are 'PortionOfMatter' and its subclasses bfo:objects or bfo:objectAggregates?

Besides the definitions of the PortionOfMatter-subclasses, we should take a closer look on all of the definitions. Many of them are imprecise at the moment! But maybe in a second step after the restructuring, to get the current PRs into the dev soon.

I implemented the distinction between energy and energyproduction now. PortionOfMatter was classified as bfo:objectAggregate because of #45 (comment)
I think the document is now in a state were merging is possible?

[fabianneuhaus]

Good question. Short answer: it depends, but probably Portion of Matter is a subclass of Object Aggregate.

Let me explain you my reasoning to illustrate how I approach these questions:
We assume that a portion of water is a portion of matter, right? If so, we can consider it as example.

Objects are causally unified and maximally self-connected. A portion of water is not causally unified and not maximally self-connected (e.g., the left half of the portion of water that is currently in my glas is itself a portion of water.) Hence, a portion of water is not an object. Therefore, it follows logically that Portion of Matter is not a subclass of Object.

If you have an entity that consists of a collection of objects and there is nothing interesting to say about the that entity beyond its parts, then it is an object aggregate. E.g., a human consists of a molecules, but we are more than just a collection of molecules. E.g., the spatial arrangement of the molecules is quite important; as are the functional interactions between them. Thus, humans are not object aggregates. In contrast, the portion of water in my glass is just a collection of molecules. There is nothing interesting to know about it beyond that. Hence it is an object aggregate.
This does not answer the question conclusively, but it shows that at least some portions of matter are object aggregates.

I believe that Portion of Matter is a subclass of Object Aggregate. Because, at least in the examples that come to my mind, the "stuff" becomes an object if you look at it on a lower level of granularity. E.g., water is just uncountable "stuff" on a macroscopic scale, but on a microscopic scale it consists of water molecules, which are (a) countable (b) are causally unified and (c) maximally connected. Hence water molecules are objects.

The question is whether there are examples of Object Aggregates that are not Portion of Matter. Intuitively, I would say "no" because a collection of people at a bus stop is an object aggregate, but I would not call this collection "a portion of matter".

Thus, I conclude that Portion of Matter is a proper subclass of Object Aggregate.

However, and that is important: what I formulated above are just my intuitions about the English phrase "Portion of Matter". What oeo:PortionOfMatter will mean depends on the definition in the OEO. And sometimes it is not easy to develop definitions that preserve the intended meanings.

[akleinau]

closes #52

[akleinau]

closes #45

[Bachibouzouk]

@akleinau - I did not indicate it clearly, but the convention I took was to indicate the PR number and not the issue number. In the changelog we want to track what was changed and where and not directly why (why is still accessible via the issue number which everyone should indicate in their PR :))

[Bachibouzouk]

I updated that in #70, so no need to change it for now , just a heads up for the future