Descripción del formato de secuencias Standard European Vector

Descripción del formato de secuencias Standard
European Vector Architecture (SEVA) con el
lenguaje Synthetic Biology Open Language
(SBOL) para uso computacional.
Estudiante: Marta Carcajona Mata
MÁSTER EN BIOINFORMÁTICA Y BIOLOGÍA COMPUTACIONAL
ESCUELA NACIONAL DE SALUD – INSTITUTO DE SALUD CARLOS III
2014-2015
CENTRO NACIONAL DE BIOTECNOLOGÍA (CNB)
DIRECTOR DE LA TESIS: Ángel Goñi-Moreno
Enero - 2016
ÍNDICE
Resumen
2
Introducción
2
Objetivos
8
Material y métodos
9
Resultados
16
Discusión
22
Conclusiones
25
Bibliografía
25
1
Abreviaturas: SEVA, Standard European Vector Architecture; SBOL, Synthetic
Biology Open Language; EDA, Electronic Design Automation; GDA, Genetic Design
Automation; SBML, Systems Biology Markup Language
1. RESUMEN
El estándar in vivo Standard European Vector Architecture (SEVA), y el estándar
in sílico Synthetic Biology Open Language (SBOL), son dos formatos clave para el
desarrollo de la biología sintética. Sabiendo que la plataforma SEVA ayuda en la
elección de vectores plasmídicos óptimos para la deconstrucción y reconstrucción de
fenotipos procarióticos complejos; y que SBOL es más completo que otros lenguajes
estándar pre-existentes, en este estudio se muestra que la traducción del formato SEVA
al formato SBOL y las aplicaciones diseñadas en el proceso, favorecen el intercambio
de diseño de componentes biológicos para uso en simulación computacional y su
posterior construcción in vivo para ensayos experimentales. Además de describir ambos
estándares, este paper reafirma el beneficio potencial de los softwares con base SBOL
para la comunidad de biología sintética.
2. INTRODUCCIÓN
2.1 Biología sintética
La biología sintética es el diseño y construcción de nuevas partes biológicas,
dispositivos y sistemas, y el rediseño de sistemas biológicos naturales para aplicaciones
útiles. Esto ha permitido a los científicos re-diseñar sistemas ya existentes, ayudando así
a entender los principios de la biología y sus mecanismos subyacentes (Chopra y
Kamma, 2006).
La biología sintética puede ser enfocada de diversas maneras:
- Ingeniería de sistemas biológicos: la síntesis de componentes biológicos los
cuales se pueden ensamblar para crear circuitos biológicos que se comportan de una
forma predecible. Estos componentes biológicos pueden ser intercambiables dentro del
circuito. Por lo tanto, es un intento de llevar los conceptos existentes de la ingeniería,
tales como la estandarización de los componentes, la disociación de los problemas y la
abstracción de la información, a la biología (Endy, 2005).
- Rediseñar sistemas ya existentes: a través de la construcción de sistemas
biológicos, han aparecido algunas lagunas en nuestro actual entendimiento de la
2
biología debido a las diferencias encontradas entre el comportamiento predicho y el
observado. Esto, nos permite entender la biología de una forma más completa. Además,
podemos desarrollar de forma potencial sistemas biológicos menos complejos haciendo
que puedan ser usados para aplicaciones más específicas.
Además, el campo de la biología sintética está generando un tremendo interés
debido a la gran variedad de aplicaciones potenciales como la producción de fármacos
más baratos (Ro y col., 2006), optimización de la producción de biocombustibles
(Atsumi y Liao, 2008), tratamiento potencial de enfermedades como el cáncer
(Anderson y col., 2006) y desarrollo de circuitos genéticos (Bonet y col., 2013).
.
2.2 Estandarización de componentes biológicos
La biología sintética trata a los organismos biológicos como un nuevo medio
tecnológico con un set de características único, entre las que podemos encontrar la
habilidad de auto-repararse, evolucionar y replicar. Estas características crean sus
propios retos de ingeniería, pero son a su vez una fuente de aplicaciones potenciales en
muchos sectores (Khalil y Collins, 2010; Keasling. 2005). Aplicaciones como la
computación biomolecular (Benenson, 2012), ingeniería metabólica (Woolston y col.,
2013), o reconstrucción y exploración de la biología celular (Nandagopal y Elowitz,
2011; Mukherji y van Oudenaarden, 2009), requieren del diseño de nuevos sistemas
genéticos codificados.
Aunque el campo de la ingeniería genética lleva en uso 30 años, el campo
multidisciplinar de la biología sintética es el que trae consigo el concepto de
estandarización para la representación de datos tanto in vivo, como in sílico (Endy,
2005). Todos los campos de la ingeniería necesitan de un set de estándares que usen los
profesionales y permita un intercambio y uso de diseños de sistemas, dispositivos y
componentes. Además, un “formato estándar intercambiable” para diseños de biología
sintética mejoraría mucho la capacidad de reproducir resultados publicados.
Actualmente, es extremadamente difícil repetir diseños de la literatura porque suelen
estar descritos de forma imprecisa y con un lenguaje propenso a malentendidos. Incluso
se omite información y datos críticos debido a que se dan por hecho, como secuencias
finales, etc. Con inputs y outputs estándar definidos por una serie de reglas, la biología
sintética puede ser una disciplina de la ingeniería que permita el desarrollo de softwares
y de herramientas de diseño automatizadas (EDA).
Estas EDA han permitido la producción de muchos y más complejos circuitos
3
biológicos aportándonos una gran cantidad de información hasta la fecha. Para permitir
esta nueva era de la biología, se requieren muchas plataformas de automatización de
diseño genético (GDA) (Myers, 2009; Myers y col., 2009). Un primer paso crítico para
el uso de estas herramientas es conseguir un set de partes genéticas con las cuales se
puede construir un diseño. A pesar de que la mínima descripción para una de las partes
es la anotación de su secuencia de DNA, la representación fiel del comportamiento del
componente no es suficiente solo con su secuencia (Peccoud y col., 2011). Por ello, un
repositorio de partes ideal debería incluir información adicional acerca del componente
incluyendo datos como la cepa en la que se suele usar y el ambiente en el reside esta. En
última instancia, los workflows de biología sintética requieren la capacidad de codificar
información adicional más allá de una secuencia anotada, incluyendo, entre otras cosas,
información del contexto ambiental y experimental, los modelos computacionales de
comportamiento y las mediciones de características de rendimiento. Por lo tanto, se
requiere unos nuevos estándares para lograr estos objetivos.
Con el fin de que los diseños de biología sintética aumenten en complejidad, los
investigadores tendrán que hacer un mayor uso de herramientas de diseño
especializadas y repositorios de partes. La amplia adopción de un estándar de diseño
permitiría al creciente número de herramientas de software el uso de un único modelo
de workflow (Beal y col., 2012) para los biólogos sintéticos tanto de centros de
investigación como en la industria.
Un ejemplo de estandarización in vivo es el Standard European Vector
Arquitecture (SEVA), un estándar de vectores plasmídicos en bacterias gran negativas
(optimizado para pseudomonas) desarrollado en el laboratorio de Víctor de Lorenzo en
el Centro Nacional de Biotecnología; y un ejemplo de estándar in silico, es el Synthetic
Biology Open Language o SBOL, un emergente lenguaje que describe componentes
biológicos de forma muy precisa.
2.3 Standard European Vector Architecture (SEVA)
Como se ha mencionado previamente, la necesidad de unos formatos ya fijados
para la organización y designación de componentes biológicos se ha vuelto más que
evidente en esta era de sistemas y biología sintética (Canton y col., 2008; Endy 2009).
La plataforma “Standard European Vector Architecture” es un recurso web y un
repositorio de material clonado que ayuda en la elección de vectores plasmídicos
óptimos para la deconstrucción y reconstrucción de fenotipos procarióticos complejos
4
(Martínez-Garía y col., 2015).
La base de datos (SEVA-DB, http://seva.cnb.csic.es) es un recurso para
implementar estándares in vivo en el ensamblaje de plásmidos y que ayuda en la
creación de una nomenclatura común y no ambigua basada en un código numérico.
Además, la base de datos funciona como un índice para repositorio de secuencias
funcionales y de construcciones disponibles en la comunidad (Durante-Rodríguez y col.,
2014).
Esta SEVA-DB consiste en una base de datos relacional como el estrato en el
que se guardan los datos, una serie de módulos alojados en un servidor y una
presentación web con los estándares que se aplican para las construcciones. Las
correspondientes secuencias de cada plásmido son accesibles a través de un link a su
entrada en GenBank o a un archivo .gbk.
Adoptando un serie de reglas sencillas sobre cómo construir los plásmidos, el
estándar SEVA facilita la combinación de segmentos funcionales de DNA simplificando
así el análisis y la construcción de diversas bacterias gram negativas.
La base de datos fue diseñada para simplificar la elección de las partes de un
vector para aplicaciones específicas de manera que el usuario pueda, de forma sencilla,
decidir la mejor configuración del origen de replicación, resistencia a antibiótico y
cargo (Figura 1), además de poder contribuir a la plataforma con nuevas construcciones
y reportar problemas.
Esta plataforma SEVA tiene una serie de reglas para el montaje físico de los 3
componentes básicos (origen de replicación, marcador de selección y cargo), edición y
síntesis de las correspondientes secuencias de DNA y, como ya hemos mencionado
antes, incluye la implementación de un código alfanumérico que describe todas las
posibles combinaciones.
Estos principios establecidos permiten el intercambio de múltiples orígenes de
replicación y diversos marcadores de selección antibióticos para dar forma a un marco
para su posterior combinación con una gran variedad de cargos que se puede utilizar
para una gran variedad de aplicaciones. La colección principal de las construcciones que
están disponibles en base de datos de SEVA es solo un punto de partida para la
expansión de la plataforma. La adopción del estándar SEVA llena el gran vacío que
existe entre la capacidad actual de sintetizar DNA y la verdadera ingeniería de bacterias
predecibles y eficaces ya que está sujeto a un formato y una nomenclatura concisos,
minimalistas y estandarizados. Además, estas herramientas son compatibles tanto con
5
viejos, como con nuevos métodos de acoplamiento y clonaje de DNA.
Figura 1. Búsqueda de resultados representativos en la SEVA-DB. La página de inicio incluye una
cabecera con links dirigidos a la estructura del formato de los plásmidos, módulos, nomenclatura,
lista de plásmidos e información de contacto. El usuario recorre la lista de plásmidos, donde la
colección de construcciones está ordenada según el origen de replicación, marcador de selección
antibiótico, tipo de cargo y código SEVA. La página de cada plásmido tiene links a su
correspondiente código en GenBank y la secuencia completa del vector.
2.4 Synthetic Biology Open Language (SBOL)
El Synthetic Biology Open Language (SBOL) ha sido desarrollado como un
estándar para la especificación e intercambio de diseños biológicos en biología sintética
(Galdzicki y col., 2012), siendo más completo que otros lenguajes estándar preexistentes. Esto permite a biólogos sintéticos e ingenieros genéticos intercambiar
diseños, mandar y recibir diseños de centros de biofabricación, facilitar el
almacenamiento de diseños en repositorios y representar diseños en publicaciones
(Galdzicki y col., 2014). Para cumplir estos retos, SBOL trae consigo un formato de
6
estandarización para el intercambio electrónico de información, tanto estructural como
funcional, de diseños biológicos. Este modelo se encuentra actualmente en una versión
beta 2.0 e incluye:
- Representación de componentes DNA y no-DNA como RNA, proteínas,
pequeñas moléculas y otros componentes.
- Descripción de aspectos de comportamiento de los diseños biológicos como las
interacciones moleculares y su relación con los modelos matemáticos correspondientes
descritos en otro estándar in sílico como es el System Biology Markup Language
(SBML, http://sbml.org/Main_Page).
- Asocia estructura y función.
Previos formatos de descripción de secuencias de ácidos nucleicos carecen de
características claves. Por ejemplo, el formato de codificación simple de los FASTA no
tiene en cuenta el diseño. Un ejemplo de formato más sofisticado como es el de
GenBank o Swiss-Prot tiene una anotación muy plana de las características de la
secuencia. Esto se adapta bien para la descripción de sistemas naturales, sin embargo,
no es capaz de representar el diseño de múltiples capas que suelen presentar los sistemas
de ingeniería (Figura 2).
Figura 2. Representación gráfica de los formatos FASTA, GenBank y SBOL. SBOL 2.0 representa
tanto la estructura como la función de un diseño genético de una forma modular y jerárquica.
7
3. OBJETIVOS
Teniendo en cuenta todos los antecedentes expuestos en la introducción, y dado que,
tanto los plásmidos SEVA como el lenguaje SBOL juegan un papel importante en el
desarrollo de la biología sintética, el objetivo de este trabajo se centra en la adaptación
de la plataforma SEVA en lenguaje SBOL para facilitar el intercambio de información
de componentes biológicos y su uso en aplicaciones de diseño automatizadas. Para ello,
se realizarán además, aplicaciones para un mejor acoplamiento de ambos estándares.
4. MATERIAL Y MÉTODOS
4.1 Java y Eclipse
Java es un lenguaje de programación de propósito general, concurrente,
orientado a objetos que fue diseñado específicamente para tener tan pocas dependencias
de implementación como fuera posible. Su intención es permitir que los desarrolladores
de aplicaciones escriban el programa una vez y lo ejecuten en cualquier dispositivo, lo
que quiere decir que el código que es ejecutado en una plataforma no tiene que ser
recompilado para correr en otra.
Eclipse es un programa informático compuesto por un conjunto de herramientas
de programación de código abierto multiplataforma. Esta plataforma, típicamente ha
sido usada para desarrollar entornos de desarrollo integrados como el IDE
de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega
como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse).
Todas las aplicaciones desarrolladas para este proyecto han sido programadas en
java y en eclipse.
4.2 Estructura de los plásmidos SEVA
Como ya hemos mencionado antes, el formato SEVA conlleva una serie de
reglas para el acoplamiento físico de los tres componentes básicos de los vectores
plasmídicos (origen de replicación, marcador de selección y cargo), además de una
nomenclatura para designar a las construcciones correspondientes.
Cada secuencia no artificial usada en las construcciones ha sido previamente
minimizada a la menor secuencia de DNA que mantiene la función. A las secuencias se
les extraen cualquiera de las dianas de estas enzimas restricción: HindIII, PstI, XbaI,
BamHI, SmaI, KpnI, SacI, SalI, EcoRI, SfiI, SphI, AatII, AvrII, PshAI, SwaI, AscI,
8
FseI, PacI, SpeI, SanDI y NotI. Esto es debido a que hay que editar las los componentes
para eliminar las secuencias que se encuentran en la estructura básica de los plásmidos
SEVA. Finalmente, cada módulo es flanqueado por unas dianas de restricción concretas:
los orígenes de replicación por FseI y AscI; los marcadores de antibiótico por SwaI y
PshAI; y el cargo por PacI y SpeI (Figura 3).
Figura 3 – Organización global de la estructura de los plásmidos SEVA. (A) Los vectores SEVA
están formados por tres regiones variables: un cargo (azul), un origen de replicación (verde) y un
marcador antibiótico (morado). Las enzimas usadas para cambiar esas regiones variables están en
el mismo color que su módulo correspondiente. Estos módulos además, están separados por 3
regiones que tienen todos los vectores, los terminadores transcripcionales T0 y T1 y origen de
conjugación oriT. (B) La estructura en detalle del cargo default. Contiene las enzimas de un
polylinker pUC18 desde EcoRI a HindIII. Enzimas adicionales como SfiI, AvrII y NotI están fuera
del polylinker por propósitos específicos de clonación.
9
La primera región variable de los plásmidos SEVA es el marcador de selección
de antibiótico. El segmento de DNA que lleva estos marcadores incluye el gen
estructural para el gen de resistencia a un antibiótico y su promotor nativo flanqueados
por SwaI y PshAI. El tamaño de este segmento de ADN varía entre 0.8 y 1.3 kb,
dependiente del marcador específico.
La segunda parte variable de los vectores SEVA es el segmento de DNA que
contiene el origen de replicación del plásmido, el cual es producido e insertado en el
plásmido entre AscI y FseI. Los distintos orígenes de replicación varían en tamaño
desde 1.6 kb hasta 3.7 kb y dota a los plásmidos de distinto copy number.
Por último, la tercera región variable de los plásmidos SEVA es la porción de
DNA que lleva la función principal del vector. Esta sección se ha designada como
“cargo” (Martínez-García y col., 2011), y está flanqueado por PacI-SpeI. Esta región
confiere un propósito específico al plásmido (clonación, expresión de genes
heterogéneos, fusiones con genes reporteros o integración cromosómica). El cargo
default (Figura 2B), consta de un polylinker básico formado por un array de sitios de
clonaje únicos de pUC18, sitios SfiI/AvrII y NotI upstream del sitio de corte de EcoRI y
un segundo sitio NotI downstream del sitio de HindIII. Los sitios F24 y R24 están en el
cargo default para permitir la verificación de fragmentos insertados.
Además del diseño estándar de las construcciones, el formato SEVA designa de
forma inequívoca cada vector con la nomenclatura. Todos los vectores son llamados
pSEVA seguido de una cifra de 4 dígitos. El primero es el marcador de resistencia a
antibiótico, el segundo el código para el origen de replicación, el tercero para el cargo
(en los casos en los que hay una variante del mismo cargo, se añade una letra mayúscula
al número), y por último, la cuarta posición es para los gadgets, los cuales se designan
con una letra griega minúscula (Figura 4).
10
Figura 4 – Nomenclatura SEVA. Los vectores incluyen 4 módulos (marcador de resistencia a
antibiótico, origen de replicación, cargo y gadget), los cuales están representados por un código de 4
dígitos.
4.3 APE (A Plasmid Editor)
APE es un software para ver, editar y analizar secuencias de plásmidos. Aunque
en su mayoría se ha usado para poder anotar zonas de restricción de distintas enzimas,
también permite labores de edición más avanzadas.
11
Con el objetivo de generar una base de datos de secuencias de los componentes
de los vectores SEVA, editamos las secuencias completas de los plásmidos haciendo uso
de APE. A partir de estas secuencias totales, al remarcar la secuencia de las enzimas que
flanquean cada componente, pudimos anotar la información de cada uno con su
secuencia sin errores. Además, gracias a esto, pudimos observar la presencia una serie
de bases que se intercalan en algunos casos junto a ciertos antibióticos y a T0 y no
estaban registradas en la plataforma SEVA. Hemos detectado la presencia de 3 de estas
anomalías, a las que hemos llamado Scars:
- ScarT0 junto a T0: CAATAATTACG
- ScarSmTc junto a Estreptomicina y Tetraciclina: ATTTACGT
- ScarKmGm junto a Kanamicina y Gentamicina: CGCGCGTTGTC
4.4 Librería libsbolj
Libsbolj es una librería en fase beta que contienen la interfaz en java y su
implementación para SBOL. La librería trae también una API para trabajar con objetos
SBOL y la funcionalidad de leer y escribir documentos SBOL como archivos
XML/RDF. Libsbolj está organizado con el software Apache Maven, el cual administra
como se construye el proyecto gracias a un archivo de información .POM. Las clases
usadas de la librería son:
- ComponentDefinition: Describe la estructura y aspecto físico de las entidades
designadas como DNA, RNA, y proteínas, además de otras entidades con las que
interaccionan, como pequeñas moléculas o propiedades del ambiente. También describe
las relaciones físicas entre subcomponentes, información sobre la orientación y el rango
(Figura 5).
Figura 5: Diagrama UML de la clase ComponentDefinition y sus propiedades asociadas.
12
- Component: Hace función de subcomponente. Incorpora información de
componentDefininition hijo y pertenece a un ComponentDefinition padre.
- Location: Específica las coordenadas y orientación de un componente genético
como moléculas de DNA o RNA o un residuo o sitio de otras macromoléculas como,
por ejemplo, proteínas (Figura 6).
Figura 6: Diagrama UML de la clase Location y sus propiedades asociadas.
- SequenceAnnotation: Describe la localización (clase Location) de subsecuencias dentro de la secuencia total del ComponentDefinition padre. Va asociado a
objetos Component (Figura 7).
Figura 7: Diagrama UML de la clase SequenceAnnotation y sus propiedades asociadas.
- SequenceConstraint: Describe la posición espacial relativa y la orientación de
dos objetos Component que se encuentran dentro del mismo ComponentDefinition
(Figura 8).
13
Figura 8: Diagrama UML de la clase SequenceConstraint y sus propiedades asociadas.
- MapsTo: crea un enlace entre dos ComponentDefinition de manera que pueden
compartir información. Necesita la información del objeto local y del objeto remoto
(Figura 9).
Figura 9: Diagrama UML de la clase MapsTo y sus propiedades asociadas.
- Sequence: Generalmente representa una serie continua de monómeros en un
polímero macromolecular como son el DNA, RNA o proteínas. También puede hacer
referencia a los átomos y uniones de una molécula con una estructura no-lineal (Figura
10).
Figura 10: Diagrama UML de la clase Sequence y sus propiedades asociadas.
14
Una vez que se ha diseñado un componente usando SBOL, se escribe en lo que
la librería denomina un SBOLDocument. Este objeto permite escribir un archivo de
salida XML o RDF con la información contenida en el SBOLDocument. Para
comprender este tipo de archivos, es necesario subirlo a alguna aplicación de diseño que
use el lenguaje SBOL como base, de manera que generará el diseño gráfico del
plásmido a través del archivo.
Para entender mejor la librería, podríamos decir, por ejemplo, que un Component
de DNA puede ser un segmento de DNA que tenga una función particular como podría
ser promoter, open reading frame, ribosome binding site y terminator. El tipo de
Component se indica usando un tipo del sequenceOntology (Eilbeck y col., 2005). Un
Component también puede ser una secuencia que está compuesta por otros objetos
Component. Cada SequenceAnnotation indica la localización (Location) del principio y
el final de la secuencia y la hebra en la que se encuentra (en el caso de componentes de
DNA). El orden de las anotaciones se organiza con el método precedes.
Figura 11: Clases principal del estándar SBOL 2.0. y sus relaciones. Las cajas verdes son clases toplevel y las naranjas son de apoyo. Flechas sólidas indican propiedad y las irregulares indican que
una clase se refiere al objeto de la otra clase.
4.5 Biojava
Biojava es un proyecto público dedicado a implementar un marco de java para
procesar datos biológicos. Trae retinas de análisis y estadística, parsers para distintos
formatos de archivo y permite la manipulación de secuencias. El objetivo de biojava es
facilitar el desarrollo a los bioinformáticos.
Con los métodos de GenbankProxySequenceReader y GenbankReaderHelper,
pudimos verificar que la secuencia total de salida de un plásmido SEVA, ya en lenguaje
15
SBOL, correspondía con la secuencia subida a la base de datos de SEVA. El primer
método lo hace a través del código de genbank, y el segundo requiere tener descargado
archivo .GBK que contenga la información del plásmido.
5. RESULTADOS
5.1 Adaptación de los plásmidos SEVA a lenguaje SBOL
Como hemos explicado antes, la necesidad de crear estándares útiles para la
biología sintética ha impulsado el objetivo final de este proyecto: traducir toda la base
de datos de la plataforma SEVA a lenguaje SBOL y hacerlo accesible para todo el
mundo. El principal problema que encontramos para la asociación de este estándar in
vivo, SEVA, y el estándar in sílico, SBOL, era la forma de implementar ambas
estructuras.
En primera instancia, comenzamos describiendo cada componente de la base de
datos SEVA de forma individual, pero viendo la complicación y el tiempo que habría
que invertir para ello, se decidió hacer algo más práctico y con más potencial: la
creación de dos aplicaciones que permitiesen la traducción instantánea de cualquier
plásmido SEVA a lenguaje SBOL a través de línea de comando.
Ya que, como hemos visto previamente, los plásmidos SEVA solo tienen 3
regiones variables (sin incluir el gadget), decidimos crear un documento SBOL con
todos los componentes fijos (llamado Template) y otro documento con todas las
posibilidades del cargo, orígenes de replicación y marcadores de antibiótico (llamado
Collections).
El
resultado
final
de
la
adaptación
conlleva
la
creación
de
un
ComponentDefinition por cada componente de los plásmidos SEVA, los cuales a su vez,
son sub-componentes (objeto Component) de un ComponentDefinition de un nivel
superior llamado SEVAXXX. Además, se crearon objetos independientes Sequence para
cada secuencia.
Cada ComponentDefinition trae información de nombre, descripción, la
secuencia a través de un enlace a su objeto Sequence correspondiente y su rol de
SequenceOntology. Por último, se añaden SequenceConstraints que determinan el orden
de los componentes a través del método precedes.
Respecto a los MapsTo, hemos creado 3 ComponentDefinition “vacíos” que
representan a cada región variable. Estos ComponentDefinition neutros, y haciendo uso
16
de este método, están asociados a su cargo, origen de replicación y antibiótico concreto
según el SEVA que estemos construyendo. Además, están englobados en un
ComponentDefinition mayor llamado RegionVariable para agrupar todos los objetos
MapsTo.
El ComponentDefinition padre (SEVAXXX), aparte de englobar toda la
información del plásmido (sub-componentes, sub-secuencias, MapsTo), trae una
SequenceAnnotation propia con el origen y fin de la secuencia total.
Figura 11: Diagrama UML del resultado final de la adaptación de SEVA a SBOL.
Por ejemplo, tenemos el ComponentDefinition AscI el cual es a su vez
Component del ComponentDefinition padre pSEVA354. Dentro de la información de
ComponentDefinition, AscI va a tener una descripción, un título y un ID. Además, tiene
una SequenceAnnotation que determina su Location (start 6428 y end 6435). El
ComponentDefinition pSEVA354 tiene englobadas todas las SequenceConstraints, las
cuales refiere a un objeto Component local y otro objeto Component remoto, en este
caso AscI y T1.
17
5.2 Aplicaciones
Se han desarrollado dos aplicaciones para generar cualquier plásmido SEVA en
lenguaje SBOL (Figura 12). La primera y más importante es el constructor de SEVAs en
lenguaje SBOL (SBOLpSEVA.jar) y la otra es la encargada de generar un cargo
personalizado a partir de cargo default de la base de datos de SEVA (CustomCargo.jar).
Como ya hemos mencionado, la primera aplicación construye un plásmido
SEVA en lenguaje SBOL. Al ejecutar la aplicación a través de línea de comando, el
display te preguntará que vector SEVA te gustaría construir (con o sin gadget). Esto dará
lugar a un SBOLDocument con toda la información del SEVA, el cual puede ser subido
a distintas aplicaciones con base SBOL. El .JAR de la aplicación contiene los siguientes
scripts:
- Template: este script se encarga de generar un SBOLDocument que crea un
ComponentDefinition para cada componente fijo de los SEVA (incluyendo los 3
ComponentDefinition vacíos a los que se le hará mapsTo con su región variable
correspondiente) y objetos Sequence para sus respectivas secuencias. Incluye también el
gadget y los scars aunque no se consideren literalmente fijos. En un nivel superior, crea
un ComponentDefinition llamado pSEVA en el cual todos estos ComponentDefinition
anteriores pasan a ser a su vez sub-componentes (objeto Component). El motivo de esto
es que como se tratan de objetos que van estar incluidos en todos los vectores, en la
aplicación principal solo será necesario llamar a ese objeto pSEVA para que se incluya
todo en el archivo de salida. Además, se crean tantas sequenceConstraints en el objeto
pSEVA como lo permita la librería (ver Discusión). También tenemos los componentes
VariableRegion, antibiotic (general), OriV (general) y cargo (general). Estos 3 últimos
componentes sirven para que en la salida final se creen tres objetos MapsTo bajo el
componente VariableRegion que van a contener cada uno el componente general y el
Component concreto al que van unidos (objeto local y objeto remoto).
- Collections: genera un SBOLDocument en el que existen los objetos Sequence
y ComponentDefinition de todos los posibles antibióticos, cargos y OriVs.
- App: El script principal del paquete. Hace uso de los .RDF que han generado
previamente los scripts Template y Collections. Hacemos dos inputStreamReader
solicitando el número de SEVA requerido y la presencia o no de gadget. Es necesario
crear 4 objetos SBOLDocument, 3 para leer la salida (archivos .RDF) de los 2 archivos
anteriores (Template.rdf y Collections.rdf) y el del paquete de CustomCargo
(CustomCargoApp.rdf); y un último para escribir el resultado final, el archivo que se
18
generará como de la salida de la aplicación.
Debido a que aún no está implementado en la librería la extracción en orden de
de los componentes de los archivos Template y Collections, es necesario, indicar en el
script de la aplicación cuál es el orden establecido de los componentes del plásmido
según el estándar SEVA. Mientras se van añadiendo los ComponentDefinition en orden
en el SBOLDocument de salida, un contador va creando y añadiendo como
SequenceAnnotation la posición de comienzo y final para la secuencia de cada
componente; y para un objeto secuencia total. Es en esta aplicación en la que los
componentes vacíos de MapsTo son asociados a su componente concreto según la
petición por consola del usuario. Finalmente, escribe es un archivo .RDF toda la
información. Si el plásmido que pide el usuario no se encuentra en la lista de los
plásmidos ya sintetizados en el laboratorio, el display mostrará el siguiente warning:
“Not contained in the Cannonical Seva Plasmid List”.
Por último, la aplicación contiene una validación a través de biojava (está
comentado ya que la validación se hizo a nivel de desarrollo, por lo que hay que entrar
en el script para usarlo) que comprueba que la secuencia total está correctamente
construida. Esta validación, como se ha explicado antes, se basa en comparar la
secuencia con su archivo de Genbank, tanto añadiendo el número de identificación,
como subiendo el archivo .GBK.
La segunda aplicación diseña un cargo personalizado bajo las instrucciones del
usuario. La herramienta necesita de al menos un SBOLdocument con la información de
los nuevos componentes. Esta información tiene que estar compuesta por el cassette del
cargo customizado que quiera el usuario y las enzimas de restricción que lo rodean, en
formato SBOL, para que pueda realizarse el análisis y edición de secuencias pertinente
para la personalización del cargo default. Una vez que la aplicación detecta de qué
enzimas se trata, hará un intercambio de secuencias con el cargo default y generará otro
SBOLDocument con el cargo completo personalizado. Este SBOLDocument puede ser
utilizado por la primera aplicación para generar un plásmido SEVA personalizado en
forma de documento SBOL.
Debido a que, como hemos mencionado antes, al leer el documento SBOL con el
cassette y las enzimas que lo rodean no se disponen en el orden correcto (ni se han
escrito previamente en el orden correcto), hemos tenido que crear una serie de scripts
con métodos propios para arreglar esto. El .JAR contiene:
- Enzyme: El archivo Enzyme.java contiene un clase que se usará en el script
19
principal que contiene los atributos bioStart, bioEnd, ID y sequence (con sus getters y
setters correspondientes).
- Cassettes: Esta clase tiene los mismos atributos que la anterior (con sus getters
y setters) y un método createCassetteSeqs que al pasarle un SBOLDocument como
parámetro te devuelve un array con todas las secuencias que contiene ese documento.
Además, tiene otro método que hace que cuando apliques en la clase principal
(en el Main de app.java) el método sort (para ordenar arrays) en un array de objetos
Cassette, te lo ordene por el atributo bioStart.
- App: Comienza con un bucle que crea tantos SBOLDocument como parámetros
le pases por línea de comando (cassettes) y luego otro SBOLdocument para el archivo
final de salida. A continuación creamos tantos objetos enzyme como enzimas tiene el
cargo, le seteamos todos sus atributos y las metemos en un array de objetos enzyme.
Paralelamente creamos un string llamado totalSequence con la secuencia del cargo por
defecto.
Tras esto, ejecutamos el método createCassetteSeqs sobre los SBOLDocument
que contienen los cassettes y guardamos cada array de strings (secuencias) de los
cassettes en un ArrayList llamado sequenceList.
Ahora mapeamos esos arrays de secuencias en la totalSequence y seteamos la
secuencia y su bioStart en otro arrayList de objetos Cassettes. Finalmente recorremos la
totalSequence y, mientras detecta las posiciones en las que van los cassettes por su
atributo bioStart, va creando la secuencia final ya modificada.
Figura 12 – Diagrama de uso de las aplicaciones SBOLpSEVA.jar y CustomCargo.jar
20
El resultado final es un SBOLDocument con un objeto ComponentDefinition del
cargo personalizado y su secuencia ya editada. Como hemos mencionado previamente,
este documento podrá ser usado por la aplicación principal para generar el plásmido
SEVA con un cargo que no esté incluido en las listas del repositorio de SEVA.
5.3 Ejemplos de uso
Supongamos que un usuario desea la información del plásmido SEVA 231.
Desde la terminal, deberá colocarse en la carpeta en la que estén las aplicaciones
(SBOLpSEVA.jar y CustomCargo.jar) y los .RDF necesarios (Template.rdf,
Collections.rdf) y ejecutar el siguiente comando:
$ java –jar SBOLpSEVA.jar
El display le pedirá que elija el pSEVA y escribirá 231:
Choose your pSEVA: 231
A continuación pedirá la información sobre el gadget y escribirá N:
Gadget attached? Y or N: N
Esto va a devolver, a la misma carpeta en la que se encuentre, el archivo
pSEVA231.rdf con toda la información sobre el plásmido. Este plásmido además puede
solicitarlo al laboratorio de Víctor de Lorenzo sin ningún coste (es un proyecto opensource), teniendo así la versión in sílico para simulación, e in vivo para experimentación
y con libertad de uso.
Ahora el usuario decide modificar su cargo con una serie de cassettes usando
nuestras aplicaciones. Siguiendo en la misma carpeta que nos encontrábamos, es
necesario que estén también los .RDF con los cassettes que quiera añadir en formato
SBOL (RFPcassette.rdf y PEM7cassette.rdf) y ejecutar:
$ java –jar CustomCargo.jar RFPcassette.rdf PEM7cassette.rdf
Esto generará un archivo CustomCargoApp.rdf que puede ser usado por la
aplicación principal de la siguiente manera:
$ java –jar SBOLpSEVA.jar
Choose your pSEVA: 23Custom
Gadget attached? Y or N: N
Obteniendo así el archivo pSEVA23Custom.rdf con la versión personalizada del
plásmido. Este usuario además puede sintetizar la versión in vivo de su plásmido y
21
mandarlo al laboratorio donde se sintetizan los SEVA para que lo puedan replicar y
añadirlo a la base de datos para que pueda ser solicitado por otros centros en el futuro.
Esto promueve una retroalimentación que beneficia a ambas partes.
6. DISCUSIÓN
La estandarización de modelos biológicos está siendo un punto clave para el
desarrollo de la biología sintética hoy en día. Estándares in vivo como SEVA, permiten
que cada porción de DNA de los plásmidos esté minimizada, caracterizada, editada de
manera que no haya problemas en secuencia ni funcionalidad y flanqueada por dianas
de restricción muy concretas (Martínez-García y col., 2015). Este estándar biológico tan
concreto, permite que no exista incertidumbre alguna acerca del plásmido que está
siendo usado, permitiendo así la combinación de todas sus partes variables en un marco
idóneo.
Respecto a SBOL, además de la gran flexibilidad que tiene a la hora de
describir componentes genéticos, comparado con otros formatos, este proyecto ha
permitido validar la versión 2.0 y contribuir a un superior desarrollo. Aún así, hemos
encontrado funcionalidades que, al ser una versión beta, tenían algunos errores. Como
que la librería no permite, cuando aplicas SequenceConstraint, que un objeto pueda
estar flanqueado en unas ocasiones por un Component y en otras por otro. O que, como
ya hemos descrito antes, no es capaz de leer un SBOLDocument en orden. Aún así, son
errores que actualmente se están corrigiendo.
Aún con esto, podemos afirmar que SBOL es un estándar interdisciplinar, ya que
no solo es un estándar para aplicaciones in vivo o para aplicaciones in sílico, sino que
realiza un trabajo intermedio entre la biología y la bioinformática con sus herramientas
adaptadas a cada rama.
Desde la aparición de SBOL, un gran número de herramientas GDA han
adoptado este lenguaje como base para sus diseños. Debido a que, como se ha explicado
previamente, la salida de un archivo SBOL es un documento .XML de difícil
comprensión, y no todo el mundo tiene los conocimientos de programación necesarios
para describir a través de la librería sus diseños con SBOL, las herramientas
automatizadas en las que hemos hecho hincapié antes juegan un papel de vital
importancia. Estas aplicaciones permiten diseñar un componente SBOL a través de un
display con representaciones gráficas de todas las partes que puede tener un plásmido.
Si ya posees tu componente en formato SBOL en el archivo .XML o .RDF, puedes
22
subirlo a estas aplicaciones y seguir modificándolo desde ahí.
Además, algunas de estas herramientas te ofrecen la posibilidad de usar SBML,
otro lenguaje estándar que posee información sobre los algoritmos de los modelos
bioquímicos, teniendo así toda la información funcional, estructural y matemática del
componente en un único documento. Esto facilita enormemente el intercambio de datos
con laboratorios y centros de biofabricación.
Un ejemplo de herramienta de diseño automatizado de componentes biológicos,
que utiliza SBOL como base, es Cello (http://www.cellocad.org/), una herramienta muy
utilizada actualmente, desarrollada por el MIT y en la que colabora el laboratorio de
Víctor de Lorenzo. Cello, a partir de las funciones que le pide el usuario, y con lenguaje
SBOL como base, diseña circuitos (Figura 13). Una vez que está completo, busca en
bases de datos y repositorios el componente biológico idóneo para la construcción según
los datos descritos en formato SBOL, y manda la información del circuito completo a
centros de biofabricación, los cual insertarán esas partes que conforman el circuito en un
vector. El problema y la dificultad que reside en esto, es que, aunque el circuito pueda
estar perfectamente diseñado, su interacción con ese vector o con la célula podría no
permitir su funcionamiento óptimo.
Ahora que SEVA tiene todos sus componentes y plásmidos traducidos al formato
SBOL y, como ya hemos explicado, no existe incertidumbre con los vectores SEVA y la
célula con la que interacciona, este tipo de errores se corregirían. De manera que si las
puertas lógicas del circuito no son las esperadas usando un vector SEVA, la única
posibilidad es que el circuito esté mal, no como podría pasar con vectores de otros
centros de fabricación.
Figura 13 – Ejemplo de diseño de circuitos usando Cello
23
Otra herramienta a destacar es SBOL Visual (VisBOL, http://visbol.org/design/),
un programa de representación gráfica de diseños biológicos que aún no tiene las
actualizaciones necesarias para su uso con SBOL 2.0 y no incluye la representación de
plásmidos (en curso).
Figura 14 – Ejemplo de diseño de componentes usando SBOL Visual
Otro objetivo en curso, y
que ha surgido a partir de este proyecto, es la
colaboración con bases de datos de componentes biológicos en formato SBOL 2.0. De
esta manera, la exportación, importación e intercambio de componentes se facilita.
Además, gracias a la traducción de la plataforma SEVA, todos sus plásmidos e incluso
sus componentes individuales se encontrarán en estas bases de datos, expandiendo así
su disponibilidad y funcionalidad.
Actualmente estamos en contacto con los desarrolladores de las bases de datos
que quieren albergar SBOL, como es SBOLhub (http://www.sbolhub.com/), la cual se
encuentra actualmente en desarrollo por los creadores de SBOL: o SYNBIS del Imperial
College, debido a que quieren hacer uso de las aplicaciones que hemos desarrollado
para facilitar el diseño personalizado de SEVAS, no solo del cargo sino de todo el
plásmido.
24
7. CONCLUSIONES
- La biología sintética necesita de estándares, no solo in vivo como es SEVA, pero
también estándares de representación y conceptualización in sílico de dispositivos,
como es SBOL.
- Es muy importante asociar estos estándares
- La funcionalidad de los SEVAs se expande no solo al diseño de los cargos, sino al
diseño de plásmidos enteros, haciendo que la plataforma SEVA sea más accesible.
8. BIBLIOGRAFÍA
Anderson, J.C., Clarke, E.J., Arkin, A.P., 2006. Environmentally controlled invasion of
cancer cells by engineering bacteria Journal of Molecular Biology 35:619–627.
Atsumi, S., Liao, J.C. 2008. Metabolic engineering for advanced biofuels production
from Escherichia coli. Current Opinion in Biotechnology 19:414–419.
Beal, J., Weiss, R., Densmore, D., Adler, A., Appleton, E., Babb, J., Bhatia, A.,
Davidsohn, N., Haddock, T., Loyall, J., Schantz, R., Vasilev, V., Yaman, F. 2012.
An end-to-end workflow for engineering of biological networks from high-level
specifications. ACS Synth. Biol. 1:317–331.
Benenson, Y. 2012. Biomolecular computing systems: principles, progress and
potential. Nat. Rev. Genet. 13:455–468.
Bonnet, J., Yin, P., Ortiz M.E., Subsoontorn, P., Endy, D. 2013 Amplifying genetic logic
gates. Science 340(6132):599-603.
Canton, B., Labno, A., Endy, D. 2008. Refinement and standardization of synthetic
biological parts and devices. Nature Biotechnology 26:787-793.
Chopra, P., Kamma, A. 2006. Engineering life through Synthetic Biology. In Silico Biol.
6(5):401-410.
Durante-Rodríguez G., de Lorenzo V., Martínez-García E. 2014. The Standard European
Vector Architecture (SEVA) plasmid toolkit. Methods Mol. Biol. 1149:469-478.
Eilbeck, K., Lewis, S.E., Muganll, C.J., Yandell, M., Stein, L., Durbin, R., Ashburner,
M. 2005. The Sequence Ontology: a tool for the unification of genome
annotations. Genome Biology 6:R44
Endy, D. 2005. Foundations of engineering biology. Nature 438:449-453.
25
Galdzicki, M., Wilson, M.L., Rodríguez, C.A., Pocock, M.R., Oberortner, E., Adam,
L., Adler, A., Anderson, J.C., Beal, J., Cai, Y., Chandran, D., Densmore, D., Drory,
O., Endy, D., Gennari, J.H., Grünberg, R., Han, T.S., Hillson, N.J., Johnson, J.D.,
Kuchinsky, A., Lux, M.W., Madsen, C., Misirli, G., Myers, C.J., Olguin C.,
Peccoud, J., Plahar, H.A., Platt, D., Roehner, N., Sirin, E., Smith, T.F., Stan, G.B.,
Villalobos A., Wipat, A., Sauro, H.M. 2012. Synthetic Biology Open Language
(SBOL) Version 1.1.0. BBF RFC 87:1-26
Galdzicki, M., Clancy, K.P.,., Oberortner, E., Pocock, M., Quinn, JY., Rodríguez,
C.A., Roehner, N., Wilson, M.L., Adam, L., Anderson, J.C., Bartley, B.A Beal, J.,
Chandran, D., Chen, J., Densmore, D., Endy, D., Grünberg, R., Hallinan,
J., Hillson, N.J., Johnson, J.D., Kuchinsky, A., Lux, M.W., Misirli, G., Peccoud,
J., Plahar, H.A., , E., Stan, G.B., Villalobos A., Wipat, A., Gennari, J.H., Myers,
C.J., Sauro, H.M. 2014. The Synthetic Biology Open Language (SBOL) provides
a community standard for communicating designs in synthetic biology. Nature
Biotechnology 32:545-550
Keasling, J. 2005. The promise of synthetic biology. The Bridge 35:18–21.
Khalil, A.S., Collins, J.J. 2010. Synthetic biology: applications come of age. Nat. Rev.
Genet. 11:367–379.
Martinez-Garcia, E., Calles, B., Arevalo-Rodriguez, M., de Lorenzo, V. 2011. pBAM1:
an all-synthetic genetic tool for analysis and construction of complex bacterial
phenotypes. BMC Microbiol 11:38.
Martinez-Garcia, E., Aparicio, T., Goñi-Moreno, A,. Fraile, S., de Lorenzo, V. 2015.
SEVA 2.0.: an update of the Standard European Vector Architecture for de-/reconstruction of bacterial functionalities. Nucleic Acids Res. 43(Database
issue):D1183-9
Mukherji, S., van Oudenaarden, A. 2009. Synthetic biology: understanding biological
design from synthetic circuits. Nat. Rev. Genet. 10:859–871.
Myers, C.J. 2009. Engineering genetic circuits. London: Chapman y Hall/CRC
Myers, C.J., Barker, N., Kuwahara, H., Jones, K., Madsen, C., Nguyen, N.-P.D. 2009.
Genetic design automation. En IEEE/ACM international conference on computeraided design (pp. 713-716).
Nandagopal, N., Elowitz, M.B. 2011. Synthetic biology: integrated gene circuits.
Science 333:1244–1248.
26
Peccoud, J., Anderson, J.C., Chandran, D., Densmore, D., Galdzicki, M., Lux, M.W.,
Rodriguez, C.A., Stan, G.B., Sauro, H.M. 2011. Essential information for
synthetic DNA sequences. Nature Biotechnology. 29(1):22.
Ro, D.-K., Paradise, E.M., Ouellet, M., Fisher, K.J., Newman, K.L., Ndungu, J.M., Ho,
K.A., Eachus, R.A., Ham, T.S., Kirby, J., Chang, M.C.Y., Withers, S.T., Shiba, Y.,
Sarpong, R., Keasling, J.D. 2006. Production of the antimalarial drug precursor
artemisinic acid in engineered yeast. Nature 440:940–943.
Woolston, B.M., Edgar, S., Stephanopoulos, G. 2013. Metabolic engineering: past and
future.Annu. Rev. Chem. Biomol. Eng. 4:259–288.
27