OBD Architecture
Structurally, we store annotations separately from primary experimental data. The primary data may be stored in OBD or can be located elsewhere in cyberspace. In the latter case, OBD stores only the annotations, with pointers to the accession numbers of the corresponding primary data in the data resources that hold the actual experimental observations. The separation of data and annotations into separate physical stores gives OBD the option to support the use of alternative annotations for the same physical data sets.
OBD, whenever possible, takes advantage of relevant standard ontologies for marking up experimental data (e.g., the MGED ontology for microarray data) and, when appropriate, stores the primary data as instantiations of those ontologies (e.g., OWL individuals, in the case of MGED). Investigators also have the option to store data in relational format or as RDF triples.
Most users will access OBD through one or more applications. The applications themselves use an application programmer interface (API) or a Web Service interface as an intermediary. The API or Web Service interface makes the underlying database implementation transparent to the application, insulating the application from schema changes, and also providing a way to share and re-use software routines.