The main design principles of EDAM are relevance to its target applications, convenient usability for annotators and users of the annotations and efficient maintainability by its developers.
To ensure relevance
, EDAM has to comprehensively cover the common bioinformatics concepts. To achieve this, numerous resources were analysed and used as sources of concepts. The myGrid ontology served as a starting point. Collections of tools were analysed, including Web services from the EMBRACE registry (Pettifer et al., 2009
), the EMBOSS suite and the BioMoby Service Ontology. Common bioinformatics data formats and the BioMoby Object Ontology served as sources of types of data and formats. The Nucleic Acids Research’s database and Web-server catalogues, as well as classifications within bioinformatics journals and conferences were used as sources of topics. Semantic annotations with EDAM and the implementations using EDAM, done in parallel with the EDAM development, provided valuable feedback.
Heuristics for ensuring that EDAM remains broadly applicable include logical consistency, clear semantic scope, well-defined interfaces with other ontologies and being open to future developments in collaboration with the community.
EDAM has to be conveniently usable by humans for the purposes of annotation and search. We have therefore avoided excessively broad or deep branches and have orientated the ontology around the small number of ‘orthogonal axes’ (sub-ontologies), each with readily understood meaning.
To keep EDAM maintainable, agile software development methods are used. This ensures that changes are delivered with good response time using limited resources and yielding consistent results. For example, relations between concepts are explicitly defined only in one direction, to minimize the possibility for inconsistencies and to ease maintenance.
EDAM’s design is not based on any metaphysical doctrine, but that does not mean that it is based on bad or no philosophy. EDAM is founded on logic, and on relevance and utility to the bioinformatics community. This is in accordance with Lord and Stevens (2010)
, Merrill (2010
) and Rzhetsky and Evans (2011)
that all indicate, using separate sets of arguments, that it is the relevance of scientific ontologies with respect to their practical applications that is more important than an imposed metaphysical ideology. EDAM concepts
are not concepts existing only in minds of the EDAM authors, but common notions shared within the bioinformatics community.
EDAM follows to some extent also the candidate OBO Foundry principles under discussion (http://www.obofoundry.org/wiki/index.php/Category:Discussion
), with a few exceptions owing to the usability, maintainability or coherence requirements. For example, terms are capitalized for aesthetic reasons and faster recognition. In some places, specialization of multiple generic concepts is logically correct and necessary for usability, such as in Structure alignment
being both an Alignment
Some mostly higher-level concepts are related to generic Semantic Web vocabularies or to higher-level concepts in specialized ontologies with different focus than EDAM: e.g. RDFS, Dublin Core, DOAP, DMOP, BRO (Tenenbaum et al., 2011
) or MeSH (Nelson, 2009
). This applies also to ontologies under development: the Semanticscience Integrated Ontology (SIO, http://code.google.com/p/semanticscience/wiki/SIO
), Web Service Interaction Ontology (WSIO, http://wsio.org
) and SoftWare Ontology (SWO, http://theswo.sourceforge.net
). Such concepts are linked from EDAM. Additionally, in the case of SWO, the bioinformatics-specific concepts of EDAM are included via OWL import. The higher-level concepts in EDAM also reference concepts in multiple upper ontologies: DOLCE (Gangemi et al., 2002
), BioTop (Beisswanger et al., 2008
), GFO and GFO-Bio (Hoehndorf et al., 2008
), BFO (Grenon et al., 2004
) and SUMO. EDAM may thus be usable in a variety of future semantic-integration scenarios. In addition, some concepts in EDAM include links to other scientific ontologies with different ‘axes’ of meaning or with more detail. These include SO, CDAO, GO and ChEBI (Degtyarenko et al., 2008
). EDAM relations explicitly reference the relations defined in the Relation Ontology (Smith et al., 2005
), IAO (http://code.google.com/p/information-artifact-ontology
) and OBI (Smith et al., 2007
). For example, has input
points to has_specified_input
in OBI and has topic
points to is about
in IAO, via links with comments explaining the differences in meanings.
EDAM has been iteratively developed yielding on average four versions released per year (in the course of the last 4 years), resulting in the current version 1.2. Concept URIs and IDs persist between EDAM versions. The name, definition, relations and other properties may change; nonetheless a given URI (ID) will remain fundamentally true to the original concept. Concepts may be deprecated on the release of a new version, but they persist, with their original ID and URI. Concept URIs do not contain a version, so semantic annotations remain valid while EDAM evolves, without an immediate need for update. Deprecated concepts indicate a replacement (via replaced_by), or one or more suggestions (via consider). EDAM will continue evolving, but future versions should not be a fundamental departure from the established scope, principles and architecture.