Los procesos ETL son probablemente los componentes más importantes y de mayor valor añadido en una infraestructura que implique la integración de varias fuentes de datos. En consecuencia, representan un pilar fundamental tanto de simples proyectos de recopilación como de soluciones complejas de Big Data o Business Intelligence, especialmente si se requiere mucha precisión o actualización en los datos.

Aunque suelen resultar transparentes a los usuarios, los procesos ETL son los encargados de recuperar información de todos los orígenes necesarios, formatearla, limpiarla e integrarla en un datamart, un datawarehouse, una base de conocimiento o cualquier otro tipo de repositorio digital. En resumen, los procesos ETL recopilan los datos y hacen posible que la información subyacente pueda ser presentada mediante las herramientas de análisis y reporting pertinentes. En el caso de Classora, los propios robots son los encargados de complementar y enriquecer cada dato con los metadatos correspondientes (fecha de carga, fuente, fiabilidad del dato, frecuencia de refresco, significado, relaciones… etc.) que permiten su posterior procesado y recuperación.

Como su propio nombre indica, los procesos ETL se dividen en tres fases:

• Extracción: consiste en obtener los datos del sistema origen, realizando volcados completos o incrementales. En ocasiones esta etapa suele apoyarse en un almacén intermedio, llamado ODS (Operational Data Store), que actúa como pasarela entre los sistemas fuente y los sistemas destino, y cuyo principal objetivo consiste en evitar la saturación de los servidores funcionales de la organización.
• Transformación: los datos procedentes de repositorios digitales distintos no suelen coincidir en formato. Por tanto, para lograr integrarlos resulta imprescindible realizar operaciones de transformación. El objetivo no es otro que evitar duplicidades innecesarias e impedir la generación de islas de datos inconexas. Las transformaciones aplican una serie de reglas de negocio (o funciones) sobre los datos extraídos para convertirlos en datos destino.
• Carga: se trata de introducir los datos, ya adaptados al formato deseado, dentro del sistema destino. En algunos casos se sobreescribe la información antigua con la nueva, mientras que en otros se guarda un historial de cambios que permite consultas retrospectivas en el tiempo, así como revertir modificaciones. Para la carga masiva de datos suele ser necesario desactivar temporalmente la integridad referencial de la base de datos destino.

Para los que nos dedicamos profesionalmente a la monitorización continua de fuentes Open Data disponibles en Internet, existen numerosos desafíos si queremos implementar unos procesos ETL eficaces y fiables, que se pueden resumir en los siguientes puntos:

• Los volúmenes de datos están creciendo de forma exponencial, especialmente los que se vierten de manera incesante sobre Internet. Precisamente para cosas como ésta nacieron las soluciones Big Data. Por su parte, la Web Semántica, de la que ya hemos hablado en anteriores ocasiones, es un intento de poner orden y organizar este vertido constante de información desestructurada a la Red.
• A mayor disparidad de fuentes, mayor dificultad de integración, a medida que los sistemas de información crecen en diversidad, también aumenta la complejidad de su integración. Crear reglas de transformación customizadas para cada nueva fuente supone un esfuerzo manual inviable en sistemas que pretenden ser escalables. De ahí, una vez más, la patente necesidad de respetar estándares como RDF o XML para publicar información.
• Las transformaciones implicadas pueden llegar a ser muy complejas. Los datos necesitan agregarse, analizarse, computarse, procesarse estadísticamente… etc. En ocasiones también se necesitan transformaciones demasiado costosas desde el punto de vista computacional. Los procesos ETL necesitan una mayor flexibilidad para conseguir respuestas en tiempo real.

Actualmente, existen herramientas comerciales, e incluso de software libre, con una gran potencia para la extracción de datos. De hecho, los problemas de rapidez y rendimiento no suelen suponer hoy en día un gran escollo técnico para la extracción y la carga. Donde realmente se sitúa el cuello de botella es en la transformación de datos: en este punto la información desestructurada debe ser convertida en información estructurada para poder ser integrada con el resto de los datos que ya existen en el sistema destino. De hecho, la automatización de este proceso es sólo uno de los grandes retos de la Web Semántica.

El caso de Classora Knowledge Base

Para que la base de conocimiento de Classora tenga información actualizada y realmente útil es necesario que se nutra constantemente de datos disponibles en distintas fuentes públicas. De hecho, dada la amplitud proyecto, estas fuentes pueden oscilar desde plataformas de referencia oficiales y completamente estructuradas (como es el caso de Eurostat, el Instituto Nacional de Estadística, o la FIFA) hasta fuentes no oficiales, escritas en texto plano o dotadas de escasos niveles de estructuración (como pueden ser blogs, noticias de medios digitales o incluso la propia Wikipedia). Con este fin, Classora Technologies ha desarrollado tres tipos de robots para la gestión de datos:

• Crawlers de extracción: encargados de la carga masiva de informes a partir de fuentes públicas oficiales. Sirven tanto para cargas absolutas como incrementales.
• Exploradores de datos: encargados de buscar y actualizar atributos concretos de una unidad de conocimiento a partir de una fuente determinada.
• Agregadores de contenidos: no se conectan a fuentes externas, sino que utilizan datos internos de Classora para generar nueva información (histórica, agregada… etc.).

No obstante, en valores absolutos, los millones de unidades de conocimiento que atesora Classora Knowledge Base son una cantidad minúscula de la información pública realmente disponible en La Red. Además, como hemos visto antes, cada nueva fuente de datos incorporada aumenta la complejidad de la integración con los datos previamente cargados, ya que se incrementa el número de transformaciones. Sin una supervisión manual (cada vez más costosa e inviable), esto se traduce a medio plazo en que la calidad de los datos puede disminuir a medida que crece la cantidad de los mismos.

Sin embargo, estas limitaciones se pueden paliar parcialmente con un mayor esfuerzo en I+D+i. Por ello, nuestra empresa plantea un proceso de mejora continua para los robots de carga que permitan incorporar más fuentes de datos, con menor nivel de estructuración, en más idiomas, y con una mejor integración con los datos previamente cargados. El problema original al que nos enfrentamos es, en el fondo, uno de los mayores retos que ha impuesto la evolución tecnológica: la transformación de información desestructurada a información estructurada.

Más acerca de los procesos de Extracción, Transformación y Carga

Si te interesa saber más sobre el tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Esperamos haber conseguido despejar algunas dudas sobre los procesos ETL, tan importantes para muchos proyectos de Big Data, Open Data, Linked Data y Business Intelligence, y que sin embargo suelen permanecer en la sombra, pasando desapercibidos para el usuario que los utiliza en última instancia.

Los metadatos son simplemente datos sobre datos, es decir, información estructurada que describe a otra información y que nos permite encontrarla, gestionarla, controlarla, entenderla y preservarla en el tiempo.

Los metadatos no son un concepto nuevo: la inclusión de metadatos es el método utilizado tradicionalmente en el mundo de las bibliotecas para gestionar libros y archivos. Sin embargo, el nacimiento de la informática y, más concretamente, las posibilidades de intercambio de información surgidas en torno a la Web Semántica, hizo que aumentara la popularidad del término. Del mismo modo se hizo patente la necesidad de describir estándares.

Para ilustrar su utilidad, podemos ver unos sencillos ejemplos de metadatos empleados por Classora Knowledge Base. Si tomamos una unidad de conocimiento como Fernando Alonso, vemos que tiene asociados diferentes atributos en su ficha: fecha de nacimiento, profesión, carreras en F1… etc. Cada uno de estos atributos dispone en Classora de un conjunto de metadatos asociados como el que se describe a continuación:

• Tipo de dato: indica si es una fecha, un valor numérico, otra unidad de conocimiento, una cadena de caracteres… etc. Por ejemplo: la fecha de nacimiento es de tipo DATE, la profesión es de tipo KNOWLEDGE-UNIT y el nº de carreras es de tipo INTEGER. En general, tener los datos tipificados resulta imprescindible en cualquier base de datos estructurada.
• Unidades: indica las unidades en las que está medido el dato, si procede. Por ejemplo, la fecha de nacimiento y la profesión no tienen unidades asociadas, mientras que el nº de carreras tiene una unidad específica para indicar que se trata de eventos de Fórmula 1.
• Modalidad de carga: indica si el dato fue cargado manualmente (por un miembro de Classora Technologies o por un usuario del portal público de datos) o bien si fue cargado automáticamente (a través de los robots de carga -crawlers- de Classora).
• Autor: indica, si procede, la persona o el bot que modificó el dato por última vez.
• Fecha de actualización: indica la fecha de la última vez que se modificó el dato.
• Fuente: indica la fuente de donde se extrajo el último valor del dato.
• Frecuencia de refresco: indica la periodicidad con la cual los robots de Classora deben conectarse a la fuente original de datos para mantenerlo actualizado. Por ejemplo, la fecha de nacimiento de Fernando Alonso es un dato constante (es decir, no necesita ser actualizado), mientras que el nº de carreras disputadas en F1 es un dato que es necesario contrastar en las fuentes originales cada 15 días.
• Fiabilidad: hay datos que están disponibles en más de una fuente. Por ejemplo, la fecha de nacimiento de Fernando Alonso puede estar disponible en la Wikipedia en inglés, la Wikipedia en español, la página de la FIA, y Freebase. Con los metadatos adecuados, los robots pueden saber que se trata del mismo dato y evaluar si su valor coincide en todas las fuentes. Por ello, si tres de las cuatro indican la misma fecha, podría establecerse una fiabilidad aproximada del 75%. Otro tema muy importante en este sentido es el orden y la actualización de las fuentes. Por ejemplo, si el mismo dato está disponible en dos fuentes diferentes, pero su valor no coincide… ¿cuál se escoge de entre los dos? Para ello Classora utiliza la precedencia de las fuentes, que establece cuales son, a priori, más fidedignas. Por ejemplo, en el caso de la Wikipedia, los bots de Classora siempre otorgan mayor precedencia a la versión inglesa que a la española.
• Significado: es probablemente uno de los metadatos más importantes, ya que permite que el dato sea interpretado automáticamente vía software. Classora sabe que el 29 de Julio de 1981 es la fecha de nacimiento de Fernando Alonso, que es un piloto de F1. Por tanto, es posible crear un informe vía CQL que devuelva todos los pilotos de F1 nacidos en ese año.
• Historial de cambios: entre los metadatos de cada unidad de conocimiento se encuentra una lista con los valores anteriores de cada atributo, incluyendo también para cada caso la fecha en la que fue incluído el valor, su autor… etc. Se trata de tener una perspectiva histórica de los cambios tanto para fines consultivos como para fines preventivos (posibilidad de recuperarse de ataques o deshacer aportaciones incorrectas).

Esta capa de inteligencia basada en metadatos es lo que hace que el repositorio digital de Classora sea considerado una base de conocimiento, y no solo una base de datos.

Tipos de metadatos

En general, los metadatos pueden clasificarse en tres amplias categorías con límites no siempre bien definidos, y muchas veces superpuestos:

Metadatos descriptivos: son aquellos que sirven para la descripción e identificación de los recursos de información. Permiten la búsqueda y recuperación de los datos, así como distinguir recursos y entender sus contenidos. Se realizan mediante estándares como Dublin Core, estándares MARC, microdatos de HTML… etc.

Metadatos estructurales: son los que más influyen en la recuperación de la información, facilitando la navegación y presentación de los recursos. Ofrecen información sobre su estructura interna y permiten establecer relaciones entre ellos, de manera que pueden incluso unir los archivos de imagen y textos que están relacionados. Los estándares más difundidos para en este sentido son SGML, RDF y EAD (Encoded Archival Description).

Metadatos administrativos: incluyen datos para la gestión de derechos, firma digital, auditorías de calidad, control de acceso mediante contraseñas… etc. También se podrían enmarcar en esta categoría los metadatos sobre preservación a largo y corto plazo. Ejemplo, imágenes DICOM que incluyen metadatos como: tipo y modelo de escáner utilizado, resolución, paciente, limitaciones de reproducción… etc.

Dublin Core y otros estándares

Dublin Core es probablemente el estándar de metadatos más extendido. Su nombre hace referencia a Dublín (Ohio, Estados Unidos), ciudad que en 1995 albergó la primera reunión a nivel mundial de muchos de los especialistas en metadatos y Web de la época.

Dublin Core describe material digital como videos, sonidos, imágenes, textos y páginas web. Para ello utiliza básicamente XML, HTML y RDF. Además, proporciona un conjunto de convenciones simples y estandarizadas para describir recursos de forma que se facilite su encuentro online. Para la transmisión de datos, tiene asociado el protocolo OAI-PMH.

Dublin Core está gestionado por la DCMI (Dublin Core Metadata Iniciative), una organización que trata de fomentar la adopción de estándares y generar un foro abierto para el desarrollo de vocabularios especializados en describir recursos, que permitan sistemas de recuperación más inteligentes.

La siguiente tabla es una recopilación no exhaustiva de algunos de los más importantes estándares para metadatos que se han generado hasta el momento.

En definitiva, tal y como hemos comentado en otras ocasiones, si estás interesado en este tema, no dudes en contactar con nosotros para que te hagamos llegar más enlaces y documentación adicional. Desde Classora Technologies quedamos completamente a tu disposición.

Con este post finalizamos la descripción de los tres estándares fundamentales para la Web Semántica: RDF, SPARQL y OWL.

No obstante, dada su importancia en este texto, antes de seguir deberíamos recordar qué es una ontología, ya que se trata de un concepto que en algunas ocasiones es difícil de explicar:

Una ontología es un conjunto de reglas que permiten describir y representar el conocimiento de un determinado contexto o dominio. En la práctica, lo único que hacen estas reglas es definir conceptos básicos y las posibles relaciones entre ellos. Las ontologías son utilizadas por personas, bases de datos y aplicaciones software que necesitan utilizar o compartir información en un determinado sector (medicina, economía y finanzas, deportes… etc.).

OWL: Web Ontology Language

Como su propio nombre indica, OWL es un lenguaje para crear ontologías en la Web. Si bien existían lenguajes ontológicos previos, especialmente destinados a temas científicos y aplicaciones de comercio electrónico, no fueron definidos para ser compatibles con la arquitectura de la World Wide Web en general, y de la Web Semántica en particular.

Para que la Web Semántica funcione, los ordenadores deben tener acceso a bases de conocimiento y conjuntos de reglas de inferencia que puedan utilizar para llevar a cabo un razonamiento automatizado. Sin embargo, la representación del conocimiento se encuentra actualmente en un estado comparable al del HTML antes del nacimiento de la Web: es claramente una buena idea, y existen algunas demostraciones prácticas prometedoras, pero todavía no se ha extendido ni ha cambiado el mundo. Para desarrollar todo su potencial debe existir un estándar y estar conectado a un sistema global único. El lenguaje OWL es ese estándar, ya que sin él, otros lenguajes como RDF perderían su potencia al representar conocimiento de manera aislada.

Como referencia para evaluar el esfuerzo que se está llevando a cabo en este sentido a nivel mundial, cabe destacar que detrás de OWL y de los demás estándares de la Web Semántica (RDF y SPARQL) están varias empresas y organizaciones punteras. Entre ellas figuran el Gobierno de los EEUU (a través de DARPA y la NSF) y la Unión Europea (mediante las infraestructuras de 5ª y 6ª generación del programa IST).

Un caso práctico de ejemplo

Veamos un ejemplo básico de OWL. Cabe destacar que, de manera estrictamente resumida, OWL permite definir clases, relaciones entre clases, atributos de clases e instancias de clases. Todos estos conceptos se corresponden o guardan una gran analogía con la Programación Orientada a Objetos (POO), y por supuesto, con la ontología de Classora. Por ejemplo, una clase «Persona» puede tener una subclase «Deportista», un atributo «lugar de nacimiento», y una instancia llamada «Fernando Alonso». ¿Cómo se modelaría esto?

Definimos las clases principales de la ontología
<owlx:Class owlx:name="Person" owlx:complete="false" />
<owlx:Class owlx:name="Region" owlx:complete="false" />

Definimos la clase «Deportista», hija de la clase «Persona»
<owlx:Class owlx:name="Sportsman" owlx:complete="false">
  <owlx:Class owlx:name="#Person" />  
</owlx:Class>

Definimos la clase «Piloto», hija de la clase «Deportista»
<owlx:Class owlx:name="Driver" owlx:complete="false">
  <owlx:Class owlx:name="#Sportsman" />  
</owlx:Class>

Definimos las propiedades de la clase «Piloto»
<owlx:ObjectProperty owlx:name="birthPlace"> 
  <owlx:domain owlx:class="#Driver" /> 
  <owlx:range owlx:class="#Region" /> 
</owlx:ObjectProperty> 
<owlx:DatatypeProperty owlx:name="birthYear">
  <owlx:domain owlx:class="#Driver" /> 
  <owlx:range owlx:datatype="&xsd;positiveInteger" /> 
</owlx:DatatypeProperty> 

Una vez definida esta ontología básica, es posible utilizarla para representar conocimiento estructurado. Por ejemplo, podemos crear instancias sobre ella utilizando los típicos tripletes de RDF, o bien aplicando directamente OWL:

Creamos un individuo o instancia de la clase «Piloto»
<owlx:Individual owlx:name="Fernando Alonso"> 
  <owlx:type owlx:name="Driver" />
  <owlx:ObjectPropertyValue owlx:property="birthPlace"> 
    <owlx:Individual owlx:name="#Oviedo" /> 
  </owlx:ObjectPropertyValue> 
  <owlx:DataPropertyValue owlx:property="birthYear">
    <owlx:DataValue owlx:datatype="&xsd;positiveInteger">1981</owlx:DataValue> 
  </owlx:DataPropertyValue>
</owlx:Individual> 

Utilización de OWL

Hoy en día existe ya un gran número de ontologías OWL disponibles en la Web. Por ejemplo, cabe destacar la biblioteca DAML, que contiene unos 250 ejemplos hechos con OWL o DAML+OIL (hay un conversor de DAML+OIL a OWL disponible online). Además se han publicado en OWL varias ontologías especialmente extensas y de interés general, como la ontología del cáncer, desarrollada por el Centro de Bioinformática del Instituto Nacional del Cáncer de los EEUU (contiene cerca de 17.000 términos relacionados con el cáncer) o la conocida ontología médica GALEN desarrollada en la Universidad de Manchester.

En cuanto a la utilización de OWL en ontologías generales (no necesariamente publicadas en Web) cabe destacar Dublín Core (Dublín Core en OWL), SUMO, FOAF y muchas otras ontologías sectoriales. Además. las principales bases de conocimiento en Internet (Freebase, DBPedia, Classora) suelen manejar ontologías propias en OWL o lenguajes afines.

Variantes de OWL

La especificación W3C incluye tres sublenguajes OWL, con diferentes niveles de potencia: OWL Lite, OWL DL y OWL Full (ordenados de menor a mayor potencia). Como consecuencia, cada uno de estas variantes contiene una extensión sintáctica de su predecesora más simple.

• OWL Lite: fue diseñado como una versión simple de OWL, que permitiera representar las necesidades básicas de una ontología. Sin embargo, en muchos casos dicha simplificación derivó en una serie de limitaciones no deseadas, que poco a poco lo han ido aparcando.
• OWL DL: fue diseñado para mantener la integridad de la información, facilitando a su vez la aplicación de algoritmos de razonamiento automático. OWL DL incluye todas las construcciones del lenguaje OWL, pero sólo se puede utilizar bajo restricciones controladas.
• OWL Full: se basa en una semántica distinta a la de OWL Lite o OWL DL. Fue diseñado para preservar cierta compatibilidad con RDF-schema. Por ejemplo, en OWL Full una clase puede ser tratada simultáneamente como una colección de individuos y como entidad por derecho propio, lo que no está permitido en las otras versiones de OWL. Sin embargo, y como contrapartida, OWL Full puede generar bucles infinitos durante el razonamiento.

Información adicional

Como en otras ocasiones te recomendamos que contactes directamente con nosotros si quieres obtener más información sobre este tema. Sin duda OWL es uno de los estándares que mayor peso están cobrando en el futuro de Internet, y estar al tanto sobre él es algo que no sobra para ningún profesional del sector. Cuenta con Classora Technologies para estar informado.