¿Por qué aprender a programar?

El jueves de la semana pasada lanzamos públicamente la versión en español de un sitio web bastante conocido por los historiadores digitales: The Programming Historian. Tras unos meses de arduo trabajo colaborativo, la publicación en español es una versión bastante ligera, con una pequeña parte del conjunto de lecciones y tutoriales sobre herramientas digitales, técnicas y flujos de trabajo que se pueden encontrar en el sitio original. Había que comenzar por algo.

No obstante lo incompleto, The Programming Historian en español merece mucho la pena ser visitado porque contiene -por ahora solamente-, la Introducción a Python, un conjunto de tutoriales pensados para estudiarse de manera seriada que permite a los historiadores aprender los rudimentos de ese lenguaje de programación de alto nivel multipropósito. Muchos colegas historiadores y humanistas se preguntarán aquí, “¿para qué nos sirve saber esas cosas que les competen a los encargados de cómputo de mi institución?”

No podemos negar que nuestro quehacer académico se ha digitalizado a un grado superlativo en las últimas décadas. Nos hemos percatado que manipular datos digitalmente nos ofrece la posibilidad de ampliar nuestros horizontes de investigación. Hace tiempo que los historiadores trabajamos con bases de datos de diverso tipo, hacemos análisis de redes sociales auxiliados de programas de cómputo especializado, recurrimos a sistemas de información geográfica para el análisis espacial y para generar representaciones cartográficas, o usamos hojas de cálculo para tabular datos seriales para hacer historia económica o demografía histórica, obteniendo gráficas muy interesantes de tendencias de crecimiento. Pero también, entre otras muchas cosas, los historiadores podemos trabajar con conjuntos de datos masivos (big data), y es ahí donde radica la importancia de aprender un lenguaje de programación que nos permita sacarle provecho a una cantidad ingente de datos.

Los historiadores generalmente acudimos a documentos en los que quedó, en forma de texto, algún registro de los acontecimientos, de las ideas de una persona o de un grupo de personas, así como de las formas culturales de estructurar los discursos. Esos son algunos de los datos con los que trabajamos. Cuando leemos un documento lo interpretamos, es decir, diseccionamos y reorganizamos su discurso de tal manera que los datos nos ofrezca un significado. En otras palabras: manipulamos los datos de diversas maneras a través de un sinnúmero de operaciones de por medio. A veces, con un conjunto de textos, realizamos una serie de operaciones cuantitativas en busca de respuestas cualitativas. Por ejemplo, contamos la frecuencia (concordancia) con la que aparece una palabra o una frase, elaboramos la hipótesis de que esta palabra resulta clave para determinada época, así que buscamos el contexto en el que se encuentra ese término para reconstruir redes semánticas que nos ayuden a comprender un corpus documental mayor. También ponemos atención a las interrelaciones entre un concepto y otro, vemos cuáles juegan un papel intercambiable en el complejo contexto del discurso que nos ofrecen los documentos. Además, ponemos énfasis en las relaciones de intertextualidad entre un tipo de documentos y otros, para intentar reconstruir y explicarnos el contexto cultural en el que se produjeron.

Podemos hacer todo esto de manera más o menos sencilla cuando nos enfrentamos a un corpus documental restrigido, de cien, quinientos o mil quinietos expedientes de archivo… e, incluso, ahí comienzan nuestros peores dolores de cabeza: tenemos que organizar nuestros glosarios de términos, nuestras redes de interrelaciones conceptuales.

Ahora imaginemos que Internet pone a nuestra disposición la transcripción de la impresionante cantidad de ¡197,745! juicios criminales llevados a cabo frente a un tribunal londinense entre 1674 y 1913. Para un historiador solitario, tal cantidad de documentos resulta imposible de procesar y analizar, ya ni se diga de imaginar. Pero, de tener las herramientas, ¿no estaríamos tentados a hacer algunos análisis cuantitativos de esos documentos? ¿No sería maravilloso buscar algunas series de conceptos, sus interrelaciones, los contextos en los que se ubican y sus cambios a lo largo de varias décadas o siglos? La herramienta para hacerlo es posible, está en nuestra propia computadora y solamente es necesario aprender un poco de programación para echarla a funcionar.

En términos de la ciencia de la computación, de la información, de la data, una palabra es una secuencia de caracteres específica, es decir, una cadena de caracteres (string) organizada de una forma determinada que nos ofrece cierto significado, pero que para una computadora es un conjunto de datos procesables carentes de significado. Las frases son una secuencia de palabras interrelacionadas de cierta manera, es decir, cadenas de caracteres de mayor longitud. Un párrafo, el contenido escrito de un documento, el de un expediente, el de un legajo, el de todo un ramo del acervo de un archivo, contiene grandes series diferenciadas de cadenas de caracteres, de datos susceptibles de ser procesados y manipulados por computadora. Los programas de ofimática que utilizamos, como los procesadores de texto, ofrecen cierta capacidad de manipular esos datos, pero es una manipulación elemental y que nunca controlamos a nuestro gusto. En el procesador de texto podemos buscar una palabra determinada (una cadena de caracteres) y obtener un informe de las veces que aparece en el texto. Pero es imposible sacarle más jugo al asunto si queremos incluir las variables de esa palabra y obtener su concordancia en los diversos contextos en las que se encuentra, o construir modelos tópicos. Además, sería imposible trabajar con 197 mil expedientes en ese tipo de programas, por ejemplo, en un solo archivo de MS-Word.

Una de las bondades de Python es que es un lenguaje de programación muy sencillo en su sintaxis a la vez que poderoso (por ser un lenguaje interpretado de alto nivel). Ello facilita el uso del conjunto de funciones orientadas para operar sobre cadenas de caracteres, entre las que se incluyen comparación, búsquedas boleanas, organización por diccionarios, aprendizaje máquina, construcción de n-gramas, modelado tópico y otras más cuya utilización es muy eficaz para analizar datos masivos y generar, con la ayuda de otras herramientas, visualizaciones de los datos que nos permitan encontrar secuencias o tendencias a nivel macro que no podríamos detectar de otra manera; por ejemplo, cómo cambia la relación de sustantivos y adjetivos vinculados con la palabra “asesinato” a lo largo de 150 años, o encontrar, como lo hizo Fred Gibbs, cuál era el método preferido por los criminales londinenses para envenenar a sus víctimas a lo largo de varias décadas. Podemos también construir, estadísticamente, el conjunto de temas predominantes en un conjunto de documentos.

Veamos el ejemplo en el que se basan los tutoriales de Python en The Programming Historian. El proyecto de publicación en Internet de los expedientes criminales londinenses, The Proceedings of the Old Bailey, puso en línea 197,745 transcripciones de juicios criminales, es decir, cerca de 127 millones de palabras registradas a lo largo de 239 años de fuentes históricas capaces de ser analizadas. Esto supuso un reto para los historiadores digitales que generó varios proyectos de desarrollo de herramientas informáticas para proponer un macroanálisis de esto que, en términos de la práctica del historiador, es un conjunto de datos masivos. Entre los diversos proyectos se puede consultar el resultado de Data Mining with Criminal Intent, un proyecto multinacional; Exploring Big Historical Data: The Historian’s Macroscope, y el origen del sitio de tutoriales para historiadores digitales cuya primera versión escribieron WJ Turkel y A MacEarchen The Programming Historian version 1.

Parece que, de ahora en adelante, para los historiadores que se enfrentan de lleno al contexto digitalizado en su práctica cotidiana, saber programar, es decir, escribir código para hacer programas y extraer datos de sus documentos, es muy recomendable. En un mundo donde tenemos acceso a cantidades increíbles de datos, si se permite la comparación, será lo mismo que saber paleografiar.

Anuncios

Procesadores de texto vs escritura académica sostenible

Un serio problema

Hace unos días, un tesista me envió un correo electrónico diciéndome que me remitía ahí mismo el borrador completo de su tesis para hacer la última lectura de revisión antes de someterla al comité académico. Verdaderamente entusiasmado -porque es un trabajo excelente y que lo va a llevar pronto a obtener su grado- abrí el correo, pero mi sorpresa fue mayúscula ya que no encontré ningún archivo adjunto. En cuanto me percaté que el email no tenía un attachment, me comuniqué con el tesista para decirle que su texto no se había adjuntado al correo. Unas (muchas) horas después recibí otro correo en el que me explicaba que había tenido innumerables problemas para adjuntar el archivo al envío y que optaba por hacérmelo llegar por Dropbox. El archivo, que está escrito de origen y guardado como un documento .docx de MS Word ocupa casi 18MB de unidades de información. Sin embargo, su extensión no rebasa las 310 cuartillas y sólo contiene algunas cuantas ilustraciones y mapas. Nada del otro mundo, en cuanto a extensión, que amerite los 18MB (¡18’000,000 de bytes!) de espacio en mi disco duro, cuando bien podría tener solamente 1MB, considerando que cuenta apenas con cerca de 780 mil caracteres más las imágenes, que son pocas, si se ponen en baja resolución. Para tener una idea de qué es a lo que me refiero en términos de extensión, cada carácter equivale aproximadamente a 1 byte por lo que 10MB de unidades de información equivalen a dos veces la obra completa de Shakespeare.

El problema no es solamente la extensión o “peso” del archivo, sino la posibilidad de manipularlo. Como todo borrador de un trabajo, aún debe ser corregido y anotado con las observaciones del director. Si bien MS Word cuenta con una herramienta para ello (-> Herramientas -> Control de cambios), su uso es realmente engorroso y no permite una apreciación cabal y por separado de las correcciones y de las anotaciones. Por otro lado, cualquier cosa que se modifique en el texto, aún siendo solamente el añadido de una coma u otro signo de puntuación, hace tambalear todo el formato del documento, muy probablemente porque el mismo fue generado en una plataforma distinta a la que utilizamos para su corrección (el paso de Windows a Mac, por ejemplo). Incluso, después de trabajar una nota sobre un cambio sustancial, el programa se colapsa y se cierra, descartando los cambios. De esta manera, ponerse a corregir y anotar con la atención debida un trabajo tan interesante, es imposible pues acaba uno por desesperarse y restarle atención al contenido (que es lo importante) por estar preocupado del funcionamiento del procesador de textos. Más valdría entonces imprimirlo en papel para corregirlo y anotarlo de la manera tradicional, lo cual es un contrasentido tratándose de un documento digital, por no hablar del peso que sobre mi conciencia ecológica significaría gastar papel en un borrador.

En los años que tengo de trabajar en entornos digitales (por lo menos 35), ningún procesador de textos me ha dado tantos problemas como el MS Word, en cualquiera de sus versiones. En tiempos de los sistemas operativos DOS, tanto en MS como en Apple, los procesadores como WordStar, WordPerfect o Apple Writer ofrecían un buen servicio: eran robustos, sencillos y eficaces. Raramente se colapsaban, generaban archivos ligeros, y uno podia concentrarse en la tarea fundamental: escribir. Y es que aquellos procesadores carecían de las características actuales, estructuradas con la filosofía del WYSIWYG,1 y uno podía dedicarse a escribir vertiendo fluidamente las ideas en el texto sin distraerse con los detalles del diseño de los márgenes, el formato de los títulos y subtítulos de cada capítulo, el acomodo de las notas a pie y de las referencias bibliográficas así como los demás agregados, gráficos o textuales. Uno escribía y, después del punto final, se dedicaba a acomodar las cosas.

Los procesadores de texto, particularmente el MS Word, no están diseñados para la escritura académica o la literaria. Esto lo han discutido ya varios escritores, científicos sociales y humanistas. Charles Stross, un conocido escritor de ciencia ficción radicado en Escocia, fue al extremo de argumentar Why Microsoft World must Die -“Por qué debe morir MS Word”:

Microsoft Word es un tirano de la imaginación, un pequeño dictador carente de
imaginación e inconsistente, que es inadecuado para cualquier uso en la escritura creativa.
Peor aún, es casi un monopolio que domina el campo de los procesadores de texto.

Soluciones

La entrada del blog de Stross es muy interesante ya que expone varias razones por las cuales MS Word es inútil para la escritura de textos largos, como las novelas, los libros o las tesis académicas. Más aún, uno de los más graves problemas de éste y otros procesadores de texto, es que resulta imposibile producir un documento digital fiable y con garantía de permanencia dado que las actualizaciones de los programas vuelven obsoletos los archivos con la rapidez inusitada de seis meses en promedio. Todos nos hemos dado cuenta en alguna ocasión que es prácticamente imposible abrir un archivo .docx creado y guardado en la versión más actualizada, con una versión anterior del programa. MS World es un buen recurso para el flujo de trabajo de las oficinas y empresas que generan una ingente cantidad de memoranda, circulares, oficios y cartas con una vida efímera; pero no funciona cuando se trata de generar textos cuyos originales necesariamente deben estar a la mano, funcionales y legibles muchos años después, como los textos académicos. Como una alternativa para contrarrestar los diversos problemas de los procesadores de texto como MS Word, Stross sugiere el uso de Scrivener, un procesador de texto pensado para la escritura de archivos largos. Pero, sobre todo, la mejor alternativa es escribir todo en texto plano, generando y guardando archivos .txt, mucho más flexibles, almacenables, distribuibles, independientes de plataforma2 y con garantía de permanencia y legibilidad a largo plazo. Y para ello no necesitamos un procesador de texto sino simplemente un humilde editor de textos como los que vienen por defecto en todas las máquinas: Notepad++ en Windows, TextEdit en OS-X, o la gran variedad de editores que hay para Linux como Vim o gEdit.

El punto de vista de un novelista como Stross es compartido por muchos académicos, pues los problemas que representan los procesadores de texto no son una novedad entre el gremio. W. Caleb McDaniel, un joven historiador de la Rice University en Houston, TX, y egresado de la prestigiosa Johns Hopkins University, es un verdadero entusiasta de este tipo de escritura sostenible independiente de plataforma y con garantía de permanencia. Basta con leer alguno de sus varios textos dedicados al tema, como por ejemplo, Why (and How) I Wrote My Academic Book in Plain Text -“Por qué (y cómo) escribí mi libro académico en texto plano.” En este texto, McDaniel explica detalladamente el cómo es posible adaptar la escritura en texto plano a los requerimientos de los textos académicos mediante la aplicación de un marcaje semántico en el propio texto con el lenguaje de marcado Markdown, desarrollado por John Gruber y Aaron Swartz. Así, es posible hacer uso de cursivas, negritas, listados, referencias y listas bibliográficas, tablas, notas a pie de página y demas florituras de los modos de escribir en nuestro oficio, con sólo un editor de texto plano. ¡Exacto! Hace falta solamente un editor de texto plano, conocer la sintaxis de Markdown y recurrir a herramientas pensadas especialmente para la escritura académica como Pandoc,3 un traductor que funciona en línea de comandos y que convierte archivos .txt o .md a cualquier formato imaginable: .doc, .docx, .odt, .pdf, .html, .tex y un amplio etcétera. Cabe decir que Pandoc fue desarrollado por John MacFarlane, un profesor de filosofía de la University of California, Berkeley; es decir, se trata de una herramienta para académicos pensada y hecha por académicos. En otras palabras: humanidades digitales en su máxima expresión. Al final de su entrada, McDaniel termina explicando el porqué no volvería a utilizar MS Word en su vida. Y yo estoy de acuerdo con él.

Desde que hace casi un año me topé con el sitio The Programming Historian (de cuyo equipo editorial ahora formo parte),4 descubrí varias herramientas y lecciones que me permitieron dejar de complicarme la existencia con los procesadores de texto, así como otra serie de prácticas sostenibles para la producción académica, al grado de que tengo ya varios meses en los que no he abierto MS Word para escribir mis textos, sino única y exclusivamente para leer los que recibo. A continuación dejo algunas pistas de lo que nos puede ser útil como científicos sociales o humanistas para crear textos académicos digitales sostenibles.

En The Programming Historian se encuentra una buena introducción a Markdown, escrita por Sarah Simpkin, “Getting Started with Markdown.” También hay una excelente lección que nos enseña a generar una escritura sostenible con texto plano, Markdown y Pandoc, escrita por Dennis Tennen y Grant Wythoff, “Sustainable Authorship in Plain Text using Pandoc and Markdown.” Si a esto le sumamos buenas prácticas para la conservación de los datos de nuestra investigación, como las que sugiere James Baker en “Preserving Your Research Data“, podemos tener la seguridad de que nos ahorraremos los incontables dolores de cabeza, pérdidas y problemas que nos depara (casi) siempre el uso de software propietario, lo cual redundará en la calidad, permanencia, posibilidad de distribución y colaboración, almacenamiento y más de nuestros textos académicos.

Para leer más

  • Dougherty, Jack y Kristen Nawrotzki. 2013. Writing History in the Digital Age. Ann Arbor: University of Michigan Press. http://writinghistory.trincoll.edu
  • Rosenzweig, Roy. 2011. Clio Wired: The Future of the Past in the Digital Age. New York: Columbia University Press. http://public.eblib.com/choice/publicfullrecord.aspx?p=895110.
  • Voutssas Márquez, Juan. 2013. Cómo preservar mi patrimonio digital personal. México: Universidad Nacional Autónoma de México, Instituto de Investigaciones Bibliotecnológicas y de la Información.

  1. Acrónimo de “what you see is what you get” (lo que ves es lo que obtienes), para referirse a la capacidad de la interfaz gráfica de usuario de las aplicaciones para desplegar el diseño de un documento digital tal y como se verá impreso. Sin embargo, la idea de WYSIWYG es tramposa, pues lo que en realidad conseguimos es un archivo con un código y un marcado muy complejos y confusos para nuestro entendimiento, que se aloja en una capa “invisible”, lo cual lo hace inmanejable.
  2. Es decir, legibles sin pérdidas o alteraciones en cualquier plataforma o sistema operativo como Mac, Linux o Windows.
  3. Pandoc es una “biblioteca” o conjunto de módulos o programas escritos en Haskell, un lenguaje de programación de alto nivel multi propósito, y cuenta con una herramienta de línea de comandos que permite utilizar dicha biblioteca.
  4. Estamos trabajando muy duro y en breve contaremos con una versión en español de todo el contenido alojado en The Programming Historian.

 

Historiadores y bases de datos 3. Jean Bauer y Project Quincy

Hace tiempo que estoy buscando la manera de mejorar y hacer más efectivo el manejo de la información que suelo procesar en una base de datos, pues generalmente he topado con algunos problemas serios a la hora de intentar compartir esa información entre usuarios de distintos gestores de bases de datos y, sobre todo, entre las distintas plataformas más utilizadas (Windows, Mac, Linux). Uno de los peores problemas es el paso de los datos entre los diferentes programas de aplicación propietarios, así como de las herramientas de procesamiento y análisis que cada uno de ellos puede generar. Por ejemplo, al intentar pasar la información de una vieja base de datos documental que utilicé para la escritura de mi tesis doctoral y que fue diseñada en el DBMS Microsoft Access a otro programa (en este caso, FileMaker, por la flexibilidad para trabajar y compartir información entre diversas plataformas, específicamente Windows y Mac), me encontré que, en ocasiones, los datos de algunos campos no tenían transparencia del 100% a la hora de migrarlos. Pero lo que me pareció más terrible es que las consultas SQL diseñadas en Access gracias a la integración del Visual Basic en el propio DBMS, eran irrecuperables en el nuevo programa de gestión de datos (aunque en FileMaker también se pueden ejecutar consultas SQL, pero la escritura del script es diferente). Finalmente, lo más patético es que resulta casi imposible compartir los datos y las consultas con otros colegas o con un equipo de trabajo si cada quien utiliza una plataforma distinta, un programa de aplicación distinto, más aún en el caso de que se quiera que la base de datos sea útil para un equipo de colabores que aporten información y que la usen colectivamente para la investigación.

El caso es que mi decepción sobre el diseño de bases de datos con los gestores comerciales se le ha sumado que, con el paso del tiempo, he acumulado una creciente desconfianza en el uso de software propietario para la investigación histórica. A la vez estoy cada vez más convencido de la necesidad de crear nuestros propios recursos para poder compartir nuestros datos entre más colegas a la vez que nos aseguramos que no sean perecederos por causa de la caducidad tecnológica tanto de software como de hardware.

Todo esto para comentar que una de las soluciones que me ha parecido más viable en teoría es la de crear bases de datos con recursos informáticos menos anclados a las directrices del software propietario común y corriente. En este caso (y gracias a una explicación que me dio hace algunos años Esteban Sánchez Rodríguez), la solución más inteligente sería la creación de una base de datos SQL que resida en un servidor. Para ello, lo más fácil sería la utilización de MySQL que, aunque es software propietario, permite una mayor flexibilidad de uso en diferentes plataformas. A esto le seguiría el diseño de un recurso de gestión y visualización en el navegador Web mediante un lenguaje de programación de alto nivel. Esto permite compartir la base de datos en Internet aprovechando las posibilidades de la Web 2.0.; es decir, de la misma manera en la que operan sitios como Facebook, Wikipedia o WordPress, lo cual nos da la posibilidad de integrar un equipo de trabajo amplio que pueda hacer uso de la base de datos ya sea vía consulta o directamente alimentando los datos en línea si el usuario tiene las credenciales adecuadas para ello.

Después de conversar con Jairo Antonio Melo el otro día sobre el diseño de una base de datos prosopográfica con estas características, me envió el enlace a un ejemplo muy interesante. Se trata de Project Quincy, una base de datos que se puede visualizar en Internet y que ha permitido desarrollar proyectos como The Early American Foreign Service Database (EAFSD), que cubre los primeros cincuenta años de la historia de la diplomacia estadounidense enfocada en los individuos que formaron parte de ella.

The Early American Foreign Service Database

The Early American Foreign Service Database

Project Quincy fue desarrollado por la joven historiadora y programadora Jean Bauer (hija, por cierto, de un informático y una novelista). Bauer diseñó una base de datos en MySQL que almacena información sobre personas, lugares e instituciones y que permite trazar la formación de redes de relaciones sociales (parentesco, patronazgo), la correspondencia entre individuos; la formación, crecimiento y decadencia de organizaciones y de las propias redes, todo ello a través del tiempo. Permite vincular la mención de fuentes para cada evento individual, y un largo etcétera. Por su parte, la visualización y gestión de la base de datos se hace mediante un sencillo framework para aplicaciones web, Django, cuyo código está escrito en Python y por lo tanto bastante accesible para historiadores programadores neófitos.

ProjectQ

Project Quincy (trace the network)

Project Quincy tiene a su favor que es una base de datos creada por una historiadora para historiadores interesados en las redes. Como dice la propia Jean: “La base de datos existe para conectar gente con otra gente en un momento particular, en un lugar en particular y por una razón en particular, permitiendo al usuario el mapeo de redes de correspondencia […] tiene más o menos seis módulos de interconexión, cada uno para rastrear diferentes tipos de redes e información: biográfica (profesional, relaciones personales, lugares de residencia); organizaciones (afiliación e historia de la institución), correspondencia (cartas); asignaciones (conectar a una persona, un trabajo y un lugar en un periodo de tiempo específico), ubicaciones y citas documentales y/o bibliográficas. ”

Dos cosas a su favor es que la base de datos trabaja en línea y puede integrar a múltiples usuarios para trabajo en colectivo. Otra cosa a su favor es que el código está disponible de manera libre en el GitHub de Jean. En cuanto tenga un tiempito voy a descargarlo y hacer una prueba. Ya les comentaré.

Historiadores y bases de datos 2. Claudia Espejel y la Relación de Michoacán.

Portal de la Relación de Michoacán, Instrumentos de consulta. ©2008, El Colegio de Michoacán, A.C.

Portal de la Relación de Michoacán, Instrumentos de consulta. ©2008, El Colegio de Michoacán, A.C.

Relación de Michoacán: instrumentos de consulta, es un portal interactivo en Internet que permite al usuario buscar y examinar con detalle la información contenida en esa importante fuente documental manuscrita de la primera mitad del siglo XVI, atribuida al franciscano fray Jerónimo de Alcalá. El portal, que es parte del sitio de El Colegio de Michoacán, lleva en línea por lo menos ocho años, así que en esta entrada no trato de una novedad que acabe de aparecer en la web 2.0, sino que busco señalar algunas estrategias y recursos metodológicos que están detrás de su diseño como medio digital de divulgación del conocimiento histórico, y que fueron creados a la par de que Claudia Espejel desarrollaba una investigación que dio lugar a una tesis doctoral y, posteriormente, a un libro.1

Aunque es de sobra conocida por los estudiosos e interesados en el Michoacán prehispánico y colonial, merece la pena apuntar algunos detalles acerca de la fuente documental misma para, a continuación, tocar algunos aspectos de la investigación de Espejel en los que fue crucial la utilización de recursos informáticos.

