This BioXHIT/CCP4 data-tracking schema describes the information accumulated during the processing of experiments in biological X-ray crystallography. Data tracking for the entire process of deriving coordinates from an X-ray crystallographic experiment. An identifying name for the project, corresponding to CCP4i's PROJECT_NAME. A descriptive title for the project (Optional) Text with a longer description of the project (like an abstract) Data items required for PDB REMARK 200 The coordinates of the final model being deposited The reflection data used for refinement List of reflection datasets used in phasing One of a number of reflection datasets used for phasing A step in the process of solving the structure and generating the final model. This could be a run of a CCP4i task or some other "driver application", a run of a script, some process of editing using a graphics program etc. A major step in the processing. A positive integer indicating the order of the steps. Step_numbers must be unique within a Deposit_history. (Optional) A short description of the step. Corresponds to the TITLE attribute in CCP4i. A list of Step_numbers indicating which previous steps provided data for input into this step (either explicitly as a data file or implicitly via logfile scraping) or which are related in some other way (for example because of application logic). A positive integer indicating the order of the steps. Step_numbers must be unique within a Deposit_history. The driver application gives the context of the step. Driver applications could be CCP4i, HAPPy, XIA, Coot, or none (if the step was "manual"). documentation missing documentation missing This is the name of the application-specific task that was run in this step, in the context of the driver application. For CCP4i this corresponds to the TASKNAME attribute, for example it could be a task such as "scala", "prehadata" or "refmac5". The date and time that the step was completed by. Data type reference: http://book.xmlschemata.org/relaxng/ch19-77041.html This is the application-specific file which contains parameters used to run the task. For example in CCP4i this would be the .def parameter file associated with the job. For other applications it could be a keyworded input script plus the command line. What is important is that the driver application knows how to make sense of this. Records which step in the PDB_extract model of deposition this Step corresponds to. Its value is one from a list of values. A data file used as input to the step, i.e. the inputs treating the step as a "black box" (more fine-grained detail can be included via the use of the Component_Substeps). For CCP4i this would be constructed from the INPUT_FILES and INPUT_FILES_DIR attributes. A data file output from the step, i.e. the outputs treating the step as a "black box"(more fine-grained detail can be included via the use of the Component_Substeps). For CCP4i this would be constructed from the OUTPUT_FILES and OUTPUT_FILES_DIR attributes. The application-generated log file for the step - typically this is the text written to stdout by the application (for example, in the case of CCP4 programs). This is a container for listing the Substeps that were run as part of the current Step. There may not be any Substeps for some applications (for example if the Step was the run of a single program) in which case the list of Component_substeps will be empty. In other cases there may be one or more Substeps which are defined by the driver application - for example in CCP4i the substeps are the individual programs run by the task in question. A Substep is an application-defined part of the current Step. For example in CCP4i this would be a run of one program within a task e.g. the "scala" task might typically runs the programs SORTMTZ, SCALA, MTZDUMP, UNIQUE and so on - each of these would constitute a Substep within CCP4i. Within Coot, a run of REFMAC might constitute a Substep. A substep of a major step in the processing. A positive integer that is unique within the current Step, to indicate the order of the Substeps. Compare Step_number. The name of the program run in the substep (Optional) The version of the program run in the substep, in whatever format the program is versioned in. (Optional) The name of the package that the program belongs to (if any). For example for SCALA it would be "CCP4", for shelxc it might be "SHELX". (optional) The version of the package that the program belongs to (if any), in the appropriate version format for that package. (Optional) Simialar to Application_control_file - the application-specific file containing the parameters to run the program in this substep. A data file used as input to the step, i.e. the inputs treating the step as a "black box" (more fine-grained detail can be included via the use of the Component_Substeps). For CCP4i this would be constructed from the INPUT_FILES and INPUT_FILES_DIR attributes. A data file output from the step, i.e. the outputs treating the step as a "black box"(more fine-grained detail can be included via the use of the Component_Substeps). For CCP4i this would be constructed from the OUTPUT_FILES and OUTPUT_FILES_DIR attributes. (Optional)The application-generated log file for the step - typically this is the text written to stdout by the application (for example, in the case of CCP4 programs). Data items required for PDB REMARK 200 "X-Ray diffraction" (the only type dealt with by CCP4) The initial model used for molecular replacement (and only for that) Groups together data items related to the data collection Groups together all the items related to the data processing Describes a file Reference to a file, with the following attributes: Filename: the name of the file, with or without a leading path (e.g. /home/pjx/aucn.mtz or aucn.mtz) Pathname: the full pathname of the directory that the file is in, if no path was supplied as part of the Filename Host: (optional) the name of the host where the file resides Format: the format that the file is written in, e.g. MTZ, PDB, CIF etc Type: (optional) the type of data held in the file, e.g. harvest file, reflection data, coordinates, Refmac dictionary The format that the file is written in, e.g. MTZ, PDB, CIF etc (optional) the type of data held in the file, e.g. harvest file, reflection data, coordinates, Refmac dictionary Conditions under which the data collection took place date in the year (no time), in dd-mmm-yyyy format, or null in degrees Kelvin 0-14 (of the crystal) angstroms, either a single wavelength (real number) or a range (two real numbers separated by a hyphen) Possible cases: -single wavelength (discrete) -polychromatic (range: e.g., 1-1.5) -Laue (range, as above) the number of crystal used in the experiment Y/N could describe the source of the X-rays - either internal generator (e.g., rotating anode) or synchrotron station (ESRF) The identification of the synchrotron beamline (e.g., ID23) Free text. Describes the optices used in the X-ray source set up (e.g., mirrors) the type of X-ray detector used (e.g., CCD, image plate) manufacturer of above detector If radiation_source above is "internal", the model of the generator (e.g., RIGAKU RU3HR) Type of monochromator used "M" or "L" Describes the reflection data obtained at the experiment documentation missing (Optional) Corresponds to the "crystal name" attribute in the MTZ file header (Optional)Corresponds to the "dataset name" in the MTZ file header (Only required for a file of type MTZ). An MTZ column label. Information regarding the initial processing of the experimental data.