Telco 20260211

Date

Wednesday, 11th Feb, 15:00 UTC

Connect

Agenda

  • NeXus Ontology update

  • Release

Present

SB, WdN, BW, PC, FdA, FS, HG, RB, TC, RO, ZM - MarkusK, LukasP (FAIRmat)

Minutes

  • NXxas_new

    • WdN: presented the current status, and the problem of having too many different measurement modes with their respective speficities

    • BW: proposed based classes show a good direction

    • MK: NXelement, NXedge might use already accepted base classes, like NXpeak. What about covering EELS? Do we need to harmonize with EELS used in EM?

    • BW: at the stage of contribution, it might be just enough to enable the community. Harmoinisation may come as a next step, but the priority is enabling the community.

    • TC: All kinds of different instrumentation may require different parameters. Instead of having only a generic description, we may want to allow optional emelements and base classes capturing all specific.

    • WdN: more and more hdf5 is used and so NXxas is long waited now, but the proposal has not been finalised. Any contribution is welcome. Still the question is shall we use different base classes for modes or extend a common AppDef.

    • Suggestion from the Telco: 1. extend application definitions from NXxas 2. use base classes as modes in NXxas 1: 6 2: 5 1 or 2: 3 SB: It is clear 50-50 situation, so both directions seems to be OK and acceptable.

    • HG: option 1 also allows easi connection to PaNET ontology.

  • Patch release

    • PC: revoew of the status

    • SB: 2 PRs need vote. During the Telco required votes were provided. Both PRs got accepted with 14 votes.

    • RO: What is the information on PR #1561

      • SB: AB expected example be included, but in Jan it was not provided, so this PR was not pushed any further

      • RO: instead of a full and proper NXtransformation, it can be enough to record the angles only. The PR is addressing this use case.

      • PC: NXmx uses NXtransformations to register the actual rotations and trsnalations

      • RO: sometimes the full setup is not (or not properly) known.

      • SB: an assumption for being able to interpret properly the rotation angle needs to know the rotation axis. NXtransfotrmation registers both axis and angle as a starting point for data analysis

      • RO: there are always mistakes in the data and conventions are good to understand where to start the refinements.

      • BW: NeXus Constructer from ESS could be a good tool for setting up a model of the beamline for NeXus

      • TC: if motor positions are registered anyway somewhere what does NXgoniometer adds if the angles are not interpretable better than in those other places.

      • RO: Indeed, the use of NXcollection could have been another option instead of using NXgoniometer, problem that NXcollection is not meant to be well-defined for machine reading.

      • WdN: why not NXmotors? (SB: NXactuator is already existing for this purpose)

      • RO: Indeed, it could be. It is nice to have a reference to paper where the motor conventions are described.

      • BW: Why not adding it to an NXnote?

      • RO: it could be used like this, but it may result a too loose connection between the goniometer angle and the convention in which it was used. If there is any problem, it is more difficult to find where it is coming from if a whole chain of transformations needs to be investigated.

      • SB: We may need to demonstrate the use NXtransofmreation, so Ray can better point out what he is lacking in it

      • RO: angles are registered anyway, but they might also be put separately to NXtransformation. NXgoniometer would allow the users to know where to start looking for goniometer positions. Such a middle ground could also be viable.

      • WdN: Would a DOI in NXtransformation would help?

      • SB: we support it already. IDENTIFIER is available in every group.

      • RO: problem is that transformation chains in NXtransformation is difficult to decouple and understand what belongs is what. E.g what is

      • PC: NXgoniometer is a fixed set of pareameters, it is very similar to NXtransoformation. Transformations of different elements shall not be necessarily mixed.

      • RO: writing NXtransformation requires more entry to be written, which makes its use uncomfortable.

      • SB: we could organise a demo where NXtransformation and its use is demonstrated. It shall cover simple use cases, like goniometer motors, and allow questions about its practical usability.

      • RO: Sure, an example would help to clarify if and what is missing compared to the proposed NXgoniometer.

  • NeXus Ontology

    • HG: we are moving from purl to w3id.

    • SB: we need a contact person. Any nominations? If not, I nominate HG.

    • WdN: +1

    • HG: accepted the nomination

    • SB: AB can then start a vote.

    • MK: In w3id, we should name our ontology: ‘NeXus’.

  • NIAC 2026 meeting

    • FdA: organisation has been started as a sattelite to NOBUGS on Sep 25-27, 2026.

March Telco

Please help to choose the date by responding to the poll by Feb 20.

We are planning to hold the telco in the regular slot of UTC 15:00. Check your local time to avoid scheduling surprises!