relacionLa Relación de Michoacán ha sido llamada así a partir de que en la primera línea de la foja uno del original se lee: Relaçion de las çerimonjas y rrictos y poblaçion y governaçion de los yndios de la provinçia de mechuacan hecha al yllustrisimo señor don antonio de mendoça, virrey y governador desta nueva españa por su magestad, &tc. Fue mandada hacer por orden del primer virrey de Nueva España durante su visita a la provincia en 1539 y terminada a principios de la década de 1540. El fraile autor del documento debía describir las costumbres y la forma de gobierno de los indios mechuaques,2 y para ello debe haberse rodeado de un grupo de informantes, escribanos y pintores seguramente indios, para recabar y organizar y presentar la información. Del documento se conservan 143 fojas manuscritas entre las que se encuentran 44 láminas que describen en imágenes algunos de los pasajes del texto, y a lo largo de ellas se menciona una gran cantidad de lugares, personajes, dioses que muchas veces están asentados con grafías diferentes, así como una serie de categorías que hacen referencia a la organización social, política y religiosa de los indios michoacanos. Por alguna razón que aún no ha sido documentada, el manuscrito llegó a manos de la Orden de San Agustín y quedó depositado en la Biblioteca del Monasterio de San Lorenzo de El Escorial, en donde se comenzó a consultar y copiar a partir de mediados del siglo XIX. Desde entonces a la fecha, la Relación de Michoacán, muchas veces editada e impresa por distintos estudiosos, ha sido utilizada como pieza clave o, incluso, piedra angular para escribir una historia sobre los indios michoacanos de finales del siglo XV y principios del XVI, a la vez que ha servido de referente documental también para la interpretación de los estudios arqueológicos en la región. Es decir, durante cerca de 160 años, la Relación de Michoacán había sido únicamente utilizada como fuente de datos con los que sostener las diversas interpretaciones sobre la cultura, costumbres e historia de los indios del antiguo Mechuacan.

justiciaYfuego1Pero, ¿cómo se hizo y estructuró la Relación de Michoacán? Claudia Espejel enfocó su investigación en la comprensión de cómo está construido el documento en sí mismo, su estructura interna y el modelo o los modelos discursivos que forman el andamiaje sobre el que se elaboró el texto. Producto de este ensayo hermenéutico es la propuesta de varias claves para la lectura de la Relación…, una de ellas muy sugerente y controvertida, ya que propone que la estructura y la forma de organizar la descripción de la cultura y el gobierno mechuaque sigue las pautas de la descripción y organización del mundo presente en un viejo documento jurídico castellano: las Siete Partidas. Dicho de otra manera, Espejel propone una lectura intertextual que permite comprender la estructura mental del autor de la Relación así como su texto. Esto, sin menoscabo de otras claves culturales propias de esa sociedad que habitó la región lacustre del occidente de Mesoamérica. De ahí, por cierto, el título del libro de Espejel: La justicia y el fuego.

Como parte del proceso de investigación, Espejel tuvo que sistematizar el conjunto de la información presente en el texto. Entre otras de sus preocupaciones (arqueóloga de primera formación, a fin de cuentas), le interesaba tener una relación de lugares capaz de echar luz sobre asentamientos de poblaciones y sitios ceremoniales; así como también poder organizar la gran cantidad de referencias y personajes que aparecen en el texto del siglo XVI. Uno de los productos de esta sistematización es el segundo volumen del libro en que dedica sus 330 páginas a la presentación de un glosario que incluye los nombres de 313 lugares, 215 personajes, 66 dioses y 300 categorías sociales. Cerca de 900 fichas en las que Espejel ofrece información sobre significados, localización geográfica, las diversas grafías o las equivalencias lingüísticas en su caso, su representación en las láminas, su ubicación en el texto de la Relación… o su referencia en otras fuentes.

Para poder organizar todos estos datos, Espejel utilizó fundamentalmente dos recursos informáticos: un sistema de bases de datos relacional y un sistema de información geográfica. Una muestra de los productos generados se pueden apreciar en el libro, pero de manera estática: el glosario de más 300 páginas y varios mapas. De ahí que haya sido una buena idea la publicación paralela del portal en línea pues no sólo sirve como instrumento digital de divulgación del conocimiento, sino como un producto en el que se muestra de manera dinámica el funcionamiento de los recursos informáticos elaborados durante la investigación ya que se pueden hacer consultas a la base de datos casi como si se estuviera utilizando la BD original en la computadora de la investigadora, o se pueden consultar los mapas de manera interactiva casi como si se estuviera frente a la interfaz del programa de aplicación del SIG. Cabe decir que esto implicó un trabajo de equipo pues Esteban Sánchez Rodríguez se encargó de asesorar y ayudar a diseñar las BD, Marco A. Hernández Andrade se encargó del SIG y Carlos A. Villalpando de Santiago se encargó del diseño del sistema en línea.

Relación de Michoacán. Instrumentos de consulta. ©2008, El Colegio de Michoacán, A.C.

Relación de Michoacán. Instrumentos de consulta. ©2008, El Colegio de Michoacán, A.C.

El sistema de BD en las que se capturó la información para su procesamiento consiste en cuatro ficheros (lugares, personajes, dioses y categorías sociales). El primer paso para armar los ficheros fue abrir un registro con cada término y llenar una serie de campos descriptivos y analíticos. Los dos campos más importantes asociados a cada registro consisten en uno con el vaciado de citas textuales de la Relación… en las que aparece el término para enseguida llenar otro campo del registro con una síntesis explicativa. A estos se le fueron agregando campos en función de la naturaleza de los registros. Paralelamente, se fue conformando otra serie de tablas interconectadas que permiten relacionar cualquier registro de los cuatro ficheros con elementos importantes para el análisis: acontecimientos que sucedieron en un lugar o en el que interviene un personaje, en el que se menciona algún dios o se hace referencia a una categoría social. También se incluyeron otras tablas vinculadas, entre las que merece mención especial la que recoge el inventario de los sitios arqueológicos hasta hoy conocidos que pueden asociarse con cada lugar mencionado en la Relación… Esta tabla contiene información detallada del sitio arqueológico como la de localización (coordenadas geográficas), lo que permite enlazar la base de datos directamente con el Sistema de Información Geográfica.

Relación de Michoacán. Instrumentos de consulta. ©2008, El Colegio de Michoacán, A.C.

Relación de Michoacán. Instrumentos de consulta. ©2008, El Colegio de Michoacán, A.C.

Finalmente, la construcción del portal electrónico se dio de manera natural, ya que fue posible gracias al potencial analítico que demostró tener el uso de dos recursos informáticos vinculados cuyo objetivo inmediato fue el de recopilar datos, organizarlos y procesarlos en el transcurso de una investigación cuya pregunta inicial fue ¿cuáles son las claves que nos permitan leer la ya tan leída Relación… del viejo fraile del siglo XVI de manera comprensiva?

