FAIRmat-NFDI · lukaspie · Jul 21, 2025 · Jul 18, 2025
diff --git a/...buted_definitions/NXellipsometry.nxdl.xml → applications/NXellipsometry.nxdl.xml b/...buted_definitions/NXellipsometry.nxdl.xml → applications/NXellipsometry.nxdl.xml
@@ -21,22 +21,6 @@
 #
 # For further information, see http://www.nexusformat.org
 -->
-<!--
-04/2024
-A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry.
-09/2024
-TODO (Workshop output):
-- Better categorization of ellipsometer types:
-Separate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense)
-Maybe make a given special field for "spectral_range" with units of eV or nm?
-- Add a StepScanAnalzer as measurement type (continuous/rotating mode the other? Ask Chris)
-- Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization.
-- Refinements for ellipsometer_type and add ellipsometer_method/mode:
-"~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc).
-~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer",  "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer"  "
-- Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions
-Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus.
-This explicitly refers to a wish to add: "exposure time, number of scans"-->
 <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXellipsometry" extends="NXoptical_spectroscopy" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
     <symbols>
         <doc>

diff --git a/...finitions/NXoptical_spectroscopy.nxdl.xml → applications/NXoptical_spectroscopy.nxdl.xml b/...finitions/NXoptical_spectroscopy.nxdl.xml → applications/NXoptical_spectroscopy.nxdl.xml
@@ -22,21 +22,12 @@
 # For further information, see http://www.nexusformat.org
 -->
 <!--
-04/2024
-Extension of the Draft Version (05/2023) of a NeXus application definition which
-serves as a template for various optical spectroscopy experiments
 TODO:
 - Add NXoptical_lens and NXwaveplate to NXinstrument?
-- Make polfilter_TYPE(NXcomponent) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument.
-- Make spectralfilter_TYPE(NXcomponent) own base class -\-> extend NXfilter?  and add them to NXinstrument.
-- Make offset angles for polar and azimuthal?
-- Can angle_reference_frame be replaced later by only using reference_frames and generic angle description?
+- Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument.
+- Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter?  and add them to NXinstrument.
 - Add optical elements and rework them: NXfiber, NXbeam_splitter,
-- Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured?
-- Is there something to describe the spot size?
-- Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?"
-- How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more arbitrary shapes as elliptically? Maybe as well focus spot size?
-- Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed?-->
+-->
 <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXoptical_spectroscopy" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
     <symbols>
         <doc>
@@ -386,14 +377,11 @@ TODO:
                             surface normal)
 
 
-                    A sample normal centered description is as well possible:
+                    A sample normal centered description is possible as well:
                       - angle of incidence (angle between incident beam and sample surface)
                       - angle of detection (angle between detection beam and sample surface)
                       - angle of incident and detection beam
                       - angle of in-plane sample rotation (direction along the sample's surface normal)
-
-                    An arbitrary reference frame can be defined by "reference_frames"
-                    and used via "instrument/angle_sample_and_beam_TYPE"
                 </doc>
                 <enumeration>
                     <item value="beam centered"/>

diff --git a/contributed_definitions/NXraman.nxdl.xml → applications/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml → applications/NXraman.nxdl.xml
@@ -21,30 +21,6 @@
 #
 # For further information, see http://www.nexusformat.org
 -->
-<!--
-N_incident_wavelengths: |
- Number of the incident wavelen
-N_incident_beams: |
- to be done....-->
-<!--
-04/2024
-A draft version of a NeXus application definition for Raman spectroscopy.-->
-<!--
-09/2024
-TODO (Workshop output):
-- Talk with VIBSO people - possible to synchronize raman_experiment_type with this ontology?
-- Similar to ellipsometry: Separate in-situ from resonant/non-resonant stuff: OR maybe allow multiple selections?
-- Shorten raman_experiment_type by removal of Raman_spectroscopy, but as well fix the Raman Reader in the same run
-- Which for more dataconverters: Output from usually Raman setups to neXus format?
-- Spot size description?
-- Description of defocusing / maybe as well as experiment_type?
-
-Wishes for NXraman or general next workshop:
-"convert existing data to NeXus"
-"dictionary lookup keywords/fields in existing formats"(?)
-Template for specific experiments (i.e. too complex to get into NeXus/FAIRdata?) - unclear what to do.
-coorporation with VIBSO ontology?
-dataset examples (i.e. NXdata_raman)-->
 <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXraman" extends="NXoptical_spectroscopy" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
     <symbols>
         <doc>

diff --git a/...ted_definitions/nyaml/NXellipsometry.yaml → applications/nyaml/NXellipsometry.yaml b/...ted_definitions/nyaml/NXellipsometry.yaml → applications/nyaml/NXellipsometry.yaml
@@ -57,22 +57,6 @@ symbols:
     sample.
   N_incident_angles: |
     Number of angles of incidence of the incident beam.
-
-# 04/2024
-# A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry.
-# 09/2024
-# TODO (Workshop output):
-# - Better categorization of ellipsometer types:
-# Separate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense)
-# Maybe make a given special field for "spectral_range" with units of eV or nm?
-# - Add a StepScanAnalzer as measurement type (continuous/rotating mode the other? Ask Chris)
-# - Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization.
-# - Refinements for ellipsometer_type and add ellipsometer_method/mode:
-# "~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc).
-# ~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer",  "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer"  "
-# - Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions
-# Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus.
-# This explicitly refers to a wish to add: "exposure time, number of scans"
 type: group
 NXellipsometry(NXoptical_spectroscopy):
   (NXentry):
@@ -293,7 +277,7 @@ NXellipsometry(NXoptical_spectroscopy):
             Website of the software.
 
 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++
-# ed62540ae1100127dc375d0ba9c12c02afad440ef2a38f723704cebb398facd8
+# 439c6e2ace0f16356ed2af0b01104ee3c32601f1496bdccd29c90c8f266796e9
 # <?xml version="1.0" encoding="UTF-8"?>
 # <?xml-stylesheet type="text/xsl" href="nxdlformat.xsl"?>
 # <!--
@@ -317,22 +301,6 @@ NXellipsometry(NXoptical_spectroscopy):
 # #
 # # For further information, see http://www.nexusformat.org
 # -->
-# <!--
-# 04/2024
-# A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry.
-# 09/2024
-# TODO (Workshop output):
-# - Better categorization of ellipsometer types:
-# Separate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense)
-# Maybe make a given special field for "spectral_range" with units of eV or nm?
-# - Add a StepScanAnalzer as measurement type (continuous/rotating mode the other? Ask Chris)
-# - Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization.
-# - Refinements for ellipsometer_type and add ellipsometer_method/mode:
-# "~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc).
-# ~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer",  "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer"  "
-# - Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions
-# Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus.
-# This explicitly refers to a wish to add: "exposure time, number of scans"-->
 # <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXellipsometry" extends="NXoptical_spectroscopy" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
 #     <symbols>
 #         <doc>

diff --git a/...nitions/nyaml/NXoptical_spectroscopy.yaml → ...cations/nyaml/NXoptical_spectroscopy.yaml b/...nitions/nyaml/NXoptical_spectroscopy.yaml → ...cations/nyaml/NXoptical_spectroscopy.yaml
@@ -23,21 +23,11 @@ symbols:
     was performed at three different temperatures and two different pressures
     N_measurements = 2*3 = 6.
 
-# 04/2024
-# Extension of the Draft Version (05/2023) of a NeXus application definition which
-# serves as a template for various optical spectroscopy experiments
 # TODO:
 # - Add NXoptical_lens and NXwaveplate to NXinstrument?
-# - Make polfilter_TYPE(NXcomponent) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument.
-# - Make spectralfilter_TYPE(NXcomponent) own base class -\-> extend NXfilter?  and add them to NXinstrument.
-# - Make offset angles for polar and azimuthal?
-# - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description?
+# - Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument.
+# - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter?  and add them to NXinstrument.
 # - Add optical elements and rework them: NXfiber, NXbeam_splitter,
-# - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured?
-# - Is there something to describe the spot size?
-# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?"
-# - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more arbitrary shapes as elliptically? Maybe as well focus spot size?
-# - Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed?
 type: group
 NXoptical_spectroscopy(NXobject):
   (NXentry):
@@ -293,14 +283,11 @@ NXoptical_spectroscopy(NXobject):
                   surface normal)
 
 
