Archive

Archive for the ‘Não estruturada’ Category

Preparando as RFCs para o UIMA

Introdução

Uma vez entendido o UIMA segue a aprendizagem sobre ele. Olhando primeira figura do texto Instalação do Apache UIMA (Apache UIMA Installation), vê-se o conjunto de material não estruturado a ser analisado, reproduzida na Figura 1, com ênfase no repositório do RFC Editor, onde repousam os principais documentos do IETF.

aeasd-1

Figura 1. O repositório das RFCs. Primeira base não estruturada a ser analisada pelo UIMA.

Como trabalhar com o repositório das RFCs

RFCs não possuem data e hora marcadas para aparecer e, estão em um formato que deve ser normalizado (brancos, figuras em texto, autores, diferenças de padrões de escrita, etc.), para adaptar-se ao UIMA ou outra aplicação. Este processo de normalização é, na verdade uma “arrumação” sobre os dados de entrada e possui as característica descritas por Wickham (2014)1. Portanto é necessário, um pré-processamento, no qual estas duas questões serão resolvidas. A Figura 2 apresenta um modelo preliminar a ser seguido.

uima-preprocessamentorfcs

Figura 2. O pré-processamento das RFCs.

O próprio RFC Editor recomenda um mecanismo2 de recuperação de RFCs usando o rsync, uma ferramenta disponível nos sistema a la Unix e também, no Windows. Como mostra a Figura 2, o rsync trás a base do RFC Editor para o diretório rfstemp/ local, de forma incremental, como se desejava. Sobre este diretório, um programa em Python (denominado preprocess.py) é executado periodicamente e, sempre, executa o rsync, transferindo as novas RFCs para o diretório rfcs/, as quais são consumidas pelo UIMA. A Figura 3 mostra o exemplo de uma execução do rsync, no Windows 10, via prompt e uma nova RFC disponível (rfc7715.txt). Naturalmente, esta execução não foi a primeira vez, oportunidade em que isto é, o diretório rfstemp/ já tinha sido populado com TODAS as RFCs.

uima-rsync-exemplo

Figura 3. Execução do rsync e a disponibilidade de uma nova RFC enfatizada em vermelho.

A periodicidade de execução do programa preprocess.py é feita, automaticamente, através do cron (um processo, também, disponível para o Windows). Ele preserva a informação sobre a última RFC atualizada, captura as novas, normalizando e colocando-as no diretório de entrada para o UIMA (rfcs/). O processo de normalização é simples, retirando tudo o que é texto inútil de cada RFC (brancos, rodapés, etc.). Em função do UIMA, o programa preprocess.py, eventualmente, evoluirá o processo de normalização e/ou aperfeiçoará a entrada (isto é, o conteúdo do diretório rfcs/).

O UIMA, ao consumir as RFCs deixa o diretório rfcs vazio. Nas atividades do UIMA, Java é a principal linguagem, como vimos no primeiro artigo da série: Instalação do Apache UIMA (Apache UIMA Installation). O segundo artigo é uma visão geral do UIMA: Funcionamento Básico do Apache UIMA


  1. Wickham, H. Tidy Statistic. Journal of Statistical Software, Foundation for Open Access Statistics, v. 59, n. 10, 2014.
  2. https://www.rfc-editor.org/retrieve/rsync/

Funcionamento Básico do Apache UIMA

 

Introdução

 

Para entender o Apache UIMA é necessário avançar sobre muitos conceitos e por meandros do inter relacionamento entre tais conceitos. A Figura 1 mostra os componentes do Apache UIMA, de forma bastante abstrata. Sobre ela segue uma abordagem, com o objetivo de facilitar a compreensão do funcionamento básico do UIMA. O documento do qual se capturou tal descrição é o UIMA Tutorial and Developers’ Guides1, Capítulo 1. A introdução em Instalação do Apache UIMA ajuda a entender onde ele se aplica.

 uima-cmaps

Figura 1. Os componentes do Apache UIMA.

 

 

Navegando pelos componentes do UIMA

O componente central do UIMA é o CAS (Common Analysis Structure), uma estrutura de dados sobre a qual todos os outros componentes do UIMA se comunicam. Há uma interface Java chamada JCas, disponível no UIMA SDK2 que atende às demandas do CAS. O JCas permite a representação de cada Feature Structure (que faz parte do CAS), como um objeto Java.

Como o Feature Structure pertence ao CAS, então ele é uma estrutura de dados. Sua estrutura de dados é construída pelo tipo e por um conjunto de pares (atributo, valor). Esta estrutura de dados é produzida pelo AE (Analysis Engine).

O AE é um programa e parece ser o componente mais importante do UIMA, pois é ele quem agrupa as análises feitas sobre os artefatos (artifacts), nome genérico dado aos elementos (multimodais, pois podem ser texto, imagem, som, etc.) de entrada que serão analisados e, também, sobre os quais serão inferidas informações. O AEs são formados através de blocos de construção chamados Annotators, que na prática constroem dois tipos de AEs: Primitive AE e Aggregate AE.

Os Annotators produzem a chamada lógica de análise (analysis logic) e são construídas a partir da análise sobre os artefatos, as quais adicionam dados, que por razões óbvias são chamados de metadados (metadata) (dados que falam sobre artefatos). Se um AE possui um único Annotator então ele é um Primitive EA. Se, por outro lado, o EA possui um conjunto de Annotators então ele é um Aggregate AE. Os Annotators criam novas representações do texto, no formato de Sofa (Subject of Analysis), que constroem a Feature Structure.  O AEs, de qualquer tipo utilizam uma interface única, compartilhada por todas as aplicações. Existem diversas facilidades disponíveis3, para a construção de Annotators.

Por fim, os AEs são incorporados, como estrutura de dados, nas Feature Structures. Se um AE contem uma informação anexada a uma parte do artefato, ele é considerado como uma annotation, enquanto os outros são Structured Data.

Vale a pena lembrar as consequências induzidas no texto: se AEs são importantes, então os Annotators, que os formam passam a ser os componentes mais importantes e por eles deve-se começar o processo de utilização do UIMA! Neste sentido e para fixar mais as ideias sobre os conceitos, eis as etapas para desenvolver um Annotator, segundo o UIMA Tutorial and Developers’ Guides1:

  1. Defina os tipos de CAS que o Annotator irá usar.
  2. Gere as classes Java para estes tipos.
  3. Escreva o código Java real, do Annotator.
  4. Crie o descritor do AE.
  5. Teste o Annotator.

Complementarmente, um bom começo está em Getting Started: Writing My First Apache UIMA Annotator4

 


  1. http://uima.apache.org/d/uimaj-current/tutorials_and_users_guides.pdf
  2. http://uima.apache.org/d/uimaj-current/index.html
  3. http://uima.apache.org/sandbox.html#uima-addons-annotators
  4. http://uima.apache.org/doc-uima-annotator.html
%d blogueiros gostam disto: