Proyecto INCAGRO. Levantamiento de la Oferta Disponible en AGRORED PERU y Políticas Conjuntas

Proyecto INCAGRO Levantamiento de la Oferta Disponible en AGRORED PERU y Políticas Conjuntas Daniel Calvelo Aros Lima, Diciembre del 2006 1

INDICE Resumen ejecutivo... 3 Antecedentes... 4 Objetivos de la consultoría... 5 Metodología empleada... 6 Tecnologías de manejo digital de archivos de documentos... 6 Reseña histórica... 6 Esquemas de metadatos... 7 Estándares en uso para la puesta en red de archivos digitales... 8 Servicios Web... 8 REST... 9 SOAP... 12 XML-RPC... 13 OAI-PMH... 13 Dublin Core... 14 Sistemas de biblioteca digital... 16 ISIS... 16 Estado de implementaciones en Perú... 17 2

Resumen ejecutivo INCAGRO en su segunda fase se propone contribuir a establecer un servicio de información científica y tecnológica para la innovación agraria. Para ello a finales del 2004 inició un trabajo de sensibilización entre las instituciones que generan y son usuarias de información científica y tecnológica. La respuesta positiva de un primer grupo de 35 instituciones le llevó a formular una propuesta denominada Servicio federado de información científica y tecnológica para la innovación agraria. En esta propuesta se reconoce la diferencia entre las instituciones que generan información de las que son básicamente usuarias. Se plantea además el respeto a la estrategia política de cada institución y se reconoce la diversidad de plataformas y tecnologías utilizadas. INCAGRO toma el liderazgo de la propuesta, desde el 2006 denominada AGRORED Perú. La labor muestra hoy resultados positivos en términos de la decisión política por parte de las más altas autoridades del sector agrario, y la respuesta masiva de las Direcciones Regionales Agrarias y de 121 organizaciones e instituciones públicas y privadas. Estos resultados le permiten a INCAGRO avanzar en la búsqueda de soluciones a los problemas siguientes: (i) qué tipo de organización o acuerdo debe regular la relación entre las instituciones participantes en AGRORED Perú; (ii) qué tecnología aplicar para lograr uniformidad en las bases de datos y permitir aligerar las búsquedas; y (iii) cómo financiar los costos de adecuación y aplicación de la tecnología. El presente documento establece, dentro del problema (ii) un estado del arte inicial, global, sobre metodologías, estándares y tecnologías de archivos digitales de documentos. Se incide en la diversidad de la oferta tecnológica, en especial en software libre, en la problemática persistente de armonización de formatos y de estándares, y de la importancia preponderante del concepto de metadatos. En primer lugar establecemos una serie de definiciones y un vocabulario específico a la problemática del intercambio de archivos de información estructurada; en segundo lugar definimos y explicamos los estándares más relevantes al problema de federación que busca resolver Agrored Perú y finalmente presentamos algunas de las tecnologías existentes y aplicadas en Perú. 3

Antecedentes El Programa Innovación y Competitividad para el Agro Peruano, INCAGRO, se puso en marcha en enero del 2001. Este Programa del Ministerio de Agricultura diseñado para ser ejecutado en tres fases: (i) Fase I de establecimiento de un sistema de innovación tecnológica; (ii) Fase II de expansión del sistema; y (iii) Fase III de consolidación del sistema. INCAGRO Inicia la segunda fase en julio del 2005. El Programa en su primera fase adjudicó recursos por US$ 6.4 millones de dólares comprometiendo US$ 6,6 a 95 entidades distintas, atendió a 137 organizaciones de productores como clientes de servicios y participaron otras 175 entidades como colaboradoras. En la segunda fase INCAGRO tiene previsto invertir US$ 32.6 millones de dólares en subproyectos de servicios de extensión, apoyo al desarrollo de organizaciones indígenas y de mujeres, investigación adaptativa e investigación estratégica, programas de incentivos para postgraduados, y capacitación. Aproximadamente 1,000 organizaciones de productores estarán directamente involucradas como clientes de los servicios y no menos de 100 entidades privadas serán sus proveedores. Se calcula que no son menos de 46 mil pequeños productores los que contratarán servicios especializados y unos 3 mil se vincularían a procesos de investigación estratégica. Otros 100 mil pequeños productores serán influenciados por las innovaciones tecnológicas y de gestión, 140 mil hectáreas incorporarán tecnología mejorada y no menos de 450 planes de negocio se encontrarán en marcha. En esta segunda fase INCAGRO tiene como meta y objetivo contribuir al establecimiento y desarrollo de un sistema de información científico y tecnológico que no solo permita que los usuarios: productores, empresarios, estudiantes, técnicos, especialistas, investigadores accedan fácilmente a los servicios de información agraria, sino más bien acceda a un servicio donde la información indiscriminada es debidamente filtrada, entregada de la forma más eficiente y efectiva posible 1. En el año 2005 INCAGRO identificó a las principales organizaciones e instituciones que generan y difunden información científica y tecnológica, a las que se convocó para encontrar soluciones al problema de dispersión, desarticulación y escasa uniformidad que caracterizan al conjunto de servicios de información que operan en el país. La respuesta positiva de la totalidad de instituciones, y un trabajo intenso de promoción de INCAGRO para crear una red, propició que el Ministerio de Agricultura emitiera el 22 de junio del 2006 la Resolución Ministerial Nro. 0537-2006-AG reconociendo la importancia de AGRORED Perú como el meta sistema virtual que favorece el desarrollo de la ciencia y tecnología para la innovación del agro peruano. AGRORED Perú se constituye así en un acuerdo en el que cada uno de las partes se compromete a asegurar, de modo permanente, la accesibilidad, inteligibilidad, relevancia, oportunidad y fiabilidad de la INFORMACIÓN AGRARIA. INCAGRO asume la responsabilidad de la promoción y animación de la red. En estos dos años INCAGRO dedica recursos y esfuerzos para identificar y definir las formas técnicas y organizativas de AGRORED PERU. En particular si ésta debería constituirse como persona jurídica o más bien mantenerse como un acuerdo entre organizaciones e instituciones públicas y privadas que buscan uniformidad en el diseño de sus bases de datos, aplican la normatividad y estándares internacionales, 1 Filosofía de Investigación y Desarrollo en Sistemas Agropecuarios. R. Cañas, R. Quiroz y C. León Velarde. Consejo Superior de Investigaciones. Boletín 53, UNMSM. 4

