Lenguaje.

Fonología

Análisis (I). Desarrollo del sistema fonológico.

Vamos a estudiar el proceso que lleva a la adquisición del sistema fonológico partiendo de los datos evolutivos y los que aportan autores de pruebas de evaluación de este proceso, más concretamente del test Fonología de la batería PLON-R.

La adquisición del sistema fonológico forma parte del proceso de desarrollo del lenguaje, pero éste es mucho más amplio y complejo, por lo que es importante delimitar de qué vamos a tratar aquí. Y para ello nada mejor que concretarlo en una fuente de datos, concretamente en este sencillo esquema de adquisiciones evolutivas.

Se trata de un procedimiento evidentemente reduccionista y simplificador, pero adecuado al objetivo que me propongo, ya que no pretendo realizar un estudio en profundidad sobre un tema tan complejo como tratado convenientemente en la literatura especializada, a la que remito al lector.

Para mis objetivos es suficiente con la información que aquí tenemos resumida, en cierto modo podemos decir que insuficientemente expuesta, pero que sintetiza, creo yo, de forma suficientemente satisfactoria el desarrollo del proceso que ilustra. 

Podemos observar en esta tabla que el proceso se considera iniciado a la edad de 3:00 años y finalizado con 5:11 años. Sabemos que ambos límites no son ciertos, que realmente se inicia antes y que se prolonga en edades más tardía. Sobre esto último, la propia tabla da pistas suficientes; y sobre la edad de inicio podemos decir que siendo falsa sí recogen en esencia lo que pretende, ya que es a esa edad cuando el proceso alcanza niveles significativos de desarrollo.

También observamos en la tabla otra característica del proceso, y es que, una vez en marcha, se desarrolla con rapidez, siendo necesario establecer subdivisiones semestrales en este periodo de máxima expansión (de ahí las subdivisiones de la tabla). En su fase final, a partir de los 5:11 años de edad, volvemos a observar cierta ralentización (de hecho se considerar que puede finalizar entre lo 6 y los 7 años), pero también cierta marginalidad, la cual no refleja esta tabla pero sí queda en evidencia en los planeamiento de evaluación que se constatan en test como PLON-R Fonología (ver contenido fonológico de la edad 6 años).

Muy interesante también es la subdivisión horizontal de la tabla en niveles porcentuales de adquisición, los cuales debemos interpretar como porcentaje de niños y niñas que producen correctamente (según el modelo adulto) determinado fonema. Por ejemplo, el 80% de los niños/as producen correctamente el fonema /g/ en el intervalo de edad 3:00 años a 3:05 años.

A partir de ahí podemos concretar lo que la teoría plantea como niveles de plena adquisición (100%) en función de los bloques etarios y niveles inferiores, subdivididos en conjunto porcentuales de 10 en 10 (de 90% a 30%). Todo estos niveles los podemos asimilar, en términos generales, a índices de dificultad del ítem.

Estas subdivisiones de niveles de ejecución exitosa tienen mucho interés en si mismas, pero también como referente comparativo con estudios empíricos (como los que aporta PLON-R, por ejemplo). 

En primer lugar porque indica claramente niveles de 100% de éxito (IDI = 1), lo cual es coherente con el enfoque de éxito en un proceso evolutivo; pero también interesa el proceso evolutivo que refleja de incremento porcentual de este factor. Algunos (pocos, pero significativos) son expresados directamente en el gráfico (vg., el fonema /rr/), pero otros deben se deducidos del análisis; por ejemplo el fonema /g/, que se sitúa en niveles de producción exitosa del 80% en 3:00-3:05 años, permanece en este nivel hasta los 3:11 años, pero pasa al 90% de producción correcta en 4:00-4:05 años, posición en la que que mantiene hasta la edad 5:05-5:11 años, en la que alcanza el 100% de ejecución exitosa, concluyendo así su proceso de adquisición.

Este marco evolutivo permiten entender, aun sin expresarlo, que existe margen para la constatación de retraso fonológico, pero también para la identificación del trastorno fonológico, aunque este último sólo en potencia y únicamente como indicio. Serán necesarios otros datos para confirmar esa posibilidad, ya que aquí no disponemos de información suficientemente discriminativa, como puede ser, por ejemplo, la identificación de diferencias de rendimiento en función de la posición del fonema en la cadena fónica. Parece evidente que no se puede interpretar del mismo modo un error en función de una determinada posición del fonema que ese mismo error extensible a todas las opciones del fonema. Y más aun si hablamos de estructuras fonológicas más amplias, como las que se observan en función del punto o del modo de articulación.

 

Lenguaje

Fonología

Análisis (II). PLON-R. Fonología. 3 años.

Los autores de PLON-R presentan en la documentación del test datos de interés para conocer el comportamiento de cada fonema (en función de su posición, inicial, medial o final) o grupo fonémico (vocálico o consonántico) que no son necesariamente coincidentes con los vistos en la documentación con la que trabajamos en la entrada anterior. Me refiero a datos de IDi.

Algo sabemos [de este índice] y de su interés para el análisis de datos y de los resultados de un test, y algo tenemos [pendiente de comprobar], precisamente es esta nuestra actual entrada. Empezaremos por mostrar (y trabajar) con los datos correspondientes a los fonemas propios de la edad 4 años.

El manual PLON-R recoge estudios de la versión original (PLON) y de la segunda versión (PLON-R), y es tan interesante observar los valores IDi como comparar unos con otros, pero en el caso 3 años no disponemos de esa versión original porque PLON se inicia en 4 años. Presento la tabla IDi de PLON-R 3 años:

Se pueden comparar estos valores IDi con los porcentajes de correcta producción (adquisición) vistos en la [entrada anterior] y advertir que existe un buen nivel de acuerdo en ambos cuantificadores (una correlación con datos finales del intervalo etario de 0,835 si eliminamos grupos fonémicos y elegimos la posición fonémica que mayor similitud IDi-% presenta). Esto indica que los IDi de PLON-R son representativos del nivel de logro esperable según las investigaciones evolutivas, aunque reflejan una realidad empírica más susceptible variaciones y diferencias que la que muestran aquellas, algo que, por otra parte, es de esperar.   

También disponemos de datos sobre Media y Dt de Fonología 3 años, así como del número de sujetos de la muestra de esta edad. Concretamente son 216 niños y niñas de 3 años, los cuales obtienen una media de 0,516 y una Dt de 0,500 en Fonología. Teniendo en cuenta la forma de puntuar la prueba (1 pto. todo correcto, 0 ptos de no cumplirse la condición anterior), lo que nos dicen estos datos nos sirve de poco, aunque muestra que tan sólo el 51% de los niños de la muestra cumplen el criterio de puntuación, lo que implica que el 49% no alcanza niveles considerados adecuados de rendimiento en términos de adquisición del sistema fonológico.

Personalmente opino que esto demuestra una de estas dos cosas, o las dos a la vez): que la muestra de alumnos presenta un elevado número de niños con cierto grado de retraso fonológico y/o que el sistema de puntuación no permite captar la realidad de lo que pretende puntuar. Me inclino más por la segunda posibilidad, aunque es posible que exista cierto sesgo negativo en la muestra, dada la función profesional de los autores de la prueba (SEO) y de su posible red de contactos; pero aun con todo, me parece que es erróneo el planteamiento de puntuación de la prueba de fonología como tal, aunque puede ser válido en el marco de la aplicación completa de la batería y del análisis del desarrollo del lenguaje en conjunto, no sabría decir. 

En todo caso creo que exigir el perfecto cumplimiento del criterio IDi = 1 implícito en el procedimiento de puntuación y que parece coherente con lo que indican las investigaciones ya comentadas, implica no tener en cuenta la realidad empírica que muestran los propios valores IDi, puesto que sólo un ítem cumple estrictamente esa igualdad (IDi /m-/ - % /m/), pero se fuerzo innecesariamente a valoración negativa lo que en realidad se puede considerar un más que adecuado nivel de acuerdo entre análisis, vg. en los fonemas /b/, /n/, /t/, en los que el IDi está muy próximo al nivel esperado (100%).

Dada esta limitación del sistema de puntuación y la categorización negativa que de él se deriva de aplicar literalmente el procedimiento estándar, se hace aun más interesante extraer toda la información posible de los datos que aportan los autores de PLON-R; en primer lugar los que nos aporta el IDi:

En primer lugar observamos que la inmensa mayoría de los fonemas y grupos fonémicos considerados dentro del rango de edad no satisfacen el criterio de 100% de logro, que equivale a un IDi = 1 (como vimos, en sentido estricto sólo lo cumple el fonema /m/ en posición inicial). Aunque existe, de hecho, un alto nivel de acuerdo, según ya expliqué, los datos empíricos muestran menor nivel de ajuste a la norma fono-articulatoria de lo esperado, ligeramente inferior y con mayor grado de variabilidad en función de la posición del fonema. Estas "deficiencia" y variabilidad deben ser entendidas como parte del proceso de adquisición del sistema fonológico, siendo lo "normal", y no como manifestación de "deficiencia", como resulta del criterio y sistema de puntuación normativo del test.

Si ordenamos los IDI en orden ascendente y calculamos el valor promedio del IDI (0,93) y su Dt (0,065) y obtenemos información sobre qué fonemas o grupos fonémicos se sitúan dentro de un rendimiento medio o inferior/superior. Esto nos permite apreciar mejor el significado diferencial de los posibles errores individuales, ya que indican que no es lo mismo que un niño de tres años "fracase" al pronunciar la palabra /moska/ o /espada/ que si lo hace al pronunciar /agua/ o /kama/. En el primer caso podemos considerarlo dentro de la "normalidad" (es muy frecuente el "error" en la pronunciación /moska/, concretamente se observa en el 24% de los niños de la muestra), pero si pronuncia mal /kama/ podría considerarse un indicador de alertas ante lo que podría ser, en este momento, un posible indicio de retraso fonológico.

Además, gracias al IDi, conociendo el número de sujetos de la muestra, podemos calcular el número de sujetos de aciertan o fallan cada uno de los fonemas, lo que nos permiten apreciar mejor lo que antes vimos desde la perspectiva de ese mismo indicador: que determinados fonemas presentan dificultad para un porcentaje significativo de niños de la muestra. Yo situaría dentro de este grupo, aunque con diferencias de énfasis, todos aquellos fonemas que alcanza niveles de error iguales o superiores al 10%. Este referente es válido teniendo en cuenta que hablamos de un fenómeno evolutivo y del momento en el que, supuestamente, dicho fenómeno alcanza su cénit. Además es coincidente con el referente de rendimiento porcentual que en la tabla de rendimiento se sitúa en el 100%, que es en gran medida coincidente con nivel IDi empíricos superiores al 95%.

Finalmente, gracias al IDI podemos obtener el valor de una media que no nos ofrecen los autores de la prueba en los términos en que nos interesa, que es el estadístico que deriva del sumatorio de aciertos del conjunto muestral. En nuestro caso, este estadístico lo obtenemos del siguiente modo:

• Sumatorio de la columna Aciertos (4216,32)
• Dividido entre el número total de sujetos (216)
• Resulta un promedio de 19,52

Dado que los valores decimales son consecuencia del artificio matemático, redondeando obtenemos que la media real de aciertos es de 20, o si se prefiere se sitúa entre los 19 y los 20 fonemas/grupos fonémicos producidos correctamente. Dado que no disponemos de dato respecto a la Dt este valor sólo nos permite una aproximación de cara a valorar el resultado individual del un niño, pero nos permite un segundo modo de valorar su rendimiento, mucho más preciso que si tomamos como referencia el sistema de puntuación de la batería. De hecho, y redundado en lo dicho, este promedio general indica dos cosas:

• Que no es de esperar que el alumnado de 3 años alcance plenamente el criterio de desarrollo fonológico esperado para su edad (de media se queda a uno o dos puntos (ítem) de conseguirlo), pero se sitúa muy cerca de ello. 
• Y que ciertamente se confirma el carácter evolutivo del proceso que se evalúa, dado que el valor promedio indica una alta posibilidad de distribución sesgada a la derecha, que es la que cabe esperar cuando un fenómeno de esta naturaleza se encuentra en su fase final. Y en este caso lo estamos en lo que al nivel de desarrollo fonológico propio de los tres años de edad se refiere.

Aunque este análisis no agota el necesario para valorar la prueba PLON-R Fonología, si nos acerca al modelo y a su posible formalización. Seguiremos profundizando en ello.

Evaluación

Automatización de la evaluación

Procedimiento básico de análisis

Refiriéndome exclusivamente al análisis de los datos de la aplicación de una prueba a un alumno, el sentido más limitado pero también el más frecuente del concepto, quiero referirme ahora a una forma simple pero efectiva de proceder haciendo únicamente uso de funciones Calc.

Sobra decir que esta forma ha sido empleada, no muy frecuentemente, eso es cierto, en los soportes Calc (Excel) primeros, siendo sustituida posteriormente por funciones Filemaker y otras basadas en OOo Basic (o VBA).

Para ejemplificar este modo de proceder tomaré como ejemplo un soporte explicado recientemente: [la escala TDAH].

En este soporte se incluye una hoja en la que se recogen datos de baremos (aquí en Pc), que son usados mediante la fórmula BUSCARV() desde la celda en la que se plantea la automatización de la puntuación normativa. Ambos recursos son necesarios, ya que sin la base de datos no es posible acceder al valor de referencia y sin la función éste únicamente está disponible para ser visualizado por el profesional. 

Y esta es precisamente la alternativa a la que con más frecuencia se recurre (en ese momento y también ahora) dada la complejidad de la documentación estadística de la mayoría de las pruebas normativas (referidas a norma). Es más, la actual tendencia a "sugerir" la corrección on-line no sólo hace más atractivo ese procedimiento, lo hace obligatorio al no aportar algunas editoriales la documentación necesaria para que sea el profesional el que consulte las tablas y realice los cálculos. Pero en otro caso, cuando el volumen de información estadística a manejar es asumible o la podemos reducimos a niveles que entran dentro de esta categoría, están a nuestra disposición estrategias de automatización de esta fase del trabajo con los test, algunas de ellas, como estamos viendo, muy simples y plenamente accesibles. Veamos este caso con un poco mas de detalle.

En la hoja Cuestionario, además de éste (planteamiento de la pregunta y calificación numérica de la respuesta según código establecido), disponemos una tabla de conteo y calificación:

En la primera de sus filas incluimos la función de sumatorio (SUMA(C3;C7;C5;C15;C19)) asociado a los ítem del cuestionario implicados en la categoría (en este caso la PD de H)

En la segunda fila incluimos la función de búsqueda (BUSCARV(D26;$Baremos.$A$4:$F$65;2)) que relaciona el valor de la celda anterior con la tabla de Pc de la hoja Baremos, concretamente con su columna B (2) que es la que contiene los datos de H. Esta función busca el valor de la celda primera en la columna A (PD) y lo relaciona con el valor Pc correspondiente de la columna 2.

En la tercera fila (Riesgo) introduzco un procedimiento de valoración del Pc obtenido mediante condicionales (=SI(D27>94;"RE";SI(D27>85;"RM";"SR")))

Repito este procedimiento, aunque con fines de codificación en al fila inferior de esta tabla (=SI(D28=E28;1;0)), resultado que será de interés para la elaboración del informe de la prueba.

Resumiendo, he expuesto un procedimiento simplificado de puntuar según norma (Pc) y valorar cualitativamente según referencia de nivel de referencia empleando únicamente funciones Calc. Este procedimiento se puede considerar una forma simple de automatizar el análisis de los datos resultantes de la aplicación de una prueba.

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.