Data formats for modelling the spatial structure of chromatin based on experimental positions of nucleosomes

1.   Introduction

The spatial structure of chromatin has an important impact on gene regulation [1]. It is closely linked to the positions of nucleosomes in the genome, which are actively regulated by cells [2]. Computer models based on Monte Carlo, Brownian Dynamics or Molecular Dynamics can be applied to investigate the connection between the positions of nucleosomes and the spatial structure of chromatin [3],[4]. Computer models differ with respect to their resolution level, among other properties. For chains with many nucleosomes coarse-grained models are used, whereas molecular models with atomic resolution are more detailed and can represent single nucleosomes. In the present work, we study the usage of coarse-grained models, beginning with experimental determination of the positions of nucleosomes and ending with analysis of data from computer simulations. We focused at the level of a particular locus in the genome of a specific cell type. For all steps in this process, a multitude of bioinformatics and computational biophysics tools are applied that require different input formats and deliver various output formats, which makes the process tedious [5].

Figure 1.  Experimental, simulation and exchange domain features constitute a workflow for the simulation of chromatin based on nucleosome positions. Domains are shown as shaded areas, artefacts are represented by ellipses, workflow steps are symbolized by arrows. The newly developed public exchange formats are depicted as white ellipses. Artefacts used internally by our research group are shown as green ellipses, and external formats are indicated by red ellipses.

DownLoad: Full-Size Img PowerPoint

For the development of data formats we analysed the workflow used in our research group as an example. We identified three domains; experimental, simulation and analysis (Figure 1). Each domain involves several steps generating different artefacts.

The experimental domain is where chromatin is prepared and experimentally investigated. Nucleosomes are isolated from chromatin by applying e.g., micrococcal nuclease (MNase), and DNA fragments are isolated and sequenced to generate raw data in the form of short reads. Nucleosome positions are determined by mapping the obtained sequences to a reference genome using dedicated software [6]–[8] or existing nucleosome position databases [9],[10].These positions usually overlap, reflecting different positions in different cells from a sample, and experimental shortcomings. For computer models, individual non-overlapping nucleosome positions at a particular locus of interest are identified using appropriate software tools [11].

The simulation domain comprises all steps required to prepare and perform a computer simulation of a locus, and files contain the positions for a genomic region of interest. Additionally, a presetting file contains the settings for the 3D computer simulation model and the simulation process, such as nucleosome geometry, and parameters for potentials and simulations. Locus and presetting parameters are agammaegated into a single blueprint, and the simulation software creates a trajectory that contains the positions and orientations of the model elements for all simulation steps.

In the exchange domain, simulation results are made accessible for other research groups. This can be done by converting the trajectory into an easy to understand exchangeable format, although this requires greater disk space. Published data can then be used for visualisation and analysis.

Computer simulations are performed differently in different research groups [12],[13] utilizing various data formats and different chromatin models [14]–[16]. In the present work, we propose common data formats for presetting and locus parameters, and an exchange trajectory based on the Extensible Markup Language XML [17]. We believe that data can be expressed in a uniform way for different applications since the information contained within is essentially of a universal structure (Figure 2). We demonstrate the viability of the approach herein using a working example. The value for other groups will be corroborated by examples of Extensible Style Language Transformations XSLT [18] for analysis of exchange trajectories and transformation into other data formats. The XML Schema files and examples of XML files are published in open source repositories.

Figure 2.  Communication between different research groups. The yellow area defines the scope of a research group for performing computer simulations. The blue area defines the scope of other research groups analysing data from the yellow group. Presetting, locus and exchange trajectory files are placed at the interface of the blue and yellow areas to illustrate their use for communication between different research groups.

DownLoad: Full-Size Img PowerPoint

2.   Materials and methods

2.1.   Extensible Markup Language (XML)

The locus, presetting and exchange trajectory data formats are freely available if (1) the format specification is unrestrictedly accessible, (2) use must not be subject to any fees or licenses, and (3) it must be interoperable (i.e., the data format must be platform-, hardware- and software-independent). A data file must be correct in terms of its structure and content. The clarity and usefulness of data can be assessed by means of a defined syntax and grammar. Data for an exchange trajectory can be validated utilising a schema describing the validity of the type and value range. In order to ensure the usability of data, data formats must not only be machine-readable, but also human-readable (i.e., text instead of a binary format). Broad and advanced software support should be available (e.g., communities, libraries, etc.) to minimise the effort for the processing an exchange trajectory. All the above criteria are met by the Extensible Markup Language (XML [17]), specified by the World Wide Web Consortium (W3C) [19]). The aforementioned data schema can be defined using an XML Schema.

2.2.   UML-Class diagram

In software development, object-oriented methods are regularly used to model structure and behaviour. Unified Modelling Language (UML) is a widespread standard [20]. In this article we use UML class diagrams to model classes and their relations as foundation for the XML formats. See the UML standard [20] for details, since most software engineering textbooks and even Wikipedia use the outdated UML 2.0 standard.

2.3.   Classes/Objects

A class defines common properties of objects. In this context, objects are also referred to as instances of a class. For example, Figure 3 shows the nucleosome as a class with the properties pos and mpos. The text after the colon describes the type of the property e.g., integer. Instances of a class have its properties with concrete values. A class may be labelled as <abstract> which means that it cannot be instantiated, and only derived classes can be instantiated (s. section Associations between Objects). An example for an abstract class is the class Bead in Figure 6. Here, only DNABead and NuclesomeBead can be instantiated.

2.4.   Relations between Objects

In UML different relations between objects can be modelled.

An association denotes a link between two classes and is depicted by a line between the two classes. A filled dot at a class signifies that the other class of the association owns the association. As example in Figure 5 Presetting owns the association to ParameterList. If no numbers or symbols are attached to the end of the line one instance of a class is associated to the other. A star indicates that an indefinite number of instances of that class are associated. As example in Figure 4 the association between Locus and Nucleosome symbolises, that a single instance of Locus can have an association to an indefinite number of instances of Nucleosome.

Inheritance describes a specialisation of an object A to an object B. One also says that B is derived from A. This means, that B inherits the properties and associations of A and has additional properties or associations that are special to B. A line with an open triangle as arrowhead in direction of the generalization represents graphically an inheritance. An example for inheritance in Figure 6 the class DNABead is derived from Bead.

3.   Results

Herein, we propose common data formats for locus, presetting and exchange trajectory files. For illustration purposes, we demonstrate our format for the blueprint.

3.1.   Locus file data

A locus is located on a chromosome and is delimited by a first and a last nucleotide (base). It contains the positions of identified nucleosomes. The position of a nucleosome is defined by the positions of the two bases that delimit the nucleosome in the genome. The positions are derived experimentally, and these relations can be modelled in a straightforward way using two classes with a one-to-many association, as shown in Figure 3. The results are presented using an XML schema, as shown in Figure 4.

Figure 3.  Schematic structure of a locus modelled as a UML class diagram [20]. The locus is defined experimentally (experiment), as are and the chromosome (chromosome) of which it is a part and the positions of the two bases (firstbase, lastbase) that delimit the locus in the genome. Furthermore, a locus includes nucleosome objects, also delimited by two bases (pos, mpos) on the mapped nucleosome of the genome. The int and string data types are built into the XML schema.

DownLoad: Full-Size Img PowerPoint

Figure 4.  Locus schema (Extensible Markup Language-Schema file (XSD)).

DownLoad: Full-Size Img PowerPoint

3.2.   Presetting file data

The presetting file defines the settings for the simulation model and the simulation process. These are mostly the geometry of the DNA at the nucleosomes, the parameters of the different energy potentials, and the simulation parameters [12]. The geometry of a nucleosome is defined as the location and orientation of the DNA at the nucleosome, and can be described by seven angles (α, β, γ, δ, ε, φ and ζ), the segment length in the elastically relaxed state, and the distance between the centre of gravity of the nucleosome and the segment centre (Figure 7) [21]. The nucleosome potential is determined by selecting one of the models implemented in our simulation software (e.g., Lennard-Jones or Gay-Berne). To exclude invalid angles or distances, the data schema uses its own data types for floating point values. It is also possible to define additional simulation parameters. The presetting structure is shown schematically in Figure 5.

Figure 5.  Schematic structure of a presetting file as a Unified Modelling Language (UML) class diagram. The presetting file consists of nucleosome geometry (Geometry), nucleosome potential (potential), and simulation parameters (type_parameter_list). The nucleosome geometry consists of the seven angles, the equilibrated segment length, and the distance between the centre of gravity of the nucleosome and the segment centre. The nucleosome potential has been designed as an enumerator comprising Gay-Berne, Lennard-Lones and Zewdie models, and their variants [22]. The simulation parameters are described as generic key-value pairs. The data types type_non_negative_double, type_gt_zero_double and type_angle limit the value ranges of floating-point values. Double and string data types are built into the XML Schema.

DownLoad: Full-Size Img PowerPoint

3.3.   Exchange trajectory file data

