[NeXus-committee] obsolescence and evolution: NeXus needs a historic dimension

[Tobias.Richter at diamond.ac.uk]

> -----Original Message-----
> From: Mark Könnecke [mailto:mark.koennecke at psi.ch]
>
> Am 17.07.2014 um 12:43 schrieb <Tobias.Richter at diamond.ac.uk>
> <Tobias.Richter at diamond.ac.uk>:
> 
> > Maybe there is a lesson to be learned from the fact that one of the
> success stories for an application definition does not actually define
> an application at all. Similarly the hard and important parts of
> defining the "application definition" for crystallography are not
> really specific to the technique.
> > I can certainly see value in capturing calibration information in a
> certain way for a particular technique, like in NXtomto. But we find
> here that same method is now used for ptychography.
> > We might be using the wrong basis for our application vector space.
> 
> 
> Please elaborate.

Despite being around for basically ever, application definitions haven't really taken off. 
My idea would be to have something more light weight that isn't an exclusive property of the entry.

Instead of a "definition" field a (for illustration purposes) "tags" string array could contain values like:

"event mode"
"small angle scattering"
"monochromatic beam"
"time series"
"cif geometry"
"imaging corrections"
"scan"
"dichroism"
"crystallography"
"scanning microscopy"
"fluorescence" 
Etc.

Those tags should as much as possible be compatible with each other. Obviously "event mode" and "monochromatic beam" are unlikely to occur together. But rather than prescribing a name for groups ("detector") we'd have tags for saying "I'm the small angle detector" and "I recorded the fluorescence". 

The main advantage is that would allow us to validate some of the content Ray (and we here) use in an ad hoc way at the moment. And an reduction programme could say: I work on "monochromatic beam" NeXus files with "cif geometry", I do not understand "event mode". So you can construct a technique (or analysis programme specific) file definition from smaller components, or base vectors to explain my figure of speech above. For the validation code that would be a fairly straightforward change.

Subentries address a similar problem in some areas without addressing the underlying problem of application definitions.

Admittedly I'm making that up as I write. 

Regards,

Tobias

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom