Adecuación del análisis de requisitos de datos al contexto filológico del proyecto CIRCE ^[1]

Accommodation of Data Requirements Analysis to the Philological Context of the CIRCE Project

1. INTRODUCCIÓN

Uno de los términos más populares en la comunidad académica a lo largo de las últimas décadas es interdisciplinariedad, entendida no solamente como la combinación de distintas áreas de conocimiento dentro del mismo ámbito (p. ej., la musicología y la sociología dentro de las humanidades), sino como la colaboración de campos dispares con distintos enfoques metodológicos. Este es el caso del matrimonio entre la filología y la informática en el contexto de las humanidades digitales. Dicho término ha estado cargado de controversia desde su incepción, ya que diversos autores entienden que la aplicación de medios informáticos al análisis literario y lingüístico debe conllevar actividades especializadas como traducción automática o análisis léxico de textos (Terras, 2014: 144). No obstante, para el propósito de este artículo y del proyecto de investigación subyacente me ceñiré a la definición de la conferencia “The Digital Humanities 2009”: «[H]umanidades digitales, ampliamente definidas para abarcar los puntos en común entre la informática y la problemática asociada a la investigación y docencia en las humanidades» (Svensson, 2014: 163)^[2]. El proyecto en cuestión es “CIRCE: Teatro europeo de la primera modernidad en pantalla”, y su objetivo es el diseño, implantación, mantenimiento y manipulación de una base de datos con información sobre adaptaciones audiovisuales (cine, televisión y multimedia) de teatro de la Edad Moderna perteneciente a las cinco grandes tradiciones teatrales europeas (España, Inglaterra, Francia, Italia y Portugal) (CIRCE, 2023: s. pág.). La introducción por parte de los miembros del proyecto de información masiva relativa a dichas adaptaciones y la existencia de diversos mecanismos de búsqueda en la aplicación web asociada a la base de datos allanará el camino hacia la creación de distintos estudios comparativos basados en los patrones hallados en la información que recabar. Dichos patrones permitirán «revelar propiedades y rasgos no evidentes cuando el artefacto se encontraba en su forma nativa» (Schreibman et al., 2004: xxiv), es decir, identificar bien tendencias bien ausencias significativas en las adaptaciones de obras, autores o tradiciones específicas (p. ej., inclinación a variar en sus adaptaciones la época histórica en la que transcurre cierta obra de teatro, propensión a la transformación pragmática de determinados personajes, o escasa presencia femenina en labores de dirección de películas producidas en algún país concreto). Las pautas descubiertas por la aplicación ayudarán a formular preguntas que den pie a subsiguientes trabajos de investigación, mayoritariamente en el campo de la literatura comparada, fomentando de este modo uno de los servicios fundamentales de las humanidades digitales: «la aplicación de búsquedas, recuperaciones y procesos críticos facilitados algorítmicamente que, con origen en el trabajo basado en las humanidades, han demostrado tener aplicación mucho más allá» (Schreibman et al., 2004: xxv).

El paso previo al desarrollo e implantación de cualquier aplicación software es la elaboración de una lista detallada de requerimientos funcionales, no funcionales y de datos. En dicha actividad, conocida como ingeniería de requisitos , se identifican las motivaciones que llevan a la creación de la aplicación desde el punto de vista de las partes interesadas, es decir: gerentes, clientes y usuarios (Pressman y Maxim, 2020: 57, 103; Sommerville 2016: 103). Considerada por algunos autores como la parte más importante del desarrollo de sistemas software (Harrington, 2016: 31), esta fase de análisis debe ser precisa, exhaustiva y verificable (Mora-Rioja, 2014: 29), y su ausencia o falta de calidad generalmente provoca la creación de aplicaciones que no responden a las necesidades de sus usuarios, situación por desgracia habitual cuando el dominio de conocimiento de dichos usuarios difiere sobremanera del de los integrantes del equipo técnico (Pressman y Maxim, 2020: 103; Sommerville, 2016: 103). En el caso de CIRCE, tanto el investigador principal (IP de aquí en adelante) como tres de los miembros del proyecto son académicos del campo de la filología. El otro miembro, autor de este artículo, cuenta con un perfil mixto como ingeniero en informática y doctor en filología inglesa. El equipo y sus colaboradores están geográficamente dispersos en cuatro ciudades de tres países distintos. Tanto la literatura sobre ingeniería del software como mi experiencia en análisis y desarrollo de aplicaciones informáticas durante décadas indican que el caso particular de CIRCE requiere un elevado nivel de fluidez en la comunicación entre usuarios técnicos y no técnicos. El hecho de que el proyecto gravite en torno a una base de datos de creación propia sugiere extremar la atención al detalle en la educción de requisitos de datos (Date, 2019: 393). Pressman y Maxim comentan lo siguiente:

Los clientes o usuarios finales pueden residir en distintas ciudades o países, pueden tener tan solo una vaga idea sobre qué es requerido, pueden tener opiniones opuestas sobre el sistema a construir, pueden tener conocimiento técnico limitado, y pueden tener tiempo limitado para interactuar con el ingeniero de requisitos. Ninguna de estas cosas es deseable, pero todas son comunes, y generalmente uno está obligado a trabajar dentro de las restricciones impuestas por esta situación (2020: 107).

Este era precisamente el estado inicial de nuestra empresa. Tras plantear la situación al IP, decidimos dar un tratamiento especial al análisis de información del proyecto mediante la inclusión de una fase de preanálisis donde todos los miembros utilizaran una serie de plantillas de datos a modo de borrador de la futura base de datos. Acabada dicha fase, el uso de estas plantillas ha constituido una parte importante del proceso de modelado de requerimientos y ha permitido identificar el dominio de información del proyecto (Pressman y Maxim, 2020: 127), refinando el proceso de educción de datos de forma iterativa y en colaboración con los usuarios de la aplicación software, como recomiendan las buenas prácticas de ingeniería de requisitos (Harrington, 2016: 28; Meier y Kaufmann, 2019: 25; Pressman y Maxim, 2020: 103). Este artículo describe y explica dicho proceso ofreciendo ejemplos concretos y demostrando las ventajas que este enfoque ha aportado al desarrollo de CIRCE y puede aportar a cualquier otro proyecto de características semejantes.

2. DEFINICIÓN DE REQUISITOS DE DATOS

El grado de utilidad de la base de datos de CIRCE depende de su exhaustividad no solamente en cuanto a la cantidad de adaptaciones registradas sino en lo referente al nivel de detalle de los datos a almacenar. Para referirme a dichos datos utilizaré la terminología definida por Gérard Genette con relación a su concepto de hipertextualidad y según la cual la presencia manifiesta de un texto en otro convierte a aquel en hipotexto y a este en hipertexto ([1962] 1989). En el contexto de CIRCE, las obras de teatro adaptadas juegan el papel de hipotexto, y sus adaptaciones audiovisuales el de hipertexto. La información básica sobre ambos tipos de texto es relativamente fácil de encontrar en internet sin necesidad de acudir a bases de datos especializadas, y una simple enumeración de adaptaciones no garantizaría el nivel de calidad deseado. Más allá de listar el elenco de actores, la duración del hipertexto, o los países de producción, se torna necesario ahondar en las características de cada producto cultural con el objetivo de detectar información de mayor valor investigador, empezando por registrar del modo más completo posible a los miembros de los equipos artístico y de producción, revelar el género de actores y personajes, clasificar cada obra audiovisual de acuerdo a su género artístico, circunstancias de grabación y relación con su hipotexto, y almacenar cuidadosamente todas las fuentes de las que los miembros del proyecto extraen dicha información. El punto de partida fue una larga lista de atributos de datos definida por el IP del proyecto (Huertas Martín, 2023: 286-289) que incluía, además de los anteriormente descritos, la presencia de paratextos o la referencia a fuentes intermedias: por ejemplo, la película West Side Story (dir. Spielberg, 2021) está basada en la obra de teatro Romeo y Julieta (Shakespeare, 1597), pero presenta una relación de intertextualidad con el film West Side Story (dir. Wise y Robbins, 1961) y con el musical en el que esta última se inspiró (Laurents, Bernstein y Sondheim, 1957).