Notas:


  1. Claudia Espejel Carbajal, La justicia y el fuego. Dos claves para leer la Relación de Michoacán, 2 Vols. (Zamora: El Colegio de Michoacán, 2008). Este libro es una versión corregida y aumentada de la tesis doctoral: Claudia Espejel Carbajal, “Voces, lugares y tiempos: claves para comprender la Relación de Michoacán”, dirigida por el Dr. Rafael Diego-Fernández y defendida en El Colegio de Michoacán en 2004. El libro se puede conseguir en este enlace, y la tesis puede descargarse de este enlace, pinchando el documento enlazado en el recuadro a la derecha de la ficha bibliográfica. 
  2. La larga y en apariencia inacabable discusión (por bizantina) sobre si se debe llamar tarascos o purépechas a los habitantes de la región lacustre montañosa de la antigua Provincia de Mechuacan me hace optar por llamarlos mechuaques, con todo el peligro que conlleva de recibir una andanada de pedradas discursivas. Por si el lector quiere revisar la discusión y el problema de asumir uno u otro vocablo, recomiendo mucho leer el interesante libro de mi querido amigo y admirado colega Rodrigo Martínez Baracs, Convivencia y utopía. El gobierno indio y español de la “ciudad de Mechoacan”, 1521-1580 (México: Fondo de Cultura Económica / CONACULTA / INAH, 2005), sobre todo pp. 19-84 

Sobre la posibilidad de resolver problemas (crear un bash)

Nótese que esta entrada replica la publicada en este sitio.

Creo que todos los que usamos una computadora tenemos la posibilidad de resolver problemas que se presentan en su funcionamiento con un poco de paciencia, tiempo, voluntad de aprender y recurriendo a la información que hay en Internet. A partir de un error detectado a la hora de correr un programa que acababa de instalar en mi computadora, hace unas semanas me pude dar cuenta de la importancia que tiene el aprender a utilizar con provecho varias herramientas que suelen venir “de fábrica” con nuestras computadoras personales para, entre otras cosas, solucionar algunos problemas. Problemas, por otra parte, que parecen ser de lo más comunes actualmente, según me comentó hoy mi estimado amigo Francisco A. Moreno. Por ejemplo, algunos de los errores más comunes surgen cuando no hay compatibilidad entre el cómo se gestionan las diferentes codificaciones de lenguajes entre sistemas. No es lo mismo codificar mediante el Formato de Transformación Unicode de 8 bits (UTF-8) que mediante el American Standard Code for Information Interchange (ASCII). Y eso lo reconocen los programas y sus variantes, y por ese tipo de aparentes nimiedades dejan de funcionar, o se niegan a hacerlo. Pero siempre hay una solución y, curiosamente, está a la disposición de todos en cada máquina que utilizamos.

Hace unos años me propuse aprender el funcionamiento de los Sistemas de Información Geográfica (SIG), porque entendí que no solamente es una buena forma de producir cartografía de las regiones históricas que estudio (utilizarlos para visualizar mapas), sino también porque sirve como un recurso muy poderoso para analizar y poner a pruebas una serie de preguntas e hipótesis acerca de los procesos de conformación de territorios y jurisdicciones en siglos pasados. Pero sobre estas preguntas e hipótesis escribiré en otro lado para no perder por ahora el asunto principal de esta entrada.

El caso es que me decidí a utilizar un SIG que fuese software libre y de código abierto: el  Quantum Gis [QGis (1.8.)]. Entonces lo utilizaba en OS X 10.8 y luego quise utilizarlo en Windows 8.1 Pro. (que era el sistema de la computadora de la oficina), pero cuando me enfrenté al problema de cargar GRASS en Windows dejé los experimentos por la paz. Como solamente utilizo el SIG con la finalidad de hacer borradores de mis mapas y pequeños análisis, y lo que me ofrece el programa sin usar el GRASS siempre ha sido más que suficiente. A fin de cuentas, cuando se requiera de un apoyo especializado, sé que el encargado del GIS de mi entorno laboral sabrá hacer las cosas mejor que yo, pero mi interés en cómo hace él su trabajo me permitirá comunicarme mejor y explicarle cuáles son mis necesidades.

Desde hace unas semanas volví a explorar sistemáticamente las posibilidades del QGis porque estoy dirigiendo un seminario sobre Historia y región – Tiempo y espacio en el trimestre enero-marzo, y quiero comunicarle  a los asistentes que pueden aprovechar los SIG para la investigación histórica. Entonces aproveché la ocasión para instalar la nueva versión de QGis (2.12.1 ), y quise instalar la nueva versión de GRASS 7 para aprender más sobre sus posibilidades (para lo que se requiere tener alguna noción rudimentaria del lenguaje de programación Python),  siguiendo cuidadosamente los pasos para la instalación previa de los diversos frameworks de William Kingesburye. Sin embargo, la terminal de OS X detectó un error a la hora de correr la aplicación:

ValueError: unknow locale: UTF-8

Esto es, el error más común que se presenta en el manejo de lenguajes entre sistemas. No voy a abundar más sobre ello por el momento. Los que conozcan más acerca de cómo funcionan nuestras PC sabrán que este error está relacionado con las variables de entorno, es decir, aquellos valores dinámicos que afectan al desempeño de un programa en un sistema determinado. Para los que no conozcan más a fondo el funcionamiento de sus máquinas (a fin de cuentas eso son: máquinas programables), no importa. La consigna es: “No entrar en pánico.”

Lo maravilloso es que este error me llevó a descubrir cómo utilizar mejor los recursos propios del sistema operativo de mi máquina (OS X 10.11.13), y que con un poco de imaginación se pueden ampliar a los demás sistemas operativos. Solamente necesitamos el editor de texto plano (TextEdit o NotePad) que viene como aplicación del sistema, así como un emulador de terminal  (Terminal) o intérprete de comandos (Símbolo del Sistema o command prompt). Por supuesto que utilizar un editor de código resuelve muchas cosas, pero ésta última es una herramienta que no todos  piensan utilizar mientras que las dos anteriores están presentes “de cajón” en sus computadoras.

Para solucionar el problema que tuve, en la Wiki de GRASS proponen crear o editar un pequeño programa que le permita a la computadora interpretar una serie de órdenes dadas por el usuario. Estos breves programas se deben crear mediante archivos bash que contienen las órdenes expresadas mediante líneas de comandos. En este caso, se recomienda crear uno llamado “.bash_profile” en el directorio raíz ($HOME o “~/elnombredemimac/”), que tenga las siguientes líneas:

export LC_ALL=en_US.UTF-8
export LANG=es_US.UTF-8

La solución implicó enfrentar dos tareas. En primer lugar, hacer visibles los archivos ocultos en el directorio raíz para confirmar que no había un archivo “.bash_profile” previo (cosa que suele ser así de fábrica) y, en segundo lugar, crear correctamente el archivo.

