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.

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

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.

Siguiendo el tema de la publicación anterior acerca de la Evaluación de los esquemas de Metadatos parte I utilizados en otras partes del mundo en el tema de gobierno electrónico o gobierno de gestión electrónica.Para la siguiente evaluación se realizara con los siguientes criterios:

• Cada característica a evaluar tiene una ponderación de 25 puntos, donde la máxima puntuación para el esquema de metadatos es de 100 puntos.
• El criterio “Experiencias en aplicabilidad al Gobierno electrónico”, se evaluara de la siguiente manera:
  • Si identifica que no hay experiencia internacional en cuando a la aplicabilidad de este esquema de metadatos se otorgaran 0 puntos;
  • Si existe de una (1) a cinco (5) experiencias internacionales en cuando a la aplicabilidad de este esquema de metadatos se otorgara 15 puntos;
  • Si existen mas cinco (5) experiencias internacionales en cuando a la aplicabilidad de este esquema de metadatos se otorgara 25 puntos;
• El criterio de “Estandarización Internacional”, se evaluara de la siguiente manera:
  • Si no cuenta con aval o validación internacional por la ISO, ANSI, IEEE o ente similar, se otorgara 0 puntos;
  • Si es una derivación de un estandar internacional, se otorgara 10 puntos;
  • Si cuenta con con aval o validación internacional por la ISO, ANSI, IEEE o ente similar, se otorgara 25 puntos;
• El criterio de compatibilidad XML, se evaluara de la siguiente manera:
  • Si no existe posibilidad o experiencia en la implementación de este esquema de metadatos con XML, se otorgara 0 puntos;
  • Si existe posibilidad o experiencia en la implementación de este esquema de metadatos con XML, se otorgara 25 puntos;
• El criterio de “Grado de Descripción”, se evaluara de la siguiente manera:
  • Si el grado de descripción de recurso u objeto digital es bajo, se otorgara 5 puntos;
  • Si el grado de descripción de recurso u objeto digital es medio, se otorgara 15 puntos;
  • Si el grado de descripción de recurso u objeto digital es alto, se otorgara 25 puntos;

Tabla10: Evaluación de Esquemas de Metadatos

Criterio	Dublin Core	MODS	MARC	eGMS	AGLS	Canadian Metadata Standard	IGMS	DRIVER
Experiencias en aplicabilidad al Gobierno electrónico	15	0	0	15	15	15	15	0
Estandarización Internacional	25	10	10	10	10	10	10	10
Compatibilidad con XML	25	25	25	25	25	25	25	25
Grado de descripción	15	5	25	25	25	15	15	25
Total	80	40	60	75	75	75	65	60

Sin embargo del resultado del que el mas ventajoso es DublinCore, sugiero tener en consideración el esquema eGMS el cual en mi opinión es posible agregar mas descripción a los objetos digitales que se intercambiaran.

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.

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

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

 A fin de realizar apoyar a la implementación de la Ley de Interoperabilidad de la legislación de la República Bolivariana de Venezuela, se presenta este estudio con el espíritu de aprovechar los servicios y tecnologías desarrolladas para el sector Bibliotecario – Académico - Científico y considerar su posible aplicación al gobierno electrónico. Cabe destacar que el sector bibliotecario implementa Interoperabilidad desde hace varios años. En ese sentido, se mostraran herramientas y evaluaciones sobre estas en las áreas de Integración, Interoperabilidad técnico-semántica, semántica; todo esto planteado y basado en la utilización de estándares abiertos y el uso de software libre y de software de fuentes abiertas para repositorios digitales e Interoperabilidad. En ese sentido, este documento esta dirigido a personas a profesionales de la informática, computación y carreras afines. 

Quisiera destacar, que los criterios de esta evaluación puede considerados validos en el caso de implementar bibliotecas digitales.

Cabe destacar que el sector bibliotecario implementa Interoperabilidad desde hace varios años. En ese sentido, se mostraran herramientas y evaluaciones sobre estas en las áreas de Integración, Interoperabilidad técnico-semántica, semántica; todo esto planteado y basado en la utilización de estándares abiertos y el uso de software libre y de software de fuentes abiertas para repositorios digitales e Interoperabilidad. En ese sentido, este documento esta dirigido a personas a profesionales de la informática, computación y carreras afines.

A grandes rasgos, cuando hablamos de repositorios digitales o sistemas de gestión de contenido(SGC), debemos hablar de los componentes que lo conforman y las tecnologías asociadas a ellos. En ese sentido, son:

• Interfaz para añadir el contenido al sistema.
• Interfaz para buscar / comprobar / recuperar contenido
• Base de datos para almacenar contenido
• Interfaz administrativa para apoyar la gestión de las colecciones y las actuaciones de conservación.
• Una característica individual puede ser la integración con otros sistemas.

Ferrer en el 2005 [1], señala que los repositorios son componentes esenciales de las bibliotecas digitales, en ese orden de ideas, el sector académico Académico - Científico utiliza repositorios digitales desde hace algunos años con el fin de divulgar y maximizar la accesibilidad a información científica.

En los inicios de esta tecnologías se utilizaban simples indexadores o 'parsers' para realizar la consulta y recuperación los objetos digitales contentivos de información científica solicitada por el usuario final. Con la amplia implantación de la tecnología WEB, donde el sector mencionado no fue la excepción, se empezó a utilizar con la finalidad de mejorar no solo proceso de consulta y recuperación con el uso de Internet, si no que también mejorar las tareas de administración y preservación de los documentos académicos y científicos. A continuación se presenta un esquema de un repositorio digital dinámico:

Imagen 1. Repositorio Digital Dinámico. Fuente: Dspace Traducción: Cenit - DIDI

En el mismo orden de ideas, es importante tener en cuenta al momento de hablar de SGC considerar las siguientes características:

• Apoyo a formatos de archivo: texto, imágenes, conjuntos de datos, video, audio, etc.
• Estándares de metadatos (descriptivo, técnico, de conservación, derechos).
• Interoperabilidad: OAI compliance, Z39.50, SRW, etc.
• Dirección o localizador permanente del artículo, ej persistente URL.
• Búsqueda / vista de metadatos.
• Búsqueda de texto completo.
• Volumen de trabajo, aportación para la aprobación del contenido
• Autorización del usuario
• Usuario administrador: proveedor del contenido, editor.
• Usuario final: acceso al contenido.
• Personalización: API (interfaz de aplicación) para personalizar el software, aumentar las características según sea necesario.

Esquemas de Metadatos

Siendo los metadatos y los esquemas de metadatos esenciales para la descripción y clasificación de los objetos digitales e información, para los cuales se han desarrollado diversos estándares los cuales se aplican en el sector académico - científico y gobierno electrónico,tales como Dublin Core, MODs, MARC Standard, EGM, AGLS, NZGLS, IGMS y CLF, siendo las ultimas cinco (5) usadas para gobierno electrónico y basadas en Dublin Core.

Según, Abdurrahman Alasem en el 2009, se describe Dublin Core de la siguiente manera (traducción por José Alfredo Medina): “El Dublin Core Metadata Initiative (DCMI) es el resultado de un taller conjunto celebrado en Dublín, EE.UU., por el Online Computer Library Center (OCLC) y el Centro Nacional de Supercomputación de Aplicación (NCSA) en 1995.

Dublin Core es uno de los estándares de metadatos más utilizados, el cual es reconocido por la Organización Internacional para la Normalización (ISO 15836: 2003). Es un estándar de metadatos sencillo y flexible que se puede utilizar en casi todos los dominios de recursos electrónicos en red. "Las aplicaciones de elementos DC han sido diseñados para cubrir no sólo el tipo de recursos en repositorios de información tradicionales, sino también en la web. Cada elemento es repetible y también puede tener sub-tipos y relaciones de subobjetos. "(Nair. S & V Jeevan., 2004, p 4). Dublin Core simple propone un conjunto de 15 elementos, tal como se muestra en la tabla siguiente.

Tabla 1: Elementos de metadatos DC

Elemento	Definición
Title	El nombre dado al recurso.
Subjet	El tema del contenido del recurso.
Description	Una cuenta del contenido del recurso.
Type	La naturaleza o género del contenido del recurso.
Source	Una referencia a un recurso del que se deriva el recurso actual.
Relation	Una referencia a un recurso relacionado.
Coverage	La extensión o alcance del contenido del recurso.
Creator	Una entidad principal responsable de crear el contenido del recurso.
Publisher	La entidad responsable de los recursos disponibles.
Contributor	La entidad responsable de hacer contribuciones al contenido de la recurso.
Rights	Información sobre los derechos en y sobre el recurso.
Data	Los datos asociados con un evento en el ciclo del recurso.
Format	La manifestación física o digital del recurso.
Identifier	Una referencia clara al recurso en un contexto dado.
Lenguage	Idioma (s) del contenido intelectual del recurso.

Según una consulta al sitio web oficial de MODS en enero de 2013, Metadata Object Description Schema (MODS), es un esquema de un conjunto de elementos bibliográficos que se puede utilizar para una variedad de propósitos, y en particular para las aplicaciones de biblioteca. El estándar es mantenido por la Oficina de Desarrollo de Redes y Normas MARC de la Biblioteca del Congreso de los Estados Unidos de América con la participación de los usuarios. MODS, propone un conjunto de elementos tal como se muestra en la tabla siguiente:

Tabla 2: Elementos de metadatos MODS

Elemento	Descripción
titleInfo	Una palabra, una frase, carácter o grupo de caracteres, que normalmente aparece en un recurso, que nombra las obras contenidas en el mismo.
name	él nombre de una persona, organización o evento (conferencias, reuniones, etc) asociados de alguna manera con el recurso.
typeOfResource	Un término que especifica las características y el tipo general de contenido del recurso.
genre	Término (s) que designa una categoría que caracteriza un determinado estilo, forma o contenido, como artística, composición musical, literario, etc
originInfo	La información sobre el origen de los recursos, incluyendo el lugar de origen o de publicación, editor / autor y fechas asociadas con el recurso
languaje	una designación de la lengua en la que se expresa el contenido de un recurso.
physicalDescription	es un elemento contenedor que contiene todos los subelementos relacionados con la información de la descripción física del recurso descrito. Los datos de entrada es sólo dentro de cada subelemento.
abstract	un resumen del contenido del recurso.
tableOfContents	Una descripción de los contenidos de un recurso.
targetAudience	una descripción del nivel intelectual de la audiencia para la que se destina el recurso
note	información general textual relativa a un recurso.
subject	Un término o frase que representa el principal tema (s) en el que se centra un trabajo.
classification	una designación aplicada a un recurso que indica el sujeto mediante la aplicación de un sistema formal de codificación y organización de recursos en función de las materias.
relatedItem	La información que identifica otros recursos relacionados con el que se está describiendo.
identifier	contiene un número único estándar o un código que identifica un recurso distintivo. Incluye manifestación, de expresión y los identificadores de trabajo de nivel. <identificador> se debe repetir para cada identificador aplicable registrados, incluidos los identificadores no válidos y anulados. Esto es más o menos equivalente a campos MARC 010, 020, 022, 024, 856
location	identifica a la institución o el repositorio contiene el recurso, o en un lugar remoto en la forma de una URL donde se encuentra disponible.
accessCondition	información acerca de las restricciones impuestas sobre el acceso a un recurso.
extension	Es utilizado para proporcionar información adicional no cubierto por MODS. Puede ser utilizado para los elementos que son propios del creador de los datos, similar a 21 campos MARC 9XX. Además, puede ser utilizado para ampliar MODS para diversos fines, cuando otro esquema XML puede manejar el tipo de información.
recordInfo	información sobre el registro de metadatos.

Según una consulta al sitio web Wikipedia la cual se realizo en enero de 2013, se obtuvo que: “MARC es el acrónimo de Machine Readable Cataloging o catalogación legible por máquina, significa que una máquina puede leer e interpretar los datos contenidos en un registro catalográfico en función de una serie de elementos que actúan como “señaladores” de los datos.

Marc 21 es una norma para el intercambio de información que permite estructurar e identificar los datos de tal forma que puedan ser reconocidos y manipulados por computadora. Este formato fue creado por un equipo de bibliotecarios de la Biblioteca del Congreso (EE UU) liderados por Henriette Avram.

Al haber sido diseñado para proveer especificaciones sobre la estructura con que los datos serán comunicados entre sistemas de información cooperantes, no imponen pautas de almacenamiento interno, de visualización, identificación y ni descripción de los datos bibliográficos. Del almacenamiento y la visualización se ocupará el software elegido, en tanto que de la identificación y descripción se encargará el código de catalogación adoptado.

Tabla 3: Elementos de metadatos MARC

Elemento	Descripción
Authority records	Codifica la información contenida en registros de autoridad de nombres, materias y series.
Bibliographic records	Codifica los datos para describir, recuperar y controlar los diferentes tipos de materiales bibliográficos; por ejemplo: libros, publicaciones seriadas, recursos electrónicos, mapas, música, materiales visuales y materiales mixtos.
Classification records	Codifica información contenida en un sistema de clasificación, por ejemplo: CDD, CDU o cualquier otro sistema que se desee automatizar.
Community Information records	Codifica la descripción de recursos no bibliográficos que responden a las necesidades de información de una comunidad, como individuos, organizaciones, programas o servicios, eventos y otros recursos que pueden ayudar a los usuarios a conseguir la información que necesitan.
Holdings records	Codifica información específica, como la signatura topográfica, cantidad de ejemplares y/o volúmenes, instituciones que posee un ítem, etc.

Así mismo, Abdurrahman Alasem en el 2009 describe UK e-Government Metadata Standard (eGMS) de la siguiente manera (traducción por José Alfredo Medina) “ El Reino Unido e-Government Framework Metadata Standard (eGMF) publicó en mayo de 2001, como resultado de varios meses de consulta y planificación que se inició en 1999, "Libro Blanco para la Modernizacióndel Gobierno", era un proyecto a largo plazo para la modernización de los servicios públicos por el Ministerio del Gabinete (Cumming, M,2001). eGMF tuvo como objetivo determinar las políticas del gobierno para la implementación y establecimiento de un estándar de metadatos para el sector público, y que se utiliza en todos los sistemas de información. Para el gobierno británico los metadatos son "un resumen de la forma y el contenido de un recurso" (Oficina del e-Envoy, 2001), el cual se utiliza para apoyar una serie de funciones, como el descubrimiento de recursos, administración, conservación, comercio electrónico y clasificación de contenido (Powell, A., 2000). El primer e-Government estándar de metadatos (EGM) fue desarrollado en 2001. Se basa en el sencillo Dublin Core y tuvo otros seis elementos para cubrir descripción y tratamiento para fines de administración electrónica.

Los seis elementos son: la eliminación; conservación; audiencia, la ubicación con fines de gestión de registros y requisitos de archivo y, la accesibilidad y el estado para el propósito de descubrimiento de recursos. (Coles, C, 2003).

Para el año 2003, la labor se había hecho y era el estándar de metadatos e-Gobierno (EGM), versión 2.0 publicado, que contiene cuatro elementos adicionales de gestión de archivos: destinatario, firma digital, los mandatos;

Tabla 4: Adicional Reino Unido Metadata Element Set EGM (EGM) versión 3.1 (2006).

Elemento	Definición
Accessibility	Indica la disponibilidad del recurso y facilidad de uso a grupos específicos
Addressee	La persona (o personas) a quien se dirige el recurso.
Aggregation	El nivel o posición en una jerarquía de los recursos.
Audience	La categoría de usuario para el que el recurso está destinado.
Firma Digital	La firma digital no se ha decidido.
Disposal	Las instrucciones de retención y disposición de los recursos.
Location	La ubicación física del recurso.
Mandate	Mandato legislativo o de otro tipo en las que se produce el recurso.
Preservation	Información para apoyar la conservación a largo plazo del recurso.
Status	La posición o estado de los recursos.

”

En el mismo orden de ideas, Abdurrahman Alasem en el 2009 describe Australian Government Locator Services (AGLS), de la siguiente manera (traducción José Alfredo Medina): “ Es un estándar desarrollado por el Gobierno australiano, denominado Australian Government Locator Service (AGLS), el cual comenzó en Diciembre de 1997, con la versión 1.0 AGLS en 1998. Para el gobierno australiano los metadatos se define como "información estructurada que se ha creado específicamente para describir otro recursos ". (AGIMO, 2004). Este fue diseñado para mejorar la usabilidad, la accesibilidad y la Interoperabilidad de los servicios de información y servicios del gobierno a través de la provisión de descripción normalizada de los recursos basada en la web

(Wilson, A, 2002).

El estándar de metadatos AGLS se basa en Dublin Core simple y tiene cuatro elementos adicionales diseñados para el contexto australiano, que son función de la disponibilidad de la información gubernamental y servicio de búsqueda, y la audiencia y el mandato para la administración de registros.

Tabla 5: Metadatos AGLS adicional Conjunto de Elementos. versión 2.0 (2006)

Definición	Elemento
Availability	Cómo se puede obtener o información de contacto para obtener. el recurso
Audience	La audiencia del recurso.
Function	La función empresarial de la organización a la que se refiere el recurso.
Mandate	Una garantía específica que requiere el recurso a crear o constituir

Por otro lado, Abdurrahman Alasem en el 2009, describe que New Zealand Government Locator Services (NZGLS) como: “ El estándar de metadatos NZGLS fue recomendado en 1998 por el New Zealand Government Locator Services, que se estableció para sugerir una política común ,estándar y las normas que se utilizarían en todas las agencias del gobierno para mejorar el descubrimiento de información del gobierno de Nueva Zelanda. Como un resultado de 15 meses de consultas y pruebas de usabilidad, el NZMSWG recomienda que el gobierno australiano utilice Australian Government Locator Service (AGLS) con algunos cambios, como la obligación elemento, el refinamiento y esquemas de codificación (Booth, K, 2002). Al igual que los AGLS, el NZGLS tiene cuatro elementos adicionales: función, la disponibilidad, la audiencia y su mandato. El NZGLS fue publicado en 2001 y en mayo de 2002, NZ organismos se requirieron crear un conjunto básico de metadatos que describen su información y servicios. (Booth, K, 2002).

Tabla 6: Metadatos NZGLS adicional Conjunto de Elementos. versión 2.1 (2004)

Elemento	Definición
Function	La función empresarial de la organización a la que se refiere el recurso
Availability	Cómo el recurso puede ser obtenida o información de contacto para obtener. el recurso
Audience	Una clase de entidad para la que está destinado el recurso o es útil.
Mandate	Una orden específica que requiere el recurso a crear o constituir

”

De igual manera, Abdurrahman Alasem en el 2009, indica que “Ireland Government Metadata Standard (IGMS) fue desarrollado en 1999, como resultado de una recomendación presentado por el Grupo de Publicación Web (WPG). El grupo recomendó el uso DC simple con dos elementos adicionales: descriptor de servicio y en la vida evento descriptor (WPG, 1999). ElA MetadataWorkingGroup(MWG) se creó para decidir cuál de metadatos que se adapta al gobierno electrónico de Irlanda, y en 2002, el MWG acordó metadatos del estándar de metadatos propuesto. Se basa DC simple, sin la adición de nuevos elementos

Así mismo, Abdurrahman Alasem en el 2009, indica que el Canadian Metadata Standard fue una estrategia establecida para el desarrollo de un esquema de metadatos dentro de los departamentos o agencias federales. El “Government On-line Metadata Working Group” establecido Metadatos para adoptar un estándar de metadatos común que se usará en la web federal. El grupo estuvo de acuerdo “ Common Look and Feel Metadata Standard (CLF)”, el cual se basa en DC simple con dos elementos adicionales: Audience para fines de gestión de registros, y Keywords para el descubrimiento de recursos. Esto apareció en 2002. (GOMWG,2005).

Tabla 7: CLF canadienses elementos adicionales estándar de metadatos.

Elemento	Definición
Audience	Una clase de entidad para la que se destina el recurso o es útil.
Keywords	Las palabras o frases que sirven como puntos de acceso para los motores de búsqueda

Por otro lado, Driver Support en su sitio oficial consultado en enero de 2013, señala que “ DRIVER, “Digital Repository Infrastructure Vision for European Research” (Visión de infraestructura de repositorios digitales para la investigación europea), es un proyecto realizado por un consorcio financiado por la Unión Europea que está creando un marco de trabajo tecnológico y organizativo para implementar una capa paneuropea de datos, que permita el uso avanzado de los recursos de contenido en el ámbito de la investigación y la educación superior. DRIVER desarrolla una infraestructura de servicios y una infraestructura de datos. Ambas están concebidas para orquestar los recursos y los servicios existentes en la red de repositorios. Básicamente, las directrices se centran en cinco cuestiones: colecciones, metadatos, implementación del protocolo OAI-PMH, prácticas recomendadas y vocabularios y semántica.

Tabla 8: Elementos de metadatos Driver

Elemento	Definición
Title	El nombre dado al recurso. Texto libre
Creator	Una entidad principal responsable de crear el contenido del recurso.
Subject	El tema del contenido del recurso.
Description	Una cuenta del contenido del recurso.
Publisher	La entidad responsable de los recursos disponibles.
Contributor	La entidad responsable de hacer contribuciones al contenido de la recurso.
Data	Fecha | ISO 8601 W3C-DTF - “Published” (Publicado) es la interpretación predeterminada al valor de dc:date
Type	La naturaleza o género del contenido del recurso.
Format	La manifestación física o digital del recurso. Debe ser de la lista registrada para IANA o tipos MIME
Identifier	Una referencia clara al recurso en un contexto dado. URI
Source	Una referencia a un recurso del que se deriva el recurso actual.
Lenguage	Idioma (s) del contenido intelectual del recurso. Debe ser marcado como un ISO
Relation	Una referencia a un recurso relacionado.
Coverage	La extensión o alcance del contenido del recurso.
Rights	Información sobre los derechos en y sobre el recurso.
Audience	Audiencia hacia el que va dirigido el recurso.

Comparación de Esquemas de Metadatos

Si bien es cierto, existe una variedad adicional de esquemas de metadatos con aplicaciones en diversas áreas, solo se estudiaran las aplicadas y/o utilizadas en el entorno bibliotecario y algunos estándares de países como UK, Nueva Zelanda, Australia entre otros, los cuales son utilizados en sus infraestructuras de gobierno electrónico. A fines de presentar una evaluación comparativa, se muestra la siguiente tabla a fin de comparar los criterios que a juicio del elaborador del presente documento pueden considerarse como relevantes para el proyecto nacional de Interoperabilidad:

Tabla 9: Comparación de Esquemas de Metadatos

Nombre	Enfoque	Estandarización ISO/ANSI	Compatibilidad XML	Experiencias de uso en gobierno electrónico	Grado de descripción
Dublin Core	Redes de Datos	ETF RFC 5013 ISO Standard 15836-2009 NISO Standard Z39.85	Si	Si	Medio
Dublin Core	Propósito General	ISO 15836: 2003	Si	Si	Medio
Metadata Object Description Schema (MODS)	Bibliotecario	No	Si	No	Alto
MARC		ISO 2709	Si	No	Bajo
UK e-Government Metadata Standard (eGMS)	Gobierno	No / Implementación de Dublin Core	Si	Si	Alto
Australian Government Locator Services (AGLS)	Gobierno	No/ Implementación de Dublin Core	Si	Si	Alto
New Zealand Government Locator Services (NZGLS)	Gobierno	No / Implementación de Dublin Core	Si	Si	Alto
Ireland Government Metadata Standard (IGMS)	Gobierno	No / Implementación de Dublin Core	Si	Si	Medio
Canadian Metadata Standard	Gobierno	No / Implementación de Dublin Core	Si	Si	Medio
DRIVER, “Digital Repository Infrastructure Vision for European Research	Bibliotecario	No / Implementación de Dublin Core	Si	No	Alto

En la proxima entrega se mostraran criterios para la selección y la evaluación de los Esquemas de Metadatos

_________________________________________________

Referencias

[1] Ferrer, A, (2005) “Los repositorios como componentes esenciales de las bibliotecas digitales: la experiencia de las bibliotecas universitarias de Cataluña (CBUC)”, 3ª Jornada sobre la Biblioteca Digital Universitaria, Córdoba (Argentina), 27-28 de octubre del 2005;

[2] Alasem, A. (2009) “An Overview of e-Government Metadata Standards and Initiatives based on Dublin Core.” Electronic Journal of e-Government Volume 7 Issue 1 2009, pp. 1 - 10, available online at www.ejeg.com; consultado en enero de 2013

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.