Una vez dispuesta la lista de atributos, hubo que tomar la primera decisión tecnológica del proyecto: la elección del modelo de datos subyacente al sistema gestor de base de datos a utilizar. El modelo relacional ha dominado el mercado de las bases de datos durante las últimas cinco décadas, pero hoy en día numerosos desarrollos de software confían su información a las llamadas bases de datos NoSQL, que dan cabida a los modelos orientado a documentos, columnar, de grafo, o de clave-valor, entre otros. Más allá de las distintas topologías en las que almacenan la información, las diferencias fundamentales entre ambos tipos de base de datos son las siguientes: 1) El modelo relacional presume la existencia de una estructura de datos bien definida que debe permanecer idealmente inalterable durante el ciclo de vida de las aplicaciones que acceden a la información, mientras los modelos NoSQL presentan mayor flexibilidad, generalmente sin necesidad de definir un esquema de datos invariable. 2) Las bases de datos relacionales ofrecen buen rendimiento como sistema centralizado, mientras los modelos NoSQL presentan una mayor capacidad de adaptación a entornos distribuidos (p. ej., en distintos servidores en la nube), y son más indicados para almacenar enormes cantidades de datos no estructurados (p. ej., big data). 3) Los sistemas gestores de bases de datos relacionales necesitan un mayor nivel de administración que los sistemas NoSQL. 4) Las bases de datos relacionales son transaccionales, por lo que proveen sistemas que protegen la integridad de los datos; las bases de datos NoSQL no garantizan dicha integridad, sacrificada en pos de la disponibilidad inmediata de la información. En el caso de CIRCE, los datos a almacenar son estructurados, como demuestra el proceso de análisis objeto de este artículo: no solo es posible definir un esquema de datos estable, sino recomendable, como Hills observa:

La ventaja de un SGBD^[3] sin esquema es que se puede comenzar a almacenar y acceder a la información sin definir primero un esquema. Aunque esto suena muy bien, e indudablemente facilita un comienzo rápido de un proyecto de datos, la experiencia muestra que la falta de planificación es generalmente seguida por mucha reflexión adicional […] [L]os cambios en el esquema no solo afectan a los datos: pueden afectar al código de la aplicación que ha de escribirse necesariamente con al menos algunas suposiciones sobre el esquema de los datos (2016: Introduction).

La base de datos existirá en un servidor web provisto por la Universitat de València, por tanto de forma centralizada. Gracias al bagaje académico y profesional del personal técnico del proyecto, asumir labores de administración no es problemático. Finalmente, el número de usuarios de la base de datos es limitado, por lo que la disponibilidad favorecida por los modelos NoSQL no aportaría ventaja alguna; en cambio, la capacidad transaccional de una base de datos relacional sería bienvenida de cara a promover la estabilidad de la información a introducir y consultar. Por todas estas razones, y dado que nuestra realidad no cumple ninguno de los motivos por los que se sugiere utilizar una base de datos NoSQL (Celko, 2014: 14), el modelo de datos más indicado es el relacional.

