Cenatic Agrega


Ampliando el círculo de estándares

6 August 2009

Uncategorized Sin Comentarios »

Puzzle

A partir de la versión 2.0 de Agrega se ha ampliado el abanico de estándares disponibles para trabajar con Agrega. Hasta ahora, era posible descargar objetos digitales (ODEs) sin empaquetar (HTML y sólo contenido) y empaquetados en los formatos:Scorm 2004, Scorm 2004 sin submanifiestos, Scorm 1.2 e IMS CP, mientras que sin embargo, sólo era posible importar a la plataforma ODEs empaquetados con formato Scorm 2004 o sin ningún tipo de empaquetado, por lo que Agrega lo formateaba automáticamente en un paquete Scorm 2004.

Con el nuevo desarrollo, Agrega da la posibilidad de importar ODEs en los mismos formatos que permite exportar. Gracias a esta nueva funcionalidad, Agrega se acerca más aún a otros repositorios y LMSs que trabajan con estándares anteriores a Scorm 2004, permitiendo la compartición de objetos y ampliando su interoperabilidad con otros sistemas.Agrega, internamente, no almacena los ODEs en los formatos Scorm 1.2 e IMS CP sino que aplica una transformación de estándares convirtiéndolos a Scorm 2004, para que de este modo sea posible editarlos con el empaquetador (básico o avanzado) de la plataforma, así como visualizarlos.

En la conversión se eliminan etiquetas propias del estándar de origen, se transforman otras o incluso se añaden etiquetas propias de Scorm 2004 asignando valores por defecto para éstas. Se hace por tanto, un remodelado completo del objeto para que sea posible importarlo a la plataforma, pero manteniendo inalterable el contenido didáctico y pedagógico.De esta forma, os será más fácil utilizar Agrega para modificar y experimentar los ODEs que descarguéis de otras plataformas.

Tratamiento de las imágenes en los ODEs de Agrega

23 July 2009

Uncategorized, Cenatic's relevant Sin Comentarios »

Como bien sabéis, todos los ODEs que se publican en Agrega llevan asociados una imagen.

La imagen de cada ODE representa de forma visual el contenido de un objeto de manera que, de un vistazo, permite a un usuario hacerse una idea del contenido del mismo.

Cuando un ODE se publica en la plataforma, atraviesa por un proceso mediante el cual se profundiza en los contenidos multimedia que lo componen y se toma la decisión de fotografiar uno de sus elementos.

Dada la diversidad de contenidos que puede albergar un objeto digital y al tratarse de un proceso automático, se hace difícil escoger aquel contenido que representa con mayor fidelidad el espíritu del ODE.

La selección del recurso, que pueda ser fotografiado (tomar una instantánea gráfica del objeto), se realiza mirando en el fichero de manifiesto (imsmanifest.xml) el primer ítem dentro del apartado </organization>. Si este recurso no puede ser fotografiado,  se escoge de entre todos los recursos que forman parte del objeto un contenido susceptible de que lo sea.

Si el resultado de la selección no da como resultado un objeto del que se pueda rescatar una imagen (un archivo de audio por ejemplo) el sistema dispone de un repositorio de imágenes por defecto que representan los contenidos que no tienen representación visual, de forma que el usuario siga teniendo la posibilidad de identificar rápidamente el tipo de contenido del que está compuesto el ODE.

ejemplo-imagen-ode.jpg

La imagen que se genera de un ODE se crea en dos formatos y tamaños. Una imagen pequeña, que se muestra junto con la descripción del ODE en el listado de resultados de búsqueda y la ficha, en formato PNG, ampliamente aceptada por los navegadores y que reduce entre un 5% y un 25% respecto a un GIF, y una imagen grande, en formato JPG, que al ser un formato comprimido, permite la creación de imágenes grandes sin un coste excesivo en tamaño.

Nuevo tratamiento de los identificadores MEC en la validación y publicación

10 July 2009

Uncategorized, Cenatic's relevant Sin Comentarios »

 catalogacion.JPG

Como sin duda ya sabéis, las versiones anteriores de Agrega permitían la coexistencia de varios identificadores en el registro de cada ODE. Podían coexistir un identificador dado por el publicador, el que otorga automáticamente la Plataforma y el identificador MEC que, además también podía ser múltiple para aquellos casos en que un ODE hubiera sido descargado, modificado y vuelto a publicar.

Esta situación en la práctica provocaba diversos errores en el proceso de validación y publicación que se han subsanado en la versión 2.0.

