Harmonize raman spectroscopy with obi assay pattern

[StroemPhi]

This PR is associated with #103 in that it provides a basis for further differentiation of the subtypes of Raman spectroscopy.
It defines two new subclasses of CHMO:Raman spectroscopy and injects subclassOf axioms to it that are in line with the OBI assay pattern by defining its main input and output. In doing so, this PR also defines the process Raman Scatting and its disjoint children (Stoke & anti-Stokes Raman scattering) based on the ISO 18115 specs which are used within the asserted subclassOf axioms.

Details:

• CHMO:Raman spectroscopy

  • injected subclassOf axioms:

    has_specified_input some 
        ('material entity'
         and ('has role' some 'evaluant role')
         and ('causal agent in process' some 'Raman scattering'))
    has_specified_output some 
        ('data item'
         and (('is about' some 
            ('material entity'
             and ('has role' some 'evaluant role')
             and ('causal agent in process' some 'Raman scattering')))
         and ('is about' some 
            ('Raman scattering'
             and ('process has causal agent' some 
                ('material entity'
                 and ('has role' some 'evaluant role')))))))
    

• 'anti-Stokes Raman Spectroscopy'

  • definition: A Raman spectroscopy that has the objective to focus only on the detection of anti-Stokes Raman scattering.
  • subclassOf axioms:

    has_specified_input some 
        ('material entity'
         and ('has role' some 'evaluant role')
         and ('causal agent in process' some 'anti-Stokes Raman scattering'))
    has_specified_output some 
        ('measurement datum'
         and ('is about' some 
            ('material entity'
             and ('has role' some 'evaluant role')
             and ('causal agent in process' some 'anti-Stokes Raman scattering')))
         and ('is about' some 
            ('anti-Stokes Raman scattering'
             and ('process has causal agent' some 
                ('material entity'
                 and ('has role' some 'evaluant role'))))))
    

• 'Stokes Raman Spectroscopy'

  • definition: A Raman spectroscopy that has the objective to focus only on the detection of Stokes Raman scattering.
  • subclassOf axioms:with the subclassOf axioms:

    has_specified_input some 
        ('material entity'
         and ('has role' some 'evaluant role')
         and ('causal agent in process' some 'Stokes Raman scattering'))
    has_specified_output some 
        ('measurement datum'
         and ('is about' some 
            ('material entity'
             and ('has role' some 'evaluant role')
             and ('causal agent in process' some 'Stokes Raman scattering')))
         and ('is about' some 
            ('Stokes Raman scattering'
             and ('process has causal agent' some 
                ('material entity'
                 and ('has role' some 'evaluant role'))))))
    

This PR also fixes a typo in the definition of Raman raw data.

[StroemPhi]

I'm wondering if we need to add also subclassOf axioms that specify the input of Stokes & anti-Stokes Raman spectroscopy in terms of the evaluated material entity causing a Stokes scattering respectively an anti-Stokes scattering, e.g.

has_specified_input some 
    ('material entity'
     and ('has role' some 'evaluant role')
     and ('causal agent in process' some 'anti-Stokes Raman scattering'))

From the parent we inherit that it must be causing a Raman scattering and I feel like this is enough, as the focus of the differentia criteria for these two sub-classes is more on the output and not the input.

[Zack-83]

The right panel is somehow readable for someone who understands OWL. But yet the definition looks too complex. "Raman scattering" and "Raman spectroscopy" are really too far from each other. In my opinion, we should introduce once an object property "technique implements phenomenon" and then include in it all restrictions.

The left panel does not help at all, sorry. Apparently such a graphical representation is not adapt to capture che complexity of multiple restrictions defined through unnamed nodes. So better leave it away, or replace it with something less picky but more understandable.

[StroemPhi]

Regarding the right panel comment:
While I agree that it looks complicated for someone not versed in OWL, this proposal follows the OBI pattern (see also: https://nfdi4chem.github.io/VibrationalSpectroscopyOntology/design_patterns/#defining-an-assay-according-to-the-obi-core-assay-pattern) and since CHMO is an OBI extentsion and VIBSO is planned as a CHMO extention, we must follow the design patterns of OBI.

But this doesn't mean I'm objecting to defining such an object property to make things easier for those kinds of assays that can be defined as methods that cause and detect a natural process (effect). As written in the notes of our last dev call importing SSN:detects won't be suitable for this. To be in line with OBO a possible parent for such a property could be RO:causally upstream of or within, which connects two causally related processes.

However, we still would want to have axioms that specify what kind of input and output such an assay has. Hence, formalizing that the evaluated material entity in such an assay is the cause of the detected natural effect seems important to me. To reduce the complexity on that part, we could define for example a "Raman spectroscopy evaluant" class as a

('material entity'
     and ('has role' some ('evaluant role' and ('realized in' some 'Raman spectroscopy'))
     and ('causal agent in process' some 'Stokes Raman scattering'))

and then just assert on Raman spectroscopy: has_specified_input some 'Raman spectroscopy evaluant'.

And we could do so similarly for the data item produced by a Raman spectroscopy, which we might want to label "Raman spectral data" and which would serve as parent for all types of data outputs of Raman spectroscopies, the unprocessed ones, like "Raman raw data", as well as the ones produced by a post-processing step, such as the plot of the spectrum.

Regarding the left panel comment:
I don't get what you mean. It is of course a reduction, but it contains as nodes and edges all asserted and inherited axioms of Raman spectroscopy. Hence it was only meant to illustrate the pattern, which imho makes it easier to see the similarities/closeness to the OBI:assay pattern.

[StroemPhi]

How about using as direct relation between Raman spectroscopy and the Raman scattering it detects RO:regulates?
It is defined as a causal relation between processes:

p regulates q iff p is causally upstream of q, the execution of p is not constant and varies according to specific conditions, and p influences the rate or magnitude of execution of q due to an effect either on some enabler of q or some enabler of a part of q.

So we could assert the subclassOf axiom:

'scattering spectroscopy' and (regulates some 'Raman scattering')

[Zack-83]

We never defined the main term "Raman spetroscopy", by the way. Is the definition in CHMO also so structured and axiomatic? I think it is legitimate to include in VIBSO external terms with minor changes, as long as we document them - at least, so far we did like that (example: https://git.rwth-aachen.de/nfdi4ing/metadata4ing/metadata4ing/-/blob/develop/metadata4ing.ttl?ref_type=heads#L306)

[StroemPhi]

We never defined 'Raman spetroscopy', as we import it from CHMO. This PR changes (improves) its semantics by injecting subclassOf axioms on it as laid out above, which should be asserted in CHMO. These injections are annotated with comments for the provenance like this:

Once we've got #103 worked out we need to see how we can get such injected axioms into CHMO, so this is more meant only as a temporary fix.

The difference to the way we define native VIBSO classes is the fact that we do the axiom injection in vibso-edit.owl, as we wouldn't want to redeclare existing classes in our TSV.

[StroemPhi]

Thanks for catching the typo in 3d4307d! I made the mistake of merging PR #124 without letting you approve it first. Will need to stop doing this, sorry.
But it has to be fixed in the TSV from which this OWL is generated using the sh run.sh make recreate-vibso_classes command in the ODK cmd line. I did this in e245fbe.