Telco 20230119

Date

Thursday, 19nd January, 15:00 UTC

Connect

• ZOOM VC link: https://hu-berlin.zoom.us/j/65272091306?pwd=WUxEa0ZtVXp1ZHlsSlVjU2lmclMrQT09
• Meeting ID: 652 7209 1306
• Passcode: nexus

Agenda

• XPCS Community Discussion
• Ontology
• Recent issues on Github (especially those labelled with “telco”)
  • definitions
  • code

Present

AB, SB PC, PJ, SN, BB, BW, CZ, HG, JW, LG, PM, WdN, AndiBarbour

Minutes

• XPCS: https://github.com/nexusformat/definitions/issues/1007
  Fundamental problem:
  Let us have 2 optional fields. How to express in NeXus that at least one of them should be provided? Another discussion was also initiated on this topic (see also, and also) showing how it can be solved by using the constract “choice”. Another suggestion was to allow logical expressions on cardinality (optional/required/minOccurs/maxOccurs), similar to that of suggested for symbol tables.
  For the moment, the suggestion is:
  1) leave both fields optional
  2) use docstrinng to explain the optional/required condition, and 3) use an enums field where it can be chose which data field is provided
  An example for this:
  NXmx/ENTRY/INSTRUMENT/BEAM/flux-attribute: enum choices

  This can be useful solution also for NXxpcs/ENTRY/data/g2-field
  One should use a list of defined enum keys (or apply “open enumeration” with adding the new enum key to the defined list in contributed case ASAP.
  new Issue on: evaluating the use of ‘union’ in NXDL (https://github.com/nexusformat/definitions/issues/1232)

• For issue 1004
  Note that the already connected discussions clarified the scopes:
  scan number (deprecated): e.g. spec (no unique ID)
  entry_identifier( required): external ID
  entry_identifier_uuid (optional): unique ID

• For issue 1005 and 1006
  nothing to discuss here.

• Ontology v2
  Discussions started on the PR for v2, but also questions popped up which require clarifications.
  Issues shall be created for them:
• Same names for different type of children of the same(?) concept (Definition/Group/Field)
  NXentry/thumbnail/type-attribute is defined in NXentry, but NXentry/thumbnail-group is referencing NXnote where NXnote/type-field is already defined (for the same purpose). Note that a machine can easily distinguish between them and the NeXus Vocabulary is already prepared for handling such cases by using a clarification postfix (as above), but are they intentionally implement two separated concepts under the same name?
  Should it be really supported?
  Similar, but intentional:
  NXentry/SAMPLE/sample_histrory-group may be defined as NXnote for a generic use, but NXellipsometry/ENTRY/SAMPLE/sample_hisotry-filed may be defined as NX_CHAR for simplicity.
  Is it OK?
  Note another intentional, but controversial use case: The NeXus convention on scanning says that a Field of an NX_NUMBER dataset can be replaced by an NXlog Group with the same name if the values supposed to be stored with timestamps. What happens if this group name is already defined as another concept, so the application of a generic concept leads to a contradiction?

  Normally, it is acceptable to have the same (short) name for different concepts, because they are uniquely identifieable by their (suffixed) full vocabulary name.
  Specifically, for the first example see also:
  Depricate and Rename: NXnote/type-field to NXnote/mime_type-field
  Depricate: NXentry/thumbnail/type-attribute and use NXentry/thumbnail/mime_type-field instead
  PR 396 to discuss it further

• regexp enumerations
  NXentry/thumbnail/type-attribute is defined with the “Obligatory value: image/”. Does it mean that it always has to be literaly “image/” or it only means that its actual value shall start with “image/“?
  Is it really an enumeration?
  Shall we enable a regexp as enumeration?

  currently - enums only allow exact match
  Note that the current implementation is not as intended. see the xml file future: maybe the use of assert or something else

• number enumerations
  In some case enumeration refers to numbers (e.g. NXguide/reflectivity/[surface,wavelength]_indices), but because of enumeration, their data type had to be forced to be NX_CHAR. Although they are now overriding the data type of the referenced(?) concept NXdata/AXISNAME_indices-attribute which is defined as NX_INT.
  Note that NXdetector/time_of_flight/axis-attribute (with enumeration value of “3”) is defined as NX_POSINT.
  Shall it be the way to go and allow enumeration for other data types, too, although their string value is given in the nxdl definition?

• default unit category
  In some cases our definitions do not specify a unit category (e.g. NXdetector/detector_number-field of NX_INT, NXdetector/bit_depth_readout-field of NX_INT, or even NXcapillary/focal_size-field of NX_FLOAT).
  If it is only for convenience, Is there a fallback solution of a default value, like NX_ANY or NX_UNITLESS? The later does apply neither to NXdetector/bit_depth_readout-field, nor to NXcapillary/focal_size-field.

  Or if the given concept (Group/Field/Attribute) is referring to another one (e.g. from a base class as NXmonopd/MONITOR/preset of NX_FLOAT referring to the same(?) concept NXmonitor/preset of NX_NUMBER units=NX_ANY) shall it receive a default unit category, or shall it simply inherit the already defined unit category from the referred concept?

• complex unit categories
  NeXus has already complex unit categories, like NX_MASS_DENSITY, NX_MOLECULAR_WEIGHT, NX_PER_AREA, NX_PER_LENGTH, NX_WAVENUMBER, etc. but others can also be derived using the Unidata’s Udunits convention (see also https://www.unidata.ucar.edu/software/udunits/udunits-2.2.28/udunits2.html). Is there a way to refer to such units or unit categories?
  Is it planed to introduce NX_UDUNITS as unit category, so one can use derived unints according?
  Or is it possible to supply a Udunits derivation as a unit category(!) (e.g. units=”m/s”), so any compatible units, like “km/h” could be used?

• units= vs. units=
  As an xml tag, units= is used by NXDL to specify unit categories for Fields. units= on the other hand can be used by application definitions to specify enumeration for the dataset attribute @units which specify the actual unit of the data.
  It is at least confusing in NeXus that both a unit category specification and a specific unit in a data file use the same plural form “units”.
  Was it ever discussed?
  Should not it be made clear: “units” for unit categories, and “unit” for the actual unit?

ZOOM Chat:

• Wout De Nolf (ESRF) to Everyone (19. Jan 2023, 16:09)
  Here is the link for the field: https://github.com/nexusformat/definitions/blob/9729b2488acc33aebe53f1865fa6c20615e31be0/base_classes/NXnote.nxdl.xml#L41
• Benjamin Watts to Everyone (19. Jan 2023, 16:17)
  the @type was renamed from @mime_type due to issue #395 https://github.com/nexusformat/definitions/issues/395 PeterC had noticed the mistake that we are discussing now, but Tobias misunderstood the issue and didn’t make a good fix
• Pete Jemian to Everyone (19. Jan 2023, 16:28)
  starts with “image/” validItemType (in the nxdl.xsd file) is a regex Paul Millar to Everyone (19. Jan 2023, 16:30) MIME type is structured, like type “/” subtype [”+” suffix] *[”;” parameter] Therefore, this constraint is really: has type “image”
• Pete Jemian to Everyone (19. Jan 2023, 16:32)
  This becomes an issue to define clearly how to describe in NXDL. We intend to match a pattern that starts with “image/”. Let’s build the issue on that. and move on from here today.
• Pete Jemian to Everyone (19. Jan 2023, 16:39)
  XML Schema “assert” seems to be a XML v1.1 feature. We use v1.0 so this would be a fundamental change. https://stackoverflow.com/questions/15573894/xml-schema-1-1-not-recognizing-assert-or-assertion NXcanSAS has a structure which is either Q as vector or Q as scalar. https://manual.nexusformat.org/classes/applications/NXcanSAS.html#nxcansas-entry-data-q-field Wout De Nolf (ESRF) to Everyone (19. Jan 2023, 16:42) https://manual.nexusformat.org/classes/applications/NXmx.html#nxmx-entry-instrument-beam-flux-attribute @flux can have “flux”, “total_flux”, “flux_integrated”, or “total_flux_integrated”. all these are optional fields
• Aaron Brewster to Everyone (19. Jan 2023, 16:45)
  I have to start walking to my next meeting but I’ll be listening in on my phone
• Balazs Bago to Everyone (19. Jan 2023, 16:48)
  I have to leave, Good Bye!
• Luca Gelisio (EuXFEL) to Everyone (19. Jan 2023, 16:49)
  Dumb question: What about ‘other’? The other two formats are well defined, but this?
• Paul Millar to Everyone (19. Jan 2023, 16:58)
  Heike, we can organise a meeting of XPCS people. There’s certainly multiple RIs interested in XPCS within DAPHNE.
• iPhone t (19. Jan 2023, 17:01)
  Gotta go. @sandor you may want to save the chat log to help with the minutes. Thanks all
• Luca Gelisio (EuXFEL) to Everyone (19. Jan 2023, 17:03)
  I agree with Sandor.
• Paul Millar to Everyone (19. Jan 2023, 17:03)
  +1 Sandor Alternatively, allow an open enumeration Suresh Narayanan to Everyone (19. Jan 2023, 17:05) Have to go now

Fabruary Telco

Please help to choose the date by responding to the poll by January 30th. We are planning to hold the telco in the regular slot of UTC 15:00. Check your local time to avoid scheduling surprises!