Difference between revisions of "NeXML Elements"

From Phyloinformatics
Jump to: navigation, search
(Nodes)
(Edges)
Line 96: Line 96:
 
* <code>length</code> - length of the edge
 
* <code>length</code> - 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 ):
+
Edges can be of the following type based on whether it is defined for a tree( int or float ) or a network( again, int or float ):
 
* [http://nexml.org/nexml/html/doc/schema-1/trees/network/#NetworkFloatEdge NetworkFloatEdge]
 
* [http://nexml.org/nexml/html/doc/schema-1/trees/network/#NetworkFloatEdge NetworkFloatEdge]
 
* [http://nexml.org/nexml/html/doc/schema-1/trees/network/#NetworkIntEdge NetworkIntEdge]
 
* [http://nexml.org/nexml/html/doc/schema-1/trees/network/#NetworkIntEdge NetworkIntEdge]

Revision as of 01:29, 27 May 2010

Preface

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.

Root

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

Attributes:

  • 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="http://www.w3.org/2001/XMLSchema-instance" 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="http://www.nexml.org/1.0", 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="http://www.nexml.org/1.0", 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="http://www.w3.org/XML/1998/namespace". 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="http://www.nexml.org/1.0 http://www.nexml.org/1.0/nexml.xsd". Notice that this attribute is a schema language snippet (identified by the xsi:prefix) that identifies a namespace http://www.nexml.org/1.0) and associates it with a physical schema location (http://www.nexml.org/1.0/nexml.xsd).

The root element can be annotated.

OTUS

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

Attributes:

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

OTU

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

Attributes:

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

Class

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

Attributes:

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

Trees

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.

Tree

Phylogenetic trees are defined in NeXML with the tree tag. With NeXML two types of tree can be defined: int and float. While an IntTree can only have integer edge length a FloatTree has an IEEE 754-1985 compliant floating point number for its edge length.

Attributes:

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

With the AbstractTree class at the root of the hierarchy the following sub types are defined.

Network

Phylogenetic networks are defined with the network tag.

Attributes:

  • id - a file level unique id
  • xsi:type - can take any of the two values: IntNetwork, FloatNetwork
  • label - a human readable description of the tree. A label is optional.

A network is modeled by the AbstractNetwork class and two concrete implementations exist:

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

Nodes

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.

Attributes:

  • 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.

Edges

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

Attributes:

  • 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 whether it is defined for a tree( int or float ) or a network( again, int or float ):

Characters

The characters element defines comparative data. NeXML dictates that the allowed parameter space for the observations be declared with a format element and the actual observation with the matrix element; both nested within the characters element. Two broad observation categories are allowed: raw character sequences and granular character state observations. Under both these categories the NeXML provides means of describing observed DNA, RNA, Protein, Restriction, Standard, and Conitnuous data.

Attributes:

  • id - a file level unique id.
  • otus - takes the id of an otus element defined previously.
  • xsi:type - can be one of the following: DnaSeqs, DnaCells, RnaSeqs, RnaCells, RestrictionSeqs, RestrictionCells, StandardSeqs, StandardCells, ContinuousSeqs, ContinuousCells.
  • label - a human readable description of the character block. A label is optional

The AbstractBlock class is at the root of the characters hierarchy with the following subtypes:

Format

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.

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

states

states is a container for defined states and their mappings. A <states> can have zero or more state, uncertain_state_set, polymorphic_state_set elements.

Attributes:

  • id - a file level unique id

With AbstractStates class at the root of the hierarchy following concrete implementations are defined:

The type of states depends on the type of its parent format. 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.

state

AbstractState.

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.

polymorphic_state_set

AbstractPolymorphicStateSet

uncertain_state_set

AbstractUncertainStateSet

char

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.

Matrix

A matrix element holds 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

Row

The row element defines a single row of a matrix.

Attributes:

  • id - a file level unique id
  • label - a human readable description of the row. A label is optional.
  • otu - takes the id of an otu defined previously

Just like its parent matrix, row can be of two abstract types each with 6 concrete type.

seq
cell

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).