QSAR DataBank - an approach for the digital organization and archiving of QSAR model information

Abstract

Background: Research efforts in the field of descriptive and predictive Quantitative Structure-Activity Relationships or Quantitative Structure-Property Relationships produce around one thousand scientific publications annually. All the materials and results are mainly communicated using printed media. The printed media in its present form have obvious limitations when they come to effectively representing mathematical models, including complex and non-linear, and large bodies of associated numerical chemical data. It is not supportive of secondary information extraction or reuse efforts while in silico studies poses additional requirements for accessibility, transparency and reproducibility of the research. This gap can and should be bridged by introducing domain-specific digital data exchange standards and tools. The current publication presents a formal specification of the quantitative structure-activity relationship data organization and archival format called the QSAR DataBank (QsarDB for shorter, or QDB for shortest).

Results: The article describes QsarDB data schema, which formalizes QSAR concepts (objects and relationships between them) and QsarDB data format, which formalizes their presentation for computer systems. The utility and benefits of QsarDB have been thoroughly tested by solving everyday QSAR and predictive modeling problems, with examples in the field of predictive toxicology, and can be applied for a wide variety of other endpoints. The work is accompanied with open source reference implementation and tools.

Conclusions: The proposed open data, open source, and open standards design is open to public and proprietary extensions on many levels. Selected use cases exemplify the benefits of the proposed QsarDB data format. General ideas for future development are discussed.

Keywords: Data format; Data interoperability; Open science; QSAR; QSPR.

Figure 1

The layout of a QDB archive in the local file system.

Figure 2

Screenshot of the graphical QsarDB curation application.

Figure 3

Container type hierarchy. There are two abstract Container types (italic typeface) and five Concrete Container types (normal typeface). Descending Container types inherit all attributes and cargos from their parent Container types. For example, Property defines two attributes (i.e. Endpoint, Species). Additionally, Property inherits five (i.e. Id, Name, Description, Labels, Cargos) attributes and one cargo (i.e. BibTeX) from Container and three cargos (i.e. UCUM, values, references) from Parameter.

Figure 4

Flat (above) and structured (below) approach for the encoding of container attributes.

Figure 5

Disambiguation of container identifiers in DataDictionary element with the use of the “prefixed identifier” mechanism.

Figure 6

Different QSAR datasets relative to availability of experimental data and QSAR lifecycle. Training and internal validation share the same data set (blue). External validation and testing have their own disjoint data sets (orange and yellow).

Figure 7

Strong (solid arrows) and weak (dashed arrows) relationships between the five container types. The ordering of Container types (along the complexity axis) follows the incremental buildup of a QDB archive.