Cada día corren ríos de tinta en los principales medios deportivos que repasan la actualidad de ambos clubes. De modo que nosotros enfocaremos el análisis desde un punto de vista estrictamente imparcial e histórico. Pero no nos limitaremos a dar el nº final de puntos conseguido por cada equipo, sino que también facilitaremos herramientas para filtrar los datos por ventanas de tiempo, de tal manera que cada uno pueda sacar sus propias conclusiones. Y si lo desea, comparar los datos con los de otros equipos.

La hipótesis inicial es clara: el Real Madrid es el mejor equipo de la historia, mientras que el FC Barcelona es el mejor equipo de los últimos años. Pero… ¿te atreves a adentrarte en los datos?

Número de ligas ganadas

En el valor absoluto de este indicador existe una clara ventaja histórica por parte del Real Madrid. Como se muestra en la gráfica de evolución inferior, el equipo blanco consiguió superar al Barça y consolidar esa ventaja durante las décadas de 1960 y 1970. A partir de 1980 ambos equipos se igualaron de tal forma que la liga la conquistaba uno u otro. La única excepción visible en la gráfica fue a principios de los ochenta, con el dominio impuesto por los equipos vascos en la LFP. En 1950 el FC Barcelona tenía cuatro ligas más que el Madrid (máxima diferencia). Por su parte, en 1990 el Madrid tenía 15 ligas más que en FC Barcelona (máxima diferencia).

Para que puedas jugar con estos datos:
Ranking de equipos con más ligas »
Gráfica de evolución de equipos con más ligas »

Liga de fútbol (LFP). Clasificación histórica

Para tener una perspectiva más detallada de lo que sucede en la liga española se puede recurrir a la clasificación histórica. Esta clasificación suma los puntos conseguidos por cada equipo en cada temporada de primera división. Si un año un club desciende a segunda división, simplemente no puntúa. Los únicos equipos que se han mantenido siempre en primera división desde el inicio de la LFP son: Real Madrid, FC Barcelona y Athletic de Bilbao. Según este indicador, merengues y azulgranas están mucho más empatados entre sí. Y no solo eso, sino que le sacan mucha distancia al tercer clasificado: el Valencia. Esto se debe a que prácticamente en todas las temporadas ambos equipos han conseguido estar en el top 3 de la tabla. De hecho, el Real Madrid ha ocupado el segundo puesto en 21 ocasiones, y el tercer puesto en 7 ocasiones. Por su parte, el Barça ha ocupado en segundo puesto en 23 ocasiones, y el tercer puesto en 12 ocasiones.

Para que puedas jugar con estos datos:
Clasificación histórica de la LFP »
Gráfica de evolución de la clasificación histórica »

Copas del Rey ganadas

En el caso de la competición copera se cambian las tornas: el equipo que más títulos ha ganado en la historia es el FC Barcelona. Y lo curioso es que el Real Madrid no es el segundo del ranking, sino el tercero. Esto se debe al Athletic de Bilbao. El equipo vasco fue el club con más copas del Rey desde el inicio de la competición, en 1901, hasta el año 1997, en el que fue igualado por el Barça. Sobre la Copa del Rey cabe destacar (como se puede observar en la gráfica inferior) como parece que está siendo bastante ignorada por merengues y azulgranas durante los últimos años (la gráfica deja de crecer para ambos clubes). Es por ello que, a partir de mediados de los años 90, la copa del Rey empezó a ser asequible para el resto de equipos.

Para que puedas jugar con estos datos:
Ranking de equipos con más copas del Rey »
Gráfica de evolución de los equipos con más copas del Rey »

Champions League ganadas

Una vez más pasamos a manejar un indicador futbolístico dominado por el Real Madrid. Al igual que en la LFP, el equipo merengue consiguió su ventaja histórica sobre el FC Barcelona y sobre los demás titanes del fútbol europeo (Bayern, Manchester, Milan, Liverpool… etc.) durante los años 50 y 60. A partir de 1966 el Real Madrid sufrió una sequía de 30 años en esta competición, hasta que en 1997 consiguió volver a codearse con los grandes levantando la séptima copa. A día de hoy, con nueve títulos, es simplemente el equipo más laureado de Europa. Por su parte, al FC Barcelona se le resistió su primera Champions durante décadas, hasta que en 1991 consiguió romper la racha. Sin embargo, el milagro azulgrana despierta de nuevo a partir de 2005, cuando el equipo toma las riendas del fútbol europeo y encarrila tres nuevos títulos en apenas seis años.

Para que puedas jugar con estos datos:
Ranking de equipos con más Champions Leagues »
Gráfica de evolución de los equipos con más Champions Leagues »

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.

