Annotations to guide RDM tools about which quantities to index for deep and exhaustive appdef instance data

[mkuehbach]

https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/2012
Assume richly contextualize instance data of NeXus appdef files are loaded in RDM systems, which concepts should be indexed with which priority
Development of a mechanism whereby RDM system can be instructed which quantities to pick up and index for e.g. search capabilities,
all required concepts, none, conflict of interest between appdefs for different target applications,

[mkuehbach]

I also think this is not an issue on the NeXus side, point is appdef tells what is required, required for what, demands for processing can differ across software tools, so for RDM tools. I agree that such capping could have a benefit in that it allows for more fine grained customizability without the need to make additional appdefs but it also then signs that when used with a specific RDM an appdef is not a useful contract because it may deliver more than the consuming app in this case the RDM is able to cope with.
That's why I think the real discussion should go towards establishing an intermediate between base classes and appdefs, in that intermediate base classes are combined but either still all optional or restrictions imposed and then in the appdef these can be composed together with adding more restrictions. Either way as soon as there is one restriction an appdef it may need a strong compromise in the community but that holds for each semantic model that applies restrictions, same story for application profiles as used in some RDM systems. Here people then build own profiles, again the same pitfall, possibility that concepts get defined twice and or in one place required in the next optional, a mess...