-          A sample normal centered description is as well possible:
+          A sample normal centered description is possible as well:
             - angle of incidence (angle between incident beam and sample surface)
             - angle of detection (angle between detection beam and sample surface)
             - angle of incident and detection beam
             - angle of in-plane sample rotation (direction along the sample's surface normal)
-
-          An arbitrary reference frame can be defined by "reference_frames"
-          and used via "instrument/angle_sample_and_beam_TYPE"
         enumeration: [beam centered, sample-normal centered]
       omega(NX_NUMBER):
         exists: optional
@@ -873,7 +860,7 @@ NXoptical_spectroscopy(NXobject):
           \@version:
 
 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++
-# a80446e818774501708ee6369d01b2af414a8aecd636c635a53e51a9e636e6c2
+# 2abaa11cec0a6ef98c266f2a2cf663d712ba684932dae831b3e2ad3d53ac1027
 # <?xml version="1.0" encoding="UTF-8"?>
 # <?xml-stylesheet type="text/xsl" href="nxdlformat.xsl"?>
 # <!--
@@ -898,21 +885,12 @@ NXoptical_spectroscopy(NXobject):
 # # For further information, see http://www.nexusformat.org
 # -->
 # <!--
-# 04/2024
-# Extension of the Draft Version (05/2023) of a NeXus application definition which
-# serves as a template for various optical spectroscopy experiments
 # TODO:
 # - Add NXoptical_lens and NXwaveplate to NXinstrument?
-# - Make polfilter_TYPE(NXcomponent) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument.
-# - Make spectralfilter_TYPE(NXcomponent) own base class -\-> extend NXfilter?  and add them to NXinstrument.
-# - Make offset angles for polar and azimuthal?
-# - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description?
+# - Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument.
+# - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter?  and add them to NXinstrument.
 # - Add optical elements and rework them: NXfiber, NXbeam_splitter,
-# - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured?
-# - Is there something to describe the spot size?
-# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?"
-# - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more arbitrary shapes as elliptically? Maybe as well focus spot size?
-# - Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed?-->
+# -->
 # <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXoptical_spectroscopy" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
 #     <symbols>
 #         <doc>
@@ -1262,14 +1240,11 @@ NXoptical_spectroscopy(NXobject):
 #                             surface normal)
 #                     
 #                     
-#                     A sample normal centered description is as well possible:
+#                     A sample normal centered description is possible as well:
 #                       - angle of incidence (angle between incident beam and sample surface)
 #                       - angle of detection (angle between detection beam and sample surface)
 #                       - angle of incident and detection beam
 #                       - angle of in-plane sample rotation (direction along the sample's surface normal)
-#                     
-#                     An arbitrary reference frame can be defined by "reference_frames"
-#                     and used via "instrument/angle_sample_and_beam_TYPE"
 #                 </doc>
 #                 <enumeration>
 #                     <item value="beam centered"/>