Las bases de datos relacionales estructuran la información de forma tabular, de modo que diversas tablas almacenan la información de cada entidad de datos (p. ej., las obras de teatro a adaptar, sus adaptaciones, los usuarios que introducen los datos), y cada tabla cuenta con una serie de registros (p. ej., cada obra de teatro, cada adaptación, cada usuario) y campos (p. ej., el nombre de cada obra de teatro, el nombre de su autor, o su año de estreno). La propuesta inicial del IP era suficiente para elaborar un diseño relacional y proceder a implantar la base de datos correspondiente. No obstante, dicho proceder habría podido ocasionar problemas de difícil solución. Al no haber comenzado el proceso de inserción de datos, desconocíamos qué campos aportarían escasa utilidad, cuáles albergarían información excesivamente compleja de encontrar, o cuáles serían necesarios según el criterio del resto de usuarios de la aplicación pero no se tomaron en cuenta en el análisis de datos inicial. Dado que el esquema de las bases de datos relacionales es poco flexible, los cambios estructurales llevados a cabo después de la implementación de una base de datos suelen ser complejos de ejecutar y suelen producir daños colaterales en las aplicaciones informáticas que acceden a dichos datos. Además, existía la posibilidad de que los restantes miembros del proyecto comprendiesen la estructura y contenido de la información de una forma distinta a la esperada. Si la colaboración entre usuarios técnicos y no técnicos es clave para el éxito de cualquier desarrollo informático, este hecho es aún más acusado en las humanidades digitales (Pitti, 2008: 485; Edmond, 2016: 55). Por todos estos motivos, decidimos añadir a la actividad de educción de requisitos una fase de preanálisis de datos en la que involucraríamos a todos los miembros del proyecto, minimizando de ese modo los potenciales problemas de los que nos avisa Sommerville: «Para la gente es más fácil entender ejemplos de la vida real que descripciones abstractas. No son buenos describiendo los requerimientos de un sistema. Sin embargo, pueden ser capaces de describir cómo manejan situaciones particulares o imaginan cosas que podrían hacer trabajando de una nueva manera» (2016: 118). Hills sugiere refinar el diseño de estructuras de información mediante un modelo de datos cuya relación con la base de datos resultante es la de los planos de un edificio con la correspondiente construcción final (2016: Introduction). Pressman y Maxim recomiendan la creación de prototipos, debido a que su uso simplifica la descripción de los cambios deseados por parte de las partes interesadas del proyecto, enriqueciendo de ese modo la comunicación entre los miembros del equipo y contribuyendo a la calidad del producto resultante, ya que es posible para el personal informático observar comportamientos visibles por parte de los usuarios (2020: 58). Sommerville propone el uso de una «plantilla estándar» para garantizar un enfoque estructurado a la hora de especificar los requerimientos de un sistema de software(2016: 123). La combinación de ambas sugerencias que decidimos implementar en el proyecto CIRCE fue la elaboración de escenarios de usuario a modo de descripciones de la futura interacción entre los usuarios y la aplicación (Sommerville, 2016: 118; Pressman y Maxim, 2020: 104). Dichos escenarios fueron representados a través de hojas de cálculo distribuidas entre los miembros del proyecto para que estos las editaran fácilmente mediante herramientas como Microsoft Excel o Google Sheets. Debido a su diseño tabular, una hoja de cálculo presenta una estructura similar a la de una tabla relacional, por lo que simula parcialmente la forma de la futura base de datos. Otra ventaja de este formato es su facilidad de edición, permitiendo a los usuarios rellenar las hojas de forma flexible, añadiendo filas, variando el nivel de jerarquía de los datos o escribiendo comentarios al margen cuando lo estimen necesario. Gracias a este método, una vez los integrantes del proyecto hubiesen rellenado varias decenas de hojas de cálculo, podríamos descubrir qué atributos de datos eran más utilizados, cuáles apenas contaban con relevancia, y cuáles se había olvidado incluir inicialmente. También averiguaríamos si los usuarios de la futura aplicación comprendían la estructura y contenido de los atributos de datos del mismo modo que el IP y el responsable técnico. Como recomiendan Meier y Kaufmann (2019: 25), el proceso podría iterar, generándose sucesivas versiones de las hojas de cálculo cada vez con mayor nivel de refinación. Excepto por el tiempo invertido, esta forma de proceder no implica grandes esfuerzos técnicos, más allá de editar la estructura de las hojas cada vez que los comentarios recibidos así lo sugiriesen. Un formato tan común como el de una hoja de cálculo nos ayudaría a encontrar un marco de comunicación compartido y evitar, de ese modo, los problemas derivados de la falta de un vocabulario común entre profesionales técnicos y no técnicos, tan habituales en proyectos de humanidades digitales (Edmond, 2016: 56).

3. ESCENARIOS DE USUARIO: CASOS DE USO

Inicialmente se crearon dos hojas de cálculo: una destinada a adaptaciones cinematográficas y otra a adaptaciones televisivas. En ambos casos, la información a almacenar se dividió en distintos apartados, comenzando por la distinción entre información sobre la obra de teatro adaptada e información sobre la adaptación cinematográfica o televisiva. Esta última, a su vez, presenta una serie de apartados que agrupan diversos atributos de datos: información técnica, datos sobre el equipo creativo, observaciones sobre los procedimientos de adaptación llevados a cabo, relaciones intertextuales con otras fuentes, y bibliografía de referencia (Huertas Martín, 2023: 286). La estructura de las hojas de cálculo fue presentada al equipo del proyecto y discutida en una reunión en línea, a la que sucedieron subsiguientes reuniones que han permitido afinar el nivel de detalle y calidad de la estructura de datos. Tras cinco meses de fase de preanálisis, el equipo ha rellenado un total de 240 hojas de cálculo. La información recabada ha permitido identificar potenciales problemas en la estructura y contenido de los datos, aportando por tanto un enorme valor con vistas al diseño de la base de datos del proyecto. El proceso de análisis de la información plasmada en las hojas de cálculo se ha sometido a dos iteraciones, por lo que en la actualidad estamos operando con la tercera versión de dichas hojas. A continuación se relatan algunos casos concretos donde este uso de escenarios ha aportado resultados positivos:

a) En la primera versión de las hojas de cálculo, junto al nombre de cada actor se registraba el nombre del personaje en la adaptación. Este proceder obviaba la relación entre el personaje del hipotexto y el del hipertexto cuando ambos son distintos. Por ejemplo, en la película Trono de sangre (Kurosawa, 1957), adaptación de Macbeth(Shakespeare, 1611), Toshiro Mifune representa el papel de Taketoki Washizu, que corresponde a Macbeth en el texto original. Otros siete personajes de la película cuentan con su equivalente en la obra shakespeariana. El registro de la relación entre los personajes del hipotexto y el hipertexto también permite identificar ausencias en el último. Por ejemplo, el film Planeta prohibido (Wilcox, 1956), basado en La tempestad (Shakespeare, 1611), representa al personaje de Prospero mediante el Doctor Edward Morbius, pero no incluye correspondencia para el personaje de Caliban, y añade personajes sin equivalente en el texto de Shakespeare, como el jefe ingeniero Quinn.

b) Inicialmente se definió una lista de valores posibles para el género de cualquier integrante del equipo artístico o de producción, haciendo hincapié en la diversidad: “femenino”, “masculino”, “no binario”, “fluido”, y “queer”. Dicha enumeración se tornó insuficiente al ser aplicada a ciertos personajes de obras de teatro –p. ej., las hadas de El sueño de una noche de verano (Shakespeare, 1600)–, por lo que se decidió añadir un nuevo valor: “indefinido”.

c) Al introducir en las hojas de cálculo información sobre adaptaciones audiovisuales de principios del siglo XX, surgieron tres situaciones que no se habían tomado en cuenta en un principio. Primero, era de interés registrar la localización física del archivo donde se encuentra la en algunos casos única copia de la película original. Segundo, hay películas cuyas copias se perdieron, hecho que es necesario reflejar en nuestra base de datos. Tercero, la duración de las grabaciones de esas décadas no se cataloga en minutos, sino en pies –medida de longitud de la cinta física que contiene la película (Society of Motion Picture Engineers, 1917: s. pág.)–, posibilidad que nuestra estructura de datos ya contempla en la actualidad.

d) A la hora de almacenar el lugar donde cada adaptación está ambientada, inicialmente se identificaron los valores “ciudad/pueblo”, “país”, “continente” e “indefinido”. Dada la existencia de adaptaciones de teatro renacentista cuya acción se desarrolla en el espacio exterior (p. ej., la mencionada Planeta prohibido), se añadió el valor “planeta” a la lista.

e) A pesar de que se buscó un enfoque exhaustivo en la definición de la lista de atributos, se tornó necesario añadir un campo de comentarios donde cada investigador pudiera incluir información que no tenía cabida en el resto de la estructura de datos. Dicho campo puede servir para esclarecer los motivos por los que se han consignado valores concretos en casos controvertidos. Por ejemplo, aunque el personaje de Ariel en La Tempestad (Shakespeare, 1611) carece de género al tratarse de un «espíritu del aire» ([1611] 2008: 3064), una acotación dramatúrgica en el texto de la obra se refiere al personaje como «él» (Shakespeare, [1611] 2008: 3086). No obstante es conocido que, en muchos casos, dichas acotaciones fueron añadidas por colaboradores de Shakespeare tras el estreno de las obras, por lo que la intención del autor respecto al género del personaje no es clara (Jowett, 2007: 107). De nada sirve averiguar el género de los actores que interpretaron al personaje en las primeras representaciones de la obra, ya que en esa época las mujeres tenían prohibido actuar (Hill, 1986: 235). Más allá de su relación con el autor del hipotexto, dado que la acotación es la única documentación fehaciente al respecto, es lógico asignar a Ariel género masculino. Más allá de anotar la información en la correspondiente hoja de cálculo de CIRCE, esta circunstancia merece ser explicada, siendo el campo de comentarios el lugar reservado para tal fin.

