Metadatos: DC, LOM y LOM-ES

This topic contains 8 respuestas, has 6 voices, and was last updated by  jrfern Hace 12 años, 5 meses.

  • Author
    Entradas
  • #390

    Anónimo

    Como es sabido eXe almacena los metadatos que se aporten en el estándar DublinCore. De origen bibliotecario, sencillito y tal.
    Para  facilitar la subida de proyectos en Agrega y similares se está implementando la posibilidad de que eXe almacene sus metadatos también en LOM y en LOM-ES.
    DublinCore utiliza 15 campos de datos. LOM utiliza… muchos. Obviamente usaremos la versión simplificada.
    Inicialmente se consideran dos opciones:
    1.- la pestaña Metadatos cargaría un formulario con n campos de entrada: la suma de los necesarios para los tres sistemas de catalogación. El usuario no tendría ni porqué saber cuáles son requeridos por uno u otro sistema. Al final del formulario habría tres botones, uno para cada sistema, y el código de eXe se encargaría de “saber” qué y cómo guardar.
    2.- la pestaña Metadatos abriría tres nuevas pestañas, cada una con lo suyo…
    las dos opciones tienen ventajas e inconvenientes.
    Estas decisiones y las que vengan detrás relacionadas tienen más probabilidades de ser acertadas dentro de un grupo de trabajo…
    Pues eso. Este es el sitio para hablar de ello.

  • #391

    ismagago
    Member

    Estupendo, Ton

    Me parece el planteamiento más adecuado. Y en mi opinión, como componente de proyecto eXeLearning optaría y/o sugeriría la opción que técnicamente cueste menos trabajo desarrollar y tenga más viabilidad de futuro.

    Se que no todo el mundo va a catalogar los contenidos que vaya desarrollando, pero si yo fuera un usuario que además vaya a publicar y validar ODEs generados con eXeLearning en Agrega optaría por la opción 2.

    Recordad que ponemos los tres porque DC (Dublic Core) es el que trae por defecto eXe y lo mantenenos, LOM por ser el estándar de catalogación en europa, y les interesa a nuesros colegas alemanes y austriacos que siguen el proyecto, y su variante LOM-ES por ser el que utlizamos en Agrega.

    Sería interesante que también opinaran nuestros compañeros gallegos, pues fueron ellos los que nos sugirieron esta funcionalidad. También me gustaría conocer la opinión de Toni Galisteo, implicado en el desarrollo de la catalogación LOM-ES que utilizamos en Agrega.

    Saludos, gracias por el trabajo y ánimo a todos.

    • This reply was modified Hace 12 años, 6 meses by  ismagago.
  • #394

    pablonimo
    Member

    Hola compañeros,
    Soy un Pablo de Galicia, pero no soy el mismo Pablo que que ha sugerido la funcionalidad. A Pablo Gulín ya lo he avisado para que se pase por aquí a dar su opinión sobre el tema 😉
    Comentar que concuerdo con el principio de “fácil y sencillo”, ya que seguramente es una de las garantís de éxito del proyecto.
    En relación al tema de discusión os voy a proponer una opción tres que, aunque no la he reflexionado demasiado, es posible que podamos discutirla.
    Se trataría de un sistema de catalogación en cuatro pestañas, y que a su vez estaría basado en una relación entre campos de los diferentes sistemas de catalogación:
    Trabajos previos:

    Análisis de los sistemas de catalogación y definición de los campos comunes entre DC, LOM y LOM-ES. Consistiría en identificar n campos que existieran en los tres sistemas. No sé el número de campos comunes que obtendríamos de este estudio….

    Pestañas de catalogación:

    Catalogación básica:

    Tendría una serie de campos (supongo que entre 10 y 20) que, perteneciendo a la lista de campos comunes, consideramos los más básicos.La aplicación podrían encargarse de cubrirlos en los tres sistemas de catalogación, ya que estarían enlazados….

    DublinCore

    Tendría el resto de campos que, perteneciendo al sistema DublinCore, no están recogidos en la pestaña “Catalogación básica”. Sean campos comunes con el resto de sistemas de catalogación, o no.

    LOM

    Tendría el resto de campos que, perteneciendo al sistema LOM, no están recogidos en la pestaña “Catalogación básica”. Sean campos comunes con el resto de sistemas de catalogación, o no.

    LOM-ES

    Tendría el resto de campos que, perteneciendo al sistema LOM-ES, no están recogidos en la pestaña “Catalogación básica”. Sean campos comunes con el resto de sistemas de catalogación, o no.

    Otras cuestiones a valorar:

    Aprovechando la magnífica idea sobre la gestión de idevices se podría permitir al usuario mostrar sólo la pestaña 1, la 1 y la2, la 1 y la 3… etc…. En todos los casos la catalogación se haría automáticamente, y para aquellos campos comunes posible en los tres sistemas.

    Es posible que sea un desbarre, y es posible que para lograr algo así el trabajo sea considerable, pero yo no me desharía de DublinCore ya que es un sistema utilizado actualmente por su simplicidad en relación a LOM. Aquí en Galicia se está utilizando en Galiciana [1] y mantenerlo sería una puerta abierta para este tipo de proyectos.
    Saludos!
    [1] http://www.galiciana.bibliotecadegalicia.xunta.es/gl/estaticos/contenido.cmd?pagina=estaticos/presentacion
     
     
     
     

  • #401

    PabloGulin
    Member

    Hola a todos,
    disculpen la tardanza en mi participación el el foro pero por motivos familiares y laborales estas últimas semanas han sido bastante caóticas… Pero bueno, ya tengo recargadas las pilas y estoy dispuesto a ponerme a fondo con este tema y mi colaboración en el proyecto. Sobre el tema de la catalogación me parece que la idea de Pablo Nimo es muy interesante y concuerdo al 100% con lo que expone. Sobre el tema del vídeo tutorial voy a necesitar alguna versión “beta” del programa que catalogue en LOM-Es para poder hacer las capturas de pantalla. Entonces cuando haya algo así me pongo inmediatamente manos a la obra y os voy mostrando como va quedando. 
    Bueno, a partir de ahora intentaré pasarme a menudo por los foros para irme empapando de Exelearning!
    Un saludo desde Galicia!

  • #422

    Anónimo

     
    Hola
    Observar que una cosa es que pueda en un proyecto haber metadatos almacenados en uno, dos o los tres sistemas y otra que cuando se pretende la exportación hay que indicar uno de ellos y eXe guardará en el IMS o SCORM lo que quiera que haya almacenado en aquellos campos. Adjunto un pantallazo de lo que podría ser una opción.
    La verdad es que no entiendo bien el interés de esa cuarta pestaña. si lo entiendo bien un usuario tendría que acabar rellenando siempre dos pestañas, la transversal + la específica, lo que me parece más lío. O algo se me escapa en esa idae.
    Yo entiendo más una “transversal” en el sentido de lo que dije como opción 1 al inicio del hilo; y el tema es que esta opción obligaría a pasar obligadamente por el formulario más amplio cualquiera que fuera el caso, lo que me hacía dudar.
     
    Otro tema es que si se pretende la pestaña LOM-ES con sus 9 categorías de metadatos con sus elementos obligatorios nada más hay quien opina que …”hay que meter todo LOM-ES porque hay elementos recomendados u optativos que son de gran utilidad didáctica o técnica, tanto para la búsqueda o filtrado de ODE, como información para los usuarios (tutores o estudiantes) en cuanto a su entorno y contexto-forma de utilización. Creo que hay que dar la opción, aunque luego si se desea no se cumplimente. Además, los obligatorios de LOM-ES no son exactamente los de AGREGA.”…
    Qué opináis?

    Archivos adjuntos:
    You must be logged in to view attached files.
  • #425

    Anónimo

    Hola Antonio:
    Pongo mi opinón sobre este tema sin conocer en de detalle la complejidad de lo que propongo.
    Creo que deberíamos evitar poblar en exceso el menú de exportación. Sería mejor:

    Poner un opción adicional en la pestaña Propiedades/Exportar para elegir entre SCORM 1.2 o SCORM 2004
    Centrar en  la pestaña Propiedades/Metadatos las opciones de Metadatos. P.e.: un combo me da a elegir entre los diferentes estándares de etiquetado y en función del estándar de etiquetado elegido, me aparecería uno u otro formulario.

    ¡Un saludo!
     

  • #430

    Anónimo

    Hay que tomar dos decisiones:
    1.- Incluso en la situación actual (sin tres opciones de metadata) lanzar la exportación buscará valientemente lo que el usuario haya rellenado en el formulario de metadatos DC. Digo valientemente porque se supone que habrá tecleado información, de hecho como eXe no se fía de que hayan tecleado nada para 5 de los parámetros se busca la vida para coger unos mínimos valores por defecto.
    Esto hace pensar que quizás esa ventana de toma de metadatos (que dispondrá ahora de 3 subpestañas) debiera poder cargarse sólo tras pulsar opción en el menú inicial. Así hay un sólo acceso a ese menú y nadie se escapa sin escribir algo.
    Es una opción, pero es interesante que:
    – tres clics son sustituidos aquí por un solo clic para seleccionar el caso deseado.
    – veo menos fácil perderse; estoy pensando en profes que entran a catalogar a rastras.  
     
    2.- Otro tema relacionado pero independiente: – scorm1.2 tendrá ahora sus tres modalidades diferentes de metadata, scorm2004 también. Pregunto: y IMS y CC? Actualmente sólo DC, habilitamos también en ese caso las tres opciones?.

    • This reply was modified Hace 12 años, 5 meses by  .
    • This reply was modified Hace 12 años, 5 meses by  .
  • #443

    Anónimo

    Nuevas reflexiones:
    Como quiera que eXe utiliza un sólo formato de metadatos posible (DublinCore) y que eXe se busca la vida para exportar en SCORM sin que el usuario siquiera haya rellenado metadatos (si el usuario no teclea nada  en la pestaña metadatos, eXe automáticamente coge algunos valores del propio proyecto, los almacena como tales y a correr, ya tiene un DublinCore minimun (*)) , el resultado es que un docente sin saber siquiera lo que es un metadato puede generar un exportado SCORM catalogable en un banco de recursos.
    Al ampliar nuestras funcionalidades a otros formatos de almacenamiento de metadatos no debiéramos complicar eXe, por tanto se puede mantener ese posible uso minimalista del siguiente modo: en Propiedades>Metadatos aparecerán ahora tres opciones (DC, LOM y LOMES) seleccionable por el usuario pero excluyentes. Por defecto seguiría estando DC y eXe seguiría funcionando en ese caso como hasta ahora (*) ; pero si el usuario selecciona (casilla de Activar) LOMES por ejemplo, eXe exportará con sus metadatos en LOMES etc.
    De este modo el usuario no avanzado no se encuentra en la duda de seleccionar un ¿formato de metadata? uuuh!?.
    Habría que hacer la misma implementación: esos 4 ó 5 datos que eXe sabe asignar directamente a ciertos campos en DublinCore, que encuentre también a dónde asignarlos en LOMES y en todo caso confiar en que si alguien cambia la asignación por defecto DC a LOMES o LOM es porque sabe lo que está haciendo y supuestamente rellenará campos….   Qué os parece?    

    • This reply was modified Hace 12 años, 5 meses by  .
    • This reply was modified Hace 12 años, 5 meses by  .
    • This reply was modified Hace 12 años, 5 meses by  .
  • #451

    jrfern
    Member

    ¿Alguna de las propuestas crea paquetes no-compatibles hacia atrás? Si hasta ahora eXe generaba siempre -hiciera lo que hiciera el usuario- metadatos DC, entonces deberíamos seguir haciéndolo. Quizás crear de entrada un esqueleto mínimo DC + LOM + LOM.ES, por el principio de “eXe se busca la vida”, y dar pie al autor a que complete los campos.

You must be logged in to reply to this topic.

Skip to content