Asumimos, que si deseamos saber la procedencia de una foto (por ejemplo), o quienes salen en ella, o a quien corresponden los derechos; es necesario documentar, con muchísima más razón ahora que resulta fundamental la credibilidad de la fuente o el origen, o que nosotros mismos (como productores de material digital) queremos proteger nuestra autoría; ya que en el mismo instante que sale de un ordenador para ser enviada a una red local, una cuenta de correo, subida a un sitio web, o simplemente subida a un servidor ftp; se halla expuesta a unos innumerables riesgos de que acabe a saber donde.

En virtud de ello; tenemos a disposición decenas de estándares, método y formas de hacerlo, algunos con muchísimas cosas en común (tal vez copias?); sensibles modificaciones a los estándares originales o adaptaciones personalizadas de uno o varios de ellos. A la hora de elegir un estándar hay varios criterios que evaluar:

Perdurabilidad: Si es que el destino final de dicho material es un archivo digital, asegurarse poder recuperar con el tiempo (años) dichos datos. Normalmente eso dependerá del sistema de archivo del que dispongamos; que puede ir desde simplemente copiar el material a un disco (DVD, disco externo, etc.) hasta dejar que forme parte de un sistema digital que gestione esos datos (como Hemerodata)
Popularidad vs. Privacidad: Si lo que deseamos es que quien sea que explore nuestro documento digital pueda leer los metadatos, hemos de elegir aquel método que sea más popular y que la mayor parte de aplicaciones de escritorio especializadas sean capaces de entenderlo. Si por el contrario deseamos mantener la privacidad de dichos datos; no queda más remedio que codificar con alguna aplicación “propietaria”; que pueda entenderlos en origen y en destino.
Respaldo y evolución: Muchos estándares prometían estar a la vanguardia y fueron adoptado por una enorme cantidad de aplicaciones capaces de “entenderlo”; pero dicho estándar no tuvo evolución (o se ha desvirtuado por completo; como el caso del japonés Exif) y los esfuerzos de documentación van a parar a la basura. En el otro extremo (el de la evolución y expansión permanente), tenemos el Adobe XMP ; que especialmente en los últimos años fué marcando el camino para la documentación de ficheros digitales.
Soporte: Dependiendo del tipo de material digital, seguramente habrá un estándar de metadatos que se adapte mejor; ya que algunos de ellos pueden utilizarse con diferentes tipos de ficheros. La homogeneidad en la documentación es un buen criterio a tener en cuenta; ya que si nos es posible editarlos a todos con la misma herramienta y “embeber” la documentación con el mismo estándar, nos aseguramos poder recuperar esa información en el futuro o que los destinatarios puedan hacerlo. Cuanto más rica información seamos capaces de almacenar en los variados formatos digitales que vayamos a gestionar; mucho mejor.

Al final; y después de toda esta especulación, la conclusión es que la elección más acertada normalmente es la de la normativa de quien domina el mercado de edición digital. Un estándar no es más que una recomendación de normas o procedimientos de como hacer las cosas.
Muchos esfuerzos han hecho los diferentes organismos independientes (como la NAA o la ISO); para publicar draft y versiones de estándares abiertos (quienes a su vez obtuvieron reglas básicas de iniciativas privadas), y que en muchos casos se vieron forzados a modificarlos en versiones posteriores por la demanda de compatibilidad de estándares de ámbito privado.

En lo que se refiere a dispositivos móviles, desde el primer portátil (en el 81; del tamaño de una maleta de viaje y con más de 10 kg de peso, el Osborbe1), o los teléfonos móviles (por el 83; y con casi 1Kg de peso, el Motorola DynaTAC) hasta los dispositivos móviles de hoy (Smartphones y Tablets) .. ha pasado mucha agua bajo el puente.

Recientemente los ejecutivos de Intel Corporation analizaron la evolución de nuestra sociedad digital destacando la creciente demanda por la conectividad en todos los aspectos de la vida cotidiana de las personas.