Una vez los requisitos de datos de una aplicación software han sido identificados, es necesario implementar una fase de validación a modo de control de calidad de dichos requisitos. En dicha fase se estudia la consistencia, completitud y falta de ambigüedad de los mismos (Pressman y Maxim, 2020: 105). Las iteraciones de uso de nuestros prototipos de datos mencionadas anteriormente han servido como fase de validación. Tras las mismas, las hojas de cálculo presentan una estructura lo suficientemente estable como para comenzar el diseño físico de la base de datos y pasar a su posterior implementación. El uso de escenarios ha facilitado sobremanera la colaboración entre usuarios de distinto perfil y ha fortalecido el análisis de requisitos de datos.

4. CONCLUSIONES

Englobado dentro de las humanidades digitales debido a su uso de almacenamiento y recuperación de datos informatizados (Terras, 2014: 144), el proceso de educción de requisitos de datos del proyecto CIRCE se ha visto beneficiado por la presencia de una fase de preanálisis donde el uso de hojas de cálculo a modo de escenarios de usuario ha aportado enorme valor al proceso de ingeniería de requisitos. Este modo de proceder ha satisfecho algunas de las mejores prácticas en ingeniería de requisitos, según las define Ambler (Pressman y Maxim, 2020: 58): «Incentivar la participación activa de las partes interesadas haciendo coincidir su disponibilidad y valorando sus aportaciones», propósito que se ha conseguido mediante el establecimiento de una serie de reuniones donde se han debatido los objetivos del proyecto en cuanto a la educción de datos y se han tomado en cuenta los comentarios de todos los participantes; «usar modelos simples (p. ej., notas post-it, bocetos rápidos, historias de usuario) para reducir barreras en la participación», tarea cubierta por el uso de las hojas de cálculo a modo de escenarios de uso; «tomar tiempo para explicar las técnicas de representación de requerimientos antes de usarlas», labor ejemplificada en las presentaciones de las hojas de cálculo que se llevaron a cabo durante las reuniones; «Adoptar la terminología de las partes interesadas, y evitar jerga técnica siempre que sea posible», finalidad lograda gracias al uso de términos como plantilla u hoja haciendo referencia a las hojas de cálculo, y fila, columna y celda al hablar sobre los elementos estructurales de cada una de ellas; y «colaborar de forma cercana con las partes interesadas y documentar los requerimientos solamente a un nivel útil para todas ellas», tarea que se va a seguir llevando a cabo durante el resto del desarrollo del proyecto, debido a los buenos resultados arrojados hasta ahora. Emplear una cantidad de tiempo considerable (cinco meses) para el análisis de las necesidades de información de la base de datos ha resultado ser una inversión en calidad y ha prevenido la futura presencia de errores, omisiones y redundancias.

Sommerville comenta que «las partes interesadas en un proyecto normalmente expresan los requerimientos en sus propios términos y con conocimiento implícito de su propio trabajo. Los ingenieros de requisitos, sin experiencia en el dominio del cliente, pueden no entender estos requerimientos» (2016: 113). Parte del éxito de la educción de requisitos de datos en el proyecto CIRCE está relacionada con el hecho de que el ingeniero de software es también académico del área de filología y futuro usuario de su propia base de datos y aplicación software. La presencia de un perfil profesional mixto se ha tornado fundamental para eliminar barreras de comunicación y comprender las necesidades de los miembros del equipo. Aunque la existencia de dichos perfiles es escasa, se recomienda su uso para proyectos de humanidades digitales. No obstante, si hay que destacar alguna conclusión por encima del resto, es necesario hablar del valor del proceso colaborativo como núcleo del correcto desarrollo de un proyecto de humanidades digitales. Edmond nos recuerda que las humanidades tradicionales operan en un entorno investigador que carece de la organización necesaria para fomentar la colaboración (2016: 55), y Pitti señala que el trabajo conjunto permite obtener resultados más completos e intelectualmente complejos de los que obtendría un individuo, especialmente cuando se mezclan los talentos de humanistas y tecnólogos (2008: 485). Como hemos comprobado en estas primeras fases del proyecto CIRCE, la comunicación abierta y transparente entre todos los miembros de empresas de este tipo se torna fundamental para garantizar su éxito, y se recomienda seguir las pautas aquí comentadas en proyectos de humanidades digitales.