buscan establecer un meta sistema donde se facilite la localización y recuperación de los conocimientos que conservan y aportan. INCAGRO inició conversaciones con la Organización para la Agricultura y Alimentación, FAO con el propósito de identificar apoyo técnico y financiero; ha consultado con especialistas; y se aboca hoy a identificar la magnitud, naturaleza y diversidad de plataformas digitales en la que se encuentran trabajando cada una de los firmantes del acuerdo AGRORED Perú. Al interior de INCAGRO, como entidad generadora de información, se ha avanzado en el diseño de herramientas que permiten hoy hacer el seguimiento y monitoreo de cada uno de los subproyectos que conduce y de los 643 previstos para la segunda fase. Lo que permitirá que la información científica y técnica, empleada o generada en cada uno de ellos conformen una base de datos, donde se aplicará el concepto de meta sistema. La experiencia permitirá generar modelos replicables a otras instituciones u organizaciones que conforman AGRORED Perú, y servirá de base para la promoción de un escuela de formación de especialistas en redes de información científica y tecnológica, y capacitación en la gestión de información científica y tecnológica agraria. INCAGRO convocó y tomó contacto, para la organización de dos talleres de AGRORED Perú, a más de 120 organizaciones e instituciones entre universidades, centros de investigación, ONG y empresas privadas, que se suman a todos los organismos descentralizados del Ministerio de Agricultura y las 50 Direcciones Regionales y Direcciones de Información del Ministerio de Agricultura, creando así una base sólida en el respaldo de una decisión política que tiene en común el desarrollo agrario del país. Con todos ellos se han discutido los criterios para identificar i) demanda de Información en Ciencia y Tecnología Agraria, ii) mecanismos de calificación de la información científica y tecnológica, iii) técnicas e instrumentos de construcción de metadatos y tesauros, iv) normatividad y derechos de autor. Existe por lo tanto un común acuerdo que permitirá avanzar y concretar qué es AGRORED Perú, cuáles son las normas de conducta de sus integrantes, qué actividades son prioritarias para que se inicie el diseño de un buscador, ya sea este producto de la aplicación de lo avanzado por FAO con su sistema AGRIS o en la construcción de uno nuevo, que signifique un aporte no sólo al país sino también a otros países en vías de desarrollo. Objetivos de la consultoría Esta consultoría busca: (i) levantar el diagnóstico tecnológico y organizativo de las entidades que conforman el núcleo inicial de trabajo de Agrored Perú; (ii) proponer un estado del arte tecnológico sobre intercambio de información digital; (iii) proponer de acuerdo al diferencial encontrado en las instituciones las líneas de fortalecimiento en términos de políticas, tecnologías y recursos humanos, y finalmente (iv) hacer un análisis conjunto con la consultoría Establecimiento del núcleo inicial de información científica y tecnológica agraria AGRORED PERU para canalizar una solicitud de apoyo de la Organización de Naciones Unidas para la Agricultura y la Alimentación, FAO. En este primer informe se ha incidido en el punto (ii), ya que la definición del núcleo inicial de trabajo de Agrored Perú se ha resuelto durante este primer período de 5

