Arquivo

Archive for the ‘Modelos’ Category

WordIETF

Introdução

Este texto evolui as preocupações, grosso modo, em dar “inteligência” aos agentes (ou IEs – Intelligents Elements} do modelo AEASD (Autonomous Elements Architecture for Specific Domains), cuja origem foi na dissertação de mestrado e em discussões posteriores (Braga-Filho, 2015) (Braga; Omar; Granville, 2015).

Trata-se de uma evolução, e natural aperfeiçoamento, da contextualização e da maneira de enxergar o problema. É um processo de aprendizagem, contínuo, permanente e natural, na vida de um pesquisador. Como a visão de Charles Darwin1, na sua celebrada e incontestável teoria. Se eu vivesse eternamente, chegaria a um consenso preciso, sobre a questão principal. Não sendo eterno, a contribuição pode interessar aos mais jovens.

A Figura 1 do meu texto “Preparando as RFCs para o UIMA” (https://ii.blog.br/2016/01/08/preparando-as-rfcs-para-o-uima/) sofreu uma pequena alteração e apresenta-se como a Figura 1, a seguir.

 tese-modeloprincipalFigura 1. Novo modelo global.

O que mudou foram as ferramentas (item 5, na figura). O Apache UIMA não é a única ferramenta disponível. Em algumas etapas, mas simples, ele é dispensável. Existem muitas outras! O que torna mais complexo, o tratamento de textos, um assunto muitíssimo difícil, como falam inúmeros autores. Com a linguagem natural nem se fala. Basta ouvir o pensamento de Noam Chomsky1 de que a linguagem natural não constitui um domínio sobre o qual se podem construir teorias científicas coerentes, como escreve Neil Smith2 em seu longo prefácio do “Novos horizontes no estudo da linguagem e da mente” (Chomsky, 2005).

Trata-se neste texto, portanto, incorporar outras reflexões e mostrar a necessidade de se criar um dicionário léxico sobre as RFCs, como o objetivo de facilitar os trabalhos futuros. Este dicionário, em um domínio específico (sobre as RFCs) é similar ao WordNet3, que se nomeou de WordIETF.

Contextualização

Resumindo, o conjunto de dados (textos não estruturados), isto é, o corpora que se deseja incluir no projeto é mostrado na Figura 2.

tese-corpusFigura 2. Corpora que interessa ao projeto final e que deve ser tratado.

Por razões de simplicidade, os exercícios preliminares serão reduzidos a um único corpus, como mostra a Figura 3

tese-corpusunico
Figura 3. Corpus sob o qual a experiência preliminar será feita.

Simplificando, fica mais fácil seguir a proposta mostrada na Figura 4, que mostra a evolução atual do que se tem em mente, para o futuro.

tese-proposta
Figura 4. A atual evolução do modelo e as questões de pesquisa envolvidas: (2), (3) e (4).

O item (1) da figura acima está desenhado na Figura 2 do texto “Preparando as RFCs para o UIMA” (https://ii.blog.br/2016/01/08/preparando-as-rfcs-para-o-uima/). O item (2) representa uma das três questões de pesquisa que, de imediato, leva à criação de um dicionário léxico, WordIETF, consignado a partir do corpus, parte do RFC Editor4.

Como estabelecer o WordIETF

Em um livro bastante interessante sobre processamento de textos (Ingersoll; Morton; Farris, 2013), ferramentas do Apache são indicadas: Hadoop5, Lucene+Solr6 com o PyLucene, Mahout7 e o openNLP8. Tais ferramentas são, realmente, suficientes para resolver desafios no domínio de um texto, como mostra a Figura 5.

tamming-desafios
Figura 5. Desafios na mantipulação de textos.

O UIMA já foi parcialmente testado e as outras propostas da Apache serão verificadas. A Python, com o seu NLTK (Natural Languange Tool Kit), permite sem maiores esforços, a construção do WordIETF e resolver os desafios da Figura 5. Oportunamente serão descritas as experiências.

Uma outra ferramenta, que pode ser até mesmo complementar é o Mathematica4. Pode o Mathematica resolver os desafios e contribuir para a construção do WordIETF? A resposta é sim, com veremos em novos documentos mais à frente.

Conclusões

Trata-se de um projeto de pesquisa que exige a construção de um dicionário léxico, o WordIETF. Observa-se a necessidade de cooperação e contribuições de eventuais interessados.

Uma das maneiras de receber colaboração e contribuições é a divulgação no âmbito do IETF e de outras comunidades interessadas. Neste sentido, caso haja tempo hábil será enviado um I-D para o IETF 96 (Berlim), em julho próximo.

Resultados parciais e dificuldades encontradas, evolução e outras informações úteis serão postas neste blogue.

Referências

BRAGA-FILHO, L. J. Modelo para Implementação de Elementos Inteligentes em
Domínios Restritos da Infraestrutura da Internet
. Dissertação (Mestrado) — Universidade Presbiteriana Mackenzie, São Paulo, SP, 8 2015.

BRAGA, J.; OMAR, N.; GRANVILLE, L. Z. Uma proposta para o uso de elementos
inteligentes em domínios restritos da infraestrutura da internet. In: Anais CSBC, WPIETFIRTF. Recife, Pernambuco, Brasil: [s.n.], 2015

CHOMSKY, N. Novos horizontes no estudo da linguagem e da mente. [S.l.]: Unesp, 2005.

INGERSOLL, G. S.; MORTON, T. S.; FARRIS, A. L. Taming text: how to find, organize,
and manipulate it. [S.l.]: Manning Publications Co., 2013.


1. https://pt.wikipedia.org/wiki/Charles_Darwin
2. https://en.wikipedia.org/wiki/Neil_Smith_%28linguist%29
3. https://wordnet.princeton.edu/
4. https://www.rfc-editor.org/
5. http://hadoop.apache.org/
6. http://lucene.apache.org/index.htm
7. http://mahout.apache.org/
8. https://opennlp.apache.org/index.html
9. http://www.wolfram.com/

Anúncios
Categorias:Apache, IETF, Modelos, TCP/IP, WordIETF

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/

Instalação do Apache UIMA (Apache UIMA Installation)

Introdução

Introduction


Este texto relata o processo de instalação do Eclipse, juntamente com o Apache UIMA1. O objetivo é usar o Apache UIMA, em uma primeira etapa, para testar a hipótese ilustrada pela Figura 1.


This paper reports the Eclipse installation process along with Apache UIMA1. The goal is to use the Apache UIMA, in a first step, to test the hypothesis illustrated in Figure 1.

aeasd
Figura 1. Modelo a ser testado no Apache UIMA.
Figure 1. Model to be tested in Apache UIMA.


Na figura, (1), representa o modelo AEASD (Autonomous Elements Architecture for Specific Domains) (BRAGA; OMAR; GRANVILLE, 2015), o qual organiza um ambiente de agentes inteligentes com características voltadas para o domínio específico dos Sistemas Autônomos, que povoam a Internet. Presume-se que os elementos inteligentes terão mais autonomia, se conseguirem aprender, ensinar e cooperar através de uma base de conhecimento ou ontologia, (2), local ou remota (como a Wikidata2 e/ou outras). Esta ontologia pode ser construída a partir de bases de dados não estruturadas, (3), desde que se possua as ferramentas adequadas (FAN et al., 2012). Um conjunto de tais ferramentas foi desenvolvido pela IBM (FERRUCCI, 2012) (FERRUCCI et al., 2010), através de uma competente equipe quando da construção do IBM Watson, (5), diante do incrível desafio de vencer humanos no Jeopardy! – existem diversos vídeos no YouTube sobre este evento, que aconteceu em 2011. Há fortes indícios de que com adaptações adequadas, tais técnicas possam ser transportadas para domínios específicos (FERRUCCI; BROWN, 2011), como o domínio de interesse da hipótese a ser testada, (4). Através das técnicas adaptadas, bases intermediárias, (6), poderão ser construídas, sobre as quais novas ferramentas, (7), podem direcionar o conhecimento adquirido no formato adequado, (2). Os elementos inteligentes do modelo AEASD irão interagir com as novas ferramentas adaptadas, (5), e desenvolvidas, (7).


In the figure, (1) represents the AEASD
model (Autonomous Elements Architecture for Specific Domains) (BRAGA; OMAR; GRANVILLE, 2015), which organizes an intelligent agents environment with features focused on the specific area of ​​Autonomous Systems, populating the Internet. It is assumed these smart elements will have more autonomy, if they can learn, teach and cooperate through a knowledge base or ontology, (2), local or remote (such as Wikidata2 and / or others). This ontology can be constructed from unstructured databases, (3), provided that it has the appropriate tools (FAN et al., 2012).
A set of such tools was developed by IBM (FERRUCCI, 2012) (FERRUCCI et al., 2010), through a competent team when the construction of the IBM Watson, (5), facing the incredible challenge to beat humans in Jeopardy! – there are several videos on YouTube about this event, which took place
in 2011. There is strong evidence that with appropriate adjustments, such techniques
can be transported to specific areas (FERRUCCI; BROWN, 2011), as the domain of interest hypothesis to be tested, (4). Through the adapted techniques, intermediate bases, (6), may be built, for which new tools, (7), can direct the acquired knowledge in the proper format, (2). Intelligent elements in AEASD model will interact with new adapted tools, (5), and developed, (7).
.

Neste texto, a preocupação é mostrar, informalmente, a experiência da implementação do Apache UIMA sob o ambiente do Eclipse (MARS.1) em Windows 10, sob Notebook Dual Core (inicialmente) e servir como guia de apoio aos interessados. Posteriormente, outros textos poderão ser produzidos com abordagens focadas no Apache UIMA, como ferramenta de análise dos dados não estruturados dentro do domínio da Infraestrutura da Internet e seus resultados em relação às experiências sobre a hipótese mostrada na Figura 1. A Figura 2, abstratamente, ilustra a tarefa do Apache UIMA em submeter informações (multi modal) do mundo não estruturado, sob um processo de transformação ao mundo dos dados estruturados. Sem mágica, naturalmente.

In this text, the concern is to show informally the experience of implementation of Apache UIMA under the Eclipse environment (MARS.1) in Windows 10, under Notebook Dual Core (initially) and serve as a guide to support interested. Later, other texts can be
produced with approaches focused on the Apache UIMA as unstructured data analysis tool within the Internet infrastructure domain and its results against experience on the hypothesis shown in Figure 1. Figure 2, abstractly, illustrates the Apache UIMA task
to submit information from (multi modal) unstructured world, in a process of transformation to the world of structured data. No magic, of course.

uima-estrutura
Figura 2. O que faz o Apache UIMA8.
Figure 2. What does the Apache UIMA8.

 

… from now on, only in Portuguese…

 

Instalação do Apache UIMA

 

São em sete, o número de etapas3 para se preparar o Apache UIMA para o trabalho a ser executado. Todas elas envolvem diretamente a implementação do Eclipse.

  1. Instalar o Eclipse
  2. Instalar os plugins UIMA no Eclipse
  3. Instalar algumas extensões complementares no Eclipse
  4. Instalar o UIMA SDK
  5. Instalar o código fonte UIMA nos arquivos jar
  6. Instalar o Javadocs do UIMA
  7. Preparar o Eclipse para ver o Código Exemplo

 

Instalação do Eclipse

 

1). Foi instalado o Java SE Develpment Kit (8u66)4

2). Foi instalado o Eclipse “for Java Developers”5, que inclui: Java IDE, cliente GIT, Editor XML, Myliyn, integrador Maven e WindowBulder. Em seguida foi incluído o m2e e o Py IDE. Para as instalações posteriores, veja a documentação6 do Eclipse.

3). Instalados os plugins do UIMA, conforme pode ser visto na Figura 3.

eclipse-uima

Figura 3. Versões dos plugins UIMA instalados no Eclipse.

4). Adicionar a variável de ambiente para o Maven7, recomentado em “One time setup ofr Maven” e “One time setup for Eclipse”. Detalhes nas Figuras 4 e 5.

eclipse-maven

Figura 4. Inclusão da variável de ambiente MAVEN_OPTS (Resultado final)

eclipse-maven2

Figura 5. Visão geral da operação de inclusão da variável de ambiente MAVEN_OPTS.

5). Instalar o UIMA SDK (Apache UIMA Version 2.8.1) disponível em http://mirror.nbtelecom.com.br/apache//uima//uimaj-2.8.1/uimaj-2.8.1-bin.zip . Descompacte-o em qualquer diretório. No meu caso foi em E:apache-uima. Em seguida crie a variável de ambiente %UIMA_HOME% para este diretório. Faça o mesmo para %ECLIPSE_HOME%, para o caminho C:Usersjbeclipsejava-marseclipse.

6). Em seguida executar adjustExamplePaths.bat, no diretório %UIMA_HOME%bin cujo resultado segue abaixo. É preciso ficar atento às quebras de linhas forçadas, para que o texto caiba integralmente.

