[NeXus-tech] [NeXus-committee] questions about NeXus data structures as per Figs 1-3 of draft paper

[Mark Könnecke]

Joachim,

Am 18.08.2014 um 15:32 schrieb Joachim Wuttke <j.wuttke at fz-juelich.de>:

> Dear colleagues:
> 
> In the draft manuscript (v6), Figs 1 and 3 show the
> common structure of raw-data and processed-data
> files, respectively.
> 
> Are these structures also described in the docs? Where?
> 
> Some groups are marked as "required". Is this specified
> in the docs? Where?
> 
> If some groups at second or third level are required,
> then the first-level group "NXroot" must also be
> required, right?
> 
> Why should we require NXdata? If scientists at a certain
> instrument have no interest in using generic default
> plotting tools, and don't like the extra complexity of
> symbolic links in their raw data files, we should allow
> them to use NeXus without NXdata.
> 
> Why is NXinstrument required for raw-data files? Is there
> an application definition without an NXinstrument group?
> 
> It seems though that there are some raw-data application
> definitions without NXsample, and many without NXuser.
> Is there a rationale why some instrumt types would
> require these metadata, and others not? Or do the
> different application definitions just reflect different
> personal preferences of different authors?
> 
> For multi-method instruments, some entries move from
> NXentry into NXentry/NXsubentry. What if one day an
> established multi-method instrument gets embedded into
> a yet more powerful instrument: will we then have
> NXentry/NXentry/NXsubentry or NXentry/NXsubentry/NXsubsentry
> or NXentry/NXsubentry/NXsubsubsentry? In my humble
> opinion, NXsubentry should never have been invented;
> why not use the power of recursion and allow NXentry/NXentry?
> 

There was some discussion on this when NXsubentry was invented. I will attach the report from the 
NeXus workshop at PSI in 2010 which contains the rationale for this on the second page. 

The main point is to capture the whole multi method instrument in one fat NXentry, all detectors, all logs 
all everything. And to provide the method specific stuff through links in NXsubentry. 

I also remember that we discussed using NXentry instead of NXsubentry. We decided for NXsubentry 
in order to keep the concepts different.   

I also feel that recursion is not the appropriate metaphor here: you do not have a powder diffractometer inside 
a fluorescence beam line inside SAS inside WAX inside…… It will always be that you have different detectors 
looking at the same sample at the same time under different aspects. This is well covered with NXsubentry.

Best

    Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nx2010report.pdf
Type: application/pdf
Size: 52357 bytes
Desc: not available
URL: <http://lists.nexusformat.org/mailman/private/nexus-tech/attachments/20140819/db7fcda5/attachment-0001.pdf>
-------------- next part --------------

 




> Best - Joachim
> 
> _______________________________________________
> NeXus-committee mailing list
> NeXus-committee at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-committee