[NeXus-tech] A motivation for variants as fields

[Wintersberger, Eugen]

Hi folks
  I was thinking a bit about our discussion on variants and indeed I
found a use case for variants for HXRD (high resolution x-ray
diffraction) where variants as fields would make sense. 

What one is typically doing in HXRD is measuring specular scane
(detector_polar_angle = 2*sample_polar_angle). No matter how good you
align you experiment both angles are typically off by some small value.
Before starting with the analysis of the data one is usually comparing
the position of a reference peak (in my case this was usually Si) in
angular space with its nominal value for a given energy and than use the
offsets to correct the measured values. 

I guess this procedure qualifies as a 'refinement' process of the
measured data. If I understood the concept of variants correctly the
'refined' (corrected) values of the polar_angles of the sample and the
detector should be stored as variants (or better the old values should
go to a variant while then ones take their place). However, in this case
the polar angles would be fields of dimension [number of points] and the
variant, hence, cannot be stored as a single attribute attached to the
field. 

To my opinion there are two approaches to attack this issue

1.) allow variants to be fields, lets say with a suffix of form   
    '_variant%i'

2.) introduce a scalar offset for each field stored in an extra field 
    with suffix '_offset'. In principle one could store this value as
    an attribute too but then only scalar offsets would be reasonable 
    and we should not restrict us to this case. 

In both cases I guess we are running into a problem. The semantics of a
field name becomes more complex. Let me give you a short example.
Consider the following names 

polar_angle -> this would be the field we want to store
polar_angle_esd -> the standard deviation of the polar angle 
polar_angle_offset -> an optional offset value

and of course we have the same vor the first variant 
polar_angle_variant1
polar_angle_esd_variant1
polar_angle_offset_variant1

In all of the above 6 cases the object of interest is the 'polar_angle'.
However, you really need to parse this name to figure this out. In other
words we would need something like a grammar for field names to read or
write them reliably. Something like 

[STRING]+?[_esd|_offset|...]+?[_variant%i]

I never really understood how to write down grammars as BNF (sorry
Herb ;)) but I guess it is obvious what I mean. If we are not doing it
this way and define some 'key-suffixes' we run into troubles as people
my use such field names by accident. 

What's your opinion about this?

regards
  Eugen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.nexusformat.org/mailman/private/nexus-tech/attachments/20131024/c7406a6e/attachment.sig>