Para presentar varios avances en hardware, software y ecosistema diseñados para ofrecerles a los usuarios experiencias más ricas en lo que a conexión se refiere a través de una gama de productos y dispositivos, estuvieron presentes Doug Davis, vicepresidente y gerente general del Netbook y Tablet Group de Intel, Renée James, vicepresidente senior y gerente general del Intel Software y Services Group y Ton Steenman, vicepresidente y gerente general del Intel Embedded y Communications Group, dieron una serie de anuncios.

Los anuncios incluyeron la presentación de una gama de dispositivos para tablets basados en el procesador recientemente anunciado Intel Atom Z670; las nuevas colaboraciones para el Intel AppUp SM Center y el Intel AppUp Developer Program en China así como la divulgación de la plataforma de infraestructura de comunicaciones de próxima generación de Intel “Crystal Forest”.

Todas las grandes compañías se encuentran en crecientes avances y rápidos giros en el despliegue de sus negocios; apuntando los cañones a los Tablets; de hecho, desde que Apple presentó el concepto no han dejado de salir al mercado. ¿Pero .. por qué será el Tablet la estrella y no el Smartphone u otros dispositivos?

En primer lugar, los tablets superan a los móviles en tamaño de pantalla, siendo suficientemente grandes para explorar con comodidad, haciendo más fácil ver detalles muy pequeños y da más seguridad a la hora de ingresar los números de las tarjetas de crédito u otra información personal.

En segundo lugar, claramente; por su portabilidad, incluso si tenemos los dos dispositivos. El Tablet es más ligero y fácil de manejar, además de ser más sencillo equilibrarlo en las rodillas cuando estamos (por ejemplo) en un sofá, esperando un vuelo o viajando en tren.

Finalmente, por su riqueza en contenido. Las aplicaciones comerciales nos hacen vivir la experiencia como si fuese un catálogo y lo ha convertido en un espectáculo audio-visual. En definitiva, estos dispositivos fomentan la navegación por recreo.

No todas las empresas pueden permitirse justificar el desarrollo de aplicaciones comerciales específicas (o realmente no encuentran por su actividad la que convenza más allá de ser un mero catálogo) ; sin embargo nadie quiere perderse esta abrumadora avalancha de aplicaciones y de un modo u otro; desean estar presentes.

De un modo u otro; está claro que la tendencia apunta a dispositivos que no sólo sean útiles a la hora de navegar o utilizar una aplicación; sino que también pueda convertirse su uso en toda una experiencia sensorial (salvando las distancias obvias; como la que hubo entre la TV en blanco y negro y la TV de color).

Todos estos proyectos tenían cosas en común:
- No llamarse “bases de datos”, para empezar; cosa que estaba bien clara en sus declaración de intensiones.
- Poder manejar eficientemente grandes volúmenes de datos; cosa que evidentemente han conseguido. Hypertable (una implementación open source de BigData), puede escribir 1000 millones de registros al día; por su parte BigTable, en conjunto con su tecnología hermana MapReduce, procesa hasta 20 petabytes de datos diarios (seguramente algunos de nuestros lectores no podrían ni imaginar cuanto es eso).
- Superar los cuellos de botella de rendimiento. Al no tener que realizar la traducción de datos hacia un formato amigable para SQL, las arquitecturas NoSQL son mucho más rápidas. El costo de mapear los datos a SQL puede valer la pena para los casos en que estos datos tengan que manipularse extensivamente… pero cuando la estructura de la base de datos es muy simple, SQL no parece que pueda ayudar.
- Ejecutan en clusters de servidores de PC baratas. Los clusters de PC se pueden expandir de forma facil y barata sin la complejidad y el costo del “data sharding”, que involucra recortar una base de datos en múltiples tablas para ejecutarse en grandes clusters o grillas. Google cuenta que uno de sus clusters de BigTable más grande se gestiona miles de servidores de pocos dólares; mientras que Oracle te necesitará hardware y la configuración adecuada de Oracle RAC (Real Application Clusters) y algún otro software mágico para lograr la misma escalabilidad. ¿Pero … a qué costo?.

Muchos de los mitos sobre el código abierto están cayendo; gracias a las comunidades que a diario aportan ideas geniales que acaban convirtiéndose en realidad, y al apoyo de grandes compañías que dan su voto de confianza a estas nuevas tecnologías emergentes.

En nuestra humilde opiñión (y por nuestra propia experiencia ) las bases de datos NoSQL son un logro (uno más) del mundo open source; y deberemos ir acostumbrándonos a que nuestra ingeniería aplicada a productos acabará siendo rentable por el servicio y no por licencias.

Foto redacción Diario ABC

Esta pequeña historia pretende comparar el desempeño de una pequeña redacción, con y sin ayuda de un DAM; y se pretende concientizar a directivos, jefes de redacción y redactores de la importancia de contar con un gestor de contenidos avanzado.
Evidentemente los personajes y hechos son absolutamente ficticios, pero estamos seguros que se sentirá identificado con el escenario.

Antes del DAM, un día cualquiera ..

Julio llega a las 8 de la mañana a su mesa en la redacción del periódico. Va rápidamente a por su café de la mañana y vuelve rápidamente porque sabe que le espera un día de “esos”.
Efectivamente; en el ejemplar de anoche hay una foto que pertenece a otro artículo ..#!@@@##…
- “Antonio !! que pasó con esto?” le dice impacientemente por el interno al responsable de cierre; esperando en lo profundo de su ser que él fuera quien estuviera equivocado.
- “No tengo ni idea, deja que averigüe algo y te digo” le contesta Antonio; a lo que Julio replica
- “Seguro que voy a tener que dar explicaciones, así que date prisa .. ”
No ha empezado bien su mañana; pero siendo ya las 10 entre leer y contestar correos y revisar los servidores y aún le aguarda lo mejor.
- “Mmm .. tengo reunión con el jefe de redacción; a ver que me pide ahora”
Pablo tenía preparadas unas ideas para el ejemplar del día, pero no sólo no lo tenía completamente decidido sino que además no sabía a quien podría enviar a cubrir las dos entrevistas, el accidente de la carretera y el arribo del subsecretario de Hacienda de su reunión en Bruselas.
De vuelta, teléfono en mano; a que la recepcionista localice a algunos de los fotógrafos y periodistas que necesitaba; mientras pide a archivo que le localicen fotos de cuatro personas que ni conoce.
- “Ya me estoy viendo .. buscando yo mismo en los discos externos y esos DVD que nunca están en sus cajas; encima el PC de archivo no sé lo que le pasa que el monitor se pone violeta; por cierto .. nota mental: mandarle un técnico.”
- “Vaya .. Jorge no está en su mesa .. estará recogiendo DVDs por la redacción .. esto hay que organizarlo .. le mando un mail con copia a Pablo”
Ya son las 13hs y me faltan dos periodistas; Juan está de licencia y Julio contaba con él, pero claro .. nadie le avisó.
- “Ommm … ommm … todo a medio hacer y encima no me traje las pastillas para la acidez”
Pablo ya tiene claro que no va a cubrir lo del ministro .. o era secretario?, bueno; da igual porque de todos modos ya mandé al redactor; y ahora ??

Va todo mal; y aún no tiene ni la mitad de fotos de archivo, pero Julio tendrá que comer algo ..
- “Bueno, un bocadillo y refresco en la cocina .. así no voy a adelgazar nunca !”

Creo que no es necesario ni relatar el resto de la tarde .. todos sabemos como acaba.

Después del DAM, un día cualquiera ..

Julio llega a las 10 de la mañana a su mesa en la redacción del periódico. Va muy tranquilamente a por su café de la mañana; anoche el sistema le mandó un SMS advirtiendo de una incongruencia en la foto de un artículo, pero por suerte se pudo avisar al responsable de cierre a tiempo y no pasó a mayores.
Cuando se encuentra con Pablo, es para charlar de fútbol .. ya aprendió a usar el sistema de gestión de asignaciones y sabe perfectamente con que periodistas y fotógrafos cuenta desde tempranito; de hecho, él mismo las hace.
Además ha conseguido sacar provecho al Discover y no sólo se entera de los temas que más “suenan” sino que ya se ha preparado varios basquets con material que el sistema le sugirió y las fotos de agencia relacionadas.

En cuanto a archivo; pff .. si no le gustan las fotos que se consiguió con el buscador él mismo, se elegirá otras y después de decidir las manda a la lista de retoque. Le gusta todo el tiempo saber como van las cosas, y con este sistema se entera a que hora entra o sale de retoque, cuando se planta en página; el momento exacto en que sus redactores empiezan a mandar el material de los eventos que fueron a cubrir …

Por su parte, Jorge; el encargado de archivo, ahora tiene tiempo para hacer lo que tiene que hacer: documentar contenidos. Tiene una pila de trabajo (las fotos de la edición de ayer, lo que ha ido seleccionando la redacción anoche; en fin .. bastante); pero afortunadamente todo va a su ritmo.

Me ha cambiado la vida; por fin puedo almorzar sano y sin prisas, y en cuanto a Pablo, ya habría discutido con él ya 5 veces .. y apenas son las 11 y media ..

• Explorador de eventos

  Aquellas instalaciones que dispongan del módulo de gestión de eventos, podrán acceder a esta poderosa herramienta. Mediante una simple configuración accesible por usuario; cada persona que tenga permisos para acceder a visualizar o gestionar los artículos de un evento, podrán filtrar la información por fases u otros criterios, visualizarla en varios formatos (incluyendo un fullscreen); pudiendo seleccionar uno o varios ítem para efectuar las acciones que le sean permitidas; como cambiar de fase, eliminar, des-enlazar u ordenar algún retoque automático al servidor -como por ejemplo, un crop-, o enviar a destinos. Útil, simple e intuitivo.

• Filtro de vistas

  Como sabemos, en IWA se accede a los contenidos de diferentes maneras. Una de ellas es la vista; que devuelve los ítems que responden a unos criterios previamente establecidos en una búsqueda, y que se ha guardado como vista. Según el tipo de material o la mezcla de ellos que se está visualizando en dicha vista, es posible aplicar diferentes filtros (normalmente con los datos coincidentes a los tipos conseguidos) con el fin de reducir y afinar los resultados, haciendo que tenga quizás más finalidades que las que se plantearon al crearla, o simplemente ayudando a localizar unos ítems concretos dentro de ella.

• Traducción en línea

  Esta opción (disponible en los menúes contextuales) permiten al usuario efectuar traducciones desde y hacia diferentes idiomas, pudiendo en ese acto corregir o ajustar dicha traducción o bien generar una copia del ítem traducido en uno nuevo. Esta funcionalidad se vale del famoso traductor de google , para lo cual resulta imprescindible que vuestro servidor tenga salida a internet.

• SmartViews®

  Un nuevo mecanismo de caché desarrollado por dbyse; que ha sido probado y utilizado durante más de un año en la aplicación de la suite IDM+; se ha implementado ahora en su versión web IWA. Este mecanismo evita los accesos redundantes a contenidos y permite que varios usuarios que se encuentran revisando las mismas páginas de contenidos, compartan información entre ellos (sólo desde el punto de vista estrictamente del servidor); reduciendo en general las llamadas al core en más de un 70%, hecho que repercute directamente al usuario en mejores tiempos de respuesta.

• Exportación o Importación por lotes

  La posibilidad de elegir un criterio determinado y establecer unas condiciones concretas de seleccionar a través de ello un conjunto de ítems; que, valiéndose de plantillas o bien de reglas creadas para el caso, puede exportarlos en diferentes formatos o efectuar llamadas a un web service externo para enviarlos. Una herramienta poderosa para compartir contenidos con otros sistemas o migrar desde su sistema actual a infoData.

• Generador RSS

  Al igual que en el caso de la exportación/importación; el core de infoData puede generar feeds RSS de manera nativa valiéndose de selectores que determinarán los artículos a publicar por lote, aunque también pueden elegirse “manualmente” vía opción en el menú contextual del ítem a publicar. En añadidura, también puede devolver los resultados de una vista en concreto también en formato ATOM para convertirse en el orígen de datos de un servicio RSS.

Todo esto es genial, pero .. que tiene de nuevo este interface?

A diferencia de su predecesor, este portal fué construido desde sus inicios pensando en la compatibilidad. La versión anterior sólo (que llegó hasta la 2.0.17) soportaba un par de navegadores de una versión específica y en una plataforma concreta; a diferencia del nuevo portal que se constituye en un verdadero cross-browser / cross-plataform, pudiendo funcionar sin ningún inconveniente, por ejemplo, en linux bajo un browser Galeon; soportando, desde luego, los más utilizados: FireFox, Google Chrome, Safari, Opera, Konkeror, etc.
El nuevo IWA se vale de tecnología ajax “entender” a sus contenedores; potencia que se aprovecha también para hacer más grata la navegabilidad con efectos visuales que aportan un acabado profesional al producto.

Mirando al futuro

Sabemos que algunos navegadores ya soportan bastante bien el standard HTML5 y CSS3; para lo que la nueva generación de portales infoData se está preparando. En paralelo a esta versión de IWA, se ha escrito la aplicación Web en HTML5, con la intensión de llegar a dispositivos móviles y a los navegadores más usados para cuando estén listos.
Es una tarea interminable; pero creemos que estamos en el camino correcto.

Ir al inicio

A menudo, las entradas al sistema son “normalizadas” por IDS; y dichas entradas deben ser re-normalizadas para cumplir los requisitos de un destino. Este proceso, en el caso de imágenes o vídeos es sumamente costoso para los procesadores; de modo que hemos pensado en la posibilidad de que un canal receptor de IDS, que necesariamente debe “descomponer” la entrada (supongamos, una imagen) para aplicar perfiles de color, hacer transformaciones de formatos; podría ahorrar muchos ciclos de reloj en otras máquinas de la red si supiera comprender un mapa VAR y aplicarlo.

En virtud de ello, hemos dotado a los canales IDS de la potestad de entender los mapas de autoenrutado y preparar los paquetes de transmisión en el mismo momento en el que procesa la entrada; dejando todo preparado para que un transmisor ODS pueda enviarlo a los destinos sin más que ocuparse del control de los medios físicos a donde deben ir.
Es muy sencillo de configurar; editando el canal, en la pestaña de Tratamiento de salida; buscar la opción de “Funciones de enrutamiento”. Al poner el estado a true nos obligará a establecer el mapa que vamos a aplicar a esa entrada; y, si al procesar la entrada ésta coincide con los valores del mapa, preparará los paquetes de preproceso para los envíos .. simple, no?

En la captura se puede ver como, después de haberla ingresado al sistema desde una entrada; se preparan los paquetes de transmisión. En términos generales entonces (y siguiendo con el ejemplo de la imagen), los procesos que realiza un canal IDS en estas condiciones son:
- Detección de una nueva imagen
- Aplicación del perfil de normalización
- Generación de previews y thumbnails
- Registro en la base de datos
- Análisis y aplicación del mapa
- Aplicación de perfiles de normalización de salida (que en muchos casos coincide con el de entrada)
- Generación de paquetes de salida
- Registro en la base de datos

Dbyse ha implementado tres diferentes maneras de acceder a los datos:

• El tradicional, donde el Core del sistema accede directamente a la base de datos SQL (normalmente MySql) mediante una tradicional conexión ODBC, recolecta los datos y devuelve un XML al cliente que los ha solicitado.
• A través de una implementación parcial de Solr, en donde los contenidos se alojan en el motor SQL pero se indexan en Solr. Esta opcion resulta ser sumamente eficiente, incluso en instalaciones con varios millones de registros.
• Alojando los contenidos completamente en Solr y en el motor SQL unas referencias que apuntan a ello; es decir, el motor NonSQL tiene toda la responsabilidad del acceso a los grandes volúmenes de texto indexados, justo como se puede esperar en instalaciones de envergadura; donde se dispone de la funcionalidad de archivo con decenas de millones de artículos; esta opción es la adecuada.

Desde un punto de vista estrictamente práctico, la configuración en todos los casos, es sumamente simple. Si Solr se encuentra presente en la instalación; las opciones de indexación estarán disponibles en el configurador; caso contrario, infoData indexará de la manera tradicional; utilizando toda la potencia del motor SQL, y en los casos en los que es posible, fullindextext.

- Sin sobrescribir los contenidos alojados en el sistema: El usuario obtiene la traducción de su artículo, puede editarla o no y luego salvar o no los cambios, valiéndose de la ayuda de tooltips que muestran el texto original.

- Duplicando el artículo en uno traducido: En este caso, se duplica el artículo original generando otro con la traducción. Esta acción puede estar sujeta a diferentes otras acciones que pueden programarse mediante el metalenguaje del que el sistema dispone; por ejemplo, asignando un nuevo “creador”, alterando algún otro dato de la ficha o asignando una fase concreta para que, por ejemplo; la traducción sea revisada por otro usuario.

Hemos publicado un artículo entero acerca del uso de las tareas programadas, de modo que sólo mencionaremos que a cada acción relevante que llega al servidor desde un usuario; como eliminar un ítem, colocarlo en una cesta, imprimir, etc.; puede asociarse una listas de tareas mediante la utilización de un metalenguaje que permite capturar el evento antes y después de la acción; analizar y validar esa lista y ejecutar las acciones, que pueden ir desde escribir un fichero XML en alguna parte hasta notificar a un web service externo de la acción; pasando por, por ejemplo; generar una traza en el artículo hasta enviar un correo con un texto determinado.

Ir al inicio

Finalmente; inspirados y motivados por los buenos resultados obtenidos desde ese punto de vista en nuestro cliente IDM+, hemos decidido dotar de un aspecto más moderno a nuestras aplicaciones cliente.
Ahora, todas (Configurator, IDS, ODS, VAR, IDM) disponen de un menú como el de la ilustración; que permite darle a cada módulo un “sabor” más moderno y actual.

En particular, IDM+ es algo diferente a las demás; ya que se halla escrita en otro lenguaje de programación, e incorpora el estilo también a los formularios, menúes y botones; pero en todos los casos se ha respetado la estética y combinación de colores de Office2007, aunque en el caso particular de IDM también se utilizó un menú en la barra superior conocido como Ribbon Bar; que incorpora unas prácticas pestañas donde se han alojado preferencias de usuario, filtros y otras cuestiones relacionadas con configuración personal.

• De agencia: Servicio, proveedor, fuente, créditos, autor, campos UNO, clasificación temática, instrucciones especiales y Copyrights entre otros
• Fechas: De creación, de transmisión, de embargo, de entrada y última modificación y transmisión otras de interés.
• Contenido (la que nos atañe en este artículo): Enumera una gran cantidad de detalles técnicos e información inherente al ítem; tanto si se tratara de un texto, foto o vídeo.
• Transmisiones: Lista de las veces que se ha transmitido a destinos, por quien, que canal y otros detalles como el estado actual de las mismas.
• Historia: Un preciso log de transacciones de acciones con el ítem; desde abrir para ver hasta la edición o impresión, con un detalle del usuario y terminal desde donde se ordenó dicha acción.



En la captura asociada al artículo se puede apreciar un detalle de los datos obtenidos de una imagen tipo JPG y un vídeo de tipo flash. Cabe suponer que la información técnica varía conforme al formato de la entrada; y el sistema conserva los valores obtenidos antes de ser procesado y después de aplicar el perfil de normalización en la entrada, a efectos de poder comparar y detectar alguna anomalía en la configuración o resolver una inquietud acerca de los detalles del material recibido.

Algunos de los nuevos valores añadidos surgen de las nuevas capacidades de IDS de poder extraerlos y gestionarlos; como por ejemplo, el color profile o el chroma subsampling en el caso de fotos; o el tipo de muestreo de audio en el caso de vídeos. Todo esto es posible desde el momento que dbyse consiguió explotar al máximo sus bibliotecas del engine gráfico, basadas en little cms, ffmpeg e image magick.



Esperamos poder seguir sorprendiéndolo con nuestras propuestas; y, desde luego, estamos completamente receptivos a escuchar vuestras ideas. Puede enviarnos sus sugerencias pinchando aqui.


Ir al inicio




]]> http://www.dbyse.com/?feed=rss2&p=490 3