NeXML Elements

From Phyloinformatics
Revision as of 10:20, 26 May 2010 by Yeban (talk) (Characters)
Jump to: navigation, search


The following document exhaustively covers the NeXML elements. The coverage is purely technical and I have linked to the appropriate schema definitions from the NeXML site for completeness. A knowledge of the XML Schema Definition( XSD ) is unnecessary to read the document. A discussion on the schema design can be found here: NeXML schema discussion. Note that this documentation is not final yet.


The root element of NeXML is called nexml. This element is an instance of the Nexml class.


  • version - a decimal number indicating the nexml schema version. At present this value is 0.8.
  • generator - an optional attribute, which is used to identify the program that generated the file. The attribute's value is a free form string.

Namespaces: (Where it says "by convention" in the list below, the convention applies to the three-letter prefixes which are free to vary in most cases, not the namespaces themselves):

  • the xml namespace prefix that identifies xml schema semantics that might be inlined in the file. By convention this is of the format xmlns:xsi="" so that parts of schema language used inside nexml (e.g. where a concrete subclass must be specified) are identified by the xsi prefix.
  • the nexml namespace prefix, by convention of the format xmlns:nex="", so that locations where nexml specific types are referenced (e.g. data type subclasses) these are identified by their nex prefix.
  • the default namespace, xmlns="", which is necessary for namespace aware processors (such as the NeXML-to-CDAO xslt stylesheet produced by an EvoInfo subgroup at the Spring 2009 hackathon).
  • the xml namespace prefix, required to be of the format xmlns:xml="". This may be used, for example, to specify the base address of the document (using the xml:base attribute).