Por ejemplo, cada día se crean en Internet 1 millón de nuevas páginas webs, se publican 1.000 millones de noticias en diarios digitales y se envían 20.000 millones de correos electrónicos. Todo ello sin tener en cuenta los mensajes publicados en Facebook o Twitter por nuestros amigos. Y por supuesto, sin contar llamadas telefónicas, SMS o Whatsapps.

En un contexto como éste, las plataformas que basan su modelo de negocio en la publicidad (como es el caso de los medios de comunicación) se tienen que enfrentar no sólo con un número demasiado alto de competidores dentro de su propio sector, sino con la posibilidad de que el usuario se vea distraído por un estímulo externo procedente de cualquier otro sector.

De hecho, las plataformas que viven de la publicidad, ya sea mediante CPC (Coste por Click), CPM (Coste por Mil Impresiones), CPA (Coste por Acción) o cualquier tipo de patrocinio suelen acabar centrándose en mejorar los dos indicadores principales de audiencia: el nº de páginas servidas a final de mes (cantidad de tráfico) y el engagement o fidelización, para segmentar mejor las campañas publicitarias en base a perfiles (calidad del tráfico). Por supuesto, también es posible aumentar la rentabilidad por impresión, aunque dada la situación actual de crisis y, salvo honrosas excepciones, muchos editores suelen zanjar este tema masificando su site con banners y publicidad intrusiva.

Desde Classora Technologies tenemos productos especialmente orientados a mantener el interés del usuario aportando valor añadido a su navegación. Veamos cómo.

Incrementando el número de páginas servidas

Desde el punto de vista de su necesidad concreta, los usuarios de Internet se pueden clasificar en dos grandes grupos:

• Buscadores de información: se han conectado porque necesitan conocer un dato puntual. Esta necesidad pueden resolverla abriendo su diario online habitual (si desean hacer seguimiento de una noticia) o utilizando una red social (si se trata de algún evento de su entorno). Sin embargo, en la mayor parte de los casos, esta necesidad se suele resolver mediante una búsqueda en Google (si no tienen una fuente de referencia).
• Buscadores de entretenimiento: ojo, la información también es un entretenimiento. Estos usuarios navegan sin un rumbo prefijado: están utilizando Internet como medio de ocio y se encuentran más disponibles para dejarse persuadir por contenidos que no estaban dentro su plan inicial. Las redes sociales suelen ser su principal destino, pero por fortuna para nosotros éstas complementan sus contenidos enlazando medios online y blogs.

Cuando estamos en modo «buscar información», nuestras barreras están activadas y apenas nos influyen las propuestas que nos hagan. Sin embargo, tarde o temprano todos acabamos entrando en Internet en modo «buscar ocio». Este es el momento en el que los medios online tienen su oportunidad para engancharnos y convencernos de que ellos son una referencia, o en su caso, un recurso informativo mejor que la competencia.

Para aumentar el número de páginas vistas, desde Classora Technologies dividimos este parámetro en dos indicadores más fácilmente atacables:

• Ratio de páginas/visita: indica cuantas páginas ve un usuario en nuestra web antes de abandonarla. Para mejorar este indicador desde Classora proponemos utilizar, aparte de las técnicas de usabilidad habituales, enriquecimiento semántico de noticias y motores de recomendaciones de contenidos. Además, se puede mejorar el buscador convirtiéndolo en un autosugeridor de contenidos en tiempo real, a medida que el usuario teclea. Así, aunque no encuentre exactamente lo que busca, tendrá alternativas válidas para continuar navegando por nuestra web.
• Número de visitas: para mejorar este indicador desde Classora proponemos utilizar, aparte de las técnicas SEO, SEM y SMM habituales, la creación de páginas de temas automáticas y el enriquecimiento semántico de las mismas mediante contenidos de valor añadido. Se trata de un refuerzo complementario a cualquier otra acción de posicionamiento en buscadores o redes sociales, ya que con ello estaremos aumentando los contenidos internos, dotándolos en ocasiones de componentes más virales.

Tanto el enriquecimiento semántico como los motores de recomendación de contenidos arrojan unos resultados extraordinarios y fácilmente trazables. Simplemente mediante la monitorización de estos indicadores con una herramienta de análisis de audiencia, como Google Analytics, puede comprobarse rápidamente sus beneficios.

Incrementando el engagement y mejorando la imagen de marca

Aunque aumentar el tráfico de una web a costa de su contenido es un objetivo deseable, este incremento debe ir de la mano de una mejora sustancial en la calidad transmitida. En numerosas ocasiones previas muchos sites sacrificaron la calidad con la que habían ganado su audiencia para conseguir una mayor cantidad de contenido a ofrecer.

