Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • nomad-FAIR nomad-FAIR
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 138
    • Issues 138
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • nomad-lab
  • nomad-FAIRnomad-FAIR
  • Issues
  • #276

Closed
Open
Created Feb 10, 2020 by Lauri Himanen@himanel1Maintainer

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).

Edited Feb 21, 2020 by Markus Scheidgen
Assignee
Assign to
Time tracking