Evaluación de Tecnologías y Esquemas de Metadatos para la Aplicación de Ley de Interoperabilidad en Venezuela Parte III

Evaluación de Esquemas de Metadatos para la Aplicación de Ley de Interoperabilidad en Venezuela por http://josealfredomedina.blogspot.com/2013/04/evaluacion-de-gestores-de-repositorios.html se encuentra bajo una Licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.

Saludos, retomando el hilo de los repositorios Institucionales, continuo comentando y mostrando mi evaluación con respecto a los protocolos de Interoperabilidad para Repositorios Institucionales

Protocolos de Interoperabilidad para Repositorios Institucionales 

Según indica que The Open Archives Initiative, OIA-PMH es un protocolo desarrollado por la Iniciativa de Archivos Abiertos. Se utiliza para cosechar (o recoger) las descripciones de metadatos de los registros en un archivo para que los servicios se pueden construir usando los metadatos de los archivos de muchos. Una implementación del protocolo OAI-PMH debe admitir que representa los metadatos de Dublin Core, pero también puede usar representaciones adicionales. El protocolo es por lo general sólo se refiere como el Protocolo OAI. Cabe mencionar que OAI-PMH utiliza XML sobre HTTP. La versión actual es la 2.0, actualizada en 2008.

Este protocolo, se basa en una arquitectura cliente-servidor, en el que "cosechadores" solicitan información sobre los registros actualizados de "repositorios". Las solicitudes de datos pueden basarse en intervalos de fecha y se puede limitar a los conjuntos con nombre definidas por el proveedor. Los proveedores de datos deben proporcionar metadatos XML en formato Dublin Core, y también puede proporcionar en otros formatos XML. En el mismo orden de ideas, es importante señalar que un número de sistemas de software compatible con el protocolo OAI-PMH, incluyendo Fedora Commons, GNU EPrints de la Universidad de Southampton, Open Journal Systems del Public Knowledge Project, Desire2Learn, DSpace de MIT, HyperJournal de la Universidad de Pisa, Primo, DigiTool, Rosetta y MetaLib de Ex Libris, PUERTA de la eLab en Lugano, Suiza, panFMP del PANGAEA (para datos de biblioteca), SimpleDL de Roaring Development y jOAI.

En otro orden de ideas, señala Wikipedia en enero del 2013, el cual es un protocolo Z39.50, el cual es orientado al modelo cliente-servidor dirigido a facilitar la búsqueda y recuperación de información en distintos sistemas a través de una misma interfaz. Su aplicación en el mundo de las bibliotecas y de los centros de documentación permite la consulta de recursos distribuidos en distintas bases de datos, desde un mismo punto de acceso. Es importante destacar que este protocolo está cubierto por el estándar ANSI/NISO Z39.50 y el estándar ISO 23950. Por otro lado, existen diferentes API's y software desarrollado que facilita la implementación de este protocolo, tal como Mercury Z39.50, Zebra, PHP/YAZ Toolkit entre otros.

Según el Boletin de la SEDIC – “DOSSIER 2 ABC del Z”, “Los servicios. Los servicios o facilidades principales del estándar son:

1. La inicialización, precursora del trabajo real, en la que se establecen los parámetros básicos de la sesión que se va a iniciar entre el cliente y el servidor. Esta negociación incluye la versión del protocolo, las operaciones que podrán efectuarse, juegos de caracteres, lenguas, segmentación y tamaño de la información, etc. Permite asimismo la autenticación del usuario.

2. La búsqueda, funcionalidad más importante del estándar, que permite realizar búsquedas simples o complejas con la misma herramienta a múltiples bases de datos, agilizando la recuperación de información. Los parámetros de búsqueda, en el caso de los registros bibliográficos, están definidos en el set de atributos. Las estrategias de búsqueda pueden utilizar operadores booleanos, de proximidad, entre otros, etc.

3. La recuperación de la información: una vez realizada la búsqueda, el cliente solicita al servidor los registros que quiere visualizar, que dependiendo del número solicitado, podrán aparecer segmentados en conjuntos de registros.

Nació hace dos décadas como protocolo para la recuperación de información bibliográfica en el seno del Linked Systems Project y llega a su mayoría de edad reconocido como norma internacional ISO 23950. Su aplicación es ahora mucho más amplia; sigue incluyendo la consulta y el intercambio de datos bibliográficos, pero también la intercomunicación de índices y resúmenes, de información geoespacial, de documentos oficiales, de objetos digitales o de metadatos que describen los documentos de las bibliotecas electrónicas o digitales. ”

La revista ARIADNE(consultada en enero de 2013), señala que SWORD (Simple Web-service Offering Repository Deposit) es impulsado por un pequeño grupo de trabajo en el marco del Programa de JISC para Repositorios Digitales. Por ser una aplicación ligera para servicios web en cuatro principales plataformas de repositorios de software: EPrints, DSpace, Fedora y IntraLibrary.

Existen muchos casos de uso para este protocolo, sin embargo la implemtación mas comun es depositar de manera remota recursos en sistemas académicos. Estos incluyen:

• Depositar en múltiples repositorios al mismo tiempo.
• Depósito de un cliente de escritorio (en lugar de en el sistema de repositorio mismo)
• Depósito con sistemas de terceros (por ejemplo, equipos de laboratorio automatizado)
• Repositorio de depósito a depósito

Según Wikipedia, (consultada en enero de 2013), SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Es uno de los protocolos utilizados en los servicios Web. SOAP puede formar la capa base de una "pila de protocolo de web service", ofreciendo un framework de mensajeria básica en la cual los web services se puedan construir. Este protocolo basado en XML consiste de tres partes: un sobre (envelope), el cual define qué hay en el mensaje y cómo procesarlo; un conjunto de reglas de codificación para expresar instancias de tipos de datos; y una conversión para representar llamadas a procedimientos y respuestas. El protocolo SOAP tiene tres características principales:

• Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desarrollo).
• Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de transporte como HTTP, SMTP, TCP o JMS).
• Independencia (SOAP permite cualquier modelo de programación).

Como ejemplo de cómo los procedimientos SOAP pueden ser utilizados, un mensaje SOAP podría ser enviado a un sitio Web que tiene habilitado Web service, para realizar la búsqueda de algún precio en una base de datos, indicando los parámetros necesitados en la consulta. El sitio podría retornar un documento formateado en XML con el resultado, ejemplo, precios, localización, características. Teniendo los datos de respuesta en un formato estandarizado "parseable", este puede ser integrado directamente en un sitio Web o aplicación externa. os desarrolladores de aplicaciones hoy en día, pueden utilizar la infraestructura de correo electrónico de Internet para transmitir mensajes SOAP ya sean como mensajes de correo electrónico de texto o como adjuntos. Los ejemplos que se muestran a continuación muestran un modo de transmitir mensajes SOAP, y deben ser tomados como el modo estándar de hacerlo. Las especificaciones SOAP Versión 1.2 no especifican tal vínculo. Sin embargo, existe una Nota W3C no-normativa [SOAP Email Binding] que describe un vínculo de SOAP con el correo electrónico. Su propósito principal es comenzar a demostrar la aplicación de la Infraestructura general de Vínculos con el Protocolo SOAP.

Otra protocolo que es usado en el entorno de las bibliotecas es REST, según indica Hevia (consultado en enero de 2013), “ el estilo arquitectónico REST fue desarrollado por el Grupo de Arquitectura Técnica del W3C en paralelo con HTTP/1.1, basado en el diseño existente de HTTP/1.0. La World Wide Web representa la mayor implementación de un sistema de conforme al estilo arquitectónico REST. REST es un ejemplo de cómo la arquitectura de la Web surgió por caracterizar y limitar las interacciones macro-de los cuatro componentes de la red, es decir, los servidores de origen, gateways, proxies y clientes, sin imponer limitaciones a los participantes individuales. Como tal, REST fundamentalmente gobierna el comportamiento adecuado de los participantes.

Los principales objetivos de REST son:

• La escalabilidad de las interacciones entre componentes
• La generalidad de las interfaces
• Despliegue independiente de los componentes
• Componentes intermedios para reducir la latencia, reforzar la seguridad y encapsular los sistemas heredados”

Comparación de Protocolos de Interoperabilidad de Metadatos

Esta comparación se basa en cinco (5) principios de SOA que Gartner establece para evaluar la calidad de un SOA. Los cuales se detallan a continuación:

“Modular

Incide sobre el concepto “clásico” de bajo acoplamiento y máxima cohesión de los módulos de software. Cada módulo tiene una misión que desempeñar y hace posible que se puedan construir módulos más complejos en base a otros más simples.

Distribuible

Los servicios de negocio se pueden distribuir en varias localizaciones físicas. Para el consumidor del servicio debe ser transparente dónde está el servicio que quiere invocar (en qué máquina). No sólo se puede invocar a un servicio independientemente de su localización física, si no también de la tecnología empleada en su construcción (y la del consumidor) el sistema operativo, etc, etc.

Claramente definido

El servicio define un contrato con el cliente donde se indica los parámetros de entrada y de salida. Respetando este contrato con el exterior, la implementación interna del servicio puede cambiar sin afectar al cliente (es una caja negra). Este papel lo juega el fichero WSDL en los servicios web.

Intercambiables

Este principio tiene mucha relación con el anterior, ya que al tener que mantener únicamente el contrato con el consumidor, la implementación interna del servicio puede cambiar complementamente sin tener siquiera que decírselo al mismo. Se consigue separar la implementación, del contrato o metadata. Esto da mucha flexibilidad en la evolución del consumidor y del servicio ya que pueden hacerlo de manera independiente.

Compartibles

El mismo servicio puede ser consumido por diferentes personas, departamentos o incluso diferentes compañías. Por lo tanto, en el diseño de los servicios, hay que hacer hincapié en que el consumidor puede ser de muy diferentes tipos. Por ejemplo, no se puede pensar que lo va a consumir un interfaz de usuario (frontal) e incluir en el mismo información para el formateado en pantalla. Por otra parte, se favorece la economía de escala ya que el servicio se implementa una sola vez y se puede consumir miles de veces por decenas de clientes diferentes.”

Adicionalmente se coloca a la comparación el principio de Autenticación, el cual se refiere a que el usuario que desee conectarse debe pasar por una capa para verificar su identidad y otorgarle acceso o no a los recursos digitales resguardados.

En la siguiente table se muestra la comparación:

Tabla 11: Comparación de protocolos de Interoperabilidad de Metadatos

Nombre	Modular	Distribuible	Claramente Definido	Intercambiables	Compartible	Seguridad
OIA-PMH	Si	Si	Si	Si	Si	No
Z39.50	Si	Si	Si	Si	Si	No
SWORD	Si	Si	Si	Si	Si	No
REST	Si	Si	Si	Si	Si	No
SOAP	Si	Si	Si	Si	Si	Si

Evaluación de Protocolos de Interoperabilidad de Metadatos

La evaluación de Protocolos de Interoperabilidad de Metadatos se realizará bajo la siguiente manera:

• La puntuación máxima a obtener sera de cien (100) puntos,
• Serán considerados los siguientes principios para la evaluación, Modularidad, Distribuible, Definición, Compartible y la Seguridad implementada,
• En caso de que el protocolo cuente con el principio “Modular”, este obtendrá diez y seis (16) puntos, en el caso de que no se cuente con este, se otorgará cero (0) puntos;
• En caso de que el protocolo cuente con el principio “Distribuible”, este obtendrá diez y seis (16) puntos, en el caso de que no se cuente con este, se otorgará cero (0) puntos;
• En caso de que el protocolo cuente con el principio “Claramente Definido”, este obtendrá diez y seis (16) puntos, en el caso de que no se cuente con este, se otorgará cero (0) puntos;
• En caso de que el protocolo cuente con el principio “Intercambiables”, este obtendrá diez y seis (16) puntos, en el caso de que no se cuente con este, se otorgará cero (0) puntos;
• En caso de que el protocolo cuente con el principio “Autenticación”, este obtendrá diez y seis (20) puntos, en el caso de que no se cuente con este, se otorgará cero (0) puntos;
  Tabla 12: Evaluación de protocolos de Interoperabilidad de Metadatos

Nombre	OIA-PMH	Z39.50	SWORD	REST	SOA
Modular	16	16	16	16	16
Distribuible	16	16	16	16	16
Claramente Definido	16	16	16	16	16
Intercambiables	16	16	16	16	16
Compartible	16	16	16	16	16
Autenticación	0	0	0	0	60
Total	80	80	80	80	100

Evaluación de Esquemas de Metadatos para la Aplicación de Ley de Interoperabilidad en Venezuela por http://josealfredomedina.blogspot.com/2013/04/evaluacion-de-gestores-de-repositorios.html se encuentra bajo una Licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.