Sistema de estadísticas homogéneo (work in progress)

De Grupos de trabajo Recolecta

Para poder definir un sistema de estadísticas de uso homogéneo para los repositorios, proponemos abordarlo desde 3 cuestiones en las que nos tendríamos que poner de acuerdo:

• ¿Que contenidos medimos?
• ¿Que medimos exactamente (downloads, consultas...)?
• ¿Que tratamientos se realizan para que lo que se mida sea más preciso?

A priori, el primer y último punto parecen más sencillos, pero en el segundo pueden existir diferentes aproximaciones. Para que sirva de inicio en la discusión, en todos los puntos mostraremos cual es la aproximación que se ha escogido desde los repositorios cooperativos del CESCA/CBUC, y también como vemos que se trata desde los proyectos COUNTER y PIRUS.

Al final se muestra una tabla que relaciona los diferentes tratamientos de precisión con el software disponible para repositorios.

--Rdelavega 11:04 1 sep 2009 (UTC)

Contenido 1 Contenidos a medir 2 ¿Que se mide? 3 Mecanismos de depuración de los accesos 4 Tabla de soluciones software por mecanismo de depuración

Contenidos a medir

Los repositorios institucionales normalmente pueden tener contenidos mixtos como artículos de revistas, tesis, working papers, technical reports, capítulos de libros, presentaciones, datasets, imagenes, etc. Parece lógico, pues, que todos estos contenidos dispongan de estadísticas de uso. Sin embargo, esta no ha sido la aproximación escogida por el proyecto PIRUS, quienes sólo abarcan los artículos de revistas (journal article) que han estado aceptados para la publicación. A continuación se muestra un cuadro de las etapas de publicación y cuales cuentan para PIRUS:

Stages in the publication of an article

NISO/ALPSP Definitions	Versions definitions	PIRUS Protocol
Authors Original	Draft	Not counted
Submitted Manuscript Under Review	Submitted Version	Not counted
Accepted Manuscript	Accepted version	Counted
Proof		Counted
Version of Record	Published Version	Counted
Corrected Version of Record	Updated Version	Counted
Enhanced Version of Record	Updated Version	Counted

Otro punto a tener en cuenta es la "granuralidad" de los contenidos. Un PFC, por ejemplo, podría contener más de un documento PDF y un video. En este caso, es crucial disponer de un identificador de ítem, entendiendo como ítem al conjunto de contenidos del que está formado. Los principales software para repositorios disponen de estos identificadores. DSpace emplea handlers del CNRI's Handle System, Eprints asigna identificadores propios y Fedora los llama PID (Persistent Identifier).

Finalmente, si entendemos como ítem un contenido único identificable ¿que os parece proponer que las estadísticas homogéneas de uso abarquen a todos aquellos ítems contenidos dentro de los repositorios? sean del tipo que sean.

--Rdelavega 15:54 1 sep 2009 (UTC)

¿Que se mide?

En las estadísticas de uso existen dos indicadores básicos:

• Número de veces que se ha consultado la página del ítem (metadatos + enlace/s a la descarga de contenido/s).
• Número de veces que se ha descargado el contenido.

Sin embargo, es muy común usar el término consulta al referirnos a las estadísticas de uso. Pero, ¿que es una consulta?, ¿las descargas, la página del ítem o una combinación de ambas? ¿Estamos delante de un tercer indicador?

En CESCA/CBUC hemos definido una consulta como una combinación de los dos indicadores. Concretamente, una consulta es un acceso a un contenido hecho a través de su página de metadatos o a través de su descarga. Sin embargo, las descargas realizadas desde la propia página de metadatos no se contabilizan. De esta manera, se cuentan las consultas a la página de metadatos (acceso por el repositorio) y también las descargas (en su mayoria, directamente desde Google), pero aquellos que consultan la pagina a través del repositorio y después se descargan el contenido, solo se cuenta como una única consulta. Esta definición esta detallada en los repositorios en donde se ha aplicado: RECERCAT, RACO y RECYT.

En COUNTER, definen un item request como el "number of items requested by users as a result of a search. User requests include viewing, downloading, emailing and printing of items".

En PIRUS, tienen en cuenta un "succesfull full-text article download".

Motivos por los que es útil disponer de un indicador único de "consulta" (pros):

• Claridad, parece más fácil de cara a los usuarios disponer de un único indicador
• Posibilita la creación de rankings únicos dentro de los repositorios (por ejemplo, para fomentar el uso y la difusión del TDR entre los investigadores cada año se premia con un diploma acreditativo a las tesis más consultadas)

Existen otras casuísticas a tener en cuenta, por ejemplo:

• Si un ítem tiene un vídeo incrustado. En este caso el indicador de descargas no importaría, peró el número de visualizaciones seria interesante.
• ¿Como se miden las consultas en los agregadores, como Recolecta? Las descargas solo podrán ser medidas en los repositorios origen, pero puede ser interesante conocer cuantas consultas (a la página del ítem con metadatos) se han realizado a través de los diferentes agregadores.

Así pues, en este punto nos hayamos que existen diferentes propuestas para debatir y encontrar la definición de un indicador o indicadores para usar en las estadísticas homogéneas:

1. Usar un indicador único "consulta"
   1. Uso del indicador "consulta", definida por un acceso a la página de resumen de un ítem (metadatos), o como la descarga del contenido cuando ésta no es a través de su propia página de resumen.
   2. ¿Alguna otra definición?
2. Usar más de un indicador
   1. Uso de los indicadores de "número de descargas" y "número de consultas a la página del ítem".
   2. Usar, a parte de los dos anteriores, también otros como "número de impresiones", "número de visionados" (en un vídeo) o "número de recomendaciones por email".
   3. ¿Otros?

--Rdelavega 15:54 1 sep 2009 (UTC)

Mecanismos de depuración de los accesos

Las "consultas" interesantes de contabilizar son aquellas realizadas por los usuarios, sin embargo, existen muchos accesos en los logs realizados por máquinas, como robots para indexar información en los buscadores. Estos logs pueden ser depurados mediante unas técnicas que se listan a continuación. En ellas se detalla si son recomendaciones de COUNTER. Respecto a esto, el proyecto PIRUS sólo menciona que se tendrian que usar las técnicas de COUNTER. Comentar que los propios de COUNTER dicen que "because the way usage records are generated can differ across platforms, it is impractical to describe all the possible filters used to clean up the data".

• Accesos válidos. Según COUNTER, los códigos de retorno del protocolo HTTP 200 i 304 son los accesos válidos.
• Doble click, peticiones múltiples. Según COUNTER, se considera doble click a dos accesos idénticos (mismo item desde la misma IP) separados por menos de 10 segundos si se trata de un HTML y de 30 segundos en caso de descargar un PDF.
• Filtrado de robots. Se trata de un filtrado dinámico de todos aquellos robots que cumplen con las buenas practicas y consultan el fichero robots.txt.
• Filtrado de lista negra. Filtrado de robots "conocidos" y otros sistemas que producen accesos de manera automatizada. La lista de COUNTER es pequeña. Se podría elaborar entre todos una lista y mantenerla en algún lugar, como este wiki.
• Filtrado de búsquedas federadas. Se usan una variedad de técnicas para conducir una búsqueda federada, incluyendo Z39.50. En COUNTER tienen una lista
• Filtrado de IPs de gestión y mantenimiento.
• Filtrado de múltiples accesos desde una misma IP. Con este filtrado se ha de tener cuidado, pues no se pueden eliminar indiscriminadamente pues puede tratarse de un proxy o de una gran organización que sale a internet con una sola IP.

--Rdelavega 15:54 1 sep 2009 (UTC)

Tabla de soluciones software por mecanismo de depuración

Existen diferentes combinaciones de software de repositorios y estadísticas de uso. En la siguiente tabla se relacionan con los procesados de depuración mostrados en el apartado anterior.

Soluciones software por mecanismos de depuración

	Acceso válido	Doble click	Filtro robots.txt	Lista negra	Filtro búsquedas federadas	Filtro gestión	Múltiples accesos
DSpace + procesado CESCA (*1)	ok	en breve	ok	ok	en breve	ok	ok(*2)
OJS + procesado CESCA (*1)	ok	en breve	ok	ok	en breve	ok	ok(*2)
DSpace + procesado e-ciencia (*3)	ok	ok	en breve	ok	ok (*5)	en breve	en breve
e-prints + procesado e-ciencia (*4)	ok	ok	en breve	ok	ok (*5)	en breve	en breve
fez + fedora + procesado e-ciencia (*4)	ok	ok	en breve	ok	ok (*5)	en breve	en breve
...

(*1) Procesado de los logs de Apache y Tomcat -> base de datos -> Pintado estadísticas online.

(*2) Comprobaciones periódicas manuales. Si se detectan accesos fraudulentos desde una dirección IP, ésta pasa a la lista negra.

(*3) Procesado de los logs de Apache o Tomcat + DSpace -> Generación de ficheros csv

(*4) Procesado de los logs de Apache o Tomcat -> Generación de ficheros csv

(*5) Usamos la misma lista Negra para robots y búsquedas federadas.

--Rdelavega 15:54 1 sep 2009 (UTC)

-- Añadidas estadísticas e-ciencia Jcorrales 19 oct 2009 (UTC)