The N4L XML schema was designed to be modular and relies heavily on reusable types. There are four basic XML object types represented by the schema, as well as several container types and a number of enumerated types for domain values. The four basic types are described in individual XSD schemas, each having its own namespace: Name xmlns=http://namesforlife.com/ns/name The nameStatusGroup contains the identifer (name, rank, DOI), the authority string, and the status of a name. This group of elements may appear in several places in the schema, and can be considered a minimal description of a name. The nameType extends the nameMetaType (contains a nameStatusGroup) by adding a list of events (see eventType and eventEnumType), a list of synonyms (each of which contains a nameStatusGroup), an optional bibliography (a collection of relevant references, see below), and any additional annotation added by curators. Essentially, a name element (nameType) is a container for all known information about a name. The synonyms are separated into two groups, 'synonyms-from' and 'synonyms-to'. These tags are redundant since each synonym contains a 'from' and 'to' attribute (both Name DOIs), but are present to allow for more straightforward processing with XPath. There are several different types of synonyms (see synonymEnumType) and each of them are described by the Bacteriological Code. A synonym also has a date associated with it, which is derived from the reference that asserted it. The taxon and exemplars may be included under the name element in one of two ways: 1. In a compact form (essentially a pointer to the taxon or exemplar record(s)); The verbose form (name status and references) are exported to their own documents. (nm.####.xml, tx.####.xml, ex.####.xml) 2. In a verbose form (name status and references) inline with the document. (nm.####.xml) Taxon xmlns=http://namesforlife.com/ns/taxon The taxon element (taxonType) has a unique DOI assigned to it (attribute 'doi'), a rank (see rankEnumType) and an is-type flag to indicate whether the taxon is the type for its parent taxon. A taxon may have a parent, which (although this may seem counterintuitive) is actually modeled as a 'has-a' relationship in the XML to enable easy traversal on a record-by-record basis. Notably, not all taxa have parents (e.g., Archaea and Bacteria, as well as some higher taxa that have not been placed taxonomically). A taxon may also have zero or more children, of which one may be marked as the type. The parent and child taxa are of type 'taxonIdentifierType' (which taxonType also inherits from) and may contain an optional nameStatusGroup (part of the name schema) that contains pre-computed status information about the current name for the taxon. A taxon may thus be represented either in a compact form: Example 1: or in an expanded form with name information. Note the namespace differences: Example 2: Alteromonadaceae Ivanova and Mikhailov 2001 emend. Ivanova et al. 2004 Aestuariibacter salexigens Yi et al. 2004 Aestuariibacter halophilus Yi et al. 2004 Aestuariibacter litoralis Tanaka et al. 2010 Exemplar xmlns=http://namesforlife.com/ns/exemplar The exemplar element (exemplarType) consists of Deposits (or strain identifiers) and any important features (accession numbers or other unique pointers to external data sources) that are associated with each deposit. Each exemplar has a distinct DOI. There will be a maximum of one type exemplar per species or subspecies, indicated by the 'is-type' flag. Do not confuse the type taxon with the type exemplar. All of the deposits within a particular exemplar are considered to be equivalent to one another. The structure of the XML (Exemplar contains Deposits, Deposit contains Features) is organized in a way that shows the particular deposit that a feature was based on. If the deposit information is not available (for instance, if no actual strain identifier is available for an environmental 16S sequence), the feature is placed under the null-strain element. Each deposit and feature is asserted with a literature reference. Reference xmlns=http://namesforlife.com/ns/reference A reference element (referenceType) consists of an outer wrapper, 'reference', which has a unique N4L ID (not a DOI) that is used for internal tracking to avoid duplicates. It contains a 'citation' element, which is intended to be compatible with the NLM citation model. However, the NLM citation model is was intended mainly for journal references, and is not descriptive enough for many of the 10,000+ references currently stored in the N4L database (particularly book citations). A citation element is marked with a 'type' attribute to indicate the citation type (journal, book, thesis, patent). A reference may be used multiple times in the same document (multiple events or deposits may be described in a single article). In order to avoid duplicating large amounts of data, the wrapper element or a refid attribute (various places in the schema) may be used independently to refer to a citation that is defined elsewhere in the document.