Lastly, to associate the instance document with the nexml schema, it requires an attribute to specify the nexml schema location, and the namespace it applies to. This is of the format xsi:schemaLocation="". Notice that this attribute is a schema language snippet (identified by the xsi:prefix) that identifies a namespace and associates it with a physical schema location (

The root element can be annotated.


OTUS means Organizational Taxonomic Units. The otus element defines a collection of taxon. An otus is an instance of the Taxa class.


  • id - a file level unique id
  • label - a human readable description of the otus.


An otu element defines a taxon. An otu is an instance of the Taxon class.


  • id - a file level unique id
  • label - a human readable
  • class - takes the id of a class element. This attribute is optional.


A set is defined in NeXML with a class element. A class is an instance of the Class class.


  • id - a file level unique id
  • label - a human readable description of the class. A label is optional.


Trees in NeXML are described following the GraphML syntax by defining nodes and edges using the node and edge element. Phylogenetic tree or network is defined with the tree and network element respectively. A trees element is a conatainer for both tree and network. In a network the in-degree of nodes is lessened, so that a node can have multiple parents.

Attribute: id - a file level unique id otus - takes the id of an otus element defined previously label - a human readable description of the trees. A label is optional.


Phylogenetic trees are defined in NeXML with the tree tag. A tree is modeled by the AbstractTree class.


  • id - a file level unique id
  • xsi:type - defines the type of the tree. A tree can be:
  • label - a human readable description of the tree. A label is optional.

While an IntTree can only have integer edge length a FloatTree has an IEEE 754-1985 compliant floating point number for its edge length.


Phylogenetic networks are defined with the network tag. A network is modeled by the AbstractNetwork class and two concrete implementations exist.


  • id - a file level unique id
  • xsi:type - defines the type of the network. A network can be:
  • label - a human readable description of the tree. A label is optional.

The difference between a float and int network is same as that between a float and an int tree.


A node tag defines a node of a tree or a network. A tree node is modelled by the TreeNode class and a network node by the NetworkNode class; both of which inherit from the AbstractNode class.


  • id - a file level unique id.
  • otu - id of a previously defined otu element. This is optional.
  • root - takes true if the node is a root node, false otherwise. The tree is considered rooted, multiply rooted or unrooted based on how many root

nodes does it have.


An edge tag defines an edge in a tree or a network.


  • id - a file level unique id
  • source - id of the node to be served as the source
  • target - id of the node to server as the target
  • length - length of the edge

Edges can be of the following type based on the whether it is defined for a tree( int or float ) or a network( again, int or float ):


The characters element is used to define storage entities like molecular sequences, categorical data or continuous data. characters is modeled by the AbstractBlock class and twelve concrete types.


The characters element is a bucket of observations and the allowed parameter space for those observations. The Seqs type being a compact representation with states listed as tokens in a sequence, and the Obs type being a verbose representation with states marked up granularly.


The format element defines the the allowed characters and states in a matrix, and their ambiguity mapping. format is modeled by the AbstractFormat type. Within format is enclosed states and char definition.

Attributes: none.

On the basis of the type of its parent characters element, following concrete implementations of the format element is defined.

Atlease one states element must be defined for any implementation of format except ContinuousFormat. char must be defined for all type of format.


states defines states and their mappings. states element is of the AbstractStates type. state, uncertain_state_set, polymorphic_state_set may be nested within states.


  • id - a file level unique id

A concrete implementation of states is based on the type of its parent format element and is one of the following:

Continuous data is stateless, hence there is no states type corresponding to it. RestrictionStates implies only two states: presence( 1 ) or absence( 0 ). Naturally, two( and only two ) state are defined for the RestrictionStates type. All other types may have zero or more state defined for them.


A state is defined with state, polymorphic_state_set, uncertain_state_set. They are respectively instances of AbstractState, AbstractUncertainStateSet and AbstractPolymorphicStateSet.

A state can be of the following kind depending on the type of the parent states element:

Attribute: id - a file level unique id symbol - the value of the state.



A char specifies which states apply to which matrix columns. A char is of the AbstractChar type.

Depending on the type of the parent format element, a char can be an instance of the following type:

Attributes: With the type of the char in place, a char can take one or more of the following attributes:

  • id - a file level unique id is a must for all the char elements
  • states - the value being the id of a pre defined states element. Except the ContinuousChar type all chars take a states attribute.
  • codon - specify the codon position. DnaChar and RnaChar optionally take the codon attribute.


A matrix element hold the state observations. One or more row can be defined in a matrix. Depending on the characters type, matrix element can be of 2 abstract types each with 6 concrete type.

Attributes: none


The row element defines a single row of a matrix. Just like its parent matrix, row can be of two abstract types each with 6 concrete type.


Semantic Annotation

Fundamental data objects in NeXML can be annotated using RDFa. This way, the annotationsare directly available to any off-the-shelf RDFa parser but are also simple to integrate into non- RDF-aware processing libraries. The annotations are expressed using recursively nested meta elements, and are essentially triples whose subjects are identified by the about attribute. To specify that a NeXML element such as a tree is the subject, the about attribute and the id attribute of the element must match. This way, core NeXML elements can be converted to RDF (for example by using an XSL stylesheet), RDFa annotations can be extracted from the NeXML (using another stylesheet), and the two resulting graphs can be aligned by the subjects of their respective triples.

  • If the triple’s object value is a literal such as a string or a number, the exact data type is specified by the datatype attribute; these types are typically core XML schema types such as xsd:string for atomic types, or rdf:Literal for nested XML element structures that are to be parsed as opaque literals in an RDF graph. The object value is enclosed inside the meta element and the predicate is specified using the property attribute (whose value must be a CURIE). meta elements of this type are of the subclass nex:LiteralMeta.
  • If the triple’s object value is a remote resource, its location is specified using the href attribute. The predicate for this class of triples is specified as a CURIE using the rel attribute. meta elements of this type are of the subclass nex:ResourceMeta.
  • If the triple’s object value is a nested annotation, its predicate is specified as a CURIE using the rel attribute. Since this enclosing meta element is to be transformed into an anonymous RDF node, it needs to be identified as the subject of a reification by assigning it an about attribute (as per the RFa rules for identifying triple subjects).