trabajo. Metodología empleada En esta primera etapa de la consultoría se ha revisado la documentación producida para Agrored Perú, los informes de los Talleres de AGRORED Perú, y se ha realizado un levantamiento inicial del estado del arte tecnológico. Se ha trabajado junto con la consultoría Establecimiento del núcleo inicial de información científica y tecnológica agraria AGRORED PERU para definir el núcleo inicial sobre el que se aplicará el diagnóstico organizativo y tecnológico y la definición de líneas de fortalecimiento. Se prevé que con estos resultados será posible establecer la o las modalidades más apropiadas para solicitar la cooperación técnica a la Organización de Naciones Unidas para la Agricultura y la Alimentación FAO. Tecnologías de manejo digital de archivos de documentos Reseña histórica El manejo de información bibliográfica por medios informáticos tiene una historia larga y fructífera. En cada fase de su evolución se ha basado en la tecnología existente, y hoy es característica la permanente preocupación por el mantenimiento del acervo, sobre todo cuando éste ya está en algún (antiguo) formato digital. Inicialmente, hacia los años sesenta, los sistemas de manejo automatizado de fichas bibliográficas empleaban mainframes, esto es computadoras centrales accesibles a través de terminales. En los ochentas se introdujo la PC (originalmente acrónimo propuesto por IBM para Personal Computer), y la posibilidad de emplear catálogos digitales se puso al alcance de muchas instituciones de presupuesto modesto para un mainframe. Los desarrollos de esta época se basan en una arquitectura material compuesta por una sola estación de trabajo. Más adelante, con la introducción de los protocolos Ethernet y AppleTalk en particular, se empezó a trabajar en desarrollos llamados cliente-servidor, en los cuales se centraba el trabajo pesado en una sola máquina central, el servidor, y se empleaban computadoras más pequeñas con programas cliente. Las aplicaciones entonces estaban divididas entre un programa cliente y un programa servidor. En los noventas, con el avance en las instalaciones de Internet y sobre todo el desarrollo del World-Wide Web desde 1994, se empezó a pasar a arquitecturas de, grosso modo, dos tipos: por un lado desarrollos llamados multi-capa, que son esencialmente de tipo cliente-servidor en los cuales el cliente es un navegador web, y por otro lado desarrollos de tipo descentralizado, donde el rol de cliente o servidor queda diluido en una relación entre nodos. Recuérdese además que en estos últimos cuarenta años las capacidades de procesamiento y almacenamiento del equipo informático se han multiplicado por un factor cercano a un millón. 6

Queda claro finalmente que la posibilidad de interoperación de todos estos sistemas está basada en un conjunto de estándares de definición de formatos de archivo, de codificación de datos y de protocolos de comunicación. En la última década ha sido de especial importancia la definición del codificador de caracteres Unicode ISO10646, del formato de estructuración de datos XML, y por supuesto el conjunto de estándares del Internet Engineering Task Force (IETF) y del World-Wide Web Consortium que definen hoy en día la Web. Esquemas de metadatos En la primera época señalada, la de las mainframes, empezó a establecerse esquemas de codificación de la información bibliográfica. En especial en los setentas, la Library of Congress patrocinó el formato denominado Catálogo Legible por Máquinas (MAchine Readable Catalog, MARC) que priorizaba la optimización de la ocupación de espacio frente a otros criterios. MARC tuvo en su momento y durante los ochentas varias derivaciones en paralelo, para luego volver a confluir en 1997 en el estándar MARC21, que es objeto de norma ISO2709. Existe una versión actual que emplea formato XML con los mismos descriptores originales de MARC21, llamada MARCXML. En la misma línea de formatos, MARC ha producido dos derivados mayores: MODS y METS. MODS es el Metadata Object Description Schema, un esquema XML simplificado con respecto a MARC y adecuado para el catalogado de todo tipo de archivo, especialmente digital. METS es el Metadata Encoding and Transmission Standard, y contempla no solamente la descripción de un recurso digital sino el posible agrupamiento y categorización de conjuntos de recursos digitales. Además, METS define una forma de encapsular otros formatos dentro de un paquete bien definido, preparado tanto para la búsqueda como para el intercambio. Estos tres estándares MARC, MODS y METS son mantenidos por la Biblioteca del Congreso de EE.UU., y son de uso común en los países anglófonos. En Perú, la penetración de archivos bibliográficos digitales fue tardía, y basada más bien en tecnologías de estación de trabajo. El sistema de archivo digital más usado para referencias bibliográficas es apreciación preliminar por corroborar CDS/ISIS o alguno de sus derivados. La proliferación de formatos y estándares de metadatos durante los años setenta a noventa llevó a grupos de normalización a tratar por un lado de armonizar y por otro de promover núcleos comunes. Un logro esencial de este trabajo es el de la definición del Dublin Core, que fue objeto inicialmente de la norma NISO Z39.85-2001, más tarde de ISO15836-2003. Dublin Core define un conjunto mínimo de quince elementos de descripción para catalogar esencialmente cualquier tipo de obra. El esfuerzo más reciente y notable es el de OAI-PMH (Open Access Initiative Protocol for Metadata Harvesting), un estándar que define una forma de poner a disposición y obtener catálogos completos a través de servicios web. 7

Estándares en uso para la puesta en red de archivos digitales Vamos a describir aquí, en forma técnica bastante detallada, los principales estándares pertinentes a la problemática de Agrored. Servicios Web Un servicio en términos de informática es una forma definida de intercambio de información. Existe un servidor que provee información a un cliente que la requiere. Ambos deben poder interactuar por lo que la definición de un servicio implica la de al menos un protocolo y un formato de datos. El término, general, se puede aplicar tanto al correo electrónico como al acceso a bases de datos como a la navegación web. Un protocolo es una convención sobre la forma en que dos aplicaciones intercambian información. Lo esencial de los protocolos empleados en Internet está definido por documentos llamados Request For Comments ó RFC. La serie completa de RFC se encuentra almacenada por ejemplo en http://www.rfc-archive.org. El cuerpo normativo para estos protocolos es el Internet Engineerng Task Force ó IETF. Un formato de datos es una convención sobre la manera de almacenar información digital. Cada tipo de información (texto, imagen, datos estadísticos, geometría,...) se almacena y se transfiere en un formato de datos adecuado al tipo en cuestión. Existen formatos de datos abiertos y propietarios. Los primeros poseen una especificación de libre consulta, están definidos por cuerpos normativos de participación abierta, no están cubiertos por patentes y, en general, han sido implementados en al menos una versión de código abierto. Los segundos en general son producto de aplicaciones comerciales y rara vez poseen especificaciones abiertas. Un servicio web es un tipo de servicio que emplea los protocolos que definen la web (HTTP, HTML y ECMAScript en particular) para prestar otro tipo de servicios más sofisticados. El cuerpo normativo principal para estos protocolos y formatos es el World-Wide Web Consortium. En un servicio web, el servidor es una aplicación que interactua con un servidor web. El cliente es un navegador web común, eventualmente con añadidos especiales. El auge de los servicios web se debe a la disponibilidad de navegadores para cualquier plataforma y sistema operativo. Para el usuario, un servicio web se presenta como una página web dentro de un navegador, a través de la cual es posible acceder a bloques de información más específicos. Los servicios web pueden además cumplir el rol de pasarelas hacia otros servicios, como en el caso del acceso a correo electrónico a través de la web. Otros servicios web notables son: el servidor de cartografía e imagen google maps, los sistemas de búsqueda como google o altavista, las aplicaciones en línea como el SEACE o las interfases de gestión de cuentas bancarias. La tendencia actual a emplear el navegador web como cliente fundamental ha llevado incluso a crear herramientas de ofimática en línea, como google spreadsheet o thinkfree office. Una oportunidad importante del empleo de servicios web es que los clientes no deben necesariamente ser navegadores interactivos como Internet Explorer o Firefox. Dada una definición suficientemente completa de un servicio web, es posible crear aplicaciones que se comporten como clientes del servicio web, y luego 8

procesen la información recuperada para otros fines. Este es el caso de los Sistemas de Información Geográfica actuales, que son capaces de acceder a información cartográfica digital a través de servicios web para luego utilizarla de la misma forma en que utilizarían ficheros de datos. En un servicio web, la información transita por Internet a través de varios niveles de protocolos abiertos, en particular TCP/IP y HTTP. En estos protocolos, la información transita de forma tal que su intercepción es fácil. Desde el punto de vista de seguridad, estos protocolos son intrínsecamente susceptibles de ser monitoreados, y la información que transita por ellos copiada. Para limitar la posibilidad de espionaje indeseado de la transmisión es posible utilizar protocolos cifrados para servicios web en lugar de los protocolos por omisión. Los usos más comunes son el de la versión cifrada de HTTP, llamada HTTPS, y versiones cifradas de IP, que conforman lo que se denomina una red privada virtual, o VPN por sus siglas en inglés. Por lo tanto, el hecho de hacer transitar información por Internet no significa necesariamente perder el control sobre la seguridad de la información. Se puede definir varias familias de servicios web, de acuerdo a los detalles técnicos de los protocolos que emplean. Los que nos interesan aquí son los servicios web de tipo REST, los basados en SOAP y los basados en XML-RPC. REST REST es un acrónimo inglés de Transferencia de Estado de Representación. De las tres familias de servicios web es la más simple. Nos explayamos sobre REST porque OAI-PMH es un protocolo de tipo REST. La forma de comunicar en servicios web de tipo REST (llamados simpáticamente RESTful web services) se basa en cuatro principios: Se emplea un protocolo cliente-servidor sin estado: la memoria de lo que ocurre en las transacciones anteriores no está definida en el protocolo, es responsabilidad de la aplicación cliente si la necesita. Se emplea el esquema URI (o URL, definida en la RFC2396) para la definición de las peticiones del cliente al servidor. Se emplean exclusivamente las operaciones GET, PUT, POST y DELETE del protocolo HTTP. Se emplea XML o alguna de sus variantes como HTML para la transimisión de las respuestas del servidor a las peticiones del cliente Ejemplo: el protocolo de servicio de mapas OGC WMS Como ejemplo de una sesión típica REST, esta es la transcripción del pedido de un mapa a un servidor OGC WMS, el servidor de cartografía de red vial del Ministerio de Transportes y Comunicaciones: 1. El cliente envía al servidor un pedido utilizando una URI correctamente formulada a través de HTTP GET http://200.48.60.53:8080/wmsconnector/com.esri.wsit.wmsser vlet/redvial?styles=0&version=1.1.1&service=wms&request=getmap &FORMAT=image/gif&HEIGHT=400&WIDTH=600&LAYERS=0&SRS=EPSG:4326& BBOX=-83,-18,-68,-3 HTTP/1.0 La URL de esta petición HTTP se puede escribir directamente en la interface de un navegador web. Analicémosla por partes: 9

http:// Se utiliza el protocolo HTTP 200.48.60.53 La dirección IP del servidor :8080 El puerto de conexión TCP en el servidor /wmsconnector/com.esri.wsit.wm SServlet/redvial La ruta hacia el servicio dentro del servidor? Hasta aquí sólo se ha especificado el servicio STYLES=0 Siguen los parámetros, bajo la forma etiqueta=valor & VERSION=1.1.1&SERVICE=WMS&REQU EST=GetMap &FORMAT=image/gif&HEIGHT=300&W IDTH=300&LAYERS=0&SRS=EPSG:432 6&BBOX=-83,-18,-68,-3 Separados por el símbolo & Estos son los parámetros básicos de la petición: tipo de servicio, tipo de petición y versión del protocolo Estos son los parámetros específicos de esta petición: al tratarse de un mapa, se solicita cierto formato de gráficos, con cierto tamaño, correspondiente a un área dada de un mapa determinado con una proyección estipulada siguiendo el codificador del Grupo Europeo de Exploración Petrolífera (EPSG), que es un estándar de facto en geomática 2. El servidor responde a la petición enviando contenido encapsulado en formato MIME (RFC822), en este caso, tal y como se pedía, el servidor de mapas del MTC devuelve una imagen en formato GIF. 10

Segundo ejemplo: una serie de transacciones OAI-PMH. Veamos en detalle cómo funciona OAI-PMH, usando como ejemplo el repositorio de artículos científicos arxiv.org. Empecemos por pedir de listado de formatos de metadata utilizando OAI-PMH: 1. El cliente envía la petición definida por una URL GET http://arxiv.org/oai2?verb=listmetadataformats HTTP/1.0 En este caso la petición es relativamente simple: solamente se da un parámetro, el verbo ListMetadataFormats, al cual según el protocolo OAI-PMH el servidor debe responder con una lista de formatos de metadata empleados en este servidor. 2. El servidor responde con un archivo XML encapsulado en MIME <OAI-PMH xsi:schemalocation="http://www.openarchives.org/oai/2.0/ http://www.openarchives.org/oai/2.0/oai-pmh.xsd"> <responsedate>2006-12-13t01:25:06z</responsedate> <request verb="listmetadataformats">http://arxiv.org/oai2</request> <ListMetadataFormats> <metadataformat> <metadataprefix>oai_dc</metadataprefix> <schema>http://www.openarchives.org/oai/2.0/oai_dc.xsd</schema> <metadatanamespace>http://www.openarchives.org/oai/2.0/oai_dc/</metada tanamespace> </metadataformat> <metadataformat> <metadataprefix>arxiv</metadataprefix> <schema>http://arxiv.org/oai/arxiv.xsd</schema> <metadatanamespace>http://arxiv.org/oai/arxiv/</metadatanamespace> </metadataformat> </ListMetadataFormats> </OAI-PMH> A partir de aquí es responsabilidad del cliente decidir qué hacer con estos datos obtenidos. Por ejemplo, dentro de una nueva transacción, el cliente puede solicitar todos los registros que corresponden a un esquema particular de metadatos, de los dos que reportó utilizar el servidor (oai_dc y arxiv): GET http://arxiv.org/oai2?verb=listidentifiers&metadataprefix=oai_dc HTTP/1.0 La respuesta a esta petición es un listado (gigantesco en el caso de arxiv.org) de registros. La parte inicial es: <OAI-PMH xsi:schemalocation="http://www.openarchives.org/oai/2.0/ http://www.openarchives.org/oai/2.0/oai-pmh.xsd"> <responsedate>2006-12-13t01:36:56z</responsedate> <request verb="listidentifiers" metadataprefix="oai_dc">http://arxiv.org/oai2</request> <ListIdentifiers> <header status="deleted"> <identifier>oai:arxiv.org:alg-geom/9311009</identifier> <datestamp>2005-04-02</datestamp> <setspec>math</setspec> </header> <header status="deleted"> <identifier>oai:arxiv.org:astro-ph/0010130</identifier> <datestamp>2005-04-02</datestamp> <setspec>physics:astro-ph</setspec> </header>... A partir de aquí, el cliente puede decidir, por ejemplo, revisar un registro particular: GET http://arxiv.org/oai2?verb=getrecord&identifier=oai:arxiv. org:astro-ph/0011444&metadataprefix=oai_dc HTTP/1.0 11

A lo cual el servidor responde con los campos de metadatos Dublin Core (puesto que la petición especifica metadataprefix=oai_dc) del registro especificado: <OAI-PMH xsi:schemalocation="http://www.openarchives.org/oai/2.0/ http://www.openarchives.org/oai/2.0/oai-pmh.xsd"> <responsedate>2006-12-13t01:42:54z</responsedate> <request verb="getrecord" identifier="oai:arxiv.org:astro-ph/0011444" metadataprefix="oai_dc">http://arxiv.org/oai2</request> <GetRecord> <record> <header> <identifier>oai:arxiv.org:astro-ph/0011444</identifier> <datestamp>2005-09-18</datestamp> <setspec>physics:astro-ph</setspec> </header> <metadata> <oai_dc:dc xsi:schemalocation="http://www.openarchives.org/oai/2.0/oai_dc/ http://www.openarchives.org/oai/2.0/oai_dc.xsd"> <dc:title> Issues and methods for CMB anisotropy data reduction </dc:title> <dc:creator>delabrouille, J.</dc:creator> <dc:subject>astrophysics</dc:subject> <dc:description> Major issues and existing methods for the reduction of CMB anisotropy data are reviewed. An emphasis is put on the proper modelling of the data. It is suggested that the robustness of methods could be improved by taking into account the uncertainty of the model for finding optimal solutions. </dc:description> <dc:description> Comment: 12 pages, 4 figures, submitted to New Astronomy Reviews </dc:description> <dc:date>2000-11-23</dc:date> <dc:type>text</dc:type> <dc:identifier>http://arxiv.org/abs/astroph/0011444</dc:identifier> <dc:identifier>new Astron.Rev. 45 (2001) 313-320</dc:identifier> </oai_dc:dc> </metadata> </record> </GetRecord> </OAI-PMH> SOAP En la familia de servicios web basados en SOAP, tanto la petición como su respuesta están dadas en formato XML empleando el esquema de encapsulado SOAP. (Inicialmente SOAP era el acrónimo de Protocolo Simple de Acceso a Objetos, pero hoy ya no se lo considera como tal.) Este es el ejemplo de comunicación SOAP de wikipedia: Solicitud del cliente, enviada como parte de una solicitud HTTP POST (la solicitud GET se emplea igual que en REST, con todos los parámetros dentro de la URL). <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <getproductdetails xmlns="http://warehouse.example.com/ws"> <productid>827635</productid> </getproductdetails> </soap:body> </soap:envelope> En este caso, getproductdetails es una solicitud propia de la aplicación, y está establecida en la definición del protocolo y de la aplicación misma. Esta sería la respuesta del proveedor, también por HTTP: 12

<soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <getproductdetailsresponse xmlns="http://warehouse.example.com/ws"> <getproductdetailsresult> <productname>toptimate 3-Piece Set</productName> <productid>827635</productid> <description>3-piece luggage set. Black Polyester.</description> <price>96.50</price> <instock>true</instock> </getproductdetailsresult> </getproductdetailsresponse> </soap:body> </soap:envelope> Donde todos los parámetros son igualmente propios a la aplicación. XML-RPC Es el acrónimo de XML-Remote Procedure Call, o llamado a proedimiento remoto por XML. Encapsula llamados a funciones remotas utilizando una representación del flujo de datos en XML. Igual que para SOAP, se emplea HTTP como protocolo de transmisión. De hecho, XML-RPC es un ancestro de SOAP. Solamente hay dos elementos de primer nivel: methodcall y methodresponse; no hay un encabezado como en SOAP, y los datos que se transmiten tienen un número definido y fijo de tipos, correspondientes a los tipos básicos de los lenguajes de programación. Es en definitiva un tipo de servicio web de mucho más bajo nivel en general que REST o SOAP. De los tres, SOAP es el menos utilizado, tal vez por la complejidad de implementación frente a los otros dos. OAI-PMH OAI-PMH (Open Access Initiative Protocol for Metadata Harvesting) es un protocolo general para recopilar (no para buscar) metadatos. Los repositorios que emplean OAI-PMH ponen a disposición sus catálogos bajo este protocolo para que los mismos puedan ser recuperados in toto o actualizados por clientes sobre los cuales recae la responsabilidad de efectuar búsquedas. OAI-PMH está basado en un esquema REST de servicios web, es un protocolo simple del cual existen varias implementaciones en software libre. El protocolo es aceptado como estándar por un sinnúmero de proyectos de desarrollo y de organización, y parece dentro del maremagnum de opciones, uno de los pocos estándares realmente estándar, a pesar de su aparición relativamente reciente (el estándar 1.0 se definió en el 2001). En OIA-PMH como servicio web REST, existe un número reducido de peticiones, especificado por verbos: verbo GetRecord Identify ListIdentifiers descripción Obtiene un registro particular identificado por un código propio a cada repositorio de metadatos Obtiene una descripción de las características de un repositorio Lista todos los encabezados de todos o parte de los registros de un repositorio; el único filtro posible es por categorías (si el repositorio está organizado en categorías) y por fechas de 13

