Hierarchical or categorized repository metadata
The repository uses some metadata to drive the search index, API, and GUI. This is most commonly used to facilitate the search and present a preview to users. While in the past, this metadata could be assigned to almost all entries, this will not be true with more diverse entries (atoms/molecules, MD, experiments, etc.).
Therefore, we need a more hiearchical model that supports subsets of nomad data only supporting certain quantities and other entries supporting different entries. This hierarchical model should be presented as a system of nested categories in the GUI, similar to traditional faceted browsing in online stores (think Amazon, Ebay).
This is related to supporting domains (a.k.a supporting entries with different top-level sections, e.g. section_run (DFT), section_experiment (experiments, etc.) #286 (closed)
one example, symmetry in DFT data:
Currently the data model for DFT calculations is expecting that the symmetry-related properties space_group_number
, crystal_system
and spacegroup_symbol
are present for every DFT calculation. Although they can be determined for every calculation, they only make sense for entries with system_type == "bulk"
. For the end-user, it is a bit confusing if we report e.g. crystal_system for molecules or atoms.
I'm working on modifying the data model to remove this expectation in the symmetry_update
branch. Although it is an easy change on the normalization level, the change would also affect the GUI. I see that e.g. the columns in the search results would be affected.
Do you think it is fine to proceed in removing these symmetry-related quantities from the GUI as well? Another option would be to postpone this until we settle on a consistent mechanism for customizing the GUI based on the user search (for example the GUI starts from a general view for all DFT data, and is then updated as the user adds search criteria that is specific to a subgroup of DFT data for which we have a customized GUI).