An exchange trajectory file contains the results of a computer simulation, in particular the type, positions and orientations of all elements for different simulation steps. It includes information about the origin of the data (i.e., the conversion of a particular trajectory format, the time stamp of the conversion, the name and version of the converter, and the version of the data schema on which the exchange trajectory is based). The parameter list contains parameters for simulations as given in the presetting file. Parameters can be changed during the simulation (e.g., the temperature in simulations can be altered by applying simulated annealing) [22]. Altered parameters can be associated to configurations in simulation steps, at which point new parameter values are valid. The resulting structure of an exchange trajectory can be represented as a UML class diagram (Figure 7).

Figure 6.  Schematic structure of an exchange trajectory in the form of a UML class diagram. A trajectory consists of parameters (ParameterList) and configurations (ConfigurationList), and contains information such as creation time (date), the version of the XML schema (schema_version), as well as the converter name (program) and version (program_version). Parameters are key-value pairs (name, value). Configurations include a segment chain (BeadList) after a number of performed Metropolis Monte Carlo steps (mc_steps). Segment chains consist of nucleosomes (NucleosomeBead) and DNA segments. Each segment is assigned a position in the chain (id) and contains its angle of intrinsic twist (intrinsic_twist), its length at equilibrium (equilibrium_segment_length), its position and the vector describing it orientation (f_vector), the vector to the next bead (segment_vector), and the vector describing the equilibrium position of the next bead (bend_vector) [22]. A DNA segment also has a flag stating whether it is charged (charged). Nucleosome segments also include information on the centre of gravity (centre) and the normal unit vector (center_orientation_vector). The coordinates of a spatial point or vector are represented by a type (Vector3D). The data types type_angle and type_gt_zero_double are used to limit the ranges of floating-point values. The data types Boolean, double, string and unsignedInt used here are built into the XML schema.

DownLoad: Full-Size Img PowerPoint

Figure 7.  Model of a bead chain. ‘id’ represents the position of the bead in the chain, yellow circles indicate nucleosome bead positions, and blue circles indicate DNA bead positions. The nucleosome is represented by a red cylinder. The segment vector s→ points from one bead to the next bead. A local coordination system characterised by the normalised vectors u→,f→ and v→ (not shown) describe the orientation of a bead, where u→ is the normalized segment vector. Vector a→ (centre vector) describes the direction from the segment to the nucleosome centre, and d is the distance between them. Vector m→ determines the geometrical center of the nucleosome, and vector o→ describes the orientation of the nucleosome and is named the centre-orientation-vector.

DownLoad: Full-Size Img PowerPoint

3.4.   Example workflow

The workflow and the suitability of the schema files are demonstrated using an example locus. Eight nucleosomes are defined, and their positions are included in a locus.xml-file (Figure 8) for which correctness was validated by the corresponding XML-schema file (Figure 4). The simulation conditions are specified in a presetting.xml file (Figure 9).

Figure 8.  Example of an XML file describing eight nucleosomes. Only the first three are shown.

DownLoad: Full-Size Img PowerPoint

Figure 9.  Example of an XML file describing the presetting of the simulation. The ‘geometry’ defining the orientation of the DNA segments at the nucleosomes is shown with a single parameter value, while other parameters are omitted for clarity.

DownLoad: Full-Size Img PowerPoint

Figure 10.  Example of an XML file describing the blueprint.

DownLoad: Full-Size Img PowerPoint

The locus and presetting files were used to generate a blueprint.xml file (Figure 10). For the generation process, an internal tool from our simulation software was employed. The blueprint was used to generate a trajectory format suitable as an input for our simulation software. All steps described so far were performed prior to the simulation being executed. For the example simulation, 5000 Monte-Carlo steps were performed. The results are in the form of an extended trajectory file containing the generated configurations, and this is converted to an exchange trajectory XML file (Figure 11).

Figure 11.  Example of an XML file containing the exchange trajectory. Only selected parameters, beads and configurations are shown.

DownLoad: Full-Size Img PowerPoint

To demonstrate the possible usage of the file format, we show two examples utilising XSLT for analysis and transformation of a trajectory. In the first example, the end-to-end distance of the nucleosome chain is computed (Figure 12). This is the Euclidian distance between the starting point of the first segment and the end point of the last segment.

Figure 12.  XSL-Transformation file for calculation of the end-to-end distance of a polynucleosome based on a trajectory file. The results are shown in the bottom right corner.

DownLoad: Full-Size Img PowerPoint

Figure 13.  XSL-Transformation file for transformation of a trajectory to a VTF file (left). The VTF format makes it possible to visualise trajectory data using VMD-Viewer. The start of the resulting VTF file is shown on the right.

