1 1
2 Bibliotecas y repositorios digitalesCapítulo 7 Interoperabilidad: ventajas y dificultades. La recolección desde otros repositorios y la exposición por diversos protocolos. El protocolo OAI-PMH. Problemas derivados del volumen y heterogeneidad de los datos recolectados. Directrices de interoperabilidad.. 2
3 Contenido Introducción Niveles de interoperabilidadFormas de interoperar Formatos de metadatos OAI-PMH Recolección de recursos Directrices de interoperabilidad 3
4 Introducción 4
5 Introducción ¿Qué es la interoperabilidad?Capacidad de los sistemas informáticos de interactuar a través del intercambio de información y servicios, para lograr un objetivo. 5
6 Introducción ¿Por qué es importante interoperar?El intercambio de servicios y recursos ayuda a cumplir parte de los objetivos de un repositorio digital: Mayor visibilidad e impacto de los recursos propios Mayor cantidad de recursos ofrecidos a los usuarios Mayor cantidad y diversidad de servicios para ofrecer 6
7 Introducción El contexto del Open AccessLos movimientos de Acceso Abierto y la tendencia mundial hacia estas políticas plantea un marco altamente propicio para la interoperabilidad entre repositorios digitales. 7
8 Introducción El contexto del Open AccessLos movimientos de Acceso Abierto y la tendencia mundial hacia estas políticas plantea un marco altamente propicio para la interoperabilidad entre repositorios digitales. 8
9 Introducción Agregadores de recursosExisten repositorios que se dedican exclusivamente a la recolección y exposición de recursos en acceso abierto de terceros. Esto significa que no cuentan con producción propia. Hispana: más de 4 millones de registros recolectados de entre más de 200 repositorios de España. Europeana: más de 32 millones de registros recolectados de entre más de 1500 repositorios de Europa (específicamente de la Unión Europea). OAIster: más de 23 millones de recursos recolectados de entre más de 1100 repositorios de acceso abierto de todo el mundo. 9
10 Introducción Agregadores de recursos- Ofrecen servicios de valor agregado. Ofrece acceso a conjuntos de todos tipos de materiales del patrimonio bibliográfico español, reunido de diversos repositorios institucionales. Reúne contribuciones culturales digitalizadas en instituciones de la Unión Eurpea. Incluyen: libros, películas, pinturas, periódicos, mapas, manuscritos, etc. Permite un servicio de búsqueda regional de publicaciones científicas, integrando el material de repositorios en ocho países de Latinoamérica. 10
11 Introducción Directrices de interoperabilidadSon un conjunto de reglas y recomendaciones que buscan establecer un marco de trabajo a fin de que dos sistemas puedan interactuar de forma exitosa y confiable. Directrices Driver 2.0: Directrices OpenAIRE: https://guidelines.openaire.eu Directrices SNRD: 11
12 Niveles de interoperabilidad12
13 Niveles de interoperabilidadDado que interoperabilidad es un término muy amplio (aplicable en muchas disciplinas), existen múltiples clasificaciones del mismo. En lo que respecta a los repositorios digitales, interesa analizar una perspectiva mas bien tecnológica y acotada: Interoperabilidad Sintáctica Interoperabilidad Semántica Agregar informacion sobre otras formas de clasificar los niveles de interoperabilidad: 13
14 Niveles de interoperabilidad SintácticaHace referencia a todo lo necesario para que dos sistemas sean capaces de establecer una comunicación e intercambiar información. Esto incluye: protocolos de comunicación y transferencia codificación de caracteres formatos de datos 14
15 Niveles de interoperabilidad SintácticaElementos que corresponden a la interoperabilidad sintáctica pueden ser, por ejemplo: protocolo TCP/IP protocolo HTTP protocolo OAI-PMH Formato XML y esquemas XML (XSD) Directrices de interoperabilidad 15
16 Niveles de interoperabilidad SemánticaHace referencia a todo lo necesario para que el sistema receptor haga una correcta interpretación de la información recibida, de forma automática. Se busca que el sistema receptor "entienda" los datos tal como los "entiende" el emisor. Para contar con interoperabilidad semántica, primero debe asegurarse la interoperabilidad sintáctica entienda = interprete, 16
17 Niveles de interoperabilidad SemánticaEntran en juego: Formatos de metadatos Vocabularios controlados: Tesauros Sistemas de clasificación Ontologías Directrices de interoperabilidad 17
18 Niveles de interoperabilidad Estándares internacionalesLa adopción de estándares internacionales aumenta las capacidades de interoperabilidad del repositorio. Protocolos de transferencia: REST, Z39.50, etc Formatos de archivos: XML, etc Formatos de metadatos: DC, MODS, MARCXML, etc Directrices: DRIVER, Lucis MODS, OpenAIRE, etc Aquí yo haría una pausa y trataría de tirar alguna idea un poco más concreta. Es mucha información junta, y requiere ser fijada. Un ejemplo quizás sirva, no lo se... 18
19 Formas de interoperar 19
20 Formas de interoperar En general, en el contexto de los repositorios digitales se habla de: Búsqueda remota Recolección de recursos Exposición Remota Depósito remoto 20
21 Formas de interoperar Búsqueda remota: Z39.50Definido en los estándares internacionales ANSI/NISO z39.50 e ISO 23950 Protocolo cliente-servidor de búsqueda y recuperación desde bases de datos remotas. Ampliamente utilizado en sistemas integrados de bibliotecas (ILS - Integrated Library Systems) para la búsqueda remota y la gestión de préstamos interbibliotecarios (Interlibrary Loan). Sintaxis de consulta específica: PQF (Prefix Query Format) 21
22 Formas de interoperar Búsqueda remota: Z39.50Z> 1=1003 software Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 66, setno 1 records returned: 0 Elapsed: Z> show 1 Sent presentRequest (1+1). Records: 1 [INNOPAC]Record type: USmarc 00770nam I 4500 s enkm a100 0 eng u $c MIA $d m.c. $d IQU $a IQUU $a QA $a 76.6 $a S64 $a 1970 $a Software 70 Conference $d (1970 : $c University...) $a Software 70: $b proceedings of a conference ... $a Princeton, N. J., $b Auerbach, $c 1970. $a 197 p. $b illus. $c 29 cm. $a Includes bibliographical references. $a Computer programming $v Congresses. $a Programming languages (Electronic computers) $v Congresses. $a Evans, David J. $a Software World (Firm) nextResultSetPosition = 2 Elapsed: Z> 22
23 Formas de interoperar Búsqueda remota: Z39.50Ventajas y desventajas Las consultas son abstractas respecto de la estructura de la base de datos que se está consultando Los mapeos de campos de búsqueda dependen de la implementación de cada servidor No aprovecha las ventajas de la web actual (protocolo REST) Vale la pena aclarar aquí que Z usa otros puertos no convencionales. Esto implica tener que abrir puertos especificos en los servidores, firewalls, etc... También podrías aclarar que necesitás instalar ciertas extensiones para usarlo. Por ejemplo, YAZ para C, YAZ++ para C++, PHP/YAZ para PHP, JZKit para Java, NET::Z3950 para Perl... 23
24 Formas de interoperar Búsqueda remota: SRU/SRWSRU (Search / Retrieve via URL) y SRW (Search / Retrieve via Web) nacen como los sucesores del protocolo Z39.50, y se apoyan sobre tecnologías actuales y muy difundidas (HTTP, XML). Al igual que Z39.50, la agencia responsable del mantenimiento de estos dos estándares es la Library of Congress Ambos son considerados muy simples de entender e implementar 24
25 Formas de interoperar Búsqueda remota: SRUSe caracteriza por enviar la expresión de búsqueda (y cualquier otra indicación) dentro de una URL. Esto es, todos los comandos necesarios para que el servidor entienda una petición y lleve a cabo las acciones pertinentes, se envían dentro de la URL misma de la petición. 25
26 Formas de interoperar Búsqueda remota: SRWAl igual que su mellizo SRU, trabaja sobre tecnologías actuales y muy difundidas: XML y HTTP, pero presenta una importante diferencia: el envío de la petición se realiza mediante un POST al servidor, en el que se envía un documento XML que contiene todas las instrucciones y datos correspondientes. Esto es, la consulta al servidor se "empaqueta" en XML y se envía, recibiendo XML como respuesta (al igual que en el caso de SRU) 26
27 Formas de interoperar Búsqueda remota: SRWLas reglas y restricciones utilizadas para armar e interpretar el paquete XML están dadas por el protocolo SOAP. SOAP fue creado y es mantenido por la W3C, en el área de los Web Services. SOAP es un protocolo estándar y muy difundido. Casi cualquier lenguaje de programación moderno tiene librerías para trabajar con SOAP. Ventaja adicional: SOAP es otro estandar, muy probado, difundido e integrado en casi cualquier lenguaje de programación moderno 27
28 Formas de interoperar Búsqueda remota: SRWPetición SRW
29 Formas de interoperar Búsqueda remota: SRWRespuesta
30 Formas de interoperar Búsqueda remota: OpenSearchEs un protocolo que extiende otros formatos para agregar la búsqueda remota. Las peticiones se realizan vía GET (los parámetros van en la URL) Proporciona Autodiscovery: permite que los navegadores detecten que el sitio soporta OpenSearch y así el sitio podrá seleccionarse como motor de búsquedas del navegador La respuestas pueden ser: la página de resultados del sitio en cuestión en RSS o ATOM, extendidos con elementos OpenSearch que agregan información sobre la búsqueda Ejemplos: Youtube, SEDICI, Facultad de Informática Ventaja adicional: SOAP es otro estandar, muy probado, difundido e integrado en casi cualquier lenguaje de programación moderno 30
31 Formas de interoperar Búsqueda remota: OpenSearchURLs de Ejemplo uedaRSS.do?q={searchTerms} Donde searchTerms es el término de búsqueda deseado rms}&p={startPage?}&c={count?}&l={language?} search/discover?rpp=100&format=atom&sort_by=2&order=desc&quer y=sedici.creator.person:"{name}" Donde {name} es el nombre del autor a buscar Ventaja adicional: SOAP es otro estandar, muy probado, difundido e integrado en casi cualquier lenguaje de programación moderno 31
32 Formas de interoperar Recolección de registros: OAI-PMHOpen Archives Initiative - Protocol for Metadata Harvesting Establece un conjunto de reglas a partir de las cuales puede realizarse el intercambio de registros de recursos de forma exitosa. Se centra en la transferencia de metadatos de un extremo a otro, sin establecer restricciones en cuanto a los datos que se transfieren. 32
33 Formas de interoperar Recolección de registros: OAI-PMHDefine dos perfiles de trabajo Data Provider: es aquél repositorio que ofrece sus recursos bajo el protocolo OAI-PMH, para que otros los recolecten mediante cosechas. Service Provider: es aquél que recolecta registros desde distintos Data Providers y brinda un servicio a una comunidad de usuarios en base a los recursos recolectados y el valor agregado aportado sobre los mismos (deduplicación, normalización, ordenamiento, búsquedas, etc). ¿esto es todo de OAI? ¿restricciones? ¿ventajas? ¿desventajas? ¿problemas típicos?.... tranquilo muñeco! viene mas adelante ... 33
34 Formas de interoperar Exposición remota: Formatos XMLRSS Siglas de Really Simple Syndication, un formato XML para sindicar o compartir contenido en la web. Permite distribuir contenidos sin necesidad de un navegador, utilizando un software diseñado para leer estos contenidos Es parte de la familia de los formatos XML, desarrollado específicamente para todo tipo de sitios que se actualicen con frecuencia 34
35 Formas de interoperar Exposición remota: Formatos XMLAtom El Protocolo de Publicación Atom (resumido en Inglés AtomPub o APP) es un protocolo simple basado en HTTP para crear o actualizar recursos en Web Surge como alternativa a RSS Se basa en tres conceptos: Fuente web Sitios web consumidores Agregadores 35
36 Formas de interoperar Exposición remota: Formatos XMLEjemplo de uso El portal de revistas científicas de la UNLP, cuyo desarrollo y mantenimiento esta a cargo del equipo del SEDICI, expone de manera remota los contenidos que corresponden a las revistas del portal y que se encuentran en el repositorio. Esto se logra mediante la utilización de los formatos xml antes mencionados. 36
37 Formas de interoperar Exposición remota: Formatos XMLRecuperación y exposición de números y artículos de una revista (Wordpress) Listado de números en XML RSS últimos artículos /open-search/discover? rpp=5&format=atom& sort_by=2& order=desc&scope=10915/402 IRI/gateway/plugin/WebFeedGatewayPl ugin/rss2 37
38 Formas de interoperar Depósito remoto: SWORDSimple Web service Offering Repository Deposit Protocolo basado en APP (Atom Publishing Protocol, a.k.a ATOMPUB) Permite realizar el depósito de documentos de forma remota: desde otros sistemas. Es un protocolo cliente-servidor 38
39 Formas de interoperar Depósito remoto: SWORDDistintos usos posibles Depósito simultáneo en múltiples repositorios Depósito automático por parte de equipamiento científico Depósito desde aplicaciones externas al repositorio (escritorio, OJS, OCS, etc) Es un estándar que se limita a la transferencia de un objeto desde el cliente al servidor, sin imponer restricciones en cuanto a los objetos que se transportan. Esto lo hace suficientemente flexible como para ser usado en cualquier tipo de repositorio. Ver como se puede completar. Quizas con algún ejemplo o alguna captura de la interfaz de SWORD en DSpace "esto lo hace suficientemente flexible".... Si, claro, pero potencialmente peligroso. Esto amerita una discusión me parece. ¿cómo conrolar lo que se sube? ¿dónde se sube lo que se sube? ¿todas las fuentes son 100% confiables? 39
40 Formas de interoperar Depósito remoto: SWORDEjemplo de uso Se utiliza para depositar la producción académica del portal de revistas de la UNLP en el repositorio institucional. En este caso: El Repositorio Institucional tiene implementado un sword-server El Portal de Revistas, implementado con OJS, posee un plugin que permite la utilización de un sword-client El depósito es unidireccional y diferido. Se creó un flujo de trabajo en el cual se deposita el contenido, se verifica el resultado de este depósito, se completan algunos metadatos que no se añaden de forma automática y se publica dicho contenido en el Repositorio. Ver como se puede completar. Quizas con algún ejemplo o alguna captura de la interfaz de SWORD en DSpace "esto lo hace suficientemente flexible".... Si, claro, pero potencialmente peligroso. Esto amerita una discusión me parece. ¿cómo conrolar lo que se sube? ¿dónde se sube lo que se sube? ¿todas las fuentes son 100% confiables? 40
41 Formas de interoperar Depósito remoto: SWORDVer como se puede completar. Quizas con algún ejemplo o alguna captura de la interfaz de SWORD en DSpace "esto lo hace suficientemente flexible".... Si, claro, pero potencialmente peligroso. Esto amerita una discusión me parece. ¿cómo conrolar lo que se sube? ¿dónde se sube lo que se sube? ¿todas las fuentes son 100% confiables? 41
42 Formas de interoperar MuestreoVer como se puede completar. Quizas con algún ejemplo o alguna captura de la interfaz de SWORD en DSpace "esto lo hace suficientemente flexible".... Si, claro, pero potencialmente peligroso. Esto amerita una discusión me parece. ¿cómo conrolar lo que se sube? ¿dónde se sube lo que se sube? ¿todas las fuentes son 100% confiables? 42
43 Formatos de metadatos 43
44 Formatos de metadatos Existen muchos estándares de formatos de metadatos Cada repositorio decide que formato de metadatos usar (incluso puede usar un formato propio) Los repositorios que deciden interoperar deben estar de acuerdo en cuanto a un formato de metadatos que ambos puedan manejar Aqui podés hacer el típico paralelismo con los idiomas y con los protocolos de comunicación... 44
45 Formatos de metadatos En todas las formas de interoperar presentadas existe un rol de proveedor de recursos y un rol de receptor de recursos. ¿Qué sucede cuando el proveedor de recursos utiliza un formato de metadatos que no es manejado por el receptor? ¿Como se gestiona este problema? La idea acá es generar charla y opiniones 45
46 Formatos de metadatos Algunas de las alternativas aplicables en cualquiera de los dos roles mencionados pueden ser: Se decide no interactuar con ese repositorio en particular Extender el software para así agregar soporte para un formato de metadatos en particular Realizar mapeos entre formatos de metadatos También dependen de la flexibilidad del software No interactuar: pérdida de potenciales recursos para el repositorio (en el caso de recolector); disminución de la visibilidad del repositorio (en el caso de proveedor) Extender el software: solo es posible con software de codigo abierto o propio; puede ser muy complejo; puede introducir errores o problemas de seguridad; muy costoso. Mapeos: la transformación de un formato complejo/jerarquico a uno simple/plano implica perdida de información; necesidad de armar los mapeos y aplicarlos en el momento adecuado (puede requerir la modificación del software) Si te animás, podés tirar un ejemplo simple para el caso de Mapeos, donde haya pérdida de información --> en la siguiente diapo propongo abrir la pagina de MODS y revisar las indicaciones para mapear a Dublin Core. Ahi se ven varios casos de perdida de información. 46
47 Formatos de metadatos Mapeos entre formatos de metadatosEn algunos casos, las entidades responsables de un formato de metadatos recomiendan cómo deben realizarse los mapeos a otros formatos. Ejemplo de esto es MODS: Conversión de DC (sin calificar) a MODS: Conversión de MODS a DC (sin calificar): Revisar algunas de las recomendaciones y ver los problemas: Conversión de DC (sin calificar) a MODS: Conversión de MODS a DC (sin calificar): 47
48 Formatos de metadatos Mapeos entre formatos de metadatosManual: es un trabajo muy costoso, ya que puede tratarse de miles de registros Automático: la transformación desde un formato complejo/jerárquico a uno simple/plano implica pérdida de información. La transformación inversa puede generar recursos deficientes en cuando a la descripción (campos incompletos, imposibilidad de uso de la especificidad de un formato complejo). No hay un humano tomando decisiones. 48
49 Name of the field in DSpaceName of the field in OJS DOI sedici.identifier.doi doc.doi Title dc.title doc.title Alternative title dc.title.alternative Author sedici.creator.person doc.author.fullName Date of publication dc.date.issued doc.DatePublished Language dc.language doc.language Summary dc.description.abstract doc.abstract Type of document dc.type doc.type Issue identification sedici.relation.journalVolumeAndIssue journal.year, journal.number, journal.volume Title of the journal sedici.relation.journalTitle journal.title 49
50
51 OAI-PMH Open Archives Initiative Protocol for Metadata Harvesting 51
52 OAI-PMH Introducción Protocolo para la recolección de metadatosAmpliamente adoptado por repositorios digitales en todo el mundo Es muy simple de entender y utilizar Funciona sobre XML y HTTP Se centra en establecer un marco de reglas para la transferencia eficiente de registros de metadatos No impone (casi) ninguna restricción en cuanto al contenido a transmitir ahhh, ahora veo que hay más OAI-PMH.... Ya me sonaba raro! (ignorá el comentario anterior) jajaja 52
53 OAI-PMH Introducción Entidades vinculadas a los metadatos - Definiciones El protocolo distingue tres tipos de entidades vinculadas a los metadatos: - Recurso: es el objeto o la “cosa”, física o digital, que puede ser descripta mediante metadatos. (P.e: un libro en papel). - Ítem: es un componente en un repositorio que representa a un recurso, constituido por los metadatos que describen al mismo. (P.e: el libro digitalizado y su conjunto de metadatos). - Registro: son metadatos en un formato específico. Es una repuesta en XML a la solicitud de recolección de un ítem específico en un repositorio. ahhh, ahora veo que hay más OAI-PMH.... Ya me sonaba raro! (ignorá el comentario anterior) jajaja 53
54 OAI-PMH Introducción Las peticiones al servidor se hacen por medio de un verbo y un conjunto de parámetros, codificados en una URL Un verbo es una orden que indica al servidor lo que se requiere, refinando algunos aspectos de ese requerimiento a través del uso de parámetros. 54
55 OAI-PMH Introducción La respuesta a una petición OAI-PMH es un documento XML. Se compone de dos secciones: Información de la petición: fecha, hora, verbo y parámetros (común para cualquier verbo) Cuerpo con la respuesta: datos con una estructura acorde a la información solicitada (específico para cada verbo) 55
56 OAI-PMH FuncionamientoLos verbos disponibles son: Identify ListRecords ListMetadataFormats ListSets ListIdentifiers GetRecord 56
57 OAI-PMH FuncionamientoVerbo Identify Retorna información del repositorio e información acerca de la implementación del OAI Data Provider. No recibe parámetros. Comentar nuevamente el significado de OAI Data Provider Explicar todas los elementos en la respuesta 57
58 OAI-PMH FuncionamientoElementos importantes que se desprenden del Identify Fecha/hora de creación del recurso mas viejo Granularidad de las peticiones Gestión de registros eliminados Compresión de los datos a transferir (Opcional) Descripción del repositorio (Opcional) Datestamp: - Debe mantenerse la fecha de creación y luego la fecha de actualización Descripcion del repositorio: además de contener texto (o incluso HTML o XML), tambien se indica un mail de contacto. Sobre Granularidad: - Nivel de dias - Nivel de segundos Sobre eliminaciones: - Opciones son: no, persisten, transient - Cuando se elimina un registro, el datestamp pasa a ser la fecha de eliminación - La marca status="deleted" en el header del registro indica que se eliminó ese registro en ese formato de metadatos, lo que significa que el mismo registro puede existir en otro formato de metadatos. Compresión de los datos: Se realiza a nivel HTTP. El cliente tiene que enviar el header Accept-encoding: gzip. La implementación de HTTP se encarga de la compresion en el origen y la descompresion en el destino. OAI Friends: una forma de encontrar nuevos repositorios 58
59 OAI-PMH FuncionamientoVerbo ListMetadataFormats Lista todos los formatos de metadatos soportados por el repositorio. OAI-PMH obliga a exportar, por lo menos, Dublin Core sin calificar. Se indica el prefix que identifica el namespace del formato de metadatos. Parámetro opcional identifier 59
60 OAI-PMH FuncionamientoVerbo ListSets Lista los distintos Sets soportados por el repositorio Son una forma de organizar la información dentro del repositorio Poseen un nombre y una clave que los identifica Parámetro opcional resumptionToken sedici.unlp.edu.ar/oai/request?verb=ListSets bdigital.uncu.edu.ar/OAI/index.php?verb=ListSets 60
61 OAI-PMH FuncionamientoVerbo ListRecords Retorna un listado de registros que cumplen con los parámetros especificados en la petición: metadataPrefix (obligatorio) resumptionToken (opcional) set (opcional) from (opcional) until (opcional) 61
62 OAI-PMH FuncionamientoCosechas incrementales por fecha (from y until) Información clasificada por conjuntos (set) Paginación de resultados resumptionToken Comentar ventajas de cada una 62
63 OAI-PMH FuncionamientoRegistro de respuesta
64 OAI-PMH FuncionamientoVerbo ListIdentifiers Lista los encabezados de todos los registros que se corresponden con los parámetros especificados. Recibe los mismos parámetros que ListRecords Se suele usar para determinar la cantidad y estado de los registros (borrado o no) que coinciden con ciertos parámetros, sin necesidad de descargar sus metadatos. 64
65 OAI-PMH FuncionamientoVerbo GetRecord Retorna el registro completo (encabezado y metadatos) de un recurso específico. Recibe los parámetros: - identifier - metadataPrefix Prefix=oai_dc 65
66 Recolección de recursosUtilizando OAI-PMH 66
67 Recolección de recursosCuando se recolectan recursos desde múltiples repositorios, se presentan varios problemas. Políticas de catalogación independientes Diferencia de formatos de metadatos (y por lo tanto de especificidad de la información) Múltiples términos para el mismo concepto (ej.: idiomas) Uso de múltiples vocabularios controlados (tesauros, sistemas de clasificación, etc) La gran mayoría expone sus recursos sólo en Dublin Core sin calificar 67
68 Recolección de recursos Problemas a solucionarFormatos de metadatos Mapeos a un formato común ¿cuál? Diferencias en la codificación de caracteres Presencia de caracteres inválidos: ¿se descarta el caracter inválido? ¿se descarta el documento completo? ¿se utiliza un caracter de reemplazo? 68
69 Recolección de recursos Problemas a solucionarAutores Distinción entre apellido y nombres (considerar el uso de iniciales) Muchas veces se incluye a la institución como autor Unificación de autores Instituciones Identificación de instituciones (generalmente aparecen junto con personas) Unificación de instituciones Agregar algunos ejemplos 69
70 Recolección de recursos Problemas a solucionarIdiomas Identificación del idioma: eng, en, en_US Muchas veces no se indica el idioma (se necesita aplicar una detección automática) Unificación de idiomas Tipología documental Múltiples formas de referenciar el mismo tipo de recurso Artículo, ART, Article Unificación de tipologías documentales Agregar algunos ejemplos 70
71 Recolección de recursos Problemas a solucionarTipología documental articulo artículo articulos artículos articl paper,Artículo article Article Peer-reviewed Article PeerReviewed ARTICULO Artículo revisado por pares journal article Articles Research paper ARTÍCULO Articulo Artículos COMUNICACION Editorial Comunicación EDITORIAL info:eu-repo/semantics/article DOSSIER Articulo de Investigación Cientifica Agregar algunos ejemplos 71
72 Recolección de recursos Problemas a solucionarOtros problemas: Acceso al PDF o a los metadatos Validación de la URL de acceso al recurso Muchas correcciones a estos problemas se han logrado automatizar mediante un sistema correcto de tareas de curación Agregar algunos ejemplos 72
73 Directrices de interoperabilidad73
74 Directrices de interoperabilidadSon un conjunto de recomendaciones que buscan maximizar la interoperabilidad entre los repositorios. DRIVER 2.0 establece recomendaciones tanto a nivel sintáctico y como a nivel semántico. DRIVER 2.0 es la mas difundida en Europa y la base de muchas otras directrices en el mundo (ej.: LUCIS-MODS, OpenAIRE). DRIVER: Digital Repository Infrastructure Vision for European Research 74
75 Directrices de interoperabilidad DRIVER 2.0Extracto del documento de DRIVER 2.0 Para la comunicación en general es importante que la persona B sea capaz de comprender lo que la persona A está diciendo. Para este entendimiento mutuo, se necesita una base común, un léxico básico con una comprensión del significado de las cosas. A partir de este punto, ya se puede comenzar el razonamiento. Para respaldar la comunicación científica con el uso de repositorios, éstos deberían hablar el mismo idioma y por tanto es fundamental crear una base común. 75
76 Directrices de interoperabilidad DRIVER 2.0: características generalesDiseñado sólo para: Protocolo OAI-PMH Recursos textuales Documentos a texto completo Documentos en Acceso Abierto Dublin Core sin calificar como formato de metadatos 76
77 Directrices de interoperabilidad DRIVER 2.0: características generalesSobre el uso de OAI-PMH Se reserva el prefijo oai_dc para identificar el formato de metadatos DC Sin Calificar Los datestamp (tanto en las solicitudes como en las respuestas) debe respetar el formato ISO8601, expresadas en UTC: AAAA-MM- DDThh:mm:ssZ La política de registros eliminados debe ser por lo menos transient (aunque se recomienda persistent). Si se usa transient, la información del registro borrado debe mantenerse por lo menos por un mes 77
78 Directrices de interoperabilidad DRIVER 2.0: características generalesSobre el uso de OAI-PMH Se recomienda que el resumptionToken se mantenga activo por lo menos por 24 horas. El tamaño del lote debe ubicarse entre 100 y 500 registros. Si se utiliza un set específico para DRIVER, se recomienda usar driver como setSpec. Es obligatorio indicar un mail de contacto (campo admin de la respuesta del verbo Identify) Explicar por que sería necesario contar con un set específico para DRIVER 78
79 Directrices de interoperabilidad DRIVER 2.0: características generalesSobre el uso de Dublin Core Es obligatorio usar codificación Unicode. El contenido de los metadatos no puede incluir lenguaje de marcado (HTML ni XML). Se recomienda que el contenido de los metadatos se encuentre en inglés. El metadato dc:creator debe respetar el estilo bibliográfico APA: apellido, iniciales (nombre) 79
80 Directrices de interoperabilidad DRIVER 2.0: características generalesSobre el uso de Dublin Core Se recomienda que el metadato dc:description contenga un resumen del documento (el abstract). El metadato dc:date debe respetar el formato de fecha ISO8601. Se recomienda que contenga la fecha de publicación del documento. 80
81 Directrices de interoperabilidad DRIVER 2.0: características generalesSobre el uso de Dublin Core El metadato dc:type debe pertenecer a un vocabulario definido en un esquema URI (info:eu-repo/semantic) info:eu-repo/semantics/article info:eu-repo/semantics/book info:eu-repo/semantics/bachelorThesis info:eu-repo/semantics/masterThesis info:eu-repo/semantics/doctoralThesis info:eu-repo/semantics/preprint 81
82 Directrices de interoperabilidad DRIVER 2.0: características generalesSobre el uso de Dublin Core Se recomienda que el metadato dc:format sea un MIME- Type incluido en IANA. Ej.: application/pdf El metadato dc:identifier debe respetar un esquema URI, y vincular a: Identificador persistente (DOI, Handle, etc) Documento a texto completo (ej.: PDF) Página de transición (jump-page) 82