En este sentido, el enriquecimiento semántico es quizá la manera más natural de optimizar una web aunando contenido y calidad. Por ejemplo, si en una noticia se habla de un determinado personaje, se puede mostrar información asociada al mismo. Si se habla de la cotización bursátil de una empresa, se puede incorporar la gráfica pertinente actualizada. Si se habla de la actuación de un equipo en una competición deportiva, se puede incrustar la tabla clasificatoria de la misma. Si se habla de un lugar desconocido para el gran público, se puede insertar un mapa para ubicar la noticia. Si se habla de un evento al que han asistido personajes del corazón, se suele acompañar la noticia con una galería de imágenes del mismo.

En todos, absolutamente todos los casos, estamos aportando valor al usuario. De hecho, en muchos casos nos estaremos adelantando a sus demandas de información. Y siempre le estaremos brindando una oportunidad para que investigue un tema de su interés sin abandonar nuestra plataforma.

Y es que un comportamiento típico, cuando un usuario desea profundizar en un tema, radica en abrir una nueva pestaña del navegador y buscar en Google la información que necesita para completar su conocimiento. ¿Por qué dejar que el usuario se informe fuera si esa información ya la tenemos perfectamente empaquetada para él? El enriquecimiento semántico pone a disposición de nuestra editorial una cantidad impresionante de información pública estructurada que se presenta al usuario cuando la necesita y de la manera que la necesita.

En fin, fidelizar al usuario, conseguir su atención y su respeto, que prefiera informarse leyéndonos a nosotros en lugar de la competencia… todo ello supone un proceso largo que se va consiguiendo con detalles como éste, que se incorporan directamente a la cadena de valor de la empresa e incluso, en algunos casos, consiguen generar una ventaja competitiva.

Conclusiones

Muchos usuarios de Internet están inconscientemente saturados con tanta información. Esto hace que cada vez nos volvamos más dispersos (es decir, que tengamos menos capacidad de concentración), que tengamos menos memoria (es decir, que tengamos menos capacidad de retención, tendiendo a utilizar a Google como un disco duro externo a nuestro cerebro) y al mismo tiempo que nos volvamos más impacientes (la distancia máxima entre una web y otra se encuentra al alcance de un click).

Las empresas que viven de la atención del usuario, sosteniendo su negocio con tráfico y publicidad, deben esforzarse por consolidarse como referencias dentro de la mente del consumidor. Para ello existen multitud de herramientas, pero es necesario llevarlas a la práctica adecuadamente para lograr resultados positivos.

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional.

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.

A día de hoy, el enriquecimiento semántico se puede dividir en tres bloques principales de funcionalidad: enriquecimiento para aportar metadatos (metadata enhancement engines), enriquecimiento para sugerir y descubrir contenidos (content discovery platforms) y enriquecimiento para integrar recursos informativos relevantes (content enhancement engines), como información enciclopédica, datos de redes sociales… etc.

De hecho, y como ya hemos comentado en anteriores posts, el enriquecimiento semántico de contenidos es probablemente una de las principales tendencias en los diarios líderes a nivel mundial (BBC, The Guardian, New York Times… etc.) y se basa en aportar semántica (es decir, contenidos externos contextuales, metadatos, profiling… etc.) a la información disponible en la plataforma digital. Es importante distinguir que este proceso de mejora semántica no se limita a incrustar microdatos o posicionar mejor en los buscadores, sino en aportar valor real, complementando cada noticia publicada, cada texto, cada tema, el propio buscador… etc. con información diferente y útil para el lector. En muchos casos se trata de alimentar al medio digital con una ventaja competitiva sobre sus principales rivales directos.

Al margen del éxito conseguido por Google con su proyecto de enriquecimiento semántico, Knowledge Graph, entre las referencias más reconocidas de proyectos notables en estos temas figura el Dynamic Semantic Publishing de la BBC, Open Calais de Thomson-Reuters, el Thesaurus de The New York Times o el Data Store de The Guardian, por citar algunos.

El enriquecimiento semántico utiliza por debajo una amplia amalgama de tecnologías diferentes que básicamente se pueden agrupar en tres pilares principales:

Primero: para el análisis semántico de los textos se utilizan tecnologías basadas en Procesado de Lenguaje Natural (NLP). El enriquecimiento semántico necesita como input un texto estandarizado (esto es: en el idioma esperado, con el encoding/charset convenido… etc.). A partir de ahí, aplica varios algoritmos NLP. El primero es un preprocesado básico para eliminar impurezas lingüisticas, como stopwords. A continuación, se aplican algoritmos de reconocimiento de entidades con nombre (NER: Named-Entities Recognition) y etiquetado gramatical (POST: Part-of-Speech Tagging).