La forma más rápida de visualizar los archivos ocultos en OS X es mediante los comandos UNIX de Terminal:

ls -a

Pero si se quieren ver directamente en Finder es necesario utilizar Terminal para configurarlo de tal manera que aparezcan, mediante los comandos:

defaults write com.apple.finder AppleShowAllFiles -bool true

E inmediatamente hay que reiniciar el Finder con los comandos:

killall Finder

Para desactivar hay que hacer el proceso inverso:

defaults write com.apple.finder AppleShowAllFiles -bool false
killall Finder

Así, se pueden manipular los archivos ocultos desde Finder pero, aunque en apariencia es más sencillo hacerlo mediante la Interfaz Gráfica de Usuario (GUI) del Finder, en realidad lo más rápido es trabajar desde Terminal, además de correcto. Explico:

Crear el archivo “.bash_profile”

A falta de un editor de código, para crear un archivo “.bash_profile” es necesario utilizar un editor de texto que bien puede ser el TextEdit que viene incluido en el OS X. Sin embargo, encontré que es un error intentar crearlo desde la propia aplicación ya que a la hora de guardar el archivo no permite crear archivos sin extensión. Por un lado, borrar la extensión del nombre del archivo es difícil ya que no se puede editar un archivo oculto (todos los que empiezan por un punto) directamente desde la GUI del Finder así que hay que borrar la extensión desde el cuadro de información del archivo; y, por otro lado el archivo así creado guarda una serie de comandos “basura” dado que incluye información de estilo como si se tratase de un .rft o de un .html. Lo correcto es crearlo y abrirlo desde Terminal, cuidando de estar situados en el directorio raíz:

touch .bash_profile
open -a “TextEdit” .bash_profile

Se abrirá entonces la ventana de TextEdit sin ningún dato de estilo y podemos introducir los comandos arriba señalados:

export LC_ALL=en_US.UTF-8
export LANG=es_US.UTF-8

Para guardar es suficiente con salir de TextEdit. Si se tiene duda de la operación de los comandos del archivo “.bash_profile”, basta con correrlo desde Terminal:

source .bash_profile

Una vez confirmado que no hay problema, GRASS corrió perfectamente y me pide que  configure sus propiedades. Pero esto es cosa de hacer otra entrada. Mientras tanto, al estar navegando por Internet buscando la solución, me percaté de que este error de lenguaje no solamente esta relacionado con la instalación de GRASS, sino también de otros muchos programas que sirven para distintas cosas de interés en la investigación y divulgación del conocimiento.

Todo el proceso a mi me sirvió para aprender más. Espero que a alguien le sirva esta larga presentación.

Historiadores y Bases de Datos 1. François-Xavier Guerra

Nótese que esta entrada replica la publicada en este sitio.

Cuando estudié la licenciatura, allá por la década de 1980, me comenzó a interesar el uso de las computadoras y las posibilidades de aplicar la tecnología a la investigación histórica. En esos años era muy difícil acercarse a una Computadora Personal (PC), aprender a utilizarla y sacarle algún provecho. La primera máquina que recuerdo haber tecleado y que no dejaba de sorprenderme con lo que aparecía en la pantalla negra con caracteres verdes fue una Apple IIe que tenían en un laboratorio de arqueología de La Escuela y en la que ya se podía correr el dBase II, así que tuve la oportunidad de aprender algo sobre bases de datos (BD) y procesadores de textos (el transparente WordPerfect para el Apple DOS). Ahí fue cuando empezó mi curiosidad por las BD; primero el problema de cómo funcionaban y segundo el problema de cómo diseñar una BD para los fines de una investigación. Y en ese sentido, siempre es bueno detenerse a pensar cómo hicieron las cosas algunos historiadores que utilizaron recursos informáticos para su investigación.

Análisis de un diseño.

En 1988 apareció la traducción al español, en dos tomos, del importante libro de François-Xavier Guerra, Del antiguo régimen a la revolución, cuya investigación inició en 1971 y fue presentada como tesis de doctorado de estado en Francia en 1982, luego publicada como libro en 1985.(1) A mi no me interesaba en realidad una historia tan contemporánea, pero el trabajo de Guerra me llamó la atención por su propuesta metodológica. FX Guerra se propuso reconstruir y analizar el universo de los actores políticos del porfiriato y la revolución para encontrar las dinámicas de cambios y permanencias en el sistema. Para hacer el análisis, Guerra recurrió a una prosopografía colectiva para lo cual tuvo que armarse de una BD ad hoc que le permitiera la captura y el manejo de información biográfica de varios miles de personajes. Todo ello, obviamente, lo hizo con los recursos informáticos existentes en el momento en el que llevó a cabo su investigación: la década de 1970.

La base de datos prosopográfica que diseñó Guerra para estudiar a los actores políticos de la historia mexicana entre 1876 y 1930, reúne información de alrededor de 7,838 individuos y colectividades, y cuenta con cerca de cien mil datos diferentes relacionados a ellos: origen familiar, fecha y lugar de nacimiento, educación, carrera política o militar y riqueza. En suma, se trata de un total de cuarenta y dos variables asociadas a cada personaje que dan cuenta de su vida y actividad publica de manera sistemática. En la actualidad, cualquiera que tenga una PC podría tratar esta información con un programa de BD relacional de fácil manejo, como Microsoft Access o FileMaker. Pero en la década de 1970, las cosas era muy distintas.

Afortunadamente, FX Guerra incluyó la base de datos en los anexos I y II de su libro, así que se puede reconstruir la manera en la que fue diseñada. Sabemos por él también que tuvo que recurrir al Centro de Cálculo (CIRCE) en Orsay. Pero fuera de comentar que la base de datos tuvo que ser alojada en tres grandes cintas magnéticas, no nos da mayor detalle de la máquina o del programa que fue utilizado, y refiere solamente que éste fue diseñado por Denys Ducornet, seguramente un ingeniero en sistemas. Sin embargo, navegando por Internet me topé con que, por aquel tiempo, en el CIRCE de Orsay tenían máquinas de la familia IBM System 360. Así que la máquina en la que se desarrolló la BD de FX Guerra debió tener un aspecto parecido a la que se ve en la fotografía de abajo.

Supercomputer_NSA-IBM360_85-1024x830

IBM System 360 Modelo 85 Tomada de Wikipedia

