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