Experimental Equipment

January 14, 2011

Part of the information we want to store about an experiment is the equipment used to conduct the experiment.

Note that this is only used to identify and provide static information about the equipment, any information which is dynamic, such as configuration settings, will be stored as parameters against the relevant datafiles or datasets.

The benefits of explicitly identifying the equipment used in the experiment include:

  • Being able to take any quirks of the equipment in to account when analysing the data.
  • Being able to find all data collected by a piece of equipment to facilitate analysis of the equipment performance.
  • Notifying users of any normalisation that needs to be performed on raw data, e.g. if part of the detector is accidentally burnt out.

We considered a number of approaches to the design:

  1. Adding an Equipment table to TARDIS core schema
  2. Extending ParameterSets to allow them to be shared between projects and creating an Equipment schema
  3. Leaving Equipment out of TARDIS core functionality, implementing an Equipment register as a separate Django application and referencing the entry from a parameter

We are currently working on the third approach, using a separate Equipment register, for the following reasons:

  • A facility may already have an equipment register, or web pages describing the equipment, in which case the functionality is not required.
  • Maintaining information on equipment is not core functionality for TARDIS, which is about experimental metadata.
  • How the equipment information should be federated isn’t clear.  Using a separate register allows the link to be valid from any location while avoiding the replication problems.
  • Django’s architecture makes it easy to implement and deploy multiple small applications (such as an Equipment Register).

Metadata strategy

October 6, 2010

The University of Southampton data management project has proposed a three-level metadata strategy, see their blog entry “Metadata strategy“:

  1. Project
  2. Discipline
  3. Core

Tardis is based on the Core Scientific Metadata model (CSMD) developed within the Science & Technology Facilities Council (STFC).  One metadata hierarchy they’ve adopted is (turned upside down to match Southampton’s):

  1. Science Specific
  2. Instrument Specific
  3. Core

(This reminds me of Robert Pirsig’s Intellectual Scalpel)

We’re extending Tardis for use within the Australian Synchrotron and ANSTO, where the STFC model is more appropriate.  However, institutional use of Tardis may also be project based.

Tardis supports configurable schemas (parameter sets) at  the experiment, dataset and datafile level.  Appropriate use of the configurable schema should allow us to handle both models, or a combined model.