Bibliografía citada

CELKO, Joe (2014), Joe Celko’s Complete Guide to NoSQL: What Every SQL Professional Needs to Know about Nonrelational Databases , Waltham, Elsevier.

CIRCE (2023), «Inicio», CIRCE – Early Modern Theatre on Audiovisual Communication , s. pág. [En línea: https://circe.uv.es/es . Fecha de consulta: 05/07/2023].

DATE, C. J. (2019), Database Design and Relational Theory: Normal Forms and All That Jazz , 2ª edición, Healdsburg, Apres.

EDMOND, Jennifer (2016), «Collaboration and Infrastructure», en A New Companion to Digital Humanities , en S. Schreibman, R. Siemens y J. Unsworth (eds.), Chichester, Wiley Blackwell, págs. 54-65.

GENETTE, Gérard ([1962] 1989), Palimpsestos: La literatura en segundo grado , trad. Celia Fernández Prieto, Madrid, Taurus.

HARRINGTON, Jan L. (2016), Relational Database Design and Implementation , Cambridge, Elsevier.

HILL, James L. (1986), «“What, Are They Chidren?” Shakespeare’s Tragic Women and the Boy Actors», Studies in English Literature, 1500-1900 , 26/2, págs. 235-258.

HILLS, Ted (2016), NoSQL and SQL Data Modeling: Bringing Together Data, Semantics, and Software , Basking Ridge, Technics Publications.

HUERTAS MARTÍN, Víctor (2023), «De EMOTHE a CIRCE: una base de datos de adaptaciones a cine y TV de teatro moderno europeo», Hipogrifo, 11/1, págs. 281-293.

JOWETT, John (2007), «New Created Creatures: Ralph Crane and the Stage Directions in The Tempest», Shakespeare Survey, 36, págs. 107-120.

LAURENTS, Arthur, Leonard BERNSTEIN y Stephen SONDHEIM (1957), West Side Story , Nueva York, Random House.

MEIER, Andreas y Michael Kaufmann (2019), SQL & NoSQL Databases: Models, Languages, Consistency Options and Architectures for Big Data Management , trad. de Anja Kreutel, Wiesbaden, Springer Vieweg.

MORA-RIOJA, Arturo (2014), Bases de datos: diseño y gestión, Madrid, Síntesis.

PITTI, Daniel V. (2008), «Designing Sustainable Projects and Publications», en en S. Schreibman, R. Siemens y J. Unsworth (eds.), A Companion to Digital Humanities, Malden, Oxford y Victoria, Blackwell, págs. 471-487.

PRESSMAN, Roger y Bruce MAXIM (2020), Software Engineering: A Practitioner’s Approach , 9ª edición, Nueva York, McGraw Hill.

SCHREIBMAN, Susan, Ray SIEMENS y John UNSWORTH (2004), «The Digital Humanities and Humanities Computing: An Introduction», en S. Schreibman, R. Siemens y J. Unsworth (eds.), A Companion to Digital Humanities, Malden / Oxford / Victoria, Blackwell, págs. xxii-xxviii.

SHAKESPEARE, William ([1611] 2008), The Tempest, The Norton Shakespeare , ed. de Stephen Greenblatt, 2ª edición, Nueva York, Norton, págs. 3066-3115.

SOCIETY OF MOTION PICTURE ENGINEERS (1917), «Motion Picture Nomenclature», Transactions of the Society of Motion Picture Engineers, Meeting of October 8-9, , 5, s. pág.

SOMMERVILLE, Ian (2016), Software Engineering, 10ª edición, Harlow, Pearson.

SVENSSON, Patrick (2014), «Humanities Computing as Digital Humanities», en Defining Digital Humanities: A Reader, ed. Melissa Terras, Julianne Nyhan y Edward Vanhoutte, Farnham y Burlington, Ashgate, págs. 159-186.

TERRAS, Melissa (2014), «Disciplined: Using Educational Studies to Analyse “Humanities Computing”», en en M. Terras, J. Nyhan y E. Vanhoutte (eds.), Defining Digital Humanities: A Reader , Ashgate, págs 67-96.