Expedientes. Análisis

Análisis de datos (IX)

Expedientes Excel (b)

Parece que ya tenemos definido el concepto de expediente SEO digitalizado, tanto en términos cuantitativos como cualitativos, así que ahora toca pasar al análisis en función de los objetivos indicados en la [entrada anterior]. Pero se nos presentan varios problemas que habrá que solucionar antes de empezar con el análisis propiamente dicho.

El primero es disponer de datos que consultar, o mejor dicho, determinar cuáles son las fuentes de datos, ya que no podemos utilizar el listado inicial (no nos aporta más que el total de elementos (archivos) por directorio (expediente) ni podemos usar el procedimiento que nos sirvió para identificar y extraer los datos que nos sirvió para realizar el análisis de los repositorios de documento único.

En este caso, por diferentes motivos prácticos (ya están disponibles) pero también por avanzar en el aprendizaje de procedimientos (acceso secuencial al contenido de múltiples archivos), me propongo trabajar con una colección de archivos sobre hoja de cálculo, resultantes de un DocAp que se expone en esta misma sección del blog, que contienen datos cuantitativos y de estructura de un conjunto amplio de expedientes SEO.

El problema que nos encontramos es que estos archivos están en formato Calc y por motivos que no tengo claros, no me es posible acceder a su contenido mediante la [biblioteca ezodf], así que me veo obligado a buscar una solución que facilite el posterior acceso a los archivos desde Python. Esto es necesario tanto por las limitaciones de OOo Basic para trabajar con múltiples documentos como por el interés que tiene el uso de Python en el análisis de datos.

Y digo esto como planteamiento inicial, porque la solución encontrada bien podría considerarse una demostración práctica de la potencia de OOo Basic para automatizar el manejo de un conjunto amplio de documentos; lo que no nos  lleva a modificar el proyecto inicial de usar Python como herramienta fundamental para el análisis de datos.

Empecemos por clarificar algunas cuestiones. Dispongo de un total de 244 archivos Calc, resultantes de la aplicación de [este DocAp]. Este total es suficientemente elevado como para considerarlo acorde con el volumen total de expedientes disponible (483). Sabiendo que esos documentos no recogen loa datos de los expedientes de 1 y 2 documentos, podemos considerarlos además, representativos de aquellos que caen dentro del concepto amplio de expedientes, aunque algunos de ellos puedan estar dentro del subgrupo de expedientes fallidos. 

A efectos prácticos vamos a considerar este dato como desconocido; en realidad podremos identificarlos visualmente o por análisis cruzados del listado con la visualización del contenido del directorio donde se encuentran. Precisamente es este trabajo "visual" el que pretendemos evitar.

Así que, aunque ya tenemos identificada nuestra fuente de datos, y podemos considerarla ajustada a nuestro objetivo, es necesario transformar el tipo de documento de Calc a Excel, para poder desarrollar después procedimientos de acceso a datos basados en Python y en su [biblioteca OpenPyxl]. Si queremos evitar realizar manualmente esta conversión desde Calc, deberemos recurrir un script o a una macro OOo Basic; si bien antes es conveniente aportar a ese soporte el listado de los documentos Calc que vamos a convertir en Excel, y para ello necesitamos recurrir a Python, concretamente a su [librería os]. Como puedes ver, todo un complejo enredo de interdependencia . En realidad una complejidad más aparente que real. Veremos por qué. 

Dado que se impone como necesidad la conversión de archivos Calc a Excel (recuerda que Calc lee .xls/xlsx, pero Excel no lee .ods), la solución que se me ocurre es utilizar Calc para realizar esa conversión, automatizando el procedimiento mediante un script basado en una macro. Ello lleva (como veremos) a desarrollar un procedimiento basado en tres subrutinas enlazadas en tándem: la primera llama a la segunda y la segunda a la tercera.

Esta solución, que requiere explicación específica, implica automatizar el proceso en parte, pero deja pendiente hacerlo a su inicio, dado que no dispongo de solución OOo Basic que facilite el acceso a los nombres de todos los archivos del directorio. Sin embargo esto es posible hacerlo sin dificultad mediante Python, concretamente usando su módulo os.

Resuelvo, pues, la automatización del acceso a la colección de documentos Calc mediante un script Python…

import os

directorio = "ExpedCalc/"

contenido = os.listdir(directorio)

n_elem = 0

print('Listado de componentes \n')

for elemento in contenido:

    n_elem = n_elem +1

    print (f'Elemento número {str(n_elem)} -> {elemento}')

print(f'\n TOTAL elementos del directorio {str(n_elem)}')

archivo = open('listaExped.txt','x', encoding='utf-8')

for elemento in contenido:

    archivo.write(elemento+'\n')

archivo.close()

… que accede al directorio que contiene los documentos Calc (directorio = "ExpedCalc/"), extrae el contenido (contenido = os.listdir(directorio)) y después de mostrarlo en pantalla lo copia en un documento txt (archivo = open('listaExped.txt','x', encoding='utf-8')) mediante un bucle (for elemento in contenido: -> archivo.write(elemento+'\n'))...

A continuación copio el contenido de este documento txt en un archivo Calc en blanco y obtengo un listado parecido a éste.

 Como puedes ver se reproduce perfectamente el listado obtenido con el script Python, por lo que nos sirve para generar el código OOo Basic necesario para realizar la transformación de documentos Calc en Excel. 

Pero el desarrollo de este procedimiento (te ahorro ese recorrido fallido) permite considerar que no es buena idea incluir la extensión del archivo como parte del texto a manejar (ya veremos el motivo), así que necesitamos trabajar con este listado para quedarnos sólo con el nombre y prescindir de la extensión .ods.

Para ello recurro a funciones built-in de Calc, concretamente a dos del grupo Texto: LARGO() e IZQUIERDA(). La primera calcula la longitud (n caracteres) de una cadena de texto y la segunda permite extraer una parte de esa cadena empezando desde la izquierda. Así que primero calculamos la longitud de cada uno de los elementos del listado y después aplicamos la función IZQUIERDA() pasando como primer parámetro la cadena y como segundo la diferencia (LARGO(Ax)-4), siendo 4 la longitud de la extensión más el punto (.ods).

Lo que obtenemos es un documento Calc que contiene una triple lista: la de los nombres íntegros de los archivos, la de la longitud de cada nombre y la de los identificadores de los archivos (nombres sin la extensión). Esta última (columna C) es la que nos interesa para desarrollar los script OOo Basic.

Partiendo de esta nueva lista sin las extensión .ods puedo aplicar un conjunto de tres script (en realidad un script y dos subrutinas) que trabajan en tandem y que (esto es muy importante) es necesario ubicar en el directorio Mis macros y diálogos, biblioteca Standard del IDE (no en  el directorio de script del documento).

El primero de estos tres script OOo Basic (acceso_lista) permite tomar cada elementos del listado para automatizar el acceso a los archivos Calc. Por ello es necesario activarlo desde el documento Calc sobre el que creamos la lista que vemos en la imagen anterior (podemos llamarlo lista_al.ods, por ejemplo). Aquí tienes el código de este primer script:

Sub acceso_lista

Dim  oHoja As Object

Dim oCelda As Object

Dim oDato As Object

Dim i As Integer

Dim n As Integer

Dim Archivo As String

n = 244

oHoja = ThisComponent.getSheets().getByName("lista") 

for i = 1 To n

oCelda = oHoja.getCellRangeByName( "C" & i)

Archivo = oCelda.getString()

AbrirDocumento(Archivo)

Next

End Sub

Como puedes ver, este script permite acceder a la lista Calc mediante el procedimiento conocido de acceso a libro->hoja->celda. Utiliza un bucle For…Next para recorrer dicha lista, entregando cada uno de los datos obtenidos a la subrutina AbrirDocumento() encargada de acceder al documento Calc.

Sub AbrirDocumento (alumno)

Dim sRuta As String

Dim mOpciones(0) As New "com.sun.star.beans.PropertyValue"

Dim oDoc As Object

mOpciones(0).Name = "MacroExecutionMode"

mOpciones(0).Value = 4

Dim ruta As String

ruta = "D:/EXPEDIENTES/ExpedientesOriginales/" & alumno & ".ods"

sRuta = ConvertToUrl(ruta)

oDoc = StarDesktop.loadComponentFromURL( sRuta, "_blank", 0, mOpciones() )

Dim oHoja As Object

Dim oCelda As Object

Dim iDato As Integer

Dim archivo As String

oHoja = ThisComponent.getCurrentController.getActiveSheet()

oCelda = oHoja.getCellRangeByName("C10")

iDato=oCelda.getValue()

if iDato <= 4 Then

oDoc.close(True)

Else

archivo = alumno

grabar_excel (archivo)

End If

End Sub

Esta subrutina permite acceder al archivo Calc, capturar el valor de la celda C10 que contiene el dato del total de documentos del expediente y, en función del (in)cumplimiento de una condición (if iDato <= 4 Then) llamar a la subrutina siguiente (grabar_excel (archivo)) pasando como parámetro el mismo dato que recibió ella también como parámetro (Sub AbrirDocumento (alumno)), antes de convertirla en una URL (sRuta = ConvertToUrl(ruta)), lo que garantiza el acceso al documento con independencia de la plataforma, pero también con total seguridad (evidentemente esa dirección debe existir y contar con los documentos Calc a los que se desea acceder).

Finalizamos el procedimiento haciendo entrar en escena la segunda subrutina y tercer componente del tandem (grabar_excel (documento)), que se encarga de grabar el archivo como Excel y en su correspondiente directorio. 

Sub grabar_excel (documento)

dim document   as object

dim dispatcher as object

document   = ThisComponent.CurrentController.Frame

dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

dim archivo As String

archivo = "file:///D:/EXPEDIENTES/ExpedientesExcel/" & documento & ".xlsx"

dim args1(1) as new com.sun.star.beans.PropertyValue

args1(0).Name = "URL"

args1(0).Value = archivo

args1(1).Name = "FilterName"

args1(1).Value = "Calc MS Excel 2007 XML"

dispatcher.executeDispatch(document, ".uno:SaveAs", "", 0, args1())

document.close(True)

end sub

Como puedes ver, esta subrutina se basa en código macro posteriormente modificado. Esta modificación se concreta como transformación de la macro en subrutina y como sustitución de la ruta absoluta directa por una variable string previamente modificada (archivo = "file:///D:/EXPEDIENTES/ExpedientesExcel/" & documento & ".xlsx") para ajustarla a los valores múltiples que va a presentar a lo lago del proceso, ya que todo ello (y en ambas subrutinas) está dentro del bucle For definido en el script principal.

El resultado es que obtenemos una copia de archivos Excel que cumplen el criterio de contener datos sobre expedientes SEO con 5 y más documentos. Estos archivos quedan ahora a disposición de script Python, objetivo último de esta fase del proceso. El directorio en el que se encuentran es el establecido en la segunda subrutina ("D:/EXPEDIENTES/ExpedientesExcel/"), siendo el de procedencia el indicado en la primera ("D:/EXPEDIENTES/ExpedientesOriginales/"). Ambas son direcciones ficticias y ambas deberán ser adaptadas a la realidad concreta de tu organización de los archivos. Cada documento queda identificado por su nombre (aquí utilizamos claves de identificación), coincidiendo éste con el que consta en el listado Calc que sirve de base de datos al conjunto del proceso y que es consultada sistemática y sucesivamente en el script inicial y principal (Sub acceso_lista) mediante el bucle For que enmarca el resto del procedimiento

for i = 1 To n

oCelda = oHoja.getCellRangeByName( "C" & i)

Archivo = oCelda.getString()

AbrirDocumento(Archivo)

Next

En la entrada que sigue explicaré el acceso al contenido de los documentos (ahora) Excel mediante Python y su librería OpenPyXL. Eso y alguna cosa más.

Expedientes. Análisis.

Análisis de datos (VIII)

Expedientes (a)

El análisis de ese grupo de directorios que llamamos repositorios para diferenciarlos de los expedientes SEO nos ha permitido comprobar que efectivamente podemos establecer esta diferenciación en base al número de documentos que contiene un directorio, pero ni este  del número ni es el único criterio a tener en cuenta ni esa división entre repositorios y expedientes se ajusta a la realidad: también podemos encontrar un tercer grupo de directorios que no se pueden considerar meros repositorios, pero tampoco cumplen criterios para ser considerados expedientes.

Si bien el número de documentos no permite diferenciar entre un mero repositorio de algo que es "algo más", sí parece permitir diferenciar un expediente SEO digitalizado de lo que no lo es. Puede que ese no ser aun expediente no implique ser necesariamente sólo repositorio, que quepa una tercera realidad más compleja y con mayores pretensiones o posibilidades; y puede que esa limitación numérica sirva para establecer ese límite entre llegar a ser y quedarse por el camino.

Tomando esto como explicación provisional, considero adecuado denominar a este tercer grupo expedientes fallidos (más que incompletos), y afirmo que lo que los diferencia de los repositorios es el tipo de documentos que contiene, y no el número. Lo escaso del número lleva a considerarlos fallidos, ya que no alcanzan un mínimo para funcionar como expedientes, pero el tipo de documentos que contienen indican que su existencia se debe a un intento deliberado de constituirlos como fuente de datos para la intervención con potencial de servir también al análisis y la evaluación de esta intervención.

Esto tiene otras repercusiones para la consideración de un directorio como expediente; algunas ya comentadas, pero otras no. Incluso es posible que sea necesario revisar las primeras.

Un expediente SEO necesita para serlo haber sido conscientemente creado con al menos el objetivo de servir para mejorar la calidad de la intervención en función de facilitar el conocimiento preciso del alumno y de la intervención desarrollada con él a lo largo del tiempo. Este objetivo implica ir más allá que el de favorecer la elaboración de un informe a partir de otro previo, o de permitir la acumulación de datos en un único documento para facilitar así la consulta de los mismo y la misma elaboración del documento (esto en el caso de que se trate de un informe de seguimiento).

Si trasladamos esto a término más concretos, podríamos decir que un expediente digitalizado debe contar con documentos que evidencien haber superado el mero aprovechamiento de lo que por defecto se hace mediante herramientas informáticas; esto es, ser documentos expresamente elaborados o transformados en/a formato digital en función de una consciencia de la utilidad y funcionalidad que estos soportes implican para su uso.

Pero también implica que el número de documentos presentes en el expediente debe ser el suficiente como para facilitar esa funcionalidad. Y aquí nos encontramos con dos cuestiones: 

• Por un lado está que ese número depende del tiempo transcurrido desde el inicio de la intervención, pero ya no puede ser un mínimo tan bajo como el que nos sirvió para identificar posibles repositorios. 
• Y por otro que cantidades inferiores a un límite, que necesariamente tienen que ser superiores al usado antes, puede dar lugar a errores en los intentos de análisis de aquellos directorios que identificamos como expedientes SEO digitalizados sin que quepa duda de que no se trata de intentos fallidos de tales.

Espero que lo que he tratado de explicar aquí haya quedado suficientemente claro, ya que lo que sigue (las entradas que siguen a ésta) estarán dedicadas al análisis de aquellos que he considerado expedientes SEO empleando en su selección criterios cuantitativos, con el objetivo de confirmar o no dos hipótesis y una condición:

• Que en la configuración de los expedientes SEO es necesario tener en cuenta la tipología documental (Doc vs pdf vs Hc).
• Que también es necesario que exista clara y suficiente evidencia de recogida sistemática de datos en formatos digitales, y especialmente en formatos que permitan la automatización de procesos o subprocesos. 
• Y que ello requiere un mínimo documental no inferior a los 5 documentos, aunque este número es sólo un punto de partida, compromiso entre la necesidad de no dejar los intentos iniciales fuera del análisis, pero no incluir otros directorios que, por su bajo número de documentos, podría ser considerados con motivos como expedientes fallidos.

Una vez que el resultado de estos análisis permita establecer con más seguridad el límite de aquellos que podremos considerar dentro de esta tercera categoría, es posible que los analice específicamente. Antes no.
  

Expedientes. Análisis.

Análisis de datos (VII)

Repositorios (d)

Como prometí en la [entrada anterior], ahora toca mostrar el script Python empleado en el análisis de la tipología de documentos que contienen los repositorios más característicos de esta categoría, los de documento único. Evidentemente también nos toca ahora analizar los resultados obtenidos con esa herramienta.

Veamos primero el script, que lo prometido es deuda:

import os

directorio = "D:/EXPEDIENTES_SEO"

contenido = os.listdir(directorio)

n_doc = 0

n_conten = 0

n_dir = 0

#Extensiones a identificar

exten_doc = 0

exten_pdf = 0

exten_xls = 0

exten_ods = 0

doc_texto = 0

#Recorrido del listado de archivos

for exped in contenido:

    dir_exped = directorio + "/" + exped

#Seleccionar directorios de un único elemento

    n_conten = len(os.listdir(dir_exped))

    if n_conten == 1:

         with os.scandir(dir_exped) as entradas:

            for entrada in entradas:

                if entrada.is_file():

                    nombre_sin_extension, extension = os.path.splitext(entrada)

                    print(f"Nombre original: {entrada}")

                    print(f"Nombre sin extensión: {nombre_sin_extension}")

                    print(f"Extensión: {extension}")

                    print('\n')

                    if extension == '.doc' or extension == '.docx' or extension == '.odt':

                        exten_doc = exten_doc + 1

                    elif extension == '.pdf':

                        exten_pdf = exten_pdf + 1

                    elif extension == '.xls' or extension == '.xlsx' or extension == '.ods':

                        exten_xls = exten_xls + 1

#Resultados

doc_texto = exten_doc + exten_pdf

print(f'\nRESUMEN DE LOS DATOS OBTENIDOS. Tipo de documento\n')

print("Número de documentos Procesador de texto " ,str(exten_doc))

print("Número de documentos de tipo PDF " ,str(exten_pdf))

print("Total documentos de texto: " , str(doc_texto))

print("Número de documentos Hoja de cálculo " ,str(exten_xls))

El objetivo de este script es identificar los archivos por su extensión para conocer el peso relativo de cada tipo de archivo en los directorios de documento único. Se trata de un script ya visto [en esta entrada], aunque con alguna diferencia. Cómo aquel se basa en el uso del módulo os del que utilizamos fundamentalmente la función os.listdir() y la función os.scandir() dentro de estructuras anidadas de bifurcación y de iteración, que son el núcleo del script.

En esto coincide este script y el que sirvió de fuente, aunque se diferencian en que en el actual es posible visualizar también el directorio original (print(f"Nombre original: {entrada}")) y el nombre del archivo (print(f"Nombre sin extensión: {nombre_sin_extension}")), además de la lista de extensiones (print(f"Extensión: {extension}")). Todo esto es posible gracias a la expresión (nombre_sin_extension, extension = os.path.splitext(entrada)).

Estos datos, que se ofrecen como listados, se complementan con los resultantes del cálculo, mediante conteo (vg. exten_doc = exten_doc + 1) y en el marco de un condicional (if extension == '.doc' or extension == '.docx' or extension == '.odt':) de una determinada categoría de archivo, definida por la extensión del documento.

Los listados permiten realizar un análisis más detallado de la naturaleza del documento, aplicando los criterios presentados en la [entrada anterior]. Al menos parcialmente podría haber planteado hacer esto mediante código, pero no lo he desarrollado hasta no disponer de los conocimientos necesarios para resolver los distintos problemas que se plantean. He preferido, como alternativa, ofrecer la lista de documentos como salida de monitor para que tú, si te interesa, puedas hacer ese tipo de análisis. Por mi parte me limitaré a realizar algunas comprobaciones.

Para que tú puedas realizar tu propio análisis es necesario, por supuesto, que dispongas de una colección de expedientes del mismo tipo de los que yo analizo aquí y que identifiques adecuadamente la ruta absoluta en la que se encuentran (los míos en directorio = "D:/EXPEDIENTES_SEO").

Pasemos ahora a exponer los datos cuantitativos del recuento: Tipología de los documentos de repositorios de documento único:

• Número de documentos Procesador de texto  91
• Número de documentos de tipo PDF  5
• Total documentos de texto:  96
• Número de documentos Hoja de cálculo  4

El número total de documentos, que resulta de sumar los anteriores, es 100; alguno más de los que recogía el análisis de frecuencias realizado sobre el primer cómputo de directorios (en ese caso eran 97), pero la diferencia es tan pequeña que podemos considerarla irrelevante.

Lo que no es es el total de documentos que pertenecen a la categoría 1: la que está formada por los documentos derivados directamente del uso de un procesador de texto, que suponen el 91% del total. frente a ellos, el resto (PDF y Hojas de datos) son absolutamente minoritarios (juntos suman el 9%). Si además sumamos los primeros con los PDF (en el supuesto que se explicó como causa principal en la [entrada anterior]), el sumatorio de documentos en encajan inicialmente en  la casuística repositorio suma un total del 96% de los directorios de documento único. Sólo 4%, las hojas de cálculo, podrían considerarse ajenas a ese criterio.

No obstante caben algunas matizaciones a lo anterior, las cuales resultan del análisis del listado de datos que nos ofrece el script:

• No todos los documentos de procesador de texto son informes o dictámenes. Aunque éstos son la mayoría (60), también tenemos documentos-procesador que son informes de intervenciones de PSC (informes SISE, 8) o de especialistas de apoyo (PT o AL) (14). Incluso otros se recogen documentos ACI-PTI (4), o de otro tipo (incluyendo de evaluación (6).
• Las hojas de cálculo se ajustan al criterio esperado (recogen procesos de evaluación, las 4)
• Los PDF, presentan un comportamiento mixto (el esperado), aunque con menos peso como concreción de informes (2/5) frente a documentos de más relacionados con la conformación del expediente (2) o con la evaluación (1).

De lo anterior se deduce que el peso de la evaluación es mayoritario (70%), pero no tanto como podría esperarse de los cómputos iniciales que lo situaba en el 96%).

Cobra importancia en el contenido de los directorios de documento único lo que podríamos llamar intentos fallidos de desarrollo de expedientes (o expedientes degradados o perdidos), que, si interpretamos como tales el sumatorio de documentos diversos, suponen el 38% del total. Podemos poner en duda que impliquen este proyecto (y no un simple guardar para después más simple) los informes SISE de PSC (8), pero no veo motivo para no hacerlo con el registro de informes de otros profesionales, los documentos ACI-PTI y, más aun los documentos de pruebas de evaluación. Todos ellos ascienden a un nada despreciable 30%.

Es posible que tampoco sea acertado considerar todos estos 30 documentos como intentos fallidos de formalizar conscientemente un expediente, pero tampoco podemos considerarlos meros repositorios de documentos disponibles en papel o que, como las pruebas de evaluación, guardarlas digitalizadas implica haber desarrollado previamente un soporte informático. 

En resumen, la realidad se muestra más compleja de lo supuesto al inicio del análisis, aunque, aun así, aquellas suposiciones se cumplen, con menor peso cuantitativo y mayor complejidad de lo previsto, pero se cumple. Hasta el momento.

Expedientes. Análisis.

Análisis de datos (VI)

Repositorios (c)

Si algún directorio representa lo que queremos decir con repositorio este es, sin duda, aquel que contiene un único documento. En esta entrada analizaré este subconjunto de repositorios con el objetivo de conocer con más detalle cuales son sus características.

Ya vimos en [entradas anteriores] dedicadas a este análisis de expedientes que el conjunto de directorios que contiene un único documento era el mayoritario (moda) y con mucho de todo el conjunto, llegando a representar algo más del 20% del total. Aunque no sean los únicos directorios que podemos considerar repositorios más que expedientes, sin duda que son los más representativo, por lo que analizarlo nos puede servir para comprender cuáles son las características distintivas de éstos frente a los directorios-expedientes.

Cómo ya comenté en la [primera entrada] en la que planteo el análisis de este subgrupo, este análisis requiere que nos centremos en el tipo de documentos que contienen los repositorios, ya que es esta variable, incluso más que la del número de documentos, la que define qué es un repositorio y en qué se diferencia de un expediente. Es evidente que el número de documentos importa por lo que delimita en teoría el campo de unos y de otros, pero no es tan evidente que sea sólo el número ni que lo sea siempre.

Podemos diferenciar la tipología de documentos en función de la extensión de los mismos, pero por lo que resulta de asociación entre ésta y el contenido del documento. 

En este sentido tenemos los documentos doc, docx y odt como representantes de todos aquellos que derivan del uso de un procesador de texto (Word o Writer). Estos servicios son los más usados por los SEO y lo son desde hace ya mucho tiempo. Con ellos se han elaborado la inmensa mayoría de los informes y dictámenes que, con mucho, son los documentos que cuantitativamente más y cronológicamente antes han formado parte de los directorios que llamaremos repositorios, pero también expedientes SEO. Estos documentos se guardan en su respectiva carpeta a la espera de ser impreso cuando resulte necesario, aunque posteriormente se observan (y usan) otras utilidades (las que con el tiempo favorecerán que un repositorio se convierta en expediente), como son la consulta y el uso para posteriores intervenciones.

En lo que se refiere a este análisis, se espera, por tanto, que este tipo de documento predomine en los repositorios. Evidentemente también en su prototipo: el repositorio de documento único.

El segundo tipo de documento es el PDF. En este caso su presencia se justifica como resultado de varios procesos posibles, de naturaleza diferenciada en relación con lo que hemos planteado como hipótesis básica:

• Bien como transformación de un documento del tipo anterior a PDF como forma de garantizar que se mantiene no modificable. En este caso, para el cómputo total podemos sumarlo a los del grupo anterior.
• Bien como resultado del escaneo de un documento originariamente en formato papel.

En el primer caso estaremos hablando de usos compatibles con el concepto de repositorio, aunque no exclusivamente; pero en el segundo la interpretación es más compleja, ya que apunta a una práctica que se acerca más a los objetivos coherentes con la creación de un expediente, pero no se ajusta a una condición básica de éste: contar con un número suficiente de documentos. Pero ¿cuántos son suficientes?, no está claro, pero evidentemente uno sólo no. ¿se trata entonces de un expediente fallido, o de un expediente perdido?. Puede que no tengamos una respuesta clara con sólo los datos disponibles, pero sí podemos asegurar que, salvo que aparezcan más documentos de ese mismo alumno, el que nos consta, aunque esté en formato PDF, no lo podemos considerar por sí sólo dentro de la categoría de expediente.

El tercer y último tipo de documento (podría haber otros, pero en la práctica no los hay) de los que forman parte de los repositorios de documento único es el que se presenta sobre una hoja de cálculo (xls, xlsx, ods), resultantes del uso de servicios como Excel o Calc. Estos, al contario que los PDF, generalmente representan potenciales anomalías, ya que no es frecuente, pero tampoco descartable, el uso de estos soportes para crear documentos compatibles con repositorios. Evidentemente nunca se tratará de informes psicopedagógicos, pero sí cabe la posibilidad de crear una ficha de datos del alumno desde planteamientos compatibles con un repositorio; al menos tanto como desde planteamientos de expediente. 

Con todo, es más fácil que se trata de una recopilación de datos resultantes del estudio del expediente académico o de la aplicación de una prueba de evaluación. En este caso, si bien no se puede prescindir del concepto de repositorio, es más plausible que se trate de desarrollar un expediente SEO, ya que se dan dos excepcionalidades desde el planteamiento del repositorio que son, en realidad, dos motivos frecuentes desde el planteamiento de la configuración de un expedientes: recopilar sistemáticamente datos que no son necesarios usando expedientes en papel y usar para ello una hoja de cálculo (en lugar de un procesador de texto).

Aclaradas estas cuestiones, en la entrada que sigue pasaré a realizar el análisis empírico de los directorios de documento único. Empezaré por exponer el script Python usado para obtener los datos y después mostraré y analizaré el resultado de su aplicación.