search

nexusformat / NIAC

Issue for the NIAC to discuss (no code)
2 stars 0 forks source link

Group referencing an Application Definition #138

Open sanbrock opened 2 years ago

sanbrock commented 2 years ago

Groups can reference Base Classes, but we may want to combine multiple Application Definitions in a new one, like a workflow of multiple experiments as subsequent steps. Under NXroot we can do that by adding arbitrary number of independent ENTRIES. Unfortunately these entries are independent and cannot be verified against a definitions (e.g. when a complex workflow requires certain steps and may contain some others. How could we write complex Application definitions which are prescribing data according to other application definitions?

Possibility A) Like NXroot, any Group in an Appdef could refer to an NXentry. Under this NXentry group, an AppDef can then specify its definition to be a specific obligatory value, or a list of enums, so it can restrict which AppDef should be implemented below that ENTRY.

Possibility B) An AppDef in any of its Groups could reference directly an Application Definition. In this case within this group, it would inherit an ENTRY and within this data should be stored according to the referenced AppDef.

Possibility C) An AppDef in any of its Groups could reference directly an ENTRY within an Application Definition. In this case, we should ensure that "type=" can refer to any item of our NeXus Vocabulary. This is happening already now, but is hidden for convenience: NXxlaue/entry inherits NXxrot/entry which inherits NXxbase/entry which only at this point inherits from NXentry on the other hand NXxlaue/entry references: type="NXentry" directly.

Shall we have a preferred method and if yes, which one should it be?

benajamin commented 2 years ago

This problem appears to be already partly addressed with NXentry and NXsubentry. This is for measurements involving simultaneous application definitions.

The other part of this issue is to have a way to proscribe an intended workflow (i.e. a compliant file should have a certain set of NXentriy's). NeXus has methods for documenting a series of steps (measurements and/or processes), but describing this kind of activity in advance doesn't fit into the NeXus architecture and is probably beyond the scope of a data format.

woutdenolf commented 2 years ago

This is an example of using NXsubentries

/:NXroot
/myentry:NXentry
/myentry/myapp1:NXsubentry
/myentry/myapp1/definition=NXxas
...
/myentry/myapp2:NXsubentry
/myentry/myapp2/definition=NXfluo
...
sanbrock commented 2 years ago

Great! NXsubentry looks like a good solution.