Segundo: para saber el significado de cada elemento y tema encontrado es necesario cruzarlo con un tesauro, generalmente una base de conocimiento. En español apenas existen bases de conocimiento públicas, con un API disponible y con un volumen y una calidad de datos suficientes como garantizar los resultados. La creación y mantenimiento de esta base de conocimiento contra la que cruzar los datos supone en si misma un esfuerzo técnico descomunal, en que se ven implicadas principalemente tecnologías de ETL (Extraction, Transformation and Load) de información, muy típicas en soluciones empresariales de Business Intelligence, así como técnicas para estructurar datos a partir de textos desestructurados, integrar fuentes heterogéneas (Linked-Data, Open-Data) y monitorizar constantemente los cambios para avalar la actualidad de los datos.

Tercero: y último, para presentar los datos devueltos en un formato adecuado es necesario recurrir a herramientas avanzadas de visualización. Esta parte se suele cubrir utilizando herramientas externas con un API disponible. Entre ellas, destacan la utilización de cartografías para visualización de mapas, gráficas para representar datos visualmente, HTML5 y jQuery e integración con estándares de la Web Semántica, especialmente RDF y OWL.

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre enriquecimiento semántico.

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.

Quizás el principal motivo sea el poder cruzar o integrar, de manera completamente automática, la información de una compañía con datos externos de su mercado, su competencia, sus proveedores… o con cualquier otra información disponible en La Red. Independientemente de donde venga, de su idioma original o de quién la haya publicado. De ahí el esfuerzo en implantar unos estándares universales para representar el conocimiento.

Pero una vez integrada toda esa información, para sacarle partido es necesario poder crear informes o consultas que nos permitan obtener conocimiento aplicable a nuestro negocio. Por ello, en este post vamos a intentar explicar el principal lenguaje de consulta para la Web Semántica: SPARQL.

Al igual que RDF, SPARQL es un estándar ideado por Tim Berners-Lee y monitorizado por el Data Access Working Group (DAWG) del World Wide Web Consortium (W3C).

Si no lo has hecho ya, te recomendamos que antes de leer este post leas nuestra entrada anterior acerca de cómo se describe el conocimiento en la Web Semántica utilizando RDF.

SPARQL: SPARQL Protocol and RDF Query Language

SPARQL es el lenguaje que nos permitirá extraer información y conocimiento de la Web Semántica. Utiliza una sintaxis derivada de SQL, y está especialmente diseñado para recuperar datos partiendo de ontologías y documentos RDF.

Al igual que SQL, mantiene una estructura declarativa con la típica sintaxis basada en cláusulas SELECT, FROM, WHERE y ORDER BY. Por supuesto, y siguiendo la equivalencia con SQL, también es necesario distinguir entre lenguaje de consulta y motor para almacenar y recuperar los datos. Por este motivo, existen múltiples implementaciones de SPARQL, generalmente ligadas a entornos concretos de desarrollo y plataformas tecnológicas.

En principio SPARQL únicamente incorpora funciones para recuperar información. Sin embargo, algunas propuestas también incluyen operaciones para el mantenimiento (creación, modificación y borrado) de datos.

Veamos cláusula a cláusula como se podría trasladar una consulta SQL a SPARQL:

• SELECT: se mantiene su funcionalidad, indicando cada elemento a seleccionar (sujeto, predicado, objeto) precedido de un símbolo ?. Al igual que en SQL, es posible especificar un carácter * para representar todos los elementos.
• FROM: la tabla a consultar (en este caso, la ontología o grafo a consultar) no se especifica mediante la cláusula FROM, sino que se indica de manera externa a la consulta. El motor SPARQL utilizado tendrá una ontología por defecto.
• WHERE: la cláusula WHERE sigue siendo la parte más importante de la consulta. Para filtrar tripletes, es posible establecer una parte del triplete (sujeto, predicado, objeto) como variable, asignándole un nombre precedido del símbolo ?. El resto del triplete puede mantenerse constante, manteniendo las URIs para especificar los valores por los que filtrar.
• GROUP BY: el funcionamiento es el mismo que en SQL. Permite agrupar resultados, y realizar operaciones de grupo tipo SUM o COUNT, al igual que filtros HAVING.
• ORDER BY: al igual que en SQL, la cláusula ORDER BY sigue permitiendo ordenar los resultados en SPARQL. No hay variación significativa.

De esta forma, la query SPARQL más simple sería la siguiente:

SELECT ?sujeto ?predicado ?objeto
WHERE {  
   ?sujeto ?predicado ?objeto .
}

Vendría a significar un SELECT * FROM [TABLA] ya que todos los elementos del triplete especificados en la cláusula WHERE son variables. Pongamos ahora una consulta ficticia basada en el primer ejemplo RDF de nuestro post anterior:

PREFIX base: <http://www.knowledge.base.org/> .
PREFIX ontology: <http://www.ontology.org/> .

SELECT ?sujeto
WHERE {  
   ?sujeto ontology:hasMother base:susana . 
}

La cual pregunta al motor de SPARQL: ¿cuáles son los hijos de Susana?

Evidentemente, las consultas SPARQL pueden llegar a complicarse de una manera sorprendente, combinando múltiples cláusulas y condiciones. Pongamos a continuación un ejemplo de consulta real basada en el ejemplo previo de RDF:

PREFIX clsa:     <http://www.classora.com/units/> .
PREFIX ontology: <http://www.classora.com/ontology/> .

SELECT ?objeto
WHERE {  
   clsa:q10035/fernando-alonso ontology:x81190/birthPlace ?objeto . 
}

La cual pregunta al motor de SPARQL: ¿dónde nació Fernando Alonso?. La respuesta de Classora se puede consultar en este enlace.

Para finalizar, hagamos una consulta real a DBPedia:

SELECT *
WHERE {  
  ?company a <http://dbpedia.org/ontology/Organisation> .
  ?company <http://dbpedia.org/ontology/foundationPlace> <http://dbpedia.org/resource/California> .
  ?product <http://dbpedia.org/ontology/developer> ?company  .
  ?product  a <http://dbpedia.org/ontology/Software> .
}

La cual pregunta al motor de SPARQL: dime todas las empresas de California que sean fabricantes de software. La respuesta de DBPedia se puede consultar en este enlace.

Si lo deseas, es posible “cacharrear” con SPARQL en este portal online del Principado de Asturias.

Más información sobre SPARQL

En fin, no es nuestra intención escribir un curso detallado de SPARQL en este post, pero si te interesa saber más sobre el tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Esperamos al menos haber logrado despejar las principales dudas sobre este lenguaje tan importante para el futuro de Internet.

RDF: Resource Description Framework

RDF es un lenguaje genérico para describir recursos, es decir, para identificar unívocamente entidades (personas, organizaciones, lugares, películas…etc) y relaciones o hechos (facts) sobre las mismas. Por ejemplo, para una entidad «persona» se pueden especificar hechos como: de dónde proviene, cuándo nació, quién es su padre, quién es su madre… etc.

Cuando la W3C se propuso escribir las especificaciones de RDF, su objetivo era crear una fórmula genérica para representar el conocimiento humano. Se trataba de crear una sintaxis tan amplia que permitiese expresar cualquier hecho, y a la vez tan estructurada que cualquier software pudiese interpretarlo de manera automática.

Para conseguirlo, la fórmula más básica que lograron sintetizar fueron los tripletes. Los tripletes son “piezas” de conocimiento que tienen la siguiente estructura:

• Sujeto: indica la entidad sobre la que se describe el hecho (ejemplo: Juan)
• Predicado: indica el tipo de hecho a describir (ejemplo: tiene un padre)
• Objeto: indica un valor adicional que ayuda a completar el hecho (ejemplo: Martín)

No es casualidad que un triplete sea una versión simple de una oración humana: así es como nosotros representamos nuestro conocimiento. RDF no es más que un estándar para que las máquinas también puedan entenderlo.

Los sujetos y predicados deben ser recursos referenciables, es decir, deben ser identificados mediante una URI (Identificador Único de Recurso) . Sin embargo, los objetos pueden ser referenciables o pueden ser valores literales (como strings, fechas, números… etc.).

Un ejemplo simplificado:

@prefix base: <http://www.knowledge.base.org/> .
@prefix ontology: <http://www.ontology.org/> .

Sujeto      Predicado           Objeto 
base:juan   ontology:isA        base:person .  Juan es una persona
base:juan   ontology:hasMother  base:susana .  Juan tiene una madre llamada Susana
base:juan   ontology:hasFather  base:martin .  Juan tiene un padre llamado Martín
base:martin ontology:hasBrother base:pedro  .  Martín tiene un hermano, Pedro

Se han introducido dos prefijos para facilitar la lectura de las URIs. A partir de ahí, cada línea es un hecho (fact). Nótese que las líneas terminan con un punto final y un retorno de carro.

Para que este ejemplo ficticio funcione, todos los recursos utilizados, tanto los sujetos (Juan, Martín) como los predicados (isA, hasMother, hasFather, hasBrother) como los objetos (Person, Susana, Martín, Pedro) deberían estar referenciados mediante una URI real.

En la Web Semántica, las URIs de ficheros RDF públicos suelen apuntar a:

• Bases de conocimiento (bibliotecas digitales) como DBPedia, Freebase o Classora.
• Ontologías (vocabularios, tesauros… etc.) como Dublín Core, SUMO, FOAF u otras ontologías sectoriales. Si bien las bases de conocimiento suelen manejar ontologías propias.

Veamos ejemplos de tripletes aplicando URIs del mundo real:

@prefix foaf:     <http://xmlns.com/foaf/0.1/> .
@prefix dbpd:     <http://live.dbpedia.org/resource/> .
@prefix frbs:     <http://rdf.freebase.com/rdf/en.> .
@prefix clsa:     <http://www.classora.com/units/> .
@prefix ontology: <http://www.classora.com/ontology/> .

Sujeto                        Predicado                    Objeto 
clsa:q10035/fernando-alonso   foaf:primaryTopic            dbpd:Fernando_Alonso .
clsa:q10035/fernando-alonso   foaf:primaryTopic            frbs:fernando_alonso .
clsa:q10035/fernando-alonso   ontology:x81190/birthPlace   clsa:y23605921/oviedo .

Este ejemplo utiliza tres bases de conocimiento (DBPedia, Freebase y Classora) y dos ontologías: FOAF y Classora. Lo único que hace es establecer una equivalencia entre los recursos llamados «Fernando Alonso» en las tres bases de conocimiento (utilizando FOAF). Por último, indica que el lugar de nacimiento de Fernando Alonso es Oviedo (utilizando Classora).

Con solo poner tres entidades juntas, el motor RDF ya sabe como interpretar un hecho. Al poner muchos hechos juntos, se llega a representar (e incluso a generar) conocimiento. En la práctica, existen aplicaciones construidas sobre RDF que agregan semántica para la elaboración de inferencias lógicas. Es decir, permiten que las máquinas saquen sus propias conclusiones.

Como se puede observar, los documentos RDF están pensados para ser leídos vía software, no por humanos. Por ejemplo, para representar una simple clasificación deportiva, perfectamente resumible en una tabla HTML, serían necesarios miles de tripletes. Esto hace especialmente relevante la notación que utilicemos.

Notaciones de RDF

Cabe destacar que un fichero RDF no es más que un conjunto de tripletes. Por tanto, puede ser representado en XML, en JSON, en CSV… etc. Incluso puede ser almacenados en una simple tabla de base de datos con tres columnas. Los documentos RDF suelen tener la extensión .rdf sólo cuando están basados en RDF/XML. Sin embargo, ésa no es necesariamente la mejor notación para RDF. A continuación se detallan las principales variantes utilizadas:

• Notation 3: es una aproximación no XML creada por Tim Berners-Lee y sus compañeros cuando se definió la Web Semántica. Esta notación es la más amplia (no solo es válida para RDF) pero también es la más ineficiente desde el punto de vista computacional.
  Extensión de los ficheros: .n3
• Turtle: es un subconjunto de Notation 3 limitado únicamente para describir grafos RDF mediante tripletes. Fue la primera notación aceptada por la W3C, en Agosto de 2011. Hoy en día es probablemente la notación RDF más extendida.
  Extensión de los ficheros: .ttl
• N-Triples: es un subconjunto de Turtle, es decir, un nivel más de simplificación sobre Notation 3. Su objetivo es crear cadenas serializables y, por tanto, fácilmente transmitibles. No obstante, su extrema sencillez deriva en una pérdida de potencia.
  Extensión de los ficheros: .nt

Motores de RDF

Para trabajar con documentos RDF y crear aplicaciones para web semántica existe un incipiente conjunto de librerías, siendo quizá Apache Jena uno de los frameworks más destacados.

Validación de RDF

Para validar que un texto o fichero RDF está correctamente formado existe un validador W3C, que permite analizar online documentos RDF en varias notaciones.

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 RDF 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.

Taxonomías

Una taxonomía no es más que un sistema de clasificación que permite agrupar un conjunto de elementos dentro de unas categorías predefinidas. Estas categorías (o taxones) pueden estar contenidas unas en otras, o relacionadas de cualquier otra manera. Un ejemplo muy ilustrativo es la taxonomía biológica: la ciencia que clasifica los seres vivos en reinos, especies, razas… etc. Análogamente existe la taxonomía geográfica, que clasifica los territorios en diferentes niveles organizacionales: país, provincia, municipio… etc. En el mundo de los medios digitales resulta básica la taxonomía IPTC, que clasifica cualquier noticia o publicación dentro de unos estándares, permitiendo así automatizar su intercambio.

Y es que en informática, y especialmente dentro de la Web Semántica, las taxonomías son un pilar imprescindible que sirven para agrupar las entidades con características comunes. No en vano la propia idea de la Programación Orientada a Objetos está basada en la construcción de taxonomías customizadas para los intereses de cada aplicación.

Ontologías

Una ontología es un modelo conceptual para representar, almacenar e intercambiar datos. Por ejemplo, un modelo entidad-relación que describe la base de datos de una empresa puede ser considerado una ontología básica. Sin embargo, hoy en día el concepto de ontología es mucho más amplio, y se apoya en la creciente posibilidad de describir estándares para compartir información entre sistemas completamente heterogéneos.

La mayor parte de estos estándares se basan en XML. Por ejemplo, en Web Semántica resulta fundamental la utilización de RDF (Resource Description Framework) y cada vez se está extendiendo con mayor virulencia el OWL (Web Ontology Language), un lenguaje que tiene como objetivo facilitar la construcción de ontologías propias que luego se publican vía web. Por último, no podemos dejar de mencionar SKOS (Simple Knowledge Organization System), una iniciativa del W3C, basada en RDF, que proporciona un modelo para representar la estructura básica y el contenido de esquemas conceptuales como taxonomías, esquemas de clasificación, tesauros y cualquier tipo de vocabulario controlado.

Folksonomías

Una folksonomía es un sistema de clasificación abierto y/o colaborativo basado en etiquetas (tags). Estas etiquetas no son jerárquicas, es decir, no se anidan unas dentro de otras. Las folksonomías son el sistema de clasificación nativo de muchas plataformas web que almacenan datos producidos con la participación de miles de usuarios. Es el caso de Wikipedia, Flickr o Delicious. Sin embargo, el sistema de etiquetas que permite Gmail para clasificar correos no es una folksonomía, ya que no es abierto ni colaborativo.

El término «folksonomía» es muy reciente. Fue acuñado hace apenas unos años por Thomas Vander Wal, y significa simplemente taxonomías populares (folks es «popular» en inglés). Por ello, una nube de tags es una buena representación visual de una folksonomía. Según su autor, existen dos tipos de folksonomías:

• Folksonomías amplias: el creador no influye en las etiquetas que se ponen a su contenido, sino que son los propios usuarios quienes lo hacen, favoreciendo así que las etiquetas estén en sus propios idiomas y en sus propias palabras. Ejemplo: del.icio.us.
• Folksonomías estrechas: al contrario que en las anteriores, sólo el creador del contenido o un número reducido de personas pueden aplicar etiquetas. Un ejemplo de folksonomía estrecha es flickr, donde la utilización de los tags la lleva a cabo el propietario.

Para poner un caso práctico que ilustre como se pueden utilizar estos conceptos en conjunto, podemos comentar que en Classora Knowledge Base disponemos de una taxonomía jerárquica para organizar las unidades de conocimiento, y de una folksonomía colaborativa para organizar rankings e informes. Además, toda la base de conocimiento se apoya en una ontología propia fácilmente exportable a estándares de la Web Semántica.

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.

Para llegar a conseguir este comportamiento final, aparentemente sencillo, existe una amplia amalgama de herramientas o motores disponibles, cada uno de ellos encargado de agrupar un conjunto de funcionalidades similares. En cada caso, trataremos de indicar dichas funcionalidades y algunas alternativas de software libre y comercial que las implementan.

Motores de preprocesado de textos

Preprocessing engines: son los primeros en enfrentarse al texto de entrada, y por tanto, les toca realizar el trabajo sucio de generar un modelo homogéneo a partir de la gran diversidad de formatos, idiomas y metadatos disponibles. En algunas ocasiones, sus responsabilidades se solapan con las de herramientas ETL. Sus principales funciones son:

• Detectar el idioma del texto
• Reconocer el encoding y content-type del texto
• Extraer los metadatos a partir de los diferentes formatos
• Convertir el texto a partir de diferentes formatos a un modelo estándar

Algunas soluciones de software libre que los implementan son Apache Tika, Metaxa Engine y Aperture Framework. Dentro de las comerciales, no podemos dejar de destacar a Autonomy, aunque también nos gustaría mencionar a alternativas más modestas como la finlandesa Connector Machinese.

Motores de reconocimiento de entidades con nombre (NER)

Named-Entity Recognition Engines: el reconocimiento de entidades con nombre consiste, como su propio nombre indica, en la detección de elementos con nombre propio dentro de un determinado texto, y su clasificación en categorías predefinidas, como personas, organizaciones, empresas, lugares, etc. La complejidad de este proceso se basa en que muchas entidades equivalentes pueden aparecer escritas de diferentes formas, por lo que es necesario contar con un conjunto de reglas semánticas avanzadas y un corpus contra el que cruzar la información para realizar desambiguaciones.

El reconocimiento de entidades con nombre se suele utilizar para hacer etiquetado automático de textos (por ejemplo, en las noticias de un diario digital) y como paso previo para el enriquecimiento semántico. El gran problema del NER es que el tratamiento de temas (topics) como prima de riesgo, o crisis eurozona es más complejo y requiere utilizar metainformación semántica.

Algunas reglas típicas de motores NER se pueden resumir en expresiones regulares como:

(N)ombre (A)pellido : Nombre / Apellido / N. Apellido / Nombre A. / N. A.
Ejemplo: Fernando Alonso: Fernando / Alonso / F. Alonso / Fernando A. / F. A.

(A)aa [de|del|la|los|las]? (B)bb [de|del|la|los|las]? (C)cc : ABC
Ejemplo: Organización de Naciones Unidas: ONU

Soluciones de software libre que implementan motores NER son, por ejemplo: Apache OpenNLP y Stanford NER (dirigido por el profesor Christopher Manning). Dentro de las soluciones comerciales cabe destacar, por ejemplo, Extractiv, Lingpipe NER, Daedalus Stilus NER, Connexor NER o Text Mining Engine. Por supuesto, en ese terreno también tiene cabida la omnipresente Autonomy. Finalmente, no podemos dejar de mencionar nuestra propia alternativa, Classora Autotagging, que además de entidades con nombre reconoce temas.

Motores de enriquecimiento semántico

Semantic Enhancement Engines: representan el eslabón más avanzado de desarrollo técnico, ya que requieren que se hayan llevado a cabo los procesos anteriores (preprocesado y NER) junto con otros algoritmos semánticos adicionales (por ejemplo, POST: Part-of-Speech Tagging) para finalmente cruzar los resultados con una base de conocimiento que les permita enriquecer los contenidos con datos adicionales procedentes de fuentes externas.

En este sentido, los motores de enriquecimiento semántico se subdividen en tres grupos principales:

• Metadata Enhancement Engines: utilizan los contenidos externos para incrustar metadatos sobre el texto de entrada, como los microdatos de HTML5 o el etiquetado RDF. El objetivo de estas herramientas es múltiple: estructurar la información interna, posicionar mejor en buscadores, o añadir un determinado website al Linked-Data Cloud. La herramienta mundialmente más conocida para este fin es Open Calais de la agencia Thomson-Reuters, que proporciona un API abierto.
• Content Discovery Platforms: manejan datos internos y externos para sugerir contenidos relacionados al usuario. Los datos internos suelen ser la propia navegación del usuario, y los externos suelen ser perfiles de usuarios similares. Además, estas herramientas manejan unos grafos de navegación muy potentes, construidos mediante la agregación del comportamiento de millones de usuarios en Internet. Los contenidos ofertados pueden proceder del mismo website, o bien de otros sitios afines. Las empresas líderes en este campo son Outbrain y nRelate, si bien existen múltiples alternativas como Orca, Pinevio o Cxense.
• Content Enhancement Engines: utilizan el cruce con las bases de conocimiento para complementar el texto de entrada con contenidos externos relevantes. Estos contenidos pueden ser de naturaleza muy variada, desde definiciones enciclopédicas a imágenes, vídeos o componentes de redes sociales. Este tipo de herramientas están entre las últimas tendencias de Internet. No hay más que ver el fulminante éxito de Google Knowledge Graph, que enriquece semánticamente la búsquedas en Google.

  Entre las soluciones de software libre para los Content Enhancement Engines cabe destacar Apache Stanbol, que también da soporte a otros tipos motores para procesamiento de textos y Apache Jena, orientado a construir aplicaciones semánticas. En cuanto a las alternativas comerciales, cabe destacar soluciones como Zemanta (para enriquecer blogs con contenidos externos desde el panel de administración), Apture (comprada por Google, que enriquecía cualquier web desde dentro con un simple javascript, o desde fuera como plugin para el navegador). Y por supuesto, en este punto cabe destacar Classora Media Support, nuestra alternativa comercial y -con humildad- la herramienta más avanzada en muchos sentidos.

Todos estos motores están diseñados para poder ser integrados en plataformas CMS. Como ya hemos comentado en ocasiones anteriores, los motores de enriquecimiento semántico se están convirtiendo en una de las principales tendencias en CMS y medios digitales. Su objetivo no es otro que dar un paso más sobre el tratamiento tradicional de los contenidos, ofreciendo un evidente valor añadido al usuario.