Skip to content

Unified entry (overview) page and declarative property and archive browser visualisations

Currently we have different entry page views (at least overview and files) depending on the entries "domain". For FAIRmat, we want to discontinue the "domain" system, because a flat list of domains is not scalable enough. A single page and single views need to fit all kinds of entries. Furthermore, the current dft entry overview and archive browser hard code if and when to show what property visualization. This should be replaced with a more declarative approach.

Assumption: We only deal with result based entries.

There are several items that depend on the actual "shape" of an entry's result section:

  • the method and parameters on the left
  • which property cards to show
  • how to present the "origin" and potential off-site data

The last point is a general thing and the same impl for all types of entry should be possible. This depends on origins like oasis, external db and not so much on the entry kind. It affects the "Author metadata" part on the overview left and "Raw data"-View.

The method parameters depend on the metainfo results.method hierarchy and should be taken from there via breadth-first traversal. For example:

  • results.method.method_name
  • results.method.simulation.program_name
  • results.method.simulation.program_version
  • results.method.simulation.dft.xc_functional_family or
  • results.method.method_name
  • results.method.experiment.eels.spectrum_type

Labels and optional components should be encoded in the metainfo quantity definitions (via special GUI annotation). All quantities are simply put into a grid.

The property cards on the right of the overview depend on the results.properties hierarchy. Properties might be bundles into a single card (e.g. electronic, vibrational, etc.). Again, a GUI annotation can be used to map properties into cards via the same property-card-key.

Similarly an annotation should describe if and how to render a section/quantity in the archive browser.

This annotation could have an interface like this:

class GUI(nomad.metainfo.annotation):
   type: enum('property-card', 'archive-browser', 'quantity')
   key: string
   component: string
   label: string

This means that "component" needs to have a common interface, e.g. all property-card components need to take the same props. All the specificity has to be encoded in the component's JS.

If the annotation is too cumbersome, a .json-based config in the GUI source could provide the same information.

Alternatively, we could still hardcode everything in the UI, but then the interface needs to be far more simple. E.g. for the property-cards:

<ElectronicPropertiesCard result={result} />
<GeometryOptimizationCard result={result} />
<EELSSpectrumCard result={result} />