Hace unos días empezó el proceso de integración de las diferentes funcionalidades que abarca el proyecto por parte de cada uno de los socios que participan en la pasarela edit@. Nos permitimos recordar aquí que la pasarela es el ‘vehiculo’ que permite la interoperabilidad con los sistemas de gestión de contenidos existentes en el mercado, por ejemplo Alfresco (Ibermática).

Cómo se hace éste proceso?
Bien. Lo primero es crear un entorno de integración. Se ha utilizado el porta colaborativo de software libre Liferay configurado en, y para, éste entorno de integración, y que es accesible para cada socio con el objetivo de cubrir dos tipos de funciones diferentes.

Qué funciones?
Una documental y colaborativa, un espacio con noticias y foro para el consorciodel proyecto; y otra técnica, que es la pasarela edit@ para pruebas de integración.

Más detalles de la técnica
La integración con pasarela, técnicamente, consiste en conexiones de tipo WebServices. Dichos servicios WebServices se han encapsulado en “componentes”. Un componente es una biblioteca, en el lenguaje de programación de la aplicación consumidora del servicio, que facilita la integración de los diferentes módulos de edit@ al abstraer al programador de dichos módulos de los intrínculis de los WebServices, incluidos la conexión y el transporte.

En el contexto del entorno de integración de edit@, ya está disponible la infraestructura de servidores de pasarela/aplicaciones para todos los socios del consorcio. Cada socio dispone de las mencionadas bibliotecas de “componentes” y puede probar la integración con pasarela de forma remota desde sus instalaciones. También se ha abierto un espacio colaborativo para la integración, en el que además de tener disponible la documentación se utiliza un foro para el intercambio de experiencias.

En estos momentos estamos concentrados en integrar al máximo nuestras aportaciones en tecnología de la voz al entorno edit@. Esto quiere decir mirar qué información tendrá que transmitir nuestra tecnología al resto de los módulos, cuál tendrá que recibir y cómo hacerlo. Las dificultades que nos estamos encontrando son las habituales de un proceso de integración: errores en los formatos, en los protocolos, en cómo ha entendido cada grupo las especificaciones, etc. Gracies a la guia de Ibermática, en el paquete de coordinación de la barra edit@, estos problemas se van superando. Es de esperar que pronto tengamos los primeros demostradores, con varias de las funcionalidades previstas activadas, y en el que el usuario final pueda ver la barra edit@ funcionando. Es un momento que esperamos con ilusión.

Los socios del proyecto ya están trabajando en la justificación de la anualidad 2009. Después de la ampliación de oficio (Urbi et Orbi) de los plazos de ejecución concedida a finales del mes de diciembre por el Ministerio, la fecha para la presentación de la documentación de todos los proyectos de la Convocatoria Avanza I+D 2009  es el 30 de abril de 2010.  Aun así, la ejecución continua, puesto que el proyecto se aprobó con carácter binaual.

En breve, más.

Imagen

La pasarela, técnicamente conocida como bus de integración de aplicaciones, de edit@ se basa en la especificación Open Knowledge Initiative Open Service Interface Definition (OKI OSID) del Massachusetts Institute of Technology (MIT).

Esta pasarela proporcionará a través de dicha especificación siete servicios básicos cuidadosamente seleccionados para cubrir la totalidad de los requisitos funcionales del proyecto edit@. Dichos servicios básicos son autenticación, autorización, logging, locale, repository, configuration y transport. Todos ellos ya son funcionales en el entorno de desarrollo, a excepción del servicio de autorización en el que se está trabajando actualmente.

Pasarela edit@ permitirá que diferentes módulos consumidores soliciten sus servicios mediante interfaces y protocolos estándar sin que los desarrolladores se tengan que preocupar de la problemática de los módulos proveedores que realmente atienden las peticiones.

Las dos grandes ventajas para el proyecto edit@ son:

1. Total independencia lógica y tecnológica de los módulos consumidores respecto a los proveedores.

2. Fácil substitución de un módulo, consumidor o proveedor, por otro manteniendo la funcionalidad existente y sin afectar a los demás.

