viernes, 24 de febrero de 2012

Semántica de Información

La semántica se ocupa de los significados, los sentidos, las interpretaciones.
(La imagen está tomada de la Web estudiantil española eolapaz, ganadora de varios
premios: http://www.eolapaz.es/domo-letras/lengua-semantica.htm)
Intentamos aquí abordar el tema sofisticado que expresa el título de este post para ilustrar, en forma adicional a lo ya conversado en oportunidades anteriores, como una semántica de información trae consigo facilidades derivadas del uso del conocimiento que en forma tácita comparten los gerentes de información. A propósito del trabajo en Arquitectura de Información, nos hemos referido varias veces a las diferencias entre los modelos que construyen los Arquitectos de información cuando los comparamos con los modelos informáticos que realizan los ingenieros. Estos últimos construyen sus representaciones de información y de sistemas de información a partir de una semántica de datos. De allí que la interacción con ellos suele resultar un poco complicada para las personas que están al frente de los servicios y son responsables de ellos ante la institución y los usuarios. De manera alternativa, los Arquitectos de información trabajan directamente en el dominio de la información, lo que constituye una aproximación diferente al diseño de modelos y aplicaciones.

Cuando se construyen modelos de información con herramientas informáticas se usa muchas veces, en forma implícita, una semántica de datos. Ésta trae beneficios porque proporciona significados que no tienen que aclararse acerca de lo que ciertos tipos de datos son. Por ejemplo, los que trabajan con datos saben siempre lo que es un número entero, un número real con decimales, una cadena de caracteres, una fecha, una hora, etc. Basta clasificar de esta manera un dato dado para saber que es lo que podemos esperar de él como dato. Entre otras cosas, los valores que puede tomar una variable y los valores que no. Por ejemplo, un número entero decimal no puede valer “García”. Una fecha no puede valer 2015-32-59, un número de horas no puede valer “Pancrasio”.

Esta semántica de datos es muy útil, pero es demasiado precaria para construir modelos de información. Los informáticos y los ingenieros de software, trabajan con este tipo de semántica y definen tablas de datos vinculados y luego relaciones de estas tablas de datos entre si de diversas maneras. Normalmente a través de un lenguaje matemático muy preciso construyen modelos de entidades y relaciones y definen los objetos con los que modelan la realidad. Es un trabajo muy minucioso y elaborado que suele estar lleno de complicaciones y que, como hemos mencionado, plantea intrínsecamente dificultades serias para la comunicación de estos modelos informáticos a las personas que no tienen esa formación.

En forma cualitativamente diferente los Arquitectos de Información desarrollan sistemas. También crean modelos, pero esta vez la aproximación a la representación de información es a través de una semántica que proporciona interpretaciones tácitas en el propio dominio de la información y que por tanto simplifica el diseño de estructuras, la definición de los métodos para manejar la información y la comunicación de las ideas.

Los Arquitectos de información trabajan con objetos de información, un concepto que hemos estado explicando en nuestros últimos post (Ver Estructuras de Información, qué son y para qué se usan, La lista de objetos de información y el Arquitecto de Información y Propiedades de Objetos de Información). La idea para un Arquitecto de información es mantenerse dentro de las asociaciones, relaciones y métodos con los que en general manejamos información. Por ejemplo, siempre que hablamos de autores sabemos que éstos son personas naturales o entes jurídicos y que pueden ser uno o varios, tener roles, direcciones físicas y electrónicas, etc. Si esto no cambia no hay que aclararlo sino que se puede seguir adelante con sólo decir: “este objeto (de información) tiene un autor”. Así, si hablamos de fecha en el dominio de la información, no sólo sabemos que es una secuencia de caracteres de la forma aaaammdd o dd-mm-aaaa, por ejemplo, sino que sabemos que las fechas representan una manera de ordenar cronológicamente la información, que con ellas podemos colocar los contenidos de información en un calendario, que podemos definir períodos, cruzarlas con otros datos, etc. Todo esto es conocimiento tácito que no requiere definiciones adicionales en el dominio de la información.

En fin, para el común de los mortales trabajar directamente en el dominio de la información es más sencillo que trabajar en el dominio de los datos. La comunicación a este nivel es mayor y más fácil y es por ello que los modelos que realizan los Arquitectos de Información resultan normalmente más sencillos de entender y de trasmitir y los proyectos más fáciles de seguir.

viernes, 17 de febrero de 2012

Propiedades de Objetos de información

Los objetos de información tienen propiedades que sirven para identificarlos,
para clasificarlos o como contenedores de ciertos datos
¿Cómo caracterizamos los objetos de información una vez que tenemos una primera lista de ellos realizada como primer paso en el diseño de una Arquitectura de Información? ¿Cuáles son los distintos tipos de propiedades de estos objetos de información? ¿Cuál es la diferencia entre la caracterización de propiedades en el dominio del dato, como la hace el informático y lo que hace el Arquitecto de información, en el dominio de la información? Estas son las preguntas que abordamos hoy, profundizando en torno al concepto de Objetos de información, una tarea clave dentro de lo que es la determinación de la Estructura de Información que subyace en un problema de gestión.

En efecto, después de darle un nombre e incluirlo en una lista, lo siguiente que hacemos con un objeto de información es especificar sus propiedades. Ahora bien, los campos, propiedades, o metadatos de un objeto de información pueden ser de distinta naturaleza. En principio, de tres grandes tipos: Identificadores, Clasificadores o Contenedores.

Los identificadores son propiedades únicas del objeto que las usamos para accederlos, llegar hasta ellos, distinguirlos, separarlos, en decir, identificarlos entre el conjunto de elementos de su clase. Por ejemplo, los nombres, apellidos, títulos, el número de identificación de una persona, la clave de acceso, el número de id, la cota de un libro, el número de inventario de un item, etc. Algunos de ellos pueden ser identificadores únicos, otros, como por ejemplo, los nombres o los apellidos de una persona, o el título de un libro, no tienen por que serlo. Aún en los casos en que estos elementos tienen una cierta ambigüedad, los usamos comúnmente para identificar, es decir, para distinguir un objeto del resto.

Otro tipo de propiedades son los clasificadores. Nuestra intención con ellos no es identificar. Los clasificadores son elementos que usamos para describir un objeto de información, pero que adicionalmente nos sirven para agruparlos con otros objetos de información relacionados y por tanto para clasificarlo. En algunos contextos los llamamos descriptores, porque se usan para describir propiedades fundamentales, pero hay que tomar en cuenta que sólo podemos considerarlos clasificadores si pensamos que la propiedad que denotan es compartida con otros objetos. Los clasificadores pueden ser de distintos tipos: temáticos (infancia, actualidad, democracia,…), geográficos (España, México, Mérida, África, Suramérica…), administrativos (personal de tipo X, miembro A, revisado, por revisar, en cuenta,…), onomásticos (Simón Bolívar, Francisco de Paula Santander, George Washington,…), etáreo (primera infancia, adolescencia,…), Autores (incluyendo principal, secundario, ilustrador,…), etc.

Los Contenedores son propiedades que son específicas de una determinada instancia de un objeto, pero que por alguna razón, como por ejemplo su longitud, no las usamos para identificarlos. Por ejemplo, el resumen de un libro, el curriculum de una persona.

A simple vista podría parecer que el trabajo de asignación de campos o propiedades a un objeto de información de la que hablamos es igual a los que hacen los informáticos en el diseño de bases de datos, pero no es así. El arquitecto trabaja en el dominio de la información mientras que el ingeniero lo hace en el dominio de los datos. En una base de datos no hay semántica de información en las propiedades. En los campos de un objeto de información si. Cuando le asignamos a un objeto de información que representa una obra de arte una fecha, va implícita que esta fecha puede colocarse en un calendario o en una línea de tiempo, de un objeto o de una lista de ellos, por ejemplo, las obras de un autor, o de un conjunto de autores de un estilo o tendencia dada. Cuando asignamos una propiedad autor a un objeto de información, va implícito, semánticamente, que este autor es una persona y que por tanto tiene atributos de persona, por ejemplo, año de nacimiento, correo (si está vivo), etc.

Sintentizando lo que trabajamos hoy con el punto de la semana pasada (Ver La Lista de objetos de información y el Arquitecto de Información): la Arquitectura de Información comienza identificando la Estructura de Información que subyace en un problema y ésta enumerando los objetos de información y sus propiedades generales. Con ello empezamos a entender la solución, sin ellos es difícil decir que entendemos el problema. Lo que no interesa al arquitecto es el detalle de todas las tablas de datos de organización informática que se requerirán, sino, en vez de ello, las propiedades que tienen atributos semánticos en el dominio de la información.

viernes, 10 de febrero de 2012

La lista de objetos de información y el Arquitecto de Información

Cada problema de gestión es descrito en el dominio de la información
con una estructura de objetos de información vinculados.
Fotografía del cúmulo globular M2, con su cerca de 100.000 estrellas,
por debajo del polo sur de la Vía Lactea
(Foto tomada del http://Observatorio.info)
La semana antepasada hablamos de las 5 dimensiones básicas de la Arquitectura de Información. La semana pasada comenzamos a trabajar con la primera de ellas: la Estructura de Información. Una visión adecuada de ésta es un paso fundamental en el diseño de un buen servicio en la Web. Manteniéndonos en esta primera dimensión nos enfocamos en esta oportunidad en el cómo comienza el trabajo a nivel de Arquitectura de Información (AI): la actividad esencial de identificar los objetos de información que son relevantes en el problema. También señalamos el por qué el trabajo de detalle a nivel de diseño de base de datos, aunque puede ser en algún momento una necesidad crítica de la implementación informática, no es lo que ocupa las energías de los Arquitectos de Información. En otras palabras, yendo de lo general a lo particular, queremos seguir profundizando, aportando cada vez más elementos acerca del cómo se mueven conceptualmente los profesionales que realizan AI y, en particular, cómo usan, estratégicamente, el concepto de “Objetos de información” en el desarrollo de soluciones bien diseñadas.

Ante un problema de información, lo primero, como dijimos, para un Arquitecto (de información, se entiende!), es identificar los objetos de información relevantes en el problema y la solución. Se trata de determinar cuáles son los elementos que entran en el juego.

Por ejemplo: Si se trata de una biblioteca tenemos libros, tesis, revistas, usuarios, personal, etc. Si se trata de la gestión de comunidades de un colegio tenemos estudiantes, personal docente, personal administrativo, personal directivo, mientras que si se trata de la gestión académica tenemos el año, las secciones, las materias, los estudiantes, los profesores, las planillas de notas. Si se trata de un club, tenemos, quizá, miembros A, miembros B, público en general. Si se trata de un sitio de promoción de turismo regional tenemos hoteles, posadas, restaurantes, turistas, propietarios, etc. Es decir, siempre hay unas entidades que son las centrales para describir el problema de información cuya gestión queremos resolver. Esos son los objetos de información.

Una lista de los objetos de información pertinentes es lo primero que tenemos que lograr cuando queremos diseñar un sitio Web adecuadamente. Cómo Arquitectos debemos conocer cuanto antes cuáles son los elementos básicos del problema sobre el que trabajamos. En una primera mirada al problema de gestión, lo que nos interesa es tener la lista completa, ya que ella nos dará una idea preliminar de la Estructura de información con la que trabajaremos. Hay que asegurar que no quede ningún objeto de información que sea esencial para la solución adecuada y que no lo hayamos tomado en cuenta, ya que esta lista nos dará la primera aproximación a la sencillez o complicación estructural de un problema.

Puede haber etapas en la implementación y puede ser por ello que algunos elementos hayan sido omitidos inicialmente, dejados para considerarlos en el detalle en una próxima etapa. Eso no significa que fueron ignorados. En ese caso el trabajo con ellos fue simplemente postergado. Por ejemplo, en la gestión de un colegio podemos tener una gestión administrativa y una académica, que pueden ser trabajadas con bastante independencia, una en la primera fase y otra luego.

Así como el informático siempre sabe que cualquier problema de información le va a plantear el desarrollo de una base de datos y que típicamente seguirá un esquema de Entidad-Relación para expresar las tablas de datos relacionales que entran en juego, el Arquitecto tiene una aproximación diferente, no de datos, sino de información. Su problema es resolver la gestión en el dominio de la información y para ello sabe, como hemos visto, que tiene que moverse en un espacio de 5 dimensiones, donde la primera de ellas es Estructura de Información y dentro de ella lo primero que hay que determinar es la lista completa de objetos de información.

Una vez que tenga la lista, lo siguiente es determinar las propiedades de estos objetos. Qué campos o metadatos debemos identificar en cada uno de ellos. Normalmente las herramientas modernas permiten hacer cambios en caliente y registrar aproximaciones sucesivas en la descripción de un problema, pero siempre nos interesa llegar a tener una primera lista, lo más completa posible, de los objetos y de sus propiedades. Otros detalles vendrán después. En nuestro caso, en nuestro próximo post.

viernes, 3 de febrero de 2012

Estructuras de información. Qué son y para qué se usan

La Estructura de Información es la dimensión donde se da soporte a la
Arquitectura de Información. En ella se definen objetos de información
y asociaciones que se integrarán en la solución
(Fotografía de una estructura del Arquitecto Japones Shigueru Ban tomada de
http://www.ignaciourbina.com/blog2012 )
En nuestro último post estuvimos conversando acerca de las 5 dimensiones de la Arquitectura de Información. Se llaman así porque lo que se define en estos aspectos conforma y coloca un sello fuerte en el resultado del servicio de información que se construye, pero cada uno de los 5 tópicos citados (Estructura de información, Funcionalidad, Navegación, Comunidades y seguridad e Imagen y estética) puede trabajarse con gran independencia de los otros. De entre estas dimensiones, la primera y la más básica es la de las Estructuras de Información. A ella dedicamos este post. ¿A qué nos referimos entonces cuando hablamos de objetos de información? ¿Por qué en Arquitectura de Información no usamos el lenguaje de los informáticos y computistas? ¿Qué hay inadecuado para el Arquitecto de Información o el Gerente de un servicio que no resulta así para el ingeniero? Son preguntas que esperamos responder hoy.

El tema debe comenzar a examinarse desde la gestión de datos. Éstos están siempre presentes en la información ya que ésta, en última instancia, está compuesta de datos. Pero la información es mucho más que la suma de datos. La información tiene estructura, tiene asociaciones y tiene semántica asociada a los datos. Es decir, no se trata solamente de un conjunto de contenidos. Por eso un administrador de archivos o de contenidos no es un administrador de información. En la información la estructura, las relaciones, las interpretaciones asociadas a los datos son claves.

Los ingenieros de software saben que los contenidos que constituyen la información, más temprano que tarde, terminan alojándose en bases de datos, sistemas diseñados para manejar tablas con valores de tipos predefinidos de una forma que resulta consistente, eficiente, práctica. Las bases de datos aíslan a los informáticos de tener que rediseñar procesos de gestión de datos cada vez que asumen un proyecto diferente, porque los llamados manejadores de bases de datos (DBMS, por sus siglas en inglés) tienen la inteligencia necesaria para hacer los procesos típicos, de rutina, sobre cualquier tabla de datos: Almacenar un contenido, buscarlo, recuperarlo, ordenarlo, asociarlo con otro, eliminarlo, etc.

El problema está en que cuando un gerente resuelve un problema de información, este manejo, a nivel del dato, es demasiado básico, demasiado atomizado, demasiado distante de la realidad para un responsable de servicios que tiene que ocuparse de problemas macro o de más alto nivel de gestión. Se trata además de alguien que requiere de tecnología, pero que no necesita ni desea profundizar en detalles excesivos que tienen que ver más con ella que con la gestión de información.

Por eso un Arquitecto de Información, un Coordinador de servicios, un Gerente, es una persona que necesita una abstracción mucho mayor que la del dato. Su mente debe mantenerse circunscrita a los objetos de información. ¿Qué son pues objetos de información? Son estructuras de información que representan entidades claramente identificables en la realidad de un problema. Por ejemplo: estudiantes, profesores, empleados, obreros, pueden ser objetos de información relevantes para administrar lo que tiene que ver con las personas que hacen vida en una institución académica. Artistas, Pinturas, Esculturas, Amigos de la institución y Público pueden ser los objetos de información relevantes para trabajar en el sitio Web de un museo. Personas, Testigos, Autoridades civiles, Partidas de Nacimiento, Actas de matrimonio, Actas de defunción pueden ser los objetos de información necesarios para trabajar en los aspectos centrales de un Registro Civil.

Puede verse que cuando un Arquitecto de información se mueve a nivel de objetos de información puede concentrarse en las estructuras de información que resultan básicas o elementales para trabajar en el área de conocimiento planteada por el problema de información a resolver. En cada tipo de objeto de información pueden distinguirse múltiples campos, metadatos o elementos variables que definen propiedades o contenidos específicos de sus instancias. Esta persona se llama Carlos Daniel Jiménez, tiene 32 años, nació en Quito, Ecuador, vive en Bogotá, Colombia, es Médico, trabaja en la sede principal del Ministerio de Salud, etc. Todos estos son datos que caracterizan a una persona en particular. Para trabajar a nivel de bases de datos hay que pensar en donde, en qué tablas específicas se guardan todos estos datos y como se relacionan entre si todos ellos y todas esas tablas de datos. Típicamente esto es demasiado detalle y complejidad para el trabajo de Arquitectura de Información.

Así como para diseñar una casa normalmente necesitamos saber donde queda, las características del terreno, el presupuesto y las necesidades y gustos del tipo de persona que la usará, pero no todos sus datos: sus nombres, sus fechas de nacimiento exactas, la dirección de su trabajo, etc., así para trabajar en Arquitectura de Información se comienza identificando los objetos de información, las estructuras de información relevantes en el problema, lo cual es mucho más sencillo, práctico y útil.

En un próximo post nos referiremos a cómo se usan estos objetos de información.