E:apache-uimabin>adjustExamplePaths.bat
E:apache-uimabin>setlocal
E:apache-uimabin>if "" == "" (set UIMA_JAVA_CALL=java )  
else (set "UIMA_JAVA_CALL=binjava" )
E:apache-uimabin>"java" -cp "E:apache-uima/lib/uima-core.jar" 
org.apache.uima.internal.util.ReplaceStringInFiles 
"E:apache-uima/examples" .xml "C:/Program Files/apache-uima" 
"E:apache-uima" -ignorecase
Ignoring case
Working on file: E:apache-uimaexamplesdataxml
IBM_LifeSciences.xml
Working on file: E:apache-uimaexamplesdataxml
New_IBM_Fellows.xml
Working on file: E:apache-uimaexamplesdataxml
SeminarChallengesInSpeechRecognition.xml
Working on file: E:apache-uimaexamplesdataxml
TrainableInformationExtractionSystems.xml
Working on file: E:apache-uimaexamplesdataxml
UIMASummerSchool2003.xml
Working on file: E:apache-uimaexamplesdataxml
UIMA_Seminars.xml
Working on file: E:apache-uimaexamplesdataxml
WatsonConferenceRooms.xml
Working on file: E:apache-uimaexamplesdeployvinci
Deploy_MeetingDetectorTAE.xml
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdeployvinci
Deploy_PersonTitleAnnotator.xml
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdeployvinci
Deploy_XmiWriterWithTutorialTypeSystem.xml
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdescriptors
MixedAggregate.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineGovernmentOfficialRecognizer_RegEx_TAE.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineNamesAndGovernmentOfficials_TAE.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineNamesAndPersonTitles_TAE.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_enginePersonTitleAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_enginePersonTitleAnnotator_WithinNamesOnly.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineRegExAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineSimpleEmailRecognizer_RegEx_TAE.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineSimpleNameRecognizer_RegEx_TAE.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineSimpleTokenAndSentenceAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineSofaExampleAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineUIMA_Analysis_Example.xml
Working on file: E:apache-uimaexamplesdescriptors
analysis_engineXmlDetagger.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_consumerAnnotationPrinter.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_consumerInlineXmlCasConsumer.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_consumerXCasWriterCasConsumer.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_consumerXmiEcoreCasConsumer.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_consumerXmiWriterCasConsumer.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_consumerXmiWriterWithTutorialTypeSystem.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_multiplierSegmenterAndTokenizerAE.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_multiplierSegment_Annotate_Merge_AE.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_multiplierSimpleTextMerger.xml
Working on file: E:apache-uimaexamplesdescriptors
cas_multiplierSimpleTextSegmenter.xml
Working on file: E:apache-uimaexamplesdescriptors
collection_processing_engineMeetingFinderCPE_Integrated.xml
Working on file: E:apache-uimaexamplesdescriptors
collection_processing_engineMeetingFinderCPE_Managed_Unix.xml
File modified, number of instances replaced: 5
Working on file: E:apache-uimaexamplesdescriptors
collection_processing_engineMeetingFinderCPE_Managed_Windows.xml
File modified, number of instances replaced: 5
Working on file: E:apache-uimaexamplesdescriptors
collection_processing_engineMeetingFinderCPE_NonManaged.xml
Working on file: E:apache-uimaexamplesdescriptors
collection_processing_engineMeetingFinderCPE_
NonManagedCasConsumer.xml
Working on file: E:apache-uimaexamplesdescriptors
collection_processing_engineMeetingFinderCPE_WithXmlDetagging.xml
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdescriptors
collection_readerFileSystemCollectionReader.xml
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdescriptors
collection_readerXmiCollectionReader.xml
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdescriptors
flow_controllerAdvancedFixedFlowController.xml
Working on file: E:apache-uimaexamplesdescriptors
flow_controllerMeetingDetectorTAE_AdvancedFixedFlow.xml
Working on file: E:apache-uimaexamplesdescriptors
flow_controllerMeetingDetectorTAE_Whiteboard.xml
Working on file: E:apache-uimaexamplesdescriptors
flow_controllerWhiteboardFlowController.xml
Working on file: E:apache-uimaexamplesdescriptors
soapServiceGovernmentTitleRecognizerService.xml
Working on file: E:apache-uimaexamplesdescriptors
soapServiceNamesAndPersonTitlesService.xml
Working on file: E:apache-uimaexamplesdescriptors
soapServicePersonTitleAnnotatorService.xml
Working on file: E:apache-uimaexamplesdescriptors
soapServiceSimpleNameRecognizerService.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex1RoomNumberAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex1TutorialTypeSystem.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex2RoomNumberAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex3RoomNumberAndDateTime.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex3TutorialDateTime.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex3TutorialTypeSystem.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex4MeetingAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex4MeetingDetectorTAE.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex4TutorialTypeSystem.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex5RoomNumberAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex6TutorialTypeSystem.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex6UimaAcronymAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex6UimaMeetingAnnotator.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialex6UimaMeetingDetectorTAE.xml
Working on file: E:apache-uimaexamplesdescriptors
tutorialsearchMeetingIndexBuildSpec.xml
Working on file: E:apache-uimaexamplesdescriptors
vinciServiceMeetingDetectorVinciService.xml
Working on file: E:apache-uimaexamplesdescriptors
vinciServicePersonTitleVinciService.xml
Working on file: E:apache-uimaexamplesdescriptors
vinciServiceXmiWriterVinciServiceWithTutorialTypeSystem.xml
Working on file: E:apache-uimaexamplesresourcesorg
apacheuimaexamplesSourceDocumentInformation.xml

