Fix issue 292: amending for mass spectrometry specific objects, properties and controlled vocabularies

[janlisec]

existing object types amended by new properties:

• INSTRUMENT.MASS.SPEC
• EXPERIMENTAL_STEP.MS_BATCH
  new object types:
• INSTRUMENT.LC_SYSTEM
• INSTRUMENT.GC_SYSTEM
  several new contr.vocab
  !! I removed (outcommented) one existing property (MS_IONIZATION_MODE) to avoid redundancy with a novel property MS_ION_POLARITY -- please check if this causes inconsistencies. If so I would modify the PR and use the old property.

[JosePizarro3]

Hi, thanks for the work, I have some minor comments + 2 larger ones:

1. Maybe it is a good idea to clarify the role of CHROMOGRAPHY_TYPE and the two objects (LC_SYSTEM, GC_SYSTEM) you want to define. It seems this could be better represented by a property of type OBJECT and a common object type called CHROMATOGRAPHY.
2. Would it be a good idea to move MS-specific definitions to its own subfolder, .../datamodel/mass_spectrometry? Similar to what we have in welding/.

[janlisec]

Hi, thanks for the work, I have some minor comments + 2 larger ones:

1. Maybe it is a good idea to clarify the role of CHROMOGRAPHY_TYPE and the two objects (LC_SYSTEM, GC_SYSTEM) you want to define. It seems this could be better represented by a property of type OBJECT and a common object type called CHROMATOGRAPHY.
2. Would it be a good idea to move MS-specific definitions to its own subfolder, .../datamodel/mass_spectrometry? Similar to what we have in welding/.

[1] I would like to upload the device objects of our group so that users can link there measurements to these devices and other groups can see what we have got. We had originally a very broad INSTRUMENT.ANALYTICAL_SYSTEM, got more specific now and also could set up INSTURMENT.CHROMATOGRAPHY as an intermediate solution (but would potentially blow this up with type specific properties in the long run). All solutions have advantages and disadvantages... :/

[2] fine with me, especially when we can expect more specific property sets to appear in the future

--> once you made decisions on the above issues, I would modify the PR accordingly, correct?

[JosePizarro3]

Hi, thanks for the work, I have some minor comments + 2 larger ones:

1. Maybe it is a good idea to clarify the role of CHROMOGRAPHY_TYPE and the two objects (LC_SYSTEM, GC_SYSTEM) you want to define. It seems this could be better represented by a property of type OBJECT and a common object type called CHROMATOGRAPHY.
2. Would it be a good idea to move MS-specific definitions to its own subfolder, .../datamodel/mass_spectrometry? Similar to what we have in welding/.

[1] I would like to upload the device objects of our group so that users can link there measurements to these devices and other groups can see what we have got. We had originally a very broad INSTRUMENT.ANALYTICAL_SYSTEM, got more specific now and also could set up INSTURMENT.CHROMATOGRAPHY as an intermediate solution (but would potentially blow this up with type specific properties in the long run). All solutions have advantages and disadvantages... :/

[2] fine with me, especially when we can expect more specific property sets to appear in the future

--> once you made decisions on the above issues, I would modify the PR accordingly, correct?

Hi @janlisec

Sorry for the delay, I was out on vacation.

[1] What is your opinion? Indeed, controlled vocabularies vs objects is always the question 🙂 so whatever you feel more natural and for longer-term sustainability of the model

I will answer the comments now. Feel free to go resolving the comments when you tackle them. There are a few comments where you didn't comment, so please take a look into these so not to overlook them.

Thanks for the work, Jan, this is looking good, my comments are quite minor fussy details🙂

[janlisec]

I believe I made all changes according to our discussions. Let me know if not. :)

[JosePizarro3]

I believe I made all changes according to our discussions. Let me know if not. :)

Thanks!

I will take a look on Monday or Tuesday, and rebase this branch (it got a bit messy because of other branches I merged). Everything looks good to me.

[JosePizarro3]

Hi @janlisec @caro-demi , check the latest changes:

• I defined you as the CODEOWNERS of the MS model (I can also define only janlisec if you prefer so, as Caro here is giving support, but I'd let you decide)
• I moved the MS-specific definitions to their own subfolder

Once you reply to me, I will merge this and include the changes in openBIS. @caro-demi if you are curious, I can show you how that is done automatically in a quick chat.