Wednesday, 24th August, 15:00 UTC
BW, CZ, WdN, AB, SB, PJ, TM, HB
SB asks about combining multiple eexperiments and processes together. BW replies that this is what NXentry is designed to accomplish. Maybe using separate files for each experiment and then have a master file to link them together. HB says that this is getting dangerous and the reason why UML was invented. Take the Java inheritance model and stick to that. SB asks about implementing sample IDs BW remembers there being something already in about UUIDs. PJ says that BlueSky uses UUIDs for each measurement, but it could easily be extended to IDs for anything else. Can be useful for tracing issues, such as using detector serial numbers to find correlations of hardware with bad results. AB says that UUIDs are 16-digit values so it might not be practical in some cases.
SB asks about NXgeometry, which is deprecated in favour of NXtransformations. NXgeometry seems like it would be useful to describe shapes, which NXtransformation doesn’t do. PJ says it would be good to ask on the mailing list
SB discusses the NeXus ontology. The ontology is currently flattening everything and doesn’t describe any inheritance. Extension terms from the ADefs are back-ported to the base classes, which makes them huge. The flattening then causes the terms from the ADefs lose some context. Instead of flattening the ontology, we could create further entities to make a more heirarchal ontology. PJ would like to see this as a PR and github issue to that others can see the discussion.
SB says that he has never seen NXint32 being used. PJ suggests that it might be from back in the HDF4 days. BW says that MK probably knows more detail. SB asks if it is appropriate for NeXus to be getting into the representation of the numbers that make up the data. PJ says that this is an artefact of NeXus being strongly coupled to HDF5 and whatever backends we support. AB reminds us that there is some interest in XML/NeXus, especially from people wanting to keep crystallography data in text-based databases. BW says that NeXus is tied by our limited resources - we have no philosophical objection to further container formats, but we lack resources to support enough tools to make further container formats “official”. SB had heard of wishes for formats like JSON or YAML. PJ replies that the issue is being able to express attributes in such formats - we would need to make some adhoc way to extend the format. BW my experience is that people wanting to be able to inspect data files with text editors have very simple files. Once NeXus starts adding lots of metadata, those files start looking much more messy and not so attractive any more.
AB asks if the NIAC will be online? BW replies that it is hybrid so people can join in person or online. BW encourages everyone to register (even if joining online) so that he can have advanced notice of what resources are needed.
AB points out a feature in ImageCIF called “equipment_component” that he has been using in NXmx that he had assumed might be generally in NeXus already, but it looks like it isn’t. Is it useful for others? PJ says “yes” and gives an example with defining the geometry of an ad hoc diffractometer. AB says that DIALS produces a detector model that is heirarchical, so that you get a set of transformations for each component. AB will write it up so that it can be discussed in the NIAC.
AB talked about the estimated time at the ACA meeting and there was strong agreement the fields should be kept as “required”. SB had similar issues that it would be useful to have something between “required” and “optional”, namely “reccommended”. “reccommended” would be be treated as “optional” by a validator, except that it would give a warning if missing.
Since we have the NIAC in mid-September, BW will run a poll for a next telco in October.