verbo descripción ListRecords datos Lista los contenidos de todos los registros, contrariamente a ListIdentifiers que sólo devuelve los enabezados respectivos ListMetadataFormaDevuelve la lista de formatos de metadatos con que trabaja el ts repositorio; para ser compatible con OAI-PMH en versión 2, todo repositorio debe poder emplear Dublin Core ListSets Los set son categorías de registros, de acuerdo a criterios del repositorio; el verbo ListSets permite obtener la lista de categorías del repositorio Como se deriva de esta descripción somera, el protocolo OAI-PMH permite acceder a un repositorio, obtener elementos que permiten discernir la forma del archivo, incluyendo los esquemas de metadatos que maneja y luego obtener listados de registros y registros particulares. Está luego diseñado para permitir el intercambio y la actualización conjunta de repositorios diversos. No es un protocolo de búsqueda, como lo puede ser Z39.50 o SRU/SRW para datos de obras, o OGC CSW para datos geográficos. Dublin Core Dublin Core define un conjunto mínimo de quince elementos para catalogar esencialmente cualquier tipo de obra. Esto es el Dublin Core Element Set. La versión 1.1 del DCES es objeto de la norma ISO15836-2003. El grupo denominado Dublin Core Metadata Initiative o DCMI es el responsable de liderar los esfuerzos en torno al estándar. Los elementos del Dublin Core son (adaptado de la traducción de Javier Masa de RedIRIS del documento oficial de definición): Tipo Nombre Descripción Etiqueta Contenido Título Claves Descripción Fuente Lengua Relación el nombre dado a un recurso, habitualmente por el DC.Title autor los tópicos del recurso. Típicamente, Subject expresará las claves o frases que describen el título o el contenido del recurso. Se fomentará el uso de DC.Subject vocabularios controlados y de sistemas de clasificación formales una descripción textual del recurso. Puede ser un resumen en el caso de un documento o una DC.Description descripción del contenido en el caso de un documento visual secuencia de caracteres usados para identificar unívocamente un trabajo a partir del cual proviene el DC.Source recurso actual lengua/s del contenido intelectual del recurso; se recomienda el uso de ISO639 e ISO3166 según DC.Language RFC3066, por ejemplo es-pe para castellano en Perú es un identificador de un segundo recurso y su relación con el recurso actual. Este elemento permite enlazar los recursos relacionados y las descripciones de los recursos DC.Relation 14

Tipo Nombre Descripción Etiqueta Propiedad Intelectual Instanciación Cobertura Autor o Creador Editor Otros Colaboradores Derechos Fecha Tipo del Recurso Formato Identificador del Recurso es la característica de cobertura espacial y/o temporal del contenido intelectual del recurso. La cobertura espacial se refiere a una región física, utilizando por ejemplo coordenadas. La cobertura temporal se refiere al contenido del recurso, no a cuándo fue creado (que ya lo encontramos en el elemento Date) la persona o organización responsable de la creación del contenido intelectual del recurso. Por ejemplo, los autores en el caso de documentos escritos; artistas, fotógrafos e ilustradores en el caso de recursos visuales la entidad responsable de hacer que el recurso se encuentre disponible en la red en su formato actual DC.Coverage DC.Creator DC.Publisher una persona u organización que haya tenido una contribución intelectual significativa, pero que esta sea secundaria en comparación con las de las personas u DC.Contributor organizaciones especificadas en el elemento Creator. (por ejemplo: editor, ilustrador y traductor) son una referencia (por ejemplo, una URL) para una nota sobre derechos de autor, para un servicio de gestión de derechos o para un servicio que dará información sobre términos y condiciones de acceso a un recurso DC.Rights fecha en la cual el recurso se puso a disposición del usuario en su forma actual. Esta fecha no se tiene que confundir con la que pertenece al elemento Coverage, que estaría asociada con el recurso en la medida que DC.Date el contenido intelectual está de alguna manera relacionado con aquella fecha; se recomienda usar ISO8601 para fechas, por ejemplo 2006-12-08 para el 8 de diciembre del 2006 la categoría del recurso. Por ejemplo, página personal, DC.Type romance, poema, diccionario, etc. es el formato de datos de un recurso, usado para identificar el software y, posiblemente, el hardware DC.Format que se necesitaría para mostrar el recurso secuencia de carácteres utilizados para identificar unívocamente un recurso. Ejemplos para recursos en línea pueden ser URLs, DOI, CNRI Handles ó URNs. Para otros recursos pueden ser usados otros formatos de identificadores, como por ejemplo ISBN, ISSN,... DC.Identifier Nótese que si bien los elementos y sus etiquetas están claramente establecidos, los descriptores a usarse dentro de cada uno son libres y variables según el recurso al que refieren. Existe entonces una multitud de tesauros, estándares, idiomas y codificadores para estos decriptores. Por otro lado, Dublin Core solamente define la lista de elementos, y no el formato de los mismos. El estándar permite repeticiones de varios elementos. DC-XML, la definición de la representación de Dublin Core en XML, trata de fijar las posibilidades de repetición y codificación. Igualmente existen representaciones oficiales de 15

