a manual

FUNDACIÓN ESPAÑOLA PARA LA CIENCIA Y LA TECNOLOGÍA
Funcionamiento de un Sistema de Recolección de Estadísticas
Documento de requisitos para la integración con Recolecta Estadísticas
Funcionamiento de un Sistema de
Recolección de Estadísticas
Documento de requisitos para la
integración con Recolecta
Estadísticas
Índice de contenido
INTRODUCCIÓN ........................................................................................................ 4
REQUISITOS TÉCNICOS PARA LOS REPOSITORIOS ............................................ 5
DIRECTRICES ............................................................................................................ 6
HERRAMIENTAS ...................................................................................................... 12
REFERENCIAS ......................................................................................................... 13
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
2/12
Funcionamiento de un Sistema de
Recolección de Estadísticas
Documento de requisitos para la
integración con Recolecta
Estadísticas
I.
INTRODUCCIÓN
FECYT está trabajando para dotar a RECOLECTA de un sistema de extracción de estadísticas de
uso de los repositorios. La necesidad de disponer de este sistema que mida las visitas y descargas
de los artículos científicos depositados en abierto se recoge en la Ley 14/2011, de 1 de junio, de la
Ciencia, la Tecnología y la Innovación, que en su artículo 37 regula el depósito de la producción
científica financiada con fondos públicos en repositorios de acceso abierto y establece que estas
versiones podrán ser empleadas en los procesos de evaluación.
El disponer de un software robusto, que facilite a las agencias de evaluación valorar la producción
científica con las estadísticas, es el fin último de la implementación de este sistema.
FECYT dispone de una herramienta de validación para comprobar que cada repositorio ofrece los
datos estadísticos conforme a las reglas establecidas.
FECYT adquiere la responsabilidad de validar y recolectar los datos estadísticos mientras que cada
repositorio se hace responsable de ofrecer sus propios datos estadísticos conforme a las directrices
establecidas.
Debido a que actualmente no existe ningún repositorio que cumpla las directrices, FECYT quiere
lanzar una prueba de concepto con 5 repositorios para confirmar que el sistema de recolección de
estadísticas propuesto puede ser llevado a la práctica con todos los repositorios nacionales.
Excepcionalmente y durante esta prueba de concepto FECYT prestará soporte a los 5 repositorios
participantes. Posteriormente este soporte se limitará a la responsabilidad de FECYT de validación y
recolección.
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
3/12
Funcionamiento de un Sistema de
Recolección de Estadísticas
Documento de requisitos para la
integración con Recolecta
Estadísticas
II. REQUISITOS TÉCNICOS PARA LOS REPOSITORIOS
La recolección de estadísticas de acceso producidas en cada una de los repositorios que participan
en el sistema Recolecta Estadísticas, se realiza desde el servidor central de recolección
perteneciente a FECYT, basándose en la recolección de metadatos OpenURL Context Objects
(CTXO) a través del protocolo OAI-PMH (en su versión 2.0), mediante una URL de recolección que
facilitará el repositorio de la institución (puede ser distinta a la utilizada para recolección de
metadatos en Dublin Core).
Es decir, si se realiza la petición:
?verb=ListMetadataFormats
a la URL de recolección de estadísticas, que debe facilitar todo repositorio que desee ser recolectado,
la respuesta debe contener la siguiente información:
<metadataFormat>
<metadataPrefix>ctxo</metadataPrefix>
<schema>http://www.openurl.info/registry/docs/xsd/info:ofi/fmt:xml:xsd:ctx</schema>
<metadataNamespace>info:ofi/fmt:xml:xsd:ctx</metadataNamespace>
</metadataFormat>
Donde el valor del campo:
metadataPrefix, corresponde al prefijo que identifica los metadatos OpenURL Context Objects.
schema, corresponde al esquema oficial utilizado para los metadatos OpenURL Context Objects.
metadataNamespace, corresponde al namespace utilizado para los metadatos OpenURL Context
Objects.
Las respuestas a las peticiones que se hagan a través de la URL de recolección deberán ser
ficheros con formato estructurado (formato XML) con las siguientes consideraciones:
•
Es obligatorio el uso de la codificación UTF-8 con los caracteres en Unicode. Esta
recomendación debe estar muy presente en los administradores puesto que un carácter que no se
encuentre en UTF-8 provocaría, por el propio formato de los datos, un error en la sintaxis de la
respuesta siendo imposible procesar el contenido.
•
Es recomendable utilizar una URL para el servicio de estadísticas por OAI-PMH del
repositorio que no sea susceptible de ser modificada, es decir, que sea independiente del lugar donde
se encuentre desplegado (utilizar una URL genérica, sin incluir información de puertos, por ejemplo:
http://digitum.um.es/oai/request) que pueda ser utilizada aunque cambie el servicio de ubicación.
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
4/12
Funcionamiento de un Sistema de
Recolección de Estadísticas
Documento de requisitos para la
integración con Recolecta
Estadísticas
III. DIRECTRICES
Para asegurar una calidad mínima de los datos de estadísticas de acceso que permita una
comparación fiable entre los datos de distintas instituciones, se han creado unas directrices
internacionales que intentan reglar los metadatos que deben contener obligatoriamente dichas
estadísticas, así como el valor de los mismos. Estas directrices se conocen como directrices
Knowledge Exchange (en adelante KE). A continuación se detallan todos los metadatos indicados
por KE (la descripción original de los metadatos se puede encontrar en el apartado 3 Data format de
la guía de uso de KE, véase KEGUIDELINES en el apartado referencias):
Parámetro
context-object
Uso
Descripción
timestamp
Obligatorio Fecha y hora en que la petición tuvo lugar en formato ISO8601.
Por ejemplo: 2009-07-29T08:15:46 +01:00
identifier
Opcional
identifier
Obligatorio Identificador URI de la publicación. Tras el URI de una
publicación puede estar tanto la URL del archivo físico (Full Text)
como la URL de los metadatos que se solicitaron. Por ejemplo:
https://openaccess.leidenuniv.nl/bitstream/1887/12100/1/Thesis.p
df
Opcionalmente si aplica, se puede incluir un identificador DOI
adicional. Por ejemplo: http://hdl.handle.net/10272/6
referringEntity identifier
Obligatorio La dirección URL que redirigió al usuario hasta la petición actual.
si aplica
Por ejemplo: http://www.google.es/...
requester
identifier
Opcional
Dirección IP cifrada desde donde se realizó la petición.
spatial
Opcional
Código en formato ISO 3166-1-alpha-2 del país desde el que se
originó la solicitud. Por ejemplo: ES
hashed-c
Opcional
Máscara de subred desde donde se realizó la petición. Al
encontrarse la IP cifrada, la máscara de subred puede ser usada
para obtener el país origen.
hashedsession
Opcional
Cifrado de la sesión de usuario que realizó la petición.
Es optativo pero recomendable para el filtrado de multiclics.
classification
Opcional
Clasificación del usuario (internal, administrative, institutional), en
caso de ser posible.
user-agent
Opcional
Cadena completa del agente HTTP utilizado.
service-type
dcterms:type
Obligatorio Provee información sobre el tipo de petición realizada por el
usuario, descarga de fichero o lectura de metadatos.
resolver
identifier
Obligatorio URL base del repositorio que contiene el ítem que ha sido
accedido.
referrer
Identifier
Opcional
referent
No existe un formato dado para el identificador (Usage Event ID),
pero de usarse debe ser opaco y único.
En los Países Bajos por ejemplo se utiliza un hash MD5 que se
genera a partir de una concatenación del código de la institución,
el identificador de la publicación y la fecha y hora.
La identificación del servicio exterior que haya proporcionado la
reseña al elemento, por ejemplo, un motor de búsqueda.
Debe estar incluido en la lista
http://infouri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=re
g&identifier=info:sid/
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
5/12
Funcionamiento de un Sistema de Recolección de Estadísticas
Documento de requisitos para la integración con Recolecta
Estadísticas
A partir de las anteriores, y teniendo en cuenta los indicadores que ha definido el Grupo de Trabajo de Estadísticas de REBIUN, se construyen las
recomendaciones Recolecta para la recolección de estadísticas. Estas recomendaciones deben ser seguidas en su totalidad, para conseguir pasar la
validación que realizará FECYT antes de proceder a la recolección de los datos de estadísticas de acceso.
Recomendaciones sobre el protocolo OAI-PMH
Regla
Tipo
Descripción
Descripción del error
Comentarios
OAI-PMH válida
Obligatorio
El formato del XML debe ser válido El formato del protocolo OAI-PMH Sin el formato correcto, los recolectores no pueden
conforme a su XSD.
no es válido conforme a su XSD.
extraer el contenido de los registros incluidos en la
petición.
Formato de metadatos
Obligatorio
Debe soportar el metadataPrefix CTXO.
Uso de sets
Opcional
El
protocolo
puede
soportar No está soportado el uso de sets en Pueden utilizarse los conjuntos para
opcionalmente la inclusión de sets para su repositorio.
recolección selectiva de los registros.
filtrar los resultados.
Política de borrado
Obligatorio
La política de eliminación del repositorio El formato de eliminar estadísticas Otra política de eliminación no está permitida.
sólo puede ser “transient” o “no”.
con el modo persistente no está
permitido.
El formato de metadatos con prefijo El formato con prefijo CTXO es el utilizado para la
CTXO no es soportado.
recolección de estadísticas de acceso.
realizar
la
Inclusión de context- Obligatorio
objects
Los objetos estadísticos deben estar Los metadatos de estadísticas no En correspondencia con la definición de CTXO como
incluidos dentro de los metadatos en un están englobados en un objeto formato de datos para el intercambio de las estadísticas a
objeto global <context-objects>
<context-objects>
través del protocolo OAI-PMH. La incorporación se debe
hacer conforme a su XSD, englobando en un objecto
<context-objects> que contenga todas las estadísticas de
acceso para el registro.
ListMetadataFormats
debe contener CTXO
El protocolo OAI-PMH debe publicar en No se encuentra el formato de El formato de metadatos de CTXO debe aparecer entre
su listado de metadatos aceptados el de metadatos CTXO.
los disponibles en la petición verb=ListMetadataFormats
CTXO.
incluyendo el XSD y el namespace correspondientes.
Véase el apartado 2.REQUISITOS TÉCNICOS PARA
Obligatorio
LOS REPOSITORIOS
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
6/12
Funcionamiento de un Sistema de Recolección de Estadísticas
Documento de requisitos para la integración con Recolecta
Estadísticas
Recomendaciones sobre los metadatos OpenUrl Context Object
Regla
Tipo
Descripción
Descripción del error
Comentarios
Timestamp del context- Obligatorio
object obligatorio
El atributo timestamp es obligatorio y El campo timestamp no se
debe seguir el formato ISO 6801.
encuentra definido o se encuentra
definido conforme a un formato que
no es el aceptado.
La ausencia o formato defectuoso del atributo timestamp
impide detectar en el momento en el que se produjo la
petición, imposibilitando detectar si se trata de una
petición válida o no.
Identifier
del
object opcional
Es
recomendable
incluir
un El atributo identifier de la etiqueta
identificador único de context-object context-object no se encuentra
basado en una concatenación del definido.
código de la institución, el identificador
de la publicación y la fecha y hora.
El atributo identifier del campo context-object permite
identificar repeticiones erróneas por fallo del software de
captura de estadísticas.
context- Opcional
Este atributo ayuda en la detección de duplicados,
aunque si no aparece se puede detectar mediante la
fecha de acceso y la ip/sesión del usuario.
referent:identifier
obligatorio
Obligatorio
El atributo referent:identifier es El campo referent:identifier no se La ausencia del campo referent:identifier no permite
obligatorio, único y debe coincidir con encuentra definido o aparece conocer el objeto digital al que se encuentra asociada la
el URI único del documento en el repetido.
petición.
repositorio.
Asimismo, este identificador debe coincidir con el URI
único que tiene definido el ítem en el protocolo OAI-PMH
para permitir el enriquecimiento de metadatos y la
posterior explotación de los datos.
referringEntity:identifier
opcional
Obligatorio
si aplica
Es recomendable incluir el campo No se encuentra definido el campo El atributo referringEntity permite identificar el lugar a
referringEntity indicando la URL a referringEntity.
través del cual el usuario ha accedido al recurso (portal
través de la cual se accedió al objeto
de acceso, buscadores, etc.). Permite obtener
digital o a sus metadatos.
estadísticas de acceso de usuario a través de buscadores
a los que se encuentra conectado el repositorio.
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
7/12
Funcionamiento de un Sistema de Recolección de Estadísticas
Documento de requisitos para la integración con Recolecta
Estadísticas
Uso de las extensiones de Obligatorio
DINI
El atributo ctx:requester/ctx:metadataby-val/ctx:format debe contener el
valor de las extensiones DINI
(“http://dini.de/namespace/oasrequesterinfo”)
El formato de los metadatos CTXO
no incluye las extensiones DINI
para incluir información adicional a
las peticiones.
La inclusión de las extensiones de DINI, contempladas en
la normativa de KE (Knowledge Exchange) permite incluir
información adicional necesaria para el correcto filtrado
de las peticiones.
Para definir estas extensiones, debe incluir el campo
ctx:requester/ctx:metadata-by-val/ctx:format con el valor
(“http://dini.de/namespace/oas-requesterinfo”).
requester:identifier
Obligatorio
obligatorio y debe ser un
hash.
El atributo requester:identifier deberá
ser obligatorio, único y deberá
encontrarse cifrado mediante un
algoritmo de hash (MD5, SHA-1, etc.)
con el formato data:,hash(32 bits).
Durante el cálculo del hash se debe
usar un salteado de al menos 12
caracteres.
El campo requester:identifier no se
encuentra
definido,
aparece
múltiples veces o no se encuentra
conforme al formato establecido.
¿Por qué debe ser obligatorio y no opcional como
indica KE?
La ausencia del campo requester:identifier no permitiría
identificar al usuario que realizó la petición,
imposibilitando el posterior filtrado de multiclics que se
pretende llevar a cabo.
Asimismo, debido a las leyes existentes sobre la
protección de datos, la ip del usuario no puede ser
enviada en texto plano o cifrada en un algoritmo simétrico
que permita ser recuperada. Se recomienda el uso de
funciones de hash (MD5, SHA1, etc).
requester:spatial opcional Opcional
Es recomendable incluir el elemento El atributo spatial del requester no El atributo spatial permite identificar el país de origen de
spatial indicando el código del país de se encuentra definido o no está la petición para obtener estadísticas de acceso por
origen de la petición en formato ISO conforme al vocabulario.
países.
3166-1-alpha-2.
requester:hashed-c
opcional
Es recomendable incluir la máscara No se encuentra definido el campo La máscara de subred desde donde se realizó la petición.
de subred, formado por la IP a la que hashed-c.
Al encontrarse la IP cifrada, la máscara de subred puede
se le ha cambiado el último dígito por
ser usada para obtener el país origen.
un .0
Opcional
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
8/12
Funcionamiento de un Sistema de Recolección de Estadísticas
Documento de requisitos para la integración con Recolecta
Estadísticas
dini:hashed-session
obligatorio y único
Obligatorio
si aplica
ctx:contextEl campo hashed-session no se ¿Por qué debe ser obligatorio y no opcional como
indica KE?
object/ctx:requester/ctx:metadata/dini: encuentra definido.
requesterinfo/dini:hashed-session es
La ausencia del campo requester:hashed-session no
obligatorio siempre que sea aplicable
permite identificar al usuario que realizó la petición,
y debe contener la sesión del usuario
imposibilitando el posterior filtrado de multiclics que se
que ha realizado la petición cifrada
pretende llevar a cabo.
mediante un algoritmo de hash.
Es obligatorio si es aplicable porque si se trata de la
primera petición de un usuario, ésta no incluirá dicha
información.
Asimismo, debido a la protección de datos, la sesión del
usuario no puede ser enviada en texto plano o cifrada en
un algoritmo simétrico que permita ser recuperada. Se
recomienda el uso de funciones de hash (MD5, SHA1,
etc).
requester:classification
Opcional
opcional pero conforme a
vocabulario
Es
recomendable
incluir
clasificación del usuario.
dini:user-agent obligatorio Obligatorio
y único
El
atributo
ctx:context- El campo user-agent
object/ctx:requester/ctx:metadata/dini: encuentra definido.
requesterinfo/dini:classification/dini:us
er-agent es obligatorio y debe
contener la cadena de identificación
del agente HTTP utilizado para la
petición.
la No se encuentra definido el campo Se permiten 3 valores:
classification o no se encuentra * internal: accesos de herramientas internas (testeadores
conforme al vocabulario.
de servicio, etc.).
* administrative: accesos por administradores o personal
técnico por motivos de mantenimiento (testing, etc.).
* institutional: accesos al servicio desde la institución
donde reside el repositorio en labores de administración.
no
se ¿Por qué debe ser obligatorio y no opcional como
indica KE?
El campo user-agent identifica al agente web que realizó
las peticiones al repositorio. La no inclusión de este
metadato impide identificar si la petición ha sido realizada
por un usuario o por un robot web.
El recolector de estadísticas realiza, además del filtro de
multiclics, el filtro de peticiones procedentes de robots
webs.
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
9/12
Funcionamiento de un Sistema de Recolección de Estadísticas
Documento de requisitos para la integración con Recolecta
Estadísticas
dcterms:format
Obligatorio
obligatorio, único y debe
encontrarse conforme al
vocabulario definido
El
atributo
ctx:service- El campo dcterms:format no se
type/ctx:metadata-byencuentra definido o el valor no está
val/ctx:metadata/dcterms:format
es conforme al vocabulario.
obligatorio y debe contener el valor
conforme al vocabulario.
resolver:identifier
obligatorio y único
El atributo ctx:resolver/ctx:identifier es El campo identifier del resolver no El campo identifier identifica el repositorio responsable
obligatorio.
se encuentra definido.
donde se encuentra el objeto digital. Este campo es
necesario para definir las estadísticas de acceso por
repositorio.
Obligatorio
referrer:identifier opcional Opcional
El campo dcterms:format identifica de forma taxativa si el
acceso se ha realizado a los metadatos o al objeto digital
a texto completo. Distinguir el tipo de acceso utilizado es
importante a la hora de realizar las estadísticas.
Es recomendable incluir el campo No se encuentra definido el campo El atributo referrer permite identificar el lugar a través del
referrer identificando el servicio referrer.
cual el usuario ha accedido al recurso (portal de acceso,
exterior que haya proporcionado la
buscadores, etc.). Permite obtener estadísticas de acceso
reseña al elemento.
de usuario a través de buscadores a los que se encuentra
conectado el repositorio.
Debe estar indicado conforme al
vocabulario info:sid
Cualquier repositorio que cumpla este estándar podrá ser recolectado por el servidor central de FECYT, siendo ellos mismos los encargados de publicar, bajo estas
especificaciones, los datos referentes a los eventos de uso que se recogen en su entorno, desarrollando su propio proveedor de estadísticas.
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
10/12
Funcionamiento de un Sistema de
Recolección de Estadísticas
Documento de requisitos para la
integración con Recolecta
Estadísticas
IV. HERRAMIENTAS
Existe un conjunto de herramientas ya implementadas por los integrantes de Knowledge Exchange
que sirven de punto de partida reduciendo significativamente los costes de implantación.
Estas herramientas están encaminadas a cumplir KE por lo que para cumplir con las
recomendaciones Recolecta, será necesaria su adaptación.
Entre las soluciones posibles destacan por su integración con los gestores de repositorios más
comunes.
SURE Data Provider
•
Desarrollador: SURFfoundation
•
Software: http://code.google.com/p/surfshare-sure/
•
Gestores de repositorios compatibles: DSpace, ePrints y Fedora.
OAS Data Provider
•
Desarrollador: DINI
•
Software: http://sourceforge.net/projects/openaccessstati
•
Gestores de repositorios compatibles: DSpace y WebDoc.
FECYT - OAS Data Provider
•
Desarrollador: FECYT (basado en el OAS Data Provider)
•
Software: https://svn.fecyt.es/svn/Recolecta/stats/oas/branches/recolecta
•
Gestores de repositorios compatibles: DSpace.
•
Observaciones: FECYT dispone de un cliente de validación para DSpace que ya cumple con
las recomendaciones Recolecta sobre las KE.
Todas estas herramientas funcionan de forma similar, se configuran contra el servidor Apache a
través del cual está publicado el gestor de repositorios y parsean los logs que se van generando
durante el funcionamiento de los mismos, de esta forma extraen la información referente a los
eventos de acceso.
El parseo de los logs se realiza mediante expresiones regulares que identifican los registros que
corresponden a eventos de acceso, de los que no lo son.
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
11/12
Funcionamiento de un Sistema de
Recolección de Estadísticas
Documento de requisitos para la
integración con Recolecta
Estadísticas
V. REFERENCIAS
A continuación se definen las utilizadas en el presente documento.
Término
Dirección
KEGUIDELINES
http://wiki.surf.nl/display/standards/KE+Usage+Statistics+Guidelines
C/ Pedro Teixeira, 8 – 28020 Madrid. Telf. 914250909 Fax. 915712172. www.fecyt.es
12/12