let's make solution preparation

[aalbino2]

Hi guys @RoteKekse @hampusnasstrom

after checking Micha's classes, I firmly believe we can share a common ground of classes, at least these: Solution, SolutionPreparation, SolutionWasching, SolutionProperties, SolutionStorage

Why? Because - together to underlying semantics - if we can share a common ground of classes, this is even more fair than sharing only a semantics that one then have to figure out across someone else's schema

We may have a brief very practical meeting on these ideas, if you would feel like that

[aalbino2]

I pin here the repos:

https://github.com/nomad-hzb/nomad-baseclasses/blob/main/baseclasses/solution.py https://github.com/nomad-hzb/nomad-baseclasses/blob/main/baseclasses/mxene_solution.py

[RoteKekse]

I think it is great if nomad has baseclasses for this out of the box, but i am not sure if i would use them, because for me it is easier and more flexible if i have full control on these schemas on this detail level.

I am ok though with having a common results section which can then be used to populate the data for solutions. so that the data is interoperable in nomad.

[aalbino2]

I just copy-pasted your classes so far. So it would be just a matter from your side of inheriting them instead of having them in your code

[RoteKekse]

yes even if they are exactly the same, i am not sure if this is good. it has been very beneficial if we can just start developing schemas to our needs and then by semantic annotation later make the data fairer

being dependent with the schemas does not fell like an advantages. it just adds coordination and therefore complexity

[RoteKekse]

is it clear what i mean?

[aalbino2]

basically I understand but I substantially do not agree

It is only sharing classes that we can build common tools on top of data structures, make wider queries in the future, and so on

[aalbino2]

We foresee to arrive at a plateau with data modeling, not keeping changing things, so it means these part of data model will be more and more steady the more we go on in the future. Also it is such an easy part of data modeling this "solution" one...

[RoteKekse]

For nomad can’t this just happen in the results section?

[aalbino2]

cmon a pure substance weight and a concentration shouldn't be so important to throw them in results, at least IMO, or to make results busy with that, and at the end of the day we would still end up sharing some classes, just not in data but in results section,

and results would need to be extended to host these quantities, or something already exists there?

[RoteKekse]

Yes extending it would be the idea. I mean you can develop basesections but I think using them neither means the data is fairer or less fair as long as it is annotated. So using them should be left to the local labs if it is helpful or not for them.

[RoteKekse]

Maybe sometimes use them and sometimes don’t . That shouldn’t impact the fairness.

[aalbino2]

It does impact it.. necessarily! Unless you have implemented some other software figuring out the similarities between two schemas retrieving their annotation and then connecting to a reasoner going through the ontology

Thank you for discussion. I'm sorry you don't wanna approach this route. Let's see what happens with time

[aalbino2]

I added the solution classes in PR #144 together to other work.

[RoteKekse]

Sry. I just try to not repeat the issues nexus has

[aalbino2]

That is?

[RoteKekse]

That it has a static structure