Tecnológicamente, la implementación de la pasarela se se basa en capas. La lógica de negocio se ha implementado en Java según la especificación Java Enterprise Edition 5 (JEE 5 o conocido anteriormente como J2EE). Dicha implementación ofrece una tanto una capa de WebServices como una capa RMI para atacar a los Enterprise Java Beans (EJB) desarrollados. Finalmente se ha desarrollado una capa de componentes que proporcionan a los desarrolladores de módulos consumidores el encapsulamiento respecto a los protocolos y transporte necesarios en un entorno distribuido (WebService, RMI…)

Últimamente, en el apartado de audio de conversión de texto a voz del proyecto edit@, nos estamos planteando el lugar que ocupa la expresividad de la voz. El proyecto pretende que los usuarios puedan señalar textos o documentos para convertirlos de texto a voz y subirlos a la Web. Las voces sintéticas actuales pueden resultar demasiado neutras o planas para reproduir textos largos y, como consecuencia la audición a menudo resulta incómoda y cansada. Es por eso que en el proyecto intentaremos incluir voces experimentales que tengan más matices expresivos para evitar estas sensaciones.

El usuario que utilice edit@ lo hará desde una plataforma de gestión de contenidos o CMS (Content Management System), donde tendrá a su disposición las nuevas funcionalidades que edit@ ofrecerá, proporcionando contenidos para dispositivos innovadores en diversos formatos.

En el marco de este proyecto se han analizado diversas alternativas de CMSs de código abierto en los que implementar edit@, atendiendo a criterios diversos: ritmo de adopción (descargas, instalaciones, soporte de terceros – publicaciones, … -) y medición de marcas (Measuring Brand Strength). Estos índices no son de carácter tecnológico y se han añadido otros, de carácter técnico/funcional, coherentes con los objetivos de edit@: web 2.0, posibilidad de definición e incorporación de metadatos, APIs de búsqueda, capacidad de referenciar nuevos tipos de contenido, y escalabilidad.

Bajo estas premisas, y realizando un análisis en profundidad de CMSs open source, la decisión final es realizar la primera implementación de edit@ bajo el CMS Alfresco, de amplia difusión en  entornos empresariales, y construido y basado en estándares como JSR-170, JSR-168, web services y REST.

Sus características de administración (gestión de usuarios, grupos, perfiles o roles, motor de workflow, plantillas prediseñadas, administración vía web), búsquedas (motor propio, uso de estándares OpenSearch o Google-like), tipificación y normalización (categorización, taxonomías, metadatos comunes y exclusivos), funcionalidad (gestión del ciclo de vida de los documentos, versionado, interfaces gráficas) e interoperabilidad (soporte XML, compatibilidad XHTML, sindicación de contenidos RSS, …) hacen de este CMS de código abierto la mejor opción para la primera implementación de edit@.

En este último año ha proliferado el desarrollo de herramientas de edición para generar contenidos conformes a la especificación SCORM muy completas siendo algunas hasta muy usables y accesibles por la mayoría de usuarios, cumpliendo con los objetivos marcados en el principio del proyecto en la edición SCORM. También, recientemente, la fundación LETSI (Learning Education Training Systems Interoperability), entre cuyos miembros se encuentran ADL, AICC, Adobe, IEEE y otros organismos, inició el trabajo de desarrollar una nueva normativa de SCORM: el SCORM 2.0. Por lo que se concluye que no merece el esfuerzo en desarrollar un editor que permita crear contenidos caducos y en desuso de aquí a unos años.

En contraposición al desarrollo del editor y ya que estaba previsto que el editor generase contenido SCORM específico para su correcto funcionamiento en dispositivos móviles y en la Televisión Digital Interactiva, se desarrollarán conversores que conviertan cualquier contenido SCORM diseñado para su funcionamiento en web en multiplataforma (Web, móviles y TVDI). Estos conversores se desarrollarán durante el desarrollo de los PT4 y PT5 del SP4 y se integrarán en el PT8 (Sistema de Gestión de Contenidos SCORM / LCMS) del SP3 haciendo así que cualquier contenido SCORM disponible en un CMS que use edit@ sea accesible desde cualquiera plataforma.

El PT3 del SP10 conocido con el nombre de STATS, después de identificar las necesidades estadísticas del resto de módulos de edit@ durante el primer semestre de este año, se ha detectado que puede ofrecer muchas más posibilidades de análisis, que las previstas inicialmente, y que permitirían realizar un seguimiento más exhaustivo de las tendencias de los usuarios en el uso de los servicios que ofrece edit@. Resultante del análisis de necesidades, varios paquetes de trabajo han solicitado disponer de estadísticas de uso de servicios tales como: traducción, conversión, anotaciones y LCMS. Por este motivo el paquete de STATS ha tenido que ampliar sus hitos.

El proyecto edit@ cuenta entre sus objetivos (SP4) “el garantizar la adaptación de contenidos al formato de dispositivo de tinta electrónica”. Pero, ¿está el mercado realmente interesado en libros electrónicos? La respuesta es, sin lugar a dudas, sí.  Sin otro propósito que el de analizar una tendencia, hacemos eco de una noticia relacionada con la tendencia de algunos fabricantes respecto a la Tinta Electrónica (eInk) y el mercado.

Consideremos, por ejemplo, el caso de Amazon. El gigante estadounidense propietario de los libros electrónicos Kindle 2 i Kindle DX ha decidido comercializar estos dispositivos a nivel internacional, pues hasta hace poco tiempos sólo se podían conseguir en territorio USA. En el caso de nuestro pais, podemos adquirir la versión más reducida (la 2) con capacidad para almacenar unos 15.000 títulos de entre los más de 300.000 que hay disponibles.

Kindle destaca por varias razones de las que destacaríamos tres: conectividad, capacidad y accesibilidad (speech reader, pero solo en lengua inglesa). Respecto a contenidos, permite visualizar además su formato propietario (.AZW), formatos PDF, DOC, TXT, MOBI (mobipocket) y PRC (webscriptions) entre otros.

No sería justo acabar esta entrada sin hacer mención tambien de otros fabricantes que ya comercializaban libros electrónicos en España ANTES que Amazon, como es el caso de Sony (Sony Reader) o iRex (iLiad y otros) y que siguen apostando fuerte por el desarrollo y avance de esta tecnología que, sin lugar a dudas, se encontrará pronto en muchas carteras.

Tal como veníamos informando, la forja Sourceforge en la que se encuentra alojado el proyecto edit@ efectuó durante los meses de mayo y junio importantes canvios técnicos (mejoras) que afectaron estructuralmente los Wikis.

El servicio técnico del Sourceforge, con el que se contactó al detectar que ya no se podía acceder al wiki de proyecto.edit@, recuperó los datos y estructuras. Sin embargo, no fue posible recuperar los enlaces a los ficheros de los entregables. Hoy mismo se ha contactado con todos los socios del proyecto para que los respectivos desarrolladores vuelvan a subir los ficheros de los entregables.

En la imagen se muestra cómo acceder al wiki.

Dos de los puntos contemplados en el proyecto edit@ son la Accesibilidad y los formatos de salida. Y bien podemos entender la suma de ambos conceptos como el formato Daisy para móviles. Pero, ¿sabemos qué es Daisy?

A continuación reproducimos parte del paper “Format for All” presentado en el Congreso OpenEducation 2008 (Utha University, Logan, USA) por Llorenç Sabaté, participante del proyecto y discapacitado visual. Coordina el WP relacionado con el formato de salida Daisy para dispositivos móviles.

To adapt a teaching material we can make a talking cassette. A speaker reads the document and records this on a cassette. This method had been used during the last years. One of the problems is that it is very difficult to find a subject. It is possible to  save a sound when a subject begins. This makes it easier to find the beginning of a subject but it is slow.

Another option is to save the voice in an audio CD as the example showed in this photo. This method is very used here in USA. We can play the CD in a car CD player and hear the book while you are driving. This method makes it easier to skip a track, similar to skipping a song in an audio CD. But it is still difficult to search a page in a track.

To solve this problem we can make a daisy book.  It is an xml document that makes it possible to browse the audio as a book. We can skip between chapters, pages or paragraphs, etc. It is possible because this xml has an index that indicates where this chapter, page or paragraph starts in the audio file. This method is better.

Another format is a book in braille. This method is very interesting for mathematical documents because it is very difficult to study this type of material in audio format.

In conclusion, to adapt a teaching material we can make a daisy or Braille book. These two formats are complementary. And I think that   it is bad practice to try to eliminate the Braille book bececause there are types of documents that are very difficult to study in an audio book. On the other hand, if we are traveling, a daisy book can be a good solution.