Hierarchy in NeXus application definitions?

[RealPolitiX]

Experimental techniques often naturally form a hierarchy: there are base terms for a class of techniques (photoemission spectroscopy, X-ray spectroscopy, etc.) that are more generic. Then, there are more specific subcategories of techniques (spin-resolved photoemission spectroscopy, X-ray fluorescence spectroscopy, etc). I have the following questions related to this topic,

1. When a new application definition is submitted or established, is it necessary to take into account a potential hierarchy (e.g. relationship to existing NeXus application definitions)? If so, how should the hierarchical relationship between application definitions be represented?

2. For a class of experimental techniques, should the top-level application definitions be submitted for review by NIAC or the lower level one, or both?

[mkoennecke]

Dear Patrick Xian,.

Am 11.12.2020 um 10:48 schrieb R. Patrick Xian notifications@github.com<mailto:notifications@github.com>:

Experimental techniques often naturally form a hierarchy: there are base terms for a class of techniques (photoemission spectroscopy, X-ray spectroscopy, etc.) that are more generic. Then, there are more specific subcategories of techniques (spin-resolved photoemission spectroscopy, X-ray fluorescence spectroscopy, etc). I have the following questions related to this topic,

1. When a new application definition is submitted or established, is it necessary to take into account a potential hierarchy (e.g. relationship to existing NeXus application definitions)? If so, how should the hierarchical relationship between application definitions be represented

NeXus application definitions support a hierarchy through the use of the extends attribute to the definition node in the NXDL file describing an application definition. See an example in NXxeuler extending NXxbase. There is another rule to keep in mind: if a field is defined both in the base class and the derived class, then the derived classes field overrules the base class field.

However, there is no common base class as such. Thus if you wish to start from scratch you can do so.

1. For a class of experimental techniques, should the top-level application definitions be submitted for review by NIAC or the lower level ones, or both?

—

All of them if you wish to have them vetted by the NIAC. Because the top level application definition would not be completely documented without the base class.

Best Regards,

  Mark Koennecke

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/nexusformat/definitions/issues/874, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGL7WQEJCF73IRRGOEU6J3SUHTHLANCNFSM4UWL44LQ.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/nexusformat/definitions/issues/874", "url": "https://github.com/nexusformat/definitions/issues/874", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[hartelt]

Thanks for your answer @mkoennecke . As far as I see, a derived class would extend a base class, so each of the base-class fields would be present in all derived classes, if only as non-required field. Is this correct? In this case it would make sense to only define the common/generic fields in the base class, and add specific/special fields only in the derived classes.

Only now, there might be several subcategories sharing certain special fields. E.g. devices in the experiment, that are needed in a number of sub-techniques but not all of them. How do we make sure those fields are defined in a consistent way across derived classes?

For our research field, we envision a universal "dictionary" of metadata definitions, which defines all possible fields in a consistent way. Then we would define application definitions as subsets of the universal dictionary, combining the fields needed for a specific experiment type. In this way, we would ensure consistency while avoiding confusion due to elements that do not apply. Is there a recommended way to implement this in NeXus?

[benajamin]

@RealPolitiX please don't shy away from "NIAC review". What really tends to happen is a collaboration to work out the inconsistencies in your proposal before you commit to it and save you from learning the "hard way". While it is nice to map out and accommodate all possibilities, we shouldn't let "perfect" be the enemy of "good". Since you seem to be comfortable with github, I suggest you create a pull request showing what changes you need/want, following the NXxeuler example pointed out by @mkoennecke.

[mkoennecke]

Dear Michael Hartelt, Patrick Xian,

Am 15.12.2020 um 10:49 schrieb Michael Hartelt notifications@github.com<mailto:notifications@github.com>:

Thanks for your answer @mkoenneckehttps://github.com/mkoennecke . As far as I see, a derived class would extend a base class, so each of the base-class fields would be present in all derived classes, if only as non-required field. Is this correct? In this case it would make sense to only define the common/generic fields in the base class, and add specific/special fields only in the derived classes.

This is correct. But you can also override a field defined as optional in the base class to be mandatory in a derived class.

Only now, there might be several subcategories sharing certain special fields. E.g. devices in the experiment, that are needed in a number of sub-techniques but not all of them. How do we make sure those fields are defined in a consistent way across derived classes?

Have a hierarchy. The example I gave has only one inheritance level, for you to get the idea and notation. You can have more levels of hierarchy when required. For example:

      |—> sub technique1

base——> sub technique 2 |—> sub-technique 3 —> sub-technique 4

and so on.

For our research field, we envision a universal

"dictionary" of metadata definitions, which defines all possible fields in a consistent way. Then we would define application definitions as subsets of the universal dictionary, combining the fields needed for a specific experiment type. In this way, we would ensure consistency while avoiding confusion due to elements that do not apply. Is there a recommended way to implement this in NeXus?

Hmm, sounds complicated. Especially as NeXus already provides an ontology of predefined names. We will also encourage you to add further names and meanings to the NeXus ontology(dictionary, expressed as base classes) when something is missing.

We also have an experimental NeXus thing called features, https://github.com/nexusformat/features which is more light weight the application definitions. This is not fully endorsed by NIAC yet but you may provide the use case which pushes over the edge for adoption.

However, with the state of NeXus as is, I encourage you to try to map your use case in a hierarchy.

Best Regards,

 Mark Koennecke

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/nexusformat/definitions/issues/874#issuecomment-745176448, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGL7WSSBQADLDATP3QK6RLSU4WKFANCNFSM4UWL44LQ.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/nexusformat/definitions/issues/874#issuecomment-745176448", "url": "https://github.com/nexusformat/definitions/issues/874#issuecomment-745176448", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[RealPolitiX]

@mkoennecke, we meant to build our new application definitions on top of the existing hierarchy within NeXus as much as possible and extend the ontology whenever necessary. Thanks for your illustration. I presume to introduce a new base class, one would need to do a pull request here? Can that be submitted separately from an application definition that uses it?

[mkoennecke]

Dear Patrick Xian,

Am 28.12.2020 um 02:50 schrieb R. Patrick Xian notifications@github.com<mailto:notifications@github.com>:

@mkoenneckehttps://github.com/mkoennecke, we meant to build our new application definitions on top of the existing hierarchy within NeXus as much as possible and extend the ontology whenever necessary. Thanks for your illustration. I presume to introduce a new base class, one would need to do a pull request here? Can that be submitted separately from an application definition that uses it?

The process is to place your new application definitions into the contributed_definitions directory. After due consideration by NIAC they then will graduate into the applications directory.

Best Regards,

  Mark Koennecke

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/nexusformat/definitions/issues/874#issuecomment-751546184, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGL7WVAOZDZBNST7GGJGGTSW7P6LANCNFSM4UWL44LQ.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/nexusformat/definitions/issues/874#issuecomment-751546184", "url": "https://github.com/nexusformat/definitions/issues/874#issuecomment-751546184", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[prjemian]

No work on this at 2022-06 Code Camp.