E:apache-uimabin>"java" -cp "E:apache-uima/lib/uima-core.jar" 
org.apache.uima.internal.util.ReplaceStringInFiles 
"E:apache-uima/examples" .classpath "C:/Program Files/
apache-uima" "E:apache-uima" -ignorecase
Ignoring case
Working on file: E:apache-uimaexamples.classpath
File modified, number of instances replaced: 5

E:apache-uimabin>"java" -cp "E:apache-uima/lib/uima-core.jar" 
org.apache.uima.internal.util.ReplaceStringInFiles 
"E:apache-uima/examples" .launch "C:/Program Files/
apache-uima" "E:apache-uima" -ignorecase
Ignoring case
Working on file: E:apache-uimaexamplesrun_configuration
UIMA Annotation Viewer.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA CAS Visual Debugger.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA CPE GUI.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA Document Analyzer.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA JCasGen Merge.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA JCasGen.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA PEAR Installer.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA Run AE.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA Run CPE.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA Start Vinci Service.launch
Working on file: E:apache-uimaexamplesrun_configuration
UIMA Start VNS.launch

E:apache-uimabin>"java" -cp "E:apache-uima/lib/uima-core.jar" 
org.apache.uima.internal.util.ReplaceStringInFiles 
"E:apache-uima/examples" .wsdd "C:/Program Files/
apache-uima" "E:apache-uima" -ignorecase
Ignoring case
Working on file: E:apache-uimaexamplesdeploysoap
Deploy_GovernmentTitleRecognizer.wsdd
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdeploysoap
Deploy_NamesAndPersonTitles.wsdd
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdeploysoap
Deploy_PersonTitleAnnotator.wsdd
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdeploysoap
Deploy_SimpleNameRecognizer.wsdd
File modified, number of instances replaced: 1
Working on file: E:apache-uimaexamplesdeploysoap
Undeploy_GovernmentTitleRecognizer.wsdd
Working on file: E:apache-uimaexamplesdeploysoap
Undeploy_NamesAndPersonTitles.wsdd
Working on file: E:apache-uimaexamplesdeploysoap
Undeploy_PersonTitleAnnotator.wsdd
Working on file: E:apache-uimaexamplesdeploysoap
Undeploy_SimpleNameRecognizer.wsdd
E:apache-uimabin>

7). Execute no prompt, eclipse -clean, para carregar o Eclipse.

8). Inclua o caminho %UIMA_HOME% no Eclipse, como mostra a Figura 5.

eclipse-path

Figura 5. Incluindo o %UIMA_HOME% no Eclipse.

9). Crie o novo projeto exemplo do UIMA executando os passos, no Eclipse:

  • Selecione o menu “File” e “Import”
  • Selecione “General/Existing Project into Workspace” e clique no botão “Next”.
  • Clique em “Browse” e indique o diretório %UIMA_HOME%.
  • Clique em “Finish”. Isto irá criar um novo projeto no Eclipse, chamado “uimaj-examples”. Realmente, não houve erro de compilação, como mostra a Figura 6.
eclipse-noproblem

