Desarrollo de un repositorio de objetos de aprendizaje

Transcripción

1 Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería Licenciatura en Informática sede Trelew Proyecto de Tesina Desarrollo de un repositorio de objetos de aprendizaje Tesina presentada para cumplir con los requisitos finales para la obtención del título de Licenciatura en Informática. Alumnos: Tutora: APU Federico Alberto Cajal APU Paula Andrea Moraga Mg. Ing. Zulema Beatriz Rosanigo Diciembre 2010 i

2 Índice ii

3 ÍNDICE... II RESUMEN INTRODUCCIÓN FUNDAMENTOS TEÓRICOS INTRODUCCIÓN AL E-LEARNING Learning Management System (LMS) Content Management System (CMS) PARADIGAMA DE OBJETOS Nociones de Objetos de Aprendizaje Nociones de Repositorio Estado actual del Paradigma ESTÁNDARES Ventajas de estándares de e-learning Proceso de desarrollo de estándares Estándares de Metadatos Estándares de Content Packaging (CP) Estándares de Learner Profile Estándares de Learner Registration Estándares de Content Communication Estándares de Repositorios Perfiles de aplicación Iniciativas y Consorcios OPEN ACCESS (ACCESO ABIERTO) Qué es OAI? Protocolo OAI-PMH INTRODUCCIÓN AL SOFTWARE LIBRE Free Software y Open Source LICENCIAS Qué es una licencia de software? Copyright vs Copyleft? Distintos tipos de Licencias de software Creative Commons ANÁLISIS DE HERRAMIENTAS DISEÑO DE OA Y ROA HERRAMIENTAS DE CREACIÓN DE OA Reload Editor Exe-learning MOS Solo Hot Potatoes CourseLab Microsoft Learning Essentials HERRAMIENTAS DE CREACIÓN DE ROA Door Ariadne Ariadne DSpace PlanetDR iii

4 4 DESARROLLO ANÁLISIS DE VIABILIDAD Análisis de las alternativas Comparativa Decisión ANÁLISIS Y DISEÑO DE LA SOLUCIÓN Instalación De DSPACE Arquitectura Funcionalidades Estándares y protocolos ALCANCES DEL PROYECTO Funcionalidades agregadas Funcionalidades quitadas Funcionalidades modificadas TRABAJOS FUTUROS CONCLUSIONES ANEXOS APACHE MAVEN Convención sobre Configuración Una interfaz común Plugins Modelo conceptual de proyecto Comparación con Ant APACHE ANT Funcionamiento MANAKIN Funcionamiento Arquitectura de Manakin LNI Diseño Funcionamiento METS Estructura MODS Estructura EXPERIENCIA CON DOOR BIBLIOGRAFÍA GLOSARIO iv

5 Resumen 1

6 En esta tesina se presenta el desarrollo de un Repositorio de Objetos de Aprendizaje que hemos denominado Graduate!. Esta iniciativa parte de nuestro deseo de combinar la Informática con el área educativa de modo que las dos trabajen colaborativamente y se fortalezcan, haciendo que la tecnología sirva de apoyo al sistema educativo universitario, y al mismo tiempo, satisfacer la necesidad de contar con un repositorio en el proyecto de investigación 628 de nuestra universidad, Hacia un Repositorio de Objetos de Aprendizaje. Primeramente se plantea un análisis del estado de arte del e-learning y particularmente del paradigma de objetos de aprendizaje, prestando mayormente atención al modo en que se almacenan estos objetos en un Repositorio de contenido educativo. Luego se hace un estudio de los estándares e-learning y se presentan las distintas organizaciones o iniciativas que participan en su desarrollo. Se detalla el estándar LOM, el modelo de referencia SCORM y otras especificaciones que se están usando actualmente en la industria del e-learning. Además se analizan las tecnologías informáticas actuales que colaboran en el servicio educativo con las que se pueden diseñar objetos de aprendizaje y construir repositorios de los mismos. Se evalúan distintas alternativas para el desarrollo del repositorio y se analiza con profundidad una a una las funcionalidades y características que presenta el software DSpace, el cual fue adoptado para la implementación de Graduate!. Finalmente se describen las adaptaciones realizadas para soportar el estándar de metadatos LOM y proveer funcionalidad para importar y exportar paquetes de contenido SCORM. 2

7 1 Introducción 3

8 En el año 2007 fuimos partícipes de un proyecto de investigación de nuestra facultad, que nos motivó a conocer como se aplicaban los recursos y tecnologías en la educación y el aprendizaje universitario. Ésto generó un interés para lograr que un sistema TIC (Tecnologías de la información y la comunicación) se aplique y se desarrolle en nuestra institución. Para ello tuvimos que investigar y adquirir conceptos educativos desconocidos para nosotros, ya que en nuestro rol de estudiantes, no habíamos tenido oportunidad de pensar como educadores o formadores de contenidos. Nuestro objetivo es lograr combinar la Informática con el área educativa de modo que las dos trabajen colaborativamente y se fortalezcan, haciendo que la tecnología sirva de apoyo al sistema educativo universitario. Como el e-learning es un área que no ha sido localmente muy explotada, ha impulsado aún más nuestras ganas de generar algo original de gran utilidad práctica que pueda convivir en nuestro entorno para facilitar y consolidar la comunicación entre todos los actores que participan en el proceso educativo como alumnos, docentes, investigadores y generadores de contenidos. Como profesionales de la informática y al mismo tiempo estudiantes, nos interesaba desarrollar un producto que cumpla con las necesidades de mejorar y ayudar a elaborar nuevas tecnologías que fortalecieran nuestro entorno educativo. Nuestro interés era generar un trabajo innovador y beneficioso para la comunidad educativa dentro de nuestro ámbito. Por eso pensamos en promover el uso de la informática dentro de la educación, a través del almacenamiento y reuso de contenidos creados dentro de nuestra universidad, y de esta manera contribuir con el proyecto de investigación Hacia un Repositorio de Objetos de Aprendizaje 1. Así surgió la propuesta de desarrollar un Repositorio de Objetos de Aprendizaje, para crear, contener, incorporar y compartir los contenidos educativos. El repositorio es una aplicación Web responsable de la organización de sus contenidos, del método de acceso y publicación/exposición de los mismos. Los objetivos planteados han sido: 1. Investigar sobre e-learning, la importancia de las nuevas tecnologías y la utilización de los OAs dentro del sistema educativo. Para poner en práctica y realizar una valoración real y pragmática de lo que hemos investigado. 2. Comprender profundamente la estructura y semántica de los OAs. Aprender a realizar buenos diseños de objetos de aprendizaje (OA), incluyendo selección de estándares de empaquetado, de metadatos, de navegación de contenidos. Para poder reutilizarlos y visualizar las características dentro de otros sistemas, como por ejemplo los LMS. 3. Analizar el estado del arte de los repositorios actuales en el mundo y elegir qué diseño de repositorio se adapta a nuestra necesidad. Seleccionando así un modelo de repositorio a crear. 4. Diseñar e implementar un ROA de acuerdo a nuestras necesidades y que cumpla con los estándares mundiales. 1 PI /E067 UNPSJB Hacia un Repositorio de Objetos de Aprendizaje, Directora: Mg. B. Rosanigo, 4

9 5. Afianzar nuestros conocimientos sobre software libre, trabajo colaborativo, que nos permitan difundir nuestro trabajo, logrando un avance significativo en nuestra región o país, al usar una tecnología tan poco conocida. Luego de un fuerte trabajo investigativo y de desarrollo logramos cumplir nuestras metas implementando el Repositorio de Objetos de Aprendizaje que hemos denominado Graduate! para uso de los estudiantes y profesores de la facultad. Éste permitirá compartir los OAs con otras universidades y con el mundo. Estamos conscientes que nuestro aporte será significativo y de gran flexibilidad de adaptación a distintas finalidades. Ya que nuestro repositorio podrá satisfacer las necesidades de una simple biblioteca digital, como también una completa organización semántica de contenidos educativos. Deseamos que realmente sea de utilidad, ya que estamos siendo pioneros con esta experiencia a nivel local y regional. Sabemos que el cambio necesita un período de adaptación, pero somos optimistas en este sentido, esperando que la filosofía de compartir sea ampliamente aceptada. Este proyecto de tesina está organizado en áreas temáticas. Comenzamos dando una introducción a los temas que abordamos y desarrollamos a lo largo del proyecto. Luego de la introducción, profundizamos los conceptos teóricos en particular para dar inicio al análisis e implementación de nuestro repositorio universitario de objetos de aprendizaje. A continuación realizaremos un recorrido por los capítulos de este trabajo. Fundamentos teóricos: Empezamos con un pantallazo de cómo ha ido evolucionando la educación e-learning hasta llegar a la actualidad donde es casi habitual hablar de LMS (Learning Management System) o plataformas de aprendizaje. Luego se introducen los conceptos de Objetos de Aprendizaje (OA) y Repositorios de Objetos de Aprendizaje (ROA). Los OA son un conjunto de recursos educativos que pueden ser reutilizados en diferentes contextos y que son descriptos a través de metadatos (datos de datos) para ser fácilmente localizados. Los ROA son los sistemas que permiten el almacenamiento, la catalogación o clasificación y la recuperación de los OA. Junto con ellos se detallan los estándares que permiten que los OA puedan ser intercambiados por los distintos sistemas de la industria de la enseñanza. Además éste capítulos hace referencia de cada una de las organizaciones e iniciativas implicadas en el proceso de desarrollo de estándares y cómo surge el trabajo en conjunto entre ellas desde los orígenes del movimiento e-learning. Se hace mención a la filosofía de acceso abierto a la información, el software libre y por último a las distintas licencias de software que existen en la actualidad. Estos conceptos han influido sobre nuestra elección en el desarrollo de un Repositorio de OA. Análisis de las herramientas: En este capítulo se detallan las herramientas con las que es posible realizar diseños de OA y otras que permiten construir distintos tipos de repositorios locales. Se analizan las ventajas y desventajas de cada una de ellas, de acuerdo con las necesidades de actuales. Este análisis y comparativa refleja el 5

10 contexto actual de las herramientas que se pueden utilizar en el área del e-learning y con esta información se avanza hacia el análisis y desarrollo del proyecto. Desarrollo: Se plantea el proyecto formalmente y se analizan los requerimientos técnicos y semánticos. Se analizan con más detalle las herramientas para la construcción de repositorios. Se decide realizar el desarrollo partiendo de la base que nos brinda un software robusto y personalizable como DSpace, tras descartar algunas otras opciones. DSpace es el software actual que mejor se adapta a nuestras necesidades a nuestro entender. Se modifica la plataforma DSpace y se realiza una descripción de las modificaciones en forma comparativa. Luego de este arduo proceso nace Graduate!. Anexos: En este capítulo se profundizan temas afines con el desarrollo del proyecto como por ejemplo: Maven, Ant, Manakin, LNI, METS, MODS, etc. 6

11 2 Fundamentos teóricos 7

12 2.1 INTRODUCCIÓN AL E-LEARNING Durante los últimos tiempos, el área educativa mundial ha sufrido muchos cambios, y uno de los más importantes es la inclusión de la tecnología para facilitar el aprendizaje, aplicando conocimientos y recursos innovadores que mejoren y ayuden a la enseñanza. Esto se pudo impulsar mundialmente gracias a la existencia de la comunicación masiva e instantánea como la que proporciona la red de redes, tan conocida como Internet. La utilización de nuevas herramientas tecnológicas en las distintas experiencias educativas actuales es más factible ya que las nuevas generaciones de estudiantes viven rodeadas de tecnologías. Ellos mismos fomentan el uso de tecnologías y se hacen rápidamente adeptos de una nueva forma de aprender que va cambiando los sistemas educativos del pasado. Es como una gran rueda que no se detiene. Por ello se han diseñado herramientas de apoyo a la educación, usando computadoras y sistemas informáticos o electrónicos. Con la aparición de la PC, y su masificación, el mundo informático ingreso en la vida social de los alumnos y docentes. Las tecnologías de desarrollo de software avanzaron sobre el sistema educativo, a tal punto que fue imprescindible que se enseñaran carreras relacionadas con la informática y las tecnologías. La red mundial Internet, comunicado y distribuye información masivamente, lo que ha sido un puntapié inicial para usar esta comunicación como método de enseñanza y publicación masiva de contenidos. Así nace la nueva modalidad de e-learning (enseñanza electrónica), usando la PC el alumno puede obtener los contenidos y conceptos necesarios. Esta nueva forma de aprendizaje se amplió rápidamente y se desarrollaron muchos sistemas de apoyo LEARNING MANAGEMENT SYSTEM (LMS) Los Sistemas de Gestión del Aprendizaje LMS (Learning Management Systems de sus siglas en inglés) son aplicaciones Web que permiten el acceso a los contenidos, la gestión de los recursos y la comunicación entre todos los actores involucrados en el proceso de enseñanza Web. Son parte de este proceso educativo alumnos, profesores, aquellos encargados de la generación de material educativo (crear y diseñar contenido) y administradores del sistema Web responsables de la gestión de cursos, recursos y de la seguridad entre otros aspectos. Ejemplos mundialmente utilizados por diferentes organizaciones y universidades son Moodle, Atutor, WebCT, Claroline, Dockeos, etc. La plataforma LMS permite gestionar el acceso, permisos y las actividades de los usuarios (inscripción, control de qué contenidos son accedidos, notas de evaluaciones) que facilita la generación de informes y estadísticas de uso. Además proporciona distintos servicios de comunicación tales como Chat o conversaciones, videoconferencia, foros de discusión, etc. 8

13 2.1.2 CONTENT MANAGEMENT SYSTEM (CMS) Con el objetivo de crear aplicaciones Web fáciles de mantener surge hace unos años, el concepto de Sistemas de Gestión de Contenidos CMS (Content Management Systems de sus siglas en inglés). Estas herramientas permiten, además de crear, mantener una aplicación Web con facilidad, esto es gestionar los contenidos en forma efectiva. En sus comienzos los CMS surgieron como apoyo a las organizaciones que publicaban gran cantidad de contenido y actualizaban continuamente en Internet por que se relaciona, a veces, la palabra CMS a herramientas de publicación de información. Sin embargo estas herramientas proporcionan además, servicios de soporte a la toma de decisiones (sistema de soporte a la gestión de contenidos). Un CMS permite realizar distintas acciones con los contenidos entre las que se destacan: El gestor de contenidos posibilita y facilita la publicación de contenido en el portal por cualquier usuario sin que este tenga conocimientos de programación. Manejo dinámico de usuarios y permisos. Mecanismos de comunicación para que los usuarios trabajen en colaboración. Tareas como actualizar, hacer copias de seguridad y restaurar el portal son viables de realizar ya que el gestor tiene una base de datos centralizada con todos los contenidos. Existe gran variedad de CMS en la actualidad dependiendo de su funcionalidad: genéricos, específicos para ONG, Foros, Blogs, Wikis, e-learning, etc. En particular los e-learning (LMS) son aquellos utilizados para la enseñanza. Profesores y alumnos hacen uso de la herramienta para la transferencia del conocimiento, por medio de aulas virtuales donde el profesor pone a disposición de los alumnos los materiales educativos. Además del LMS existen sistemas especializados para la Gestión de Contenidos Educativos LCMS (de Learning Content Management System en inglés,) que son herramientas donde los generadores de contenidos (generalmente profesores) pueden crear, almacenar, gestionar y presentar contenidos digitales almacenados en un repositorio centralizado. Los LCMS respetan el concepto básico de los CMS, que es la administración de contenidos, pero enfocados en el ámbito educativo, administrando y concentrando únicamente recursos educativos y no todo tipo de información. 2.2 PARADIGAMA DE OBJETOS NOCIONES DE OBJETOS El concepto importante en la educación e-learning es la utilización de objetos de aprendizaje (OA), por medio de los cuales se elaboran contenidos reutilizables. Si bien esto no es obligatorio, pues existen sistemas de e-learning que no emplean OAs, es recomendado el uso de OAs por numerosos factores que veremos más adelante. Los OAs son piezas digitales que contienen material de estudio para lograr un mecanismo 9

14 de aprendizaje, promoviendo la interacción de los alumnos y sus docentes en un sitio Web que presenta sus contenidos. Los OAs pueden ser utilizados en varias oportunidades en entornos y contextos diferentes. Es por esto que brindan la posibilidad de reuso, y de construcción de áreas temáticas, cursos, exámenes, etc. Varios docentes pueden hacer uso del mismo OA con distintos objetivos de enseñanza. Un objeto de aprendizaje se define como conjuntos de objetos de información seleccionados y ensamblados alrededor de un objetivo [7]. Un objeto de información (OI) es una pieza o unidad de información (la más pequeña) que puede ser utilizada como entidad independiente y que posee un nombre único que la identifica por ejemplo un video, una imagen, un artículo, una definición, un procedimiento, un sonido, etc. Un OI es un recurso digital que no incluye ninguna estructura o envoltura educativa. Un ejemplo de ello sería un vídeo que muestra un proceso de fabricación en el cual el OI sería el recurso (video) sin datos acerca de quién lo desarrolló, detalles de cómo usarlo, etc. Los objetos de información por lo general son almacenados en repositorios digitales no educativos. Muchas veces los OAs se confunden con los OIs. Los objetos de aprendizaje incluyen un objetivo de aprendizaje, además pueden contener componentes educativos con resultados, evaluaciones así como también información del propio objeto. Uno de los mayores problemas de la utilización de objetos de aprendizaje es la incapacidad de las instituciones participantes en ponerse de acuerdo acerca de lo que compone a un objeto de aprendizaje. Definir el tamaño, el alcance y la granularidad de OA puede ser una tarea difícil, pero es fundamental para la creación de OAs reutilizables que puedan ser usados en distintos contextos. Una característica primordial, es que los OAs están constituidos por material educativo y además información sobre sí mismos. Esta información se denomina metadatos. Estos metadatos son de vital importancia a la hora de buscar, almacenar y publicar los contenidos. La correcta y completa disponibilidad de metadatos de un OA permite que sea fácilmente ubicado, catalogado en algún repositorio de OAs y posteriormente utilizado en su software de e-learning, aumentando su calidad y popularidad NOCIONES DE REPOSITORIO Los OAs se deben poder ensamblar criteriosamente para construir una unidad de conocimiento más abarcativa. Para que estos recursos, provenientes de distintos orígenes, sean verdaderamente explotados han surgido iniciativas y tecnologías para organizar su almacenamiento de manera de potenciar su reutilización, tales como bibliotecas digitales o repositorios de objetos de aprendizaje. Un repositorio de OA (ROA) es una colección estructurada de OA que brinda facilidades para ubicarlos por contenidos, áreas, categorías y otros descriptores, por medio de sus metadatos. Los OAs son catalogados en ROAs con la finalidad de que estén disponibles al público y sean utilizados en diferentes contextos de aprendizaje como aulas virtuales, lecciones, cursos, etc. Para que un ROA cumpla su objetivo los OA almacenados en él deben estar correctamente etiquetados, estructurados y organizados para poder ubicarlos e 10

15 identificarlos, como lo haría una biblioteca común con sus libros, lo cual es gracias a la utilización de los metadatos ESTADO ACTUAL DEL PARADIGMA Tecnología para la creación de contenido educativo Veremos cómo están evolucionando los contenidos educativos dentro del contexto de enseñanza digital. Apuntando a llegar a la última de las etapas en la construcción colaborativa de contenidos educativos. En la primera etapa encontramos contenidos creados por los docentes, utilizando aplicaciones ofimáticas, como pueden ser documentos de texto o presentaciones multimedia, que son compartidas con los alumnos por medio de la exposición en clase usando proyectores, cañones multimedia, etc. En una segunda etapa, podemos recalcar el interés de que los contenidos creados en la primera etapa estén publicados en la Web. Es decir, se destaca el incentivo de compartir contenidos educativos masivamente, por lo que se crean páginas estáticas o dinámicas con el contenido embebido o incrustado para bajarlo. Son un ejemplo claro, los documentos en pdf, presentaciones multimedia o diapositivas. En una tercera etapa en la que estos contenidos ya están disponibles en la Web, se busca una aproximación más integral a la elaboración de contenidos de aprendizaje. Se desea establecer un sistema de campus virtual online que sirva de apoyo a la enseñanza tradicional presencial. Se busca la elaboración de materiales para la confección de cursos en línea, utilizando el apoyo de software LMS. Los contenidos se estructuran, se catalogan, se plantean objetivos de aprendizaje, y ésto conlleva a la utilización práctica del concepto de objetos de aprendizaje. El empleo de los OA dentro del e-learning brinda interoperabilidad de contenidos, búsqueda eficiente de información y la posibilidad de reutilización de los contenidos. Por último, la cuarta etapa denominada de creación colaborativa destaca la importancia de la creación de blogs y Wikis en los que se comparte y crean muchos contenidos educativos de forma desinteresada, al estilo de Internet. Actualmente existen muchas discusiones y controversias acerca del uso de objetos de aprendizaje dentro del ámbito educativo. No están claros los conceptos de OA y sus características, por lo que hace difícil la tarea de construir material educativo como si fueran piezas de lego. Esto es así porque es difícil la secuenciación y agregación de materiales educativos heterogéneos, de diferente granularidad y semántica. Además no hay consenso en la utilización de estándares, de repositorios de OAs, lo que genera muchas divisiones e implementaciones técnicas de los OAs. Lo más destacable es no perder el espíritu de compartir, de generar recursos educativos, con el mayor esfuerzo en cuanto a su calidad, pero sin perder de vista que en la práctica es muy difícil alcanzar los objetivos originales o ideales de los OAs. Para lograr un buen diseño de contenidos educativos, es necesario contar con herramientas versátiles y completas, así mismo esto no asegura la calidad final del proceso enseñanza-aprendizaje, ya que el docente puede no utilizar correctamente todas las herramientas disponibles o los alumnos no aprovechar la comunicación ofrecida por los entornos virtuales de capacitación (LMS). Es por esto que debemos 11

16 apuntar a obtener los mejores resultados posibles, dando a los docentes las herramientas necesarias, como así también una capacitación eficiente para lograr buenos diseños de los contenidos, logrando así calidad técnica, calidad de contenidos educativos y calidad humana por parte de los docentes para unir los aspectos técnicos y pedagógicos dentro de un entorno virtual Objetos de Aprendizaje En la actualidad, en la mayoría de las instituciones que utilizan OAs, la generación de éstos es una tarea que sigue siendo responsabilidad de los docentes aunque algunos opinan que el personal técnico del organismo debería desempeñar un papel importante en la creación de OAs. En algunas instituciones se usan tecnologías para producir el material educativo pero la labor del profesor no es reemplazable. En estos casos existe una asociación entre lo técnico y el profesor, quien opera como experto en la materia. Esta asociación permite que los profesores se concentren en lo que mejor saben hacer, la investigación, la creatividad, la enseñanza sin tener que concentrarse mucho en la tecnología. Los estudiantes también desempeñan un papel como contribuyentes y usuarios de OA. Muchas veces los estudiantes sirven cono generadores de nuevos materiales: la experiencia de los estudiantes se utiliza para mejorar o chequear los OAs que pueden ser reutilizados en otros contextos de enseñanza. En cuanto al rol tradicional de catalogador de la información se puede decir que por mucho tiempo los bibliotecarios han cumplido con la tarea de catalogar todos los recursos publicados (bibliotecas digitales). Sin embargo, en el caso de la publicación de OAs, la tarea por lo general no se sabe de quien es responsabilidad. Muchas veces son los profesores los encargados de catalogar o etiquetar los OAs. Los docentes están incorporando OAs a sus cursos de aprendizaje virtual. La idea es generalizada y se está de acuerdo con que los objetos de aprendizaje se utilicen en la enseñanza para mejorar la calidad de la experiencia de aprendizaje. Muchos docentes utilizan OA debido a la eficiencia que les permite la reutilización de materiales en más de un curso o un ambiente de aprendizaje. Además se pueden diferenciar dos aspectos que afectan a la enseñanza, relacionados con la calidad del OA. [23] El primer aspecto está relacionado con la eficacia de la enseñanza en los entornos educativo donde los OAs son utilizados como herramientas de aprendizaje. Los creadores y diseñadores (por ejemplo profesores) de los contenidos deben producir OA con sentido pedagógico significativo, con los mismos objetivos que se plantean al elaborar contenidos en un entorno donde se aplican métodos tradicionales de enseñanza. Es decir que la enseñanza eficiente no depende de la utilización o no de OAs. Para asegurar que el aprendizaje sea eficiente se implementan, por ejemplo, sistemas de revisiones que monitorean y evalúan el éxito de la aplicación de contenidos educativos tanto en sistemas presenciales como virtuales. El segundo aspecto se refiere a la calidad de OA en sí mismo. Esta calidad se cuantifica observando y evaluando los recursos y la estructura del OA. Además es necesario definir las personas u organizaciones involucradas en el proceso de revisión y calificación de los OAs. Por ejemplo en los repositorios de OAs se realiza una 12

17 discriminación selectiva del material y se cuenta con equipos profesionales en educación que evalúan los objetos antes de su publicación Principales Repositorios MERLOT Merlot (Multimedia Educational Resource for Learning and Online Teaching) es uno de los repositorios más conocidos y en los últimos años ha marcado tendencia en cuanto al desarrollo de otros ROA. Es un repositorio centralizado donde se almacena únicamente los metadatos y las referencias a sitios remotos donde se encuentran los recursos. MERLOT está disponible en Es un repositorio abierto y de libre acceso donde cualquier usuario puede tener acceso a los OAs almacenados en MERLOT y únicamente los miembros pueden subir contenidos. Para ser miembro no se requiere más que inscribirse y no se adquiere ninguna responsabilidad. Está orientado principalmente a estudiantes y docentes de educación superior pero contempla otros niveles educativos. Es un repositorio que está en constante crecimiento. A principios de 2008 contaba con OAs y ahora cuenta con más de (consultado: octubre de 2010). Además en los últimos 30 días, por ejemplo se inscribieron 1000 miembros y se subieron 100 OAs al sitio. El repositorio provee búsquedas y otros servicios como personalización, importación y exportación de objetos. Además MERLOT ha desarrollado un formato estándar y un sofisticado sistema de revisión llamado Peer Reviews (revisión por pares). Siguiendo el modelo de revisión utilizado por las publicaciones académicas tradicionales donde equipos disciplinarios cuidadosamente seleccionados y entrenados revisan y valoran los objetos de aprendizaje relevantes a sus áreas de conocimiento. Los evaluadores pueden agregar comentarios que crean necesarios en la revisión. Los usuarios registrados en el repositorio pueden enviar nuevos contenidos educativos sobre los que se les permite: Agregar anotaciones o comentario. agregar tareas o ejercicios como por ejemplo si un OAs representa una lección se pueden anexar preguntas y respuestas indicando la URL donde está ubicado la actividad. Además a los usuarios registrados en Merlot se les brinda una herramienta llamada Colecciones personales que permite que el usuario agregue referencias a material enviado por otros usuarios para que sea más práctico identificar los objetos que son de mayor interés para él. Las búsquedas pueden ser (usuario registrado o no): Por palabra indicando tipo de material a buscar. Avanzada indicando metadatos. Navegar por categoría. Palabra más categoría limitando las búsquedas. MERLOT utiliza el estándar LOM (IEEE, 2002) para los metadatos de los OAs. 13

18 Revisión de pares Figura 1- Revisión por pares de un OA Merlot provee resúmenes que visualizan las actividades que presenta el repositorio. En este resumen aparecen, por ejemplo cuantos miembros se han subscriptos en los últimos 30 días, materiales agregados y revisados. Figura 2 - Resumen de la actividad reciente en el repositorio Colombia aprende Colombia Aprende es el Portal Educativo del Ministerio de Educación de Colombia y el registro en él permite hacer uso de servicios como correo, foros, chats y disco duro virtual. Además le permitirá obtener información de interés de manera exclusiva según el perfil al que pertenezca: Docentes, estudiantes, familia y comunidad, directivos o investigadores. También hay información para quienes no pertenecen a ningún perfil pero están interesados en la educación de Colombia. El portal Colombia Aprende está disponible en 14