A partir de esta versión sólo se admite un único identificador MEC en el campo IDENTIFIER en la categoría GENERAL de LOM-ES y todos los demás identificadores MEC que quedan obsoletos por la descarga, modificación y nueva publicación de cada ODE se incluyen en la categoría RELATION lo que nos permite continuar manteniendo el histórico de cada ODE publicado.

Os recordamos que el formato admitido para el identificador MEC es:

Código de localización geográfica _fecha de publicación_código de lengua_nivel de agregación_cadena numérica aleatoria 

Este es un identificador que admite variaciones posibles dentro de su cadena.

El código de localización geográfica puede ser de dos tipos:

·         Las letras “es” correspondientes a España

·         Las letras “es” seguidas de un guión alto y otras dos letras correspondientes a la CCAA que crea o modifica el ODE. (ejem: “es-ex” que indicaría que el ODE ha sido creado o modificado por la CCAA de Extremadura)

Después aparece la fecha de publicación del ODE en formato año-mes-día.

En el caso del código de lengua se establece la siguiente codificación:

  •  “_”para no identificar la lengua
  • “1″ para castellano
  • “2″ para catalán
  • “3″ para euskera
  • “4″ para gallego
  • “5″ para valenciano y
  • “6″ para inglés

Posteriormente se incluye el dígito del nivel de Agregación correspondiente al campo agregationLevel de la categoría GENERAL de LOM-ES.

En cuanto a los 7 últimos dígitos son una cadena aleatoria generada de manera automática. En este caso se solicita a los proveedores de contenido que no inicien este código con el número 9 reservado para indicar los ODES creados o modificados por la propia Plataforma Agrega.

Actualización taxonómica y contenidos inapropiados

26 June 2009

Uncategorized, Cenatic's relevant Sin Comentarios »

Uno de los puntos fuertes de Agrega es sin duda la clasificación taxonómica del contenido atendiendo a normas y estándares reconocidos lo que asegura rigor en la recuperación de los ODEs respecto a su adaptación curricular.

Como sabéis las taxonomías disponibles actualmente en Agrega son:

  • Accesibilidad LOM-ESv1.0: clasificación que recoge el modo de acceso e interacción de los alumnos con el ODE.
  • Competencia LOM-ESv1.0: clasificación que recoge las competencias generales y específicas que los estudiantes deben adquirir para desenvolverse en su entorno académico, laboral y social.
  •  Nivel educativo LOM-ESv1.0: clasificación que recoge los  niveles educativos dentro de las diferentes etapas de enseñanza.
  • Árbol curricular LOE 2006: clasificación que incluye las enseñanzas mínimas recogidas porla LOE en los niveles de la Enseñanza Reglada no universitaria.
    Y el tesauro:
     
  • ETB-LRE MEC-CCAA V.1.0: adaptación para LOM-ES del tesauro ETB que amplia su cobertura al sistema educativo español. 

Ontologia

Pero, ¿qué sucede cuando se produce algún cambio en el árbol curricular vigente, por ejemplo debido a una modificación legislativa en la educación?. En ese caso es función de los administradores de Agrega realizar la modificación pertinente, como ya comentamos en el blog de la Comunidad Virtual. .  

La herramienta de modificación disponible en las herramientas de administrador (ADMINISTRACIÓN -> Modificador) proporciona una solución a este problema. La herramienta de modificación permite a un administrador crear una tarea para modificar objetos del repositorio añadiéndoles una nueva rama del árbol curricular vigente o una nueva rama del tesauro.

Además, desde la versión 1.2.0 de Agrega, esta funcionalidad evoluciona para permitir añadir cualquier tipo de taxonomía o tesauro (vigente o antigua) disponible en la plataforma. Una vez ejecutada una tarea de modificación sobre los objetos publicados en el repositorio, los índices de búsqueda quedan actualizados de modo que a partir de entonces las búsquedas permiten encontrar los viejos objetos en las ramas del nuevo árbol curricular.

Otra de las funciones que debe llevar a cabo el administrador de Agrega hace referencia a los objetos reportados por el usuario como “Contenido inapropiado”. Cada vez que un usuario de Agrega considera que un objeto, por diversas razones, no es adecuado para formar parte del repositorio y así lo indica, el administrador recibe un correo electrónico con los datos del objeto y el comentario que ha introducido el usuario. Es tarea del administrador en ese momento evaluar si el contenido es realmente inapropiado y, en caso afirmativo, proceder a eliminarlo de la Plataforma.

Actualizado el proyecto en la forja

21 April 2009

Uncategorized Sin Comentarios »

Siguenos  en el apartado de forja de nuestra comunidad, hemos realizado ya subidas de codigo y documentación.