Figura 6. Nenhum erro de compilação do projeto exemplo do UIMA

Após estes passos, o código fonte do UIMA já foi inserido no ambiente do Eclipse, incluindo o Javadocs, não sendo necessário cumprir outras atividades. Portanto, o Eclipse está pronto para o UIMA! Cumpriu-se assim, todas as sete etapas da constantes da seção “Instalação do UIMA”, como mostra a Figura 7.

eclipse-pronto

Figura 7. Visão parcial do Eclipse pronto para o UIMA.

 

Comentários Finais

 

Esta iniciativa de preparar o Apache UIMA para ser testado foi motivado pela disciplina Cognição e Aplicações Computacionais [turma 01A] – 2015/2, ministrada pelos Profs. Dr. Nizam Omar e Dr. Ismar Frango Silveira, no Programa de Pós Graduação em Engenharia Elétrica e Computação, da Universidade Presbiteriana Mackenzie, São Pauo, aos quais expresso meus agradecimentos pela oportunidade.

 

Referências

 

BRAGA, J.; OMAR, N.; GRANVILLE, L. Z. Uma proposta para o uso de elementos inteligentes em domínios restritos da infraestrutura da internet. In: Anais CSBC 2015 – WPIETFIRTF. Recife, Pernambuco, Brasil: [s.n.], 2015.

FAN, J. et al. Automatic knowledge extraction from documents. IBM Journal of Research and Development, IBM, v. 56, n. 3.4, p. 5–1, 2012.

FERRUCCI, D.; BROWN, E. AdaptWatson: A methodology for developing and adapting Watson technology. Armonk, NY, 2011. 8 p. Disponível em: <http://domino.research.ibm.com/library/cyberdig.ns/papers/29303F8DC7A92FC9852579F30049ABCD&gt;.

FERRUCCI, D. A. Introduction to “This is Watson”. IBM Journal of Research and Development, IBM, v. 56, n. 3.4, p. 1–1, 2012.

FERRUCCI, D. et al. Building Watson: An overview of the DeepQA project. AI Magazine, v. 31, n. 3, p. 59–79, 2010.


  1. Apache UIMA. http://uima.apache.org/index.html
  2. Wikidata. https://www.wikidata.org/wiki/Wikidata:Main_Page
  3. UIMA Overview & SDK Setup. http://uima.apache.org/d/uimaj-current/overview_and_setup.pdf
  4. http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
  5. http://www.eclipse.org/users/
  6. http://help.eclipse.org/mars/index.jsp
  7. http://uima.apache.org/one-time-setup.html#maven-setup
  8. Adaptation of Figure 2.1 available in http://uima.apache.org/d/uimaj-current/overview_and_setup.pdf

Modelos: BGP, Internet e outros componentes

 

Instead of trying to impress the reader with what I know,
I try to explain why the things I’ve learned impress me.

Donald Knuth, aqui

 

Introdução

 

Este é o terceiro da série (imagino, longa) de artigos necessários para consolidar as ideias do projeto sobre Objetos de Projeto Estendido (OPE)1. Na sequência do primeiro artigo foi apresentada a MEF (Máquina de Estado Finito) do BGP1. O modelo da MEF foi construído com base na descrição fundamental, isto é, a RFC42714.

Um dos mais importantes componentes dos artigos são os modelos. Via de regra abstratos e produzidos por imagens ou figuras, eles são acompanhados de uma descrição para que se desfaça algumas confusões mentais. A noção de modelos, tal qual se imagina é descrita, a seguir.

 

Modelos

 

Modelos tem sido explorados por muitos pesquisadores e autores. Particularmente, por Scott E. Page5, 6 e 7, em seus inúmeros textos além dos citados. Por exemplo, em seu curso Model Thinking. Professor Scott5 chama a atenção para fatos interessantes, sobre modelos:

  • Quando mais você conhece o contexto, mais seu modelo se aproxima da realidade.
  • Modelos devem ser aperfeiçoados, isto é, refinados de forma sistemática.
  • Nenhum modelo é perfeito. O modelo da MEF do BGP se aproxima mais da realidade quando damos nomes aos arcos com o objetivo de descrever, compreender e garantir sua consistência.
  • Muitas vezes, principalmente em sistema com razoável complexidade, precisamos de vários modelos para descrevê-lo. É o caso do BGP. A MEF não modela o BGP como um todo, mas sim uma parte dele que é o automato finito para que a conexão seja estabelecida. A figura e a respectiva descrição2 representam, por outro lado, uma parte da MEF do BGP. Está faltando o comportamento do autômato finitoo (ou MEF), no que diz respeito às mensagem recebidas, que está disponível no livro do Stewart8.
  • Sistemas como a MEF do BGP tendem a permitir a construção de modelos bem representativos do seu comportamento. Em sistema mais complexos isto só será possível com um conglomerado (ou nuvem) de modelos. O próprio BGP é um sistema muito complicado, como já foi dito. A MEF é um componente, simples, do BGP. Para entender o BGP, como um todo, precisamos de vários modelos. Até mesmo vários modelos de autômatos finitos. por exemplo, para que o BGP funcione, os pares precisam estar conectados. A conexão é feita em TCP. A modelagem de uma conexão TCP exige um outro autômato finito. Veremos isto mais à frente.
  • Há três equívocos comuns cometidos por pessoas, sobre modelos:
    1. Pessoas acreditam piamente em modelos.
    2. Algumas pessoas desacreditam os modelos, por razões políticas.
    3. Pessoas confundem modelos com o que foi produzido por eles. Algo como considerar o BGP como sendo a MEF. Ou, mais simplesmente, como diz Scott, a árvore com a madeira.