La familia de las IBM System 360 corresponde a un tipo de máquina que se conoce como Computadora Central o Mainframe. Las IBM S-360 fueron producidas entre 1964 y 1977,  eran inmensas y funcionaban con sistemas operativos cuya utilización demanda necesariamente el conocimiento de lenguaje ensamblador de alto nivel para poder darle instrucciones a la máquina. Algunas tenian pantallas en las que se podían leer las líneas de comandos y guardaban los datos en grandes cintas magnéticas. La base de datos de Guerra estuvo contenida en tres de estas cintas. Es importante resaltar que, al contrario de nuestras actuales PC de escritorio, en ese tipo de máquinas es necesario codificar previamente toda la información que se introduce en la base de datos. El que FX Guerra haya considerado necesario incluir en los anexos del libro la explicación de cómo se codificó la información es de gran ayuda para los historiadores interesados en la prosopografía porque, aunque no utilicemos una IBM S-360 sino una pequeña PC con un programa de BD, nos muestra que es muy importante la manera en la que se eligen los datos a sistematizar y nos permite entender cómo diseñar una BD.

Cuando tuve en mis manos el libro de FX Guerra estuve repasando durante varios meses los anexos relativos a la base de datos. Para finales de la década de 1980, toda la explicación de la codificación podía parecer un tanto árida pues ya contábamos con PC con programas en los que se podían diseñar BD sin recurrir a una codificación previa tan compacta. Sin embargo, observar el sistema de codificación resultaba interesante e incluso útil porque, por entonces, los campos de las BD no soportaban textos largos tipo memo sino que tenían que construirse campos con solamente algunos cuantos caracteres alfanuméricos. Además, el ejercicio permitía que uno se adentrase en la lógica del diseño.

Aunque parece lo contrario a simple vista, la codificación es muy sencilla y obedece a las necesidades de interrelacionar partículas de información con una persona determinada, ya sea individuo o colectividad. Lo primero que tuvieron que hacer fue determinar una clasificación para los individuos, pues la finalidad de una base de datos prosopográfica es relacionar y organizar la información biográfica de los personajes. Para ello se optó por dotar a los individuos con un código de identificación único que consta de las iniciales de su primer apellido y su primer nombre, más un número arbitrario de uno a cuatro dígitos (al parecer, es el número consecutivo según se fue alimentando la BD). Por ejemplo, Francisco I. Madero está codificado como MF 7081, mientras que Porfirio Díaz tiene el código DP 7080. En el caso de las colectividades (ciudades, pueblos, unidades militares), el proceso de identificación es muy parecido.

Una vez organizada y sistematizada la lista de los actores individuales y colectivos, fue necesario establecer la codificación para el resto de la información. Como se trata de un análisis prosopográfico, los datos básicos hacen referencia a la vida de una persona: familia, nacimiento, educación, actividad pública y muerte. También son importantes los datos cronológicos y espaciales pues los individuos hacen su vida en el espacio-tiempo. Pero, como el interés principal era analizar la participación política, hay una serie de datos importantes que Guerra decidió tomar en cuenta: sus cargos políticos o militares, su actividad en acciones importantes, sus vínculos personales y su filiación política.

Cada uno de los acontecimiento de la biografía de un actor se codificó mediante la creación de un módulo de diez celdas en las que debía describirse el suceso de la manera más sintética posible. Cada módulo debía organizar la información sobre la naturaleza del acontecimiento, fechas, lugares, así como la característica específica de ese dato. Después, cada una de las celdas se llenó con un carácter alfanumérico preestablecido y así se obtenía el código respectivo del acontecimiento particular.

Los datos biográficos de un individuo adquieren una sintaxis curiosa en el informe impreso de la BD. Por ejemplo, para referirse al nacimiento de una persona el módulo comienza con el código BN (posiblemente “biographie” y “naissance“) en las dos primeras celdas; las dos siguientes se refieren al año de nacimiento, la siguiente al mes, y las cinco restantes al lugar. De tal manera, los datos del nacimiento de Francisco I. Madero se expresan con la siguiente sintaxis:

BN73ACO036

Lo cual quiere decir que Francisco I Madero nació en algún día del mes de octubre de 1873, en la Hacienda de Parras, Coahuila.

Veamos, por ejemplo, la ficha biográfica completa de Bernardo Reyes en la base de datos de FX Guerra:

BREYES0

Biografía codificada del Gral. Bernardo Reyes en la BD de F-X Guerra

Los códigos leídos por filas de izquierda a derecha y de arriba a abajo indican lo siguiente: 1) Es parte de una red de lazos interpersonales (LX), 2) Origen familiar (BF), 3) Fecha y lugar de nacimiento (BN), 4) Cultura (BC), 5) Profesión (BW, 6) Grado militar (WF), 7) Victoria militar (BZ), y así hasta llegar a BM que se refiere a la fecha y lugar de fallecimiento que, en el caso de Reyes se lee: “caído en combate en el mes de febrero de 1913 en la ciudad de México.”

Por fortuna, las BD en la actualidad nos permiten generar campos con texto completo y no es necesario sintetizar la información como se hacía anteriormente, aunque estos campos presentan el problema de no poder ser indexados por lo que tenemos que elegir cuáles campos de nuestra BD podrán contener texto completo y cuales necesariamente deberán ir ser numéricos o alfanuméricos con un número de caracteres limitado para que la BD tenga un mejor rendimiento. Pero ese será el tema de otra entrada.

Lo que sigue siendo muy interesante de la BD de FX Guerra es el cómo se determinaron las variables que entran en juego en la biografía de una persona así como su clasificación. Mientras que un grupo del total de las 46 variables se refiere a acciones específicas de la vida (nacimiento, educación, origen, muerte), otras se refieren a los cargos políticos, administrativos y militares ocupados por la persona. Es decir, una base de datos prosopográfica de este tipo está diseñada haciendo énfasis en las personas como actores políticos. Si nosotros queremos diseñar una base de datos prosopográfica, no solamente tendremos que incluir los datos vitales de las personas sino todos aquellos acontecimientos que sean importantes dependiendo de la orientación de nuestra investigación. Así, serán diferentes los acontecimientos incluidos en una BD construida para una investigación de historia empresarial que los incluidos en una investigación sobre historia intelectual. Por lo pronto, aquí dejo las variables de la BD de FX Guerra.

Variables

 


Notas:

(1) François-Xavier Guerra, Del antiguo régimen a la revolución, 2 Vols., trad. de Sergio Fernández Bravo, México, Fondo de Cultura Económica, 1988 (Sección de Obras de Historia). Edición original: Le Mexique de l’Ancien Régime à la Revolution, Paris, L’Harmattan/Publications de la Sorbonne, 1985 (Travaux et mémories de l’Institut des hautes études de l’Amérique latine, 36).