DownLoad: Full-Size Img PowerPoint

As a second example, we transformed the exchange trajectory into another trajectory format, VTF [23], which can be used with VMD-Viewer [24]. This can be done also easily with XSLT (Figure 13).

As an example for the whole workflow, we analysed a locus in mouse cells at chromosome 14 from base pair 47589000 to 47593031 (genome mm9). We evaluated experimental data from MNase-seq experiments of mouse embryonic stem cells (ESC) (GSM1004653), Neural Precursor Cells (NPC) (GSM1004652) and mouse embryo fibroblast (MEF) (GSM1004654) cells (BED-Files, zero based coordinates, right open interval) [25],[26]. Positions of nucleosome were determined applying the software NucPosSimulator using default settings [11] identifying between 22 and 24 nucleosomes (Table 1). We simulated the three cell types according to the described workflow with our simulation software [3] for 1000000 Monte Carlo steps, saved all 2000 steps and transformed each last configuration of the exchange trajectories for visualization with the raytracer POV-Ray [27] (Figure 14). Moreover, we analysed the average end-to-end distances of the chain. From analysis we excluded the first 25 values respectively 50000 steps needed for equilibration [28]. The results are presented in Table 1. Surprisingly, the chromatin model for MEF cells have longest elongation despite the largest number of nucleosomes caused by the positions of the nucleosomes.

Figure 14.  POV-Ray [26] visualization of snapshots from chromatin chains based on experimental data from MNase-seq experiments of mouse (A) ESC (GSM1004653 [25]), (B) NPC (GSM1004652 [25]) and (C) MEF (GSM1004654 [25]) cells from base pair 47589000 to 47593042) at chromosome 14 [26]. Red cylinders represent the nucleosomes and blue cylinder represent DNA.

DownLoad: Full-Size Img PowerPoint

Table 1.  Mean end-to-end distances, standard deviation and number of nucleosomes from Monte Carlo-simulations for chromatin chains based on experimental data from MNase-seq experiments of mouse (A) ESC (GSM1004653 [25]), (A) NPC (GSM1004652 [25]) and (C) MEF (GSM1004654 [25]) cells from base pair 47589000 to 47593042) at chromosome 14 [26].

Type of Cell	End-To-End Distance in nm	#Nucleosomes
ESC	90,50 ± 32,31	22
NPC	89,44 ± 29,30	23
MEF	97,68 ± 28,67	24

---

 | Show Table

DownLoad: CSV

4.   Discussion and conclusions

In this article, we present data formats for use in a workflow for computer simulation of chromatin based on experimental nucleosome positions that are easy to read and process. The formats establish inputs and outputs for the simulation domain as XML schemas. We used an example workflow on a locus to demonstrate the viability of our approach. Specifically, three XSL transformations demonstrated the ease with which the XML format can be processed. XML is superior to other text formats such as JSON [29] since it has standardised schema definitions and permits transformations using XSLT. Sophisticated libraries exist for nearly all programming languages. XML is the standard file format used by the systems biology community, especially the Systems Biology Markup Language (SBML) [30]. On the downside, XML files tend to require much more disk space than terser formats such as our internal trajectory format or binary formats (Table 2). These data formats are less readable, which hinders analysis by other groups. For publication of trajectories, we recommend only to publish uncorrelated configurations, and to compress the trajectory using standard tools such as bzip2 to minimise disk space.

Table 2.  Comparison of file size for Block-Trajectory, Exchange-Trajectory and Compressed Exchange Trajectory formats with an increasing number of configurations.

#Configurations	Block-Trajectory	XML-Trajectory	Compressed
100	2.55 Mb	26.5 Mb	895.6 Kb
1250	31.33 Mb	327.8 Mb	10.8 Mb
2500	63.00 Mb	655.1 Mb	21.9 Mb

---

 | Show Table

DownLoad: CSV

The proposed formats are limited to systems containing DNA and nucleosomes. Next-generation computer models include explicit models of linker histones [31], CTCF or Cohesin [32]. The format will be advanced in the future to include these elements. The proposed file format has possible shortcomings that may inhibit use by other groups. For example, the angles describing the geometry of nucleosomes are very specific for our model. However, chromatin has been investigated for more than 20 years using computer simulations [33], and a common file format for model and simulation results has not yet been proposed. Simulation data are usually not published, and the present work is the first to attempt to establish a common format. We intend to publish all future data in the proposed format and invite other groups to participate in this endeavour.

Data Availability

All mentioned files are included in the supplemental material and are publicly available at https://github.com/HOSTbioinformatics/ExchangeFormats