Dependendo das ferramentas utilizadas, modelos podem ser complicados para entendermos. É o caso de modelos mais formais onde matemática e física são utilizadas. O próprio Scott6, exibe um formalismo para modelar o comportamento de redes, em geral, com aplicações na Internet, na sociologia, nas finanças e em muitas outras áreas do conhecimento. O formalismo matemático apresentado pelo Professor Scott é necessário para manter o rigor da modelagem e permitir a verificação do desempenho de um modelo usando ferramentas computacionais. As dificuldades podem ser vistas no que o eminente físico Richard Freynman disse para Leonard Mlodinow, [9, página 54]: …eu jamais deveria pensar que compreendi um trabalho de física se tudo o que fiz foi ler a prova de outra pessoa. A única maneira de realmente entender uma teoria, afirmou, é refazer a prova por conta própria – quem sabe você não acaba refutando a teroria? … No mesmo parágrafo, Mlodinow lembra, também, que um professor de Harvard, especializado em probabilidade e estatística disse, a propósito de dificuldades de pessoas e bons matemáticos não conseguirem identificar o erro em algo aparentemente óbvio: …Nosso crérebro não foi muito bem projetado para resover problemas de probabilidade. …

 

O problema de Monty Hall

 

Leonard Mlodinow, faz as citações acima no capítulo 3 do seu incrível livro, páginas 50-68: Encontrando o caminho em meio a um espaço de possibilidades. É a abordagem sobre um programa de televisão apresentado por Monty Hall (nos períodos de 1963-1976 e 1981-1991), uma famosa colunista chamada Marilyn vos Savant (maior QI já registrado no planeta, segundo o Guiness), o brilhante matemático Paul Erdös e uma imensa parcela do povo americano.

Se você ouvir o Scott E. Page falar sobre o problema das três portas de Monty Hall, e em seguida responder a um questionário, este poderá ser apenas uma tentativa. Isto porque, naquele momento você não está acostumado com a Lei do Espaço Amostral, lembrada inicialmente por Gerolamo Cardano, no século XVI. Vejamos o problema, as consequências para Marilyn e sua coluna “Ask Marylin”, Paul Erdös, um pedaço do povo americano e você, ao assistir a aula de Scott.

Com pequenas modificações, ao invés de portas, teremos três caixas de chapéus idênticas e indevassáveis (digamos, chapéus de inglesas abastadas). Elas são grandes o suficiente para caber, em uma delas, o roteador dos seus sonhos (valor em torno de $50,000.00). Nas outras duas caixas serão colocadas “switches” usados, que não necessariamente funcionam, cujo preço de novos está em torno de R$50,00, cada um (“hubs”, talvez). Como a Figura 1, que segue.

 

Figura 1. Três caixas de chapéus enormes, idênticas e indevassáveis. (Desenhadas pelo autor)

 

Se olharmos as caixas com visão de raios X teremos algo parecido com a Figura 2. Esta é a visão do apresentador, que sabe qual caixa contem roteador e quais as duas que contem os equipamentos usados. Este é um fato importante que qualifica o apresentador para interferir no processo da escolha feita pelo competidor (ou você).

 

Figura 2. Conteúdo das caixas de chapéus, vistas com visão de raios X. (Desenhadas pelo autor)

 

O esquema é o seguinte: Você escolhe uma caixa. O apresentador irá então interferir no processo, abrindo uma das caixas que contem um equipamento usado. A seguir ele lhe pergunta se você quer trocar ou não a sua escolha original. O que você deve fazer? Permanecer na caixa escolhida ou trocar de caixa (só tem mais uma para a troca). Em outras palavras, você tem duas caixas a escolher, o que significa que você tem 50% de ganhar o roteador. O que fazer? Continuar na escolha original ou trocar?

Fizeram a mesma pergunta no “AskMarilyn”. Marilyn afirmou em sua coluna que o melhor seria mudar a escolha! Marilyn recebeu cerca de 10.000 cartas reagindo contra sua posição de trocar a caixa original. Também, quase 1.000 matemáticos, aparentemente irados, com a posição de Marilyn. Paul Erdös, em particular, foi agressivo: “Impossível!”, afirmou ele. Foi tão brutal, o impacto que Marilyn parou de discutir o tema. Até que ficou provado que Marilyn estava correta. Paul Erdös só se convenceu depois de avaliar uma simulação feita por computador que mostrou a resposta correta de Marilyn, e admitiu estar errado. Na realidade, quando você tinha de escolher, inicialmente, uma das três caixas, sua chance de coincidir com a caixa do roteador era de 1/3. Mas, quando o apresentador interferiu no processo que era aleatório ele alterou o estado da probabilidade. Melhor dizendo, você sabe que uma das caixas (ela foi aberta!), portanto tem de escolher 2 entre três (2/3!). Dobrou a probabilidade de acertar! Então, troque, pois sua escolha inicial foi com a chance de 1/3! Leonard Mlodinow é perfeito na descrição do problema, no capítulo 3 de seu livro. O modelo (Oops, figura?) exibido na Figura 3 nos dá a noção precisa de nossas escolhas em cada uma das alternativas.

 

Figura 3. Esquema de Monty Hall (adaptado pelo autor)

 

 

Modelando uma conexão BGP

 