Dublin Core en formato RDF. Sistemas de biblioteca digital Existe, desarrollada desde los años noventas, una oferta variada de aplicaciones de biblioteca digital, tanto en software libre como propietario. Entre los productos más notables por su nivel de penetración encontramos GNU eprints y Dspace. Estos sistemas presentan características similares a las del sistema EIMS desarrollado por FAO. Los sistemas actuales de Gestión de contenidos (Content Management Systems o CMS) como Plone y Joomla! y las plataformas de aprendizaje virtual (como Moodle) se integran además al movimiento OAI y soportan nativamente o con aditivos por lo menos OAI-PMH. Sin embargo, lo esencial de las aplicaciones orientadas a bibliotecas virtuales son aplicaciones instaladas durante la década de los ochenta, y en especial el sistema ISIS. Existe por lo tanto una oferta tecnológica inmensa, de libre acceso y libre uso. Los problemas inmediatos son por lo tanto: 1. La elección de una plataforma, dada la elección previa de estándares de contenido y procedimientos de trabajo 2. La migración de los sistemas existentes a la plataforma y los estándares definidos Al respecto, Agrored Perú deberá incidir esencialmente en la caracterización de la oferta existente; su mejora o adaptación a requerimientos particulares de Agrored Perú (lo cual es posible en sistemas de software libre); la capacitación en el empleo de las herramientas; y el apoyo técnico y estratégico para la migración. ISIS ISIS es un sistema de gestión de bases de datos estructuradas, orientado al mantenimiento de bases bibliográficas. Fue originalmente desarrollado por la OIT en la segunda mitad de los setentas, y luego el mantenimiento pasó a manos de UNESCO. Diseñado inicialmente como un sistema monopuesto, fue complementado por BIREME para poder ser accesible desde la Web, dando el actual sistema WebISIS, empleado para la consulta en línea de los catálogos de la BAN, por ejemplo. ISIS almacena los metadatos en un formato propietario, de acuerdo a un esquema de definición parametrable, en un fichero local de la máquina en que se ingresan los datos. Esta flexibilidad es una de las dificultades principales a la hora de tratar de hacerlo interoperar con otros sistemas, ya que las bases construidas con ISIS no necesariamente corresponden a alguno de los estándares de metadatos en uso en tras instituciones. Cuando mínimo, es necesario establecer la correspondencia entre Dublin Core y los campos definidos en cada base. Existen dos líneas de trabajo para hacer interoperar bases ISIS. La primera, estática, consiste en compartir los ficheros de datos. Este es el esquema empleado por la REBIAPE: cada biblioteca mantiene su propio archivo ISIS, y periódicamente cada entidad envía su fichero a la BAN, que los centraliza y permite interrogar todas las bases. La versión más moderna de este esquema consiste en utilizar una exportación a XML (en dos etapas en general: primero a texto luego a XML) para que pueda ser aprovechada en tanto Repositorio Estático OAI y compartida a través de OAI-PMH. La segunda línea, dinámica de trabajo consiste en construir 16

interfaces para el acceso directo a los ficheros a través de protocolos de más alto nivel, tipo OAI-PMH ó Z39.50. Existen soluciones en software libre para facilitar ambos esquemas de interoperación de bases ISIS preexistentes. Dentro de una estrategia de migración, hay dos posibilidades de trabajo. La primera es seguir empleando internamente el flujo de trabajo existente y las herramientas ISIS, y emplear una interface estática o dinámica para interoperar con otros repositorios. La segunda consiste en migrar la base de datos a un nuevo sistema, que reemplazará a ISIS. Este nuevo sistema alternativo debe presentar características suficientemente avanzadas y mejoradas con respecto a ISIS para vencer la barrera del cambio tecnológico y la inercia organizacional. Estado de implementaciones en Perú Según el registro de eprints, hay cuatro puntos para Perú sirviendo catálogos en OAI-PMH, cibertesis en San Marcos, la UDP (en prueba probablemente: sólo hay tres registros disponibles), el Instituto Francés de Investigación sobre los Países Andinos y el servidor SciELO de concytec. Cibertesis utiliza el sistema cyberdocs; UNMSM lo tiene activo y lo está alimentando. La BAN y la REBIAPE emplean WinISIS, la versión de ISIS desarrollada para funcionar en el sistema operativo Windows. La interface de búsqueda es WebISIS. La federación de bases de datos se realiza en forma manual, intercambiando archivos estáticos de bases bibliográficas. No se ha instalado interfaces para OAI- PMH. La segunda fase de esta consultoría permitirá ampliar y detallar a cabalidad este horizonte de estado de implementación, así como definir las formas tecnológicas de adecuación a las normas idóneas para Agrored Perú. 17