Curso Metadatos completo by Patricia Fernández

CURSO METADATOS Y SU APLICACIÓN EN LA DESCRIPCIÓN DE RECURSOS.

MÓDULO 1. CONTEXTOS Y VÍAS DE ACCESO A LA INFORMACIÓN DIGITAL. 1.1. PROBLEMAS ASOCIADOS A LA RECUPERACIÓN EN INTERNET. Si la imprenta de tipos móviles supuso en el siglo XV el fin del monopolio intelectual de una élite, ha sido la red de redes la que ha revolucionado y democratizado de manera definitiva la difusión y el acceso a la información. Nunca antes había sido tan fácil para cualquier ser humano comunicar un mensaje informativo de manera que pudiera ser recibido por un número potencial de receptores tan amplio. Esto ha potenciado el crecimiento exponencial de la Web, generando un vasto cuerpo de conocimiento al que, sin embargo, resulta imposible acceder en su totalidad o con la precisión necesaria. Los sistemas de recuperación implementados hasta el momento (directorios y buscadores, principalmente), basados en técnicas cuyo funcionamiento ha demostrado ser especialmente eficiente en sistemas de información finitos, resultan insuficientes (existe, ciertamente, una “web invisible”) frente al siempre cambiante, siempre inabarcable espacio informativo de la red. Se han propuesto varias metáforas para describir dicho espacio, entre ellas la metáfora de las “islas” y “archipiélagos” de información. La metáfora de las “islas de información”, utilizada desde hace tiempo (por ejemplo, por Atherton en 2002 en el proyecto británico “Seamless UK”), se refiere al hecho de que en la web existan espacios informativos, generalmente organizados en forma de sistemas de información, que se encuentran aislados entre sí, lo que limita la capacidad de recuperación de información. En la actualidad, la principal tendencia es precisamente afrontar el problema de abajo a arriba, es decir, empezando por crear islas, espacios limitados en los que los recursos estén organizados y controlados para, en la medida de lo posible, ir aumentando la red y el tamaño de dichas islas así como sus interconexiones para, finalmente crear espacios informativos conectados cada vez más amplios que posibiliten la implementación de servicios de información digital para la Sociedad del Conocimiento. La clave de este proceso radica en el desarrollo de un conjunto de estándares que regulen todos los aspectos implicados en él, entre los que se encuentran los estándares de metadatos como vía para la óptima descripción de recursos.

1.2. REPOSITORIOS Y BIBLIOTECAS DIGITALES. CONCEPTO Y DIFERENCIACIÓN. Desde que se empezó a hablar de ellas a principios de los años noventa, han aparecido numerosas definiciones de biblioteca digital. A partir de un detallado análisis de las mismas, Borgman (1999) diferenció dos ámbitos de procedencia: •

Las definiciones procedentes del ámbito bibliotecario, que enfatizan el papel de los servicios a los usuarios.

•

Las procedentes del ámbito informático, que ponen su énfasis en el almacenamiento y acceso a los contenidos.

De este doble origen se deriva una doble concepción de biblioteca digital:

•

La biblioteca digital entendida como extensión o evolución de la biblioteca tradicional. Comprende definiciones stricto sensu como las de la Digital Library Federation (DLF, 1998), la UNESCO Digital Library Taskforce.

•

La biblioteca digital entendida como simple almacén o base de datos. Sería, por tanto, la más cercana al concepto de repositorio, y comprende definiciones lato sensu como la del IMS.

En las diferentes definiciones se identifican cuatro dimensiones, que conforman la concepción actual de biblioteca digital: 1. Comunidad. Referida al contexto social, político, legal y cultural en que se desarrolla la biblioteca digital. 2. Tecnología. Considerada el motor de la biblioteca digital, del avance en su desarrollo depende el desarrollo de las potencialidades de la biblioteca digital. 3. Contenido. Referida a cualquier tipo de documentos, tanto digitales como no digitales (lo que alude al concepto de “biblioteca híbrida”). 4. Servicios. El diseño de formas de acceso adecuadas representa la finalidad última de la biblioteca digital, que en el futuro deberá facilitar servicios de referencia digital, respuesta en tiempo real, alfabetización informacional, etc. Entre las instituciones que han promovido su desarrollo se encuentran: • • • •

•

Digital Library Initiative (DLI). Financiada por el gobierno de EE. UU. e iniciada en 1994, actualmente se encuentra en su segunda fase. Digital Library Federation (DLF). Consorcio de instituciones estadounidenses, principalmente académicas. Iniciada en 1995. DELOS Network of Excellence on Digital Libraries. Financiada por la Comisión Europea e iniciada en 2004. Fin previsto: 2008. Online Computer Library Center (OCLC). Entidad sin ánimo de lucro estadounidense fundada en 1967 que ha desarrollado varios proyectos relacionados con bibliotecas digitales. Joint Information Systems Committee (JISC). Organización creada en 1993 para el desarrollo de TIC en Educación.

1.3. BIBLIOGRAFÍA. ATHERTON, L. (2002). Seamless UK: building bridges between information islands. New Library World, vol. 103, n. 11/12, p. 467-474. BORGMAN, C. L. (1999). What are digital libraries? Competing visions. Information Processing and Management, vol. 35, n. 3, p. 227-243. DLF (Digital Library Federation) (1998). A working definition of digital library [en línea]. [Consulta: 22 de febrero de 2007]. Disponible en: http://www.diglib.org/about/dldefinition.htm.

MÓDULO 2. EL PAPEL DE LA DESCRIPCIÓN: ¿QUÉ SON LOS METADATOS? 2.1. Definición y conceptos básicos Al hablar de metadatos, la primera, más intuitiva y a la vez ya casi manida idea que se nos suele presentar es la de “datos sobre datos”, traída de su etimología (del griego meta, más allá, que en Informática denota “sobre” y el latín datum, que en su acepción actual recogida en el DRAE se relaciona con documento o información tratable mediante ordenadores, esto es, digital). Sin embargo, si bien esta definición sirvió para popularizar el término desde mediados de los años 90, hoy no resulta ya especialmente útil -más allá del contacto inicial- ni estrictamente válida. Greenberg (2003) aporta una definición que consideramos más completa: metadatos son “datos estructurados sobre un objeto, que soportan funciones asociadas al objeto designado”. Con esta definición, la autora quiere destacar tres aspectos relevantes: 1) la estructuración de los datos conforme a unas “normas” (que se denominan esquemas de metadatos), 2) la referencia de esos datos estructurados a un objeto, que puede ser tanto físico como lógico (digital), al que se suele hacer referencia como DLO (Document Like Object u objeto asimilable a un documento) y 3) la finalidad de los metadatos, que no es otra que contribuir a que la función primordial del documento, que es la comunicación del mensaje informativo que le dio origen (Rodríguez Bravo, 2002), sea desempeñada de manera óptima a través de los procesos de recuperación de información. El término “metadatos”, que se emplea como tal en el ámbito informático desde los años 80 (Caplan, 2003, p.1), ha suscitado en la última década el interés de los profesionales de la Documentación. Diversos autores, entre ellos Lancaster (2002, p. xi), han criticado el entusiasmo de éstos con los metadatos, entendiendo que no es sino un término de moda, traído de la mano de otras disciplinas, y que hace referencia a técnicas clásicas de las Ciencias Documentales: la descripción formal y de contenido. Sin embargo, el propio Lancaster reconoce que con la adopción del nuevo término se quiere atender a una realidad, la de los contenidos digitales en red, que comporta una complejidad que quizá supera los límites tradicionalmente asignados a la descripción bibliográfica (Lancaster, 2002, p. 346). De hecho, cuando se habla de metadatos se suele sobreentender que se está haciendo referencia a la descripción de recursos de información, es decir, documentos digitales.

2.1.1. Registros y esquemas de metadatos. De esta manera, podemos definir los metadatos como descripciones normalizadas de recursos que sirven para que éstos puedan ser correctamente identificados y recuperados en sistemas de información digital (SID). Formalmente, los metadatos adoptan la forma de registros (en inglés, metadata records), que presentan secuencias de pares “atributo” - “valor". Los atributos son las características o propiedades genéricas de una clase de objetos que se han de representar, mientras que los valores son propios y distintivos de cada recurso. Así, por ejemplo, para un sitio web se pueden identificar como atributos básicos: nombre o título, autor, fecha, localización y tema. En un caso concreto, tomaría los siguientes valores:

Atributos Valores Nombre o título Sitio web de la Universidad Carlos III de Madrid Autor Universidad Carlos III de Madrid Fecha o fecha de actualización 2007 Localización (URL) http://www.uc3m.es Tema Educación Superior, Universidades, Madrid En la práctica, los atributos constituyen elementos de los esquemas de metadatos, y los valores asignables a los recursos descritos pueden ser bien de libre asignación o bien ser tomados de listas de valores o vocabularios controlados. Los registros de metadatos se realizan de acuerdo a modelos descriptivos de referencia denominados esquemas de metadatos (en inglés, metadata scheme). Existen múltiples esquemas de metadatos, en función del tipo de recursos que describan, si bien uno de los de mayor difusión es el Dublin Core Metadata Element Set (DCMES), que trataremos en detalle más adelante. Un esquema de metadatos se puede definir como el conjunto de reglas y elementos que constituyen un modelo de metadatos. Los esquemas determinan tanto la sintaxis como la semántica. Respecto a la sintaxis, establecen los elementos y orden en que habrán de disponerse éstos así como el formato de etiquetado o codificado de los metadatos. En cuanto a la semántica, ofrecen recomendaciones de uso de los elementos, de vocabularios especializados o acepciones específicas de términos en determinados dominios (es el caso de los perfiles de aplicación). En un esquema de metadatos se recogen, en definitiva, cuáles son las características más representativas de los objetos que trata de describir así como la forma de elaborar los registros de metadatos correspondientes.

2.1.2. Descripción mediante metadatos La descripción de recursos mediante metadatos se puede realizar de dos maneras: una interna, mediante su integración en el código fuente del recurso (en inglés este tipo se denomina embedded metadata), y otra externa (stand-alone metadata), bien mediante la utilización de los elementos de descripción en un archivo HTML o XML independiente o bien como campos de una base de datos que mantiene un enlace al documento descrito. Un ejemplo de metadatos internos lo encontramos en el propio sitio web de la Iniciativa Dublin Core de Metadatos (http://dublincore.org/). Si visualizamos su código fuente (Ver > Código fuente), podremos acceder al registro de metadatos correspondiente, realizado según el esquema DC.

Un ejemplo de metadatos externos lo encontramos, por ejemplo, en el repositorio de contenidos educativos MERLOT. En él se observa que los registros de metadatos han servido para diseñar la base de datos que constituye el repositorio, de manera que los atributos se han convertido en campos de la base para posibilitar la búsqueda de recursos en función de los valores asignados previamente. Así, en el ejemplo seleccionado, “Visual Chemistry Laboratory”, se recogen características como el tipo de material de que se trata, su formato, su coste de uso, fecha, autor, categoría temática, etc. Asimismo, recoge un enlace al recurso descrito.

La utilización de uno u otro tipo de metadatos suele depender de la naturaleza de los recursos y del uso que se pretenda hacer de los mismos. Los metadatos internos se suelen generar en el momento de creación de los recursos (como en el caso del fichero de audio que se muestra más abajo); por su parte, en los externos éstos se generan con posterioridad, y, en el caso de metadatos aplicados al diseño de bases de datos se suelen emplear para dar acceso a recursos ajenos, no modificables, mientras que los externos anejos a los recursos en archivos independientes se suelen emplear en el intercambio de registros (un ejemplo lo veremos más adelante con los paquetes de contenidos SCORM).

2.2. Tipos de metadatos Actualmente existe una gran diversidad en el campo de los metadatos, por lo que no es fácil realizar una clasificación de los mismos. Se suelen mencionar, entre otros, criterios como su origen (humanos o automáticos), forma (internos o externos), estructuración (de libre asignación o estructurados en función de un esquema concreto), nivel de descripción (colecciones o recursos) o funcionalidad (administrativos, descriptivos, etc.), si bien ninguno de ellos nos puede ofrecer sino una aproximación parcial. En general, podemos decir que los recursos informativos poseen tres aspectos fundamentales que pueden ser representados (descritos) mediante metadatos (Gilliland-Swetland, 2000): • • •

Su contenido: su mensaje informativo. Su contexto: los agentes y circunstancias de creación del recurso. Su estructura: relaciones existentes entre recursos o partes de recursos entre sí.

Sin embargo, además de los metadatos referentes al recurso en sí, hay otros tipos de metadatos que son necesarios para la gestión de recursos en sistemas de información. Desde que un recurso es incorporado a un SID, pasa por diversos

momentos (véase debajo el gráfico que representa el ciclo de vida de los documentos) en los que intervienen diversos agentes y procesos, tanto manuales como automatizados, que van agregando “capas” de metadatos relativos a dicho objeto. Así, en un primer momento, se le añaden datos relativos a su entrada en el sistema (fecha, responsable, etc.), su estado (si es original o versión de otro documento) y elementos pertinentes de descripción (autoría, fecha, indización o categorización temática, derechos de autor asociados al recurso, etc.). Posteriormente, y a medida que el recurso es recuperado o modificado, se van incorporando o actualizando los datos que componen el registro de metadatos. Así, suele ser necesario actualizar periódicamente los datos de localización del recurso (en caso de que el recurso no cuente con DOI o sistema de identificación similar) o recoger información sobre el uso que ha recibido (número y tipo de usuarios que lo han utilizado, anotaciones o valoraciones que han realizado éstos, contextos en los que se ha empleado -en relación a la gestión de derechos de autor, etc.).

2.2.1. Clasificación de Gilliland-Swetland Una de las clasificaciones más aceptadas de los distintos tipos de metadatos implicados es la de Gilliland-Swetland (2000), que atendiendo a su función distingue: Tipo

Uso

Ejemplos • Información sobre la adquisición del recurso • Registro de derechos de autor • Documentación de requisitos legales de acceso Se emplean en la gestión de • Información sobre la localización Administrativos los recursos en sistemas de del recurso información • Criterios de selección para la digitalización • Control y diferenciación de versiones

Descriptivos

Se utilizan para identificar recursos y representar su contenido informativo

De conservación

Recogen información relevante para la gestión de

• • • • •

Registros catalográficos Ayudas en las búsquedas Índices especializados Hiperenlaces entre recursos Anotaciones de usuarios

•

Documentación del estado de conservación de los recursos

la conservación de los recursos

Técnicos

Recogen las características técnicas del recurso y los sistemas necesarios para su utilización

De uso

Se emplean para determinar el tipo y nivel de uso de los recursos

•

Documentación de las acciones necesarias para preservar las versiones tanto físicas como digitales de los recursos

•

Documentación de hardware y software requeridos Información sobre la digitalización (formato, ratio de compresión, etc.) Datos de autenticación y seguridad (claves, códigos de encriptación, etc.)

•

• •

Registro de usuarios y del uso que hacen de los recursos Registro de los contextos de reutilización

2.2.2. Clasificación de Caplan Caplan (2003), por su parte, considera los siguientes tipos: Tipo

Función/subtipo Recuperación Identificación Selección Colocación AdquisiciónPermiten localizar el recurso o una copia del mismo

Descripción Facilitan encontrar recursos pertinentes Facilitan la individualización y distinción entre recursos similares Permiten determinar cuáles son los recursos que mejor responden a una necesidad de información concreta Permiten agrupar recursos

Descriptivos

Evaluación

Relación

Usabilidad

Administrativos Gestión de derechos Preservación

Proporcionan valoraciones de los recursos, bien de los autores de los recursos o registros de metadatos o bien de los usuarios Permiten registrar las relaciones existentes entre los recursos descritos y otras versiones o recursos Recogen información sobre las características técnicas del recurso que facilitan su uso Recogen las condiciones de uso del recurso en función de la protección de derechos de autor Permiten conocer el estado de los

Técnicos

Estructurales

Vinculación

recursos y sus requisitos de preservación Recogen las características técnicas de los recursos tales como formato, duración, etc. Permiten registrar las relaciones existentes entre las partes componentes de los recursos descritos

2.2.3. Tipos de metadatos (a efectos prácticos) En la práctica, se observa que la mayor parte de los esquemas de metadatos recogen información relativa a la mayoría de los tipos mencionados, si bien el tratamiento (nivel de detalle o análisis) que reciben en cada caso es diferente, en función del tipo de recursos que traten de describir. A la vista de las aportaciones reseñadas, cabrá distinguir, a efectos prácticos, los siguientes tipos de metadatos: Metadatos relativos a la gestión de recursos en SID Datos de incorporación del recurso al SID Adquisición (identificador, fecha de incorporación en el SID, responsable, etc.) Características técnicas del recurso (formato, Técnicos extensión, etc.) Administrativos Restricciones de uso en virtud de los derechos de Gestión de autor asociados (materiales protegidos, adquisición derechos del licencias, etc.) Estado de los recursos y sus requisitos de Preservación preservación Metadatos relativos a los recursos Datos básicos de identificación del recurso (autor, Identificación título o nombre, fecha de creación o actualización, etc.) Descriptivos Palabras clave, descriptores o clasificación temática Representación del recurso Vínculos entre partes componentes de un recurso, Relación versiones y otros recursos relacionados Metadatos relativos al uso de los recursos Registro de Número, tipo y nivel de usuarios que acceden al usuarios recurso De uso Anotaciones realizadas por los usuarios respecto al Valoración recurso

2.3. Bibliografía CAPLAN, P. (2003). Metadata basics. En: CAPLAN, P. Metadata Fundamentals for All Librarians. Chicago: American Library Association, p. 116-128.

GILLILAND-SWETLAND, A. J. (2000). Introduction to Metadata: Setting the Stage [en línea]. En: BACA, M. (ed.). Introduction to metadata: pathways to digital information. Los Angeles: Getty Information Institute, p. 1-8. Disponible en: http://www.getty.edu/research/conducting_research/standards/intrometadata/setting.pd f. GREENBERG, J. (2003). Metadata and the world wide web. En: BATES, M. J.; MAACK, M. N. y DRAKE, M. (eds.). Encyclopedia of Library and Information Science. New York: Dekker, p. 1876-1888. RODRÍGUEZ BRAVO, B. (2002). El documento: entre la tradición y la renovación. Gijón: Trea LANCASTER, F. W. (2003). Indexing and abstracting in theory and practice. London: Facet. ISBN 1856044823. Bibliografía básica en castellano BACA, M. (ed.) (1999). Introducción a los metadatos: vías a la información digital. Los Ángeles: J. Paul Getty Trust. ISBN ISBN 0892365358 MÉNDEZ RODRÍGUEZ, E. M. (2002). Metadatos y recuperación de información: estándares, problemas y aplicabilidad en bibliotecas digitales. Gijón: Trea

MÓDULO 3. INTEROPERABILIDAD Y ESTÁNDARES. 3.1. CONCEPTO Y TIPOS DE INTEROPERABILIDAD Señalábamos en la primera lección la necesidad de integración de los sistemas y servicios de información digital. Pues bien, esta integración pasa por hacer posible su capacidad de trabajar de forma conjunta, a lo cual se denomina genéricamente interoperabilidad. El concepto de interoperabilidad es un concepto complejo, que se aplica en múltiples contextos, referido desde, por ejemplo, la posibilidad de utilizar un dispositivo como una memoria USB (pendrive) y los datos que en él se almacenan en diversas máquinas con diferentes configuraciones (sistemas operativos, etc.), a la posibilidad de realizar búsquedas simultáneas en varios catálogos de bibliotecas (lo que se conoce como búsqueda federada o federated search). En relación a los metadatos, el objetivo primordial es precisamente hacer posible que recursos que han sido descritos mediante diferentes esquemas puedan ser recuperados más allá de los diferentes sistemas locales en que se generaron dichas descripciones. Para ello, será necesario que los metadatos se hagan conforme a estándares o conformable a estándares de uso común en su ámbito de aplicación. Desde el punto de vista tecnológico, la interoperabilidad se define como “la capacidad de dos o más sistemas o componentes para intercambiar información y usar la información que han intercambiado” (IEEE, 1990). Desde el punto de vista del diseño de sistemas de información, la interoperabilidad se entiende como “la labor de construir servicios coherentes para usuarios cuando los componentes individuales son técnicamente diferentes y están gestionados por diferentes organizaciones” (Arms, 2000). La interoperabilidad se manifiesta, por tanto en (Borgman, 2000): • • •

La capacidad de los sistemas para trabajar entre sí en tiempo real. La capacidad del software para trabajar en diferentes sistemas. La capacidad de los datos para ser intercambiados entre diferentes sistemas (portabilidad).

Para ello, se ha de potenciar el desarrollo de (Arms, 2000): • • • •

Formatos estandarizados de documentos. Formatos estandarizados de metadatos. Formatos estandarizados de protocolos de comunicación y recuperación. Medios estandarizados de autenticación y seguridad

3.1.1. Tipos de interoperabilidad En relación a los metadatos, se diferencian dos tipos de interoperabilidad: la interoperabilidad sintáctica y la interoperabilidad semántica. La primera hace referencia a la interoperabilidad basada en la utilización de formatos estandarizados de codificación de documentos (formatos como XML y RDF, que veremos más adelante), mientras que la segunda hace referencia a la utilización de instrumentos de representación semántica estandarizados (esquemas, ontologías y vocabularios).

Un concepto relevante a la hora de hablar de interoperabilidad semántica es el concepto de crosswalks (“pasarelas” o “tablas de correspondencia”). La DCMI define crosswalk como “una tabla que mapea las relaciones y equivalencias entre dos o más esquemas de metadatos” (Woodley, 2003). Se trata, pues, de buscar correspondencias entre los elementos de al menos dos esquemas, identificando las coincidencias en la semántica que intentan representar los distintos elementos, con la finalidad de que dos o más sistemas de información que utilizan esquemas descriptivos distintos logren alcanzar el máximo grado de interoperabilidad entre sí. Un ejemplo de crosswalk sería, por ejemplo, el realizado por la Biblioteca del Congreso de los Estados Unidos entre el esquema Dublin Core y el formato MARC que se presenta a continuación (tomado de http://www.loc.gov/marc/marc2dc.html): Elementos DC Campos MARC Title 245 100, 110, 111, 700, 710, 711 Creator 720 Subject 600, 610, 611, 630, 650, 653 Description 500-599, excepto 506, 530, 540, 546 Contributor Publisher 260$a$b Date 260$c Leader06, Leader07 Type 655 Format 856$q Identifier 856$u Source 786$o$t 008/35-37 Language 546 Relation 530, 760-787$o$t 651 Coverage 752 Rights 506, 540 Fig. 1: Mapeo DC-MARC realizado por la Library of Congress Al proceso de conversión (de alguna manera, “traducción”) entre esquemas distintos del que se derivan los crosswalks se denomina mapeo (“mapping”). Obviamente, este proceso no está exento de dificultades, ya que, como señala Cromwell-Kessler (Baca, 1999:22) algunas de las cuestiones más difíciles de resolver pueden ser, entre otras: •

•

La existencia de dos o más conceptos que puedan estar representados por un único elemento en el otro esquema con el que se quiere realizar el mapeado (“target scheme”). La existencia de información que en un esquema se encuentra consignada en elementos tipo “notas” y que en el esquema de destino está recogida en elementos específicos. Que no existan equivalencias para determinados elementos.

3.2. ESTÁNDARES: IDENTIFICACIÓN Y LOCALIZACIÓN (DOI, URI, PURL). La normalización de las formas de identificación y localización de recursos digitales trata de proporcionar estabilidad a los mismos. Por su especial implicación en en desarrollo de metadatos, trataremos, al menos brevemente, tres de los principales estándares: DOI, URI y PURL. DOI (Digital Object Identifier) Definido por el estándar NISO Z39.84: DOI Syntax, que fue desarrollado por dos asociaciones de editores estadounidenses, el DOI trata de proporcionar enlaces permanentes a los recursos a los que se refiere. Cada código de identificación de un recurso está registrado en un directorio global gestionado por la International DOI Foundation (www.doi.org). Dicho registro deberá ser actualizado en función de los distintos cambios de ubicación que experimenten los recursos. Cada DOI está compuesto por un prefijo, que es un código asignado a cada organización que lo solicite, y un sufijo, que puede ser un identificador preexistente (por ejemplo, el ISBN) u otro creado ad hoc. Ejemplos de DOI serían: 10.1234/NP5678 10.5678/ISBN-0-7645-4889-4 10.2224/2004-10-ISO-DOI URI (Universal Resource Identifier) El URI es una cadena de caracteres que identifican a un recurso en la red. El tipo de URI más habitual es el ya más que conocido URL (Uniform Resource Locator), que especifica el protocolo de comunicación (http, ftp, gopher, etc.) y la ubicación del recurso. PURL (Persistent Uniform Resource Locator) Similar al DOI, fue desarrollado por la OCLC (http://www.purl.org/). Se trata de una URL referida a un recurso que apunta no al recurso en sí directamente, sino a un servicio intermedio que gestiona los cambios de ubicación de los recursos, redireccionando al usuario a la última ubicación registrada para dicho recurso. Una forma típica de PURL sería: http://purl.oclc.org/OCLC/PURL/FAQ.

3.3. ESTÁNDARES: LENGUAJES DE MARCADO (HTML, XML, RDF) En esta sección realizaremos una breve aproximación a los lenguajes de marcado, exponiendo sus principales conceptos y aportaciones, pero sin entrar en el procedimiento de codificación en sí, que excedería los límites del presente curso. Los estándares de codificación más relevantes para el tema que nos ocupa son: • • •

HTML (HyperText Markup Language) XML (Extensible Markup Language) RDF (Resource Description Framework)

3.3.1. HTML (HyperText Markup Language) Este lenguaje de codificación, nacido a principios de los años 90, es una simplificación de un lenguaje mucho más complejo denominado SGML (Standard Generalized Markup Language). HMTL es un estándar (véase el documento en que se describe su estructura básica: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.4.2) que trata de facilitar la publicación de contenidos en la web mediante su codificación con etiquetas (tags). Sus principales ventajas son que, al igual que su predecesor SGML, HTML es un formato no propietrario (no depende de una empresa concreta) y que es independiente de plataformas hardware o software específicas, lo que facilita el intercambio de información en sistemas distribuidos. Su principal limitación radica en su falta de capacidad expresiva, ya que el número de marcas que se pueden utilizar en la codificación de un documento está limitado a las que se han predefinido en el estándar, orientadas además en su mayoría a aspectos relativos a la presentación de los documentos y no a su contenido. Sin embargo, hoy día HTML sigue siendo el lenguaje más comúnmente utilizado para la publicación de documentos en la Web, en gran medida debido a su sencillez de uso para usuarios no expertos.

3.3.2. XML (Extensible Markup Language) Desde su primera aparición pública en el año 1996, XML ha sido protagonista destacado del desarrollo de aplicaciones y servicios para la web. A medio camino entre la simplicidad de HTML y la expresividad de SGML, se trata de un estándar desarrollado por el Consorcio Web (W3C o World Wide Web Consortium) que ofrece un modelo para representar el contenido informativo de los recursos de manera que éste sea fácilmente procesable por distintas aplicaciones. De hecho, XML no sería de gran utilidad sin un conjunto de aplicaciones relacionadas que se ocupan de la forma en que se han de procesar los documentos XML, lo que otorga utilidad práctica al estándar. Una de las principales características de XML es que, a diferencia de HMTL, permite diferenciar entre la forma de presentación de los documentos, su estructura y su contenido informativo. Este hecho tiene importantes repercusiones: por una parte, posibilita un control más eficiente y a la vez sencillo de las características de presentación a través de hojas de estilo (CSS); por otra, permite utilizar un número ilimitado de etiquetas en la descripción del contenido, siempre que éstas se encuentren definidas en su correspondiente DTD (Document Type Definition), que es el documento en que se especifica el conjunto de marcas que pueden ser utilizadas para codificar un determinado tipo de documento. De hecho, para que un sistema pueda procesar un documento XML, éste habrá de referir la DTD en que se basa. Así, en el ejemplo del sitio web de la Iniciativa Dublin Core de Metadatos (http://dublincore.org/), observamos la siguiente estructura: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"

Declaración de tipo de documento, señalando las DTD correspondientes

lang="en-US" xml:lang="en-US"> <head> <title>Dublin Core Metadata Initiative (DCMI)</title> <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> <meta name="DC.title" content="Dublin Core Metadata Initiative (DCMI) Home Page" /> <meta name="DC.description" content="The Dublin Core Metadata Initiative is an open forum (…)" /> <meta name="DC.date" content="2007-05-07" /> <meta name="DC.format" content="text/html" /> <meta name="DC.contributor" content="Dublin Core Metadata Initiative" /> <meta name="DC.language" content="en" /> (…) </head> <body> (…) </body> </html>

Inicio de la cabecera Etiqueta de título Etiqueta de enlace al esquema DC

Etiquetas de metadatos (meta tags) del estandar empleadas en la descripción del recurso

Cierre de la cabecera Cuerpo del documento Cierre del documento html

En la práctica, HTML y XML se pueden llegar a utilizar incluso de forma combinada (XHTML), ya que aunque XML ofrece interesantes ventajas y ha recibido un tratamento entusiasta por parte de la comunidad web en los últimos años, esto no quiere decir que haya sustituido a HTML, ya que en principio ambos atienden a funcionalidades distintas.

3.3.3. RDF (Resource Description Framework)

Se trata de una recomendación (no estándar propiamente dicho) del Consorcio Web orientada a representar la semántica implícita en los documentos de manera que ésta pueda ser procesada y “comprendida” por máquinas. Presenta un modelo conceptual en función del cual se pueden representar los metadatos referentes a los recursos, sus propiedades y valores con otros lenguajes, generalmente XML. Junto a este último, es considerado la base de la denominada “Web semántica”, como se muestra en la siguiente figura:

Fig. 2: Estructura (“layer-cake”) de la web semántica (Daconta, Obrst & Smith, 2003) Un ejemplo de registro DC codificado en RDF (XML) sería el siguiente: <?xml version="1.0" ?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description about="http://purl.org/DC/documents/notes-cox-816.htm"> <dc:title>Recording qualified Dublin Core metadata in HTML</dc:title> <dc:description> We describe a notation for recording qualified Dublin Core metadata in HTML meta elements. The syntax includes recommended usage of the standard HTML syntax to record the different classes of qualification needed to represent the model.</dc:description> <dc:date>1999-08-18</dc:date> <dc:format>text/html</dc:format> <dc:language>en</dc:language> <dc:publisher>Dublin Core Metadata Initiative</dc:publisher> </rdf:Description> </rdf:RDF>

3.4. ESTÁNDARES: PROTOCOLOS (Z39.50, OAI-PMH) Los protocolos establecen un conjunto de reglas que regulan la comunicación entre sistemas informáticos (dos conocidos protocolos son el HTTP o Hypertext Transport Protocol y el FTP o File Transfer Protocol). En esta sección destacamos dos protocolos especialmente relevantes para la recuperación de información en SID: Z39.50 y OAI-PMH.

3.4.1. Z39.50

Se trata de un estándar utilizado principalmente en el ámbito bibliotecario que hace posible que dos sistemas informáticos en la red puedan comunicarse con el propósito de intercambiar y recuperar información, de manera que los usuarios finales puedan realizar búsquedas en varias bases de datos (por ejemplo, catálogos de bibliotecas) de manera simultánea a través de un interfaz común y sin necesidad de conocer la sintaxis de búsqueda empleada en cada una de ellas. Su origen está en el proyecto LSP (Linked System Project) desarrollado en la década de 1980 con objeto de normalizar la búsqueda en los catálogos de la OCLC, LOC (Library of Congress), RLG (Research Library Group) y la WLN (Western Library Network). Recogido en 1988 en la norma NISO de la que toma su nombre (ANSI/NISO Z39.50-1995: Information Retrieval, Application Service Definition and Protocol Specification), en 1997 se aprobó como estándar ISO 23950 la tercera versión del protocolo, siendo la NISO del año 2003 la última presentada hasta el momento (texto de la misma accesible en: http://www.loc.gov/z3950/agency/Z39-50-2003.pdf). De su mantenimiento se encarga la LOC Z39.50 Maintenance Agency (http://www.loc.gov/z3950/agency/) y el grupo de “implementadores” ZIG (Z39.50 Implementors Group, http://www.loc.gov/z3950/agency/zig/zig-meetings.html). El sistema que define el protocolo está basado en una estructura cliente/servidor. Tanto la aplicación cliente, denominada Zclient, que es aquella desde la que se formulan las consultas, como la aplicación servidor o Zserver, que es la que ejecuta las consultas contra su base de datos y devuelve los resultados correspondientes, deben ser capaces de interpretar el protocolo. El protocolo normaliza los mensajes que estas dos aplicaciones deben enviarse, su semántica y formato de transferencia de datos. En primer lugar, la aplicación cliente traduce la estrategia de búsqueda planteada por el usuario a un conjunto de mensajes válidos según el protocolo, y a continuación las envía al servidor. El servidor recibe entonces el mensaje, lo traduce al lenguaje comprensible para la base de datos de destino, ejecuta la búsqueda y devuelve los resultados al cliente en un formato válido según el protocolo Z39.50, que de nuevo es interpretado en la aplicación inicial. La adopción del protocolo por parte de los principales proveedores de Sistemas Integrados de Gestión de Bibliotecas (SIGB) mediante la implementación en los mismos de software Zserver y Zclient ha permitido alcanzar un más que satisfactorio grado de interoperabilidad entre catálogos de bibliotecas de todo el mundo. Sin embargo, el potencial del protocolo va más allá, y son varios los proyectos que, desde finales del 2001, fecha en que se aprobó el programa ZING (Z39.50 International Next Generation) para definir la evolución del protocolo en el marco de la Web, abordan su aplicación en distintos ámbitos: SRW (Search/Retrieve Service), CQL (Common Query Language), ZOOM (Z39.50 Object-Oriented Model), etc. Cabe mencionar que el protocolo Z39.50 es un estándar de aplicación compleja, por lo que se han desarrollado los denominados “perfiles”. Los perfiles especifican las partes, funciones y características del protocolo que una implementación específica debe soportar. Se han desarrollado perfiles para información gubernamental (GILS), datos geoespaciales (GEO) o la navegación de tesauros (Zthes). Una completa lista de perfiles del protocolo se puede encontrar en: http://www.loc.gov/z3950/agency/profiles/profiles.html 3.4.2. Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)

En cumplimiento de su misión estratégica, “desarrollar y promover estándares de interoperabilidad que busquen facilitar la difusión eficiente de contenidos” (http://www.openarchives.org/), la Open Archives Initiative (OAI), ha desarrollado un protocolo específico que permite intercambiar registros de metadatos de publicaciones académicas (artículos, informes, etc. producidos en el ámbito académico, normalmente conocidos como e-prints) entre los distintos repositorios de acceso abierto que los pudieran albergar. La OAI propuso con este protocolo una tecnología alternativa al Z39.50 para la búsqueda bibliográfica simultánea en varias bases de datos. Su protocolo trata de salvar la dificultad que plantea a Z39.50 la recuperación sobre múltiples bases de datos al mismo tiempo (búsqueda distribuida), y para ello plantea el uso del “harvesting” o “recolección” de registros de metadatos hacia una base de datos centralizada (Service Provider), que actúa como intermediaria entre los repositorios que los contienen (Data Providers) y el usuario final. La comunicación que se establece entre los sistemas implicados se basa en la utilización de instrucciones del protocolo http para emitir preguntas y obtener respuestas (GET / POST). Un ejemplo de petición y respuesta entre cliente y servidor sería el siguiente (Barrueco y Subirats, 2003): Petición: http://an.oa.org/OAI-script? verb=GetRecord&identifier=oai:arXiv:hep-th/9901001&metadataPrefix=oai_dc Respuesta: <?xml version="1.0" encoding="UTF-8" ?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2002-05-01T19:20:30Z</responseDate> <request verb="GetRecord" identifier="oai:arXiv:hep-th/9901001" metadataPrefix="oai_dc">http://an.oa.org/OAI-script</request> <GetRecord> <record> <header> <identifier>oai:arXiv:cs/0112017</identifier> <datestamp>2001-12-14</datestamp> <setSpec>cs</setSpec> <setSpec>math</setSpec> </header> <metadata> <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"> <dc:title>Using Structural Metadata to Localize Experience of Digital Content </dc:title> <dc:creator>Dushay, Naomi</dc:creator>

<dc:subject>Digital Libraries</dc:subject> <dc:description>With the increasing technical sophistication of both information consumers and providers, there is increasing demand for more meaningful experiences of digital information. We present a framework that separates digital object experience, or rendering, from digital object storage and manipulation, so the rendering can be tailored to particular communities of users. </dc:description> <dc:description>Comment: 23 pages including 2 appendices, 8 figures</dc:description> <dc:date>2001-12-14</dc:date> </oai_dc:dc> </metadata> </record> </GetRecord> </OAI-PMH> Como se puede observar en este ejemplo, el formato de intercambio es XML, y el esquema de metadatos empleado es Dublin Core no cualificado, si bien este protocolo admite la utilización de otros esquemas adicionales.

3.5. ESTÁNDARES DE METADATOS: DESARROLLO Y TIPOLOGÍA. Una norma se puede definir como un “documento de aplicación voluntaria que contiene especificaciones técnicas basadas en el resultado de la experiencia y del desarrollo tecnológico; fruto del consenso entre todas las partes interesadas e involucradas en la actividad objeto de la misma” (AENOR, http://www.aenor.es/desarrollo/normalizacion/quees/ventajas.asp). En efecto, el desarrollo de normas sigue un proceso complejo, que podría ser resumido gráficamente de la siguiente manera:

Fig. 3: Esquema de desarrollo de estándares Como se puede observar, las necesidades de nuevos productos o servicios expresadas por determinadas comunidades de uso (usuarios, organizaciones, etc.) al sector industrial propicia el desarrollo de especificaciones (normas de facto), que a la larga pueden dar lugar a normas (normas de iure) en las que se recogen las experiencias y prácticas previas, y que son publicadas por entidades de normalización nacionales e internacionales (por ejemplo, ISO). La validez de estas normas está sujeta a la utilidad que posean para las comunidades de uso, y en la medida en que sirvan a ésta pueden dar lugar a nuevas especificaciones y normas. En el contexto de los metadatos, se diferencian tres tipos de esquemas: Estándares: esquemas normalizados, aprobadas por organismos oficiales de normalización (ISO, ANSI, AENOR, etc.) y que son adoptadas por los distintos sectores afectados. Es el caso del estándar Dublin Core (ISO 15836:2003) o la norma del IEEE para objetos de aprendizaje (IEEE 1484.12.1-2002, aprobada por ANSI el 14 de noviembre de 2002) . Especificaciones: esquemas desarrollados por consorcios, principalmente de entidades industriales. Su utilidad reside en hacer llegar a los órganos de normalización las necesidades de los distintos sectores implicados o afectados. Pueden servir, por tanto, de base para la elaboración de normas. Es el caso, por ejemplo, de las especificaciones del IMS o ADL (SCORM). Implementaciones: también llamados perfiles de aplicación, son esquemas transformados en atención a las necesidades específicas de determinadas comunidades de usuarios. Recogen elementos de uno o varios estándares y/o especificaciones, y se implementan bien aplicando restricciones de uso (número de elementos o repeticiones de los mismos) o bien añadiendo extensiones (nuevos elementos o vocabularios/espacios de nombres, namespaces).

3.6. BIBLIOGRAFÍA ARMS, W. Y. (2000). Digital libraries [en línea]. Cambridge, MASS: MIT Press. [Consulta: 21 de marzo de 2007]. Disponible en: <http://www.cs.cornell.edu/wya/DigLib/>. ISBN 0262018808. BACA, Murtha (1999). Introducción a los metadatos: vías a la información digital. Los Ángeles: J. Paul Getty Trust. ISBN ISBN 0892365358. BARRUECO, J.M.; SUBIRATS, I. (2003). OAI-PMH: Protocolo para la transmisión de contenidos en Internet [en línea]. Disponible en: <http://www.uv.es/=barrueco/cardedeu.doc>. BORGMAN, C.L. (2000). From Gutenberg to the Global Information Infrastructure: Access to information in the networked world. Cambridge, USA: MIT Press. ISBN 026202473X. Institute of Electrical and Electronics Engineers (1990). IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE. Disponible en: http://www.sei.cmu.edu/str/indexes/glossary/interoperability.html. WOODLEY, M.S. (2003). Glosario DCMI. [en línea]. Disponible en: <http://www.sedic.es/glosario_DCMI.pdf>. Bibliografía básica en castellano ABSYSNET.COM (2003) ZING Z39.50 International: Next Generation [en línea]. Disponible en: <http://www.absysnet.com/tema/tema25.html>. ABSYSNET.COM (2001) Z39.50 [en línea]. Disponible en: <http://www.absysnet.com/tema/tema0.html>.

MÓDULO 4. ESTÁNDAR DUBLIN CORE (ISO 15836:2003) 4.1. Características del esquema DC En este apartado está dividido en cuatro subapartados: • • • •

Breve historia de la Dublin Core Metadata Initiative (DCMI). Organización de la DCMI. DC en España. Características del estándar.

4.1.1. Breve historia de la Dublin Core Metadata Initiative (DCMI) A mediados de los años 90, se empezó a apreciar que la creciente cantidad de documentos electrónicos disponibles en la red imposibilitaba su tratamiento profesional. Por ello, un grupo de expertos procedentes de diversos ámbitos de trabajo, aunque principalmente de las Ciencias Documentales, decidió que debían pensar en un modo de facilitar que los propios autores dieran un tratamiento documental básico (de ahí el término “Core”) a los contenidos que publicaban en la web y dotar a éstos de unas mínimas garantías de poder ser recuperados a posteriori mediante los motores de búsqueda. Así, en 1995 se celebró en Dublin (Ohio, Estados Unidos, ciudad de la que toma su nombre) la primera reunión de la iniciativa, promovida por la OCLC (Online Computer Library Center) y el NCSA (National Center for Supercomputing Applications), que en adelante se denominaría “DC1” (las distintas reuniones de la iniciativa fueron numeradas con objeto de facilitar la ubicación cronológica de las distintas decisiones adoptadas). En esta primera reunión se realizó una primera aproximación al objeto de descripción, el DLO (Document Like Object) y al modelo descriptivo, el Dublin Core Metadata Element Set (DCMES). El concepto de DLO hace referencia a la unidad documental mínima tratable, que si bien en origen puede referirse a elementos tanto digitales como no digitales, en la práctica se identifica con cualquier documento digital al que se pueden incorporar metadatos con objeto de facilitar su recuperación. En los últimos años, el término predominante ha sido, no obstante, el de “recursos digitales” (“digital resources”) o simplemente “recursos”. Por su parte, el conjunto de elementos Dublin Core ha ido evolucionando a lo largo de las diferentes reuniones que se han ido celebrando, tanto en forma de workshops o talleres periódicos como de congresos que anualmente se han celebrado en distintas ciudades del mundo (http://dublincore.org/workshops/), desde Tokyo (2001) a Singapur (2007), pasando por Madrid (2005). Fruto del trabajo desarrollado y del grado de consenso alcanzado con el mismo, el DCMES se convirtió en norma estadounidense ANSI/NISO Z39.85 en el año 2001 (http://www.niso.org/standards/resources/Z39-85.pdf), aprobándose en 2003 como norma internacional ISO 15836:2003 (http://www.niso.org/international/SC4/n515.pdf). 4.1.2. Organización de la DCMI El trabajo de la iniciativa está liderado por un equipo directivo (conformado en la actualidad por Max Dekkers y Thomas Baker) que se encarga de marcar las líneas de actuación así como de supervisar las distintas actividades desarrolladas. Cuenta con un equipo asesor denominado “Board of Trustees” (compuesto actualmente por nueve miembros de distintas nacionalidades) que supervisa el conjunto de la iniciativa, busca financiación y promociona la adopción del DCMES. Por otra parte, el “Usage board” se encarga de controlar el desarrollo de los distintos elementos que conforman el esquema a partir del modelo conceptual base, el DCMI Abstract Model

(http://dublincore.org/documents/abstract-model/), así como las distintas experiencias y necesidades de las comunidades en se que va aplicando el esquema, que se canalizan a través de los distintos grupos de trabajo de la iniciativa (como la DCMI Libraries Community dedicado a las bibliotecas o la DCMI Education Community dedicado a la comunidad educativa). 4.1.3. DC en España En España existe un grupo de trabajo asociado a la iniciativa, el “Grupo de Trabajo sobre Normalización para la Recuperación de información en Internet” (NORMAWEB), que desarrolla sus actividades desde la SEDIC (Asociación Española de Documentación e Información). Dicho grupo mantiene un mirror español de la web de la DCMI (http://es.dublincore.org/) así como una lista de distribución en RedIris, DCMIES, abierta a la comunidad hispanohablante (http://www.rediris.es/list/info/dcmies.es.html). 4.1.4. Características del estándar El estándar Dublin Core es hoy día uno de los esquemas de mayor difusión en el mundo, tanto por su simplicidad como por su flexibilidad, demostrada en su aplicación a múltiples disciplinas y comunidades de interés. Se compone de tan sólo 15 elementos, que comparten las siguientes características: • • •

Todos están al mismo nivel jerárquico. Todos ellos son opcionales y repetibles tantas veces como sea preciso. El orden en que se presenten es indiferente.

El desarrollo de este esquema de metadatos sigue cuatro principios (Hillman, 2003): 1. Su simplicidad de creación y mantenimiento. El esquema ha de ser tan simple como sea posible tanto en su forma, contando con el mínimo número de elementos que permitan realizar una descripción adecuada, como en su construcción y mantenimiento. 2. Uso de semántica convenida. Los elementos del esquema representan características (semántica) que se pueden encontrar en recursos generados por distintas disciplinas y que por tanto son de común aplicación. 3. Alcance internacional. El esquema pretende poder ser aplicado internacionalmente, a recursos de todo tipo y procedencia. Para ello, la DMCI realiza un importante esfuerzo por aunar los intereses expresados por los distintos agentes internacionales participantes, realizando versiones en varias lenguas. 4. Extensibilidad. La DCMI ha previsto la posibilidad de que el esquema sea adaptado en función de las necesidades particulares de cada comunidad de uso mediante los denominados “perfiles de aplicación”, que posibilitan el uso del esquema DC junto con elementos procedentes de otros esquemas u otros de creación local (denominadas “extensiones”). A la hora de aplicar el esquema, la DCMI recomienda tener en cuenta los siguientes principios (íbidem): 1. El principio uno-a-uno (“One-to-one principle”). Según este principio, cada versión de un recurso (tanto por alteración de su contenido, formato, etc.) ha de tener una descripción propia, independiente. La relación natural entre el

recurso y sus distintas versiones ha de ser, eso sí, preservada en la descripción. 2. El principio de simplificación (“Dumb-down principle”). Según este principio, cualquier aplicación podría emplear los valores asignados al cualificador de un elemento aunque dicha aplicación no esté preparada para “entender” cualificadores. Esto quiere decir que si, por ejemplo, un centro importara un registro de metadatos codificado según DC cualificado y dicho centro no empleara más que DC simple, los valores incluídos en los cualificadores del registro importado se tomarían en el centro de destino como valores de elementos DC simple, sin alterar por ello la naturaleza ni efectividad de los mismos. 3. Adecuación de los valores. Este principio establece que en la elección de los valores asignados a los distintos elementos y calificadores ha de primar su interés para la recuperación. 4.2. DC simple y cualificado DC posibilita dos niveles de descripción: DC simple y DC cualificado (qDC o “qualified Dublin Core”). DC simple comprende el conjunto de 15 elementos recogidos en el estándar, y representa un conjunto de elementos que sirven para describir un recurso informativo de manera genérica. Sin embargo, en determinados contextos de aplicación, de ámbito más específico, se precisará un mayor nivel de detalle en la descripción de los recursos para que éstos sean identificados de manera adecuada. Por ello, la DCMI propuso lo que se denomina “DC cualificado”, que incorpora siete elementos adicionales así como un conjunto de subelementos (33 en total) desarrollado para algunos de los elementos principales que se denominan “cualificadores” (“qualifiers”) o “refinamientos” (“refinements”), que matizan, especifican o precisan (no extienden) el alcance de los primeros. Cuando se hace uso de estos subelementos, se dice que se está utilizando “DC cualificado”. En términos lingüísticos, los elementos serían los nombres y los cualificadores los adjetivos. La DCMI mantiene un registro (http://dublincore.org/dcregistry/) en el que se recogen los distintos elementos, calificadores y vocabularios asociados al esquema. Antes de presentar los distintos elementos del esquema, debemos señalar que después del año 2000, en sintonía con los desarrollos de lenguajes de codificación para la web, la DCMI decició que los nombres de elementos y calificadores se escribieran en minúsculas, salvo en el caso de nombres compuestos, en los que se introducen mayúsculas para una mayor claridad en su lectura (http://dublincore.org/documents/naming-policy/). 4.2.1. DC Simple

Los elementos de DC simple son:

title [Título] Nombre por el que formalmente se conoce el recurso. creator [Creador]

Persona o entidad responsable de la creación del recurso o la versión del mismo de que se trata. subject [Materia] Tema de que trata el recurso. description [Descripción] Descripción, a texto libre, del contenido del recurso. publisher [Editor] Entidad responsable de la publicación del recurso. contributor [Colaborador] Persona o entidad con responsabilidad parcial en la creación del recurso. date [Fecha] Fecha de creación o publicación del recurso u otras fechas asociadas a su ciclo de vida. type [Tipo de recurso] Naturaleza del recurso, en función de su contenido. format [Formato] Naturaleza del recurso, en función de sus características técnicas. identifier [Identificador] Referencia para la identificación inequívoca del recurso (URI, URL, DOI, etc,) source [Fuente] Referencia al identifier del recurso del que se deriva el recurso descrito. language [Idioma] Idioma o idiomas empleados en el recurso. relation [Relación] Referencia al identifier del recurso o recursos con los que está relacionado el recurso descrito. coverage [Cobertura] Alcance espacial, temporal o jurisdiccional asociado al contenido del recurso. rights [Derechos] Datos relativos al régimen de protección de derechos de autor que afecta al uso del recurso descrito. 4.2.2. DC Cualificado En cuanto a los cualificadores recomendados por la DCMI, éstos son: • • •

Elementos. Refinamientos (“Element Refinements”).

4.2.2.1. Elementos accrualMethod [Método de incorporación] Modo en que el recurso se incorpora a la colección. accrualPeriodicity [Periodicidad de incorporación] Frecuencia con la que un recurso se incorpora a una colección.

accrualPolicy [Política de incorporación] Política de incorporación de recursos a la colección. audience [Usuario] Tipo de usuario para al que se dirige el recurso o para el que puede ser de utilidad. instructionalMethod [Método instructivo] De especial utilidad en la descripción de recursos educativos, especifica el método instructivo empleado en el recurso. provenance [Procedencia] Identificación de los sucesivos cambios en la propiedad y custodia del recurso desde su creación relevantes para su autenticidad, integridad e interpretación. rightsHolder [Propietario de derechos] Persona o entidad a la que pertenecen los derechos de autor asociados al uso del recurso. 4.2.2.2. Refinamientos (“Element Refinements”) E: description; ER: abstract [Resumen] Resumen del contenido del recurso. E: rights; ER: accessRights [Derechos de acceso] Información sobre las restricciones de acceso al recurso. E: title; ER: alternative [Título alternativo] Cualquier forma del título de un recurso que se emplee como sustituto o alternativo al principal. E: date; ER: available [Disponible] Fecha o fechas en la que un recurso estará disponible en red. E: identifier; ER: bibliographicCitation [Cita bibliográfica] Referencia bibliográfica del recurso. E: relation; ER: conformsTo [Conforme a] Referencia a la norma o normas que el recurso cumple. E: date; ER: created [Fecha de creación] Fecha de creación del recurso. E: date; ER: dateAccepted [Fecha de aceptación] Fecha en la que se aceptó el recurso (tesis, artículo científico, etc.). E: date; ER: copyright [Fecha de copyright] Fecha del copyright asociado al recurso. E: date; ER: dateSubmitted [Fecha de remisión] Fecha de remisión del recurso (tesis, artículo científico, etc.). E: audience; ER: educationLevel [Nivel educativo] Identifica el nivel educativo del usuario al que se dirige el recurso o para el que puede ser de mayor utilidad. E: format; ER: extent [Extensión] Tamaño o duración del recurso. E: relation; ER: hasFormat [Tiene formato en] Identifica posteriores versiones (en cuanto a formato) del recurso descrito. E: relation; ER: hasPart [Tiene parte en] El recurso descrito está compuesto de una o varias partes, entre las que se

encuentra/n la/s referenciada/s. E: relation; ER: hasVersion [Tiene versión en] Referencia a la/s versión/es (en cuanto a contenido) del recurso descrito. E: relation; ER: isFormatOf [Es formato de] Establece la relación inversa al cualificador hasFormat. E: relation; ER: isPartOf [Es parte de] Establece la relación inversa al cualificador hasPart. E: relation; ER: isReferencedBy [Es referenciado por] El recurso descrito es referenciado o citado por el recurso referenciado. E: relation; ER: isReplacedBy [Es reemplazado por] El recurso descrito ha quedado obsoleto y ha sido reemplazado por el recurso referenciado. E: relation; ER: isRequiredBy [Es requerido por] El recurso descrito es requerido por el recurso referenciado ya sea de manera física o lógica. E: relation; ER: isVersionOf [Es versión de] Establece la relación inversa al cualificador hasVersion. E: date; ER: issued [Edición] Fecha de edición formal del recurso (publicación). E: rights; ER: license [Licencia] Disponibilidad de documento legal en que se de permiso de manera oficial para hacer uso del recurso. E: audience; ER: mediator [Mediador] Identifica el tipo de usuario que puede mediar en el acceso a un recurso educativo (docente o administrador). E: format; ER: medium [Medio] Material o medio físico del recurso descrito. E: date; ER: modified [Modificado] Fecha en la que el recurso fue modificado. E: relation; ER: references [Referencia a] Establece la relación inversa al cualificador isReferencedBy. E: relation; ER: replaces [Reemplaza a] Establece la relación inversa al cualificador isReplacedBy. E: relation; ER: requires [Requiere] Establece la relación inversa al cualificador isRequiredBy. E: coverage; ER: spatial [Espacial] Identifica la cobertura espacial del recurso (lugar/es). E: description; ER: tableOfContents [Índice] Lista de las secciones del recurso descrito. E: coverage; ER: temporal [Temporal] Identifica la cobertura temporal del recurso (tiempo o época). E: date; ER: valid [Válido] Identifica la fecha o rango de fechas en que el recurso es válido. 4.3. Vocabularios

Como se ha dicho anteriormente, los esquemas de metadatos determinan tanto la sintaxis como la semántica. En cuanto a esta última, determina los posibles valores que pueden adoptar los elementos. En función del elemento de que se trate, DC permite nutrirlo de distintas maneras: códigos alfanuméricos, texto libre o vocabularios. DCMI diferencia dos tipos de vocabularios: listas de términos y vocabularios controlados. En los siguientes cuadros-resumen se presentan datos relativos a los vocabularios recomendados, los elementos a los que están asociados y la localización del texto de referencia correspondiente a cada uno de ellos: Vocabulario: dcmi-box Elemento: spatial [coverage] Descripción: Identifica una región espacial a partir de sus límites geográficos. Localización: http://dublincore.org/documents/dcmi-box/ Vocabulario: dcmi-type Elemento: type Lista de valores empleados para categorizar la naturaleza o género del Descripción: contenido del recurso descrito. Localización: http://dublincore.org/documents/dcmi-type-vocabulary/ Vocabulario: DDC Elemento: subject Descripción: Valores recogidos en la Dewey Decimal Classification (DDC). http://www.oclc.org/dewey/ Localización: http://www.oclc.org/dewey/resources/summaries/deweysummaries.pdf Vocabulario: ISO3166 Elemento: spatial [coverage] Descripción: Códigos estándar para la representación de nombres de países. http://www.iso.org/iso/country_codes/iso_3166_code_lists/ Localización: english_country_names_and_code_elements.htm Vocabulario: ISO639-2 Elemento: language Descripción: Códigos normalizados para la representación de nombres de idiomas. Localización: http://www.loc.gov/standards/iso639-2/langhome.html Vocabulario: LCC Elemento: subject Descripción: Valores recogidos en la Library of Congress Classification (LCC). Localización: http://www.loc.gov/catdir/cpso/lcco/ Vocabulario: LCSH Elemento: subject Descripción: Valores recogidos en la Library of Congress Subject Headings (LCSH). Localización: http://www.loc.gov/cds/lcsh.html#lcsh20

Vocabulario: Elemento: Descripción: Localización:

MESH subject Valores recogidos en la Medical Subject Headings (MESH). http://www.nlm.nih.gov/mesh/meshhome.html

Vocabulario: dcmi-period Elemento: date; temporal [coverage] Descripción: Especifica los límites de un intervalo de tiempo. Localización: http://dublincore.org/documents/dcmi-period/ Vocabulario: dcmi-point Elemento: spatial [coverage] Identifica un punto en el espacio a través de sus coordenadas Descripción: geográficas. Localización: http://dublincore.org/documents/dcmi-point/ Vocabulario: Elemento: Descripción: Localización: Vocabulario: Elemento: Descripción: Localización: Vocabulario: Elemento: Descripción: Localización: Vocabulario: Elemento: Descripción: Localización: Vocabulario: Elemento: Descripción: Localización:

RFC1766 language Códigos normalizados para la representación de nombres de idiomas. http://www.ietf.org/rfc/rfc1766.txt RFC1766 language Códigos normalizados para la representación de nombres de idiomas. http://www.ietf.org/rfc/rfc3066.txt TNG spatial [coverage] Valores recogidos en el Getty Thesaurus of Geographic Names. http://www.getty.edu/research/conducting_research/vocabularies/ tgn/index.html UDC subject Valores recogidos en la Universal Decimal Classification (UDC, CDU en castellano). http://www.udcc.org/outline/outline.htm URI identifier; source; relation La forma más conocida de Universal Resource Identifier (URI) es la URL (Universal Resource Locator). http://www.ietf.org/rfc/rfc2396.txt

Vocabulario: Elemento: Descripción: Localización:

W3CDTF date; temporal [coverage] Basada en ISO8601, permite codificar fechas y horas. http://www.w3.org/TR/NOTE-datetime

Además de estos vocabularios, la DCMI fomenta el que las distintas comunidades de aplicación del esquema utilicen otros vocabularios, tanto estándares como desarrollados localmente, en los distintos centros de aplicación. Se recomienda, en todo caso, utilizar los vocabularios recomendados en la medida de lo posible con el fin de tratar de asegurar el mayor grado de interoperabilidad con otros sistemas de información usuarios de DC. 4.3.1. Cuadro-resumen del esquema DC completo El siguiente cuadro nos será de utilidad como referencia a la hora de realizar registros siguiendo el esquema DC:

accrualMethod accrualPeriodicity accrualPolicy audience + educationLevel + mediator contributor coverage + spatial + temporal creator date + available + created + date accepted + dateCopyrighted + dateSubmitted + issued + modified + valid description + abstract + table of contents format + extent + medium identifier

Tipo Cualificador (Elemento) Cualificador (Elemento) Cualificador (Elemento) Cualificador (Elemento) Cualificador Cualificador Elemento Elemento Cualificador Cualificador Elemento Elemento Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Elemento Cualificador Cualificador Elemento Cualificador Cualificador Elemento

Vocabulario/s

dcmi-box / ISO3166 / point / TGN period / W3CDTF no especificado period / W3CDTF

IMT

URI

+ bibliographicCitation instructionalMethod

Cualificador Cualificador (Elemento)

language

Elemento

provenance publisher relation + conformsTo + hasFormat + hasPart + hasVersion + isFormatOf + isPartOf + isReferencedBy + isReplacedBy + isRequiredBy + isVersionOf + references + replaces + requires rights + accessRights + license rightsHolder source

Cualificador (Elemento) Elemento Elemento Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Cualificador Elemento Cualificador Cualificador Cualificador (Elemento) Elemento

subject

Elemento

title + alternative type

Elemento Cualificador Elemento

ISO639-2 / RFC1766 / RFC3066

URI URI URI URI URI URI URI URI URI URI URI URI URI URI

URI DDC / LCC / LCSH / MESH / NLM / UDC

dcmi-type

En los casos en que no se especifica un vocabulario determinado o bien no hay necesidad de usar ninguno dada la naturaleza de los datos a consignar (caso de title, creator, etc.), o bien no se recomienda ninguno en particular pero sí se recomienda utilizar o desarrollar vocabularios específicos (caso de accrualMethod, accrualPeriodicity, etc.). Recordemos que la utilización de una lista de valores o de un vocabulario controlado está motivada por la necesidad de desambiguación que en determinados casos pueden darse con objeto de incrementar las posibilidades de recuperación. 4.4. Codificación de DC en HTML, XHTML, RDF y XML Una de las características de DC es que se trata de un esquema que actúa a nivel semántico, siendo versátil a la hora de adaptarse a distintos sistemas de codificación. La DCMI ha publicado varias guías en las que se recogen recomendaciones para la codificación de su esquema, disponibles en http://dublincore.org/resources/expressions/.

4.4.1. Codificación de DC en HTML/XHTML Como ya se ha mencionado, las metaetiquetas (metadatos) se han de consignar en la parte inicial del código fuente del documento, denominada cabecera (sección <head>), que se sitúa entre la declaración y el cuerpo (<body>). Una forma típica sería la siguiente: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <link rel="schema.DC” href="http://purl.org/dc/elements/1.0/"> <link rel="schema.DCTERMS” href="http://purl.org/dc/terms/"> <meta name="DC.title“ content="La aventura de Don Quijote de la Mancha"/> <meta name="DCTERMS.audience" content="learners"/> </head> <body> </body> </html> Las líneas en que se consignan los elementos <link> son necesarias para indicar que los elementos DC (tanto simple, en el caso de la primera, como cualificado, en el caso de la segunda) que se van a emplear en la descripción están registrados y definidos en las URL referenciadas. En el ejemplo presentado, se han incluido un elemento (title) y un cualificador (audience). El primero hace referencia al esquema simple (está

precedido por la abreviatura del esquema, DC, especificada en el primer elemento <link>), mientras que el segundo hace referencia al esquema cualificado (precedido de la abreviatura del esquema cualificado, DCTERMS, especificada en el segundo elemento <link>). Como se puede observar, cada etiqueta tiene dos partes, “meta name” o nombre del elemento y “content”, que especifica el valor asignado al elemento. Para indicar los vocabularios de los que se han tomado los valores que se han asignado a los elementos, habrá que incorporar una nueva línea, en la que, esta vez, el nombre del elemento irá relacionado con dicho vocabulario. Un ejemplo de esto sería: <meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text"/> Para los casos de elementos cuyos valores son enlaces (URIs) a otros recursos, la DCMI recomienda emplear el elemento XHTML <link> de la manera que se muestra en los siguientes ejemplos: <link rel="DC.relation" href="http://www.example.org/"/> <link rel="DCTERMS.references" href="http://www.example.org/publications/2002/176459.pdf"/> En cuanto al idioma de los valores de los elementos, la DCMI recomienda utilizar los atributos “lang” (HTML) “xml:lang” (XHTML, idioma del valor) o “hreflang” (idioma del contenido de recursos enlazados, si se trata de un elemento que contiene este tipo de valor), según se muestra en los siguientes ejemplos: <meta name="DC.title" lang="en" content="Expressing Dublin Core in HTML/XHTML meta and link elements" /> <meta name="DC.subject" xml:lang="en-GB" content="seafood"/> <meta name="DC.subject" xml:lang="es" content="marisco"/> <link rel="DC.relation" hreflang="fr" href="http://www.example.org/fr/"/> <link rel="DC.relation" hreflang="de" href="http://www.example.org/de/"/> 4.4.2. Codificación de DC en XML En la guía para la implementación de DC en XML más reciente, disponible en http://dublincore.org/documents/2003/04/02/dc-xml-guidelines/, se realizan dos recomendaciones generales: en primer lugar, que en las distintas aplicaciones se empleen schemas en lugar de DTDs y, en segundo lugar, que se utilicen los namespaces o espacios de nombres para identificar los elementos, cualificadores y vocabularios DC, según se recoge en http://dublincore.org/documents/2007/07/02/dcmi-namespace/. En dicha guía se ofrece un registro XML que ejemplifica la forma que éstos suelen adoptar: <?xml version="1.0"?> <metadata xmlns="http://example.org/myapp/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://example.org/myapp/ http://example.org/myapp/schema.xsd" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:title>UKOLN</dc:title> <dc:description>UKOLN is a national focus of expertise in digital information management. It provides policy, research and awareness services to the UK library, information and cultural heritage communities.UKOLN is based at the University of Bath.</dc:description> <dc:publisher>UKOLN, University of Bath</dc:publisher> <dc:identifier>http://www.ukoln.ac.uk/</dc:identifier> </metadata> Como podemos observar, el elemento contenedor de los metadatos DC en este registro XML nos encontramos con <metadata>, si bien podemos encontrarnos otros, como <record> o <dc>, ya que la DCMI no establece una recomendación clara al respecto. Tampoco se establece de manera clara una manera de indicar que una descripción está asociada a un recurso en particular si no es mediante el elemento <identifier>, cuyo valor es el URI del recurso correspondiente. Cada elemento DC será considerado en XML un elemento XML, y su valor será el contenido del elemento XML. Así, por ejemplo, encontraremos lo siguiente: <dc:title>Don Quijote de la Mancha</dc:title> En los casos en que a un mismo elemento le correspondan varios valores, éstos se repetirán de la siguiente manera: <dc:subject>Aventuras</dc:subject> <dc:subject>España</dc:subject> Los cualificadores se tratan en XML de la misma manera que los elementos de DC simple. Así, encontraremos, por ejemplo: <dcterms:available>2007-06</dcterms:available> En cuanto a la especificación de los vocabularios de los que se han tomado los valores que se han asignado a los elementos y cualificadores, ésta se hará mediante el atributo “xsi:type”, tal y como se ilustra en el siguiente ejemplo: <dc:identifier xsi:type="dcterms:URI">http://www.uc3m.es/</dc:identifier> Para la codificación del idioma de los valores de los elementos, la DCMI recomienda utilizar el atributo “xml:lang”, como se muestra en el siguiente ejemplo: <dc:subject xml:lang="en">seafood</dc:subject> <dc:subject xml:lang="es">marisco</dc:subject>

En determinados sistemas de información, el esquema DC puede no ser suficiente para satisfacer sus necesidades descriptivas, por lo que habrá emplear elementos procedentes de otros esquemas. XML permite combinar elementos procedentes de diferentes espacios de nombres, lo que permitirá solventar estas carencias. En el ejemplo siguiente (tomado de la guía mencionada de la DCMI), observamos cómo se ha añadido a DC el elemento “typicalLearningTime” del esquema IMS (equivalente a IEEE LOM): <?xml version="1.0"?> <record xmlns="http://example.org/learningapp/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://example.org/learningapp/ http://example.org/learningapp/schema.xsd" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:ims="http://www.imsglobal.org/xsd/imsmd_v1p2"> <dc:title>Frog maths</dc:title> <dc:identifier>http://somewhere.com/frogmaths/</dc:identifier> <dc:description>Simple maths games for 5-7 year olds</dc:description> <ims:typicallearningtime> <ims:datetime> 0000-00-00T00:15 </ims:datetime> </ims:typicallearningtime> </record> 4.4.3. Codificación de DC en XML/RDF La DCMI ha publicado dos recomendaciones, una para DC simple y otra para qDC (pendiente de aprobación). En ellas, la DCMI detalla cómo realizar la codificación del esquema. El resultado del proceso lleva a la realización de registros como el que presenta: <?xml version="1.0"?> <!DOCTYPE rdf:RDF PUBLIC "-//DUBLIN CORE//DCMES DTD 2002/07/31//EN" "http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://www.ilrt.bristol.ac.uk/people/cmdjb/"> <dc:title>Dave Beckett's Home Page</dc:title> <dc:creator>Dave Beckett</dc:creator> <dc:publisher>ILRT, University of Bristol</dc:publisher> <dc:date>2002-07-31</dc:date> </rdf:Description> </rdf:RDF> En este registro, se aprecian dos diferencias principales con respecto a un registro XML: la declaración del uso de RDF (cuarta línea) y la identificación de los elementos DC como descripción de un recurso concreto (líneas 6 a 11). Al igual que con XML simple, con RDF es posible combinar elementos de distintos esquemas mediante la especificación de los distintos espacios de nombres implicados. En la siguiente figura, por ejemplo, se ha combinado el elemento “DC.title” de Dublin Core con el elemento “intendedEndUserRole” del esquema IEEE LOM.

<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:lom-edu=" http://ltsc.ieee.org/xsd/LOMv1p0"> <rdf:Description rdf:about=" http://www.lib.csusb.edu/TIJ "> <dc:title>The Information Jungle: Learn to use the Internet for academic research </dc:title> </rdf:Description> <rdf:Description rdf:about=" http://www.lib.csusb.edu/TIJ"> <lom-edu:intendedEndUserRole>Learner</lom-edu: intendedEndUserRole> </rdf:Description> </rdf:RDF> 4.5. Bibliografía HILLMAN, D. (2003). Guía de uso del Dublin Core [en línea]. Disponible en: <http://dublincore.org/documents/usageguide/>. Bibliografía básica en castellano Conjunto de elementos Dublin Core, versión 1.1: Descripción de referencia [en línea]. Disponible en: <http://www.sedic.es/DCES.pdf>. WOODLEY, M.S. (2003). Glosario DCMI. [en línea]. Disponible en: <http://www.sedic.es/glosario_DCMI.pdf>.

MÓDULO 5. HERRAMIENTAS PARA LA CREACIÓN Y/O EDICIÓN DE METADATOS. 5.1. Tipología Como hemos visto anteriormente, las descripciones realizadas mediante metadatos se pueden incorporar a los documentos digitales a los que se refieren bien de forma interna o de forma externa. Dado que los creadores de metadatos no tienen por qué saber redactar código, se han desarrollado diversas herramientas para facilitar su creación, actuando como intermediarias entre las personas y las máquinas, a la manera de “traductores”. En la práctica, los distintos tipos de herramientas suelen combinarse para facilitar las distintas fases del proceso de creación. Se podrían distinguir las siguientes: Tipo de metadatos Herramientas para su creación • Formularios • De marcado Metadatos internos • De extracción • De conversión Metadatos externos • Formularios

Fig. 1.Tipos de herramientas para la creación de metadatos. 5.1.1. Metadatos externos En el caso de los metadatos externos, el caso más frecuente es el que encontramos en repositorios y bibliotecas digitales, en los que se facilitan a sus colaboradores una serie de formularios en los que deberán consignar los datos correspondientes a los documentos cuya incorporación proponen. Así, por ejemplo, para agregar un documento al repositorio educativo MERLOT (http://www.merlot.org/merlot/index.htm), se habrá de cumplimentar el formulario que se muestra en la siguiente figura:

Fig. 2. Formulario para la descripción de contenidos educativos en MERLOT. Otras herramientas de este tipo son el editor de ADLib (Athabasca Digital Library in a Box) de la Universidad de Athabasca (Canadá), que permite crear y editar en línea los metadatos de los objetos de aprendizaje incorporados al repositorio mediante un formulario que sigue el esquema IEEE LOM, la herramienta eRIB (EduSource Repository in a Box) perteneciente a la iniciativa EduSource (Canadá), que utiliza el mismo modelo y puede ser descargada como base de datos/repositorio independiente (eXist) o ser utilizada a través de COL-LOR (Commonwealth of Learning-Learning Object Repository).

Fig. 3. Formularios para la descripci贸n de objetos de aprendizaje en ADLib y COL-LOR

5.1.2. Metadatos internos En el caso de los metadatos de carácter interno, encontramos que se suelen utilizar varios tipos de herramientas (NISO, 2004: 10): •

Herramientas de extracción automática de metadatos. A través del análisis del código fuente de un recurso cuya URL haya sido introducida, este tipo de herramientas generan de forma automática una descripción conforme a un modelo de metadatos y una sintaxis especificados. El resultado no suele ser de buena calidad, por lo que generalmente debe ser editado y validado manualmente.

•

Formularios (templates). Se utilizan bien para la incorporación de registros a una base de datos (como hemos visto para el caso de los metadatos externos en repositorios y bibliotecas digitales), bien para la generación de descripciones en el momento de la creación de los documentos (caso de las herramientas de autor y plantillas de metaetiquetas tipo MetaTagBuilder, disponible en http://www.localsubmit.com/metatags.asp) o bien para la edición de las descripciones generadas automáticamente por las herramientas de extracción automática de metadatos.

•

Herramientas de marcado. La función de estas herramientas es la de facilitar el proceso de creación y edición de código fuente de diversas maneras: mediante la utilización de etiquetas autorellenables, colores para los distintos elementos la sintaxis, presentación arbórea de los distintos niveles jerárquicos de las estructuras, y sobre todo mediante la identificación automática de errores. Herramientas como XMLSpy o Notepad++ permiten crear y editar código HTML, XML o JavaScript, entre otros.

•

Herramientas de conversión. Su misión es traducir esquemas de metadatos, trasladando los datos de un modelo a otro. Parece evidente que el éxito de la traducción dependerá del grado de compatibilidad entre los elementos de origen y los de destino, y que se pueden producir pérdidas de información.

5.2. Descripción funcional de herramientas aplicables La utilidad de las herramientas de creación y/o edición de metadatos reside en facilitar la creación de metadatos de calidad a los autores de contenidos, bien para potenciar su recuperación en web o bien para ser importados y extraídos posteriormente por sistemas concretos de gestión de contenidos (Greenberg et al., 2003). Por lo general, estas herramientas permiten extraer automáticamente los metadatos contenidos en los recursos, con posibilidad de editarlos, o bien generar nuevos metadatos. Entre las herramientas más representativas (un registro de las cuales se puede encontrar en http://dublincore.org/tools/) destaca DC-dot por ser una de las más completas de que se dispone en este momento. Se trata de una aplicación Java (utilizable en línea o descargable para uso local) desarrollada y mantenida por Andy Powell, de la Universidad de Bath (Reino Unido), en la que se han integrado varias de las funcionalidades que acabamos de ver en el apartado anterior. A partir de una URL, esta herramienta es capaz de extraer los metadatos de un recurso y devolver un registro Dublin Core en XHTML, que es editable a través de un formulario. Posteriormente, dicha descripción puede ser convertida a otros lenguajes de marcado y esquemas.

Al acceder a DC-dot (http://www.ukoln.ac.uk/metadata/dcdot/), encontramos la casilla en la que se nos ofrece la posibilidad de introducir la URL así como solicitar que el resultado se muestre no en XHTML sino en RDF.

Fig. 4. Página de inicio de DC-dot Una vez introducida la URL deseada (en este caso, por ejemplo, www.uc3m.es), el botón Submit (“enviar”) nos lleva a una nueva pantalla en la que podemos visualizar el registro resultante de la extracción automática de metadatos así como un formulario en el que podemos modificar el contenido de dicho registro:

Fig. 5. Registro resultante y formulario de edición Una vez editado y actualizado (“re-submit”) el registro (en caso de que haya sido necesario hacerlo), éste se puede visualizar en formato XML, HTML o RDF (recuadro 1). Otros formatos disponibles son (botón “other formats”, recuadro 2) IEEE LOM, IMS, USMARC, SOIF, TEI, IAFA/ROADS, GILS y OLSTF. Dependiendo del formato elegido, el archivo de salida tendrá una extensión diferente (en función de la aplicación de destino). Así, por ejemplo, si seleccionamos la salida RDF obtendremos el archivo xml correspondiente (salida 1), mientras que si seleccionamos la salida SOIF (Summary Object Interchange Format, ver http://harvest.sourceforge.net/harvest/doc/index.html) obtendremos el archivo .soif correspondiente (salida 2).

Fig. 6. Salida 1: RDF.

Fig. 7. Salida 2: SOIF La principal ventaja de esta herramienta es que cada uno de los resultados obtenidos se podrá copiar y pegar directamente en el código fuente del documento de destino, en la correspondiente sección de cabecera. El principal inconveniente que presenta radica en que dado que la plantilla base es DC simple, la conversión a otros esquemas es limitada. Así, por ejemplo, encontraremos que aunque esta herramienta nos permite convertir un registro a un formato de la complejidad y riqueza semántica de IEEE LOM, no podremos aprovechar todo el potencial descriptivo de éste, ya que sólo se utilizarán los elementos de LOM con correspondencia en DC. Herramientas similares a ésta de carácter no comercial son MetaMaker, desarrollada por la FAO (Food and Agriculture Organization, Naciones Unidas) o Reggie (Distributed Systems Technology Center DSTC, Australia). 5.3. Bibliografía GREENBERG, J.; et al. (2003). Iterative design of metadata creation tools for resource authors [en línea]. International Conference on Dublin Core and Metadata Applications: Supporting Communities of Discourse and Practice. 28 septiembre-2 octubre. Disponible en: <http://www.siderean.com/dc2003/202_Paper82-color-NEW.pdf>. NISO (2004). Understanding metadata [en línea]. Disponible en: <http://www.niso.org/standards/resources/Understanding Metadata.pdf>.

MÓDULO 6. APLICACIONES EN LA WEB 6.1. Ventajas y desventajas del uso de metainformación en la Web Hace unos años, Abadall ponía de manifiesto que “una de las preocupaciones más importantes para los promotores de la interconectividad y de las autopistas de la información es, precisamente, llenarlas de contenidos” (Abadall Falgueras, 2001). Más adelante, añade “el problema reside ahora en diseñar sistemas que permitan organizar este cosmos y establecer procedimientos destinados a favorecer el acceso a las personas que lo deseen” (íbidem). En efecto, tan importante como proporcionar contenidos de calidad a la red es dotarla de medios adecuados para su recuperación, y no cabe duda que los metadatos constituyen uno de los medios más adecuados para ello. En la Web, la recuperación de la información se hace, principalmente, a través de la interrogación a las grandes bases de datos que conforman los buscadores. La interrogación se puede definir, en este contexto, como el proceso mediante el cual un sistema es capaz de hacer coincidir las estrategias de búsqueda introducidas por un usuario con las representaciones (términos seleccionados) de los documentos que la base contiene. Entra en escena en este momento un concepto de extremada importancia en recuperación de información (Information Retrieval o IR): la precisión o relevancia. Ésta se podría definir de manera genérica como el grado de adecuación de una respuesta documental a una necesidad de información concreta. El objetivo de las herramientas de búsqueda es precisamente ofrecer respuestas lo más relevantes posible, evitando tanto el silencio (no recuperación de documentos relevantes) como el ruido documental (recuperación de documentos no relevantes). Algunas de las principales ventajas del uso de metadatos en la recuperación de información en la Web son: 1. Su capacidad para representar el contenido de los documentos textuales mejor que los propios documentos y que las representaciones automáticas que de ellos efectúan los buscadores. 2. La mejora de la precisión de los sistemas de recuperación, posibilitando la prestación de servicios “inteligentes”. 3. La posibilidad de representar el contenido de documentos no textuales, tales como imágenes, sonidos o vídeos, que no se prestan fácilmente a técnicas de indización automática. Entre sus principales inconvenientes podemos señalar los siguientes: 1. Su creación, eminentemente manual, frente al V3 (Volumen, Variedad y Volatilidad) que caracteriza la Web, hace que su coste sea elevado. 2. Su aplicación no resulta especialmente eficaz si no es en entornos delimitados, finitos de la Web. 3. Puede ser objeto de usos malintencionados. Durante un tiempo, el uso de metaetiquetas estuvo muy difundido en Internet ya que los buscadores basaban en gran medida su recuperación en ellas y se consideraba una forma – eso sí, ilícita, que se denominó “spamming”- de promocionar sitios web dado que el lugar ocupado por una página en el ranking de resultados dependía de la frecuencia (estadística) de aparición de términos en ella. Con el tiempo, y dado que estas metaetiquetas no hacían sino afectar negativamente al

resultado de los buscadores, se empezó a penalizar el uso de las mismas, llegando al punto de que hoy muchos buscadores no consideran en absoluto la etiqueta <keywords> y tratan con precaución la etiqueta <description>. 6.2. Aplicaciones, experiencias y perspectivas: multimedia, Web semántica y Web 2.0 El aumento de la capacidad de almacenamiento y procesamiento de datos de las máquinas así como la cada vez mayor capacidad de transmisión de las redes de comunicación han propiciado la incorporación de nuevos tipos de contenidos y servicios en la Web. Analizaremos en esta sección tres de los principales fenómenos que marcan la agenda de desarrollo de la red: los materiales multimedia, la Web semántica o la Web 2.0. 6.2.1. Aplicación de metadatos a contenidos multimedia Los materiales multimedia predominan hoy en la red, ofreciendo un espacio virtual cada vez más atractivo a sus usuarios. Sin embargo, el tratamiento documental de estos contenidos presenta especiales dificultades, y se ha desarrollado una gran variedad de esquemas descriptivos, los denominados “metadatos para material multimedia” (Sheth, Klas, 1998). Su desarrollo ha estado liderado por dos grupos: a) Moving Picture Experts Group (MPEG). Este grupo de trabajo de ISO/IEC, ha desarrollado distintos estándares para la compresión, decompresión y codificación digital de vídeo y audio (véase http://www.chiariglione.org/mpeg/). Entre ellos, destacaremos uno, por ser el principal estándar de descripción de contenidos multimedia: el MPEG-7: Multimedia Content Description Interface (http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm). Aprobado en 2001 por ISO como ISO/IEC 15398, se trata en realidad de un conjunto de herramientas que determinan tanto la forma de generar descripciones de recursos como la forma de gestionar tales descripciones en su transporte y almacenamiento. El estándar se basa en la acción de cuatro elementos: 1. Esquemas de descripción: equivalentes a esquemas de metadatos. 2. Descriptores: equivalentes a valores de elementos. 3. Un lenguaje de definición de descripción (DDL): modelo que posibilita la creación de nuevos esquemas y/o la extensión y modificación de los existentes. 4. Herramientas de sistema: herramientas que soporten el envío simultáneo de descripciones, la sincronización de descripciones con el contenido, mecanismos de distribución y codificación de representaciones (tanto en formato textual orientado a la manipulación humana como en formato binario) para la transmisión y almacenamiento eficientes así como la gestión y protección de derechos de autor El estándar establece que las descripciones se han de generar en forma de paquetes o wrappers (técnica que, como ya sabemos, está orientada a la interoperabilidad) siguiendo los Esquemas de Descripción de Multimedia (Multimedia Description Schemes o DSs). En lugar de utilizar un solo esquema, este estándar emplea múltiples esquemas (en realidad, más de 100). Estos esquemas de metadatos determinan, según el estándar “una forma de describir en XML importantes conceptos

relacionados con la descripción y gestión de contenido audiovisual con el fin de facilitar su búsqueda, indización, filtrado y acceso”. MPEG-7 permite desarrollar dos tipos de descripciones válidas: unidades de descripción (description units) y descripciones completas (complete descriptions). El elemento raíz de cualquier descripción será <mpeg7>, que incluye un encabezamiento <descriptionMetadata>, en el que se recoge información sobre el propio registro de metadatos. Un ejemplo de descripción en MPEG-7 sería el siguiente: <Mpeg7 xmlns="http://www.mpeg7.org/2001/MPEG-7_Schema" xml:lang="en" type="complete"> <ContentDescription xsi:type="ContentEntityType"> <MultimediaContent xsi:type="ImageType"> <Image> <MediaLocator> <MediaUri> http://www.tilab.org/mpeg/mpeg_logo-anim_l.gif </MediaUri> </MediaLocator> <CreationInformation"> <Creation> <Title xml:lang="en">The animated MPEG Logo</Title> <Creator> <Role href="urn:mpeg:mpeg7:cs:RoleCS:AUTHOR"> <Name xml:lang="en">Author</Name> </Role> <Agent xsi:type="OrganizationType"> <Name>MPEG</Name> </Agent> </Creator> </Creation> <RelatedMaterial> <MediaLocator> <MediaUri>http://www.tilab.com/mpeg/</MediaUri> </MediaLocator> </RelatedMaterial> </CreationInformation> </Image> </MultimediaContent> </ContentDescription> </Mpeg7> Este registro, correspondiente al logo del grupo MPEG, presenta la descripción de la imagen (dentro de <contentDescription>), identificado el tipo de contenido multimedia (<image>), su ubicación (<mediaLocator>) e información sobre las características del objeto tales como su título (<title>), autor (<creator>) y contexto de uso (<relatedMaterial>). b) Joint Photographic Experts Group (JPEG). Se suele conocer bajo tal denominación al comité ISO SC29/WG1, que ha desarrollado el estándar JPEG2000 (ISO/IEC 15444-1:2000, Image Coding System), un formato de compresión de imágenes que incluye un registro de metadatos principalmente descriptivos. 6.2.2. Metadatos y Web semántica

Aunque la idea no era original, teniendo a Paul Otlet (Rayward, 1994) y Vannevar Bush (1999) como sus más conocidos precursores, fue Berners-Lee, actual director del Consorcio Web (W3C), quien materializó la Web y su más ambiciosa dimensión, la Web semántica, a finales de la década de 1990 (Berners-Lee, 1999). Éste la ha definido como “una extensión de la web actual, en la que se otorga a la información significado bien definido, mejorando las posibilidades de que los ordenadores y las personas trabajen de forma cooperativa” (Berners-Lee, 2001). Tal visión se apoya en tres pilares: XML, RDF y agentes basados en ontologías. El propósito de estas herramientas, cuyo desarrollo está siendo impulsado por el Consorcio Web, es precisamente dotar a los recursos web de anotaciones semánticas comprensibles para las máquinas (esto es, metadatos) con objeto de desarrollar servicios sofisticados basados en técnicas automáticas de recuperación de información. Mientras XML facilita la interoperabilidad sintáctica de los recursos, los vocabularios (codificados en RDF u otros lenguajes de representación formal como OWL o SKOS) están orientados a proporcionar interoperabilidad semántica. En este caso, cuando hablamos de vocabularios nos estamos refiriendo tanto a esquemas de metadatos (schemas) como a vocabularios (schemes), incluyendo entre estos últimos a vocabularios controlados, taxonomías y ontologías. Para el desarrollo de la Web semántica, es importante el nivel de formalización de los vocabularios, ya que las máquinas precisan de información suficientemente tratada como para que los agentes (robots) puedan aplicar sobre ella reglas lógicas y de inferencia para la resolución de tareas. Las ontologías pueden ser consideradas los vocabularios con un mayor grado de formalización, y, por tanto, los instrumentos más adecuados para la representación semántica en la web. Sin embargo, su desarrollo es complejo y costoso, por lo que aún no gozan de gran difusión. Se considera, no obstante, que los lenguajes documentales pueden, en muchos casos, constituir una buena base, una base de calidad, en la construcción de ontologías útiles para la Web semántica. 6.2.3. Metadatos y Web 2.0 El concepto de Web 2.0 hace referencia a una nueva aplicación de la red en la que el soporte tecnológico tiende a hacerse invisible, facilitando la publicación de contenidos y la comunicación entre los usuarios. El usuario pasa a ocupar un primer plano, en el que desempeña un papel activo: sus experiencias vitales o ideas (expresadas en blogs), sus opiniones sobre productos (reflejadas en ebay, amazon, etc.), sus conocimientos (recogidos por ejemplo, en wikipedia), sus contenidos favoritos (que referencia o alberga en delicious, flickr, youtube, etc.), en definitiva, todas sus experiencias y creaciones pasan a formar parte de los contenidos de la web en aras al bien común pero, sobre todo, al común interés. Las distintas aplicaciones que se han desarrollado en el contexto de esta Web 2.0, han propiciado la aparición de una forma económica de asignación de metadatos a los contenidos. Sin embargo, la mayoría de los metadatos asignados son de carácter informal, no profesional. En este contexto, predominan los vocabularios informales, en ocasiones denominados folksonomies, social tagging, etc. Estos vocabularios están constituidos por términos (palabras clave) sobre los que no se ejerce ningún tipo de control terminológico. Responden a una finalidad práctica: disponer de una forma rápida de representar el contenido informativo de los recursos para su recuperación. La eficacia de tal representación se enfrenta claramente a la economía y la capacidad

de los usuarios para realizar cualquier otro tipo de representación. Por ello, en numerosos casos la precisión de la respuesta de los sistemas ante estrategias de búsqueda concretas será muy baja. Un ejemplo de ello son las etiquetas temáticas o categorías asignadas en estas aplicaciones, que en la mayoría de los casos producirán un sustancial ruido. En Youtube, se definen las etiquetas como “elementos heurísticos asociativos que facilitan la localización de elementos de interés” (Glosario Youtube, disponible en: http://www.google.com/support/youtube/bin/answer.py?answer=70181). De manera más prágmática, en Flickr se definen como “palabras clave o categorías que agregas a una foto para que sea más fácil encontrarla luego” (Ayuda de Flickr, disponible en: http://www.flickr.com/help/tags/#37). Flickr permite asignar hasta 75 etiquetas a cada imagen que se suba. La representación visual (tag cloud o nube de etiquetas) que se presenta a continuación recoge la frecuencia de aparición de las etiquetas asignadas más frecuentemente en la aplicación:

Fig. 1: Tag cloud de etiquetas más frecuentes en Flickr En esta representación observamos que las etiquetas que aparecen en un tipo de letra mayor son las más frecuentes. Inferimos que la mayor parte de las imágenes que los usuarios de Flickr han subido son fotos correspondientes a eventos familiares (bodas, cumpleaños, etc.), lugares, viajes, familia, etc.

La asignación de etiquetas semánticas a los contenidos facilita, además, su presentación categorizada (fig.2). Esto hace posible el browsing o navegación por la estructura de contenidos que propicie una búsqueda por navegación o serendipitous browsing, especialmente útil cuando la necesidad de información del usuario es de carácter genérico o no ha sido concretada.

Fig. 2: Categorías temáticas de Youtube basadas en etiquetado semántico Otra posibilidad basada en etiquetas semánticas es la que ofrece Flickr, que permite visualizar sus contenidos (en este caso, imágenes) en función del lugar geográfico que representan (a lo que denomina “geoetiquetas”).

Fig. 3: Visualización geográfica de imágenes en Flickr basada en “geoetiquetas” En su búsqueda de nuevas y cada vez más atractivas formas de acceso a los contenidos, observamos en estas aplicaciones un interés por explotar el potencial de los metadatos para la prestación de servicios de información. No obstante, no podemos obviar las dificultades a las que se enfrentan al basarse en una asignación de etiquetas semánticas a la que no se aplica filtro alguno orientado a asegurar su pertinencia, consistencia y calidad. 6.3. Bibliografía ABADALL FALGUERAS, E. (2001). Sistemas y servicios de información digital. Gijón: Trea. BUSH, V. (1999). As we may think. Library Computing, vol. 18, n. 3, p. 180-188. BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. (2001). The semantic web. Scientific American, May issue. BERNERS-LEE, T. (1999). Weaving the web: the original design and ultimate destiny of the World Wide Web by its inventor. New York: Harper. ISBN 0062515861 RAYWARD, W. B. (1994). Visions of Xanadu: Paul Otlet (1868-1944) and hypertext. Journal of the American Society for Information Science, vol. 45, n. 4, p. 235-250.

SHETH, A.; KLAS, W. (1998). Multimedia Metadata Management handbook: integrating and applying digital data. New York: McGraw-Hill. ISBN 0070577358. Bibliografía MARGAIX ARNAL, D. (2007). Conceptos de web 2.0 y biblioteca 2.0: origen, definiciones y retos para las bibliotecas actuales. El profesional de la información, vol. 16, n. 2, p. 95-106. SÁNCHEZ FERNÁNDEZ, L.; FERNÁNDEZ GARCÍA, N. (2005). La Web Semántica: fundamentos y breve "estado del arte" [en línea]. PC World, n. 178, p. 6-11. Disponible en: <http://www.ati.es/novatica/2005/178/178-6.pdf>.

MÓDULO 7. APLICACIONES EN BIBLIOTECAS Y ARCHIVOS

7.1. Aplicaciones, experiencias y perspectivas en bibliotecas En la primera lección hemos partido de una idea intuitiva de biblioteca para presentar el concepto de biblioteca digital. Pero, ¿qué es una biblioteca? Una biblioteca es una unidad (sistema) de información (UI) que presta servicios de mediación de acceso a la información y los documentos. La diferencia con respecto a otras unidades de información como centros de documentación y archivos es la naturaleza de sus fondos y sus servicios, que en el caso de la biblioteca se orienta por lo general a fines culturales. Así, distinguimos bibliotecas públicas, bibliotecas universitarias o bibliotecas escolares, entre otras. Los fondos de las bibliotecas han estado tradicionalmente constituidos por materiales con soportes físicos. Sin embargo, en su adaptación al contexto tecnológico actual para la satisfacción de las necesidades informativas de sus usuarios, la biblioteca ha empezado a llamarse a sí misma “híbrida” en cuanto combina ya los soportes tradicionales con los nuevos soportes de información digitales (y no sólo de contenido textual, sino también cada vez más imágenes, sonidos, videos, etc.). Por otra parte, la colección de una biblioteca está hoy constituida no sólo por aquellos recursos que posee dicha biblioteca, sino también por todos aquellos recursos a los que puede acceso gracias a acuerdos de cooperación bibliotecaria (desarrollo de catálogos colectivos, licencias compartidas de acceso a bases de datos, etc.). Por todo ello, la biblioteca ha ido avanzando en el desarrollo de distintos estándares (algunos de los cuales hemos visto en lecciones anteriores) que posibiliten una adecuada gestión de recursos de información para la prestación de dichos servicios. En este sentido, dos de los proyectos más destacados en la actualidad están siendo desarrollados por la Biblioteca del Congreso de los Estados Unidos (LOC): MODS y METS (http://www.loc.gov/standards/). 7.1.1. MODS (Metadata Object Description Schema) Se trata de un esquema XML para la descripción de recursos que se sitúa a medio camino entre el formato bibiotecario para la descripción bibliográfica automatizada denominado MARC 21 (Machine-Readable Cataloging, http://www.loc.gov/marc/umbspa/) y el estándar Dublin Core. Son tres las características de este esquema que lo hacen especialmente útil: • • • •

Es más sofisticado, más completo que DC. Al mismo tiempo, no es tan complejo como el formato MARC. Presenta un mayor grado de compatibilidad con MARC que cualquier otro esquema, por lo que la pérdida de datos entre conversiones es menor. Es más amigable que MARCXML (esquema desarrollado en 2002 por la LOC que recoge la forma de conversión de MARC a XML).

Se emplea: •

Como extensión de METS (que veremos a continuación): la exhaustividad de las descripciones MODS encajan bien con la jerarquía de los objetos METS.

• •

• • •

Para generar descripciones de recursos que posibiliten su recolección (OAIPMH). Como formato admitido por el protocolo SRU (Search/Retrieval via URL, http://www.loc.gov/standards/sru/resources/schemas.html) para la interoperabilidad de datos de registros y su recuperación en sistemas distribuidos. Como elemento de convergencia entre descripciones MARC y otras descripciones en lenguaje XML. Para la descripción de recursos en XML de manera más sencilla que con MARC. Para generar registros de metadatos que deban ser empaquetados junto a recursos electrónicos.

Es conveniente observar la conversión de registros de metadatos de MARC a MODS no se hace de forma directa, sino que se ha de realizar previamente una conversión de MARC a MARCXML y de ahí a MODS. La última versión del esquema, la 3.3, ha sido publicada en agosto de 2007. Los elementos de nivel superior que en él se recogen y su equivalencia respecto a los elementos del DCMES (http://www.loc.gov/standards/mods/dcsimple-mods.html) son los siguientes: Elemento MODS titleInfo

Elemento DC title

name

creator

typeOfResource genre originInfo language physicalDescription abstract tableOfContents targetAudience note subject

type type publisher, date language format description description audience description subject

classification

subject

relatedItem identifier location accessCondition

relation identifier identifier rights

recordInfo

Descripción Título del recurso. Encabezamiento o autoridad (persona, entidad, etc.). Tipo de recurso. Género de la obra. Datos de publicación del recurso. Idioma del recurso. Descripción física del recurso. Resumen del contenido del recurso. Sumario o índice del recurso. Tipo de usuario al que se dirige el recurso. Notas. Tema o materia del recurso. Código de clasificación, según vocabulario controlado. Recursos relacionados con el descrito. ID o identificador del recurso. Ubicación del recurso. Condiciones de acceso al recurso. Datos administrativos del recurso: fecha de creación, modificación, etc.

Se puede consultar una versión ampliada de este esquema en: http://www.loc.gov/standards/mods/v3/mods-3-3-outline-review-new.html.

Para ver un ejemplo de registro MODS, acudimos a una de las colecciones digitales de la Biblioteca del Congreso estadounidense (fig. 1) y realizamos una búsqueda. El registro que se nos presenta es el siguiente:

Fig. 1: Registro correspondiente a una videograbación en la Biblioteca del Congreso (http://lcweb2.loc.gov/diglib/ihas/loc.natlib.ihas.200035762/default.html) El registro se puede visualizar en formato MODS y METS. El correspondiente a su codificación en MODS sería el siguiente (sólo se presenta la parte principal del registro, destacando en negrita los elementos principales): − <mods:mods ID="MODS" version="3.0"> − <mods:titleInfo> − <mods:title> Library of Congress Song of American Tour with Thomas Hampson, January 17, 2006, Saint Paul, MN </mods:title> </mods:titleInfo> − <mods:name type="personal"> <mods:namePart>Hampson, Thomas</mods:namePart> − <mods:role> <mods:roleTerm authority="marcrelator" type="text">Performer</mods:roleTerm> </mods:role> </mods:name> − <mods:name type="personal"> <mods:namePart>Rieger, Wolfram</mods:namePart> − <mods:role> <mods:roleTerm authority="marcrelator" type="text">Performer</mods:roleTerm> </mods:role> </mods:name> <mods:typeOfResource>moving image</mods:typeOfResource> − <mods:originInfo>

<mods:dateIssued>2006</mods:dateIssued> <mods:issuance>monographic</mods:issuance> </mods:originInfo> − <mods:physicalDescription> <mods:form authority="ihas">videorecording</mods:form> <mods:reformattingQuality>access</mods:reformattingQuality> <mods:digitalOrigin>reformatted digital</mods:digitalOrigin> </mods:physicalDescription> <mods:targetAudience authority="marctarget">adult</mods:targetAudience> − <mods:note type="General"> Presented by the Schubert Club International Artist Series. </mods:note> − <mods:note type="General"> Performed at the Ordway Center for the Performing Arts, Saint Paul, Minnesota. </mods:note> <mods:note type="General">Thomas Hampson, baritone; Wolfram Rieger, piano.</mods:note> <mods:note type="Copyright Notice">Courtesy of The Schubert Club.</mods:note> <mods:identifier displayLabel="IHASDigitalID" type="local">200035762</mods:identifier> <mods:identifier displayLabel="IHASMODSID" type="local">24344</mods:identifier> − <mods:location> <mods:physicalLocation authority="marcorg">DLC</mods:physicalLocation> </mods:location> − <mods:recordInfo> <mods:recordContentSource>IHAS</mods:recordContentSource> <mods:recordChangeDate encoding="marc">060824</mods:recordChangeDate> <mods:recordIdentifier source="IHAS">loc.natlib.ihas.200035762</mods:recordIdentifier> </mods:recordInfo> Para complementar las capacidades de MODS, la Biblioteca del Congreso ha desarrollado una especificación para la codificación en XML de registros de autoridad (nombres de persona, entidades, títulos, materias, géneros y nombres geográficos) denominada MADS (Metadata Authority Description Schema, disponible en: http://www.loc.gov/standards/mads/). El registro de autoridad para un nombre de persona, por ejemplo, que recoge la forma autorizada para el mismo así como sus variantes, adopta la siguiente forma (ejemplo tomado de http://www.loc.gov/standards/mads/mads-name.xml): − <mads xsi:schemaLocation="http://www.loc.gov/mads/ mads.xsd"> − <authority> − <name> <namePart>Smith,John</namePart> <namePart type="date">1995-</namePart> </name> </authority> − <variant type="other"> − <name> <namePart>Smith, J</namePart> </name> </variant>

− <variant type="other"> − <name> <namePart>Smith, John J</namePart> </name> </variant> <note type="history">Biographical note about John Smith.</note> − <affiliation> <organization>Lawrence Livermore Laboratory</organization> <dateValid>1987</dateValid> </affiliation> </mads> 7.1.2. METS (Metadata Encoding and Transmission Standard) Desarrollado en 2001 a partir del proyecto MOA2 (Making of America II) de la Digital Library Federation (http://www.diglib.org/) y la LOC, METS es una especificación para la descripción, gestión e intercambio de todo tipo de recursos que puedan ser albergados en repositorios y bibliotecas digitales. Un registro codificado en METS (a lo que se denomina “documento METS”) puede llegar a contar con los siguientes componentes: •

•

Encabezamiento (metsHdr). El denominado “METS header” contiene información relativa a la creación del documento METS: nombre del archivo, fecha de creación y modificación del mismo, nombre del responsable de su creación, etc. Metadatos descriptivos (dmdSec). El registro METS puede contener una referencia de metadatos (Metadata Reference) o un paquete de metadatos (Metadata Wrapper). El primero consiste en una referencia (mediante un enlace) a un registro de metadatos externo, mientras que el segundo está conformado por un paquete de metadatos codificados bien en código binario (Base64) o en XML. METS ofrece un alto grado de flexibilidad en el sentido de que, aunque suele relacionarse con MODS o Dublin Core, no utiliza ningún esquema de metadatos en particular para la descripción de los recursos, sino que permite usar aquel que sea oportuno en cada contexto de aplicación. Metadatos administrativos (amdSec). Dispone de cuatro subcomponentes: metadatos técnicos, derechos de acceso y uso (rights metadata), origen (source metadata), y metadatos de conservación (preservation metadata). Al igual que el componente de metadatos descriptivos, puede hacer referencia a un registro externo o bien conformar un paquete de metadatos. Directorio de archivos (fileSec). El “file inventory” permite contar con una lista de los archivos asociados a un documento y sus relaciones. Los archivos que comprende pueden ser enlazados o pueden estar contenidos en el regostro como código binario. El mapa estructural (structMap). Describe la estructura de un recurso, presentando en una organización jerárquica los registros de metadatos y los archivos de contenido a los que éstos se refieren. Este mapa fomenta el desarrollo de instrumentos que faciliten la navegación de los usuarios en vastas colecciones de documentos. Enlaces estructurales (structLink). Especialmente útil para describir sitios web, trata de recoger los hiperenlaces referidos en las divisiones indicadas en el mapa estructural. Comportamiento (behaviorSec). Asocia comportamientos de ejecución al contenido del documento METS, de tal manera que, por ejemplo, sea posible especificar el tipo de aplicación necesario para utilizar el recurso o para indicar

que el recurso requiere una determinada hoja de estilo para ser mostrado correctamente. De estos componentes sólo el directorio de archivos y el mapa estructural son de uso obligatorio en METS. Ejemplos de documentos METS se pueden consultar en: http://www.loc.gov/standards/mets/mets-examples.html. Al igual que en el caso de otros esquemas, se han desarrollado diversos perfiles de aplicación de METS. Estos perfiles adaptan las múltiples posibilidades que ofrece el esquema a las necesidades de contextos de aplicación particulares. Un perfil de aplicación METS ha de contener los siguientes elementos (Cundiff, 2004): • • • • • • • • • • • • •

URI asignado al perfil de aplicación. Breve título para la clase de documentos que tratará el perfil. Resumen. Fecha de creación del perfil. Información de contacto. Fecha de registro del perfil en la Biblioteca del Congreso estadounidense. Indicación de otros perfiles que puedan estar relacionados. Enumeración de extensiones. Enumeración de reglas de descripción así como detalles de aplicación. Enumeración de vocabularios controlados aplicables. Descripción de requisitos estructurales relacionados con la construcción del propio objeto METS. Descripción detallada de las características técnicas o comportamientos de ejecución de los archivos de contenido que se puedan permitir. Descripción de herramientas afiliadas, compatibles con el perfil.

Entre las instituciones que han desarrollado perfiles de aplicación de METS se encuentran la OCLC, la California Digital Library, la Oxford Digital Library, la Library of Congress o la Universidad de Graz. Se puede consultar una lista completa de perfiles METS registrados en: http://cassatt.cdlib.org/%7Etingle/mets/mets-registered-profiles.html. 7.2. Aplicaciones, experiencias y perspectivas en archivos Los archivos, como unidades de información, nacen para recoger todos aquellos documentos generados o recibidos por una entidad en el desarrollo de su actividad. La base de la teoria archivistica reside en el denominado “principio de procedencia”, según el cual los archivos se organizan atendiendo al origen orgánico de sus documentos, que queda reflejado en el “cuadro de clasificación”. Es precisamente la información relativa al contexto y evolución de los documentos uno de los elementos principales en la descripción archivística, como señala Gilliland-Swetland (2000): “Determinar y registrar el contexto es lo que ayuda a identificar y preservar el valor probatorio de los documentos de archivo y de los objetos a lo largo del tiempo, al tiempo que facilita la determinación de su autenticidad y ayuda a los investigadores en su análisis e interpretación”. En los últimos años se han desarrollado distintos esquemas para la descripción de documentos de archivo, entre ellos el formato MARC Archival and Manuscript Control (AMC) desarrollado en 1984 por la Biblioteca del Congreso y que posteriormente se integraría en el propio formato MARC, la norma ISAD (G) o General International Standard for Archival Description desarrollada por el Consejo Internacional de Archivos en 1994, o el Encoded Archival Description (EAD).

Esta última, la EAD (http://www.loc.gov/ead/), es sin duda la aplicación más importante en el campo de los archivos. Se trata de una norma que describe un formato para la creación, codificación e intercambio de instrumentos de descripción (registros) en formato electrónico (SGML y XML) con objeto de facilitar el desarrollo de aplicaciones que posibiliten su recuperación en red. EAD en consta de tres elementos: • • •

Una DTD válida para SGML y XML. Un repertorio de etiquetas EAD (EAD Tag Library) en el que se describen los elementos definidos en la DTD. Unas directrices de aplicación, en las que se ofrecen recomendaciones sobre la manera de aplicar EAD a la descripción archivística.

Aunque se trata de una norma desarrollada en Estados Unidos, en su elaboración se tomaron en cuenta distintos modelos internacionales como ISAD(G), RAD, APPM, etc. Por ello, EAD se fundamenta en principios básicos de la descripción archivística expuestos en tales estándares, como son la descripción multinivel. La descripción multinivel consiste en describir un fondo de archivo con sus distintas partes componentes (secciones, series, expedientes, documentos, etc.) de manera que las distintas descripciones queden relacionadas, adoptando una forma jerárquica. Por lo general, en un registro EAD se pueden diferenciar tres partes o segmentos: • • •

eadheader: Información relativa al registro EAD en sí mismo. frontmatter: Información relevante para la publicación formal del registro. findaid: Descripción del material archivístico propiamente dicho, junto con la información contextual y administrativa asociada.

El siguiente esquema presenta una visión general de los elementos EAD:

Fig.2: Representación arbórea de los elementos EAD (Peis y Ruiz-Rodríguez, 2004) Como se puede observar en la fig. 2, el elemento raíz de un documento EAD es el elemento <ead>, que contiene tres elementos: <eadheader>, <frontmatter> y <findaid>. 7.2.1. Descripción de materiales archivísticos Centraremos nuestra atención en los elementos empleados para la descripción de los materiales archivísticos propiamente dichos, esto es, aquellos que componen el segmento findaid: archdesc Puede ser considerado el elemento principal de un documento EAD. Debe ir acompañado siempre por un atributo level que indica el nivel de la descripción: fondo, sección, subsección, serie, expediente o unidad documental. Éste se codificará mediante las palabras reservadas collection, file, fonds, series, etc. El elemento <archdesc> cuenta con los siguientes atributos adicionales: •

audience: cumple la misma función que en el elemento <ead>. Si toma el valor internal, el contenido del elemento <archdesc> no se mostrará a los usuarios. Si toma el valor external, sí será visible.

• •

relatedencoding: se puede utilizar en este elemento para indicar equivalencias entre EAD y un sistema de codificación alternativo. langmaterial: recogerá el idioma de la documentación que se describe, mediante su código ISO 639-2 (Codes for the Representation of Names of languages) legalstatus: situación jurídica del documento. type: indica si el instrumento de descripción es de tipo “inventario” o “registro”.

did Elemento de identificación descriptiva, constituye el bloque principal de cualquiera de los niveles de descripción del documento EAD. Incluye los siguientes elementos hijos: • • • • • • • • •

<head>: permite asignar un título al elemento <did> para su impresión o visualización en pantalla. <repository>: nombre del organismo encargado de dar acceso al documento, que es normalmente su custodio. <origination>: nombre del responsable de la creación o reunión del material que se describe. <unittitle>: título de la unidad de descripción. <unitdate>: fecha o fechas de la unidad de descripción. <physdesc>: descripción física, extensión y formato de la unidad de descripción. <unitid>: identificador único de la unidad de descripción. <physloc>: ubicación física de la unidad de descripción. <abstract>: resumen del contenido de la unidad documental.

admininfo Recoge una serie de elementos que recogen información sobre la custodia, adquisición, proceso y organización de la unidad de descripción, así como condiciones de acceso y reproducción de los documentos y la existencia de otras versiones en distintos formatos. Estos elementos son: • • • • • • • • •

<acqinfo>: recoge información sobre el tipo de adquisición del material (compra, donación, transferencia o depósito). <custodhist>: recoge información sobre cambios en la custodia de la unidad de descripción que hayan podido influir en su control, integridad o interpretación. <accessrestrict>: recoge información sobre las condiciones de acceso al material descrito. <userestrict>: recoge información sobre las condiciones de uso del material descrito. <altformavail>: indica la existencia de copias del material descrito en otros formatos distintos. <prefercite>: recoge la forma recomendada de referenciar el material descrito. <appraisal>: recoge información sobre la valoración de la unidad de descripción, procesos de selección y expurgos realizados. <accruals>: recoge información sobre adquisiciones, envíos o transferencias previstas relacionadas con el material descrito. <processinfo>: recoge información sobre cualquier tipo de procesamiento que no haya dado lugar a formato diferente del original.

bioghist

Este elemento recoge datos biográficos del autor de la unidad que se describe. controlaccess En este elemento se recoge una serie de descriptores (nombres propios, de entidades, geográficos, de materias, etc.) que sirven de punto de acceso al contenido de la unidad descrita para facilitar la recuperación. Por regla general, los valores asignados se tomarán de vocabularios controlados. note Información dirigida al usuario. Puede ser utilizado para indicar que la unidad descrita pertenece a una unidad de descripción más amplia que ha sido descrita en otros documentos EAD. odd Elemento multiuso, que recoge “otros datos descriptivos”, información que no ha podido consignarse en ningún otro elemento EAD. scopecontent Recoge información relativa al ámbito y cobertura temática del material descrito, citando a los principales individuos, organizaciones, hechos, lugares y temas que en ella se representan. add Recoge “datos descriptivos complementarios”, comprende instrumentos complementarios de acceso como bibliografías, índices, unidades de descripción relacionadas, etc. Puede incluir los siguientes elementos: • • • • • •

•

<head>: información relativa a la presentación de los elementos. <bibliography>: recoge referencias bibliográficas relacionadas con el material descrito. <fileplan>: permite recoger el cuadro de clasificación del archivo. <index>: facilita un índice en que se recogen los nombres de personas, instituciones, lugares, etc. que se citan en el material descrito. <otherfindaid>: indica la existencia de guías complementarias para la unidad de descripción. <relatedmaterial>: indica la existencia de materiales complementarios no relacionados directamente con el material descrito que pueden ser de interés para el usuario. <separatedmaterial>: indica la existencia de materiales directamente relacionados con el material descrito, pero que se hallan separados de éste físicamente.

7.3. Bibliografía CUNDIFF, M. V. (2004). An introduction to the Metadata Encoding and Transmission Standard (METS). Library Hi Tech, vol. 22, n. 1, p. 52-64.

GILLILAND-SWETLAND, A. J. (2000). Introduction to Metadata: Setting the Stage [en línea]. En: BACA, M. (ed.). Introduction to metadata: pathways to digital information. Los Angeles: Getty Information Institute, p. 1-8. Disponible en: <http://www.getty.edu/research/conducting_research/standards/intrometadata/setting.p df>. PEIS, E.; RUIZ-RODRÍGUEZ, A.A. (2004). EAD (Encoded Archival Description): Desarrollo, estructura, uso y aplicaciones [en línea]. Hypertext.net, n. 2. Disponible en: <http://www.hipertext.net/web/pag223.htm>. Bibliografía DIGITAL LIBRARY FEDERATION (DLF) (2007). METS: Metadata encoding and transmission standard: primer and reference manual [en línea]. Disponible en: <http://www.loc.gov/standards/mets/METS%20Documentation%20final%20070930%2 0msw.pdf>. DIGITAL LIBRARY FEDERATION (DLF) (2006). Implementation guidelines for shareable MODS records [en línea]. Disponible en: <http://www.diglib.org/aquifer/dlfmodsimplementationguidelines_finalnov2006.pdf>.

MÓDULO 8. METADATOS EDUCATIVOS: UN CASO DE APLICACIÓN ESPECÍFICA.

8.1. Estándares y perfiles de aplicación para contenidos educativos Entendemos por metadatos educativos los metadatos aplicados a la descripción de cualquier recurso educativo o de utilidad educativa (textos, imágenes, multimedia, etc.). Mediante los metadatos, los recursos educativos a los que se encuentran asociados quedan identificados y preparados para su recuperación en distintos contextos (web, repositorios y bibliotecas digitales educativas, etc.) con vistas a su posterior uso y reutilización en diferentes entornos educativos. 8.1.1. Metadatos educativos y objetos de aprendizaje El interés que en los últimos años ha suscitado el tema de los metadatos educativos viene dado por la relevancia que la descripción de contenidos ha cobrado en los entornos de educación a distancia a través de redes de comunicación (e-learning). La perentoria necesidad de reutilización de contenidos en las instituciones educativas (principalmente universitarias) ha propiciado la investigación en torno a una realidad acuñada en el ámbito informático: los objetos de aprendizaje o learning objects (LO). A pesar del gran número de trabajos que han abordado el tema desde que en 1994 W. Hodgins empezara a hablar de ellos, aún no se ha logrado alcanzar una definición de consenso de LO. El término, que procede obviamente de la programación orientada a objetos (OOP), hace referencia a un tipo concreto de documentos digitales, de naturaleza educativa, autónomos o con cierto grado de autonomía y cuyo objetivo prioritario es estar preparados para poder ser reutilizados posteriormente. 8.1.2. Estándares Vamos a estudiar dos estándares: • •

IEEE Standard for Learning Object Metadata (LOM). DC-Ed AP (DCMI).

8.1.2.1. IEEE Standard for Learning Object Metadata (LOM) LOM es un estándar elaborado por el Comité para la Normalización de Tecnologías Educativas del Instituto de Ingenieros en Electricidad y Electrónica (IEEE LTSC) a partir de trabajos previos del IMS y el proyecto europeo ARIADNE. La versión 1.0 fue aprobada en 2002, y desde entonces ha alcanzado una gran difusión, habiéndose realizado incluso una traducción al castellano, el “Estándar para metadatos de Objetos Educativos” (IEEE, 2002). El propósito de este estándar es facilitar, mediante una adecuada descripción, la creación, intercambio y uso de los en él denominados “objetos educativos”, entendidos como “cualquier entidad, digital o no digital, que pueda ser usada, reutilizada o referenciada durante cualquier actividad de aprendizaje basada en la tecnología”. La actual versión del estándar presenta 77 elementos de descripción, todos opcionales y repetibles que, organizados jerárquicamente, se agrupan en torno a nueve categorías: 1. General. Recoge algunos de los principales elementos de identificación del documento descrito: código de identificación, título del recurso, idioma, breve

2. 3. 4. 5.

6. 7. 8. 9.

descripción de su contenido, palabras clave, cobertura temporal o geográfica, estructura e información sobre su granularidad o nivel de agregación. Ciclo de vida. Recoge información relativa a la autoría, fecha de creación, versión y estado del recurso descrito. Meta-metadatos. Proporciona información sobre el esquema de metadatos empleado en la descripción del recurso, fecha, nombre del creador e idioma del registro. Técnica. Recoge información relativa al formato, tamaño, URI, duración y requisitos técnicos para la utilización del recurso. Uso educativo. Describe el uso educativo del recurso (ver tabla I): tipo de recurso de que se trata, tipo y nivel del usuario al que se dirige, contexto de utilización, tipo y nivel de interactividad que presenta, densidad semántica, dificultad, idioma y descripción de su uso. Derechos. Recoge aspectos relativos a las restricciones de uso asociadas al recurso: coste, protección de los derechos de autor y otras restricciones de uso. Relación. Proporciona información sobre las relaciones, en caso de que las haya, establecidas entre el recurso descrito y otros recursos. Anotación. Recoge los comentarios del catalogador sobre el uso pedagógico del recurso. Clasificación. Descripción del contenido del recurso a partir de uno o varios sistemas de clasificación, vocabularios y palabras clave.

La organización de los elementos en estas categorías es la que se presenta en el siguiente gráfico:

Fig. 1: Distribución de elementos en el estándar LOM En cuanto a los elementos de descripción de características propiamente educativas de los recursos, éstos son: Elemento

Descripción y uso

Tipo de aprendizaje predominante soportado por este objeto de aprendizaje: activo (que inducen a la participación directa por parte 5.1 Tipo de de los aprendices), expositivo (aquel en el que la tarea principal del interactividad aprendiz consiste en asimilar los conceptos que le son expuestos) y combinado (mezcla del activo y expositivo) Tipo de recurso, según lista de valores: ejercicio, simulación, 5.2 Tipo de cuestionario, diagrama, figura, gráfico, índice, diapositiva, tabla texto recurso narrativo, examen, experimento, planteamiento de problema y educativo autoevaluación. Grado de interactividad que caracteriza al objeto educativo (la 5.3 Nivel de interactividad es referida al grado en que el aprendiz puede influir en interactividad el aspecto o comportamiento del objeto educativo). Grado de concisión de un objeto educativo. Puede ser estimada en 5.4 Densidad función de su tamaño, ámbito y duración. Es independiente de su semántica dificultad. Usuario principal para el que ha sido diseñado el objeto educativo: 5.5 Destinatario profesor, autor, aprendiz, administrador. Entorno principal en el que se utilizará el objeto educativo según los 5.6 Contexto valores: Escuela, Educación Secundaria, Entretenimiento, otros. 5.7 Rango típico Edad del destinatario típico. de edad Grado de dificultad que presenta para los destinatarios típicos, 5.8 Dificultad trabajar con y utilizar este objeto educativo 5.9 Tiempo Tiempo aproximado o típico que necesitan para asimilar el objeto típico de educativo los destinatarios típicos (expresado en segundos). aprendizaje 5.10 Descripción Comentarios sobre cómo debe utilizarse este objeto educativo. Idioma utilizado en el objeto educativo. 5.11 Idioma 8.1.2.2. DC-Ed AP (DCMI) Dentro de la Dublin Core Metadata Initiative (DCMI) se constituyó en 1998 un grupo específico, el Dublin Core Education Group, con objeto de desarrollar una propuesta de aplicación del estándar a la representación de propiedades o características propias de recursos de utilidad en entornos educativos, esto es, a la descripción de recursos educativos. Resultado del trabajo de este grupo, actualmente dirigido por Sarah Currier y Diane Hillman, es el Dublin Core Education Application Profile (v.0.2), que especifica la aplicación de los elementos Dublin Core al área educativa e incluye dos nuevos elementos. El primero es Audience, que ha sido el primer elemento de un dominio específico en ser incorporado al esquema general DC, e identifica el tipo de usuario al que se dirige el recurso educativo o para el que pueda ser de utilidad. Presenta dos calificadores: EducationLevel, que describe el nivel educativo al que se dirige, y Mediator, que hace referencia a la persona o entidad que media en el acceso al recurso. El segundo es el elemento InstructionalMethod, que hace referencia al método instructivo que emplea el recurso. Audience y Audience-EducationLevel describen características que pueden ser de utilidad tanto para docentes como discentes, mientras que Audience-Mediator e InstructionalMethod están más orientados al trabajo docente. Se trata, no obstante, de un trabajo todavía en curso, y actualmente se trata de desarrollar como módulo independiente (un “application profile module”) que pueda ser aplicado junto al esquema básico de DC para la descripción de recursos educativos.

8.1.3. Especificaciones Veremos estas dos especificaciones: • •

IMS (IMS Learning Resource Metadata). SCORM (Sharable Content Object Reference Model).

8.1.3.1. IMS (IMS Learning Resource Metadata) Como ya se ha mencionado, el IMS Global Learning Consortium se ha visto activamente involucrado en el desarrollo del estándar LOM del IEEE. Su especificación se tomó como base para los primeros borradores del estándar, y más tarde, con su maduración, fue aquélla la que se adaptó a él. La última versión del IMS LRM se considera equivalente a LOM, facilitando una guía para su implementación. En la actualidad, IMS lidera un consorcio de instituciones educativas y empresas de contenidos educativos que está desarrollando un estándar de empaquetado de contenidos, el Common Cartridge (Cc). Los estándares de empaquetado permiten preparar (“envolver”) los objetos de aprendizaje de forma que puedan ser intercambiados (importados, exportados, agregados y desagregados) entre sistemas y plataformas educativas (en archivos formato .zip). Common Cartridge aglutina y reinterpreta estándares preexistentes, como IMS Content Packaging, IEEE Learning Object Metadata y SCORM. 8.1.3.2. SCORM (Sharable Content Object Reference Model) Producido por la iniciativa ADL (Advanced Distributed Learning) del Departamento de Defensa estadounidense, se trata de un conjunto de estándares y especificaciones especialmente orientado a la gestión de contenidos educativos dentro de plataformas de e-learning o LCMS (Learning Content Management Systems). En el grupo relativo a la gestión del contenido educativo, el Content Aggregation Model, observamos que SCORM utiliza el estándar LOM de forma directa, si bien complementado con otras especificaciones que afectan a la estructura, el empaquetado o la secuenciación de tales contenidos. Un paquete SCORM contiene:

Un índice o manifest. Define, mediante un archivo XML, la forma en que se han de importar los contenidos, así como la forma en que se han de presentar, tal y como lo concibió en origen su creador. Incluye: Metadatos. Descripción del recurso. Estructura. Define la estructura del objeto de aprendizaje. Recursos. Identifica los archivos de que se compone el objeto de aprendizaj

Subíndice o sub-manifest (no siempre).

Un ejemplo de paquete SCORM y su integración en una plataforma educativa (en este caso, Moodle) sería el siguiente:

En primer lugar, se descarga un paquete de contenidos del repositorio TILE (The Inclusive Learning Exchange, disponible en http://www.barrierfree.ca/tile/index.htm), observando que el archivo zip se encuentra el Ăndice y los archivos que componen el recurso:

A continuaci贸n, se a帽ade el paquete SCORM a la plataforma:

Finalmente, se comprueba que el contenido se reproduce en ella de forma correcta:

8.1.4. Implementaciones de estándares AICC (Aviation Industry CBT Committee) Formado en 1988, este grupo fue el primero en desarrollar especificaciones relacionadas con las tecnologías educativas, en su caso aplicadas a la formación de los profesionales de la aviación. Participa activamente en las actividades del IEEE LTSC. La última versión de su esquema de metadatos, la 1.7 (AICC, 2006), se presenta como un perfil de aplicación de LOM, aunque, a diferencia de éste, ofrece una recomendación sobre el carácter obligatorio u opcional que han de tener sus elementos. Su mayor aportación se sitúa en la categoría educativa, en la que prescinde de los elementos referidos a la densidad semántica y el rango típico de edades e incorpora 12 nuevos subelementos, relativos a aspectos pedagógicos métodos, técnicas y recursos didácticos- orientados al trabajo docente (Instructional Domain, Instructional Context, Instructional Events, Instructional Strategy, Learning Outcome Type, Objective y Required Training Resources), a la evaluación que efectúa el recurso (Assessment Type, Instructional Feedback Level y Training Event Reporting), a los conocimientos previos necesarios (Competency Level) o la capacidad del contenido para adaptarse al estudiante o la plataforma virtual de enseñanza (Adaptability). CEMARC (Curriculum Enhanced MARC) La denominación de Curriculum-Enhanced MARC se refiere a la utilización de varios campos del formato MARC21 en la consignación de información de interés para la recuperación de recursos educativos. Así, el campo 520 (Summary, etc.) se puede utilizar para incorporar un comentario valorativo del recurso, el 521 (Target Audience Note) para el tipo de usuario más apropiado para el recurso (curso, edad, etc.), el 526 (Study Program Information Note) para el título del programa docente del que pueda formar parte el recurso y el 658 (Index Term-Curriculum Objective) para el tipo de objetivos curriculares estatales o nacionales que persigue el recurso (especialmente

válido para el ámbito anglosajón). IBERMARC, por su parte, ofrece correspondencia con CEMARC en los campos 520 (Nota de sumario, resumen etc.), 521 (Nota de nivel del destinatario) y 526 (Nota de información sobre el programa de estudio), si bien estos dos últimos no son de uso común. 8.1.5. Perfiles de aplicación empleados en repositorios y bibliotecas digitales educativas Entre el conjunto de iniciativas actualmente en marcha, destacan las siguientes: • • • • • •

ARIADNE. EdNA Online. EduSource. GEM. MERLOT. The Learning Federation.

8.1.5.1. ARIADNE Es el resultado de un proyecto europeo realizado entre los años 1996 y 2000. Actualmente, la Fundación ARIADNE se encarga de mantener en funcionamiento el SILO (Search & Index Learning Objects), repositorio accesible en doce lenguas que alberga objetos de aprendizaje aportados por sus miembros y potencialmente útiles para instituciones académicas y empresas. Su esquema de descripción, de tipo modular, y que sirvió de base a los trabajos del IEEE, como ya hemos comentado anteriormente, se considera en su estado actual un perfil de aplicación de LOM.

Elementos de su esquema: Elemento 1 General 1.1 Title 1.2 Language 1.3 Date 1.4 Usage rights 1.5. Usage remarks 1.6 Restrictions 1.7 Version information (Based on) 1.8 Authors 1.9 Source 1.10 Description 2 Semantics 2.1 Science type 2.2 Main discipline 2.3 Sub-discipline 2.4 Main concept

Descripción y uso Características generales del recurso Título del documento. Idioma del recurso. Fecha de publicación del recurso. Derechos de propiedad intelectual. Notas sobre las condiciones de uso. Restricciones de uso. Identificación de versiones anteriores del recurso. Nombre del autor o entidad responsable del recurso. Origen del recurso. Descripción general del recurso. Clasificación del recurso Categoría clasificatoria más genérica, según lista de valores: Exact, Natural and Engineering Sciences y Human and Social Sciences. Especificación de la disciplina principal de la que trata el recurso, según lista de valores. Especificación de la subdisciplina de la que trata el recurso, según lista de valores. Concepto principal sobre el que trata el recurso, a texto libre.

2.5 Concept synonyms 2.6 Other important concepts 3 Pedagogical 3.1 User type

3.2 Document type

3.3 Document format

3.4 Interactivity level 3.5 Semantic density

3.6 Pedagogical duration

3.7 Difficulty level

3.8 Didactical context

3.9 Granularity 4 Technical data 4.1 Main file name 4.2 Media type 4.3 Operating system 4.4 File size 4.5 OS Version 4.6 Installation notes 4.7 Other constraints 5 Indexation data 5.1 Header creation date 5.2 Header author 5.3 Validation date

Sinónimos del concepto principal sobre el que trata el recurso, a texto libre. Conceptos alternativos sobre los que trate el recurso, a texto libre. Características didácticas del recurso Tipo de usuario a que se dirige el recurso, según lista de valores: Learner, Teacher, Author, Manager. Equivalente a LOM 5.5 Educational.IntendedEndUserRole Tipo de recurso, según lista de valores: Active y Expositive. Equivalente a LOM 5.1 Educational.InteractivityType. Formato del recurso, en función del tipo de recurso y según lista de valores: para Active: Ariadne course, Experiment, Exercise, Problem statement, Questionnaire, Self-assessment, Simulation; para Expositive: Diagram, Graph, Index, Table, Narrative text, Hypertext, Slides, Figure, Photograph, Video, Sound y Voice. Equivalente a LOM 5.2 Educational.LearningResourceType Grado de interactividad que presenta el recurso. Equivalente a LOM 5.3 Educational.InteractivityLevel. Densidad semántica. Equivalente a LOM 5.4 Educational.SemanticDensity. Tiempo estimado aproximado, expresado en minutos (en LOM es en segundos), necesario para la utilización del recurso. Equivalente a LOM 5.9 Educational.TypicalLearningTime. Nivel de dificultad que presenta el recurso. Equivalente a LOM 5.8 Educational.Difficulty. Contexto educativo de utiilización del recurso. Equivalente a LOM 9.2.2.2 Classification.TaxonPath en combinación con 9.1 Classification.Purpose=’educational level’ y 9.2.1 Classification.TaxonPath.Source=’ARIADNE’.. Nivel de modularidad o detalle del recurso. Equivalente a LOM 1.8 General.AggregationLevel. Características técnicas del recurso Nombre del archivo principal del recurso. Designación del tipo de medio, siguiendo la lista de valores del estándar MIME. Tipo de sistema operativo mínimo requerido. Tamaño del archivo, expresado en kB. Versión del sistema operativo. Comentarios de instalación. Requisitos técnicos adicionales. Datos de indización para el recurso Fecha de creación de la autoridad. Consignación del autor o entidad responsable del recurso. Fecha de validación del registro, incorporación del

5.4 Validator 5.5 Identifier 5.6 Last modified date 5.7 Language 6 Annotations 6.1 Creation date 6.2 Language 6.3 Annotation 6.4 Annotator

recurso. Persona o entidad que valida el registro. Identificador del recurso. Fecha de รบltima modificaciรณn del registro. Idioma del registro. Notas Fecha de creaciรณn de la nota. Idioma de la nota. Nota. Persona o entidad que realiza la nota.

Es un servicio de informaciรณn respaldado por el gobierno australiano que pone a disposiciรณn de toda su comunidad educativa un vasto repositorio de recursos didรกcticos (alrededor de 20.000) organizado por sectores educativos. El esquema desarrollado para la descripciรณn de sus contenidos, el EdNA Metadata Standard v.1.1 (EdNA, 2002), es un perfil de aplicaciรณn de Dublin Core que incorpora como extensiรณn local entre sus elementos de descripciรณn educativa el correspondiente a la valoraciรณn del recurso (EdNA.Review y EdNA.Reviewer), elemento de utilidad en la discriminaciรณn de contenidos por la recomendaciรณn de anteriores usuarios del recurso.

Elementos de su esquema: Puesto que la descripci贸n y uso de los elementos tomados de Dublin Core son los que figuran en la especificaci贸n (y que se pueden revisar en la figura 4, anteriormente presentada), s贸lo nos detendremos en aquellos aspectos particulares de EdNA. Elemento DC DC.Identifier DC.Title DC.Description

DC.Subject

DC.Publisher DC.Creator DC.Date DC.Type DC.Format DC.Language DC.Coverage

Descripci贸n y uso Elementos tomados de Dublin Core DC, URL. DC DC Vocabularios: APSDEP (Asian and Pacific Skills Development Programme Thesaurus), DDC (Dewey Decimal Classification), edna-kla (Schools Key Learning Areas), LCC (Library of Congress Classification), LCSH (Library of Congress Subject Headings), MeSH (Medical Subject Headings), SCIS (Schools Catalogue Information Service-Subject Headings), UDC (Universal Decimal Classification). DC DC DC Listas de valores DCMI y EdNA. DC DC DC

DC DC DC DC Extensiones Listas de valores propias: edna-audience (Administrator, Community member, Parent/carer, Student, Teacher/lecturer), edna-sector (Adult and Community Education, Higher EDNA.Audience Education, Preschool, School, Vocational education and training) y edna-userlevel (de 0 a 13, según los Australian Qualification Levels, AQF). Identifica a la persona o entidad que aprueba la incorporación EDNA.Approver del recurso al respositorio. Código de control de las categorías temáticas. Se utiliza en la EDNA.CategoryCode presentación de la búsqueda por categorías. Fecha de entrada del registro en el repositorio, de asignación EDNA.Entered automática. Define el nivel de profundidad en la indización automatizada EDNA.Indexing de páginas web. Comentario de evaluación del recurso. EDNA.Review Persona o entidad que realiza la revisión del recurso. EDNA.Reviewer Versión del esquema EdNa utilizado en la descripción del EDNA.Version recurso.

DC.Rights DC.Relation DC.Contributor DC.Source EDNA

8.1.5.3. EduSource Es un proyecto financiado por CANARIE (entidad sin ánimo de lucro apoyada por el gobierno canadiense), en un esfuerzo por aunar las múltiples iniciativas de repositorios de recursos educativos que se han venido desarrollando en Canadá, entre los cuales destaca el Alexandria Digital Content Repository y su motor de búsqueda CAREO (Campus Alberta Repository of Educational Objects) y su software de catalogación ALOHA (Advanced Learning Object Hub Application) desarrollados en el marco del proyecto BELLE (Broadband Enabled Lifelong Learnig Environment). Desde EduSource, estudiantes y profesores pueden realizar búsquedas federadas a los distintos repositorios que recoge, algunos de ellos estadounidenses o australianos: Eureka, RDN, EDNA, POND, ADLIB, SAVOIRNET, UQTR, INNOVA, eRIB, CAREO, testHB, eklexis, SMETE. El esquema de metadatos que utiliza es un perfil de aplicación denominado CanCore, basado en el estándar IEEE LOM y la especificación IMS Learning Resource Metadata.

CanCore v.2.0 pretende ser una simplificación de LOM, tomando 61 de sus 77 elementos (todos ellos igualmente opcionales), así como una guía de aplicación y buenas prácticas para todos aquellos que deseen implementar dicho estándar. En

cuanto a los elementos educativos incluidos en el perfil, es destacable el hecho de que CanCore no recomiende el uso de los elementos LOM 5.1.TipoDeInteractividad, 5.3.NivelDeInteractividad, 5.4.DensidadSemántica, 5.8.Dificultad y 5.10.Descripción, bien por considerar que la información que ofrecen es redundante (todos menos 5.8) o porque son de difícil interpretación (caso de 5.4), de escasa utilidad (caso de 5.4 y 5.8) o de coste elevado (caso de 5.10). 8.1.5.4. GEM Es un proyecto del Departamento de Educación estadounidense y ERIC (Education Resources Information Center) que pretende dar acceso desde una plataforma única a la vasta colección de recursos albergados en sus distintas instituciones educativas. Su esquema descriptivo, perfil de aplicación de Dublin Core, tiene tres versiones: Gateway Lite, que representa el nivel mínimo de descripción con un número de elementos obligatorios, Gateway Full, que ofrece un nivel de descripción intermedio con los elementos obligatorios del anterior y algunos opcionales y GEM, que es el nivel de descripción más completo, siendo todos sus elementos opcionales y repetibles.

Señalamos a continuación las extensiones propuestas por GEM: Elemento Audience Age Beneficiary

EducationLevel

Mediator Prerequisites Cataloging CatalogingOrganization CatalogingTool IndividualCataloger Duration Essential resources

Descripción y uso Tipo de usuarios potenciales del recurso Edad de los potenciales usuarios del recurso. Tipo de usuarios potenciales del recurso, según lista de valores propia: Administrators, Students, Teachers, Librarians, Vision-impaired students, etc. Nivel educativo de los usuarios potenciales del recurso, según lista de valores propia: Grade (Kindergarten-12) y Educational Level (All, Unspecified, Adult/continuing education, Community College, Higher education, Preschool education, Vocational education). Persona o entidad que media en el acceso al recurso, según lista de valores propia: Administrators, College/University instructors, Curriculum Supervisors, etc. Conocimientos previos de que ha de disponer el usuario potencial del recurso para la su correcta utilización. Datos de catalogación Entidad que realiza la catalogación. Herramienta de catalogación empleada: esquema empleado. Nombre del catalogador. Tiempo típico de utilización del recurso Recursos técnicos requeridos para la utilización del recurso

Instructional method

Assessment

Grouping

Teaching methods

Método instructivo Tipo de evaluación desarrollada en el recurso, según lista de valores propia: Alternative assessment, Authentic assessment, Curriculum based assessment, Informal assessment, Observation, Peer evaluation, Portfolio assessment, Self evaluation, Standardized testing, Testing. Tipo de agrupación de estudiantes necesario para la utilización del recurso, según lista de valores propia: Cross age teaching, Heterogeneous grouping, Homogeneous grouping, Individualized instruction, Large group instruction, Non-graded instructional grouping, Small group instruction. Descripción del método instructivo empleado en el recurso, según lista de valores propia: Brainstorming, Computer simulations, Demonstrations, Discovery learning, Experiential learning, Project-based learning, etc.

8.1.5.5. MERLOT Es un repositorio desarrollado por un consorcio de cuatro instituciones universitarias estadounidenses que recoge recursos web aportados por sus usuarios de naturaleza y temática diversa de utilidad para profesores y estudiantes universitarios. Su esquema descriptivo toma como referencia el estándar LOM, incorporando entre sus extensiones locales el elemento Average Ratings, en el que se recoge la evaluación de los recursos incorporados realizada por un grupo de docentes en función de la calidad de su contenido, su potencial efectividad como herramienta didáctica y su facilidad de uso.

Elemento Average Ratings

Type Title or name Location Mirror Site

Primary Subject Category

Author Description Submitted by Primary Audience Technical Format

Descripción y uso Valoración, del 1 al 5, de tres aspectos: calidad de su contenido, su potencial efectividad como herramienta didáctica y su facilidad de uso. Tipo de recurso, según lista de valores: simulación, animación, tutorial, ejercicios y prácticas, tests, presentaciones y materiales de clase, estudios de caso, colecciones y materiales de referencia. Título o nombre del recurso. Ubicación del recurso (generalmente URL). Ubicación alternativa del recurso. Categoría/s temática/s del recurso, según clasificación propia cuyas grandes categorías son: Arte, Negocios, Educación, Humanidades, Matemáticas, Ciencia y tecnología y Ciencias sociales, teniendo además una categoría específica para Documentación dentro de Educación. Autor o entidad responsable del recurso. Descripción del recurso. Responsable de la incorporación del recurso al repositorio. Principales usuarios a los que se dirige el recurso, según lista de valores: Grade School, Middle School, High School, College, Graduate School, Professional. Formato del recurso, según lista de valores: Java applet, Shockwave, Flash, Director file, Authorware file,

Language(s) Section 508 Compliant Cost Involved with Use Copyright and/or Other Restrictions Source Code Available

HTML/txt, Video, Audio, Image, VRML, Javascript, ActiveX, CD-ROM, PDF, Executable program. Idioma del recurso, según ISO 639-1. Adecuación del recurso a la sección 508 de la “Rehabilitation Act” del gobierno estadounidense, que regula la accesibilidad de los recursos Web para personas con algún tipo de discapacidad. Coste de uso. Restricciones de uso. Disponibilidad de acceso al código fuente del recurso.

8.1.5.6. The Learning Federation Es un proyecto que forma parte de la Schools Online Curriculum Content Initiative (SOCCI), iniciativa de los gobiernos australiano y neozelandés con la que se pretende potenciar el uso de contenidos digitales de calidad en sus escuelas mediante su colaboración, en un periodo de cinco años que concluyó en 2005, en la producción de objetos de aprendizaje y de plataformas para la gestión e intercambio de los mismos . Su esquema descriptivo, el Learning Federation Metadata Application Profile (v.2.0), es un perfil de aplicación de LOM, y uno de los más ricos en extensiones locales, considerando entre ellas elementos relacionados con el contexto de aplicación de los recursos descritos (Curriculum, Learning area, Strand, Sector) o su posible utilidad didáctica (Educational value).

Observa la utilización obligatoria de los siguientes elementos:

Clave: 1=Objetos de aprendizaje, 2=Recursos digitales, x=obligatorio Elemento 1 2 Descripción y uso Características generales del recurso 1 General Subelementos LOM considerados obligatorios tanto para 1 como para 2: 1.1.1.1 Catalogue, 1.1.1.2 Entry, 1.1.2 Description, 1.1.3 Keyword, 1.1.7 Aggregation Level, 1.2.1 Version, 1.2.2.1 Status, 1.2.2.2 Date, 1.2.2.2 Remark, 1.2.3.1 Role, 1.2.3.2 Entity, 1.3.2 Language. Características didácticas del recurso 2 Educational 2.1 Subject Equivalente a Subject del Dublin Core Metadata x 2.1.1 Topic Element Set, describe el contenido del recurso a partir del School Online Subject Thesaurus (ScOT) Extensión local (TLF), describe la parte del curriculo x 2.1.2 Curriculum en que se inscribe temáticamente. Extensión local (TLF), describe las áreas de estudio a las que se adscribe el contenido del recurso, según el 2.1.2.1 Learning vocabulario Edna KLA (Key Learning Areas): English, x area Mathematics, Science, Studies of Society and Environment, Health and Physical Education, Arts, Languages Other Than English (LOTE), Technology. Extensión local (TLF), describe las secciones de las áreas de estudio a partir de una lista de valores x 2.1.2.2 Strand propia. Para English, por ejemplo, los valores asignados son: Listening and Speaking, Reading and writing y Viewing. Extensión local (TLF), describe el tipo de resultado didáctico que persigue el contenido del recurso (por lo general, actitudinal o competencial), según lista de 2.1.2.3 x valores propia. Algunos de los valores asignados a Content/concept English, por ejemplo, son: Argumentation, Challenging ideas, Critical literacy, Reading, etc. Extensión local (TLF), describe las habilidades y procesos cuyo aprendizaje persigue el contenido del 2.1.2.4 x recurso, según una lista de valores tomados de la Skills/process taxonomía de Bloom: Knowledge, Comprehension, Application, Analysis, Synthesis y Evaluation. Equivalente a Type del Dublin Core Metadata 2.2 Resource type Element Set, describe la tipología del recurso. Extensión local (TLF), describe el tipo de actividad que presenta el recurso, según lista de valores 2.2.1 Student activity x propia: Comprehension activity, Concept map, Experiment, Practical activity, etc. Extensión local (TLF), describe los métodos y formas de presentación de los materiales, según una lista de valores propia: Auditory learning, Collaborative learning, Demonstrations, Experiential learning, 2.2.2 Learning design x Independent learning, Inquiry learning, Mentoring, Peer tutoring, Problem solving, Resource based learning, Tactile/kinaesthetic learning, Visual learning, Team teaching, Testing.

x x x x

Equivalente a Audience del Dublin Core Metadata Element Set, describe las caracteristicas del potencial usuario del recurso. Equivalente a Audience del EDNA Metadata Standard, identifica el colectivo escolar a que se dirige el recurso, según su lista de valores: Student, Teacher/lecturer, Parent/carer, Administrator, Community member. Equivalente a Sector del EDNA Metadata Standard, identifica el nivel educativo al que se dirige el recuro, según una lista de valores tomados del vocabulario EDNA: Preschool, School, Vocational education and training. Equivalente a Userlevel del EDNA Metadata Standard, indica el año escolar al que se dirige el recurso (de 0 a 13, según los Australian Qualification Levels, AQF). Extensión local (TLF), describe los objetivos didácticos del recurso. Se consigna a texto libre. Extensión local (TLF), trata de describir la posible utilidad didáctica del recurso. Características técnicas del recurso. LOM LOM LOM LOM

LOM

2.3 Audience

2.3.1 Type

2.3.2 Sector

2.3.3 User level

2.5 Key learning objective

x x

2.6 Educational value 3 Technical 3.1 Format 3.2 Size 3.3.1 Type 3.3.2 Name 3.3.3 Minimum version 4 Rights Management 4.1 Rights 5 Accesibility

5.2 Access profile

Restricciones de uso del recurso. LOM Características de accesibilidad del recurso. Extensión local (TLF), describe las características de accesibilidad del recurso, según una lista de valores propia: Visual independence, Colour independence, Hearing independence, Physical independence, Device independence, Cognitive support

8.2. Incorporación de metadatos a recursos educativos: herramientas y procedimientos En esta sección nos acercamos a las herramientas de edición y creación de paquetes de contenidos educativos mediante el análisis de dos de las más destacadas: CourseGenie y Reload. Ambas permiten generar objetos de aprendizaje a partir de la integración de distintos tipos de recursos así como paquetes de contenidos SCORM convenientemente descritos. 8.2.1. CourseGenie CourseGenie es una aplicación comercial desarrollada por Wimba (se puede descargar una versión de prueba desde la página del producto http://www.wimba.com/products/coursegenie/) que funciona como plugin de Microsoft

Word y que permite generar objetos de aprendizaje en HMTL y paquetes SCORM e IMS a partir de textos (que la aplicación traduce antes a XML, como codificación intermedia). El procedimiento general y más sencillo para editar objetos de aprendizaje y generar paquetes de contenido con CourseGenie será el siguiente: 1. En primer lugar, instalaremos el software siguiendo para ello las instrucciones del fabricante. 2. Una vez instalada, arrancamos la aplicación una vez abierto el texto a tratar (en el ejemplo, una práctica de “Análisis de Contenido”. El documento puede contener imágenes.

3. En primer lugar, describimos el documento agregando los metadatos pertinentes. Para ello, abrimos en el menú “CourseGenie” la opción “Metadata”. En la ventana “Course Genie Metadata” que se nos ofrece, iremos rellenando las distintas solapas con la información correspondiente. Observe que los datos están tomados del esquema general LOM que, como ya comentamos anteriormente, es el empleado por SCORM e IMS.

La aplicación generará una tabla al comienzo del documento que contendrá los valores asignados a los distintos elementos:

4. A continuación, procedemos a segmentar el texto base, identificando cada una de las partes que lo estructuran mediante las etiquetas facilitadas por la herramienta a tal efecto. En primer lugar, seleccionamos el título del documento y le aplicamos el estilo “cgPageTitle”, disponible en la lista desplegable.

5. Seguidamente, hacemos lo mismo para cada sección del documento, esta vez aplicando el estilo “cgSectionTitle”:

6. Finalmente, generamos el paquete de contenido. Para ello: a. En el menú “CourseGenie” seleccionamos “Generate Course” (generar curso). b. Seleccionamos una ubicación para la carpeta de contenido:

Aparecerรก una ventana que nos informarรก sobre el progreso y resultado de la acciรณn.

c. Visualizamos el contenido HTML generado:

Si queremos generar un paquete SCORM, seleccionaremos esta opción en el menú “Settings” de CourseGenie (solapa “Content”) antes de generar el contenido (“Generate Course”).

Observaremos que el paquete zip contiene el índice o manifiesto del que ya hemos hablado:

El contenido está en este momento preparado para ser captado por distintas plataformas educativas, descrito y sin perder su estructura original.

8.2.2. Reload Reload (Reusable Learning Object Authoring and Delivery) es una aplicación opensource para la creación de paquetes de contenido desarrollada gracias a la financiación de la entidad británica JISC (Joint Information Systems Committee, http://www.jisc.ac.uk/). Se puede descargar gratuitamente en http://www.reload.ac.uk/, y dispone de versiones en varios idiomas, entre ellos el español. El procedimiento general y más sencillo para generar paquetes de contenido con Reload será el siguiente: 1. Una vez instalado el programa, crearemos en primer lugar una carpeta en la ubicación que se desee, en la que guardamos los distintos archivos que compondrán el paquete. Por ejemplo, una carpeta denominada “SCORM”. 2. Creamos un nuevo paquete SCORM (Archivo > Nuevo > Paquete SCORM).

3. Seleccionamos la carpeta creada en el punto 1. Se nos presentarán los distintos contenidos que contiene. En este momento, la aplicación crea el índice o manifiesto del paquete.

4. A continuación, identificamos el esquema de metadatos que utilizaremos para describir el contenido del paquete. Para ello, pinchamos el manifiesto con el botón derecho del ratón y seleccionamos “Añadir metadatos”. Pinchamos con el botón

derecho del ratón sobre “metadatos” y seleccionaremos “añadir esquema”, seleccionando el esquema adecuado. Describimos el contenido complentando el formulario (botón derecho sobre “Metadatos” > “Editar metadatos”).

5. Seguidamente, diseñaremos una estructura para los contenidos (“Organizations”). Para ello, generamos una organización que renombramos como “main”, que será la raiz o nivel superior de la jerarquía en la que se organizarán los contenidos.

6. A esta organización principal vamos incorporando los archivos que conforman el objeto de aprendizaje, simplemente seleccionándolos de la lista de recursos de la

carpeta SCORM, arrastrándolos y dejándolos sobre la organización “main”. En ocasiones, deberemos renombrar los items.

7. Previsualizamos el paquete de contenidos, comprobando que el proceso se ha realizado correctamente (Ver > Previsualizar paquete de contenidos).

8. Finalmente, guardamos el paquete de contenidos (Archivo > Comprimir paquete de contenidos). El paquete está ya listo para ser incorporado a distintas plataformas de elearning.

8.3. Bibliografía IEEE LTSC (2002). Estándar para metadatos de objetos educativos [en línea]. IEEE P1484.12.1-2002. Disponible en: <www.cenorm.be/cenorm/businessdomains/businessdomains/isss/activity/lomspanish1 .doc>.