Quando estabelecemos uma rede interna, usando o TCP/IP, ou em outras palavras, usando IPv6 ou IPv4 (hoje estamos preferindo o IPv6), nosso cenário é como o da Figura 4. É necessário que nossa LAN (rede local) tenha um “gateway” que seja capaz de receber pacotes em IPv6 de algum equipamento de origem e os encaminhe de volta para a LAN, na direção do destino, na mesma LAN. Este modelo não é único, pois neste caso, o “gateway” pode ser um simples “switch”. Estamos colocando um “gateway”, no modelo, porque estamos enxergando a Internet, na qual deseja-se ardorosamente conectar. Tanto que a exibimos no modelo.

 

Figura 4. Modelo de uma LAN com expectativa de se ligar à Internet em futuro próximo.

 

Quando da decisão de se conectar à Internet, o primeiro passo é encontrar um operador de trânsito que seja membro da Internet. Em outras palavra, procurar por um operador de trânsito que seja um Sistema Autônomo (AS). Por ser um AS, o operador de trânsito poderá nos fornecer os IPv6 que precisamos para estabelecer nossas conexões à Internet. Nosso modelo ficará um pouco mais complexo, visto na Figura 5. Agora temos IPv6 para atender nossas expectativas e nosso “gateway” passa a ser um roteador, quem sabe o que ganhamos do Monty Hall… Para os equipamentos que estão na rede local, a rota “default”, isto é, a direção de pacotes que contem IPv6 que não são nossos, é o IPv6v, colocado na LAN de nosso roteador. Já pacotes com IPv6 desconhecidos do roteador serão encaminhados para a sua rota “default”, que é o IPv6a.

 

Figura 5. Modelo de uma conexão simples de uma rede à Internet.

 

O modelo da Figura 5 não está legal. Falta a ele capturar diversas informações importantes, que podemos enumerar:

  1. A LAN, passou a ser uma rede do operador de trânsito. Na realidade, embora a LAN não pertença ao operador de trânsito, os IPv6 pertencem a ele, partindo do pressuposto de que são IPv6 válidos.
  2. A LAN é cliente comercial do operador de trânsito. O operador de trânsito é um AS.
  3. O cliente comercial não é um Sistema Autônomo. É parte de um Sistema Autônomo.
  4. A conexão TCP estabelece um tráfego de pacotes para, e da Internet usando um protocolo que não é o BGP. Quem usa o BGP é o operador de trânsito.
  5. O cliente comercial é uma rede que está na Internet, via o operador de trânsito.

Como estamos usando um modelo gráfico e estático, muitas informações complementares devem ser descritivas. Porém, à medida que padronizarmos o modelo gráfico, menos descrições complementares serão necessárias. Padronizar, neste caso, envolve um cenário mais universal, no sentido de que a grande maioria dos envolvidos concordam com o que está sendo desenhado. Já existem propostas para isto. Os diagramas da UML (Unified Modeling Language), iniciativa da OMG (Object Management Group) é uma proposta de unificação de padrões, que não cobre somente a engenharia de software.

 

Figura 6. Refinamento do modelo, de uma conexão simples de uma rede à Internet.

 

A Figura 6 é uma proposta de modelo com um significativo refinamento ao da Figura 5. Ele nos traz muito mais informações do que o frágil modelo da Figura 5. Eis os pontos importantes exibidos no novo modelo, os quais dizemos que fazem parte do escopo do modelo:

  1. A Internet que ele está exibindo é a Internet IPv6. Hoje temos duas Internet. A outra é a Internet IPv4.
  2. O operador de trânsito em questão é um Sistema Autônomo. Ele possui um número de AS, no modelo representado por n, ou ASn.
  3. A Internet é um conjunto de ASes (nuvens em verde), incluindo o operador de trânsito.
  4. Está claro agora, que o cliente do operador de trânsito tem acesso à Internet, e que é membro da rede do operador de trânsito, pois ele não é um AS.

Há, também, coisas que o modelo não nos informa (são partes do que chamamos de não escopo), a saber:

  1. Não nos fala nada sobre a Internet IPv4. Fica apenas o registro da Internet IPv6.
  2. O modelo não identifica qualquer acordo entre o cliente e seu operador de trânsito.

O próximo modelo, finaliza nosso refinamento desta etapa, pressupondo de que o cliente passa a ser um AS. Está na figura 7, a seguir.

 

Figura 7. Modelo de uma conexão BGP nas duas Internet.

 

O comentários importantes sobre o modelo da Figura 7, são os seguintes:

  1. Retiramos a ideia de operador de trânsito. Temos agora, somente os ASes que, na realidade, fornecem tráfego através da Internet ou não. Tráfego é trânsito, ou transporte, ou “peering”, ou todos eles. Estas noções podem ser vistas em [10].
  2. As duas Internet estão transparentes. O ex-cliente, agora ASj é dono de seus próprios IPs. Como, geralmente, um AS tem IPv6 e IPv4, ele pode se conectar à Internet IPv6 e/ou IPv4, através de várias técnicas, uma das quais é a pilha dupla, que o modelo subentende.
  3. A ideia mais importante mostrada no modelo é a Conexão TCP. Antes de ser AS, o cliente tinha, também, uma conexão TCP. Agora, sendo AS, ele ativou o protocolo BGP, que só se viabiliza, se os “pares” tiverem uma conexão TCP, entre si.

 

Modelando o BGP

 