19 Desde el portal existen accesos a distintos centros de recursos: Banco de Proyectos, Mediateca y Objetos de Aprendizaje (Objetos virtuales de aprendizaje). Centro de Recursos Figura 3 - Portal Colombia Aprende Acceso a Centro de Recursos. Cuando se accede al centro del recursos existe un link al ROA Nacional llamado Banco Nacional de Objetos de Aprendizaje (también llamado en el portal Banco Nacional de Recursos Educativos). Acceso al ROA Nacional (Banco Nacional de Objetos de Aprendizaje) Figura 4 - Portal Colombia Aprende Acceso al Banco Nacional El Banco Nacional de Recursos Educativos estuvo listo en junio de 2007 y fue el fruto del proyecto "Catalogación de Objetos de Aprendizaje en Instituciones de Educación Superior" en que participaron nueve universidades en cuatro regiones de Colombia, publicando más de 1700 objetos de aprendizaje e informativos. Además la iniciativa invita a la comunidad colombiana académica a que participe de ésta iniciativa, consultando el banco, comentando y valorando los objetos que se encuentran publicados. El material es de libre acceso y descarga, respetando la licencia de uso de cada universidad. El Banco Nacional de Recursos Educativos o Catalogo de Objetos de Aprendizaje de las IES (Instituciones Educativas de Nivel superior) cuenta con dos interfaces una para usuario público ( y otra para usuario registrado ( o ). 15

20 El ROA clasifica la información en [24]: Objetos de Aprendizaje: son diferenciados con color celeste y se definen como Un conjunto de recursos digitales que puede ser utilizado en diversos contextos, con un propósito educativo y constituido por al menos tres componentes internos: contenidos, actividades de aprendizaje y elementos de contextualización. Además, el objeto de aprendizaje debe tener una estructura de información externa (metadato) para facilitar su almacenamiento, identificación y recuperación. Objetos informativos: son diferenciados con color rosa y se definen como Un conjunto de recursos digitales que puede ser utilizado en diversos contextos educativos y que posee una estructura de información externa (metadato) para facilitar su almacenamiento, identificación y recuperación. La arquitectura del ROA es distribuida. Cada Institución de Educación Superior cuenta con un Banco de Objetos propio que permite en primer lugar, que sea la institución la que realice la evaluación del contenido que se va a publicar, en segundo lugar, no se lleva a cabo ninguna cesión de derechos patrimoniales de los autores al MEN (Ministerio Educación Nacional) ya que las IES (Instituciones de Educación Superior) publican el material bajo cualquier tipo de licenciamiento decidiendo si ceden los derechos patrimoniales sobre los objetos o si solamente permiten su uso, en tercer lugar, cada una de las IES cuenta con su propio banco de objetos adaptándolo de acuerdo a sus necesidades y velando por su sostenibilidad y evolución. [25] La Red Nacional de Banco de Objetos se le llama a las instituciones de Educación Superior de Colombia que cuentan con su propio Banco de Objetos y trabajan en forma distribuida con el banco nacional. Se tiene acceso de la siguiente manera: Acceso a la Red Nacional de Banco de Objetos Figura 5 - Acceso a la Red de Banco de Objetos. 16

21 Figura 6 - Universidades en la Red de Banco de Objetos Acceso a los ROA propio. En la siguiente tabla resumimos la información de las Universidades en la Red de Banco de Objetos (datos consultados octubre 2010): Universidad ROA Cantidad Objetos Universidad del Norte Universidad de Antioquia Pontifica Universidad Bolivariana Universidad EAFIT Universidad de la Sabana Universidad Minuto de Dios Universidad Nacional de Colombia Pontificia Javeriana de Cali TOTAL 1944 Volviendo al Banco Nacional de Objetos de Aprendizaje e Informativos podemos decir que éste tiene una organización por temas o áreas de conocimiento bajo las cuales se agrupan los diferentes Objetos de Aprendizaje y los Objetos Informativos. Además utiliza el estándar IEEE LOM para la descripción de los OAs. Cualquier persona que visite el portal, ya sea si es un usuario registrado o no, puede: Agregar comentarios a los OAs. Descargar el OAs. Valorar OAs, pero para ello debe acceder al contenido en el ROA propio de la Universidad que lo contenga. 17

22 Las búsquedas pueden ser: Por palabras. El listado muestra los resultados resaltando las palabras introducidas en la búsqueda. Navegar por áreas de conocimiento. Otras facilidades (llamados servicios) a destacar son: Permite sugerir el sitio o invitar a amigos : le llega un mail al amigo invitándolo a que se registre. Puntos de usuarios: los usuarios registrados tienen puntajes. Todas las palabras comunes. Muestra las palabras más comúnmente usadas en los OAs Jorum El proyecto Jorum apoya a la enseñanza y a las instituciones de nivel superior del Reino Unido fortaleciendo el intercambio y la reutilización de contenido educativo con el objetivo de mejorar el aprendizaje en la educación. El Portal de Jorum está disponible en Acceso al ROA JorumOpen Figura 7 - Portal Jorum Acceso a la búsqueda, compartir (enviar) y al foro de discusión. El resultado del proyecto Jorum son dos repositorios con distintas características: JorumOpen: cualquiera puede registrarse y el material está bajo licencia Creative Commons, sin embargo, únicamente miembros de instituciones de enseñanza superior del Reino Unido pueden depositar contenido educativo en el repositorio. JorumUK: sólo para uso de los miembros de instituciones de enseñanza superior ya que la suscripción es institucional. En este repositorio solamente 18

23 estos miembros pueden depositar y descargar material educativo y los recursos son creados en virtud de licencias JorumUK. A continuación describiremos JorumOpen. Este repositorio fue creado utilizando DSpace (Ver más), herramienta para la creación de repositorios. El ROA organiza el material en dos grandes comunidades. Separa las instituciones de nivel superior del Reino Unido en Instituciones Postsecundaria (FE) del las de Enseñanza Superior (HE). Las colecciones en cada una de éstas son asociadas a áreas de conocimiento. La comunidad llamada FE cuenta con 313 OAs y la HE posee OAs (datos consultados octubre 2010): Figura 8 - JorumOpen FE (Instituciones Postsecundarias) HE (Instituciones de Enseñanza Superior) Además ofrece un espacio de discusión. Un foro que permite que se hable de experiencias en el uso de los recursos digitales en el aprendizaje, así como también obtener asesoramiento sobre los aspectos a considerar al crear materiales de enseñanza y aprendizaje para compartir. El JorumOpen ofrece búsquedas: Por palabra. Navegar por dos comunidades: FE y HE. Búsqueda avanzada indicando los metadatos: título, descripción, palabras clave, autor y licencia. El listado resultado puede ordenarse por fechas, titulo, etc. indicando orden descendente o ascendente. Una vez que encontramos el OA que nos interesa JorumOpen ofrece algunas facilidades haciendo uso de las comodidades provistas por la herramienta DSpace: formato Dublín Core en los metadatos al descargar el OA creado y almacenado en el repositorio. Exporta los recursos más metadatos en un zip. una vista en miniatura que permite una visualización rápida del OA. 19

24 formato Content Package para descargar material creado con una herramienta creadora de OA (Reload Editor, Exe-learning, MOS Solo, etc. Ver más) e importado al ROA por un usuario con permisos RUA Figura 9 - JorumOpen Descargar OA RUA Repositorio Institucional de la Universidad de Alicante de España, ofrece acceso abierto al material en formato digital (para descarga) generado por los miembros de la Universidad en su tarea como docentes o investigadores. Sólo estos miembros tienen permisos para depositar o subir OAs al repositorio. Está disponible en RUA fue desarrollado usando la herramienta de creación de repositorios DSpace pero ofrece otras facilidades que iremos describiendo más adelante. El ROA organiza el material en cuatro colecciones: Docencia, Institucional, Investigación, Revistas y Congresos. Cuando visitamos a cada una de éstas colecciones se muestra una breve descripción del objetivo de la colección en cuestión. El RUA ofrece búsquedas: Por palabras. Navegar por cuato comunidades distintas y colecciones dentro de éstas. Búsqueda avanzada indicando los metadatos: título, descripción, palabra clave, autor. El repositorio agrega otros metadatos como asignatura, patrocinador, grupo de investigación o docencia entre otros. El repositorio almacena tanto recursos como metadatos. Cualquier persona puede registrarse para convertirse en usuario del ROA, no obstante, algunas funciones son restringidas, tales como el depósito de contenidos y la descarga de los metadatos asociados a los recursos. Éstas requieren autorización de la comunidad. El público sólo 20

25 puede realizar búsquedas por metadatos y descargar los recursos asociados a esos metadatos. Además el ROA brinda utilidades para los usuarios que visitan el repositorio como: una sección de Preguntas frecuentes sobre Derechos de Autor, Suscripciones (notificaciones por correo), Glosario y Estadísticas de uso. Entre las estadísticas que se pueden visualizar en el repositorio podemos nombrar: ítems (OAs) más visitados y más descargados por mes y por año. Visitas y descargas por mes desde Cantidad de descargas o visitas de un OA por año y por país. Acceso a Estadísticas de uso Figura 10 - RUA ítems (OAs) más visitados y más descargados Visitas y descargas por mês El repositorio nos brinda la posibilidad de visualizar estadísticas específicas del AO o item que estamos visitando. Estadísticas del OA. Figura 11 Acceso a estadísticas del OA 21

26 2.3 ESTÁNDARES Estándar es sinónimo de norma, regla o modelo. Un estándar es el modelo a seguir cuando se realiza o desarrolla algo. Cuenta con documentos que dan los detalles técnicos y las reglas necesarias para que un producto o tecnología se use correctamente. Por ejemplo los códigos de barras donde los fabricantes de lectores y los etiquetadores siguen las mismas normas, saben como escribir y leer esos códigos. En el campo del e-learning la estandarización es el proceso por el cuál se definen reglas o norma comunes y aceptadas por las diferentes empresas o instituciones involucradas en tal proceso que permiten la cooperación entre ellas sin perjudicar su posibilidad de competir. La existencia de estándares es importante ya que facilita el intercambio de los contenidos entre diversas plataformas y sistemas. Además los estándares regularizan o normalizan el acceso a dichos contenidos. Como consecuencia se logra una eficiente recuperación de la información para ello se utilizan por ejemplo lenguajes de búsqueda, formatos de almacenamiento y protocolos de conversión provistos por distintos estándares. Un estándar proporciona ventajas no sólo a las empresas, si no también al usuario, ya se amplía la capacidad de elección de distintas herramientas de los más diversos proveedores evitando así atarse con tecnología propietaria. El usuario tiene a disposición todos aquellos proveedores que cumplen un estándar determinado y por ello crean productos que son compatibles. Existen dos tipos de estándares: Estándares oficiales: son aquellos que han sido establecidos por consenso y aprobados por un organismo oficial de estandarización (nacional o internacional). ISO 9000 es un ejemplo de este tipo de estándar, que designa un conjunto de normas sobre calidad y gestión continua de calidad, establecidas por la ISO (Organización Internacional para la Estandarización). Puede ser aplicada a una organización o actividad dedicada a la producción de bienes o servicios. Estándares de facto: normalmente impulsadas por fabricantes o grupos de interés, los estándares de facto son aquellos que se usan por voluntad propia, beneficio o utilidad. Tienen una gran aceptación aunque no hayan sido aprobados por un organismo de estandarización. En el caso de Internet y, específicamente, en el desarrollo Web, la organización W3C (World Wide Web Consortium) crea las especificaciones probablemente más utilizadas en este campo y que en muchos casos después de publicadas pasan a ser reconocidas como estándares formales. El lenguaje HTML v2.0 (Hypertext Transfer Model Protocol) es un ejemplo de las normas creadas por esta entidad. 22

27 2.3.1 VENTAJAS DE ESTÁNDARES DE E-LEARNING La utilización de estándares de e-learning brinda muchas ventajas no sólo en la educación a distancia sino que también aporta beneficios por ejemplo en la enseñanza presencial. A continuación detallaremos algunas ventajas importante [40]: Rol Clientes o consumidores Proveedores de herramientas o vendedores Beneficio Los estándares los previenen de casarse con tecnologías propietarias. Los costos se reducen a medida que se remplazan desarrollos propios por configuraciones plug and play.por ejemplo un cliente podría cambiar de LMS y reutilizar toda la información con la que contaba en su LMS anterior. Para éstos contar con métodos estandarizados de comunicación e intercambio elimina la necesidad de escribir interfaces propietarias para cada uno de los productos existentes y. simplifica la integración de diferentes productos. Esto reduce los costos de desarrollo y aumenta el mercado potencial para las aplicaciones Los estándares les permite que el contenido producido sea en un formato único y pueda ser utilizado en cualquier plataforma o sistema. Generadores de contenido Además, un amplio mercado de contenidos de aprendizaje, hace más probable que los productores de contenidos inviertan recursos necesarios para producir una amplia gama de contenidos educativos (aumentando oferta y calidad), incluso en áreas especializadas. Para el diseñador de contenido, los estándares facilitan su trabajo, ya que le dan acceso a grandes almacenes de contenido reutilizable, reducen la necesidad de desarrollar contenidos para múltiples sistemas y permiten crear contenido modular que puede ser más fácil de actualizar y de mantener. Alumno Para el alumno, los estándares aumentan la posibilidad de elección de productos educativos o herramientas. Además implican que los resultados de su aprendizaje (créditos o certificados) tengan mayor portabilidad PROCESO DE DESARROLLO DE ESTÁNDARES Hoy en día existe una serie de organizaciones que desarrollan especificaciones e- learning y no existe UN (único) estándar e-learning. Los distintos consorcios e iniciativas se muestran en la siguiente figura. Figura 12 Consorcios e Iniciativas - Proceso de Desarrollo de estándaresfuente: 23

28 Estas organizaciones pretenden lograr integración e interoperabilidad entre las numerosas plataformas e-learning que los consumidores tienen a disposición en el mercado. Para ello productores de contenidos, consumidores, empresas y vendedores se agrupan en consorcios e iniciativas (empresas relacionadas a la industria) y trabajan en conjunto uniendo esfuerzos y recopilando requerimientos comunes y que ellos mismos demandan. Estas agrupaciones tienen como objetivo generar estándares formales con alto nivel de aceptación. El proceso de desarrollo de estándares se divide en tres niveles de trabajo: Nivel de especificación. Se recopilan requisitos y necesidades de muchas fuentes y se elaboran recomendaciones basadas en el análisis de esos datos. El resultado de este paso es una especificación técnica consensuada que se puede experimentar o implementar. Además pueden existir cambios de contextos y nuevas necesidades por la que la especificación propuesta debe entonces ser corregida y actualizada. En este nivel se encuentran los consorcios IMS (Instructional Management Systems) y AICC (Aviation Industry Computed Based-Training). Estos producen especificaciones técnicas (recomendaciones) que son soluciones a las necesidades de los consumidores de cursos on-line. Por ejemplo, IMS ha producido cerca de 16 especificaciones que se dedican a analizar los distintos ámbitos de interoperatividad entre plataformas e-learning. Nivel de validación. Las especificaciones desarrolladas en el paso anterior se incorporan en nuevos productos. Se ejecutan aplicaciones de prueba (prototipos) que miden la efectividad y aplicabilidad de la especificación. Así surgen los modelos de referencia que ensamblan distintos estándares y especificaciones para formar un sistema e-learning completo. Por ejemplo las especificaciones técnicas de IMS y AICC nombradas en el nivel anterior son probadas en productos. Para ello pasan a un segundo cuerpo: el ADL (Advanced Distributed Learning). Este organismo realiza pruebas para verificar su consistencia utilizando prototipos. Por lo que ADL reúne las mejores ideas de implementación de los consorcios, generando lo que se denomina modelos de referencia SCORM. Nivel de estandarización. Las especificaciones validadas en el paso anterior son tomadas por los organismos oficiales de estandarización que se encargan de refinar, clarificar y consolidar respectos de los requerimientos que satisfacen. Para los productos que cumplen con cierto estándar existe un proceso de acreditación donde los organismos oficiales examinan minuciosamente el producto y determinan su calidad respecto de los estándares que satisfacen. Siguiendo el ejemplo del nivel anterior, cuando ADL afirma que ha realizado suficientes pruebas sobre las especificaciones publican los modelos de referencia del nivel anterior. En ese momento éstos pasan a un tercer cuerpo: estándares. Estas organizaciones son generadores de estándares como lo son el IEEE (Institute of Electrical and Electronic Engineer) y el W3C encargados de la Web. Se espera entonces que en un futuro esas 24

29 especificaciones se conviertan en estándares universales si por ejemplo es aprobada por algún organismo superior como ISO. Es importante recalcar la diferencia entre especificación y estándar. La primera es el resultado de un proceso de trabajo de perfeccionamiento. La especificación está sujeta a cambios porque pretende satisfacer las necesidades analizando los nuevos requisitos de los propios participantes. En cambio el estándar acreditado es mucho más estable y menos propenso a modificaciones. Las especificaciones desarrolladas por los distintos consorcios son recomendaciones que en la industria de e-learning se tratan de adoptar. IEEE LTSC es el único organismo de estandarización. Sus estándares son probados y sancionados por ISO ESTÁNDARES DE METADATOS Un estándar de metadatos es un conjunto de metadatos propuesto por alguna iniciativa u organización reconocida que permite describir los OAs. Estos estándares permiten que la gestión de los OAs sea más eficiente, es decir permiten que éstos sean fácilmente localizados, catalogados, organizados en un almacén o repositorio de OAs. Algunas de las características que se obtienen de la aplicación de estándares de metadatos son: Accesibilidad: los contenidos podrán ser buscados e identificados cualquiera sea su ubicación. Por ejemplo si el mismo OA se encuentra en dos repositorios distintos los metadatos permite que éste se encuentre indistintamente donde se lo esté buscando. Interoperabilidad: ésta característica permite que se pueda intercambiar y combinar contenidos de diferentes fuentes. Con ello se logra que exista la comunicación y la interacción entre distintos sistemas o plataformas e-learning. Reusabilidad: los estándares permiten el reuso de contenidos. Por ejemplo un OA puede ser utilizado por una herramienta o plataforma distinta a la que se usó para su creación o un contenido que se desarrolló en un contexto determinado puede ser después reusado con otros objetivos educativos. Durabilidad: si se utiliza un estándar probablemente el OA podrá ser reutilizado en otros contextos de aprendizaje auque la herramienta que con la cual ha sido creado ya sea obsoleta y podrá ser intercambiado (interoperabilidad) entre distintas plataformas o sistemas que cumplan con tal estándar. Varias iniciativas se abocan a la creación de estándares de metadatos: IEEE LTSC creó la especificación llamada LOM (Learning Object Metadata). IMS, ADL, ARIADNE (Alliance of Remote Instructional Authoring and Distribution Networks for Europe) y muchas organizaciones han adoptado y amoldado LOM. DCMI (Dublín Core Metadata Initiative) creó un estándar diferente de metadatos llamado DCMES utilizado originalmente por bibliotecas y editores pero que ha tenido gran aceptación en el área educativa. El lenguaje EML (Educational Modelling Language) permite describir la metodología pedagógica de un curso. El equipo IMS Learning Design (Diseño del aprendizaje) adoptó en el año 2003 EML dando una solución de más bajo 25

30 nivel creando descripciones interpretables por computadora. Esta solución puede clasificase dentro de las especificaciones para metadatos En nuestro trabajo utilizaremos para describir a los OAs, el estándar de metadatos más detallado y completo, denominado LOM (Learning Object Metadata) ESTÁNDARES DE CONTENT PACKAGING (CP) Para que distintos software de e-learning puedan interactuar con OAs de distintas fuentes deben ajustarse además de los estándares de metadatos, a estándares de Content Packaging (Paquete de contenidos) o empaquetado. Las especificaciones y estándares de paquete de contenido o empaquetado permiten que los cursos puedan ser transportados de un sistema de aprendizaje a otro. Esto es realmente importante ya que el OA puede ser creado por una plataforma y modificado por otra plataforma u otra herramienta. Además podrían ser almacenados en un ROA mantenido por un proveedor y utilizados en un sistema LMS producidos por un proveedor diferente. Los OA incluyen tanto los recursos de aprendizaje como información acerca de cómo se organizan para formar grandes unidades de aprendizaje. También puede determinar las reglas de cómo será la transmisión del contenido al alumno. Dentro de las iniciativas relacionadas con el empaquetamiento de contenido se encuentran: IMS CP (Content Packaging - Paquete de contenidos). IMS SS (Simple Sequencing - Secuenciación Simple). AICC Guidelines and Recommendations for CMI (Computer Managed Instruction). Específicamente su visión del curso como estructura de carpetas, para que pueda ser entendido por cualquier plataforma. ADL SCORM (Sharable Content Object Reference Model). Una parte de éste modelo de referencia se basa en el trabajo de la AICC (representación del curso). IEEE que colabora situando en proceso de acreditación los trabajos de la AICC y a SCORM relacionados con empaquetamiento. Los componentes que se emplean para realizar preguntas y evaluaciones al alumno dentro de un OA, son un tipo especial de paquete de contenido, apoyado por un conjunto de especificaciones diferente. Los estándares permiten que dichas preguntas, evaluaciones, preguntas de opción múltiple, etc. puedan ser creadas en un entorno determinado y luego ser utilizados en otros. La iniciativa más significativa relacionada con Assessment Packaging (paquetes de evaluaciones): IMS QTI (Question and Test Interoperability Preguntas y evaluaciones interoperables). En nuestro desarrollo utilizaremos para empaquetar los contenidos educativos el estándar de facto más empleado en el mundo, el cual se conoce como SCORM. 26

31 2.3.5 ESTÁNDARES DE LEARNER PROFILE La información del Learner Profile (Perfil del alumno) permite compartir información sobre los alumnos entre distintas plataformas o sistemas. La información puede incluir datos personales, planes de aprendizaje, historial del aprendizaje, requerimientos de accesibilidad, certificados o títulos, evaluaciones de conocimiento, participación del alumno en un curso dado. Dentro de la comunidad e-learning los esfuerzos más importantes para estandarizar la información del perfil del alumno son: IMS Paquete de información del alumno LIP (Learner Information Package). IEEE Información personal y privada PAPI (Personal and Private Information). Además se podría incluir en este grupo el estándar de intercambio de información personal vcard (electronic business cards), estándar SPEEDE/Express que es parte de SIF (Schools Interoperability Framework) y el protocolo de Recursos Humanos HR-XML (Human Resource-XML) ESTÁNDARES DE LEARNER REGISTRATION El objetivo de Learner Registration (Registro del alumno) es soportar los procesos de interoperatividad entre plataformas de e-learning (LMS) y los Sistemas Gestión de Información existentes en las distintas organizaciones como por ejemplo: Sistemas de monitoreo de habilidades y competencias de RRHH y de definición de designación para programas de capacitación. Sistemas de administración de alumnos que incluyan gestión de catálogos de cursos, agendas de clases, registro de programas académicos, matriculación a clases, registro de asistencia, funciones de libro de notas entre otras. Sistemas de administración de la capacitación que incluyan funciones de administración de cursos, matriculación a cursos entre otras funciones de capacitación del personal. Sistemas de administración de bibliotecas con gestión de colecciones de objetos de aprendizaje tanto físicos como electrónicos y la gestión del acceso a esos materiales. Ésto permite saber qué ofertas se pondrá a disposición del alumno, y proporciona información sobre el aprendizaje de los participantes en una plataforma LMS Las iniciativas que se encargan de estos requisitos son: IMS Enterprise define paquetes XML para el intercambio de la información referida al registro del alumno entre los sistemas. La primera versión del 2000, se centró principalmente en el apoyo a la interacción entre el Sistema de Gestión de Aprendizaje y Cursos, sistemas de estudiantes empresariales y Sistemas de RRHH. SIF (Schools Interoperability Framework): Tradicionalmente, las aplicaciones independientes que usan las escuelas públicas tienen la limitación de aislamiento de datos. Esto se traduce datos redundantes, problemas de integridad, información ineficiente e incompleta. SIF no es un producto, sino una iniciativa que permite que diversas aplicaciones pueden interactuar y 27

32 compartir información, es decir es un modelo de interoperabilidad de software educativo y acceso a datos ESTÁNDARES DE CONTENT COMMUNICATION Cuando el contenido se pone en marcha, es decir empieza la interacción con el alumno y el LMS, se necesita comunicar datos del alumno e información de actividades previas al contenido. Además cuando el alumno interactúa con éste, genera resultados de actividades, puntuaciones o calificaciones del curso. Compartir la puesta en marcha, estado de las actividades de aprendizaje y los resultados a través de múltiples componentes de un ambiente de aprendizaje, requiere de estandarización. Las especificaciones Content Communication (Comunicación del contenido) brindan componentes para compartir resultados, tanto como para evaluaciones individuales o como todo lo involucrado en un proceso de aprendizaje (finalización de un curso). Esto se logra mediante la creación de protocolos estandarizados de comunicación y modelos que permiten que los contenidos se comuniquen con el sistema LMS. Dentro de esta clasificación se encuentran las siguientes iniciativas: AICC CMI que incluye comunicación de componentes. ADL SCORM. La versión 1.1 incluye una API (Application Program Interface) de JavaScript que permite al contenido e-learning comunicarse con la plataformas LMS utilizando un navegador Web ESTÁNDARES DE REPOSITORIOS La idea de los estándares de repositorios se enfoca en facilitar la interoperabilidad (intercambio de contenido) entre las funciones más comunes del repositorio la cuales son: buscar, exponer, colectar, enviar, almacenar, pedir, entregar y alertar. Estas se agrupan en actividades y se reconocen cinco principales: Buscar/Exponer, Colectar/Exponer, Enviar/Almacenar, Pedir/Entregar y Alertar/Exponer. En la siguiente tabla se describen cada una de las actividades [22]: Función Buscar/Exponer (Search/Expose) Colectar/Exponer (Gather/Expose) Enviar/Almacenar (Submit/Store) Pedir/Entregar (Request/Deliver) Alertar/Exponer (Alert/Expose) Descripción Ejecuta la búsqueda de metadatos asociados con los contenidos que el repositorio expone. Se refiere a la actualización periódica entre repositorios. Define la solicitud de metadatos que el repositorio expone: se agregan metadatos de otros repositorios en mi búsqueda o se almacena metadatos de repositorios externos. Por ejemplo, Pull: OAI, Push: alert (notificación que algo cambió). Se enfoca en la manera en la que un objeto se mueve a un repositorio desde un sitio accesible por red y cómo el objeto será representado en el repositorio para su acceso. Permite, que una vez que el usuario ha localizado los metadatos en la función Buscar, pueda solicitar al repositorio el acceso al recurso. Función clave, en la que a través de correo electrónico se notifica a los usuarios sobre eventos en el repositorio, pero no está contemplada todavía en esta versión de la especificación. 28

33 El intercambio de información entre repositorios se puede realizar de distintas maneras y se debe determinar en particular para cada aplicación, los requisitos y grado de interoperabilidad. Sin embargo existen soluciones que facilitan la implementación del intercambio de contenidos como por ejemplo el estándar IMS DRI (Digital Repositories Interoperability). El estándar IMS DRI es un ejemplo de este tipo de especificación cuyo objetivo es facilitar el acceso a los contenidos en los repositorios educativos sean estos LMS, CLMS o portales de búsquedas PERFILES DE APLICACIÓN Ningún estándar puede cubrir todas y cada una de las necesidades que exigen la gran diversidad de aplicaciones y contextos educativos. Estas especificaciones y estándares brindan un conjunto de normas de definición de metadatos que muchas veces es necesario refinar para que se adapten a los requisitos concretos de un dominio o aplicación. El término perfil de aplicación se refiere a la adaptación, la restricción o el aumento del vocabulario en los campos de un esquema de metadatos para satisfacer las necesidades de una comunidad en particular. Un perfil de aplicación no puede crear nuevos elementos, pero puede darle semánticas precisas a campos ambiguos o genéricos de un esquema. Por ejemplo, actualmente existen muchos perfiles de aplicación LOM que particularizan el estándar según los requisitos de sistemas educativos concretos, escogiendo un subconjunto de los metadatos LOM, ampliándolo dándole otro significado a algún campo de metadatos existente, modificando los vocabularios que soporta, etc. Por ejemplo, el perfil de aplicación CanCore utiliza un subconjunto de los metadatos de la especificación en LOM para describir sus OA en el sistema canadiense. Los perfiles de aplicación son tan importantes que IMS publicó una especificación denominada Application Profile Guidelines, en la que se define un perfil de aplicación en el contexto de las especificaciones IMS y los beneficios que se obtienen al llevarlo a cabo. Además se ofrece orientación sobre los factores claves para decidir si se debe proceder o no a implementar un perfil de aplicación y un proceso detallado de cómo llevar a cabo dicha actividad. Los documentos de la especificación se ofrecen como una guía, basada en la experiencia de un número de comunidades de usuarios en la adopción y aplicación de las especificaciones, con la esperanza de que su experiencia sea de utilidad para otros que se enfrenten con los mismos problemas INICIATIVAS Y CONSORCIOS A continuación se presentan algunas de las iniciativas y consorcios que, a nuestro criterio están teniendo una mayor repercusión en el campo e-learning. Estas iniciativas se detallaran de acuerdo con su nivel dentro del proceso de estandarización: Nivel de especificación: AICC, DCMI e IMS. Nivel de validación: ADL. Nivel de estandarización: IEEE e ISO. 29

34 Figura 13 Relación entre Consorcios, Iniciativas y Organizaciones fuente: Ref. [42] AICC La AICC (Aviation Industry Computed Based-Training) es una asociación internacional para capacitación basada en computadores (Cumputed based training) en el campo de la industria de la aviación. Esta asociación se formó ya que el software educativo (por ejemplo la simulación) era, en un principio, de gran importancia en el sector de la aviación. Más tarde, el Comité AICC se generalizó y se desarrollaron otras áreas de trabajo e investigación. La página oficial de la AICC es La AICC es una organización dedicada a ayudar a la comunidad de la aviación en lo que respecta a sacar el máximo provecho de la tecnología para la enseñanza y el entrenamiento en tal sector. Esto se logra reuniendo a los capacitadores de la aviación, desarrolladores de cursos, proveedores de software, diseñadores de simuladores, desarrolladores de normas y estándares, y los análisis de las buenas prácticas y recomendaciones tecnológicas. Los estándares y procesos de certificación obtenidos por la AICC son compartidos para que se utilicen en otras áreas. La AICC ha desarrollado una serie de guías y recomendaciones, llamadas AGR (AICC Guidelines & Recommendations) por sus siglas en inglés. Cada AGR hace una recomendación técnica en un área específica: AGR 001: AICC Publications. AGR 002: Courseware Delivery Stations (1988). AGR 003: Digital Audio (1992). AGR 004: Operating/Windowing System. AGR 005: CBT Peripheral Devices. AGR 006: Computer-Managed Instruction (1993). AGR 007: Courseware Interchange. AGR 008: Digital Video. AGR 009: Icon Standards: User Interface (1996). AGR 010: Web-Based Computer-Managed Instruction (1998). AGR 011: The Package Exchange Notification Services (2005). AGR 012: Training Development Checklist (2005). 30

35 CMI GRADUATE! UN REPOSITORIO DE OBJETOS AICC publica recomendaciones en muchos aspectos del e-learning. La guía que ha tenido mayor aceptación es la AGR 010 Web-Based CMI (Computer-Managed Instruction) que habla de la interoperabilidad entre las plataformas e-learning y los cursos. Esta guía especifica pautas de cómo crear contenido que se pueda comunicar con el mayor número de sistemas LMS. La AGR 010 resuelve dos problemas fundamentales: El LMS no debe tener problemas a la hora de cargar o importar cursos creados por otras plataformas. Este objetivo se consigue porque el curso se define como una entidad totalmente independiente de la plataforma, y se crea un sistema de representación del curso que pueda ser entendido por cualquier plataforma (estructura de carpetas). El curso debe poder transmitir información al LMS y viceversa. Este objetivo se logra mediante la definición de un mecanismo de comunicación entre el curso y la plataforma LMS. La AICC describe dos mecanismos: uno basado en el protocolo http (más sencillo y extendido) y otro mediante una API. Por ejemplo un curso obtiene información necesaria sobre el usuario del LMS para luego transmitir a la plataforma los resultados de las interacciones y evaluaciones realizadas por ese usuario con el fin de que estos datos sean almacenados y sean útiles en futuros resúmenes estadísticos. La AICC cuenta con un programa de certificación y dispone de un Test Suite que le permite a las instituciones verificar si sus productos son compatibles con las especificaciones AICC y así lograr interoperabilidad con otros sistemas DCMI DCMI (Dublín Core Metadata Initiative) es un foro abierto dedicado al desarrollo de estándares de metadatos de propósito general enfocado principalmente en la localización y catalogación de recursos. Es una iniciativa que tiene una amplia aceptación en varios campos ya que los metadatos son usados en organizaciones educativas, bibliotecas, instituciones del gobierno, el sector científico de la investigación, autores de páginas Web, etc. Los objetivos de DCMI son: Desarrollar estándares de metadatos para la recuperación de recursos educativos en Internet entre diversos sistemas o dominios. Definir marcos de trabajo para lograr la interoperabilidad o intercambio entre conjuntos de metadatos. Facilitar conjuntos de metadatos específicos para una comunidad o disciplina, (acordes a los dos objetivos descriptos anteriormente). DCMI organiza actividades que incluyan mejoras en el uso de los metadatos y para que cada vez más gente se interese en la utilización de los metadatos Dublín Core. El sitio de la DCMI se encuentra disponible en En Agosto de 1999 el Comité Asesor de Dublín Core (Dublín Core Advisory Committee, DCAC) creó el grupo de trabajo cuyo objetivo fue desarrollar una propuesta que simplifique el uso de metadatos de Dublín Core en la descripción de recursos 31

36 educativos. El resultado principal ha sido el Dublín Core Metadata Element Set versión 1.1 (DCMES) que contiene 15 elementos: Elemento Title Creador Subject Description Publisher Contributor Date Type Format Identifier Source Language Relation Coverage Rights Etiqueta dc.title dc.creator dc.subject dc.description dc.publisher cd.contributor dc.date dc.type dc.format dc.identifier dc.source dc.language dc.relation dc.coverage dc.rights Entre las características que presenta el formato Dublín Core encontramos: Internacional: DC se ha convertido en un formato mundial y la traducción a más de 20 idiomas avala el carácter internacional. Simple y Flexible: El formato DC es un formato simple y los 15 elementos son opcionales y repetibles por lo que el autor puede escoger aquellos elementos que considere necesarios para la descripción de sus recursos de información. Además los elementos pueden aparecer en cualquier orden. Interoperabilidad semántica 2 : Dublín Core propone un conjunto de elementos que presentan una semántica sencilla e intenta promover un conjunto de descriptores comprensibles por la mayoría de las disciplinas. La mayoría de los elementos del formato tienen una semántica equivalente a un registro de catalogo de una biblioteca tradicional. Extensibilidad: Los perfiles de aplicación consisten en tomar elementos de datos de uno o más formatos de metadatos y adaptarlos a una aplicación determinada, permiten que diferentes comunidades puedan utilizar en sus perfiles de aplicación elementos de sus formatos, mezclados con elementos del formato Dublín Core y viceversa. La DCMI organizó tareas de ampliación y perfeccionamiento del original DCMES donde se agregaron nuevos elementos a la lista de 15. Éstos están en el mismo nivel de los originales o son elementos que refinan a alguno de ellos añadiendo mayor descripción 2 Capacidad de los sistemas informáticos de intercambiar la información y de tener el significado de esa información interpretada automáticamente por el sistema de recepción para producir resultados útiles, según lo definido por los usuarios finales de ambos sistemas. 32

37 a los recursos que se describen con el formato DC. Los nuevos calificadores fueron identificados y evaluados en reuniones de trabajo y la junta de uso DCMI. Este nuevo esquema es llamado DC calificado (Qualified Dublin Core) que incluye términos de refinamiento y esquemas de codificación de los elementos Elementos de refinamiento Estos calificadores hacen que el significado de un elemento sea más específico. Un elemento refinado comparte el significado del elemento no calificado, pero con un alcance más restringido. Las aplicaciones que no entienden un elemento de refinamiento deben ser capaces de ignorar el calificador y el tratamiento de los metadatos debe ser como si se tratara de un elemento más amplio. Por ejemplo, el término de refinamiento abstract (ver tabla siguiente), está asociado al elemento description e indica que el valor del elemento es un resumen del recurso que se está describiendo Esquema de codificación Estos calificadores identifican esquemas que ayudan en la interpretación de un valor. Estos esquemas incluyen vocabularios controlados y notaciones formales o reglas de análisis. Los calificadores de esquemas permiten a los autores proporcionar más contexto para la interpretación correcta de los metadatos. Un ejemplo de esquema de codificación asociado al elemento date es el W3C-DTF que define las reglas de codificación W3C para fechas y horas, la cual debe escribirse de acuerdo al formato: yyyy-mm-dd. Si no se especifica, una fecha como (12 nov. 2005), puede ser interpretada también como 11 dic La tabla siguiente contiene los elementos de refinamiento y la codificación de DC: Elemento Etiqueta Elementos de refinamiento Esquema de codificación Title dc.title alternative Creador dc.creator Subject dc.subject LCSH,MeSH,DDC,LCC,U DC Description dc.description Abstract, tableofcontents Publisher Contributor dc.publisher cd.contributor Date dc.date available, issued, created, dateaccepted,datesubmite d,modified,valid DCMI Period,W3C-DTF Type dc.type DCMI Type Vocabulary Format dc.format Extent IMT medium Identifier dc.identifier bibliographiccitation URI 33

38 Elemento Etiqueta Elementos de refinamiento Esquema de codificación Source dc.source URI Language dc.language ISO 639-2RFC 3066 Relation dc.relation isversionof, conformsto, hasformat, haspart, hasversion, isformatof, ispartof, isreferencedby, URI isreplacedby isrequiredby referentes replaces requires Coverage dc.coverage Spatial DCMI Point,ISO 3166 temporal DCMI Box,TGN Rights dc.rights accessrights license URI Audience dc.audience Mediator, educationlevel Provenance Rights Holder Instructiona l Method Accrual Method Accrual Periodicity Accrual Policy dc.provenance cd.rightsholder dc.instructiona l Method dc.accrual Method dc.accrual Periodicity dc.accrual Policy IMS Global Consortium El proyecto de Sistemas para la Gestión del Aprendizaje IMS (Instructional Management Systems) se origina en 1997 como un proyecto en el consorcio EDUCOM (en la actualidad EDUCAUSE) con el objeto de estandarizar contenidos de aprendizaje. Rápidamente amplía sus participantes y extiende sus objetivos. De esta forma adquiere una entidad propia que queda institucionalizada e identificada bajo el nombre 34

39 IMS Global Consortium que es más conocida por sus iniciales IMS GLC. Disponible en IMS tiene muchas especificaciones. Cada una de ellas está enfocada en una necesidad distinta del proceso de enseñanza. A continuación, describiremos algunas de las más relevantes. Normalmente cada una de ellas se encuentra detallada al menos en tres documentos: Information Model (Modelo de Información): este documento realiza una descripción formal de los datos, así como también define su estructuración, detallando cada uno de los elementos considerados en la especificación. El modelo que se expone en este documento es independiente del formato físico en el que se representa finalmente la información. Best Practices and Implementation Guide (Guía de Implementación y consejos). En este documento se incluyen ejemplos, la forma de uso de la especificación, la relación con otras especificaciones e información complementaria que pueda servir de ayuda. Normalmente es el documento que se recomienda leer primero para entender los conceptos generales de la especificación. XML Binding (Vinculación con XML). Documento que ofrece la forma de representar el esquema de datos en archivos XML. Adicionalmente se proporciona el esquema documental XML que nos permite comprobar la validez de la estructura de un archivo XML creado por nosotros IMS Learning Resource Metadata Specification En la siguiente tabla se muestra de qué manera surge el IMS LRM Specification ya que en el proceso de este estándar se encuentran involucradas distintas iniciativas y organizaciones. Año Sucesos El consorcio sin fines de lucro EDUCOM (ahora llamado EDUCAUSE) en EEUU inicia el Proyecto IMS. Desarrolló estándares basados en el mercado abierto para el aprendizaje en línea, incluyendo especificaciones de metadatos de objetos educativos. Proyecto IMS y ARIADNE presentaron una propuesta conjunta al IEEE que se convirtió en el documento base de la actual especificación Learning Object Metadata (LOM) de IEEE LTSC. El Proyecto IMS se constituyó como el IMS Global Learning Consortium (IMS GLC), dando a conocer el trabajo de IEEE. IMS GLC es una corporación privada creada por algunas de las empresas más importantes del sector educativo. Su objetivo fue el diseño de un formato que pusiese en práctica las recomendaciones de la IEEE y de la AICC. Los grupos de estudio NIST (Instituto Nacional de Estándares y Tecnología) y el IEEE P.1484 (ahora el IEEE LTSC) comenzaron con esfuerzos similares. En julio el grupo de trabajo 12 de IEEE LTSC publica la versión 3.5 de LOM. 5 septiembre LOM v3.6 35

40 Año Suceso En agosto IMS GLC dio a conocer la especificación para metadatos v1.0 (LRM Specification). Se basaba en los metadatos identificados en LOM v3.5. Contaba con tres documentos: IMS Learning Resource Metadata (LRM) Information Model IMS LRM XML Binding Specifications (además basada en W3C XML specification versión 1.0) IMS LRM Best Practices and Implementation Guide. Se publican revisiones periódicas de IMS Metadata basadas en las distintas actualizaciones del esquema conceptual de datos IEEE LOM. 05 junio IMS LRM information model v.1.1 (final). Hace referencia a IEEE LTSC LOM v3.5 Borrador de Trabajo v5 de IEEE LTSC LOM - publicado 8 de Febrero de Borrador de Trabajo 6.1 de IEEE LTSC LOM -publicado 13 de Febrero de abril 2001 IMS LRM information model v.1.2 (borrador). Hace referencia al Borrador de Trabajo 6.1 LOM 17 Mayo 2001 IMS LRM information model v.1.2 (final). Hace referencia al Borrador de Trabajo 6.1 LOM 28 septiembre IMS LRM information model v (final). Hace referencia al Borrador de Trabajo 6.1 LOM 27 Noviembre 2001 IMS Schema Updates v1.2.2 (Borrador) 2001 Versión XSD Schema - Maintenance Release (Mantenimiento de esquema XSD) 2002 En junio el esquema de datos de LOM (a cargo del grupo de trabajo 12) es aprobado como la especificación IEEE LOM v1.0 El estándar LOM consiste en varias partes: 1. un esquema conceptual de datos 2. la norma ISO / IEC11404 Borrador de trabajo 6.4 de IEEE LTSC LOM -publicado en Marzo. El 19 julio IEEE publica el documento Summary of Changes que es un resumen de cómo la especificación LOM ha afectados a los proyectos anteriores, especialmente el Borrador de trabajo del grupo 6.1,6.2, 6.3 y

41 3. vinculación de metadatos LOM con documentos XML 4. Resource Description Framework(RDF) En febrero el estándar XML asociado al estándar IEEE es aprobado como la especificación IEEE Se publica la nueva versión de IMS Metadata Specification v1.3 que se reajusta para cumplir con IEEE y IEEE Junto con esta especificación se publica recomendaciones de cómo transformar documentos XML basados las v1.2.1, v1.2.2 and v1.2.4 de IMS LRM a LOM v1.0. Desde la primera versión de las especificaciones IMS para metadatos v1.0 (Learning Resource Metadata Specification) del año 1999, IMS ha adoptado LOM como estándar de metadatos. Esto se debe a que el estándar LOM se basa en los esfuerzos previos hechos para la descripción de recursos educativos del Proyecto IMS del año 1997, y también de proyectos como ARIADNE y Dublín Core. Actualmente IEEE LOM es el estándar de e-learning formalmente aprobado que goza de mayor aceptación y que ha sido adoptado en la última especificación IMS para metadatos v3.1 (Final) del año En la tabla de la próxima sección se muestran las distintas versiones de LOM adoptadas por IMS LRM Specification. IEEE LOM especifica un esquema de metadatos y define los atributos, nombres, definiciones, tipos de datos y longitudes, su estructura jerárquica y define los valores que pueden tomar esos metadatos (por ejemplo define vocabularios controlados). Es decir únicamente define un modelo teórico de metadatos. Esta especificación no detalla cómo representar el esquema. IMS, en cambio, especifica el uso de metadatos LOM con un carácter más práctico. Define la forma de representar del esquema en lenguaje XML. Proporciona componentes que permiten que esos metadatos se puedan transmitir y que en el lugar de destino éstos puedan ser entendidos y procesados. No olvidemos que las distintas iniciativas u organizaciones trabajan en conjunto para desarrollar estándares que les sean útiles a todas las partes involucradas en la industria e-learning. IEEE LOM e IMS LRM hacen referencia a lo mismo pero en un nivel distinto dentro del proceso de desarrollo de normas: LOM a nivel de estándar y LRM a nivel de especificación IMS Content Packaging v1.1.2 La especificación de Paquetes de Contenidos CP (Content Packaging) describe el modo de empaquetar los contenidos educativos para que sean intercambiables y reutilizables. El objetivo es permitir que los LMS puedan importar, exportar, ensamblar o disgregar contenidos creados por otras plataformas o sistemas de terceros. De esta forma, facilita la interoperabilidad entre diferentes LMS independientemente de modo y el lugar utilizados para la creación de los contenidos. 37

42 El estándar ofrece una forma de empaquetar los contenidos educativos en un archivo comprimido (zip, cab o jar). Estos contenidos pueden ser uno o más cursos o cualquier tipo de recurso necesario en el proceso educativo por ejemplo una lección, una imagen, exámenes, un curso en formato HTML. La estructura de un paquete de contenido se puede visualizar en la siguiente figura: Figura 14 Modelo conceptual de IMS Content Package fuente: Ref. [11] El paquete IMS anterior se compone de dos elementos principales, en la figura se muestran con color rosa: un archivo fundamental llamado imsmanifest en formato XML que describe la organización de contenidos y los recursos en un Package (paquete). Es decir en él se describe la estructura de datos incluida en el paquete. los archivos físicos (que tienen su descripción en el archivo XML). En la siguiente figura se muestra un paquete IMS con los dos componentes que hemos descripto. Figura 15 Ejemplo de un IMS Content Package simple (archivo *zip) El modelo conceptual de IMS Content Package define las siguientes piezas estructurales básicas para describir y organizar el paquete de contenido que es utilizado para el intercambio. A continuación se describen las relaciones entre estas piezas: Interchange package (paquetes de intercambio): archivo comprimido en formato zip, cab o jar, que contiene al imsmanifest.xml de nivel superior y a todos los archivos físicos referenciados dentro de éste. Es un Package en formato de intercambio Web 38

43 (comprimido). Es decir es un conjunto de componentes que están listos para ser intercambiados entre los sistemas o plataformas. Logical package (paquete lógico): directorio lógico que incluye el archivo imsmanifest.xml y los subdirectorios que contienen los archivos físicos. Manifest (manifiesto): elemento obligatorio que describe al paquete de contenido. También puede contener opcionalmente submanifest. Además los documento XML poseen un sistema de validación en formato XSD o DTD por lo que pueden existir referencias a componentes remotos. Cada manifiesto contiene las siguientes secciones: Metadata (metadatos): Es un elemento XML que describe el manifiesto en su conjunto. A este nivel (contenido por el manifest) es información descriptiva correspondiente al paquete de contenido como un conjunto sin embargo los metadatos pueden ser asignados a cualquiera de las secciones dentro del paquete lógico incluyendo organizations, resources y submanifest y files. Dentro de los metadatos pueden existir referencias a los componentes remotos por ejemplo una referencia a un sitio remoto. Organizations (organizaciones): relaciones entre las unidades de contenido. Es un elemento XML que describe ninguna, una o varias organizaciones del contenido dentro de un manifiesto. Por ejemplo teniendo dos organizaciones se pueden dar dos opciones diferentes para la navegación en un curso en formato de páginas HTML o sea dos maneras distintas de visualizar el mismo curso. Resources (recursos): Es un elemento XML que contiene referencias a todos los recursos físicos y a los entornos que son necesarios para el manifiesto, lo que incluye metadatos de recursos y referencias a archivos externos. Sub Manifest (manifiesto subordinado): es opcional y puede existir uno o varios. Lógicamente se ven como manifiestos anidados. Files (archivos): estos son los elementos reales del curso que se está empaquetando utilizando el estándar IMS CP. Son ejemplo los archivos de texto, gráficos, páginas HTML, etc. Además dentro de este grupo se encuentran aquellos recursos que se encuentran en sub-directorios que se describen en el o los distintos manifiestos. 39

44 <?xml version="1.0"?> <manifest identifier="manifest1" <metadata> <schema>ims Content</schema> <schemaversion>1.1</schemaversion> <imsmd:record> <imsmd:general> <imsmd:title> US">Manifest</imsmd:langstring> <imsmd:langstring xml:lang="en- </imsmd:title> </imsmd:general> </imsmd:record> </metadata> <organizations default="toc1"> <organization identifier="toc1" structure="hierarchical"> <title>default</title> <item identifier="item1" identifierref="resource1"> <title>lesson 1</title> <item identifier="item2" identifierref="resource2"> </item> <title>introduction 1</title> <item identifier="item3" identifierref="resource3"> </item>.. </item>... </organization> </organizations> <resources> href="lesson1.htm"> <title>content 1</title> <resource identifier="resource1" type="webcontent" <file href="lesson1.htm"/> </resource>... </resources> </manifest> metadata identifierref es una referencia a la sección resource. Debe existir un recurso con ese identificador. 40

45 IMS Learning Design Si hablamos de métodos tradicionales de enseñanza se hallan dos corrientes principales en el diseño de estos modelos: la objetivista es un enfoque más tradicional, incluye modelos que señalan la forma de presentar el contenido considerando los resultados de aprendizaje deseados. la constructivista que busca facilitar la construcción del conocimiento a través de actividades de aprendizaje que permitan su transferencia a tareas de la vida real. Sin embargo, cada profesor tiene su concepción particular del aprendizaje y del conocimiento y sus propias opiniones sobre las variables esenciales que deben considerarse al modelar un proceso de aprendizaje. Desde el punto de vista tecnológico, se pretende diseñar herramientas que no se enfoquen únicamente en la creación de contenidos y recursos, sino que además ayuden a modelar el Learning Design (Diseño del Aprendizaje). Además se pretende al mismo tiempo, garantizar que los materiales educativos puedan ser compartidos entre diferentes plataformas lo que produciría que se reduzcan el tiempo y recursos empleados en la generación de contenido educativo. En 1997 la Universidad Abierta de Holanda OUNL (Open University of the Netherlands) decidió transformar todos sus cursos realizados hasta entonces en cursos on-line (en línea). Los cursos existentes empleaban una variedad de enfoques educativos que consistían en combinaciones de tres elementos básicos: recursos educativos, roles y actividades educativas. El EML (Educational Modelling Language), introducido por la OUNL, permite definir estos tres elementos y especificar la estructura de una Unidad de Aprendizaje (Unit of Learning - UoL) mediante un documento XML. UoL es la actividad o tarea, que se crea con actores (por ejemplo alumnos, profesores) que trabajan para lograr un cierto objetivo educativo. La tarea de la OUNL fue el desarrollo de un framework (marco) que apoye a la diversidad pedagógica y fomentar el intercambio de los materiales e-learning. El objetivo es describir las metodologías educativas implícitas en un proceso de enseñanza, de forma que sean procesables por un LMS. Para ello se utiliza el nuevo concepto, la Unidad de Aprendizaje, ya que se considera que lo importante no son tanto los objetos de aprendizaje por sí mismos, si no las actividades en las que se encuentran implicados. En el año 2003 IMS comenzó el proceso de desarrollo de una especificación para la definición de aspectos educativos, pero en lugar de una especificación totalmente nueva decidió adoptar EML. El resultado fue una nueva especificación llamada IMS Learning Design. El término Learning Design se refiere al conocimiento que emplean los profesores o generadores de contenido educativo cuando diseñan los materiales que son utilizados para la enseñanza. Existen modelos que ayudan a aplicar y difundir esos conocimientos, los cuales determinan cómo diseñar los procesos de aprendizaje para ampliar las habilidades de interpretación de la información adquirida por los estudiantes. 41

46 IMS DRI Repositorios Digitales Interoperables DRI (Digital Repositories Interoperability) define repositorios digitales como cualquier colección de recursos que son accesibles a través de una red sin el conocimiento previo de la estructura de la colección. Los repositorios pueden almacenar assets (recursos) o los metadatos que describen los assets. No es necesario que los assets y sus metadatos sean depositados en el mismo repositorio. Esta especificación utiliza esquemas ya definidos en otras especificaciones IMS como por ejemplo IMS Metadata y Content Packaging. La especificación DRI elabora especificaciones que permiten la interoperabilidad entre diferentes repositorios. El objetivo es que se pueda acceder a cualquier repositorio y recuperar los recursos educativos sin la necesidad de saber cómo es la estructura u organización de dicho almacén. Los metadatos cumplen una función muy importante en esta recuperación para la búsqueda e identificación de los recursos almacenados en el repositorio IMS VDEX Definición e Intercambio de Vocabularios IMS VDEX (Vocabulary Definition and Exchange) permite el intercambio y el procesamiento automático de los términos del lenguaje humano, junto con la información que pueda ayudar a un ser humano para comprender el significado de los diversos términos. Es un lenguaje de marcado (define una gramática) que permite la descripción y la creación de vocabularios controlados que pueden ser fácilmente intercambiables. Un vocabulario es una colección o una lista de palabras con una breve explicación de su significado. VDEX por ejemplo puede ser utilizado para expresar datos válidos en LOM, IMS LRM, ADL SCORM, etc. En estos casos, los términos generalmente no son palabras del lenguaje humano sino que son símbolos abstractos. VDEX considera dos categorías distintas de vocabulario, diferenciados por la clave utilizada para identificar un concepto: Vocabularios donde la clave es algún tipo de token o símbolo, el cual hace referencia de forma efectiva a algún término del lenguaje humano ("tokenized terms" o términos tokenizados). Vocabularios donde la clave es un término del lenguaje humano ("human language terms"). VDEX es capaz de codificar varios tipos de vocabularios: una simple lista de términos plana, un glosario o diccionario, un tesauro, o una jerarquía de términos. A continuación se listan los que requieren ser explicados con más detalle: Descripción de vocabularios controlados que vienen expresados como pares fuente=valor. Descripción de vocabularios jerárquicos o taxonomías. Expresan la posición de un término en una herencia (se trata de un camino en una estructura en forma de árbol). Los identificadores son tokens independientes del lenguaje que pueden estar asociados con cualquier número de referencias en lenguaje humano. En este sentido el modelo de IMS VDEX está dotado de una estructura jerárquica que facilita la representación de una taxonomía. 42

47 Ejemplos de uso: Descripción de tesauros: expresan relaciones entre pares de términos. La estructura del modelo de información no está preparado explícitamente para representar las relaciones ya que éstas generan una estructura de grafo. Para expresar estas relaciones IMS VDEX proporciona términos que representan las posibles relaciones definidas entre pares de términos. La distribución de vocabularios entre muchos usuarios se puede lograr compartiendo archivos XML o mediante el almacenamiento repositorio. Utilizar hojas de estilo XML para seleccionar y generar vista diferentes. La validación de las instancias de metadatos. Se valida un perfil de aplicación, mediante la comparación de los términos del vocabulario utilizado en ciertos elementos de metadatos IMS QTI La especificación Preguntas y Evaluaciones Interoperables QTI (Question & Test Interoperability) describe un modelo de datos para representar preguntas individuales y evaluaciones. Además contempla la estructura para representar los informes de resultados correspondientes a esas preguntas y evaluaciones. Por lo tanto, la especificación permite el intercambio de preguntas, evaluaciones y resultados entre herramientas, repositorios, herramientas de construcción de evaluaciones, LMS y sistemas de evaluación en línea. Es decir el formato Assessment Packaging (paquetes de evaluaciones) de los paquetes, es independiente del sistema o herramienta que fue utilizada para crearlos. El modelo de datos se describe de manera abstracta usando UML para facilitar la vinculación de una amplia gama de herramientas de modelado de datos y lenguajes de programación. Sin embargo, para el intercambio la vinculación utiliza XML y el uso de ésta es muy recomendable. Ésto permite que el mismo grupo de preguntas sea compatible con una variedad de sistemas o plataformas. Por lo que podríamos integrar a un LMS paquetes de preguntas que fueron creadas por un sistema de evaluación electrónica o evaluaciones elaboradas por diferentes herramientas. Además el sistema LMS podría ser informado de cuáles fueron los resultados de esas evaluaciones. La especificación permite, además de las preguntas individuales y evaluaciones, agregar información necesaria como por ejemplo datos para procesamiento de puntuaciones, de respuestas o consejos para la realización de las actividades, etc. QTI brinda un gran conjunto de tipo de preguntas que habitualmente son utilizadas en las evaluaciones, tales como elección verdadero/falso, elección múltiple con respuesta única, elección múltiple con varias respuestas válidas, rellenar campos en blanco, ordenar objetos, relacionar objetos, etc. Además permite definir nuevos tipos de preguntas. Esta especificación se apoya y se relacionada con otras de IMS como LRM, CP, SS y DRI. Además de las especificaciones nombradas anteriormente IMS define otras especificaciones como: 43

48 IMS Reusable Definition of Competency or Educational Objective (Definición de reusabilidad de habilidades o objetivos educativos). IMS Enterprise (Empresarial) IMS Simple Sequencing La especificación Secuenciación Simple SS (Simple Sequencing) define un método para representar el comportamiento previsto por el autor o profesor de una experiencia de aprendizaje. El propósito es que cualquier sistema e-learning pueda dar una secuencia adecuada a las actividades o recursos educativos una manera consistente. La especificación define los comportamientos requeridos y la funcionalidad que los sistemas deben implementar. La especificación define por ejemplo, de acuerdo a los resultados de las interacciones de un alumno con el contenido: el orden en el que se presentan los objetos de aprendizaje. o las reglas para seleccionar un objeto de aprendizaje entre varios posibles ADL La iniciativa de Aprendizaje Distribuido Avanzado ADL (Advanced Distributed Learning) pretende aprovechar las tecnologías para ofrecer educación y formación de alta calidad, de fácil acceso y facilitar la ayuda necesaria en tal proceso. ADL fue fundada en 1997 para estandarizar, modernizar la formación y gestionar la educación. El Departamento de Defensa de EE.UU. y la Oficina Ciencia y Tecnología de la Casa Blanca son responsables de dicha iniciativa. ADL utiliza un método colaborativo que convoca a grupos multinacionales relacionados con la industria, el mundo académico y el gobierno para definir especificaciones y estándares para la industria del aprendizaje. Además determinar el alcance de dichas especificaciones y establecer el desarrollo de herramientas que las validen. Su labor se coordina con otras organizaciones como IEEE, IMS y AICC. Dentro de las estrategias de ADL se encuentran: Explotación de las tecnologías existentes network-based (basadas en red). Creación de una plataforma, cursos y contenido reutilizables reduciendo costos (se reduce tiempo y esfuerzo). Fomentar la colaboración de varios sectores educativos para satisfacer necesidades comunes y generales. Mejorar el rendimiento de las tecnologías de aprendizaje. El desarrollo de estándares y normas comunes. Liberar especificaciones ADL como por ejemplo SCORM, ADL Registry, Training Evaluation y Learning Technology Lab. ADL trabaja con varias organizaciones para desarrollar y validar las especificaciones y estándares. ADL aporta ideas y conceptos técnicos, así como también integra y realiza las pruebas necesarias en las especificaciones que se encuentran en las primeras etapas de desarrollo (nivel de especificación) para que lleguen a un estado de adopción generalizada (nivel de estandarización). 44

49 SCORM GRADUATE! UN REPOSITORIO DE OBJETOS El principal resultado de ADL es un conjunto de especificaciones que, bajo la denominación Modelo de Referencia para Objetos de Contenido Compartibles SCORM (Sharable Content Object Reference Model) miden la efectividad y aplicabilidad (nivel de validación) de especificaciones y estándares en el área del e-learning. Un modelo de referencia es un modelo que muestra qué tipo de servicios serán necesarios para resolver un problema particular, la forma en que se pueden unir, los estándares que se aplican y cómo podrían ser utilizados. Así surgen los modelos de referencia que ensamblan distintos estándares y especificaciones para formar un sistema e-learning completo. SCORM aplica las tecnologías del aprendizaje mediante el uso de un modelo de contenido para garantizar la aplicación consistente de la educación y formación en la comunidad e-learning. SCORM se basa en la labor de organizaciones como AICC, IMS GLC, IEEE, ARIADNE y otros, para crear un modelo de referencia unificado que integre las guías y especificaciones técnicas y que cumpla con los requisitos de alto nivel de sistemas y contenido de aprendizaje basados en Web: Accesibilidad: La capacidad para localizar y acceder a los componentes de aprendizaje desde un lugar remoto y que éstos puedan ser distribuidos a muchos otros lugares. Interoperabilidad: la capacidad de tomar componentes educativos desarrollados por herramientas o plataformas y que estos puedan ser utilizados en otros lugares por otro conjunto de herramientas o plataformas. Durabilidad: La capacidad de soportar la evolución y los cambios de la tecnología sin que esto repercuta en el costo de rediseño, reconfiguración o re codificación. Reutilización: La capacidad de incorporar componentes educativos utilizados en otras aplicaciones o contextos educativos. Las distintas versiones de SCORM se muestran a continuación: Versiones de SCORM Fecha de publicación SCORM Versión 1.0 Enero 2000 SCORM Versión 1.1 Enero 2001 SCORM Versión 1.2 Octubre 2001 SCORM st Edition Enero 2004 SCORM nd Edition Julio 2004 SCORM rd Edition Octubre 2006 SCORM th Edition Versión 1.1 Agosto 2009 SCORM versión SCORM v1.2 brindó la capacidad para empaquetar material educativo y agregó metadatos para la importación y exportación. El paquete de contenido es una parte integral para alcanzar uno de los requisitos generales de SCORM que es la interoperabilidad. 45

50 Esta versión se organiza en tres libros donde cada uno se centra en un aspecto técnico distinto: Visión general (overview). Modelo de agregación de contenidos CAM (Content Aggregation Model). Entorno de tiempo de ejecución RTE (Run Time Environment). En esta especificación se aplican las tecnologías desarrolladas por grupos como IMS GLC, AICC, ARIADNE y la IEEEE LTSC para definir un modelo de contenido y elaborar recomendaciones para la implementación consistente que sirva a toda la comunidad del e-learning. En la siguiente figura se visualizan estos conceptos: Figura 16 - SCORM agrupa las diversas especificaciones de distintos libros (BOOK) fuente: Ref. [9] En la siguiente tabla se detallan las distintas especificaciones que son referenciadas en los libros de SCORM: Iniciativa Especificación Contenido de la especificación Fecha AICC CMI001 - CMI Guidelines for Interoperability Versión 3.4. AICC Course Structure Format AICC CMI Data Model Octubre 2000 IEEE dictionary: define los Obs: en 1998 IMS y ARIADNE IEEE LTSC elementos de metadatos de LOM - Borrador de Trabajo presentaron una propuesta al IEEE que serviría como base de trabajo para el 18 abril (grupo 12) grupo 12.encargado de definir LOM IMS GLC CP v1.1.2 agosto 2001 IMS LRM Information Model (hace referencia IEEE LTSC LOM Borrador de Trabajo 6.1) IMS GLC LRM Specification v 1.2 IMS LRM XML Binding Specifications (además basada en W3C XML specification versión 1.0) IMS LRM Best Practices and Implementation Guide. 20 abril

51 Modelo de agregación de contenidos Modelo de Agregación de Contenido (CAM) define cómo es la estructura de un curso SCORM en base a unidades más pequeñas. Desde la perspectiva educativa, un curso on-line se puede componer de módulos, lecciones, capítulos, etc. SCORM determina la forma de describir esta estructura con el objetivo de que las plataformas e-learning sepan reconocer tal estructura de curso. Para ello CAM define: Content Model (Modelo de Contenidos): describe los componentes que son parte de un proceso o experiencia educativa. Los componentes se dividen en dos grandes grupos (ver tabla). Metadata: descripción o clasificación de los componentes del Content Model, que permite realizar búsquedas o catalogar dichos componentes. Content Packaging: mecanismo para empaquetar los contenidos, y hacerlos fácilmente intercambiables entre distintas plataformas o herramientas. La siguiente tabla muestra los temas que se presentan y detallan en el documento CAM de SCORM v1.2. Tema Subtema Contenido Descripción Son archivos digitales (texto, imágenes, audio, vídeo, páginas Web, flash y otros Assets (recurso): materiales que pueden ser distribuidos en la Web) El Asset es el elemento básico de construcción con que se representa el contenido Representan el núcleo de la Content Model Content Model Components SCO (Sharable Courseware Object) especificación SCORM y se definen como una colección de uno o más recursos que representa un elemento educativo indivisible y que emplea el RTE (Run Time Environment). de SCORM para comunicarse con un LMS. Es una organización de Assets y SCOs que forma una unidad educativa Content Aggregation (Agregación de contenidos) cohesiva. Es como una receta: instrucciones para lograr un resultado. En la educación el resultado es la selección de recursos de aprendizaje con una secuencia dada y que refleja una estructura (módulo, curso o capítulo) Metadata Componets Content Aggretation Metadata SCO Metadata Assets Metadata Metadata Information Model 47

52 XML Binding Application Profiles Best Practice (Guía de buenas prácticas) Estructure Description Content Packaging Information Model CP XML Binding Application Profiles Entorno de tiempo de ejecución Entorno de tiempo de ejecución (RTE) especifica mecanismos que permiten al contenido comunicarse con la plataforma LMS. Por ejemplo para registrar el progreso de un alumno (su grado de avance, puntuación, etc.). La siguiente tabla muestra los temas que se presentan y detallan en el documento RTE de SCORM v1.2. Tema Launch (ejecución) Application Program interface (API) Contenido Assets: No tienen, por sí mismos, posibilidad de comunicación con la plataforma LMS por ejemplo archivo *.doc ó *.PDF. SCO (Sharable Courseware Object): capacidad para comunicarse con la plataforma LMS SCO to LMS Comunication API SCO Responsability LMS Responsability Elements Data Model Handling List (manejo de listas) Data Type Controlled Vocabulary Behavior (comportamiento) Compatibilidad SCORM cuenta con un mecanismo por el cual se puede verificar, validar y asegurar la compatibilidad e interoperabilidad de cualquier producto con sus especificaciones. A través de un juego de herramientas, el ADL Conformance Test Suite, puede testear y validar el correcto cumplimiento de las especificaciones SCORM de por ejemplo un paquete SCORM, LMS o repositorio. Esto facilita, en una plataforma dada, la incorporación de contenidos creados por terceros, agilizando el intercambio de esos contenidos. 48

53 SCORM st Edition El número de especificaciones y el tamaño de los documentos han hecho que sea necesario un cambio en los libros de SCORM para que sea más efectivo gestionar las revisiones y correcciones del conjunto de documentos. Esta versión cuenta con cuatro libros: Visión general (overview). CAM. RTE. Secuenciación y navegación SN (Sequencing and Navigation). ADL SCORM 2004 es un modelo de referencia para las siguientes especificaciones: Iniciativa Especificación Fecha IEEE LTSC IEEE Data Model For Content Object Communication noviembre 2003 IEEE LTSC IEEE LTSC IEEE LTSC IMS GLC IMS GLC ECMAScript Application Programming Interface for Content to Runtime Services Communication LOM Data Model XML Binding for LOM Data Model CP Simple Sequencing Nota: El Equipo Técnico de la ADL ya da soporte a esta edición. SCORM rd Edition 2006 En esta versión SCORM continúa elaborando un CAM y RTE para el contenido educativo basado en Web. Además sigue fortaleciendo sus especificaciones y estándares para proporcionar un conjunto completo de capacidades de e-learning que permiten la interoperabilidad, la accesibilidad y la reutilización del contenido de aprendizaje basado en Web. ADL valida y certifica las siguientes especificaciones: Iniciativa Especificación Fecha IEEE LTSC ECMAScript Application Programming Interface for Content to Runtime Services Communication. noviembre 2003 IEEE LTSC LOM 2002 IEEE LTSC XML Binding for LOM 2005 IMS GLC CP Versión Final Specification octubre 2004 IMS GLC CP Best Practice Guide, Versión Final Specification octubre 2004 IMS GLC Simple Sequencing Behavior and Information Model v1.0 Final Specification AICC CMI Guidelines for Interoperability (CMI001) Versión 3.5 abril

54 IEEE LTSC El Instituto de Ingenieros Eléctricos y Electrónicos IEEE (Institute of Electrical and Electronic Engineer de sus siglas en inglés) es una asociación técnica profesional y mundial dedicada mayormente a la publicación de estándares. Se trata de un organismo que promueve la creación de una norma ISO, una normativa estándar de amplia aceptación. Dentro del famoso instituto IEEE se encuentra el LTSC (Learning Technologies Standarization Committee) destinado a gestionar las tecnologías relacionadas con el aprendizaje y la formación. El LTSC se encarga de preparar estándares técnicos, prácticas y guías para componentes software, herramientas, tecnologías y métodos de diseño que facilitan el desarrollo, implantación, mantenimiento e interoperabilidad de sistemas de educación y de formación. La institución cueta com grupos de trabajo WGs (working groups) y grupos de estudio SGs (study groups) que elaboran especificaciones para distintas áreas de conocimiento dentro de la industria del e-learning por ejemplo: Áreas WGs Subgrupos Descripción actividades generales IEEE Architecture and Reference Model IEEE Glossary : IEEE Standard for Learning Object Metadata Especifica un esquema conceptual de los datos que define la estructura de los metadatos de los OAs : Standard for Su propósito es proveer de ISO/IEC binding for semántica precisa para modelos de Learning Object Metadata datos, según lo permitido por la data model notación datos y metadatos IEEE Learning Object Metadata : Standard for Learning Technology- Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata Su propósito es proveer de manera obligatoria XML para habilitar el intercambio de instancias de LOM en sistemas que implementan el modelo de datos : Standard for Resource Description Framework (RDF) binding for Learning Object Metadata data model El propósito de este estándar es proveer RDF (Resource Description Framework) para habilitar el cambio de instancias de LOM en sistemas que implementan el modelo de datos

55 Áreas WGs Subgrupos Descripción IEEE Semantics and Exchange Bindings IEEE Data Interchange Protocols : Data Model for LMS y aplicaciones IEEE Computer Managed Instruction Content to Learning Management System Communication : ECMAScript API for Content to Runtime Services Communication Se basa en CMI v3.4 de AICC Se basa en la API CMI v3.4 de AICC IEEE Platforms and Media Profiles IEEE Competency Definitions Los trabajos de IEEE LTSC se basan en los esfuerzos previos hechos para la descripción de recursos educativos en los proyectos ARIADNE, IMS y Dublín Core y también en los trabajos desarrollados por el comité de la AICC. En estos momentos el área de mayor impacto es la relacionada con los metadatos de los recursos educativos, ya que el estándar IEEE LOM es el formato más utilizado en la actualidad en los sistemas de e-learning. Como se muestra en la tabla anterior éste último formato es parte del estándar IEEE LOM que especifica cuáles son los metadatos necesarios para describir un recurso y el intercambio de instancias LOM mediante la utilización obligatoria de archivos XML. Además promueve la utilización RDF (Resource Description Framework), una estructura para el intercambio de metadatos. RDF es equivalente al XML pero agrega una serie de restricciones estructurales. Por ello ofrece una potencia mayor que el XML ya que permite expresar semántica de tal manera que es posible interpretarlo de forma automática IEEE LOM El estándar IEEE LOM es el resultado de años de trabajo y colaboración de muchas instituciones mundiales. La institución IEEE fue la responsable de convertir lo que hasta hace unos años era un proyecto de descripción de recursos en un estándar tal como lo conocemos en estos días. En el año 1998 el Proyecto IMS de EEUU (no estaba establecida como IMS Global Consortium) y la institución europea ARIADNE colaboraron con la iniciativa de crear un norma que sirva para la descripción de recursos digitales y presentaron a la IEEE un documento que sería la base para el actual estándar LOM tal como lo conocemos en estos días. 51

56 En julio de 1999 el grupo de trabajo 12 de IEEE LTSC publica la versión 3.5 de LOM. Ese mismo año el proyecto IMS se consolida y se convierte en la institución IMS Global Consortium, dando a conocer mundialmente las recomendaciones de la IEEE y la AICC. Las especificaciones para metadatos IMS versión 1.0 se basaban LOM v3.5. El estándar IEEE LOM especifica la sintaxis y la semántica de los metadatos LOM definiendo los atributos necesarios para describir completamente y adecuadamente un OA. Un OA es cualquier entidad, digital o no, que puede ser utilizada, reutilizada o referenciada durante el aprendizaje apoyado por tecnología. Por ejemplo dentro de las tecnologías que son utilizadas como apoyo del aprendizaje encontramos: aprendizaje apoyado en los sistemas de formación basados en computadoras, entornos de aprendizaje interactivos, sistemas inteligentes de enseñanza asistida por computadora, sistemas de enseñanza a distancia y ambientes de aprendizaje colaborativo. Los OA pueden almacenar contenidos multimedia, contenidos educativos, objetivos de aprendizaje, software educativo, y la descripción de: las personas, organizaciones o eventos referenciados durante el aprendizaje apoyado en la tecnología. El estándar LOM centra sus esfuerzos en un conjunto (lo más reducido posible) de atributos necesarios para que estos OAs sean manejados, localizados y evaluados. Los objetivos de ésta especificación son: Permitir a estudiantes e profesores buscar, evaluar, adquirir y utilizar OAs. Facilitar el uso compartido y el intercambio de OA entre tecnologías de apoyo al aprendizaje como LMS, Repositorios, Bibliotecas digitales, etc. Permitir el desarrollo de OAs en unidades que puedan ser acopladas y disgregadas. Proporcionar el conjunto mínimo de atributos para que estos OAs sean gestionados, localizados y evaluados de manera apropiada. Permitir a los generadores de contenidos mediante el uso de una computadora desarrollar clases o cursos personalizados para estudiantes individuales en forma automática y dinámica. Permitir a las instituciones educativas y de formación tanto del gobierno, públicas y privadas, que puedan expresar sus contenidos educativos y las normas de rendimiento en un formato estandarizado que es independiente del contenido en sí. Para definir un estándar simple pero extensible a varios dominios y jurisdicciones con el fin de que sea fácil y ampliamente adoptado y aplicado. Proporciona soporte necesario para seguridad y autentificación en la distribución y el uso de OAs. Hablaremos del estándar IEEE ya que es el formato oficial más utilizado en la industria del e-learning. Muchas iniciativas han utilizado este estándar dentro de sus reglas y normas. Por ejemplo tanto IMS como ADL han adoptado LOM dentro de sus especificaciones. 52

57 IEEE LOM El estándar IEEE especifica un esquema de metadatos para la descripción de OAs. Detalla un esquema conceptual de datos que define la estructura de una instancia de metadatos para los OA. Para este estándar, un OA se define como cualquier entidad, digital o no, que pueda ser utilizada en el aprendizaje, educación o formación. Para el estándar una instancia de metadatos describe las características relevantes del objeto al que se aplica. Dichas características se pueden agrupar en categorías. El Esquema Base de LOM 1.0 se divide en nueve categorías [29]: Categorías General Ciclo de Vida. Meta-Metadatos Técnica Uso Educativo Derechos Relación Anotación Clasificación Descripción información general que describe un OA de manera global características relacionadas con la historia y el estado actual del OA, y aquellas que le han afectado durante su evolución información sobre la propia instancia de Metadatos, (en lugar del OA descrito por la instancia de metadatos) requerimientos y características técnicas del OA características educativas y pedagógicas del objeto derechos de propiedad intelectual y las condiciones para el uso del OA Características que definen la relación entre este OA y otros objetos educativos relacionados. comentarios sobre el uso educativo del objeto e información sobre cuándo y por quién fueron creados dichos comentarios describe este OA en relación a un determinado sistema de clasificación El modelo de datos de LOM es una jerarquía de elementos de datos, incluyendo elementos de datos agregados y simples (nodos hoja). En el esquema base LOMv1.0 sólo los nodos hoja tienen valores individuales definidos a través de sus vocabularios controlados y tipos de datos asociados. 53

58 En la siguiente figura se muestra la jerarquía de los elementos de datos LOM. Figura 17 jerarquía de los metadatos LOM fuente: Ref. [11] Entre las características que presenta esta especificación encontramos: Interoperabilidad semántica: LOM especifica un esquema conceptual de datos común para las implementaciones de los metadatos de OAs logrando un alto grado de interoperabilidad semántica. Como consecuencia se simplifica la tarea de interpretar los metadatos en los distintos sistemas o plataformas que implementan este estándar. Para algunos elementos de datos se definen vocabularios controlados o listas de valores recomendados. Por ejemplo en la categoría General structure (estructura) que es la estructura interna del material, LOM define el un vocabulario controlado para describirla. Se pueden usar también otros valores. Sin embargo, los metadatos que se ajustan a los valores recomendados tendrán grado de interoperabilidad semántica más alto. Flexible: Los autores pueden utilizar sus propios vocabularios, adaptados a sus necesidades particulares y asignar un valor a un elemento que no forma parte de la lista de vocabularios controlados de LOM. Esta opción proporciona mayor flexibilidad a expensas de la interoperabilidad semántica. Los valores definidos por un usuario o comunidad concreta, no se usarán consistentemente en otros sistemas o dominios. Extensibilidad: La categoría Clasificación, permite a un usuario final clasificar un OA de acuerdo con una estructura de clasificación arbitraria. Como puede hacerse referencia a cualquier sistema de clasificación, esta categoría se proporciona como un mecanismo de extensión 54

59 IEEE El LTSC escogió unos de los aportes de la AICC y realizando mejoras obtuvo una descripción más detallada de los contenidos incluidos en un curso que la ofrecida hasta entonces por la especificación AGR 010 de la AICC. Se divide en: IEEE : éste estándar se basa en un modelo de datos "Computer Managed Instruction (CMI) Guidelines For Interoperability," versión 3.4, definido por AICC que se encuentra disponible en Para apoyar tanto a las implementaciones existentes como a las nuevas la IEEE realiza correcciones técnicas en los elementos del CMI: selecciona únicamente aquellos elementos que son mayormente utilizados. modifica el nombre de algunos elementos para aclarar su significado. modifica los tipos de datos de elementos para reflejar los tipos de la norma ISO y requisitos de internacionalización. elimina algunas estructuras de organización usadas por CMI para grupos de elementos que en la práctica son específicos de la comunidad AICC y no de aplicación general. introduce algunos elementos de datos que no están presentes en CMI para corregir defectos técnicos conocidos. IEEE : También hace referencia a otra especificación ya que se basa en la API definida por "CMI Guidelines For Interoperability versión ISO La organización internacional de estándares ISO (International Standards Organisation) es el mayor desarrollador y editor de estándares mundiales. Es una red de institutos de estándares nacionales de 163 países que trabaja en colaboración con los gobiernos, empresas y organizaciones de usuarios. ISO es una Organización NO gubernamental que forma un nexo entre los sectores público y privado. Por un lado, muchos de los institutos pertenecen a la estructura gubernamental de sus países o son impulsados por su gobierno a ser miembros de ISO. Por otra parte, otros miembros tienen sus raíces únicamente en el sector privado, que han sido creadas por las asociaciones nacionales privadas relacionadas con la industria. Por lo tanto, las normas ISO permiten consensos para llegar a soluciones que satisfagan tanto las necesidades más amplias de la sociedad como las del negocio. Numerosos estándares se desarrollan conjuntamente con la IEC (normas ISO/IEC). La comisión electrónica internacional IEC (International Electrotechnical Commission) es una organización dedicada a desarrollar estándares en los campos eléctrico, electrónico y tecnologías relacionadas ISO/IEC JTC 1 JTC1 es un comité técnico formado por ISO y por IEC tiene como misión desarrollar, mantener, promover y facilitar estándares de TI (Information technology) requeridos por los mercados de negocios mundiales y por los requisitos de los usuarios en 55

60 relación con la elaboración sistemas de información, herramientas y productos portables, compatibles e interoperables. Comité Estandares Descripción JTC1: TI SC2 SC6 SC7 SC 17 SC22, SC23, SC24, SC25, SC27, SC28, SC29, SC31,SC32, SC34, SC35 SC36:dedicado a desarrollar ITLET SC37 Juegos de caracteres cifrados Telecomunicaciones e intercambio de información entre los sistemas Ingeniería del software y de sistemas Tarjetas e identificación personal WG1: Vocabulario WG2: Tecnologías de Colaboración WG3: Información del estudiante WG4: Gestión y entrega WG5: Aseguramiento de la calidad y marco de trabajo descriptivo WG6: Perfiles Estandarizados Internacionales WG7: Cultura, lenguaje y actividades del comportamiento humano JTC 1/SC 36 La mayor parte del trabajo se realiza por distintos subcomités que se ocupan de un área o campo en particular. Dentro de éstos se encuentra el SC36. SC36 es un subcomité dentro de JTC1 dedicado a elaborar estándares en el ámbito de las Tecnologías de Información para la formación, educación y aprendizaje ITLET (Information Technology for Learning, Education and Training) Los estándares se desarrollan para apoyar a individuos, grupos u organizaciones y para permitir la interoperabilidad y reutilización de los recursos y herramientas. Numerosos países están representados en este grupo y han creado siete comisiones o grupos de trabajo. 2.4 OPEN ACCESS (ACCESO ABIERTO) El open access (acceso abierto) nació como solución a problemas en el ámbito científico ya que los profesores opinaban que sus trabajos no estaban siendo consultados por otros profesionales. Además los lectores no tenían acceso a toda la información por lo que el conocimiento quedaba limitado. El acceso abierto a la información científica significa que ésta está disponible en Internet permitiendo que cualquier usuario pueda leer, descargar, imprimir y distribuir o hacer uso en forma legal de la misma. 56

61 Las ventajas que presenta esta forma de acceso son: Intercambio de ideas. Desarrollo de nuevos conocimientos. Acelera la investigación. Compartir el aprendizaje. Aumenta la difusión y el impacto de la investigación. OAI (Open Archives Initiative) es parte del movimiento internacional donde científicos, estudiosos y bibliotecólogos de todo el mundo buscan dejar libres los contenidos al alcance de la comunidad QUÉ ES OAI? Los avances tecnológicos, el furor de Internet y la posibilidad del acceso a la información dan origen a la gran manifestación de contenido digital al alcance de la sociedad. Esto que es muy útil trae aparejado otras consecuencias como la desorganización por el inmenso volumen de información, la duplicación de los datos y la falta de interconexión entre los sistemas que contienen esa información. La Open Archives Initiative (OAI) se creó con el objetivo de desarrollar estándares de interoperabilidad para facilitar el intercambio de contenido en Internet. Como primera medida surgió para incrementar la disponibilidad de publicaciones científicas (eprints) pero pronto se descubrió que el intercambio de contenido bibliográfico utilizando un protocolo común se podría implementar más allá de la comunidad científica y utilizarlo para otros materiales digitales. Su nombre proviene de los siguientes términos: Open (Abierto): Se refiere al punto de vista de la arquitectura del sistema y la disponibilidad de la información defiendo interfaces que permitan el fácil acceso. No en el sentido de gratuito o acceso ilimitado. Archive (Archivo): Depósito donde se almacena información de distinto tipo. En sus orígenes se pensaba en almacenar documentos científicos. No se refiere al concepto tradicional de archivo donde aparecen conceptos de preservación y conservación de archivos. Initiative (Iniciativa): el proyecto se centró en permitir el intercambio de contenido digital entre distintas máquinas utilizando reglas comunes Convención de Santa Fe a la OAI En el año 1999 se realizó una reunión en Santa Fe (Nuevo México, USA) y los participantes (especialistas en bibliotecas digitales) debieron analizar problemas relacionados con el intercambio de los contenidos, definir sistemas de identificación comunes, formatos de metadatos, modelos de documentos o protocolos. Los participantes optaron por una solución minimalista con el objetivo de tener una amplia aceptación entre la comunidad de proveedores de contenido digital. La solución llamada Metadata Harvesting (recolección de metadatos) permitía a los proveedores presentar sus metadatos a través de una interfaz; esta serviría como base para el desarrollo de servicios de mayor complejidad o mayor valor agregado. 57

62 El resultado de la reunión fue un conjunto de acuerdos técnicos y de organización conocidos como la Convención de Santa Fe. Los aspectos técnicos incluían tres puntos fundamentales: un formato para los metadatos. un protocolo basado en el antiguo Dienst 3. un sistema de identificación. En la reunión de Santa Fe se puso mucho énfasis en la búsqueda de interoperabilidad por lo que se definieron cuestiones técnicas simplistas como: Norma de metadatos para recuperar documentos: Dublín Core en formato simplificado. XML como sintaxis. OAI-PMH (Open Archives Initiative Protocolo for Metadata Harvesting) para recolección de metadatos. Sistema de identificación uniforme: Un identificador único identifica de forma inequívoca un elemento dentro de un repositorio que es utilizado en las peticiones OAI-PMH para la extracción de metadatos. Se optó por el formato URI (Uniform Resource Identifier). Rechazo de la búsqueda distribuida (Z39.50): una mínima complicación para las instituciones que deseen implementarlo. Traslado de la complejidad a los servicios: creación de servicios basados en la utilización de la información almacenada en los repositorios de archivos abiertos PROTOCOLO OAI-PMH El software desarrollado bajo la filosofía de OAI implica que debe compartir los metadatos de cualquier tipo de material digital (audio, música, videos, animaciones, planos, objetos de aprendizaje, etc.) y así colaborar en la integración de distintos sistemas de información. Estos programas se pueden dividir en dos clases de acuerdo con el tratamiento de la información: proveedor de datos y proveedor de servicios. Los proveedores de datos son administradores de contenido que soportan OAI donde se presentan los metadatos y el material asociado. Los proveedores de servicio se encargan de recolectar la información ofrecida por los proveedores de datos (metadatos) distribuidos en Internet, en un sistema centralizado utilizando el protocolo OAI. De esta manera se construye un servicio más completo para los usuarios finales. Los proveedores de servicios pueden adoptar dos formas de trabajo según como está ubicada la información en Internet y de qué manera presentan el material los repositorios que la contienen: 3 Dienst (Distributed Interactive Extensible Network Server for Techreports) protocolo basado en HTTP y proporciona una interfaz orientada a objetos para un modelo de documento. El modelo de documento permite tener acceso al documento en su totalidad o nombrado subpartes. Haciendo uso de este protocolo un cliente Web podría buscar documentos distribuidos en distintos sitios por texto completo o navegar rápidamente usando vistas en miniatura de los documentos. 58

63 Federación: La información está almacenada en forma descentralizada. Cada vez que el usuario desea realizar una búsqueda el proveedor de servicios ejecuta los servicios remotamente dependiendo de las necesidades del usuario y la lista de proveedores de datos que contenga. Requiere más esfuerzo en cada fuente de contenido digital pero es más fácil para el sistema local. Las búsquedas federadas con el protocolo Z39.50 son un ejemplo de esta forma de presentar los datos o metadatos. Recolección: los metadatos se transfieren continuamente desde la fuente (proveedores de datos o metadatos) al punto donde los proveedores de servicios están localizados y se almacenan en forma centralizada. Los usuarios finales formulan las consultas a través de la interfaz que ofrece el proveedor de servicios (sistema central). Esta forma de trabajar requiere más esfuerzo en el sistema local pero es más simple para los proveedores de datos. Esta solución puede ser utilizada como base para desarrollar servicios más complejos. Un ejemplo es la unión de catálogos. La tendencia de OAI se centra en recolección a través de la creación del protocolo de recolección de metadatos OAI-PMH (Open Archives Initiative Protocolo for Metadata Harvesting) tanto en proveedores de datos como de servicios. Es un protocolo simple que permite el intercambio de metadatos de cualquier material almacenado en soporte electrónico. Los metadatos a transferir son codificados en Dublín Core en formato simplificado por lo tanto los que quieran implementar este protocolo deberán convertir sus datos, como mínimo, en un formato común de 15 elementos. Se eligió este formato por su simplicidad y por las múltiples disciplinas en las que estaba siendo usado. A continuación daremos una breve descripción de la forma de trabajar del protocolo: OAI-PMH utiliza el protocolo HTTP para realizar solicitudes y respuestas entre un proveedor de servicios y un proveedor de datos. Estas transacciones son realizadas como operaciones de GET/POST que representan las operaciones de recepción y envío de información entre un programa cliente/servidor vía protocolo HTTP. Las respuestas que proporciona el proveedor de datos son presentadas en documentos XML. Veamos un esquema de su funcionamiento: Figura 18 Funcionamiento de OAI-PMH fuente: Ref. [46] 59

64 El protocolo soporta múltiples formatos para expresar los metadatos, no obstante requiere que todos los servidores ofrezcan los registros utilizando al menos Dublín Core no calificado en formato XML. El servidor o repositorio puede además ofrecer otros formatos como por ejemplo MARC. Este protocolo trabaja con distintos tipos de datos: Resource (recurso) es un material digital. Ítem es una colección de propiedades sobre un recurso (title, author, etc.). Propiedades disponibles en el repositorio sobre el recurso. Record (registro) es un ítem con un formato XML que responde a un XSD. Los registros se asocian con metadatos. Como OAI-PMH realiza recolección de registros, éstos contienen los metadatos y campos adicionales necesarios para la operación de recolección. Por ejemplo los metadatos recolectados contienen enlaces útiles al contenido digital (recurso). EL protocolo OAI-PMH define seis (6) tipos de solicitudes que el cliente puede realizar al servidor de la forma clave=valor y algunos parámetros complementarios: Solicitud Descripción de la solicitud Argumentos Descripción Argumentos GetRecord Permite recuperar un registro identifier metadataprefix identificador del registro formato de respuesta Permite recuperar Identify información del servidor o repositorio ListIdentifiers Permite recuperar los encabezamientos de los registros [from] [until] fecha desde en formato UTC. fecha hasta en formato UTC Formato de metadatos a recuperar. Los formatos [set] criterio de búsqueda metadataprefix que soporta el repositorio se pueden consultar con ListMetadataFormats. resumptiontoke flujo de control ídem al anterior pero ListRecords permite recuperar registros completos Permite recuperar ListSets información de un conjunto de registros Lista de los formatos de ListMetadataFormats metadatos que soporta el OAI-PMH 60

65 2.5 INTRODUCCIÓN AL SOFTWARE LIBRE FREE SOFTWARE Y OPEN SOURCE Son dos movimientos filosóficos que se preocupan de los derechos sobre el software. Son diferentes en lo que respecta a sus ideas filosóficas pero en la práctica, esto no es tan marcado. "El software libre" es un asunto de libertad, no de precio. Para entender el concepto, se debe pensar en "libre" como en "libertad de expresión". Free Software o Software Libre se preocupa de la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, modificar el software y distribuirlo modificado. En su visión de libertad restringir estas propiedades en el software es inmoral. Esta idea expresa que los usuarios de programas tienen cuatro libertades [17]: I. La libertad de ejecutar el programa, para cualquier propósito (libertad 0). II. La libertad de estudiar cómo trabaja el programa, y cambiarlo para que haga lo que uno quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello. III. La libertad de redistribuir copias para que pueda ayudar al prójimo (libertad 2). IV. La libertad de distribuir copias de sus versiones modificadas a terceros (libertad 3). Si lo hace, puede dar a toda la comunidad una oportunidad de beneficiarse de sus cambios. El acceso al código fuente es una condición necesaria para ello. Open Source o Código abierto se preocupa más de lo práctico y su idea es el software es más valioso si podemos obtener su código fuente. Ésto permite modificarlo y redistribuirlo, posibilitando que el software sea de mayor calidad y más creativo. Se llega más rápido a satisfacer las necesidades de los usuarios ya que el trabajo colaborativo hace que surjan infinidades de mejoras para el software del cual se tiene acceso a su código fuente. Los dos movimientos (Free Software y Open Source) afirman que no están en contra de añadir costos al software. Sino que no encuentran aceptables costos que van más allá de la de los gastos que implican la entrega de un software, como por ejemplo la venta de una licencia software. Un gasto aceptable y que se le puede sumar al software sería por ejemplo el agregado de manuales. Según estas dos filosofías un usuario podría realizar la venta de un software que ha sido desarrollado por terceras personas. Sin embargo las acciones de la persona que hace la compra no están limitadas, éste podría venderlo o cederlo. Además es preciso que el comprador tenga acceso al código fuente, lo que lo posibilita a modificar el código y distribuirlo según sus necesidades. Por ejemplo una persona defensora del Free Software frente a un software propietario diría algo como Este software es inmoral, ya que no tengo derecho a ver lo que hace en mi computador y un defensor del Open Source diría Este software es de mala calidad ya que pocas personas han participado de su desarrollo y depende de una sola empresa para evolucionar El software libre suele estar disponible gratuitamente o al precio de costo de la distribución a través de algunos medios (costo de entrega). No hay que confundir 61

66 software libre con software gratuito, ya que éste último es un software restrictivo que se distribuye gratuitamente no se tiene derecho a modificar, vender o distribuir. El software gratis o freeware no necesariamente es software libre y muy rara vez es de código abierto. 2.6 LICENCIAS QUÉ ES UNA LICENCIA DE SOFTWARE? El diccionario de la RAE (Real Academia Española) define en primer término a licencia como un permiso para hacer algo, por lo tanto una licencia software es básicamente un elemento legal que brinda a los usuarios del software determinadas libertades o permisos de uso. Una licencia es básicamente un documento en el cual queda de manifiesto un contrato, donde el usuario tiene especificado qué puede y qué no puede hacer con el software que tiene en sus manos. Existe la posibilidad de incluir con el software una determinada licencia que regule su uso. Si un software no posee licencia, se considera de dominio público. Por el contrario si tiene una licencia, por más débil que sea, ya no se considera de dominio público. Un software de dominio público pertenece a toda la humanidad, y cualquiera puede utilizarlo con fines legales. Este software puede ser una donación del autor a la humanidad o cuando los derechos de éste han caducado, por ejemplo 70 años después de su muerte. Según la filosofía y deseos del autor de un software, éste puede tener diversos fines y objetivos, por lo tanto hay varios tipos de licencia, algunas son más fuertes y otras más débiles. Cuando hablamos de licencia fuerte estamos implicando una mayor cantidad de derechos reservados por el autor, y cuando hablamos de licencia débil estamos indicando que el usuario final tiene más libertades en el uso del software COPYRIGHT VS COPYLEFT? Empecemos definiendo copyright. Copyright es una palabra de origen inglés que significa derecho de autor o literalmente derecho de copia. Detrás del concepto de copyright, existen diferentes normas y leyes que dan forma y especifican estos derechos que tiene el creador de una obra intelectual, o la persona que pueda demostrar su autoría. Aquí en Argentina los derechos de autor están respaldados en primera instancia por la Constitución Nacional en su artículo n 17: Todo autor o inventor es propietario exclusivo de su obra, invento o descubrimiento, por el término que le acuerde la ley. La ley específica a la que se refiere es la ley n que regula la Propiedad Intelectual. En dicha ley está expresamente definido que el producto software (programa de computación) goza de la propiedad intelectual por parte de sus autores o creadores. Por otro lado copyleft es una forma de licencia que modifica los derechos tradicionales de autor impuestos por el copyright, es por esto que puede entenderse como un opuesto al copyright. Su filosofía es la de permitir que el receptor de una copia de 4 Dicha ley se actualizó con la ley n de 1998 específicamente para incluir bajo protección al software 62

67 software pueda utilizarla, analizarla, modificarla, publicarla y compartirla con los demás. No se trata de algo ilegal, es únicamente una cuestión filosófica de cómo se debe utilizar la obra y el nombre viene de un simple juego de palabras opuestas. El autor de un software que lo licencia utilizando copyleft, sabe la finalidad con la que ha desarrollado el software. Por lo tanto el copyleft les da la libertad a los usuarios del software sin riesgos que los derechos que el autor pensó para el software, sean capturados por intermediarios. Esto significa que nadie puede adueñarse de un software licenciado con copyleft, siempre habrá una copia disponible y el usuario tiene la libertad para modificar el software que el autor pensó libre. Esto no restringe a alguien que quiera desarrollar un software con copyright a partir de un software con copyleft. Veremos más adelante un ejemplo de licencia copyleft, la denominada CC (Creative Commons). Es importante aclarar que siempre hay un propietario del software, tanto en copyright como en copyleft, la diferencia es qué permisos les da ese propietario a los usuarios del mismo DISTINTOS TIPOS DE LICENCIAS DE SOFTWARE Podemos distinguir distintos tipos de licencia según la cantidad de derechos que el autor reserva sobre su obra. Pero básicamente encontramos tres grandes grupos: las licencias de código abierto permisivas, las licencias de código abierto robustas y las licencias de código cerrado: Robustas de código libre: CPL v.1.0 (Common Public License). Eclipse Public License. ecos License v.2.0 Sleepycat Software Product License. Affero License v.1.0 Affero License v.2.0 OpenSSL License GNU GPL (General Public License): esta licencia es la Licencia Pública General de GNU. La primera versión se desarrolló en 1989 por la Fundación de Software Libre (Free Software Foundation) del pionero en promover el software libre: Richard Stallman. Esta licencia se considera la primera licencia copyleft y se convirtió en un estándar de facto para este tipo de licencias. Esta licencia dice que cualquiera que redistribuya el software, con o sin cambios, tiene que dar la libertad de copiarlo y modificarlo a tal efecto no se puede emplear software GPL para integrar software privativo o no libre. Es por esto que el software que es acompañado por esta licencia se denomina software libre. Existen licencias hermanas de la GNU GPL aplicadas a obras musicales, bibliotecas, etc Permisivas de código libre: Academic Free License 63

68 Apache Software License Artistic License Attribution Assurance license. BSD License: La licencia BSD cubre las distribuciones de software de Berkeley Software Distribution, además de otros programas. Ésta es una licencia considerada 'permisiva', ya que impone pocas restricciones sobre la forma de uso, alteraciones y redistribución del software. El software puede ser vendido y no hay obligaciones de incluir el código fuente. Esta licencia garantiza el crédito a los autores del software pero no intenta garantizar que las modificaciones futuras permanezcan siendo software libre. MIT License. University of Illinois/NCSA Open Source License. W3C Software Notice and License. Zope Public License. Open LDAP License. Perl License. Academic Free License. Python License. PHP License. Q Public License. BSD. X De código cerrado: Estas licencias son las que se adjuntan al adquirir un software cerrado, es decir que no se obtiene acceso al código fuente del mismo. Este software se conoce con el nombre de software propietario o privativo. En ellas, los propietarios o autores establecen los derechos de uso, copia, distribución, modificación, cesión y en general cualquier otra consideración que se crea necesaria. Este tipo de licencias, por lo general, no permiten que el software sea modificado, desensamblado, copiado o distribuido de formas no especificadas en la propia licencia. No cumplir con esto implica la concreción de un delito conocido como piratería informática. Una licencia de este tipo regula el número de copias que pueden ser instaladas e incluso los fines concretos para los cuales puede ser utilizado el software. La mayoría de estas licencias limitan fuertemente la responsabilidad derivada de fallos en el programa y son en general muy restrictivas para el usuario. Un ejemplo claro de esto, son las licencias que poseen los sistemas antivirus, las cuales caducan en un determinado tiempo. Los fabricantes de programas sometidos a este tipo de licencias por lo general ofrecen servicios de soporte técnico y actualizaciones durante el tiempo de vida del producto. Ejemplos de este tipo de licencias son las llamadas CLUFs: Contrato de Licencia para Usuario Final o EULAs: End User License Agreement. 64

69 2.6.4 CREATIVE COMMONS Creative Commons es una ONG (organización no gubernamental) internacional sin fines de lucro que desarrolla una filosofía a favor del copyleft. Fue fundada en 2001 en Estados Unidos y en pocos años alcanzó renombre internacional gracias al proyecto International Commons. En español CC sería algo como Bienes Creativos Comunes, esta organización fomenta el uso de sus licencias públicas CCPL (Creative Commons Public License) para incentivar el desarrollo de los creativos, minimizando las barreras legales. A través de las licencias Creative Commons se pueden licenciar todo tipo de obras intelectuales. Entre otras posibles: fotos, libros, textos académicos, videos, animaciones, música, sitios Web, blogs. etc. Sólo existe un tipo de obra para la cual CC recomienda utilizar otra licencia. Este caso especial es el software. Para ello, CC recomienda utilizar la GNU GPL de la Fundación para el Software Libre que vimos anteriormente. Las licencias CCPL están en un intermedio entre una clásica licencia copyright y la ausencia de licencia ( dominio público ). La novedad en este tipo de licencias es que están a disposición del autor y del público en general, las potestades y requerimientos que se aplican a los licenciados. Es por esto que se sale del clásico todos los derechos reservados (que es característica de los productos con copyright) y se ingresa en el mundo de algunos derechos reservados. Estos derechos reservados son elegidos por el autor o propietario del objeto a licenciar. Tanto el autor como el usuario saben qué pueden y qué no pueden hacer con la obra. Es por esto que hablamos de las licencias CCPL, porque dependiendo del grado de fortaleza o de restricciones, el autor elige una u otra. Esta organización se encuentra en muchos países del mundo, y cada vez más las licencias se están traduciendo y aplicando en cada país, bajo las normativas vigentes en cada caso. En Argentina el otorgamiento de las licencias CC está a cargo de una ONG llamada Bienes Comunes. Bienes Comunes es una organización no/neo gubernamental (ONG) sin fines de lucro, fundada en el 2005 y ubicada en la Ciudad Autónoma de Buenos Aires. Está formada por personas interesadas en la investigación, regulación y protección de los bienes comunes de nuestras sociedades. En Argentina un creativo que desee licenciar su obra/producto, puede elegir entre seis tipos de licencia diferentes. En existe un asistente para guiar la elección de la licencia que más se adapte a las necesidades del autor. Antes de adquirir la licencia es recomendable que el autor registre su obra en la Dirección Nacional de Derechos de Autor para ampliar la protección contra usos indebidos (esto no es requisito para adquirir una licencia CCPL). Vemos a continuación las seis licencias disponibles en Argentina. Cada una tiene una imagen gráfica de cómo se verá adjunta a la publicación de la obra, haciendo así más fácil de entender lo que permite y lo que exige: 65

70 Logo Nombre Permite A condición de que Atribución 2.5 Argentina Atribución-No comercial 2.5 Argentina Atribución-No comercial-sin Obras Derivadas 2.5 Argentina Atribución-No comercial- Compartir Obras Derivadas Igual 2.5 Argentina Atribución-Sin Obras Derivadas 2.5 Argentina Atribución- Compartir Obras Derivadas Igual 2.5 Argentina Copiar, distribuir, exhibir y ejecutar la obra. Hacer obras derivadas de la obra original. Usar la obra comercialmente Copiar, distribuir, exhibir y ejecutar la obra. Hacer obras derivadas de la obra original. Copiar, distribuir, exhibir y ejecutar la obra. Copiar, distribuir, exhibir y ejecutar la obra. Hacer obras derivadas de la obra original. Copiar, distribuir, exhibir y ejecutar la obra. Usar la obra comercialmente. Copiar, distribuir, exhibir y ejecutar la obra. Hacer obras derivadas de la obra original. Usar la obra comercialmente. Se atribuya la autoría sobre la obra en la forma en que haya sido especificada por el autor o el licenciante de la obra. Se atribuya la autoría sobre la obra en la forma en que haya sido especificada por el autor o el licenciante de la obra. Ni la obra original ni sus obras derivadas se usen comercialmente. Se atribuya la autoría sobre la obra en la forma en que haya sido especificada por el autor o el licenciante de la obra. La obra no se use comercialmente. No se produzcan obras derivadas sobre la obra original. Se atribuya la autoría sobre la obra en la forma en que haya sido especificada por el autor o el licenciante de la obra. Ni la obra original ni sus obras derivadas se usen comercialmente. Las obras derivadas se compartan bajo la misma licencia de la obra original. Se atribuya la autoría sobre la obra en la forma en que haya sido especificada por el autor o el licenciante de la obra. No se produzcan obras derivadas sobre la obra original. Se atribuya la autoría sobre la obra en la forma en que haya sido especificada por el autor o el licenciante de la obra. Las obras derivadas se compartan bajo la misma licencia de la obra original. 66

71 Es muy importante que el autor conozca muy bien los tipos de licencia que tiene a su disposición porque una vez otorgada la licencia y publicada su obra bajo la misma, ésta es a perpetuidad, por lo que los derechos que no fueron reservados no pueden revocarse. Si bien puede retirar la licencia u obtener otra más privativa, esto no afectará a quienes obtuvieron una copia de la obra bajo la licencia inicial. Las licencias CCPL de Argentina son una muy buena opción la licenciar los contenidos de nuestro repositorio, por lo que hemos decidido incluirla dentro del software que vamos a desarrollar. 67

72 3 Análisis de herramientas 68

73 3.1 DISEÑO DE OA Y ROA La elaboración de un diseño de un entorno virtual de enseñanza y los objetos de aprendizaje que serán utilizados, no consta únicamente de la selección de los contenidos sino también aspectos pedagógicos, aumentando la importancia de los roles del docente, el alumno y el creador de contenidos. Se tiene que evitar pensar al diseño de objetos de aprendizaje como una simple copia lineal de un contenido cerrado. Un proceso de enseñanza y aprendizaje, toma a los OA como herramientas importantes, pero no únicas, y brinda al docente una participación y cercanía con sus alumnos, para que sirva de nexo entre los contenidos y la metodología de enseñanza. El docente no debe limitarse únicamente a subir contenidos ni tampoco el alumno a leerlos como si fuera un libro, inhibiendo su actividad mental constructivista. Los OA deben proveer al diseño, capacidades de interacción que promuevan el desarrollo de actividades que colaboren con el uso de las herramientas tecnológicas, aumentando la comunicación entre el docente y el alumno de manera sincrónica o asincrónica. Se pretende que un entorno virtual de capacitación sea mucho más que tener una página Web con contenidos, donde simplemente no se requiera asistir a clase. 3.2 HERRAMIENTAS DE CREACIÓN DE OA Lo primero que tenemos que tener en cuenta es quien va a realizar el proceso de creación de los OA y si los contenidos de los mismos ya están creados o no. Así podremos elegir una u otra herramienta. En inglés estas herramientas se conocen como authoring tools. Dependiendo de la experiencia de los diseñadores/creadores de contenidos en el manejo de la tecnología podemos clasificarlos en dos grandes categorías: profesionales y no profesionales. Los desarrolladores de contenidos profesionales crean el material usando programas como DreamWeaver, Photoshop, y otras herramientas profesionales. Los contenidos creados con estas herramientas pueden compilarse y empaquetarse sin problemas con el editor de metadatos profesional RELOAD, obteniendo así paquetes SCORM. El software profesional ADL Test Suite permite comprobar la integridad y corrección de los paquetes SCORM compilados con RELOAD. Luego estos paquetes pueden ser subidos a repositorios o LMS compatibles. Los no profesionales en la generación de contenidos, pueden iniciarse utilizando el paquete ofimático Microsoft Office (Word, Excel, PowerPoint, FrontPage, Visio) y luego con su complemento Learning Essentials para Microsoft Office generar el paquete de contenido SCORM. Con Learning Essentials se puede crear fácilmente contenido educativo Web en HTML usando drag and drop (arrastrar y soltar). Otra opción interesante resulta utilizar la herramienta MOS Solo para crear actividades o empaquetar los contenidos creados anteriormente con el Office. Con MOS Solo cualquiera puede crear nuevos contenidos, cuestionarios, presentaciones. El software SCORM Test Track (RUSTICI) valida los paquetes de contenido subiéndolos a un repositorio personal alojado en Internet. Luego los usuarios pueden subir y probar los paquetes de contenido en su LMS definitivo. 69

74 Describiremos en detalle las aplicaciones que hemos mencionado anteriormente y algunas otras que están siendo usadas actualmente RELOAD EDITOR Este software es un editor profesional de metadatos y paquetes de contenido (Content Packages) de varios estándares, uno de los cuales es SCORM1.2. También soporta IMS MD, IMS CP, SCORM2004 e IMS LD, por lo que lo hace uno de los productos más completos a la hora de completar la información de los OAs. Es un software orientado a profesionales del diseño y creación de contenidos de e-learning, ya que para su uso se requiere un amplio conocimiento de los estándares, y se necesita saber lo que se está haciendo ya que no es tan intuitivo como otras herramientas que veremos luego. Este software está diseñado para creadores de contenidos o especialistas técnicos, es por esto que puede resultar complejo para algún docente no habituado a la teoría de OAs. Como hemos visto en la sección 2.2., un paquete de contenido es un archivo que contiene o empaqueta recursos digitales con una organización establecida. Reload puede usarse para crear o editar dichos paquetes, que representan el envoltorio de nuestros OAs. Para lo cual se requiere que se le brinden los recursos (que en terminología SCORM son llamados assets) ya diseñados. Entonces lo que hace este software es organizarlos de tal manera que sean fácilmente navegables e interpretables por el LMS en donde se ejecutará. En el sentido práctico nuestros OAs son representados por un conjunto de recursos que conforman los contenidos, un conjunto de actividades de aprendizaje y una organización subyacente, que son envueltos y empaquetados por este programa conforme al estándar SCORM. Para introducir OAs dentro de un entorno LMS por ejemplo, necesitamos empaquetarlos para que éste los reconozca de alguna manera. Los paquetes de contenidos siguen un estándar mundial. Es por esto que es la mejor herramienta para compartir nuestros OAs con otros repositorios o entornos software. Reload permite agregar, quitar o modificar cualquier tipo de metadatos asociado a un OA, ya sea un metadato del propio contenido o un metadato asociado con la organización y el empaquetado del mismo. Además se encarga de la administración de la organización de los recursos, posibilitando un diseño de navegación eficiente. Se puede personalizar el idioma, como por ejemplo configurarlo en español, lo que facilita su utilización EXE-LEARNING Exe-learning es un creador y editor de contenidos educativos orientado a los docentes sin conocimientos técnicos sobre los detalles del modelo. Con este software el docente puede crear contenidos educativos con riqueza visual y contenidos dinámicos. Cuenta con siete temas y diseños de colores diferentes para crear cursos y exámenes más agradables para el alumno. El funcionamiento es muy intuitivo, el programa consta de dos partes bien diferenciadas: una barra de opciones y comandos y un editor de contenidos. 70

75 Crear una página con un cuestionario es tan simple como seleccionar el tipo de actividad, ejercicio, contenido, desde la lista de opciones de la parte izquierda y luego completar la información usando el editor de la parte derecha. El editor básicamente es un mini procesador de textos (similar al que encontraremos en un cliente de correo electrónico a la hora de redactar un ). Este procesador editar individualmente cada parte del curso, como puede ser una pregunta o una opción, o texto que el docente quiera presentar al alumno, acompañado de imágenes, animaciones o videos. Es destacable la presencia de numerosas ayudas breves en pantalla sobre los elementos que pueden ser modificados. Es un software intuitivo y con una facilidad de aprendizaje muy notable. Cada elemento que se seleccione de la lista de la izquierda se añadirá debajo del último elemento agregado en la página actual. Los contenidos son obtenidos en formato Web estándar es decir XHTML. Como punto sobresaliente destacamos la posibilidad de exportar los contenidos Web en numerosos formatos. Podemos exportar los cursos como páginas Web XHTML, archivo de texto, como paquetes de contenido en los principales formatos estándares mundiales como lo son IMSCP o SCORM1.2 o IMS CommonCartridge. Se puede personalizar el idioma, como por ejemplo configurarlo en español, lo que facilita su utilización. Para aquellos docentes que conocen el proceso de empaquetamiento y los estándares relacionados, pueden confundirse con el sistema de metadatos de Exe-learning, ya que permite metadatear en formato Dublín Core, pero algunos metadatos se pierden al realizar el empaquetado, detectando así una falla en la conversión MOS SOLO Este es un software que nos permite crear los recursos desde cero, o importarlos si ya fueron creados con otro software. Es un software orientado a personas no profesionales, brinda una interfaz visual muy intuitiva, amigable y contiene muchos ejemplos y ayuda. Se encuentra disponible en Básicamente un curso creado con MOS Solo cuenta con subunidades independientes. Estas subunidades pueden ser de tres tipos: un documento, una actividad, o una secuencia de ambos. A su vez cada subunidad tiene una determinada cantidad de páginas. Y dentro de esas páginas están los contenidos y los exámenes. Es así que construir un OA se asemeja bastante a unir piezas didácticas y reunirlas en una subunidad, y luego en una unidad. Esto deja evidenciado el concepto de agregación de contenidos predicado por SCORM. Más aun si se examina un OA en su interior se ve claramente cada subunidad como un archivo HTML independiente con metadatos asociados. Soporta metadatos en todos los elementos que conforman el paquete de contenido. Utiliza el estándar SCORM2004 para empaquetar los contenidos. Los metadatos de las subunidades subyacentes o del curso completo son almacenados en formato estándar LOM. 71

76 Figura 19 MOS Solo - Metadatos Es similar a Exe-learning en su filosofía y modo de uso. Su objetivo primario es conformar recursos en formato HTML, los cuales pueden contener: documentos, actividades o secuencias (de actividades y/o documentos). Realmente se puede crear contenido muy vistoso y de una manera fácil, con una interfaz simple, no demasiado cargada, con lo que es ideal para aquellos que quieren lograr con rapidez un curso auto evaluativo. Cuenta con un soporte básico de estilos, que dan el formato visual al curso. Podemos elegir el mejor estilo que creamos conveniente para nuestro curso o, editar un estilo existente y personalizarlo con nuestra institución educativa por ejemplo. Soporta todo tipo de contenido multimedia, es decir, no sólo se puede leer el contenido sino que también pueden agregarse imágenes, generar tablas, agregar sonidos, música, animaciones, videos, etc. Dentro de las actividades que podemos crear nos permite elegir: cuestionario, texto libre, preguntas con respuesta binaria o múltiple. Una característica importante es que permite pre visualizar en tiempo real en el navegador Web, el curso que se está diseñando, sin necesidad de descargar ninguna otra herramienta para este fin. O bien es posible exportarlo como página Web para luego ejecutarlo en modo offline (fuera de línea), sin necesidad de instalarlo dentro de algún LMS. Una característica importante de este software es que permite la exportación de sus contenidos parcialmente, es decir brinda la posibilidad de compartir cada subunidad. Esta reutilización ahorra esfuerzos de desarrollo y fomenta la creación de distintos templates o plantillas de ejercicios, exámenes y presentaciones de contenidos. Lo que permite reutilizar en otros proyectos u otros OAs. Hace uso de IMS QTI para describir las preguntas de los ejercicios. Cuenta con la posibilidad de configurarle un corrector ortográfico en español. 72

77 Esta herramienta no es open source, pero si es gratuita. Si bien en su instalación no cuenta con soporte al idioma Español, esto no es un problema ya que se puede descargar de la página oficial, otros idiomas como Alemán, Español, etc HOT POTATOES Esta suite de 6 aplicaciones es freeware pero no es open source. Se puede descargar gratis desde su sitio oficial Hay cinco aplicaciones que se centran en un tipo de contenidos o actividad, como por ejemplo, preguntas múltiple opción/respuesta breve (JQuiz), rellenar los blancos (JCloze), ordenar una oración (JMix), unir con flechas/coincidir (JMatch), hacer un crucigrama (JCross). El sexto programa (The Masher) permite unir éstas actividades ya creadas en un único proyecto, para crear un ejercicio combinado. Entonces queda el modo de uso bien establecido del programa: los ejercicios se crean primero por separado y después pueden unirse en un mismo tutorial o ejercicio combinado. Se encuentra traducido en varios idiomas. Trabaja con el estándar Dublín Core y permite ir visualizando la salida XML. Este programa puede generar varias salidas o exportaciones del trabajo: una página HTML en formato V6, o en formato para versiones menores a la 6 en los navegadores un zip con el HTML obtenido un paquete SCORM copia en el portapapeles para imprimirlo Hay que destacar que cuando se exporta a SCORM, los metadatos que se ingresaron en formato DC no se reflejan dentro del empaquetado, en ningún archivo XML. Aunque sí están almacenados dentro de la cabecera del archivo HTML generado y empaquetado COURSELAB Es una herramienta de creación de contenidos, tutoriales, presentaciones y cursos en línea gratuita. Pero tiene funcionalidades que únicamente están disponibles con la compra de packs adicionales, como por ejemplo la captura de pantalla, la importación de archivos de PowerPoint y plantillas de creación. Este software está diseñado para crear contenido educativo en forma de diapositivas (slides) y el producto resultante es muy parecido a una presentación de Microsoft PowerPoint. Tal es así que se puede importar una presentación en dicho formato y luego editarla. CourseLab es compatible con varios LMS entre los cuales están Atutor, Moodle, Blackboard, Ilias y muchos más; es freeware, de código cerrado, y además tiene agregados que no son gratuitos. En cuanto a la modalidad de trabajo, se van creando diapositivas en las cuales podemos agregar gran variedad de objetos, tanto internos (animaciones, globos de diálogos, java applet, videos, cuestionarios, elementos de formularios HTML, etc.) 73

78 como externos que son una referencia a algún elemento que se encuentra en nuestra máquina o en Internet (URL). Los elementos llamados externos son mostrados a la hora de ejecutar el curso - en el navegador y en caso de que no se pudiera se procede a la descarga de los mismos. El empaquetamiento de contenidos se logra mediante la función publicar curso. Esta función nos permite elegir si el contenido lo queremos en formato de run CD (IMSCP), SCORM 1.2, SCORM 2004 y AICC. El resultado es una página HTML que respeta el estándar de empaquetado elegido. Este HTML puede ser pre visualizado antes de ser empaquetado o exportado a un CD. En su sitio Web oficial se pueden ver ejemplos de OAs (cursos) diseñados utilizando las características de este software. Algo importante que notamos en este software es que no soporta otros idiomas que no sea el inglés. Pero algo aun más importante es la no posibilidad de completar los metadatos de los recursos o del curso entero. Por esto concluimos que es un software diseñado para la creación ad-hoc de evaluaciones y materiales educativos, que no está preparado para que esos contenidos sean compartidos y reutilizados en otros contextos. Debido a la falta de descripciones de sus contenidos carece de sentido almacenarlos en un repositorio. Su uso es más bien directo y el destino final es almacenarlo dentro de un LMS para su uso MICROSOFT LEARNING ESSENTIALS Este software es un producto orientado tanto a estudiantes como a profesores. Viene en un CD junto al Microsoft Office o bien puede descargarse en el sitio de Microsoft o del sitio del desarrollador THESIS. Nos centraremos en el uso que el profesor puede darle a este software. Se requiere que el profesor tenga instalado el Microsoft Office, ya que desde esas aplicaciones, él creará los contenidos. La clave de este producto de Microsoft es la utilización del software THESIS SCORM en su versión Lite. Es posible comprar o migrar a la versión Profesional. Si bien es un software pago, pueden descargarse gratuitamente versiones de prueba por tiempo limitado. Una vez que instalamos el software en cada aplicación ofimática (Word, Excel, PowerPoint, Visio, Publisher) se encuentra disponible una nueva barra de herramientas, en la sección Complementos. Desde allí se pueden guardar los documentos en formato de objetos de aprendizaje. Esto implica convertir al documento en uno o más archivos HTML. Hay varias funciones que brinda la barra de herramientas. Figura 20 Microsoft Learning Essentials 74

79 Hay opciones para importar un OA en THESIS SCORM, hay opciones para los estudiantes y para los profesores (educadores). Los educadores pueden contar con herramientas en matemáticas y ciencias, como una tabla periódica, calculadora, editor de ecuaciones, etc. Además pueden agregar al documento preguntas y actividades de: verdadero o falso múltiple choice asociación respuesta breve rellenar espacios en blanco. Se permite agregar metadatos, pero no se pueden completar la totalidad de los campos definidos en IMS MD1.2.1 (que es formato interno que utiliza). Fuera de esto los OAs generados utilizando el producto THESIS SCORM son compatibles con el estándar SCORM1.2 o SCORM HERRAMIENTAS DE CREACIÓN DE ROA Luego de analizar los creadores de contenidos educativos veremos los encargados de almacenar y administrar dichos contenidos. Para ello hemos analizado gran variedad y cantidad de aplicaciones Web. Únicamente mencionaremos aquellas que cumplen con licencias OpenSource (código fuente libre y gratuito) dejando de lado productos comerciales cerrados DOOR DOOR permite crear un repositorio local de OA abierto (de sus siglas en inglés Digital Open Objects Repository). Esta desarrollado en el lenguaje php y trabaja con una base de datos MySQL. Este software cuenta con un plugin que permite vincular los OA subidos a Door a un curso dentro de la plataforma LMS Moodle. El creador de cursos que utiliza la plataforma e-learning Moodle 2.0, al momento de diseñarlos, tiene la opción de buscar OAs directamente en un repositorio Door pre configurado. Luego estos OAs en formato SCORM son anexados como una actividad más del curso. Se puede descargar la versión desde la página oficial de Door en Los idiomas disponibles de la aplicación son: italiano, inglés, francés y español. Sin embargo la ayuda únicamente se encuentra en inglés. El manual del usuario de la versión 1.0 se puede encontrar en formato PDF visitando aunque sería de gran utilidad contar con el manual actualizado. Se encuentra disponible una demo del ROA en y entrando como usuario editor (contraseña: dooreditor) o guest (contraseña: doorguest) se puede probar el repositorio sin tener que instalarlo en tu equipo. Un ejemplo concreto de este repositorio es MOREA (Múltiples Objetos Reutilizables para la Enseñanza y el Aprendizaje) 75

80 DOOR es ideal para proyectos pequeños que no requieren de excesiva funcionalidad. Y posee una presentación muy simple. El ingreso de un objeto al repositorio es bastante rápido, ya que no se ingresan más de 13 metadatos. Se puede elegir subir o no un archivo adjunto, o una URL. El adjunto no debe superar el tamaño de 20Mb. Es un repositorio simple que permite trabajar con estándares de metadatos IMS LRM e IMSCP Sin embargo en la práctica, no se ha logrado interoperabilidad entre paquetes de contenido Door y otras herramientas o repositorios. Para más información ver la sección 5.2 del Anexo ARIADNE 2006 Fundación ARIADNE (Alliance for Remote Instructional Authoring and Distribution Networks for Europe) es una asociación europea abierta y el núcleo de su infraestructura es una red distribuida de repositorios de objetos de aprendizaje. Ariadne distribuye entre otras herramientas el software que permite la creación de un repositorio federado de OAs, el cual utiliza estándares de metadatos LOM y Dublín Core. Para la creación del repositorio local se cuenta con dos aplicaciones Web (*.war) que se copian en el directorio /webapps del servidor Web Tomcat. La primera aplicación denominada AWS (Ariadne Web Services) permite configurar la Base de Datos, los usuarios del repositorio, el directorio donde se van a alojar los OA en el sistema de archivos y además permite hacer comprobaciones de configuración entre otras cosas. La segunda aplicación llamada SILO (Search & Index Learning Objects) permite la búsqueda de contenidos en el repositorio local AWS y búsquedas federadas empleando un lenguaje de consulta denominado SQI (Simple Query Interface). El repositorio de objetos de aprendizaje fue desarrollado usando los siguientes requerimientos: Base de Datos (Oracle o Postgresql 8.1, no funciona con Postgres 8.3) Apache Tomcat 5.0.x Java 2 SE JVM 1.4.x (Hay que hacer algunos cambios en el código fuente para compilarlo con Java 2 SE 1.5 o superior) ARIADNE 2009 Ariadne ha evolucionado desde su versión en 2006 y en la actualidad su infraestructura central tiene varios componentes: el repositorio (Learning Object Repository) ofrece una gestión de OA y metadatos. el motor de búsqueda federada permite la búsqueda transparente dentro de una red de repositorios heterogéneos. el buscador (Finder) es un cliente Web para la búsqueda y publicación de OAs el recolector (Harvester) reúne los metadatos de los OA que se encuentran en repositorios externos. 76

81 el servicio de validación de metadatos valida metadatos contra los estándares mundiales de metadatos Learning Object Repository El repositorio Ariadne almacena tanto metadatos como el material educativo, los cuales conforman los OAs. Este repositorio es diferente a los que ya hemos analizado, en el sentido que permite guardar metadatos o recursos educativos independientemente. Para la búsqueda el repositorio ofrece una interfaz de búsqueda basada en la especificación Simple Query Interface (SQI). Para la publicación se utiliza una interfaz de basada en la especificación Simple Publishing Interface (SPI), y para la recuperación se hace uso de una interfaz basada en OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting). SQI le permite interactuar con diferentes lenguajes de consulta (por ejemplo, el lenguaje de consulta PROLEARN [PLQL], el contextual Query Language [CQL], o la consulta de intercambio de idiomas [Qel]) y los estándares de metadatos (como LOM, Dublín Core [DC]). Además SPI permite la interoperabilidad para recolectar OA e instancias de metadatos y OAI-PMH permite la recolección de metadatos de otros repositorios externos. Debido a que SQI, SPI, y OAI-PMH son parte de la estructura del paradigma de almacenamiento de metadatos, el componente del repositorio permite integraciones con aplicaciones externas (que adhieren a dichos estándares). El repositorio de ARIADNE es una aplicación Web que corre bajo un contenedor de servlets como Tomcat que guarda la información (metadatos y descripción de archivos físicos) en una base de datos XML Actualmente soporta dos bases de datos gratuitas: la base de datos opensource Exist ( y la base de datos DB2, adicionalmente se está incluyendo el soporte para Oracle. Se requiere para la correcta ejecución del repositorio: Java5, Tomcat 5.5 hasta , base de datos XML exist o DB2. Pasos para instalar el repositorio: descargar el repositorio y copiar el archivo repository.war al directorio /webapps del Tomcat configurar los parámetros del repositorio en el archivo de configuración que se encuentra en el subdirectorio /webapps/repository/install/ariadne.properties. Aquí se harán los cambios dependiendo del gestor de base de datos que se esté usando Motor de búsqueda federada y el Registro El motor de búsqueda federada se basa en SQI y ofrece una búsqueda transparente en una red de repositorios. Este motor realiza consultas en los repositorios con SQI habilitado y genera automáticamente el registro del repositorio en el servicio de registro (Registry). Ariadne Registry es independiente en la arquitectura del repositorio, el cual permite modificar los datos del repositorio registrado. El componente se encuentra en El motor de búsqueda 77

82 permite a otras federaciones recuperar metadatos de repositorios que están disponibles en la Federación de Ariadne. permite el intercambio con otros componentes (finder, harvester, etc.), permitiendo así a otros repositorios reutilizar el motor de búsqueda federada Ariadne. Además provee una estricta separación entre la búsqueda y la gestión de repositorios diferentes en una federación. permite realizar una consulta inteligente. Por ejemplo, los sistemas no enviarán una consulta que contiene palabras clave de un diccionario de sinónimos médico a un repositorio que contiene sólo material de informática Finder Esta herramienta permite a sus usuarios compartir y reutilizar OA, es decir subir, buscar o bajar OAs. Cuando se comparte un nuevo objeto de aprendizaje, la herramienta guarda el objeto y los metadatos en el repositorio (Learning Object Repository). Se permite o requiere, según el caso, el uso de OpenID para operar con el repositorio. OpenID es un estándar de identificación digital descentralizado, con el que un usuario puede identificarse en una página Web a través de una URL y puede ser verificado por cualquier servidor que soporte el protocolo. Además de publicar objetos de aprendizaje y metadatos, brinda una interfaz de búsqueda donde permite a los usuarios encontrar objetos de aprendizaje en el repositorio local de Ariadne y navegar a través de resultados utilizando categorías. El buscador oculta los protocolos y estándares al usuario y soporta búsqueda en otros repositorios a través de su conexión con el motor de búsquedas federadas DSPACE DSpace es una plataforma de software, la cual está diseñada para ser ejecutada en entornos Web. Su misión es la de la elaboración, el registro y almacenamiento de todo tipo de contenidos digitales. Puede usarse esta plataforma como base para la creación de repositorios institucionales en organizaciones de distinta índole. Nació en 2002 gracias a los esfuerzos de desarrolladores del MIT (Massachussets Institute of Technology) conjuntamente con pares de Hewlett Packard Laboratories. Es un proyecto que no para de crecer. Se han creado grupos de desarrollo que han colaborado con la Comunidad DSpace y esto ha llevado a la necesidad de crear una organización de apoyo a todos los usuarios e investigadores de DSpace. Es así que en el 2007 nace la Fundación DSpace. DSpace permite el registro de múltiples tipos de contenidos como tesis, libros, papers, imágenes, videos, audios, etc. A cada objeto digital almacenado se lo denomina ítem, y cada ítem está almacenado en al menos una Colección, la cual está contenida dentro de alguna Comunidad. Cada ítem cuenta con información acerca de si mismo, esta información o metadatos siguen un estándar ampliamente utilizado. Se trata del estándar de metadatos Dublín Core Calificado. Este estándar cuenta con 15 campos genéricos y una calificación para cada uno de los 15 campos, de ahí su nombre. Este esquema de metadatos es idóneo para catalogar por ejemplo libros (los cuales no requieren de extensa especificación de metadatos). Este desarrollado en java y cuenta 78

83 con dos interfaces gráficas: una jsp y la otra denominada Manakin, basada en Apache Cocoon utilizando tecnología XML. Esta última interfaz es más agradable visualmente. Soporta base de datos Postgresql u Oracle. Cuenta con una interfaz ampliamente personalizable, ya que cuenta con abundante documentación de calidad. Es de amplio uso mundial gracias a su diseño de propósito general. Este software puede considerarse una herramienta para crear repositorios de objetos digitales PLANETDR Es un proyecto ambicioso que desarrolló una avanzada arquitectura federada que interconecta repositorios de contenido educativo. Este proyecto forma parte de una serie de proyectos dentro de la fundación Planet, de ahí su nombre PlanetDigitalRepository. Este proyecto desarrolló una aplicación Web distribuida denominada PlanetDR, con la que se puede crear un repositorio o nodo local, contenido en un repositorio distribuido basado en los estándares IEEE LOM, IMSCP y DRI. En el sito oficial se pueden descargar versiones para Windows y Linux del instalador. Es un proyecto OpenSource, pero el código fuente no está publicado, hay que solicitarlo puntualmente. No cuenta con mucha documentación técnica y requiere versiones específicas de la JVM y Mysql. Es por esto que no es muy difundido ni usado, aunque tiene algunas características interesantes que por lo general sus competidores no poseen, como la búsqueda de contenidos en otros servidores (búsqueda federada), la posibilidad de subir varios OA a la vez, además obtiene los metadatos del OA que se desea importar. Este software no crea los contenidos, únicamente los almacena para su búsqueda y reutilización. Es por esto que necesita que se le suministren los archivos en formato *.zip cumpliendo con el estándar SCORM. En la actualidad este proyecto se encuentra discontinuado, ya que la última actualización figura en junio de

84 4 Desarrollo 80

85 4.1 ANÁLISIS DE VIABILIDAD En este capítulo empezaremos a recorrer el camino necesario para la elaboración del software. Antes de encarar la programación, etapa indispensable, necesitamos planificar, evaluar las diferentes alternativas, para alcanzar nuestros objetivos con la mejor utilización de los recursos con los que contamos. El tiempo pasa a ser nuestro recurso crítico, ya que tenemos un tiempo acotado para entregar y presentar nuestro trabajo. Tenemos que tener en cuenta las herramientas y conocimientos previos que tenemos como estudiantes y que posibilidades de éxito tenemos al encarar este proyecto de tesina. Todos los conocimientos teóricos que hemos presentado previamente fueron necesarios investigarlos y aprehenderlos para que nuestro conocimiento en el área se viera fortalecido para dar impulso firme a nuestros objetivos, quitando dudas, ambigüedades con el anhelo de que toda nuestra energía sea bien aprovechada a lo largo del proyecto. La primera etapa de investigación y acotamiento del problema a resolver fue larga, debido a nuestros pocos conocimientos en el área educativa digital en general y también debido a que es una tecnología y área que está en pleno desarrollo y nosotros nos vamos a ir desarrollando junto a ella, tratando de hacer un aporte significativo con nuestro trabajo. Así damos por iniciada esta etapa de anteproyecto, poniendo énfasis en el carácter y el modo de desarrollo, implementando técnicas y conocimientos de ingeniería de software en el proceso de desarrollo. Hicimos una lista de requerimientos, de cómo debería ser nuestro repositorio de objetos de aprendizaje, que cosas son las deseadas, qué cosas son las no deseadas, tratando de cumplir con estándares internacionales, para fortalecer la interoperabilidad, el reuso y fomentar la utilización de esta tecnología en nuestro ámbito educativo. A nuestro entender nuestro repositorio tendría las siguientes cualidades o características: Realizado en un lenguaje de programación conocido y maduro. Debidamente documentado a nivel de desarrollador y usuario. De código abierto y gratuito. De amplio uso mundial de su plataforma. Utilización de estándares mundiales para el metadateo de los OA (IEEE LOM). Posibilidad de compartir información con otros repositorios (OAI-PMH). Posibilidad de importar y exportar objetos desde y hacia otros repositorios utilizando estándares mundiales (SCORM). Persistencia en los identificadores de cada OA. Navegabilidad de los contenidos por área temática o catalogación. Búsqueda simple y avanzada. Multiplataforma. No distribuido, almacena metadatos y archivos localmente. 81

86 Facilidad de uso y administración, entorno Web. Publicación/Suscripción/Sindicación de contenidos nuevos dinámicamente (RSS). De fácil uso para los depositadores y para los extractores de información. En un momento dado pensamos en la posibilidad de construir desde cero nuestro repositorio, pero luego de hacer estimaciones temporales y la curva de aprendizaje necesaria para aprender el manejo de las herramientas, en pos de darle al software la calidad necesaria, decidimos que no era una solución viable empezar un proyecto desde cero, lo cual implica un esfuerzo de diseño y programación que no estábamos dispuestos a pagar, pensando en el poco tiempo que disponíamos dos personas. Al conocer la filosofía del software libre y de código abierto, nos adherimos fuertemente a la idea colaborativa de aportar a algún proyecto existente, el cual nos sirva de punto de partida hacia nuestro repositorio. Esto fue motivado por la gran cantidad de software de repositorios disponible. Descartando la posibilidad de enfrentar la construcción de un ROA desde cero, nos abocamos a la tarea de buscar el prototipo de repositorio que más nos conviniera para nuestros objetivos. Investigamos muchas herramientas de creación de repositorios de código abierto, por ejemplo DOOR, PlanetDR, E-Prints, DSpace, Ariadne ANÁLISIS DE LAS ALTERNATIVAS En esta sección describiremos el análisis de las distintas alternativas de software de creación de repositorios. Nos centraremos principalmente en la documentación, las funcionalidades ofrecidas y el diseño de cada repositorio. DOOR: El primer software analizado fue DOOR, el cual es extremadamente simple e intuitivo, y cuenta con una interfaz de usuario clara y puede se personalizada al español. En un primer momento quedamos contentos con él, pero esto pronto cambiaría. Tiene las opciones básicas de un repositorio, las cuales son, almacenar, explorar, buscar y compartir el contenido digital educativo. Pero no es lo suficientemente robusto en diseño y performance para ser un repositorio institucional. Soporta únicamente IMSMD e IMSCP 1.1. La interoperabilidad no es un punto fuerte, ya que no acepta la mayoría de los paquetes educativos, tanto IMS como SCORM. Así como también, los paquetes que se descargan, son de una versión específica de IMS que se ha quedado obsoleta. Es decir no se puede trabajar con otro software para la edición de los paquetes a subir o bajar de este repositorio. RELOAD, el editor por excelencia no acepta como validos los paquetes IMS que son descargados de DOOR. Para más información ver anexo. Su diseño pequeño y simple no ha sabido explotar completamente todos los metadatos que brinda el estándar IMSMD, que con alrededor de 50 campos, sólo se utilizan 13 al momento de crear un objeto digital. Es un proyecto que ha sido discontinuado y los comentarios de su sitio Web han quedado un poco desactualizados. DOOR nació en el 2006 con su versión 1.0 y ha ido 82

87 sacando nuevas versiones hasta 2008 que sacó la 1.8, hoy luego de más de dos años no hay noticias del proyecto. Su diseño es correcto, aunque por desconocimiento en el lenguaje php no podemos asegurar un buen manejo de la concurrencia, ni tampoco la posibilidad de corrección en tiempo de sus debilidades como sistema. Nuestros deseos de obtener un repositorio con fuerte aceptación internacional se debilitaban con esta elección, lo que nos hizo seguir investigando, ya que la interoperabilidad se veía comprometida con el uso de este software. Además no es una opción de repositorio formal con soporte de usuario y mantenimiento. PLANET-DR Y DSPACE: Nuevamente en el camino se nos presentaron dos alternativas, mejor dicho dos plataformas de repositorio bien diferentes: PlanetDR y DSpace. Estas dos son diferentes en varios aspectos, por ejemplo PlanetDR es de fácil instalación y DSpace requiere conocimientos de administrador para instalar el repositorio, ya que es más largo y manual el proceso. Luego de instalar PlanetDR hicimos pruebas satisfactorias, pero tuvimos problemas para conseguir el código fuente y poder hacer funcionar la versión compilada por nosotros mismos. Es por esto que nuestra experiencia no ha sido muy extensa ni satisfactoria con la herramienta PlanetDR ya que no pudimos dejar el repositorio en completo funcionamiento. Como primera medida instalamos PlanetDR versión en Windows pero la parte de búsquedas federadas no estaba disponible. Después de luchar varias semanas con fallos inesperados decidimos seguir investigando con más entusiasmo la plataforma DSpace. No fue difícil hallar documentación y nos fue gratamente sorprendente encontrar la respuesta a cada interrogante que se nos presentaba durante el descubrimiento de DSpace. Pudimos evaluarlo con un LiveCD, luego instalarlo con el código fuente y rápidamente entrar a analizar su estructura. Comprobamos que era el repositorio que cumplía con los requerimientos de documentación y de apoyo de la comunidad de desarrolladores y usuarios. Muchos de los requisitos funcionales eran cumplidos por DSpace entonces elaboramos una lista de cosas por hacer y decidimos que este software era el candidato elegido para desarrollar nuestro propio ROA. Además está posicionado como líder por la cantidad de instalaciones en todo el mundo. Esto se refleja en datos del ROAR (Registro de Repositorios de Acceso Abierto) y OpenDOAR (Directorio de Repositorios de Acceso Abierto). 83

88 Figura 21 DSpace presenta 614 instalaciones en el mundo fuente: Con 614 instalaciones nos brinda una clara evidencia de su robustez, su facilidad de uso, su bajo costo, su fácil implementación, su facilidad de mantenimiento y su popularidad actual. E-Prints es otro software ampliamente usado pero lo descartamos ya que se encuentra escrito en PERL y en funcionalidades es similar a DSpace. Y por último el tercer competidor directo de DSpace es FEDORA (Flexible Extensible Digital Object Repository Architecture, es decir Arquitectura digital de repositorio de objetos digitales flexible y extensible), escrito en java, pero sin una interfaz Web de administración, lo que no favorece su elección. Nos pareció demasiado complicado y tedioso lidiar con software de terceros para gestionar gráficamente el núcleo FEDORA COMPARATIVA Análisis de la documentación DOOR (versión 1.8): PLANETDR: DSPACE: Documentación muy breve sobre instalación en idioma inglés únicamente. No posee documentación del sistema, un único manual de usuario que corresponde a la versión 1.0 del 2006 y que está en inglés. Pobre documentación técnica. Documentación online abundante en varios idiomas, con manual de usuario en inglés, y código fuente claro y documentado, guías paso a paso, etc Análisis de las características y funcionalidades DOOR: No permite subir archivos de más de 20Mb. No utiliza todo el estándar de metadatos IMSMD, únicamente usa 13 campos. Soporta OAI 2.0 (oai2/ es el módulo que hace de Proveedor de Datos - OAIDataProvider). Multiplataforma: Linux Windows. BD: MySQL. 84

89 DSPACE: PLANETDR: Lenguaje: Php Soporte multilenguaje. Permite descargar los objetos, metadatos + recursos. Permite subir recursos de cualquier tipo y tamaño. (Utiliza el sistema de archivos para su almacenamiento). Gran comunidad de desarrolladores y soporte técnico experto. Manejo de objetos dentro de Colecciones o Jerarquías de Colecciones, un objeto puede pertenecer a más de una colección. Indización de metadatos y texto completo, documentos MS Word y PDF (MediaFilters). Soporta Dublin Core, pero puede importar y exportar en otros formatos. Amplio control de autorizaciones, flexibilidad, seguridad. Búsqueda local. No permite búsquedas federadas o remotas. Libertad en el manejo de los grupos de usuario. Sistema de plugins para la importación y exportación de objetos: ejemplo METS. Los objetos pueden ocultarse/desactivarse (withdrawn). Soporte multilenguaje. Identificadores persistentes a los objetos, colecciones y comunidades (CNRI Handle System - Multiplataforma: Linux, Solaris, Windows, MAC OS. Lenguaje java jsp. Permite descargar los objetos, metadatos + recursos. Permite subir archivos por lotes (solo por línea de comandos). Sistema de estadísticas muy básico. Permite completar campos con valores por defecto en el proceso de envío/creación de un objeto. Usuarios notificados por o RSS de novedades. Soporte para licencias individuales por colección. Soporte para licencias Creative Commons. Sólo soporta dos niveles de usuario: administrador y usuario registrado. Lenguaje java jsp. Búsqueda simple, avanzada y remota. En el código fuente esta última ya no estaba disponible. Sólo permite subir objetos empaquetados. Permite descargar los objetos, metadatos + recursos. Permite la subida masiva de archivos empaquetados, indicando el directorio donde se encuentran todos los *.zip. 85

90 Análisis del diseño DOOR: PLANETDR: DSPACE: Está diseñado íntegramente en php. Buena idea la de la implementación de un plugin para Moodle. Fácil instalación. Tiene un diseño modular muy claro y práctico. Sistema de plugins para la importación (ingest) o exportación (disseminate) de objetos y/o sus metadatos. Soporta el protocolo OAI-PMH. No es monolítico, se apoya en otras tecnologías, Framework, Apis (Apache Maven, Apache Ant). Cuenta con una interfaz METS SWORD. Diseño para soportar dos SGBD: PostgreSQL y Oracle. Posibilidad de ampliar/reducir o crear nuevos esquemas de metadatos para los objetos almacenados. Por defecto usa Dublin Core Calificado. Posee interfaces gráficas que permiten ser personalizadas, ejemplo formularios de envío. Instalación no trivial, muchos componentes adicionales necesarios DECISIÓN Luego de hacer numerosas pruebas y análisis concluimos que DSpace es un software idóneo para crear nuestro primer repositorio, sin tener un diseño complejo, ni ser un software extremadamente ambicioso, es ideal para personalizar y adaptar a nuestros requerimientos. Recordando el uso general del sistema DSpace y pensando en organizaciones como por ejemplo bibliotecas o de índole no informática, remarcamos que DSpace cuenta con una instalación no trivial y que requiere de personal especializado en la administración y programación de sistemas. 4.2 ANÁLISIS Y DISEÑO DE LA SOLUCIÓN En esta sección analizaremos por dentro al software seleccionado, DSpace versión 1.5.2, identificaremos los componentes, las funcionalidades y las implementaciones de las características mencionadas anteriormente. Luego detallaremos cómo diseñamos los cambios que fueron necesarios realizar para cumplir con el repositorio deseado. Vamos a ir viendo al sistema desde afuera hacia adentro, desde lo más general a lo más particular para comprender mejor su estructura, lo que se conoce como metodología Top-Down. Por el momento sólo basta saber que DSpace es un software de aplicación en entorno Web, siguiendo una arquitectura cliente/servidor. 86

91 4.2.1 INSTALACIÓN DE DSPACE El primer paso para observar y evaluar un software es ponerlo en funcionamiento. Para ello es necesario instalarlo. El proceso de instalación se divide en tres partes: compilación, instalación/deployment y configuración. Esto es algo muy habitual en el software de código abierto si no tenemos los binarios y contamos con el código fuente. A continuación mencionamos los requerimientos de software de DSpace: Sun JAVA JDK 1.5 o posterior (J2SE). Apache Ant o posterior. Apache Maven o posterior. Apache Jakarta Tomcat 4 o superior (webapps container). PostgreSQL 7.3 u Oracle 9 (o versiones posteriores). Podemos elegir el sistema operativo que deseemos, ya que DSpace puede ser instalado bajo Windows, Unix, Linux, Solaris, Mac OS. Cada instalación tiene sus detalles dependientes del sistema operativo, por lo tanto mostraremos los pasos comunes de toda instalación DSpace. Esto no pretende ser una guía, por lo tanto no mostraremos líneas de comando o consola, únicamente es una guía rápida para conocer el sistema Fase de compilación Llamaremos [dspace-src] al directorio o carpeta donde se encuentre el código fuente de DSpace, simplemente [dspace] al directorio o carpeta donde deseemos instalar el sistema. Creamos la base de datos (BD) con el gestor que elijamos. La BD se llama dspace y el propietario de la misma se llama dspace. El proceso cambia según el motor de BD. Modificamos el archivo [dspace-src]/dspace/config/dspace.cfg para configurar las siguientes propiedades necesarias: Propiedades dspace.dir dspace.url dspace.hostname dspace.name db.password Mail.server Mail.from.address feedback.recipient Mail.admin Descripción donde quedara instalado el software ruta completa del repositorio en nuestro servidor nombre completo de nuestro servidor el nombre de nuestro repositorio el password del usuario dspace de la Base de Datos nombre completo del server SMTP dirección de correo electrónico, que será el remitente de las notificaciones a los usuarios de los eventos del sistema dirección de correo electrónico para la recepción de comentarios de los usuarios dirección de correo electrónico del administrador de DSpace 87

92 alert.recipient registration.notify dirección de correo electrónico para la recepción de alertas y errores internos del servidor dirección de correo electrónico para la recepción de las notificaciones de registro de usuarios Ahora creamos la carpeta o directorio de instalación [dspace]. Luego iniciamos la compilación usando la herramienta Apache Maven. Un detalle importante es que necesitamos tener una conexión a Internet si es la primera vez que instalamos el sistema. Ya que Maven descargara de sus repositorios los paquetes que necesite (Ver anexos para una descripción más detallada). [dspace-src]/dspace/mvn package Figura 22 Repositorio Maven fuente: Ref. [47] Luego de ejecutar este comando veremos en la pantalla cómo se irán compilando todos los módulos que conforman de DSpace. Y en la carpeta [dspace-src]/dspace/target/dspace-version.dir/ tendremos el código ya compilado Fase de instalación/deployment En esta fase llevaremos el código compilado previamente a las ubicaciones correspondientes, para dejar instalado el sistema. Para dicha tarea, usaremos la herramienta Apache Ant. (Ver anexos para una descripción más detallada). Ant hará el trabajo por nosotros, copiará los archivos necesarios a la carpeta de instalación que hayamos definido en [dspace] e inicializará la base de datos para el primer uso del sistema. Ejecutamos: [dspace-src]/dspace/target/dspace-version.dir/ant fresh_install 88

93 Fase de configuración En esta última fase tenemos que preparar nuestro servidor Web, crear una cuenta de administrador para el sistema y realizar los últimos ajustes para dejar en funcionamiento el sistema. Para la primera tarea tenemos dos opciones: Enlazar al contenedor de aplicaciones con la carpeta [dspace]/webapps/ o Copiar dicha carpeta en la carpeta correspondiente donde está instalado el contenedor de aplicaciones Web. La carpeta [dspace]/webapps contiene varias subcarpetas que más adelante veremos en detalle. Luego creamos mediante un comando interno de DSpace al administrador del sistema, para ello ejecutamos: [dspace]/bin/create-administrator Pedirá datos como el nombre, el correo electrónico y la clave de acceso que elijamos. Aunque no es necesario, recomendamos configurar nuestro servidor Web, de tal forma que las conexiones a nuestro repositorio se hagan usando el protocolo HTTP en modo seguro (HTTPS), es decir HTTP sobre SSL. También si lo deseamos podemos instalar packs de idiomas adicionales. Por último debemos utilizar las funciones automáticas que brinda nuestro sistema operativo, como por ejemplo cron en el caso de Unix/Linux, para configurar la ejecución periódica de ciertos scripts: Scripts [dspace]/bin/sub-daily [dspace]/bin/filter-media [dspace]/bin/checker [dspace]/bin/dsrun org.dspace.checker.dailyreposrt er [dspace]/bin/stat-general [dspace]/bin/stat-monthly [dspace]/bin/stat-report-general [dspace]/bin/stat-report-monthly Descripción Envía mail diariamente a los usuarios que se hayan suscripto a las novedades de determinadas Colecciones de objetos Realiza indexaciones a texto completo y vistas en miniatura de los contenidos de los objetos Realiza verificaciones sobre los archivos almacenados en el repositorio comprobando alteraciones Envía al administrador si hubo alteraciones de los archivos Realiza la generación de estadísticas generales Realiza la generación de estadísticas mensuales Realiza los reportes de estadísticas generales Realiza los reportes de estadísticas mensuales Hemos terminado la instalación, reiniciamos el servidor Web y luego invocamos la URL de nuestro repositorio para realizar una prueba local que sería algo como: o Deberíamos ver la página inicial del repositorio. 89

94 4.2.2 ARQUITECTURA Maven El software DSpace es de un tamaño importante y está organizado en diferentes módulos de software, los cuales tienen una función determinada dentro del sistema. Los módulos, no solamente quedan evidenciados al examinar la estructura de directorios y archivos del código fuente, sino también por la utilización de la herramienta Apache Maven y la información que ella nos brinda en la compilación del código fuente. Apache Maven se utiliza para organizar las dependencias intra e inter módulos. Construye su propio repositorio bajando paquetes jar de Internet. Este conjunto de archivos jar, contiene exactamente los archivos que necesita DSpace para ser compilado. Esta información está contenido en cada archivo pom.xml que se encuentra en el raíz de cada módulo. Analicemos el código fuente y veamos la estructura de directorios del proyecto. Es claramente un proyecto de proyectos o como se conoce en el mundo Maven un proyecto multi-módulo o proyecto que permite agregados. Figura 23 pom.xml a nivel raíz Cada archivo pom.xml define un proyecto, el cual puede ser visto como un módulo independiente o bien parte de otro proyecto. Ver figura 23 Existen dos tipos de relación entre los proyectos POM. Una es la herencia, en donde un proyecto hereda de otro, y la otra relación es la agregación, en donde un proyecto incluye o agrega subproyectos, en forma de módulos: dspace-parent dspace-api dspace-lni dspace-jspui dspace-xmlui dspace-oai dspace modules dspace-sword dspace-jspuiapi dspace-jspuiwebapp dspace-oaiapi dspace-oaiwebapp dspace-jspuiapi dspace-jspuiwebapp dspace-lniclient dspace-lnicore dspace-lniwebapp dspace-xmluiapi dspace-xmluiwing dspace-xmluiwebapp lni jspui xmlui oai sword Figura 24 Herencia en DSpace fuente propia 90

95 Módulos Figura 25 Agregación en DSpace fuente propia Cuando iniciamos la compilación del sistema leemos en la pantalla lo que nos va presentando Maven: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] DSpace Parent Project DSpace Kernel :: API and Implementation DSpace JSP-UI DSpace JSP-UI :: API and Implementation DSpace JSP-UI :: Web Application Resources DSpace XML-UI (Manakin) DSpace XML-UI (Manakin) :: Wing-Framework DSpace XML-UI (Manakin) :: API and Core Aspects [INFO] Resources DSpace XML-UI (Manakin) :: Web Application [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] DSpace LNI DSpace LNI :: Core Implementation DSpace LNI :: Web Application Resources DSpace LNI :: CLI Client Application DSpace OAI DSpace OAI :: API and Implementation DSpace OAI :: Web Application Resources DSpace SWORD DSpace SWORD :: API and Implementation DSpace SWORD :: Web Application Resources DSpace Addon Modules DSpace XML-UI (Manakin) :: Web Application Figura 26- módulos DSpace 91

96 [INFO] [INFO] [INFO] [INFO] DSpace LNI :: Web Application DSpace OAI :: Web Application DSpace JSP-UI :: Web Application DSpace SWORD :: Web Application [INFO] DSpace Assembly and Configuration Vemos cómo busca y lista recursivamente los archivos pom.xml (26 en total) y presenta una lista de proyectos a construir. El encargado de ordenar los módulos de tal manera que siempre se satisfagan las dependencias ínter modulares, es el plugin llamado Reactor, una parte central de Maven. Rápidamente nos damos cuenta que empieza a construir en Núcleo de DSpace, es decir la API, luego la interfaz gráfica JSP, la interfaz gráfica XML, la interfaz LNI, la interfaz OAI, la interfaz SWORD, los módulos superpuestos y por ultimo construye el módulo que ensambla todo el sistema. De esta información obtuvimos 7 (siete) módulos claramente diferenciados: DSpace Kernel (API). DSpace JSPUI. DSpace XMLUI. DSpace LNI. DSpace OAI. DSpace Kernel DSpace SWORD. DSpace Addon Modules. Este módulo constituye principalmente el corazón del sistema. Todos los otros componentes dependen de él para funcionar, puesto que los objetos relevantes del sistema se encuentran en este módulo. DSpace JSPUI Figura 27- Ubicación del módulo API (kernel) Este módulo se encarga del renderizado (interpretación) gráfico del sistema y se trata de una interfaz gráfica basada en tecnología JSP (Java Server Pages). En las primeras versiones del sistema era la única interfaz que existía. Su diseño interno presenta dos submódulos, uno que se encarga puramente del renderizado (dspace-jspui-webapp) y otro que se encarga del control del mismo (dspace-jspui-api). La figura muestra la relación entre el módulo y estructura de directorios del sistema completo. 92

97 DSpace XMLUI Figura 28- módulo jspui Este módulo al igual que el anterior se encarga de la presentación gráfica del sistema. Lo que cambia es la tecnología usada para el renderizado. El módulo anterior trabaja con páginas JSP, acá se construyen los gráficos usando tecnología XML. Se ha bautizado como Manakin a esta nueva interfaz gráfica. Tiene la ventaja de ser modificada, agregando temas y aspectos sin necesidad de saber java o jsp. Permite ser personalizada con mayor facilidad, soporta internacionalización y localización y es más agradable visualmente que la anterior intefaz gráfica vista. La figura muestra la estructura de directorios de este módulo. Consta de tres submódulo: dos para el procesamiento y uno para la presentación gráfica final. DSpace LNI Figura 29- módulo xmlui En este módulo se implementa una interfaz liviana de red (Lightweight Network Interface), para controlar DSpace de manera remota. LNI nació como un agregado o mejora al proyecto CWSpace del MIT. En este proyecto, los contenidos del OpenCourseWare (OCW) del MIT se alojan en un repositorio DSpace para su acceso público, su reutilización y su conservación. Actualmente no es un parte central del repositorio, sino un agregado opcional, pero es un avance hacia la interoperabilidad de la plataforma DSpace, orientada a la comunicación mediante Web Services. 93

98 Figura 30- módulo lni Como vemos en la imagen, este módulo consta de tres submódulos: uno es un cliente de prueba de la interfaz, otro engloba los objetos de la lógica y control y el tercer módulo ofrece un punto de acceso para los clientes dentro del servidor Web. Esta interfaz sirve para realizar acciones, sin utilizar el servidor DSpace, la idea es realizar ciertos controles o actividades de manera remota al servidor sin estar ligados a ninguna interfaz gráfica. Así se expone de una manera completa y comprensiva la API de DSpace para que se desarrollen aplicaciones cliente que puedan comunicase con la API de una manera indirecta. El proyecto sigue en desarrollo, ampliando la interfaz para brindar más control. Es una iniciativa positiva, aunque hoy por hoy no es la interfaz más usada. DSpace incluye una aplicación cliente SOAP para probar de manera muy trivial si se ha instalado correctamente el servidor LNI. Es una aplicación auto contenida en un JAR llamada LNISmokeTest. Por ejemplo podemos usarla desde la línea de comandos de la siguiente manera: java -jar dspace-lni-client snapshot-jar-with-dependenc ies.jar -e -f /252 DSpace OAI Figura 31 módulo oai 94

99 Este módulo es la implementación del protocolo OAI-PMH 2.0, es decir el Protocolo de Recolección de Metadatos creado por la OAI que vimos con anterioridad en el tema de Acceso Abierto. DSpace toma el rol de proveedor de datos ante sus clientes. Estos clientes son usualmente servidores o proveedores de servicios. DSpace expone los metadatos Dublin Core para los ítems que son de acceso público. La única restricción es que los metadatos de los ítems, internamente usan calificadores, cuando se recolectan, pierden el calificador encontrándose bajo el nombre del campo únicamente. Por ejemplo description.abstract se describe como description. Las Colecciones también tienen la posibilidad de ser presentados a través de un mecanismo de conjunto de OAI-PMH. OAICat Open Source de OCLC (Online Computer Library Center) es el Framework que provee esta funcionalidad. DSpace soporta tres formatos de metadatos oai_dc (Dublin Core), RDF (Resource Description Framework) y METS (Metadata Encoding and Transmission Standard), aunque de ser necesario se pueden implementar más formatos, mediante la implementación de Crosswalks. Estos se habilitan desde el archivo de configuración de OAICat: [dspace]/conf/oaicat.properties La URL base del proveedor de datos es: Para identificar unívocamente a un ítem, OAI no utiliza el Handle del Ítem, puesto que el Handle identifica al Ítem y lo que OAI requiere es un identificador del registro de metadatos de dicho Ítem. Se define un identificador OAI a la siguiente terna: oai:nombre_host:handle Por ejemplo: oai:dspace.univ.edu.ar: /432 A continuación mostraremos ejemplos de cada una de las consultas OAI-PMH realizadas en DSpace. 9/91&metadataPrefix=oai_dc 07&metadataPrefix=oai_dc &metadataPrefix=oai_dc

100 DSpace SWORD Este módulo es la implementación de un estándar denominado SWORD Simple WebService Offering Repository Deposit. A su vez SWORD está basado en el estándar APP o Atom Publishing Protocol. Esta interfaz permite depositar ítems en repositorios remotos, desde archivos empaquetados. La Web oficial del proyecto SWORD es Para usar SWORD se necesita de una aplicación cliente. Existen clientes genéricos, pero estos no suelen ser la elección en la mayoría de los casos. También existen clientes específicos, por ejemplo SWORDAPP de Facebook o mediante el Add-In Article Authoring de Microsoft Word Para usar estos clientes podría ser necesario agregar a DSpace un ingester (consumidor) de paquetes específico para los paquetes de contenido que los clientes crearan, o agregar un ingester de metadatos si DSpace no contara con el Plugin Crosswalk correspondiente. DSpace permite depositar contenidos únicamente si están empaquetados en formato METS. Si no existiera un cliente que se adecue a las necesidades del usuario, se pueden crear clientes SWORD sin partir de cero, utilizando librerías de código o APIs existentes para PHP y java. Actualmente DSpace soporta SWORD 1.3, pero ya salió la versión 2 del estándar. Otros repositorios como Fedora, IntraLibrary, E-prints cuentan con su implementación de SWORD. Figura 32 módulo sword En DSpace la implementación de SWORD está separada en dos módulos, uno contiene la lógica y otro ofrece la interfaz Web (no gráfica) para conectarse al servicio. 96

101 DSpace Addon Modules Figura 33 módulo addon Este módulo se encuentra vacío y es de propósito general. Está dividido en subcarpetas que contienen los mismos nombres que algunos submódulos anteriormente vistos (por ejemplo el módulo dspace-jspui dentro de este módulo se llama jspui). La utilidad de este módulo es la de presentarse como un contenedor de módulos Overlay, es decir superpuestos. Se los llama así porque redefinen o refinan el comportamiento de la interfaz Web de los módulos originales. Por ejemplo cualquier archivo puesto dentro de las subcarpetas /modules/jspui/src/main/webapp, reemplazará a su homónimo que está dentro de la carpeta /jspui/src/main/webapp dentro del submódulo Webapps del módulo original. Los módulos originales que no cuenten con un submódulo Webapp no podrán ser personalizados mediante este sistema. Por ejemplo dspace-api no cuenta con una subcarpeta en este módulo. Si se desea cambiar el comportamiento de la API, se debe trabajar sobre ella. Este sistema de overlapping, puede ser usado para reemplazar archivos de configuración, agregar idiomas para la internacionalización, cambiar el aspecto grafico de las páginas jsp, etc Extensibilidad Acabamos de ver al sistema DSpace como un conjunto de módulos agregados, en la cual Maven toma un rol primordial, al permitir la extensibilidad, mediante el acoplamiento de nuevos módulos (proyectos) al árbol de directorios. Estos son tratados como subproyectos y se compilan dentro del todo que es DSpace. Es por esto que queda la puerta abierta a nuevos proyectos y funcionalidades para añadir a DSpace. Claramente podemos afirmar que está pensado para crecer y ello permite la gran adhesión de los clientes y usuarios a lo largo de todo el mundo. Favorecido hoy en día por el reuso de código, la interoperabilidad, la solidez que brindan los frameworks y API de terceros que fomentan el desarrollo de proyectos open-source. 97

102 La forma modular de DSpace, permite a los usuarios usar aquellos módulos que realmente les sirvan. Evitando aquellas funcionalidades y recursos que no van a utilizar. En el siguiente diagrama vemos como puede ser extendido el sistema DSpace: Figura 34 DSpace: estructura modular fuente: Se puede añadir un agregado simple (your-addon) dependiente por ejemplo de dspace-api, que es un proyecto que forma parte de un nuevo submódulo de DSpace, y puede ser utilizado por otros proyectos (por ejemplo dspace-jspui). También se puede agregar una aplicación Web independiente (your-webapp) o una aplicación Web que modifique el comportamiento de una Webapp existente. Ésta es una de las principales motivaciones que tuvo el proyecto DSpace a la hora de elegir y migrar (en su versión 1.5) hacia Apache Maven como gestor de proyecto Modelo de Capas Luego de analizar el conjunto de artefactos del código fuente y ver al sistema como un todo de una manera tangible, se ve el sistema como un conjunto de sistemas y subsistemas integrado descubriendo la arquitectura subyacente en el modelo lógico de implementación. 98

103 Figura 35- DSpace: sistemas y subsistemas (Capas) fuente: Manual DSpace DSpace se describe como una suite de aplicaciones. Este conjunto de utilidades, sigue una arquitectura cliente-servidor. Se pueden identificar claramente tres capas de software con funcionalidades claramente diferenciables. Como se trata de un repositorio, necesita proveer un servicio de almacenamiento. A esta capa inferior la denominamos Capa de almacenamiento. Luego el repositorio necesita tener todos los objetos que necesita modelar para su utilización. Todo el comportamiento de objetos de primera clase se concentra en la segunda capa, o capa media denominada Capa de Lógica de Negocio. Y por último el repositorio necesita poder comunicarse con el mundo exterior, es aquí donde identificamos la tercer y última capa. En esta capa se ubican las aplicaciones que utilizan el mundo modelado en la capa intermedia, que a su vez sirven de interfaz con los usuarios finales o con otras aplicaciones tanto locales como remotas. A esta capa superior la llamamos Capa de Aplicación, puesto que es un conjunto de aplicaciones gráficas y no gráficas. Cada capa invoca a su inmediata inferior, no pudiendo acceder directamente a otras capas no adyacentes. En la Figura 35 se muestran dos APIs, que son un conjunto de subapis dentro de la capa en cuestión. Los objetos de una capa únicamente acceden a la capa inferior a través de dichas APIs. Analicemos con más detalle cada una de las capas. El código fuente está organizado en paquetes, que se diferencian según la capa que representen, como lo indica la tabla: Nombre del paquete org.dspace.app org.dspace org.dspace.storage Capa Capa de Aplicación Capa de Lógica de Negocio (excepto app y storage) Capa de Almacenamiento 99

104 Capa de Almacenamiento En esta capa veremos todo lo relacionado con la gestión de la persistencia de los contenidos almacenados en el sistema. DSpace usa un modelo de base de datos relacional (PostgreSQL) para almacenar toda la información de la organización de los contenidos, sus metadatos, información acerca de los usuarios, las autorizaciones, el estado de los envíos pendientes, en fin, todo aquello que sea necesario persistir en el tiempo. En la base de datos por ejemplo se encuentran los índices de navegación de los Ítems. A continuación se muestran las tablas más importantes del esquema de la Base de Datos: Figura 36- PostgresSQL: tablas más importantes del repositorio fuente propia La mayoría de las funciones que utiliza DSpace pueden ser brindadas por cualquier gestor de base de datos relacional que soporte transacciones. Los índices de navegación utilizan características especiales de algunos SGBD. Actualmente DSpace está soportado tanto por PostgreSQL y Oracle. DSpace brinda secuencias de comandos SQL para la inicialización y limpieza de la base de datos en la carpeta [dspace-src]/etc. 100

105 La funcionalidad de esta capa es abstraer las operaciones de consultas, altas, bajas y modificaciones de bajo nivel a los usuarios. Para tal fin existen dos APIs como se aprecia en la figura del Modelo de Capas. RDBMS Wrapper: La primer API está dentro del paquete org.dspace.storage.rdbms. Dicha API crea una abstracción sobre cualquier gestor de base de datos en particular y gestiona el acceso general a la DB. Bitstream Storage Manager: Esta segunda API se encarga de trabajar con los archivos almacenados por el repositorio. Está API contenida en el paquete org.dspace.storage.bitstore, aunque no suele usarse directamente, sino que se utiliza a través de los métodos del objeto de negocio Bistream. Los archivos de contenidos que deseen ser almacenados se trataran como flujos de bits. De aquí que el nombre para estos objetos sea Bitstream. Un Bitstream tiene asociado un BitstreamFormat como veremos en el modelo de objetos del sistema. Un BitstreamFormat es el formato del archivo, inherente a su codificación interna. El sistema identifica varios formatos, estos están inicialmente en un archivo XML, que durante la instalación del sistema se vuelcan en la base de datos. El archivo XML es [dspace]/config/registries/bitstream-formats.xml. Existen dos formas de almacenar los Bitstreams en el sistema: la primera es utilizando el sistema de archivos del servidor, la segunda es utilizando un SRB (Storage Resource Broker). Sin entrar en detalles, un SRB es un gestor de almacenamiento robusto, sofisticado que provee de almacenamiento ilimitado y una sencilla forma de replicación de los datos en otro servidor local o remoto. Por defecto se utiliza la primera opción. Los Bitstreams son almacenados en un proceso transaccional seguro dentro de la carpeta [dspace]/assetstore. Dentro de su tabla en la BD tienen un campo booleano de baja lógica que por defecto está en true. Esto hace que si ocurre un problema durante la subida del archivo al servidor, la base de datos quede consistente, ya que se ignoraran los Bitstreams borrados y nunca habrá un registro de Bistream apuntando a un archivo inexistente. Existe una herramienta para eliminar físicamente aquellos Bitstreams marcados como borrados ubicada en [dspace]/bin/cleanup. La copia de seguridad de los Bitstreams es muy sencilla, simplemente comprimiendo o empaquetando la carpeta configurada en dspace.cfg bajo la clave assetstore.dir Capa de Lógica de Negocio En esta capa veremos los aspectos internos del sistema, donde se aprecia el modelo de objetos del sistema, su comportamiento y la implementación de sus características y funciones. Clases centrales En este apartado veremos las clases que son ampliamente utilizadas a lo largo del código de DSpace. Dichas clases se encuentran en el paquete org.dspace.core. El gestor de Configuración El gestor de configuración (ConfigurationManager) es la clase encargada de leer el archivo de configuraciones principal [dspace]/config/dspace.cfg. Las plantillas de los 101

106 mails son accedidas desde esta clase así como también otros archivos de configuración de otras herramientas. El sistema se configura editando los valores de las propiedades en los archivos ubicados en [dspace]/config. Los scripts de línea de comando pueden acceder a la configuración, preguntando al ConfigurationManager por la propiedad específica que necesita, por ejemplo un script debería contener una línea similar a: /dspace/bin/dsrun org.dspace.core.configurationmanager -property property.name Lo que hace esta línea es imprimir en la salida estándar el valor de la propiedad con nombre property.name ubicada dentro del archivo dspace.cfg. Constantes Esta clase contiene constantes que son usadas para referencias los tipos de objetos, acciones en el sistema, nombres por defecto de los Bundles. En la base de datos puede encontrarse estas constantes. Por ejemplo la tabla resourcepoliciy en el campo resource_type_id, donde el valor contenido sea por ejemplo Constants.ITEM. Contexto Esta clase es central en las operaciones de DSpace. Cualquier código que desee utilizar la API de la Capa de Lógica de Negocio, deberá crear un objeto Context. Eso es similar a crear una conexión con la base de datos (que de hecho es una de las cosas que suceden). Un objeto Context, está relacionado con numerosos métodos y constructores, brindándoles información importante. Cuando se crea un Context se completa automáticamente la siguiente información: Se crea una conexión transaccional segura con la base de datos. Se crea una cache de objetos de la API de gestión de contenidos. Por ejemplo cada vez que se crea un Item o un Bitstream, éste se cachea dentro del objeto Context. Si el objeto se consulta de nuevo, se usa la versión de la cache. Esto alivia el uso de la base de datos y la complicación de tener varias copias de un objeto con estados diferentes. Además se puede almacenar la siguiente información dentro de un objeto Context, pero es la aplicación la que se encarga de llenarlo de la manera correcta. El usuario autenticado, si hay. Algún grupo especial, en el que el usuario sea miembro. Cualquier información de la Capa de Aplicación que debería ser registrada en el archivo de Log del sistema (*.log), por ejemplo la información de la sesión en el caso de aplicaciones Web. Un flag indicando si se debe ignorar la autorización. Esto se usa raramente, pero por ejemplo en la primera instalación del sistema, cuando no hay ningún usuario autorizado, alguien debe crear al administrador. Muchas operaciones pueden ser realizadas con un objeto Context. Si todo sale bien se llama a complete() para guardar los cambios y liberar los recursos usador por el contexto. Si hubo algún error, se llama a abort() y se hace un roll back liberando los recursos en el estado que se obtuvieron. 102

107 Siempre se debería llamar a abort() cuando ocurre un error, sino podría quedar inconsistente la información. También se puede llamar a commit() lo que guarda los cambios en la base datos y se mantiene vivo el contexto para seguir usándolo. Enviar un correo electrónico es muy simple. Para ello se utiliza el método ConfigurationManager.get (). Se necesita completar los argumentos y los destinatarios y se envía. Los textos de los correos electrónicos con sus respectivos argumentos, se encuentran en la carpeta [dspace]/config/ s/ LogManager Esta clase consiste de un método que crea un encabezado de log estándar. Esto no escribe nada en el log, únicamente crea la cadena para luego ser enviada a la llamada de log4j correcta. Una línea de log típica es similar a la siguiente: :11:32,903 INFO 86 Esta información se divide en: Fecha y hora con milisegundos :11:32,903 Nivel (FATAL, WARN, INFO, DEBUG) Clase Java del usuario o anonymous INFO Anonymous : Información extra del contexto session_id=bd84e7c194c2cf4bd0ec3a6cad0142bb : Acción view_item : Información extra handle=1721.1/1686 Este formato permite un fácil análisis sintáctico (parseo). El script PERL [dspace]/bin/log-reporter es una herramienta simple para analizar los logs. Gestor de Plugins Esta clase gestiona los plugins del sistema. Más adelante veremos en detalle como funcionan y para que son utilizados. 103

108 Utilidades Esta clase contiene diversas utilidades que se requieren a lo largo de todo el sistema. Manejo de claves MD5, copiado de archivos, manejo de fechas son algunos usos más frecuentes. API de Gestión de Contenido Clases del Modelo de Datos Esta API está ubicada en el paquete java org.dspace.content y engloba a las clases que se requieren para leer y manipular los objetos que almacenan contenidos en el sistema. Estos objetos debido a su importancia se los denomina objetos de primera clase. Esta es la API que más usan las aplicaciones, en la Capa de Aplicación. Las clases de este paquete que se corresponden con el Modelo de Objetos de DSpace (Item, Collection, Bitstream, Bundle, Community), son subclases de la clase abstracta DSpaceObject. Por lo general estas clases tienen uno o varios métodos find, que son usados para instanciar estas clases. Los constructores son privados. Para crear una Collection, un Bundle, y un Bitstream, hay que llamar al método correspondiente de su contenedor. Por ejemplo para crear una colección habría que llamar al método correspondiente del objeto comunidad que lo contendrá. Los ítems son creados inicialmente bajo la forma de InProgressSubmission. Esta interfaz está implementada por dos clases: WorkspaceItem y WorkflowItem. En el proceso de envío antes de finalizar el último paso, el ítem en proceso es un objeto WorkspaceItem, es decir está en el espacio de trabajo del usuario. Una vez finalizados todos los pasos del proceso de envío, el usuario desea enviar el ítem creado al repositorio. Si no se requiere de autorizaciones adicionales, este ítem se almacena en el archivo por medio de la clase InstallItem. Si se requiere de alguna autorización para instalar físicamente el ítem, éste pasa a ser un WorkflowItem, es decir un ítem en el flujo de trabajo. En este flujo de trabajo el ítem es revisado por otros usuarios con privilegios. Más adelante veremos el proceso de ingestión o publicación para aclarar dudas. Las Community y los BitstreamFormat son creados por el administrador del sitio. Metadatos Las clases que comienzan con DC manipulan los metadatos Dublin Core. Este diseño de nombres en las clases indica que DSpace no está pensando en los metadatos genéricamente. Otras clases La clase FormatIdentifier intenta identificar el formato de los Bitstreams, actualmente sólo mira la extensión del archivo y la compara con los registros en la base de datos. Esto debería ser mejorado en el futuro. La clase ItemIterator permite recorrer los ítems de uno en uno, y es usada por los métodos que devuelven una gran cantidad de ítems, más de los que se desearía tener en la memoria. 104

109 La clase ItemComparator permite comparar los ítems de acuerdo a determinado campo Dublin Core. Modificaciones Cuando modificamos los objetos del Modelo de Datos de DSpace tenemos que saber cuando las cosas ocurren en memoria y cuando ocurren en la base de datos. En un principio si no se llama a complete() o a commit() en el objeto Context, no habrá cambios en la base de datos, si hubieran problemas se debería llamar siempre a abort() en el objeto Context asociado. Algunos cambios únicamente ocurren en memoria, cuando se llama al método update() de los DSpaceObject por ejemplo, que luego estos son persistidos en el momento de llamar a complete() o commit() en el contexto asociado. En general los cambios que producen los métodos que cambian metadatos, sólo se producen en memoria, y los cambios que producen los métodos que involucran relaciones con otros objetos se producen en la base de datos al momento del complete() del contexto. Qué hay en memoria? Cuando se instancia un objeto y éste contiene a otros, éstos también son instanciados, porque en el diseño se supone que se necesitará la información asociada contenida en los objetos relacionados. Esto a veces puede ser una desventaja que apunta a la sobrecarga de memoria. Un ejemplo claro de ello es al momento de instanciar un Item, también se instancian sus Bundles y a su vez los Bistreams de cada uno de sus Bundles. Metadatos Dublin Core y soporte para nuevos esquemas La clase DCValue representa un valor de un elemtento Dublin Core, especificado por un nombre de esquema, un nombre de campo y calificador opcional. Se agregaron clases adicionales para el soporte a nuevos esquemas. Se sugiere dejar de utilizar la clase DCValue, y utilizar en su lugar a MetadataValue. La clase MetadataField representa a un elemento de metadatos. Si bien se pueden agregar nuevos esquemas no se provee soporte para esquemas jerárquicos, sólo se admiten esquemas planos, como Dublin core. La clase MetadataSchema representa a un esquema de metadatos. Dublin Core es soportado por defecto. Plugins Por último veremos los Plugins que se encuentran dentro de org.dspace.content. Existen dos tipos de plugins, los Crosswalk y los Packager. Los primeros permiten trabajar con los metadatos de los objetos de primera clase y los segundos lo hacen a nivel de paquetes de contenidos. Los packagers pueden hacer uso de los plugin Crosswalk. Por ejemplo los primeros hacen el trabajo de tomar la información del paquete (metadatos + recursos) y les delegan el trabajo a los Crosswalk para que éstos manipulen los metadatos de un ítem. Los plugin Crosswalk están dentro del paquete java org.dspace.content.crosswalk. La idea de estos plugins es trabajar con metadatos distintos al formato nativo de DSpace (Dublin Core), importando o exportándolos en formato XML. Se pueden entender como una especie de 105

110 traductores, ya que permiten incorporar a los objetos, metadatos en otros formatos estándares (ingest) o traducir en algún otro formato, los metadatos de algún objeto de DSpace (dissemination). Los plugin Packager están dentro del paquete org.dspace.content.packager. Funcionan de una manera similar a los anteriores, es decir como traductores, aunque a nivel de paquete. Un paquete es una secuencia de bytes, por lo general en formato comprimido que representa por ejemplo a un ítem del sistema. Existen dos tipos de packagers (llamaremos packagers o empaquetadores a los plugins de este tipo): los ingesters y los disseminators. Los ingesters, permiten procesar un paquete en algún formato externo al nativo de DSpace, e incorporarlo al repositorio. Los diseminators realizan la tarea inversa, toman un objeto del sistema, por ejemplo un Ítem y lo empaquetan en algún formato externo al sistema, por ejemplo un paquete METS. Packager Crosswalk ingesters Los ingesters traducen un paquete en un Item de DSpace. Los ingesters traducen un esquema de metadatos externo en un esquema de metadatos interno empleado por los Item de DSpace. diseminators Los disseminators traducen un Item en un paquete. Los disseminators traducen los metadatos internos de un Item en un esquema externo XML. Gestor de Plugins Este componente central de DSpace permite instanciar a los plugins y comprobar la configuración del sistema para el adecuado uso de los mismos. La clase que realiza el trabajo es org.dspace.core.pluginmanager. Un plugin es una pieza de software que implementa cierta interface java. De ahí que puede ser intercambiado por otras implementaciones y ser enchufado o plugged in en inglés. De este concepto surge que cualquier clase puede ser usada como un plugin si se configura correctamente. Los plugins son reusables, ello quiere decir que siempre el gestor de plugins devuelve el mismo objeto en todas las llamadas. Éste es el comportamiento por defecto, si no se requiere esto habrá que especificar cuales plugins no son reusables. Tipos de plugins El gestor de plugins soporta tres patrones de uso: Plugin Singleton: e un plugin que está implementado en una única clase en todo el sistema. Se configura estáticamente. Para obtener el plugin se usa el método de clase getsingleplugin() con la clase de la interfaz como parámetro. Es un plugin anónimo, ya que sólo requiere el nombre de la interfaz para instanciarse. Secuencia de plugins: consiste en una secuencia de plugins. Es decir se utilizan en serie como una pila o tubería. Para obtener este plugin se usa el método de clase getpluginsequence() con la clase de la interfaz que cumple como parámetro. Un ejemplo de esto puede ser el sistema de autenticación 106

111 Stackable (más adelante veremos esta funcionalidad). El orden de los plugins es el orden definido estáticamente en el archivo de configuración. Plugin con nombre: se usa cuando para un tipo de plugin, mejor dicho para una interfaz de plugin, existen varias implementaciones y se requiere sólo una implementación. Para instanciar el plugin se utiliza su nombre. El nombre tiene que ser único, es decir si varias clases implementan la interfaz del plugin, deben tener nombres distintos en el archivo de configuración. Este tipo de plugins son comunes en los packagers y crossowalks vistos anteriormente. Para instanciar el plugin se usa el método de clase getnamedplugin() con la interfaz y el nombre como parámetros. El gestor de plugins puede devolver todos los nombres de las implementaciones de un plugin determinado. Esto puede ser útil para presentarle al usuario una lista de opciones para realizar determinada tarea. Para comprobar la configuración de los plugin dentro del archivo de configuración se usa el método estático checkconfiguration(). Configuración Los plugins se configuran en el archivo de configuración del sistema dspace.cfg mediante el uso de pares clave=valor. Se puede especificar en dicho archivo la siguiente información: Interface: el paquete seguido del nombre de la interfaz java que se requiere implementar. Clase de implementación: el paquete seguido del nombre de la clase que implementa la interfaz. Nombre: el nombre del plugin en caso de ser un plugin con nombre. Reusabilidad: especificación de no reusabilidad, ya que por defecto todos son reusables. Sistema de Flujo de Trabajo El Sistema de Flujo de Trabajo o más conocido como Workflow, es el proceso que modela la incorporación de un nuevo Ítem al sistema. El flujo de trabajo comienza cuando usuario que deposita el ítem acepta la licencia y manifiesta su intención de que su material sea incorporado al repositorio. El proceso puede ser más o menos largo/riguroso. Es por ello que está modelado mediante una máquina de estados finita. La cantidad máxima de estados es cinco. Pero cada colección configura este parámetro. Veamos una ilustración y luego analizamos como se implementa este proceso. 107

112 Figura 37- Implementación proceso Workflow fuente: Manual DSpace El Item recientemente depositado está contenido en un objeto WorkspaceItem que nos indica que esta en proceso de envío (WorkspaceItem implementa la interfaz InProgressSubmission). La clase que controla todo el proceso es org.dspace.workflow.workflowmanager. El gestor del flujo de trabajo de los ítems, es controlado mediante eventos. El primer evento ocurre cuando termina el proceso de envío por el usuario, luego de aceptar la licencia en el último paso del asistente de envío. Este evento llama al método start() del WorkflowManager. El cual toma el ítem contenido dentro del WorkspaceItem, lo deposita dentro de un nuevo objeto, un WorkflowItem y elimina el WorkspaceItem. A partir de este momento el ítem está dentro del flujo de trabajo, puesto que WorkflowItem también implementa la interfaz InProgressSubmission, el ítem aun sigue en proceso de envío. Aunque en el diagrama no se observan, existen tres estados más, son estados de espera, en los que los ítems están en un pool esperando a ser tomados para entrar en los estados diagramados. Así podemos definir STATE_POOL_N donde N es el estado de 1 a 3. Luego de pasar por STATE_POOL_N el siguiente paso es STATE_N. La secuencia de estados normalmente seria la siguiente: Evento Estado del WorkflowItem Usuario Acepta la licencia STATE_POOL_1 Revisor acepta la tarea pendiente STATE_1 Revisor aprueba el ítem STATE_POOL_2 Supervisor acepta la tarea pendiente STATE_2 Supervisor aprueba el ítem STATE_POOL_3 Editor acepta la tarea pendiente STATE_3 Editor aprueba finalmente el ítem 108

113 ARCHIVED Cuando el WorkflowItem inicia su recorrido por los estados, puede hacerlo velozmente o quedar un tiempo indeterminado, hasta que otro evento haga que avance o retroceda de estado. La cantidad de estados está definida dentro de la colección dueña del ítem. Si la colección tiene asignado un grupo de usuarios supervisores/revisores/editores en el paso N, entonces el WorkflowItem tendrá que esperar un evento que lo deposite en el estado N. Este evento ocurre cuando un supervisor del paso N acepte la tarea pendiente que le ha sido notificada por . Si la colección dueña no tuviera un grupo de supervisores asignados en el paso N, el WorkflowItem avanzaría al paso siguiente y así sucesivamente. Si la colección no tuviera asignados supervisores en ningún paso, el ítem simplemente atravesaría por todos los estados rápidamente y en el último estado (ARCHIVED) seria archivado físicamente. Herramientas de Administración El paquete org.dspace.administer contiene algunas herramientas para la administración del sistema que generalmente no son requeridas por las demás aplicaciones. La clase CreateAdministrator se usa para crear un administrador. Esto se hace desde la línea de comandos al instalar el sistema como vimos en el capitulo de la instalación. Una vez que se ha creado el administrador, éste puede configurar el sistema desde la interfaz gráfica Web. La clase DCType modifica los registros de los campos de metadatos Dublin Core por parte del administrador. La clase RegistryLoader permite cargar la base de datos con los registros iniciales tomados desde archivos de configuración XML. Por lo general esto lo hace Apache Ant en el proceso de instalación y configuración final. Gestión de Usuarios/Grupos Los usuarios del sistema son representados por la clase EPerson del paquete org.dspace.eperson. Los usuarios registrados pueden realizar muchas actividades como consultar colecciones con restricciones, subir contenidos, bajar, importar y exportar. La mayoría de las actividades del sistema, requieren que se realicen por un usuario registrado. Como vimos anteriormente éste se almacena en una operación, dentro del Context actual de dicha operación. La clase EPerson almacena los nombres, el teléfono, el correo electrónico, el idioma, la codificación encriptada MD5 5 de su contraseña, etc. Contiene múltiples setters y getters y métodos para consultar información de los usuarios indicando por ejemplo su , nombre, etc.. La contraseña no se almacena en la BD, sólo se registra su código MD5. Los Grupos son listas o conjuntos de usuarios (EPerson). Los grupos representados por la clase Group tienen métodos para agregar y quitar usuarios de los mismos. Se usa 5 MD5(Message-Digest Algorithm 5) Algoritmo de Resumen del Mensaje 5 es un algoritmo de reducción criptográfico de 128 bits. 109

114 addmember() para agregar un miembro y removemember() para quitar un miembro existente. Los grupos tienen un nombre. Un grupo puede ser visto matemáticamente como un conjunto, donde sus elementos son los objetos Eperson. Un grupo puede compartir miembros con otro grupo. El sistema crea automáticamente grupos de usuarios cuando por ejemplo creamos una colección, siguiendo ciertas convenciones de nombre. Por ejemplo si creamos la colección 100, a los usuarios a los que les hayamos dado permiso para depositar ítems, pertenecerán al grupo llamado COLLECTION_100_ADD. Cuando se modifica la cardinalidad del conjunto de miembros, ya sea quitando o agregando miembros al grupo, hay que llamar al método update() para no perder los cambios. El sistema de autorización usa mucho los grupos, por lo tanto se provee del método ismember() para determinar rápidamente si un usuario o grupo de usuarios es miembro de un determinado grupo. Autorizaciones En este apartado veremos como el sistema aplica las políticas de seguridad. Veremos el modelo subyacente de autorización y las clases intervinientes. El modelo de seguridad que implementa DSpace implica que ninguna acción es permitida a menos que se especifique lo contrario. Las políticas de seguridad consisten de una larga lista de objetos, acciones y usuario/grupos. En donde una política está claramente identificada por el objeto en el cual el usuario o los usuarios del grupo pueden realizar determinada acción. El sistema de autorización está contenido dentro del paquete org.dspace.authorize. La clase que gestiona todas las autorizaciones es AuthorizeManager, y la clase que almacena todas las políticas de seguridad es ResourcePolicy. Los objetos ResourcePolicy tienen un campo que indica el tipo de recurso (ITEM, COLLECTION, COMMUNITY, etc.) y otro campo que indica la acción a permitir (ADD, READ, WRITE, etc.). Ambos valores son constantes enteras, extraídas de la clase org.dspace.core.constants. El método principal de la clase AuthorizeManager es authorizeactionboolean() donde nos indica si el usuario puede realizar determinada acción sobre determinado objeto del sistema. Por defecto todos los ítems de las colecciones se permiten ser accedidos públicamente. A esto nos referimos cuando no hay un usuario específico que ha iniciado sesión en el sistema (logeado). A los usuarios anónimos, se les asigna el grupo 0. El grupo con ID=0 se denomina ANONYMOUS y todos los usuarios registrados pertenecen por defecto a este grupo. Otro grupo especial además del grupo público ANONYMOUS, es el grupo del administrador, es decir el grupo con ID=1. El grupo ADMINISTRATOR pertenece a todos los grupos. Este sistema de políticas de acceso es muy flexible, puesto que un mismo objeto puede tener numerosas políticas según el usuario o grupo de usuarios, según la acción, o una combinación de ambos. Los ítems heredan las políticas de lectura por defecto de su colección dueña. 110

115 Gestión de Identificadores En este apartado analizaremos como hace DSpace para asignar identificadores a sus comunidades, colecciones e ítems. Para tal fin DSpace decide no reinventar la rueda y apuesta al proyecto en vías de estandarización, del CNRI (Corporation for National Research Initiatives), denominado The Handle System. Este sistema distribuido, permite asignar identificadores persistentes a objetos, ofreciendo un sistema de resolución de nombres, o mejor dicho de handles. Se llama handle a cada identificador. El sistema de gestión de identificadores o handles, está en el paquete org.dspace.handle. La clase principal que gestiona los handles es HandleManager. En ella se pueden crear los handles para un objeto DSpace, se puede obtener la URL de un handle, se puede obtener un objeto a partir de un handle, etc. El sistema de handle puede funcionar sin el servidor de handle instalado, de manera local. En este caso DSpace maneja la resolución de handles. Hay que tener en cuenta que cuando no se utiliza el servidor de Handles, los identificadores que crea DSpace son locales y no persistentes, puesto que el servidor central de handle.net no se entera. En modo offline (fuera de línea) se generan handles con un prefijo por defecto: hdl: /nro_obj (nro_obj es un entero que apunta a un ítem, una colección o una comunidad). Para tener persistencia en los identificadores hay que instalar el servidor de handles en el sistema. Luego de realizar un proceso de registro en y habilitarnos como servidor, se nos dará un número de Naming Authority (prefijo), es decir, estaremos habilitados para gestionar nuestros propios identificadores persistentes. Con lo que nuestros objetos serán unívocamente identificados y encontrados en todo el mundo. Una vez que tengamos el prefijo asignado (prefijo_asignado) nuestros handles serán de la forma: hdl:prefijo_asignado/nro_obj En un sistema en producción, se acompaña la instalación de DSpace con el servidor de Handles versión 5.2 ubicado en [dspace-src]/lib/handle.jar, o bien puede descargarse desde la última versión del servidor. CNRI provee una API que DSpace implementa (en la clase HandlePlugin). Se configura la instalación del servidor de Handles mediante el comando [dspace]/bin/make-handleconfig. HandlePlugin es la API local que se comunica con la API remota central, para proveer del servicio de resolución de nombres a quienes quieran acceder a nuestros objetos internos. El servidor de handles estará listo después de ejecutar [dspace]/bin/start-handleserver. Si se ha instalado el servidor después de haber creado ítems, habrá que cambiar los handles locales por los handles reales, de esos objetos. Para tal tarea se cuenta con la herramienta [dspace]/bin/update-handle-prefix. 111

116 Búsquedas Ésta es una de las partes más importantes del sistema, ya que la búsqueda de los contenidos que se almacenan es uno de los principales usos del repositorio. DSpace decide no desperdiciar esfuerzos y hace uso de soluciones existentes en materia de motores de búsqueda de código abierto. En este caso, adapta un motor de búsquedas como es Apache Lucene. La API de búsquedas de DSpace simplemente envuelve al motor real Lucene. Buscar implica dos operaciones básicas, la indexación y la consulta. El código se encuentra en el paquete org.dspace.search. Indexación La indexación está a cargo de la clase DSIndexer. Dicha clase contiene un método indexcontent() que agrega al índice los contenidos de los campos del objeto DSpace que se le pase como parámetro. Éste puede ser un Item, una Collection, o una Community. También existen métodos para desindexar y para reindexar, unindexcontent() y reindexcontent() respectivamente. Además DSIndexer puede ser llamado desde la línea de comandos, es por esto que existen utilidades como [dspace]/bin/index-init o [dspace]/bin/index-update. La indexación se personaliza mediante las clases DSAnalizer y DSTokenizer que extienden a sus correspondientes Analizer y Tokenizer definidas en el API de Lucene. Una pregunta obvia sería: Qué información indexa DSIndexer? La respuesta es: lo que nosotros le indiquemos en el archivo de configuración dspace.cfg. Definimos los índices de la siguiente manera: search.index.i = nombre_indice:esquema.campo[.calificador.*] Ésto indica que el índice número i llamado nombre_indice indexará todos los contenidos de todos los objetos cuyos metadatos correspondan con el esquema.campo o esquema.campo.calificador. DSpace por defecto define los siguientes: search.index.1 = author:dc.contributor.* search.index.2 = author:dc.creator.* search.index.3 = title:dc.title.* search.index.4 = keyword:dc.subject.* search.index.5 = abstract:dc.description.abstract search.index.6 = author:dc.description.statementofresponsibility search.index.7 = series:dc.relation.ispartofseries search.index.8 = abstract:dc.description.tableofcontents search.index.9 = mime:dc.format.mimetype search.index.10 = sponsor:dc.description.sponsorship search.index.11 = identifier:dc.identifier.* 112

117 search.index.12 = language:dc.language.iso DSpace permite búsquedas avanzadas, en las cuales se especifican los índices mencionados anteriormente. Consultas La clase DSQuery cuenta con tres versiones del método doquery(), que en castellano significaría realizarconsulta. La primera versión busca en todo el repositorio. La segunda versión, busca únicamente en una colección, y la tercera en una comunidad. Los resultados se devuelven en un objeto QueryResults que contiene una lista de handles de los objetos que satisficieron la búsqueda. El paquete org.dspace.search también provee una interfaz de Harvesting o recolección. Ésto permite a los usuarios de esta API, extraer información de los ítems que fueron modificados en determinado rango de fechas. Actualmente esta API es usada por la aplicación que implementa el protocolo OAI-PMH, de ahí el nombre que se le da a esta interfaz. Otro uso que se le da a esta funcionalidad es la de recolectar la lista de ítems modificados en determinada fecha para avisarle a los suscriptores mediante el envío de un correo electrónico. Navegación Llamamos navegación a la funcionalidad del sistema que consiste en desplegar elementos rápidamente mediante un índice seleccionado. Es una de las funciones más utilizadas para encontrar rápidamente el contenido deseado. Veamos como está implementada. El paquete que concentra esta API es org.dspace.browse. La navegación se realiza sobre ítems archivados y autores. Los índices sobres los cuales se realizan las búsquedas parametrizadas que luego devuelven los resultados son: Title (Listar Ítems por título): Se indexan los ítems por el campo dc.title. Author (Listar Autores): Se indexan los autores y la información se extrae de los ítems en el campo dc.contributor. Tiene ciertas limitaciones como por ejemplo que el mismo autor aparezca dos veces si no se ha ingresado con exactamente el mismo nombre, o también que dos autores con el mismo nombre aparezcan una sola vez en el índice. Date of issue (Listar ítems por fecha de publicación): Se indexan los ítems por el campo dc.date.issued. En este listado se tiene en cuenta la fecha de publicación en el sistema, no la fecha de ingreso o envío, que puede ser anterior a la aprobación final. Date accessioned (Listar ítems por fecha de envío): Se indexan los ítems de acuerdo a su fecha de envío, es decir por el campo de metadatos dc.date.accessioned. En este listado no importa cuando se hicieron públicos, sólo importa cuando fueron enviados. Sirve por ejemplo para ver envíos recientes. Items of an autor (Listar los ítems de un autor específico): Se pueden realizan listados de ítems de determinado autor. No necesariamente tiene que ser el principal. También se puede especificar el ámbito de colección o comunidad. La API devuelve todos los ítems del autor, no se pueden filtrar los resultados. 113

118 Subject (Listar los asuntos o temas de los ítems): Se indexan los asuntos o temas de los ítems. Para ello se utiliza el campo dc.subject de cada ítem. Para utilizar esta API generalmente se crea un objeto BrowseScope, donde se parametrizan detalles de la búsqueda, luego este objeto se envía al objeto BrowseEngine donde se le pasa como parámetro al método browse() o browsemini(). Luego este método devuelve los resultados en un objeto BrowseInfo. El objeto BrowseScope puede parametrizarse por ejemplo se puede especificar: La cantidad de entradas en el índice que se desean listar. Seleccionar el ámbito de una colección, comunidad o todo el sistema. La parte inicial del índice a buscar (llamado foco). Por defecto se usa el inicio del índice, pero se podría informarle un valor de índice para que liste a partir de ese valor. Esto se usa cuando se lista por orden alfabético. Cuántas entradas deben incluirse antes del foco. Algo importante a tener en cuenta es que todos los ítems tienen metadatos para el índice. Aún para los usuarios que no tienen permisos para acceder a los ítems. Únicamente verán los metadatos usados en la lista de ítems. Si los usuarios no tuvieran privilegios para acceder, al intentar entrar en un ítem, aparecería el mecanismo habitual de autorización. Los índices se mantienen por lo general automáticamente, y esto lo hace la API de la Gestión de Contenido. Aún así existen métodos para agregar o quitar elementos del índice y para regenerar los índices desde cero. Si por alguna razón los índices se tornan inconsistentes, existe una herramienta de línea de comandos [dspace]/bin/index-init que regenera los índices de navegación. También puede hacerse directamente llamando a las clases: IndexBrowse f r ItemCounter Actualmente la implementación de los índices no es muy eficiente. Se reduce a extraer los metadatos de los ítems, normalizarlos (extraerles información no utilizada, pasarlos a minúsculas, etc.) y almacenarlos en la base de datos en determinadas tablas, con determinados índices y ordenamientos. Los índices de navegación, están configurados en el archivo de configuración dspace.cfg de la siguiente manera: Si se trata de un índice de metadatos del ítem (por ejemplo listar autores) se configura con la siguiente sintaxis: webui.browse.index.<n> = <index name> : metadata : \ \ <schema prefix>.<element>[.<qualifier>.*] : (date title text) : (asc desc) (date title text <other>) se refiere al tipo índice de datos del campo (fecha título con link o texto sin link). Si se trata de un índice de ítems se configura con la siguiente sintaxis: webui.browse.index.<n> = <index name> : item : <sort option name> : (asc desc) 114

119 Donde sort option name es el ordenamiento aplicado en la visualización. Debe coincidir con webui.itemlist.sort-option de más abajo. Por defecto la configuración aparece de esta forma: webui.browse.index.1 = dateissued:item:dateissued webui.browse.index.2 = author:metadata:dc.contributor.*:text webui.browse.index.3 = title:item:title webui.browse.index.4 = subject:metadata:dc.subject.*:text Comprobador de Suma de Seguridad (Checksum): El sistema provee una herramienta que permite comprobar mediante el uso de una clave MD5 si el contenido de los Bitstreams o archivos almacenados han sufrido alteraciones. Esta herramienta puede invocarse desde [dpace]/bin/checker. Este script invoca a la aplicación ubicada en org.dspace.app.checker. Pero el paquete que realiza esta tarea finalmente se encuentra en org.dspace.checker. Se puede configurar su ejecución periódicamente mediante herramientas del sistema operativo como cron de Linux o el gestor de tareas programadas de Windows. En archivos grandes este proceso puede demorar demasiado afectando el rendimiento del servidor. Cada Bitstream enviado al archivo calcula su clave MD5 y la almacena en la BD. La herramienta simplemente vuelve a calcular esta clave y la compara Capa de Aplicación En esta capa veremos las distintas aplicaciones que se ejecutan sobre la capa de Logica de Negocio, utilizando todas las funcionalidades que les brinda la API del sistema, para poder darle a los usuarios finales las herramientas para utilizar el sistema de la manera más eficiente. Interfaz Web del usuario Empezamos describiendo una de las aplicaciones mayormente utilizadas. Nos referimos a la aplicación que nació en DSpace como la única interfaz Web de usuario. En las versiones anteriores, esta era la interfaz por defecto, de ahí que tiene numerosos adeptos. En la versión actual, sigue siendo la interfaz gráfica Web por defecto, pero además tiene a su nueva competidora en este terreno, la interfaz XMLUI que ya presentamos anteriormente. En este apartado hablaremos de la interfaz gráfica tradicional JSP. Esta interfaz permite a los usuarios acceder al sistema DSpace utilizando cualquier navegador Web. Está basada en tecnología java, como el nucleo del sistema, por ende estamos hablando de servlets y JSP del lado del servidor. Esta interfaz cumple con dos estándares como XHTML 1.0 y WAI (Web Accessibility Initiative) nivel 2. Además cuenta con un espacio dedicado para el administrador del sistema, pero no es no es muy flexible, y el administrador debe saber bien lo que está haciendo. 115

120 Distribución de Archivos Los archivos relacionados con esta aplicación Web están diseminados por muchos directorios a lo largo de [dspace-src]. Este cambio es debido a la reestructuración del proyecto, ahora usando Maven para la construcción. JSPUI forma parte de DSpace como un submódulo pseudoindependiente. Veamos en una tabla donde está cada componente: Ubicación dentro del código fuente [dspace-src]/dspace-jspui/dspace-jspuiapi/src/main/java/org/dspace/app/webui [dspace-src]/dspace-jspui/dspace-jspuiapi/src/main/java/org/dspace/app/webui/filters [dspace-src]/dspace-jspui/dspace-jspuiapi/src/main/java/org/dspace/app/webui/jsptag [dspace-src]/dspace-jspui/dspace-jspuiapi/src/main/java/org/dspace/app/webui/servlet [dspace-src]/dspace-jspui/dspace-jspuiapi/src/main/java/org/dspace/app/webui/servlet/admin [dspace-src]/dspace-jspui/dspace-jspuiapi/src/main/java/org/dspace/app/webui/util/ [dspace-src]/dspace-jspui [dspace-src]/dspace/modules/jspui/src/main/webapp [dspace-src/dspace/modules/jspui/src/main/resources [dspace-src]/dspace-jspui/dspace-jspuiwebapp/src/main/webapp/web-inf/dspace-tags.tld Descripción Archivos fuente de la interfaz gráfica Web. Filtros Servlet(versión 2.3) Clases de las etiquetas personalizadas JSP. Servlets (Controladores) de la interfaz principal. Servlets que constituyen la parte de administración de la interfaz Web. Diversas clases usadas por los servlets y los filtros. Los archivos JSP. Donde se depositan las páginas JSP personalizadas Donde se deposita la versión modificada del archivo Messages.properties. Descriptor de las etiquetas personalizadas de DSpace. Servlets y JSPs La interfaz JSPUI está inspirada en el modelo MVC (Modelo Vista Controlador). El Modelo está representado por la API de Gestión de Contenido, vista anteriormente en la capa de Lógica de Negocio. La Vista está implementada mediante las páginas JSP y el papel de Controlador lo cumplen los distintos servlets. Las interacciones con esta interfaz son de la siguiente forma: Se recibe una petición HTTP de un cliente. Se invoca al servlet apropiado y éste procesa la solicitud HTTP utilizando la API de Gestión de Contenido de la capa de Lógica de Negocio. El servlet elige la JSP apropiada de acuerdo al resultado de la operación solicitada. Se procesa la JSP y se envía al cliente. 116

121 Como deducimos todo el procesamiento termina antes de enviar la JSP al cliente. Se intenta que las páginas JSP sean lo más sencillas posibles, tratando de incrustarles la menor cantidad de código java, para permitir su fácil personalización. La mayor parte del código de control y proceso está dentro de los servlets. Si ocurre algún error, éste no sucederá cuando se está realizando el dibujado de la página JPS, es decir durante el renderizado HTML. La página será presentada detallando el error al cliente. Todos los servlets son subclases de DSpaceServlet. La clase DSpaceServlet maneja algunas cosas básicas como la creación de un Context, la gestión de errores y autenticación, etc. Los servlets de DSpace no sobrescriben los métodos doget() y dopost() tradicionales. En cambio implementan dodsget() y dodspost() los cuales tienen un parámetro adicional para recibir al Context y poder manejar muchas excepciones de una manera natural. Los servlets procesan los contenidos de las peticiones HTTP. Ésto podría involucrar la recuperación de los resultados de una búsqueda, el acceso al registro del usuario EPerson actual, o actualizar el proceso de envío de un ítem. De acuerdo al resultado de este procesamiento el servlet tiene que decidir que página JSP decide mostrar. Entonces rellena los atributos correspondientes del objeto HttpRequest mediante el método setattribute() de la clase javax.servlet.http.httpservletrequest, objeto que es pasado dentro del servlet desde el Tomcat. Luego el servlet le da el control a la JSP a través del método JSPManager.showJSP(). Este método hace un forward() tradicional de servlets a la página solicitada. El Tomcat procesa la JSP y envía la página al cliente. En la parte superior de cada JSP, después de la licencia y el copyright, está documentado qué parámetros deben ser rellenados antes de llamar a la JSP, no hay validación, por lo que si no se cumple con estas precondiciones, es probable que ocurra un error en tiempo de ejecución, con lo que se mostrará la jsp de Error interno del sistema. Muchas jsp incluyen formularios (form) que tienen campos ocultos (hidden) que le informan a los servlets qué formulario ha sido rellenado. El servlet del envío de ítems, que controla el ingreso de metadatos, SubmissionController es un buen ejemplo de ésto. SubmissionController trabaja con formularios de entrada de diferentes jsp, es por ello que los campos hidden como step y page se usan para informarle al servlet cuál página de qué etapa ha sido completada. En la figura siguiente se visualiza el proceso que hemos terminado de describir: 117

122 Figura 38- Flujo de control durante el proceso de una petición HTTP fuente: Manual DSpace Etiquetas JSP personalizadas Todas las jsp de DSpace usan alguna etiqueta personalizada. Estas etiquetas están definidas en [dspace-src]/dspace-jspui/dspace-jspui-webapp/src/main/webapp/web- INF/dspace-tags.tld y sus correspondientes clases java residen en org.dspace.app.webui.jsptag. Se listan a continuación las etiquetas. layout: Esta etiqueta está en todas las jsp. Es la que construye la cabecera y el cuerpo HTML. Por ende todo el contenido de cualquier jsp está dentro de <dspace:layout> codigo </dspace:layout> sidebar: Esta etiqueta únicamente puede usarse una vez dentro de layout. Todo el código dentro de <dspace:sidebar> será colocado en forma de columna a la derecha de la página. date: Esta etiqueta sirve para mostrar en forma adecuada el contenido de un objeto DCDate. Incluye: Esta etiqueta es obsoleta, su uso es similar a <jsp:include> ítem: Esta etiqueta sirve para mostrar en pantalla a un objeto Item. Se muestran sus metadatos y los links a los Bitstreams. Se decidió mostrar un ítem mediante una etiqueta por dos motivos, primero porque es una tarea que se repite mucho dentro de la interfaz gráfica y segundo porque es una tarea que involucra más código que HTML. itemlist, collectionlist, communitylist: Estas etiquetas se usan para listar ítems, colecciones, y comunidades en forma de tablas. Se muestra 118

123 información reducida y se ofrece un link para ir a la información detallada del objeto en cuestión. popup: Esta etiqueta permite abrir una ventana adicional sobre la ventana de trabajo actual. Se aconseja tener activado javascript en el navegador del cliente. selecteperson: Esta etiqueta genera algo similar a un SELECT de HTML, es una lista de donde se puede elegir usuarios EPerson. sfxlink: Esta etiqueta muestra un link a un servidor SFX. Esta etiqueta requiere que se configure la propiedad sfx.server.url en el archivo de configuración dspace.cfg. Internacionalización (i18n) DSpace para mostrar texto internacionalizable, utiliza la JSTL 1.0 (Java Standard Tag Library). Esto le permite utilizar la etiqueta <fmt:message>. Esta etiqueta recibe un parámetro key. El texto mostrado resulta ser el valor de ese key, el cual está especificado en un archivo de diccionario. Veamos un ejemplo para entender como funciona: DSpace tiene un archivo llamado Messages.properties en [dspace-src]/dspaceapi/src/main/resources/. Este archivo contiene pares de clave = valor. Donde clave es pasado como parámetro a la etiqueta fmt:message. Supongamos que en el archivo aparece la línea: browse.menu.author = Autor Y tenemos una jsp que contiene la línea <fmt:message key= browse.menu.author /> Cuando se procese la jsp, dentro del HTML generado aparecerá la palabra Autor. Puede haber varios archivos Messages.properties con diccionarios en diferentes idiomas. Por ejemplo Messages_es.properties sería un diccionario de español, y Messages_es_AR.properties sería un diccionario español de Argentina. DSpace utilizará el idioma del diccionario que tenga configurado en default.locale dentro de su archivo de configuración. Proveedor de datos OAI-PMH DSpace soporta el protocolo OAI-PMH versión 2.0 como proveedor de datos, apoyándose en el framework OAICat del OCLC. Provee implementaciones de las interfaces AbstractCatalog, RecordFactory y Crosswalk, que utilizan la API de Gestión de Contenido y la API de Harvesting que se encuentra dentro de sistema de búsquedas. Por defecto está habilitado el formato básico de exportación, es decir oai_dc, que exporta los metadatos Dublin Core de los ítems. Ésto es trivial ya que los ítems cuentan con un formato nativo de metadatos Dublin Core. Mediante plugins Crosswalk se pueden extender los formatos de exportación. La clase que implementa el formato oai_dc es org.dspace.app.oai.oaidccrosswalk. Se pueden crear nuevos plugins en la carpeta [dspace-src]/dspace-oai/dspace-oaiapi/src/main/java/org/dspace/app/oai/. 119

124 Los distintos Crosswalk se puede habilitar o deshabilitar desde al archivo de configuración de OAICat en [dspace]/config/oaicat.properties como se muestra a continuación: Crosswalks.oai_dc = org.dspace.app.oai.oaidccrosswalk OAI expone las colecciones o comunidades como objetos set mediante el verbo ListSets. El control de flujo del protocolo se ve claramente cuando se tiene que satisfacer una consulta de numerosos registros. OAI no devuelve todos los registros de una sola vez. Lo hace de a tantas de MAX_RECORDS definido en DSpaceOAICatalog. Actualmente tiene el valor de 100, es decir que si el resultado de ListRecords supera los 100 registros, necesitara utilizar la conocida técnica de los Resumption Tokens, es decir tokens de reanudación. Cuando el proveedor de datos recibe un pedido que requiere devolver muchos registros, el proveedor devuelve los registros de a tandas parciales con un resumption token. Luego el recolector puede volver a solicitar otra tanda de registros mediante el token recibido en la tanda anterior. El token tiene un tiempo de vida, actualmente es de una hora. Para entender cómo funciona en la sección de Acceso Abierto en el protocolo OAI-PMH hay una ilustración del funcionamiento. Estructura de importación de Comunidades y Colecciones DSpace provee de un comando administrativo por línea de comandos, que permite importar estructuras de comunidades y colecciones definidas en archivos XML. La sintaxis es la siguiente: [dspace]/bin/structure-builder -f [archivo_xml] -o [xml_de_salida] -e [ del admin] El comando se loguea en el sistema con el del administrador, importa la estructura del archivo_xml y escribe en xml_de_salida la misma estructura con el atributo del handle en cada comunidad o colección. Ahora veremos un ejemplo de archivo_xml: <import_structure> <community> <name>nombre de la Comunidad</name> <description>texto descriptivo</description> <intro>texto introductorio</intro> <copyright>noticias sobre el copyright</copyright> <sidebar>texto de la barra lateral</sidebar> <community> </community> <collection> <name>nombre de la sub-comunidad</name> <community>...[y así repetidamente]... </community> <name>nombre de la Coleccion</name> <description>texto descriptivo</description> 120

125 </community> </import_structure> </collection> Y el archivo XML de salida sería: <import_structure> <intro>texto introductorio</intro> <copyright>noticias sobre el copyright</copyright> <sidebar>texto de la barra lateral</sidebar> <license>licencia especial</license> <provenance>información del a procedencia</provenance> <community identifier= /1 > repetidamente]... </community> </community> </import_structure> <name>nombre de la Comunidad</name> <description>texto descriptivo</description> <intro>texto introductorio</intro> <copyright>noticias sobre el copyright</copyright> <sidebar>texto de la barra lateral</sidebar> <community identifier= /2 > </community> <name>nombre de la sub-comunidad</name> <community identifier= /3 >...[y así <collection identifier= /4 > </collection> <name>nombre de la Coleccion</name> <description>texto descriptivo</description> <intro>texto introductorio</intro> <copyright>noticias sobre el copyright</copyright> <sidebar>texto de la barra lateral</sidebar> <license>licencia especial</license> <provenance>información del a procedencia</provenance> Una limitación es que actualmente no provee del mecanismo de exportación de la estructura. Importación y exportación de paquetes Entendemos por paquete a un archivo autocontenido comprimido con la información necesaria para representar a un Ítem dentro del repositorio. Los paquetes siguen un formato estándar interno y externo para garantizar su interoperabilidad y su uso 121

126 generoso afuera del repositorio. Además sirven como mecanismo para la compartición de información entre sistemas DSpace y otros sistemas. DSpace provee de una herramienta administrativa de línea de comandos para permitir importar y exportar paquetes. La sintaxis del comando se consulta de esta manera: [dspace]/bin/packager help. Este comando permite tanto ingerir (importar) un Ítem ya empaquetado desde su archivo y convertirlo en un Ítem del repositorio o diseminar (exportar) un ítem del repositorio y obtener un paquete que lo represente. Tanto el trabajo de importar como el de exportar paquetes lo realizan los plugins Packager del sistema que vimos anteriormente en la sección Plugins de la API de Gestion de Contenido. Lo plugins Packager se configuran en dspace.cfg de la siguiente forma: # Packager Export Plugins: plugin.named.org.dspace.content.packager.packagedisseminator = \ org.dspace.content.packager.dspacemetsdisseminator = METS # Packager Import Plugins: plugin.named.org.dspace.content.packager.packageingester = \ org.dspace.content.packager.pdfpackager = Adobe PDF, PDF, \ org.dspace.content.packager.dspacemetsingester = METS Importando La sintaxis del comando para importar es la siguiente: [dspace]/bin/packager -e user -c handle -t packager path Donde el user es la dirección de de la EPerson que desea realizar la operación, handle es el identificador persistente de la colección en la cual se desea colocar el ítem, packager es el nombre del plugin (ingester) según el archivo de configuración, y path es la ruta al archivo del paquete a importar o - si se toma de la entrada estándar. Exportando La sintaxis del comando para exportar es la siguiente: [dspace]/bin/packager -e user -d -i handle -t packager path Donde el user es la dirección de de la EPerson que desea realizar la operación, handle es el identificador persistente de la colección en la cual se desea colocar el ítem, packager es el nombre del plugin (disseminator) según el archivo de configuración, y path es la ruta y el nombre del archivo del paquete a crear o - si se imprime en la salida estándar. Se provee soporte para paquetes METS, tanto en importar como exportar. Más información en 122

127 Importación y exportación de Items DSpace brinda herramientas para la importación y exportación de Items en modo batch o por lotes. Ésto es útil para copiar colecciones de una instancia de DSpace a otra por ejemplo. Para tales tareas se define un formato de archivo/directorio conocido como Simple Archive format. Veámoslo. Formato Simple de Archivo La idea de este formato es contener dentro de un directorio los Items exportados. La estructura de directorios creada implica contener dentro de un directorio, numerosos subdirectorios, que representan a cada ítem y en cada uno de ellos los archivos pertenecientes a ese Ítem. archive_directory/ item_000/ dublin_core.xml (Metadatos Dublin Core Calificado) metadata_[prefijo].xml (Metadatos en ) contents (Mapeo de Bitstreams - Bundles) file_1.doc (Archivos a agregarse como Bitstream) file_2.pdf ( ) item_001/ dublin_core.xml contents file_1.png... El formato de los archivos de metadatos tiene la siguiente sintaxis: <dublin_core> <dcvalue element="title" qualifier="none">titulo</dcvalue> <dcvalue element="date" qualifier="issued">1990</dcvalue> <dcvalue element="title" qualifier="alternate" language="en">title</dcvalue> </dublin_core> Aunque se prevé que se incorporen otros esquemas de metadatos, el formato sigue siendo un esquema plano, produciendo confusión, por ejemplo que para el esquema X dentro del archivo metadata_x.xml se tengan que utilizar etiquetas como <dublin_core>, <dcvalue>, etc. Si se crea un nuevo esquema de metadatos por ejemplo ETD se tiene que especificar el parámetro schema de la etiqueta dublin_core. Por ejemplo el archivo metadata_etd.xml: <dublin_core schema="etd"> <dcvalue element="degree" qualifier="department">computer Science</dcvalue> <dcvalue element="degree" qualifier="level">masters</dcvalue> 123

128 <dcvalue element="degree" qualifier="grantor">texas A & M</dcvalue> El archivo contents contiene una lista de archivos incluidos en el directorio. En este se especifica un archivo por línea, se puede especificar el bundle al que pertenece en el objeto Item. Si no se especifica \tbundle:[bundle_name] después del nombre del archivo en cada línea, se asume que ese archivo pertenece al bundle ORIGINAL. Importando Ítems La utilidad para importar se encuentra org.dspace.app.itemimport.itemimport, y se ejecuta con el comando [dspace]/bin/import. Con la opción h se obtiene una lista de parámetros y ayuda. Este comando funciona tanto con el ID interno o el de la EPerson que intenta importar. Con esta herramienta se pueden agregar, quitar y reemplazar Items de una colección del sistema. Se puede especificar más de una colección, en ese caso la primera colección especificada será la propietaria de dicho Ítem y las restantes contendrán un mapeo del item. Si ocurrió un error al agregar se puede intentar resumir desde el último intento. Para agregar un ítem se usa la siguiente sintaxis: [dspace]/bin/import -a -e joe@user.com -c collectionid -s items_dir -m mapfile Donde a indica que es una operación de agregar, -e especifica el del usuario que realiza la operación, -c especifica el handle o ID de la colección o colecciones donde se desea agregar el ítem, s especifica la ruta que contiene los archivos de los ítems en el formato especial de DSpace, por último m especifica el nombre del archivo mapa que registrara detalles útiles, que luego pueden ser usados para quitar del archivo un ítem importado. Para ejecutar este desimportar se necesita invocar: [dspace]/bin/import --delete --mapfile=mapfile Donde mapfile es el nombre del archivo creado en el proceso de importar. Se puede también reemplazar los ítems importados por otros sin perder el handle original. Ésto se logra con el mapfile creado al importar la primera vez. Luego se invoca: [dspace]/bin/import --replace --eperson=joe@user.com --collection=collectid --source=items_dir --mapfile=mapfile También se puede realizar una comprobación del directorio fuente, invocando al parámetro -test. Ésto no realiza ningún cambio en el sistema y es útil para validar si son correctos los archivos fuente. Por defecto el comando importar saltea cualquier flujo de trabajo asociado a una colección. Para desactivar esta opción se necesita agregar el parámetro -workflow. Exportando Ítems El exportador de ítems puede exportar un Ítem o una colección de ítems, y crea una estructura de directorios respetando el formato Simple Archive Format. Para exportar una colección se invoca: 124

129 [dspace]/bin/export --type=collection --id=collid --dest=dest_dir -- number=seq_num La palabra COLLECTION indica que se solicita exportar todos los ítems de una colección. La colección a exportar está indicada por su handle o su collid, la ruta a la carpeta donde se guardaran los archivos está indicada por dest_dir y seq_num indica el número de secuencia inicial para nombrar a la primer carpeta del primer ítem. Si se especifica un valor de 3, los ítems estarán contenidos en carpetas llamadas 3, 4, 5, y así sucesivamente. Si se desea exportar un único ítem la sintaxis es: [dspace]/bin/export --type=item --id=itemid --dest=dest_dir --number=seq_num Con la misma semántica de los parámetros que cuando se requiere exportar una colección. Después de haber realizado la exportación, dentro de cada carpeta de cada ítem, habrá un archivo de texto llamado handle, el cual contiene el handle de dicho ítem. Esto es para que cuando se importen los ítems en otra instancia retengan el mismo identificador persistente y que no existan idénticos objetos con distinto identificadores. En el siguiente apartado trataremos la migración de ítems de un sistema DSpace a otro. Transferencia de Items entre instancias DSpace: Ahora veremos una herramienta útil en el caso que se desee transferir un Item o una colección de ítems de una instancia DSpace de prueba a una de producción por ejemplo La herramienta es un script de línea de comandos que utiliza el comando *N*X (Linux/unix) sed. La sintaxis es la siguiente: [dspace]/bin/dspace_migrate <exported item directory> Lo que hace este script es recibir por parámetro un directorio conteniendo subdirectorios con los archivos de los ítems. Inspecciona cada subdirectorio y elimina los archivos handle y modifica los archivos de metadatos Dublin Core Calificado dublin_core.xml eliminando las entradas con metadatos que son automáticamente creados por la herramienta importar. Esto es importante recordarlo, porque esta herramienta está destinada a ser usada antes de invocar al comando importar. Los metadatos que elimina del archivo de metadatos son los siguientes: date.accessioned (fecha de envío). date.available (fecha de publicacion). date.issued (fecha de publicación o distribucion). description.provenance (historial de cambios sobre el ítem). format.extent (tamaño o duración). format.mimetype (identificador MIME). identifier.uri (URI del item). Alguien con intenciones de migrar ítems entre instancias de DSpace tendría que realizar la siguiente secuencia de operaciones: export -> dspace_migrate -> import 125

130 Herramientas METS DSpace realizó un esfuerzo por exportar sus Items en un formato más estándar que su formato interno. Es por esto que está desarrollando una herramienta experimental de exportación basada en el estándar METS (Metadata Encoding and Transmission Standard). METS es el estándar de empaquetado, los metadatos internamente se codifican siguiendo el estándar MODS. Para más información vea los anexos METS y MODS. Para invocar la herramienta por línea de comandos: Si se desea exportar un ítem: [dspace]/bin/dsrun org.dspace.app.mets.metsexport --item [handle] Si se desea exportar una colección: [dspace]/bin/dsrun org.dspace.app.mets.metsexport --collection [handle] Si se desea exportar todo el repositorio: [dspace]/bin/dsrun org.dspace.app.mets.metsexport --all Si no se especifica -destination = directory se usa el directorio actual para generar el paquete AIP. Un ejemplo de la estructura de directorios que se genera es: hdl%3a %2f8/ mets.xml -- METS metadata 184BE84F bitstream 3F9AD0389CB FB82113C32D Actualmente esta herramienta es obsoleta. El paquete generado no es AIP. No existe una herramienta para importar paquetes AIP METS. No existe la sección strucmap, algunos metadatos técnicos no se escriben, y el mapeo de DC a MODS es muy simple, necesita verificaciones. Filtros Multimedia DSpace cuenta con una interesante característica, que permite modificar los contenidos de los Items para generar nuevos contenidos. Esto es filtrar los bitstreams para conseguir nueva información o nuevos bitstreams. Esto por ejemplo se ve reflejado en la generación de imágenes en miniatura de las imágenes, la extracción de texto de ciertos tipos de bitstreams. Lo importante del concepto es la aplicación de procesos sobre los bitstreams, para obtener información necesaria para brindar otras funcionalidades. A los encargados de realizar estas tareas de procesamiento, los denominamos filtros. La clase que controla los filtros es org.dspace.app.mediafilter.mediafiltermanager, la cual atraviesa el almacén de bitstreams o recursos, invocando sobre los mismos a las clases MediaFilter o FormatFilter. En el archivo de configuración bajo la clave filter.plugins se listan los filtros MediaFilter y FormatFilter habilitados. Por ejemplo: filter.plugins = \ PDF Text Extractor, \ 126

131 PDF Thumbnail, \ HTML Text Extractor, \ Word Text Extractor, \ JPEG Thumbnail, \ Branded Preview JPEG El sistema de filtros multimedia, está pensado para ser ejecutado a través de la línea de comandos, periódicamente, como ya vimos en otros comandos, mediante herramientas de planificación de tareas a nivel de sistema operativo, como por ejemplo cron. El comando simplemente llama a MediaFilterManager y es el siguiente: [dspace]/bin/filter-media Si no se agregan parámetros, recorre todos los bitstreams (archivos), salteando aquellos que ya han sido filtrados, y a cada uno le aplica todos los filtros habilitados. Con la opción f se fuerza a que se procesen todos los bitstreams sin importa si ya han sido filtrados. Con la opción i se limita la aplicación a una comunidad, a una colección o un ítem especificado. Con la opción m se especifica un máximo de bitstreams a procesar. Con la opción n no se crean los índices de búsqueda a texto completo por ejemplo Con la opción p se especifica cual o cuales filtros se van a aplicar únicamente. Con la opción s se permite definir un rango de handles a saltear Con la opción v se imprime en pantalla detalles de la info. extraída por el filtro. Se pueden crear filtros personalizados implementando la interfaz java org.dspace.app.mediafilter.formatfilter. Estadísticas DSpace provee de un paquete de estadísticas limitado, que puede ser usado para ver un resumen de las actividades principales del sistema, como por ejemplo búsquedas, visualizaciones de ítems, errores, ingresos (logueos), etc. El sistema de estadísticas está basado en el análisis de los logs generales de DSpace. Existe una clase que realiza el procesamiento sobre éstos. Este procesamiento está dividido en dos etapas. En la primera etapa se extrae información estadística de los archivos de log buscando patrones de texto conocidos dentro de ellos. Luego esta información se escribe en archivos de texto que son utilizados en la segunda etapa. La segunda etapa es la que genera los archivos HTML con los datos obtenidos de la primera etapa. La clase org.dspace.app.statistics.createstatreport realiza el trabajo, y es llamada desde los scripts: [dspace]/bin/stat-[initial monthly general] en la primera etapa y luego desde [dspace]/bin/stat-report-[initial monthly general] en la segunda. CreateStatReport lee los logs del directorio log.dir especificado en el archivo de configuración dspace.cfg. También lee la propiedad report.dir para saber donde escribir los reportes HTML con la información estadística, para que sean accedidos por los usuarios de la interfaz JSPUI. 127

132 log.dir por defecto es [dspace]/log/ report.dir por defecto es [dspace]/reports/ Actualmente esta herramienta de estadísticas no permite internalizaciones. Las estadísticas están en inglés. Las estadísticas pueden ser consultadas públicamente si se modifica la propiedad report.public = false en el archivo de configuración. El paquete de estadísticas viene con un archivo de configuración, [dspace]/config/dstat.cfg. Este archivo contiene ajustes que pueden modificarse: Ajustes start.year y start.month general.summary exclude.word exclude.type exclude.character item.type item.floor y search.floor item.lookup user. Descripción Año y mes que se inician las estadísticas Lista de actions del log de Dspace que se quieren mostrar en la sección Overview. No hay que cambiarlo a menos que sea necesario Palabras filtradas fuera de los términos de búsqueda en las estadísticas Índices de los términos de búsqueda de Lucene filtrados fuera de las estadísticas (corresponde a los índices de búsqueda). Caracteres especiales de Lucene filtrados fuera de las estadísticas Tipos de ítems para los que se requieren estadísticas. Corresponde a los valores de los formularios definidos en el campo dc.type, o algún campo de metadatos con un elemento llamado type. Especifica un número mínimo de accesos necesarios de un ítem para que sea contabilizado. Y numero mínimo de veces que un ítem resultó buscado se incluya en las estadísticas Especifica el número máximo de ítems de la lista con información Autor/Titulo para las estadísticas Especifica cuando se mostrará el del usuario en las estadísticas de login. Por privacidad, su valor por defecto es false (es decir, no mostrar el ). Otro archivo de configuración que encontramos es [dspace]/config/dstat.map en el cual encontramos un mapeo entre los nombres de las acciones contabilizadas en las estadísticas y un texto descriptivo de cada una. Por ejemplo: browse_title = Browse By Title Este archivo se puede modificar para adaptar los textos a otro idioma que no sea el inglés por ejemplo. Para generar las estadísticas se necesita la ejecución periódica de los scripts, y de esta manera tener la información actualizada. Es por ello que se necesita programar la ejecución periódica de estos comandos poniéndolos en la configuración de las herramientas del sistema operativo para la programación de tareas y procesos, como ya hemos visto anteriormente. 128

133 El orden de la ejecución de los scripts es importante. Primero se ejecuta el script stat- [tipo] y luego el stat-report-[tipo] donde tipo puede ser: inicial (estad. iniciales), monthly(estad. mensuales) o general(estad. generales). El equipo de desarrollo de DSpace planea mejorar el sistema de estadísticas actual en las versiones futuras. Gestión de subcomunidades DSpace provee una herramienta de línea de comandos para asociar o desasociar comunidades y subcomunidades. Con esta herramienta se pueden asignar subcomunidades a comunidades, o quitar subcomunidades a una comunidad, o una combinación de ambas operaciones que permita mover una comunidad dentro de otra. Esta herramienta no suele ser muy utilizada debido al carácter poco cambiante de las comunidades y subcomunidades. Pero en versiones anteriores donde no se permitían subcomunidades, se creó esta utilidad para crear esos vínculos jerárquicos entre las comunidades. Para agregar una subcomunidad a una comunidad se invoca: dsrun org.dspace.administer.communityfiliator -s -p padreid -c hijoid Para quitar una subcomunidad de una comunidad se invoca: dsrun org.dspace.administer.communityfiliator -r -p padreid -c hijoid Es importante aclarar que el concepto de comunidad huérfana existe. No se elimina la comunidad únicamente se le quita su padre. Las comunidades de primer nivel, son huérfanas porque no dependen de ninguna otra comunidad, ellas son la raíz del árbol de comunidades, subcomunidades y colecciones Modelo de objetos Hemos nombrado muchas veces que DSpace contiene objetos de primera clase, almacena objetos, administra recursos, etc. Nos estamos refiriendo indirectamente al modelo de datos u objetos que forma parte del modelo esencial del sistema. Este modelo está implementado en la capa media. DSpace intenta que su estructura de datos, se relacione con la estructura de la organización que emplea el sistema. Cada sitio está dividido en Comunidades, que a su vez pueden dividirse en subcomunidades. Reflejando así una estructura típica de universidades, colegios, con departamentos, centros de investigación o laboratorios. Las Comunidades contienen Colecciones, que son contenidos agrupados relacionados entre sí. Una colección puede aparecer en más de una Comunidad. Cada Colección está compuesta de numerosos Items, que son los elementos básicos como unidad semántica de almacenamiento. Cada elemento tiene una y sólo una colección propietaria. Un ítem puede aparecer en más de una colección, aunque sólo una será su dueña. Los ítems contienen Bitstreams, que son los archivos de recursos. Los Bitstreams se agrupan en Bundles, o grupos de archivos relacionados. La mayoría de los ítems tienden a tener los siguientes bundles de nombre: ORIGINAL: en este grupo o fajo, se agrupan los archivos enviados por el usuario. 129

134 THUMBNAILS: en este bundle se ponen las imágenes en miniatura de las imágenes del bundle anterior. TEXT: en este bundle se extrae el texto de los archivos de texto del bundle ORIGINAL, para indexar a texto completo LICENSE: en este bundle se almacena la licencia de la organización que el usuario acepto. CC_LICENSE: en este bundle se almacena la licencia para la distribución del ítem. Es una licencia Creative Commons. Cada Bitstream se asocia con un Formato de Bitstream. Se requiere tener una identificación de los formatos soportados por el sistema para tratarlos de manera diferente en el momento de la presentación al usuario. Cada Formato de Bitstream cuenta con un nivel de soporte por parte del sistema, que indica el grado en que la institución dará soporte a ese tipo de archivo en el futuro. Por ejemplo el MIT Libraries usa estos tres niveles: Soportado Conocido No soportado El formato es reconocido y la institución está segura que puede almacenar archivos con este formato, usando cualquier combinación de técnicas (migración, emulación, etc.) es apropiado dado el contexto de necesidad. El formato se reconoce y la institución promete almacenarlo como está y permitir que sea recuperado. La institución intentará obtener información para lograr que este formato en el futuro sea Soportado. El formato no se reconoce pero la institución se compromete a almacenarlo como es y permitir su acceso para su recuperación. Cada ítem tiene un registro de metadatos Dublin Core calificado. Estos metadatos son ingresados por los usuarios quienes envían el contenido al repositorio o pueden obtenerse a partir de otros metadatos mediante un proceso de importación de ítems. Los ítems pueden eliminarse de dos maneras: pueden ser retirados (withdrawn), lo que implica que no son eliminados físicamente, pero no pueden verse ni accederse. Si se intentara acceder a un ítem retirado, se mostrará una indicación. Los ítems retirados pueden ser restituidos por el administrador del sistema. pueden ser expulsado del repositorio definitivamente, eliminándolos del archivo físico. Objeto Comunidad(Community) Colección(Collection) Ítem(Ítem) Fajo(Bundle) Archivo(Bitstream) Formato(Bitstream Format) Ejemplo Laboratorio de Ciencias de la Computación, Centro de Investigación Oceanográfico Tesis, Revistas, Estadísticas Un reporte técnico, un conjunto de datos con información descriptiva, un video de una lectura Un grupo de archivos HTML e imágenes que conforman un sitio Web Un archivo HTML, un archivo de imagen, un archivo de código fuente Microsoft Word Versión 6.0, JPEG, GIF, MP3 130

135 Figura 39 Modelo de objetos fuente: Manual DSpace Directorios y Archivos En este apartado veremos como se utiliza el sistema de archivos para desplegar la estructura. Anteriormente en el capítulo de instalación del sistema ya vimos un adelanto de que estructura de directorios tenía. Luego en la sección del Análisis de los módulos del sistema vimos un poco más de cerca la estructura de directorios del código fuente. Ahora veremos en detalle la estructura física del sistema. DSpace una vez instalado completamente en el servidor, cuenta con tres estructuras o árboles de directorios bien diferenciados. Directorio Fuente: en este directorio se encuentran todos los archivos fuente del sistema. Los archivos de configuración que se encuentran en este árbol sólo se utilizan hasta el momento de la instalación. Luego de la instalación, se utilizan los archivos de configuración copiados al Directorio de instalación. Este directorio se conoce como [dspace-src] Directorio de instalación: este directorio se crea durante la instalación del sistema y durante la ejecución del mismo va sufriendo modificaciones. Contiene archivos de configuración, herramientas de línea de comandos, quizás contenga los Bitstreams. Este directorio se conoce como [dspace] Directorio de despliegue Web: este directorio se despliega cuando el contenedor Web, como por ejemplo Tomcat, descomprime los archivos *.war. Estos archivos war contiene las aplicaciones Web, como por ejemplo 131

136 La interfaz Web JSP, la interfaz Web XML(Manakin), la interfaz OAI-PMH, la interfaz LNI, la interfaz SWORD, etc. Se conoce como [tomcat]/webapps Directorio de Instalación Figura 40 Directorio de instalación de DSpace fuente propia Directorio de Código Fuente Veremos el directorio [dspace-src]/dspace: Figura 41 Directorio de código fuente propia 132

137 Directorio de despliegue Web Veremos la estructura de las dos interfaces gráficas: JSPUI y XMLUI. Figura 42 jspui fuente propia Figura 43 xmlui fuente propia 133

138 Logs Un archivo de log es un archivo de texto, con información útil para el sistema y para el administrador del mismo, cuando ocurre un error o un comportamiento del sistema inesperado. Desde que DSpace utiliza herramientas y frameworks de terceros, se ha incrementado la cantidad de archivos de log. El directorio de logs por defecto del sistema es [dspace]/loos. En la siguiente tabla mostramos los archivos de logging habituales. Archivo de Log [dspace]/log/dspace.log [tomcat]/logs/catalina.yyyy-mm-dd.log [tomcat]/logs/[nombre_host].yyyy-mm-dd.log [tomcat]/logs/stdout_yyyymmdd.log [dspace]/log/cocoon.log [dspace]/log/checker.log [dspace]/log/handle-plug.log [dspace]/log/handle-server.log [dspace]/handle-server/error.log Qué hay en él? Archivo principal de log del sistema. Aquí están los eventos y errores del sistema. Se puede controlar la verborragia de este archivo editando [dspacesrc]/dspace/config/log4j.properties, luego ant init_configs. Archivo que contiene la salida estándar por consola de la aplicación Catalina que es el contenedor de servlets del Tomcat. Información del estado del servidor y las aplicaciones que se están ejecutando. Salida estándar de las aplicaciones Web en el host en un día mes y año específicos Archivo con información sobre los sucesos y errores de Cocoon, parte central de la interfaz XMLUI. Resultados del proceso [dspace]/bin/checker. Aparecen en este archivo los bitstreams que han sido alterados. Errores del plugin de DSpace para la resolución de handles. Errores ocurridos en el servidor de handles CNRI antes de llamar al plugin de DSpace. Errores ocurridos en el CNRI Handle Server FUNCIONALIDADES Luego de recorrer el sistema DSpace por dentro y analizar el cómo se realizan las funciones, veremos un resumen de las funcionalidades Almacenamiento DSpace utiliza el sistema de archivos del servidor o un SRB (Storae Resource Broker) para almacenar los contenidos. Lo que lo hace sumamente flexible, pudiendo 134

139 almacenar cualquier cantidad de archivos, tamaños muy grandes inclusive (hasta 512Mb) Identificadores Para permitir que las referencias, las citas de los materiales e investigaciones que hay a lo largo de Internet, sean perdurables en el tiempo, confiables, DSpace utiliza un sistema de asignación de identificadores persistentes a sus ítems, colecciones y comunidades. Ésto favorece el intercambio de información y la disponibilidad a través del tiempo, evitando links rotos. Para este fin, DSpace se apoya en el sistema de Handles del CNRI. Para tal fin cada sitio DSpace necesita registrarse en la página del sistema Handle CNRI para obtener un prefijo que será parte de cada identificador de los ítems, colecciones y comunidades del sitio. El sistema provee un mecanismo de resolución de identificadores, puesto que cualquiera escribe un identificador y automáticamente accede al recurso. Para tal fin cada sitio DSpace deberá ejecutar un servidor que resuelva los handles locales, así cualquiera que necesite acceder a los recursos almacenados sabrá cómo hacerlo. Los handles se escriben de dos maneras: hdl: / DSpace se encarga de mantener la asociación de la última parte del handle con el contenido relacionado. La asociación entre la instancia DSpace y el sistema Handle es a nivel de sitio únicamente. Los Bitstreams también tienen un identificador persistente y este es el sequence_id o número de secuencia que es único para cada bitstream por ítem. Es mucho más volátil que el handle del ítem al cual pertenece. Este identificador queda obsoleto si el contenido se cambia de servidor u organización. Por ejemplo se pueden acceder a los bitstreams con la siguiente URL: dspace url/bitstream/handle/sequence ID/filename Metadatos Se registran tres tipos de metadatos del contenido almacenado: Metadatos descriptivos DSpace puede soportar múltiples esquemas planos de metadatos para la descripción de un ítem. Por defecto se provee el estándar Dublin Core Calificado. Este esquema viene preconfigurado en el código fuente, pero para describir a un ítem pueden agregarse otros esquemas y realizar un mix de metadatos. En la base de datos se almacena información descriptiva de las comunidades y colecciones, como por ejemplo el nombre, una descripción en prosa, etc Metadatos administrativos Metadatos administrativos son metadatos relacionados con el funcionamiento del sistema, la preservación de los ítems, las políticas de autorización. La mayoría de estos datos reposan en la base de datos. Los metadatos de la proveniencia de un ítem, y su historial, son almacenados en un campo Dublin Core (dc.provenance). 135

140 Otros metadatos que son almacenados en campos DC son el tamaño de los bitstreams y su tipo MIME Metadatos estructurales Estos metadatos incluyen información de cómo mostrar un ítem o su contenido a un usuario. Es muy básica la información estructural que cuenta DSpace. Por ejemplo la constitución de los bundles, la organización de los bitstreams dentro de ellos. Los bitstreams tienen un sequeceid que los identifica unívocamente dentro de un ítem. Este metadato se usan para crear identificadores persistentes de un bitstream Búsquedas y Navegación DSpace permite a los usuarios finales del sistema encontrar el material requerido de varias maneras: Se puede acceder al contenido a través de un handle. Se puede acceder al contenido buscando palabras clave en los metadatos o en el contenido de los ítems, mediante la indexación a texto completo. Se puede acceder al contenido navegando por distintas comunidades y colecciones. Listando los contenidos por autor, título, palabras clave, fechas, etc. El sistema de búsquedas en DSpace se apoya en el conocido motor de búsquedas Apache Lucene, que mantiene los índices y realiza las consultas para obtener resultados Publicación El proceso de publicación de un ítem en el sistema no es trivial y atraviesa varios pasos. Este proceso puede iniciarse de dos maneras: el administrador por medio del importador de paquetes decide ingresar al sistema un paquete externo SIP (Submission Information Package), o bien un usuario registrado decide enviar un contenido a una colección determinada usando la interfaz Web. Figura 44- Proceso de publicación de un ítem fuente: Manual DSpace Si se opta por la interfaz Web se deben completar los metadatos correspondientes. Luego el SIP se transforma en un objeto del sistema (IPS) y empieza a transitar el flujo de trabajo. Dependiendo de las propiedades de la colección de destino, este proceso será más o menos largo. En este proceso de workflow el contenido es 136

141 revisado en etapas que se pueden ver en la imagen de abajo. Usuarios con privilegios autorizados a realizar los controles decidirán si es adecuado el contenido al repositorio o no. Si es afirmativo deciden enviar al IPS al siguiente paso o etapa. Sino se le envía un al depositante indicándole la razón por la cual no se le aprueba el envío. Figura 45 - Proceso de workflow fuente: Manual DSpace Luego de pasar por todas las etapas el IPS (Item en progreso de envío) es archivado definitivamente y obtiene un identificador persistente o handle y se indexa para ser encontrado en las búsquedas Plugins El Gestor de Plugins o PluginManager es un contenedor de componentes o plugins muy simple. Crea y organiza los plugins y ayuda a elegir el plugin en los casos donde hay muchas opciones. Un plugin es una clase java que cumple determinada interfaz. El consumidor busca el plugin preguntando por su interfaz. Son intercambiables porque puede haber varias clases que implementen la misma interfaz. El filtrador multimedia es un ejemplo de implementación de plugins. Es un buen aspecto de diseño, el contar con la posibilidad de extender el sistema por medio de plugins. Los dos tipos de plugins más utilizados son: Packager plugins Los packagers son módulos de software que traducen un ítem en una representación externa o paquete y viceversa. Hay dos tipos de packagers los Ingesters y los Disseminators. Ingesters: Los ingesters traducen un paquete en un Item de DSpace. Disseminators: Los disseminators traducen un Item en un paquete. Un paquete es típicamente un archivo zip, que incluye un archivo manifest o manifiesto con información acerca del paquete y su contenido. Un estándar de paquete puede ser IMS Content Package, o METS. Un paquete también puede ser un único archivo multimedia conteniendo metadatos. Tanto los ingesters como los disseminators son un tipo de Plugin con nombre. No es necesario contar con ambos para un tipo de paquete determinado. Puede ser necesario contar sólo con uno de ellos. 137

142 Es muy típico de los Packagers apoyarse en otro tipo de plugins como lo son los Crosswalks. La tarea de los Crosswalks es similar, pero a nivel de metadatos. Realizan una traducción a nivel de estándares, ya no de empaquetado sino de metadatos. Es decir un plugin puede llamar a otro sin problemas Crosswalk plugins Los Crosswalk son módulos de software que traducen los metadatos internos de DSpace en una representación XML externa. Existen dos tipos de crosswalk: Ingesters: Los ingesters traducen un esquema de metadatos externo en un esquema de metadatos interno empleado por los Item de DSpace. Disseminators: Los disseminators traducen los metadatos internos de un Item en un esquema externo XML. Por ejemplo un ingester MODS traduce un esquema de metadatos MODS en un esquema Dublin Core de un Ítem. Y un disseminator MODS crea un documento MODS a partir de los registros de metadatos Dublin Core de un Ítem. Los Crosswalks son plugins con nombre, y es muy sencillo agregar nuevos plugins de este tipo. Ocurre lo mismo que con los packagers, no es necesario implementar ambos tipos de crosswalks. Puede ser suficiente tener o un ingester o un dissemiantor para un esquema de metadatos determinado. Por ejemplo puede que me interese exportar los metadatos en MODS, pero no me interese importarlos. Tanto los packagers como la aplicación de OAI-PMH utilizan los Crosswalk para obtener metadatos Autenticación y Autorización DSpace utiliza dos conceptos clave para la autenticación y la autorización. Para ello define dos entidades principales en el sistema: EPerson y Group. Cada usuario registrado del sistema es representado por un objeto EPerson. Cada EPerson tiene una lista de Group a los que pertenece. Para realizar ciertas tareas se requiere el ingreso o logueo de un usuario al sistema. Esta autenticación se realiza con los datos de la EPerson almacenados en la base de datos. Una vez autenticado el usuario dentro del sistema, para realizar las distintas operaciones necesita obtener una autorización, es decir tiene que cumplir con la política de autorizaciones. Esto se define por grupos, Los grupos son conjuntos de usuarios, con lo que una acción en el sistema está permitida para ciertos grupos. La autenticación está implementada de manera stackable es decir se apilan los mecanismos o métodos de autenticación o logueo. Ésto permite ir probando de uno en uno cada mecanismo hasta que alguno termina con éxito. Esto es muy útil para autenticaciones implícitas, por medio de certificados de confianza, etc. Se separa la autenticación de la interfaz del usuario Web, permitiendo abstraer la autenticación, haciéndola más flexible para otros usos. Las autorizaciones están implementadas en un sistema de mapeo de acciones con objetos y la lista de Eperson que pueden realizarlas. 138

143 Por ejemplo estas son las acciones aplicables (a) a los objetos de primera clase del sistema: Acción/Objeto Comunidad Colección Item Bundle Bitstream ADD/REMOVE a a a a - DEFAULT_ITEM_READ - a DEFAULT_BITSTREAM_READ - a COLLECTION_ADMIN - a READ/WRITE - - a - a DEFAULT_ITEM_READ y DEFAULT_BITSTREAM_READ de una colección son heredadas por los respectivos objetos de dicha colección como READ Suscripciones Una utilidad interesante para los usuarios registrados es la capacidad de registrarse en determinadas colecciones, con el fin de enterarse vía correo electrónico cuando se han depositado nuevos ítems en dichas colecciones. Se puede excluir de las subscripciones para dejar de recibir notificaciones por . Otra alternativa a las suscripciones son las sindicaciones RSS Suma de comprobación El administrador del sistema posse la capacidad de reconocer cambios en los archivos depositados. Esto es a través de un proceso constante de revisión. Se le envía notificación por si ocurre alguna anomalía Sindicación (RSS) DSpace provee la funcionalidad de brindar novedades en sus colecciones a través de feeds RSS. Ésto permite que con cualquier lector de RSS se puedan ver los nuevos ítems en determinadas colecciones de interés para una persona, usuaria o no del sistema DSpace. Ésto permite globalizar los contenidos, abriendo el repositorio al mundo Creative Commons Se provee la alternativa de adjuntar licencias Creative Commons a los ítems almacenados. Esta opción está deshabilitada por defecto, pero si se habilita se puede elegir una licencia CC, en el proceso de llenado de metadatos. Se accede a la página de CC para elegir la licencia Importar y Exportar DSpace permite importar y exportar paquetes de contenidos mediante herramientas administrativas por línea de comandos únicamente. Actualmente no permite importar ni exportar paquetes por interfaz gráfica. Lo que el sistema permite es exportar ítems, colecciones y comunidades (en formato nativo o simple archive format) a través de la interfaz gráfica. Actualmente en la interfaz gráfica se pueden ver dos acciones similares: exportar y migrar. Exportar incluye todos los metadatos de los ítems y su 139

144 handle. Migrar en cambio excluye ciertos metadatos que son conflictivos a la hora de importar ítems en otro sistema DSpace Estadísticas Existen diversas estadísticas sobre el uso y los contenidos del sistema. Se realizan por medio del análisis de los logs del sistema. Se pueden personalizar las acciones o actividades a contabilizar en la sección Resumen, que se encuentra en la parte superior del reporte estadístico. Estas estadísticas generales pueden incluir: ítems visitados, colecciones visitadas, comunidades más visitadas, cantidad de peticiones OAI, etc. El reporte incluye datos sobre: estadísticas sobre el archivo de contenidos, ítems más visualizados, actividades del sistema, navegaciones, búsquedas, importaciones, exportaciones, ingresos, errores, etc. Estas estadísticas pueden visualizarse en resúmenes mensuales, y según esté configurado el sistema, pueden verse públicamente o únicamente el administrador tiene acceso a ellas Recolección (OAI) Este servicio adicional permite poner a disposición de otros servicios, sus contenidos. DSpace se convierte en un proveedor de datos. DSpace utiliza el Framework OAICat para implementar el protocolo OAI-PMH ESTÁNDARES Y PROTOCOLOS Metadatos (DC) DSpace utiliza el estándar Dublin Core Calificado para almacenar los metadatos de los ítems. Durante la instalación del sistema el esquema se crea estáticamente en un archivo XML ([dspace]/config/registries/dublin-core-types.xml). Aquí una descripción del esquema: Elemento contributor coverage creator date identifier description format language publisher relation rights source subject Calificador advisor author editor illustrator other spatial temporal accessioned available copyright created issued submitted citation govdoc isbn issn sici ismn other uri abstract provenance sponsorship statementofresponsibility tableofcontents uri extent medium mimetype iso isformatof ispartof ispartofseries haspart isversionof hasversion isbasedon isreferencedby requires replaces isreplacedby uri uri uri classification ddc lcc lcsh mesh other 140

145 Elemento title Calificador alternative SWORD DSpace cumple con el estándar SWORD (Simple WebService Offering Repository Deposit), permitiendo que clientes de distinta naturaleza, puedan depositar ítems utilizando este protocolo. El estándar de paquetes soportado por defecto por el servidor SWORD es METS y los metadatos contenidos pueden ser DC o MODS LNI DSpace provee de una interfaz LNI del tipo WebService para exponer su API a aplicaciones nuevas no java, a aplicaciones que implementan su propia interfaz con el usuario y se sirven únicamente del engine o motor de DSpace para utilizar sus funcionalidades. En este módulo de software opcional, DSpace emplea estándares para la comunicación subyacente. Estos estándares son WebDAV y SOAP. Esta interfaz está orientada a usuarios desarrolladores y no a los usuarios finales del sistema DSpace OAI-PMH Como su nombre lo indica, DSpace mediante este módulo adicional de software, provee de una interfaz para la recolección de metadatos de los contenidos del sistema. Esta interfaz Web, implementa el protocolo OAI-PMH, que suelen usar los proveedores de servicios para difundir los contenidos de una red de repositorios. En este ámbito DSpace se comporta como un proveedor de datos. 4.3 ALCANCES DEL PROYECTO Después de un análisis minucioso de todo el sistema DSpace decidimos implementar ciertos cambios que próximamente veremos más detalladamente. El sistema se adaptó para brindar soporte a objetos de aprendizaje cuyos metadatos siguen el estándar LOMv1.0. Ahora los Item del antiguo DSpace representan a los OA. Para el desarrollo se utilizó el entorno de desarrollo (IDE) Eclipse Ganymede (3.4.2), Maven, Ant, PostgreSQL, pgadminiii, Java Sun JDK FUNCIONALIDADES AGREGADAS Internacionalización de los reportes estadísticos Las estadísticas del sistema original están en un proceso de maduración muy temprano. Ésto se refleja en los HTML, donde se encuentran escritos directamentes los textos correspondientes a las estadísticas en inglés. Lo que va en en contra del diseño general del sistema. Ésto hace que sea cual sea el idioma configurado por la aplicación, los reportes de las estadísticas siempre se elaboraban en inglés. Nosotros decidimos extraer todas las palabras y agregarlas al diccionario de Mensajes común de las JSP ([dspace-src]/dspace-api/src/main/resources/messages.properties). Los nombres de los eventos registrados en los logs del sistema, siguen estando en inglés. Ésto se puede internacionalizar editando el archivo [dspace]/config/dstat.map. 141

146 Envío hacia múltiples colecciones La capacidad de que un ítem aparezca en más de una colección estaba disponible en la versión original del sistema, pero era muy ineficiente. El proceso para agregar un ítem en más de una colección se hacía por medio de dos operaciones en la interfaz gráfica. El usuario que depositaba el ítem, debía elegir sólo una colección en el formulario y delegar la tarea de replicar ese ítem al administrador del sistema o a otro usuario con permiso de administración. En el nuevo repositorio Graduate!, este concepto se refleja permitiendole al usuario, elegir más de una colección en el proceso de envío. Respetando el mismo comportamiento que cuando se realiza el envío hacia una única colección. Esto quiere decir, que se permite guardar el estado del envío para luego retornarlo en otra sesión y continuarlo a partir de donde se dejó. Este requerimiento implicó un cambio en la API y en la base de datos. Por medio de la creación de dos tablas: workspaceitem2collection y workflowitem2collection, guardamos las múltiples colecciones involucradas en el proceso de envío o IPS. A continuación vemos una captura del sistema original y una captura del sistema actual Graduate!, permitiendo elegir múltiples colecciones : 142

147 Una captura Graduate! permitiendo reanudar un envío hacia múltiples colecciones: Nuevos campos de formularios La tarea de implementar una nueva interfaz de envío de metadatos, no sólo ocasionó la necesidad de crear formularios más extensos por la mayor cantidad de metadatos del nuevo esquema, sino que también se requirió la necesidad de crear nuevos tipos de datos para esos elementos. Si bien el sistema original brinda varios campos predefinidos listos para usarse, como por ejemplo: name onebox date series 143

148 qualdrop_value dropdown twobox textarea list Estos tipos de input-type no eran suficientes para representar loa metadatos compuestos del esquema LOM. En el sistema original cada tipo de input está asociado únicamente a un elemento de metadatos, por lo que fue necesario crear nuevos input y Graduate! presenta estos nuevos campos de formularios: contribute_value 144

149 format_value duration requirement_value taxón Importar/Exportar Ítems (SCORM) Packagers El sistema original brindaba la posibilidad de emplear plugins Packagers para importar y exportar contenidos, pero no eran utilizados en la interfaz gráfica. Coexistiendo un sistema de exportación e importación de ítems muy poco claro, se decidió atacar dos problemas en uno. Por un lado se simplificarían las tareas de exportar e importar ítems y por otro lado se emplearían los plugins Packagers que se encontraban sin ser explotados. Es por esto que se inició un cambio en la manera en que el nuevo repositorio Graduate! expondría sus contenidos. Se desestimó la posibilidad de seguir exportando para unos pocos es decir sólo para sistemas DSpace. Por ello se eliminó la exportación de ítems en formato nativo DSpace donde el paquete zip contenía una cartepa, y dentro de ella se encontraban los recursos y los metadatos del paquete. Los ítems en Graduate! se exportan en formato estándar SCORM 1.2, de manera que un ítem pudiera interoperar con muchos otros sistemas. Para llevar a cabo esto, se unificó el concepto de exportar/migrar un ítem del sistema original en una única tarea llamada exportar (SCORM). Además se agregó la funcionalidad de importar ítems en la interfaz gráfica, que en el sistema original no estaba presente. Una solución que salió casi inmediata fue la de utilizar los plugins Packagers para la importación y exportación de paquetes SCORM. 145

150 El sistema original no contaba con packagers SCORM. Éstos se crearon en base a un desarrollo previo del proyecto CWSpace, donde se utilizaban Packegers para trabajar con el formato de paquete IMSCP. En Graduate! se emplea dos clases distintas para la traducción de paquetes SCORM: SCORMIngester y SCORMDisseminator Crosswalk En cuanto al nivel metadatos de los objetos de primera clase se implementó un plugin Crosswalk llamado LOMCrosswalk, que lee los metadatos XML del paquete importado y los traduce al formato LOM interno del ítem. A su vez este plugin puede realizar la tarea inversa, es decir escribir en XML los metadatos LOM de un ítem. Graduate! posee un sistema de importación y exportación en la interfaz gráfica, como resultado de la colaboración de ambos plugins: SCORMIngester se encarga de traducir el paquete SCORM y los metadatos en LOM de ese paquete son manipulados por LOMCrosswalk. LOMCrosswalk se encarga de traducir los metadatos del ítem a LOM y luego viene la tarea de SCORMDisseminator que empaqueta esos metadatos y los recursos del ítem en un paquete SCORM. Figura 46 -Visualización de un ítem y la opción de exportarlo como paquete SCORM Figura 47 - Pantalla de inicio en la sesión de un usuario, el tercer botón indica la opción para importar un paquete SCORM. 146

151 Parámetros en campos de formularios Graduate! mejora la presentación de los campos en los formularios de envío. Ésto consiste en parametrizar algunas etiquetas xml en el archivo de configuración de los formularios [dspace-src]/dspace/config/input-forms.xml y modificar las clases java correspondiente al procesado de dicho archivo. Definimos los parámetros max-char-size y actual-char-size a los tipos de entrada onebox, duration y taxon para limitar el tamaño de los inputs, y la cantidad de caracteres máximos. Esto fue necesario para validar los límites que impone el estándar LOM en sus campos. Al elemento <field> le modificamos el subelemento <repeatable> que era de tipo booleano. Ahora indica un valor entero máximo de repeticiones que puede tener ese campo de metadatos dentro del formulario. Si se deja vacío se asume sin repetición. Graduate! incorpora esto para respetar el máximo de apariciones de un elemento en el estándar LOM. Por ejemplo: <field> <dc-schema>lom</dc-schema> <dc-element>gen~title</dc-element> <dc-qualifier></dc-qualifier> <repeatable></repeatable> <label>titulo: </label> <input-type max-char-size="1000" actual-char-size="60">onebox</inputtype> <hint>ingrese el nombre del titulo.</hint> <required>este campo es obligatorio.</required> </field> En este ejemplo tomado del archivo input-forms.xml se denota a input del tipo onebox que representa el elemento de metadatos lom.gen~title, el cual no es repetible. Gráficamente el input tiene un tamaño de 60 caracteres, pero acepta un límite de 1000 y es de llenado obligatorio FUNCIONALIDADES QUITADAS Soporte QDC a nivel de Item Si bien el sistema original brinda la posibilidad de crear un nuevo esquema de metadatos, dando la posibilidad de enriquecer los metadatos aportados por Dublin Core, a través de metadatos mixtos, en la práctica esto obliga a tener que si o si trabajar con Dublin Core. No se puede ignorar este esquema, puesto que en la implementación de la interfaz gráfica y en la misma API hay muchos elementos de código fuente anclados o atados a los campos de este esquema. Ésto nos obligó a realizar un mapeo entre los dos esquemas y adoptar sólo uno. 147

152 El código de las páginas JSP está muy dublinizado, nosotros al realizar el cambio, ya que no contamos con soporte de APIs genéricas de metadatos, dejamos el código lomizado. Es por ello que al final sugerimos como trabajo futuro, implementar un sistema de metadatos totalmente genérico. A pesar de ésto, respetamos el estándar en funciones como la implementación del protocolo OAI-PMH donde se requiere responder solicitudes en formato Dublin Core FUNCIONALIDADES MODIFICADAS Nuevo formulario de envío predeterminado Para permitir el ingreso de nuevos ítems al repositorio se tuvo que rediseñar el proceso de envío. Se utilizaron nuevos tipos de input en los formularios. Se cambió el proceso de envío por defecto a todas las colecciones. En el sistema original el proceso de envío tiene los siguientes pasos: 1. Seleccionar la colección de destino del ítem. 2. Describir los metadatos del ítem (3 páginas). 3. Enviar el o los archivos adjuntos. 4. Verificar los metadatos ingresados. 5. Aceptar la/s licencia/s (licencia CC es opcional). En Graduate! se ha alterado la secuencia y la cantidad de páginas para la descripción de los metadatos LOM: 1. Seleccionar la/s colección/es de destino del ítem. 2. Enviar el o los archivos adjuntos. 3. Describir los metadatos del ítem (9 páginas). 4. Verificar los metadatos ingresados. 5. Aceptar la/s licencia/s(licencia CC es opcional). Este cambio en el orden de los pasos se logró modificando el archivo [dspacesrc]/dspace/config/ítem-submission.xml. Y las nueve páginas de descripción y llenado de metadatos se crearon con la modificación del archivo [dspacesrc]/dspace/config/input-forms.xml. Si bien este nuevo proceso de envío es el predeterminado para todas las colecciones, se puede crear un proceso con menos pasos o con menor cantidad de metadatos para determinadas colecciones específicas. 148

153 Figura 48 sistema original Start a New Submission Figura 49 - Graduate! Comenzar un nuevo envío Otro cambio notable que se realizó fue la modificación del sistema de licencias CreativeCommons. Originalmente, asignar una licencia CC a un ítem es opcional. Para habilitar esa característica hay que cambiar una opción en el archivo de configuración. Una vez habilitado, se agrega automáticamente una pestaña más al proceso de envío. En esa pestaña se enlaza con la Web oficial de CC y se permite elegir una licencia. Graduate! aprovecha esta característica, pero no utiliza toda la Web para seleccionar una licencia. Utiliza una API brindada por CC, en la forma de un SELECT HTML, o combobox parametrizable. Este combo se ubicó en la pestaña Derechos, donde se parametrizó el idioma y el país licenciante. Para nuestro caso configuramos el combo en español, con licencias Argentinas. Esto se ilustra a continuación. 149

154 Figura 50 Utilización del API que brinda CC Cuando en Graduare!, el usuario elige una licencia CC, en la antepenúltima pestaña se muestra la licencia elegida, describiendo rápidamente y por medio de una ilustración las atribuciones que el autor delega. En este caso el rol de autor es la persona que otorga la licencia, es decir el usuario que esta completando el formulario. En la siguiente ilustración mostramos que el usuario por ejemplo eligió Atribucion- CompartirDerivadasIgual 2.5 Argentina. Figura 51 Ejemplo cuando se elige licencia: Atribucion-CompartirDerivadasIgual 2.5 Argentina 150

155 Otra personalización implementada sobre el formulario de envío, fue la adaptación de los vocabularios controlados a un tipo de entrada (input) específico. En nuestro caso decidimos emplear vocabulario controlado para el ingreso de las áreas temáticas, o clasificaciones de un OA. Cuando el usuario en la pestaña Clasificación rellena la Ruta Taxonómica de la clasificación del OA, lo hace a través de un popup, conteniendo el vocabulario controlado con un árbol de categorías. Estas categorías son personalizables y están almacenadas en archivos XML dentro de [dspace]/config/controlled-vocabularies/. A continuación veremos la pantalla en cuestión: Figura 52 Clasificaciones de un OA o áreas temáticas Adaptación OAIDCCrosswalk Se adaptó el plugin Crosswalk que exporta los metadatos respondiendo un XML en respuesta a peticiones externas del protocolo OAI-PMH. Se devuelve la información contenida en los metadatos LOM de los ítems, en formato DC Sistema de búsquedas adaptado a LOM Como la estructura interna de los metadatos de los ítems cambió, se modificaron los campos indexados de la base de datos. Se modificaron las páginas JSP de la búsqueda y la búsqueda avanzada. Se reconfiguraron los índices en el archivo de configuración dspace.cfg. Por defecto el sistema está configurado con los siguientes índices: search.index.1 = author:dc.contributor.* search.index.2 = author:dc.creator.* search.index.3 = title:dc.title.* search.index.4 = keyword:dc.subject.* search.index.5 = abstract:dc.description.abstract search.index.6 = author:dc.description.statementofresponsibility 151

156 search.index.7 = series:dc.relation.ispartofseries search.index.8 = abstract:dc.description.tableofcontents search.index.9 = mime:dc.format.mimetype search.index.10 = sponsor:dc.description.sponsorship search.index.11 = identifier:dc.identifier.* search.index.12 = language:dc.language.iso Los 9 índices se ilustran en la siguiente figura de búsqueda avanzada. Figura 53- índices en el sistema original En Graduate! esos índices se reemplazaron por los siguientes: # nuevos campos indexados search.index.1 = type:lom.educat~learn-res-type search.index.2 = identifier:lom.gen~identifier.* search.index.3 = mime:lom.technical~format search.index.4 = language:lom.gen~language search.index.5 = title:lom.gen~title search.index.6 = keyword:lom.gen~keyword search.index.7 = description:lom.gen~description search.index.8 = author:lom.lifecycle~contribute.author search.index.9 = classification:lom.classif~taxon-path.* Figura 54 índices en Graduate! 152

157 Luego de reindexar todo el archivo de ítems, las búsquedas arrojan resultados, pero se requieren más cambios para visualizarlos correctamente. Otro aspecto del sistema de búsquedas que se modificó es el uso de la navegación por áreas temáticas. Se indexó el campo LOM de las rutas taxonómicas y se crearon dos archivos XML en [dspace]/config/controlled-vocabularies/ UNPSJB.xml y UNESCO.xml. En cada archivo se define una estructura jerárquica de categorías, que son utilizadas por los usuarios para especificar las categorías de los OAs. Consideramos que era necesario crear una categorización local, dividida por Facultad y Carreras y otra categorización general para albergar objetos de cualquier índole en el repositorio y poder encontrarlos rápidamente. A continuación una captura de la navegación temática en Graduate!. Figura 55 Navegación por áreas temáticas en Graduate! Lista de ítems adaptación a LOM Un cambio que era imperioso hacer era la manera en que se listaban los ítems, puesto que el buscador funcionaba correctamente pero no mostraba resultados. Esto sucedía debido a que no encontraba metadatos indexados de acuerdo a los índices antiguos. Se actualizaron las columnas de la tabla que lista los ítems, y se habilito la opción de mostrar una vista en miniatura en la primera columna de la izquierda. Estos cambios se realizaron en el archivo de configuración dspace.cfg. Veremos a continuación una captura del sistema original listando por título y luego el sistema Graduate! realizando idéntica tarea. 153

158 Figura 56 - Navegación por título en el sistema original Figura 57- Navegación por título en Graduate! Visualización de un ítem adaptación a LOM El nuevo estándar implementado, no sólo implicó un cambio en el sistema de búsquedas y listados, sino que también (aunque de manera más obvia), condujo a un cambio en la forma de la presentación de los ítems. Este cambio se realizó modificando el comportamiento de la etiqueta JSP personalizada <dspace:item>. 154

159 A continuación una captura del sistema original listando los metadatos QDC de un ítem. Figura 58 Metadatos en el sistema originales Ahora veremos los metadatos de un ítem en Graduate!: Figura 59 - Metadatos en Graduate! 155