• No se han encontrado resultados

Codificación por formato

OWL 3 , los dos estándares que ayudan a convertir la Web en una infraestructura global en la que es posible compartir y reutilizar datos y documentos entre diferentes tipos de

2.6.   Estado del Arte

2.6.3.   Tecnologías Usadas

2.6.3.2. Codificación por formato

En algunas  fuentes, sobre  todo las  estructuradas,  existen  patrones de formato que  permitan asignarle cierta semántica a los datos encontrados. Estos patrones suelen estar  formados  por  elementos  de  presentación (fuentes  subrayadas,  tipos  de  letra, etc.),  símbolos   gráficos (símbolos de moneda, sobre de correos, etc.) o simplemente por la  colocación  de  los  caracteres  en  estructuras  (listas,  tablas,  etc.).  Los  extractores  de  información automáticos hacen uso de estas propiedades y extraen la información de  acuerdo al formato que tienen los datos. La dependencia que presenta la semántica de los  datos con el formato o aspecto de su presentación es un hecho muy común en los  documentos Web, y nos permiten a nosotros los humanos comprender el contenido de  manera mucho más eficiente sin necesidad de explicaciones detalladas. 

A continuación se detallan tres formas de codificación por el formato: 

Codificación por caracteres. Si se considera una fuente textual como una cadena de  caracteres se pueden encontrar patrones que se repiten y aportan significado a los datos  encontrados. De   esta manera podemos suponer con cierta probabilidad de acierto,  dependiendo del dominio, que ciertas secuencias de caracteres corresponden a datos  buscados: cantidades monetarias, fechas, direcciones de correo electrónico, etc. Es un  método muy apropiado para la detección de instancias de conceptos con una particular  presentación. En algunos casos este método es suficiente para la detección de valores de  atributos de instancias e incluso para la detección de relaciones semánticas entre distintas  instancias. Esto sucede si dicha información está codificada enteramente por el formato  de los datos y el formato de los datos está unívocamente determinado por los caracteres  de la fuente. Un claro ejemplo es un documento CSV (comma separated value), valores  separados por comas que representan una tabla con dimensiones conocidas   y con  significado claro  para cada celda. Normalmente, para detección de relaciones semánticas  complejas o para asignar valores de atributos a instancias ya existentes debe analizarse  más en profundidad el significado del contenido. 

El mecanismo más usado para la detección de cadenas que cumplan condiciones deseadas  son las expresiones regulares. Una expresión regular permite describir de forma abreviada  con conjunto de cadenas con cierta propiedad. Existen variaciones sobre la notación de las  expresiones regulares, según la implementación del software de detección que se use. 

 

 

Ejemplo: Una posible expresión regular para detección de cadenas de correos electrónico. 

 

a z | 0 9

@



a z

 

| 0 9



.

a z

 

| 0 9



 

Un ejemplo, a veces doloroso, son los programas que buscan y coleccionan direcciones de  correos electrónicos para propósitos de publicidad no deseada (spam). 

La construcción y depuración de expresiones regulares  es una tarea compleja y tediosa.  Con  el  objetivo    de  reducir  este  esfuerzo    se  han  utilizado  con  éxito  técnicas  de  aprendizaje automático que a partir de un conjunto inicial   de ejemplos positivos y  negativos son capaces de inferir expresiones regulares para la detección de cadenas o  grupos de cadenas deseadas. Este es el caso de la empresa WhizBang!, cuyo sistema  FlipDog (http://flipdog.monter.com), descrito más adelante, detecta información sobre  puestos de trabajo. El proceso de aprendizaje consiste en almacenar las fuentes HTML en  una  forma  tabular  y sobre ellas  se marcan  los  ejemplos positivos, los nombres de  empresas,  puestos  ofertados,  condiciones  salariales,  etc.,  para  generar    reglas  de  detección basadas en expresiones regulares. 

Codificación por estructura. Algunos sistemas que trabajan sobre un dominio reducido 

pueden inferir el significado de los datos a partir de la estructura del documento. Si la  estructura  sigue un  patrón estable se  puede combinar técnicas de expresiones con  algunas reglas semánticas que toman en cuenta estructuras. Este es el caso de sistemas  como Citeseer (Citeseer) que es capaz de procesar artículos científicos online. Este tipo de  documentos  tiene  una  estructura  fija  y  en  ellos  se  pueden  basar  las  reglas  de  identificación de títulos, autores, resúmenes, citas a otros artículos, etc. Las reglas de  estructura,  normalmente  construidas  ad‐hoc  para  cada  sistema,  dependen  en  gran  medida del dominio y del formato que usen los documentos (HTML, PDF, LaTeX, etc.). 

Codificación Visual. Como los documentos online están orientados para consumo por 

lectores humanos, la composición visual de éstos es otra fuente que aporta significado a  los datos extraídos. Sobre todo en formatos como HTML, donde la forma de visualizar el  documento no está unívocamente ligada a una fuente (distintas fuentes producen igual  efecto  visual resultante),  es  una  ayuda contar  con  esta  información  para  inferir  el  significado. Para procesar el contenido visual de un documento es necesario contar con un  modelo de dos dimensiones del emplazamiento de los datos. Con este modelo se pueden  comprobar  las  posiciones  relativas  y  absolutas  entre  elementos  del  documento.  Información sobre si una etiqueta  y un dato está en la misma línea virtual, si una frase  esta debajo de un gráfico o si unos números están  en la misma columna la cual aporta  información muy valiosa. 

 

 

Este es el caso del sistema AIDAS (Hoog et al, 02) del proyecto IMAT (IMAT) descrito más  adelante, que procesa manuales técnicos mediante distintas ontologías con el objetivo de  construir un documento para propósitos de educación y formación. Los documentos,  originalmente en formato PDF, se procesan y se extrae información sobre el aspecto y  colocación visual de cada parte, como se indica en el ejemplo

 

l (text('12.1', 'Times-Bold-12'), area (60,160,34,14), , [position=left /* alineado al margen derecho */ , column = 3 /* en la tercera columna*/ , fontsize = large /* fuente grande*/

, emphasis = bold /*negrita*/ ]).

 

Posteriormente  reglas  de  inferencia  permiten  deducir  la  semántica  de  las  partes  considerando toda la información disponible. 

En los documentos HTML está necesidad se hace más notoria. Con un procesamiento  simple de las fuentes no es posible determinar si dos datos se encuentran en una misma  línea o columna visual o ni siquiera si están cerca uno del otro. Para determinar esta  información  es  necesario  realizar  el  mismo  proceso  que  hacen  los  navegadores  interpretando etiquetas HTML, funciones javascript, hojas de estilo, etc., para visualizar un  documento y además construir un modelo espacial de su contenido que se puedan  consultar desde programas. Para el formato HTML existen varias librerías de software  (IceSoft,  WebRenderer)  que  permiten  construir  este  tipo  de  modelos  donde  cada  elemento  del  documento  HTML  tiene  asignado  coordenadas 

X Y,

  para  que sean  consultadas e interpretadas, como se ilustra en la figura 25. 

 

 

 

A este proceso se le suele denominar renderización19, del inglés render, que significa 

retratar.