Na seção anterior, os modelos foram construídos para conexões BGP e não para o BGP propriamente dito. Já está claro que para uma conexão BGP funcionar, dois componentes são importantes: uma conexão TCP e a MEF do BGP. A MEF do BGP já é nossa conhecida. Sobre conexão TCP, muito pouco foi dito, até agora. A questão importante sobre conexão TCP é de que ela é estabelecida, usando-se soquetes. Um exemplo prático pode ser visto aqui no blogue3, onde soquetes foram usados para estabelecer uma conexão de telnet sob a ótica do paradigma cliente-servidor. Entretanto, já sabemos, também, que ao falarmos de BGP, a característica cliente-servidor desaparece. O mesmo acontece com a conexão TCP que dá suporte, ou que viabiliza o BGP. Isto nos leva a pensar da forma correta de que uma conexão TCP é estabelecida atrávés de um autômato finito ou MEF, também.

Falaremos sobre a MEF de uma conexão TCP em outro momento, mas podemos modelar o BGP conforme a Figura 8, que segue.

 

Figura 8. Modelo de uma conexão da MEF do BGP.

 

Eis as informações que nos interessam sobre o modelo acima:

  1. Os empareamentos são: ASi com ASj e ASj com ASk.
  2. O pré-requisito para iniciar uma conexão TCP é a existência de ligações físicas (camada L1), entre os empareados. Não interessa a extensão destas ligações.
  3. A MEF do TCP inicia o processo em entendimento entre os pares. Uma vez estabelecida a conexão TCP, o estado IDLE da MEF do BGP é acionado.
  4. A MEF do TCP mantêm a conexão TCP. Se ela cair, a conexão BGP cai e o processo começa novamente por ela, que no momento adequado aciona novamente o estado IDLE do BGP.
  5. Cada empareamento age de maneira independente. Se cair a conexão de um, o outro continua.
  6. Observa-se que, cada dia que passa, as conexões de camada física estão se tornando mais estáveis, apesar do preço cada vez mais baixo. Provavelmente, consequência da competição que está aumentando e a necessidade das operadoras (ou ASes) se tornarem mais eficientes. Um visível sintoma é o fato do Nic.br (no Brasil) já admitir que um AS possa ter somente uma conexão.

 

Conclusões

 

A MEFTCP é o mais importante para a proposta de OEP1. Da mesma forma que a MEFBGP, a qual ficará completa quando for analisado o mecanismo de mensagens do BGP.

A noção sobre modelos é apenas um princípio de como se pode tratar questões ligadas a implementação de BGP. O tratamento deve ser semelhante a um projeto. Os processos são as diversas etapas que seguem aquelas recomendadas a um projeto normal. Há requisitos, escopo e a implementação propriamente dita. Provedores de Internet, principalmente os pequenos sofrem na mão de grandes operadores. Se as propostas referente a um esquema mais profissional de implementação de projetos, quando se tratar de BGP, os ganhos serão enormes e podem, inclusive, admitir à ANATEL a criação de um mecanismo adequado para ela administrar sua função de vigilante das normas legais. Um exemplo é o uso de algo parecido com um Termo de Abertura do Projeto (TAP), criado especificamente para este fim. Sobre este assunto, isto é, a aplicação de metodologias e/ou técnicas de projetos sobre implementações de BGP, incluindo análise de topologias e outros protocolos associados (iBGP, OSPF, entre outros), oportunamente serão tratadas aqui neste blogue.

 

Referências

 

  1. Julião Braga. (Agosto 2012). Objetos de Projeto Estendidos (OPE). Disponível em: https://juliaobraga.wordpress.com/2012/08/22/objetos-de-projeto-estendidos-ope/. Acessado em 05/09/2012.
  2. Julião Braga. (Agosto 2012). Máquinas de estado finito: Parte Prática: MEF do BGP. Disponível em: https://juliaobraga.wordpress.com/category/projetos/gerenciamento-de-projetos/. Acessado em 05/09/2012.
  3. Julião Braga. (Março 2012). Soquetes: PHP, IPv6 e ‘inseguridade. Disponível em: https://juliaobraga.wordpress.com/2012/03/04/soquetes-em-php-ipv6/. Acessado em 05/09/2012.
  4. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 05/09/2012.
  5. Scott E. Page. Prologue The Card Catalogue. Disponível em: http://www.cscs.umich.edu/~spage/ONLINECOURSE/R1Page.pdf. Acessado em 09/09/2012.
  6. Scott E. Page, Lecture 23 Networks. July 28, 2006. Disponível em: http://www.cscs.umich.edu/~spage/teaching_files/modeling_lectures/MODEL5/M29networknotes.pdf. Acessado em 09/09/2012.
  7. Scott E. Page, The Difference: How the power of diversity creates better groups, firms, schools, and societies. Aug 11, 2008. Disponível em: http://pt.scribd.com/doc/82442356/Scott-E-Page. 424 p. Acessado em 09/09/2012.
  8. Stewart, J. W. III. BGP4: inter-domain routing in the Internet. Reading, Mass.: Addison Wesley, 1998.
  9. Leonard Mlodinow (1954). O andar do bêbado: como o acaso determina nossas vidas. Rio de Janeiro: Zahar, 2009. Tradução de Diego Alfaro.
  10. Julião Braga. (Março 2010). Tráfego, trânsito, transporte e peering (uma proposta de definição). Disponível em: https://juliaobraga.wordpress.com/2010/03/09/trafego-transito-transporte-e-peering/. Acessado em 10/09/2012.
%d blogueiros gostam disto: