The Topology of A2RDTestbed

 

Introdução

 

Este artigo descreve o ambiente que servirá como teste para o projeto A2RD, tratado em artigo anterior.

A topologia lógica é apresentada na Figura 1. Há algumas questões pendentes, tais como o local onde este ambiente será implementado, autorizações e acordos formais, recursos físicos e lógicos da Internet (numeração, conexões, tráfego, etc.).

É uma topologia portátil. Ela poderá mudar de local e não deve criar problema de transporte. Por exemplo, “desktops” são difíceis de transportar, devido ao volume, mas HDs podem. HDs podem se o SO o permitir. FreeBSD, por exemplo, permite a portabilidade de HDs. IPv4 e IPv6 públicos são de portabilidade fácil se os túneis escolhidos respondem por serviços disponíveis no mundo todo. Mas, se necessário a portabilidade internacional, é importante lembar que recursos de um pais podem não ser recomendados para outros países. A mochila da Figura 2 é hospedeira de todos os recursos físicos da topologia, quando necessário o transporte.

 

Introduction

 

This article describes the environment that will serve as a test for the A2RD project discussed in the previous article.

The logical topology is presented in Figure 1. There are some outstanding issues, such as where this environment will be implemented, authorizations and formal agreements, physical and logical Internet resources (numbering, connections, traffic, etc.).

It is a portable topology. It may change places and should not create a transportation problem. For example, “desktops” are difficult to carry because of the volume, but HDs can. HDs can if the OS allows it. FreeBSD, for example, enables the portability of hard drives. Public IPv4 and IPv6 are easy portability if the tunnels chosen account for services available worldwide. But if international portability is required, it is important to remember that one country’s resources may not be recommended for other countries. The backpack of Figure 2 is the host of all the physical resources of the topology, when necessary transport.

 

LabA2RD-id
Figura 1. Logical view of the A2RDTestbed topology

 

mochilaA2SDTestbed
Figura 2. All physical resources of the A2RDTestebed should fit into this backpack.

 

 

Descrição da topologia

 

A topologia da Figura 1 nomeada como A2RDTestbed caracteriza três representações lógicas: duas Redes Locais (LANs) em um ambiente comum chamadas, respectivamente, carl e cassini e diversas redes remotas chamadas, simplesmente, Exterior.

Há alguns pré-requisitos a serem seguidos em relação à implantação da topologia:

  • Não se sabe o IPv4 da interface do empareamento com (2). Também, ainda não se sabe nada sobre IPv6. Entretanto, preferencialmente, as conexões públicas serão IPv6.
  • Dependendo das facilidades no local de implementação da A2RDTestbed poderá haver NAT IPv4, pois alguns servidores locais precisam acesso remoto à Internet IPv4.
  • Evitar o uso de cabo com preferência a rede sem fio. Entretanto, no Exterior esta questão não é trivial. A conexão entre os roteadores (1) e (2) terá de ser cabo coaxial, de no máximo 50 cm.
  • Toda a infraestrutura das redes carl e cassini é projetada para permitir sua instalação em qualquer local e seus equipamentos / recursos devem facilitar o transporte.

carl

(1): Roteador de borda (Mikrotik RB450) – é o roteador de borda da LAN carl e, também, integra a LAN cassini, anunciando o bloco 192.168.168.0/24. Dependendo do acordo de conexão com o roteador (3) (Pendência 1) poderá usar e/ou, eventualmente anunciar IPv4 público para (2). A interface de rede local deste roteador será 192.168.168.254/25. O bloco 192.168.168.0/25 será roteado para demandas locais. A interface para (2) será 10.10.10.1/30 e o roteamento será dinâmico com base na tabela de rotas construída pelos anúncios vindos de (2), em conexão BGP.
(11): ponto de acesso sem fio,
com switch
– responsável pelas conexões à LAN sem fio carl, para onde todo o bloco 192.168.168.128/25 está conectado via rota estática de (1). A conexão com o roteador (1) será via cabo coaxial de no máximo 50 cm.
(12): notebook responsável para hospedar servidores como o intelligent Internet Route Registry (iIRR}, looking glass (LG), Domain Name System (DNS), quagga e outros. Pela característica dos serviços e do acesso (via ssh), terá sistema operacional a la Linux. A proposta é que seja um notebook com um servidor Ubuntu. Mas será analisado a hipótese de um Chromebook.

Ele, também será responsável por estabelecer uma sub rede da rede carl, a qual terá pelo menos dois Raspberry PI.

(13): ponto de acesso sem fio,
com switch
– responsável pela sub rede russel. A conexão com (12) é via cabo coaxial de no máximo 80 cm.
(14): Vários Raspberry PI que habitarão as redes e sub redes descritas acima. Eles serão os principais (mas não os únicos) hospedeiros dos Elementos Inteligentes (IEs) do modelo A2RD. A razão de utilizar tais equipamentos se justifica pelas pesquisas dos IEs em Internet of Things (IOT) criando ambiente propício para testes relacionados com o projeto Dark Thing Security (DTS) (BRAGA et al., 2017).
(15): recursos de IPs – note-se que o IPv6 ainda não está definido. Provavelmente, a solução será usar um túnel, para manter a independência das configurações da A2RDTestbed em relação à sua localização.

 

cassini

(2): Roteador de borda (Mikrotik RB450) é o roteador de borda da LAN cassini e, também, integra a LAN carl, anunciando o bloco 192.168.192.0/24. A interface de rede local deste roteador será 192.168.192.254/25. O bloco 192.168.192.0/25 será roteado para demandas locais. A interface para (1) será 10.10.10.2/30 e roteada por ela através de tabela de rotas construída pelos anúncios de (1).
(21) ponto de acesso sem fio,
com switch
– responsável pelas conexões à LAN sem fio cassini, para onde todo o bloco 192.168.192.128/25 está conectado via rota dinâmica de (2). A conexão com o roteador (1) será via cabo coaxial de no máximo 50 cm.
(22): telefone VoIP para conectar ao INOC.br. Provavelmente terá de suportar voz sob NAT. O aparelho será adquirido no local da primeira instalação e servirá para contatos com qualquer administrador de um AS e outras pessoas interessantes.
(23): notebook pessoal do administrador da A2RDTestbed – contribui com Windows 10, FreeBSD e outros SO, no ambiente da A2RDTestbed. Se ele estiver remoto ao A2RDTestbed, ele captura um IP da LAN cassini via uma conexão VPN.
(24): Vários Raspbery PI hospedeiros de IEs do ambiente do AS, ao qual eles pertencem.
(25): recursos de IPs – note-se que o IPv6 ainda não está definido. Provavelmente, a solução será usar um túnel, para manter a independência das configurações da A2RDTestbed em relação à sua localização.

 

Exterior

(3): roteador de empareamento de um ambiente de projeto denominado PEERING cujas condições de conexão estão em negociações finais (Pendência 2).
(4): trânsito alternativo – fornecido pelo projeto PEERING. Ainda são desconhecidos os detalhes dos recursos a serem disponibilizados.
(5):Internet.
(6):roteador do fornecedor local de trânsito para a Internet. Ainda é desconhecido se o trânsito é síncrono ou assíncrono, pois depende da disponibilidade da localidade onde a A2RDTestbed será implementa. Os acessos remotos, através de VPN serão feitos através deste enlace.
(7):roteador para captura de recursos da Internet e consequente trânsito. Este enlace é uma alternativa para conseguir os recursos, caso não se consiga via (6).
(8):tráfego com o operador de trânsito onde a A2RDTestbd está instalada. É o único canal de comunicação efetivo, como veremos na Topologia Física, Figura 3.
(9):eventual trânsito opcional.
(10): – tráfego de VPN e / ou BGP,
com o PEERING.
(20): – tráfego de VPN e / ou BGP,
com o eventual provedor de recursos de numeração, IPv4, IPv6, etc.
(30): – peering entre as duas LANs da A2RDTestbd.

 

A topologia física

 

A Figura 3 exibe a topologia física. Em outras palavras, a topologia possível. Só há um ponto de conexão para o Exterior. Todas as outras conexões (e tráfego) compartilham o empareamento (2) com (6). Assim, por exemplo, (1) recebe o tráfego de PEERING através de (2) que garante a fluxo da maneira desejada.

 

Topology description

 

The topology of Figure 1 named as A2RDTestbed characterizes three logical representations: two Local Area Networks (LANs) in a common environment called, respectively, carl and cassini and several remote networks called, simply, Outer.

There are a few prerequisites to follow regarding topology deployment:

  • The IPv4 of the pairing interface with (2) is unknown. Also, nothing is known about IPv6 yet. However, preferably, the public connections will be IPv6.
  • Depending on the facilities at the A2RDTestbed implementation site, there may be IPv4 NAT because some local servers need remote IPv4 Internet access.
  • Avoid using cable with preference to the wireless network. However, this issue is not trivial in the Outer. The connection between the routers (1) and (2) must be a coaxial cable of a maximum of 50 cm.
  • The entire infrastructure of the carl and cassini networks is designed to allow them to be installed in any location and their equipment / resources should facilitate transportation.

carl

(1): Border Router (Mikrotik RB450) – is the router router of LAN carl and also integrates the LAN cassini, advertising the block 192.168.168.0/24. Depending on the connection agreement with the router (3) (Pending 1) you can use and / or eventually advertise public IPv4 to (2). The local network interface of this router will be 192.168.168.254/25. Block 192.168.168.0/25 will be routed to local demands. The interface to (2) will be 10.10.10.1/30 and the routing will be dynamic based on the route table built by the ads coming from (2), in BGP connection.
(11): wireless access point, with switch – responsible for the wireless LAN carl connections, where all the 192.168.168.128/25 block is connected via static route of (1). The connection to the router (1) will be via coaxial cable of maximum 50 cm.
(12): is a notebook that is responsible for hosting servers such as the intelligent Internet Route Registry (iIRR), looking glass (LG), Domain Name System (DNS), quagga and others. The proposal is that it be a notebook with an Ubuntu server, but the possibility of a Chromebook will be analyzed.

He will also be responsible for establishing a sub network of the carl network, which will have at least two Raspberry PIs.

(13): wireless access point, with switch – responsible for russel subnet. The connection to (12) is via coaxial cable of maximum 80 cm.
(14): several Raspberry PIs will hosting the networks and sub networks described above. They will be the main (but not the only) hosts of the A2RD Intelligent Elements (IEs). The reason for using such equipment is justified Internet of Things (IOT) research, creating a favorable environment for tests related to the Dark Thing Security (DTS) project (BRAGA et al., 2017).
(15): IP resources – note that IPv6 is not yet defined. Most likely, the solution will be to use a tunnel to maintain the independence of A2RDTestbed‘s settings from its location.

 

cassini

(2): Border router (Mikrotik RB450) – is the border router of the cassini LAN and also integrates carl LAN, advertising the block 192.168.192.0/24. The local network interface of this router will be 192.168.192.254/25. Block 192.168.192.0/25 will be routed to local demands. The interface to (1) will be 10.10.10.2/30 and it will be routed through the route table built by (1) advertising.
(21): wireless access point, with switch – responsible for the connections to the wireless cassini LAN, where the entire 192.168.192.128/25 block is connected via the (2) dynamic route. The connection to the router (1) will be via coaxial cable of maximum 50 cm.
(22): VoIP to connect to INOC.br – probably have to support voice under NAT. The device will be purchased at the first installation site and will be used for contacts with any AS administrator and other interesting people in the world.
(23): A2RDTestbed’s personal administrator notebook – contributes with Windows 10, FreeBSD and other OS, in the A2RDTestbed environment. If it is remote to the A2RDTestbed, it captures an IP of the cassini LAN via a VPN connection.
(24): several Raspberry PI hosts from IEs of the AS environment, to which they belong.
(25): IP resources – note that IPv6 is not yet defined. Most likely, the solution will be to use a tunnel to maintain the independence of A2RDTestbed’s settings from its location.

 

Outer

(3): peering router with a design environment called PEERING whose connection conditions are in final negotiations (Pending 2).
(4): alternative traffic – provided by the PEERING project. The details of the resources to be made available are still unknown.
(5): Internet.
(6): router from the local transit provider – to the Internet. It is still unknown if the traffic is synchronous or asynchronous, as it depends on the availability of the locality where the A2RDTestbed will be implemented. Remote access through VPN will be done through this link.
(7): Router for capturing Internet resources and consequent traffic. This link is an alternative to obtain the resources, if one can not get via (6).
(8): local transit operator where A2RDTestbd is installed. It is the only effective communication channel, as we will see in Physical Topology, Figure 3.
(9): optional transit
(10): VPN traffic and / or BGP, with PEERING
(20): VPN traffic and / or BGP, with the eventual provider of numbering resources, IPv4, IPv6, etc.
(30): traffic etween the two A2RDTestbd LANs.

 

Phyisical topology

 

Figure 3 shows the physical topology. In other words, the possible topology. There is only one point of connection to the Exterior. All other connections (and traffic) share the peering (2) with (6). Thus, for example, (1) receives the PEERING traffic through (2) which guarantees the flow in the desired manner.

 

LabA2RD-real
Figura 3. Phisical view of the A2RDTestbed topology

 

 

Considerações Finais

 

  1. carl é uma homenagem a Carl Sagan.
  2. cassini é uma homenagem à fantástica sonda Cassini, da NASA e ao incrível trabalho da equipe associada.
  3. russel é uma homenagem a Bertrand Russel, meu bisavô acadêmico.

 

Final Considerations

 

  1. carl is a tribute to Carl Sagan.
  2. cassini is a tribute to the fantastic Cassini, a NASA probe and the incredible work of the associated team.
  3. russel is a tribute to Bertrand Russell, my academic grandfather.

 

Referências

 

  1. BRAGA, J.; SILVA, R. A.; ENDO, P. T.; OMAR, N. Dark Think Security: Enhancing the Security for the Autonomous Architecture over a Restricted Domain. In: Proceeding of CSBC 2017. Mackenzie Presbiterian University: [s.n.], 2017. p. 8.

Refinando o modelo da base de conhecimento para o A2RD | Refining the Knowledge Base Model for A2RD

 

Introdução

 

O modelo ANARD (descrito em artigos anteriores, neste blogue) passou a ser chamado de Autonomous Architecture for Restricted Domain (A2RD). Trata-se de um amadurecimento do modelo e, o objetivo este texto é exibir este amadurecimento.

 

O Refinamento

 

Há quase um ano atrás, em um artigo denominado wordIETF, exibi o primeiro modelo de meu projeto de pesquisa de longo prazo, conforme apresentado na Figura 1. Não está em debate, minha estranha habilidade para desenhar.

 

Introduction

 

The ANARD model (described in previous articles in this blog) came to be called Autonomous Architecture for Restricted Domain (A2RD). It is a maturation of the model and the purpose of this text is to display this maturity.

 

The Refinement

 

Almost a year ago, in an article called wordIETF, I exhibited the first model of my long-term research project as shown in Figure 1. It is not in debate, my strange ability to draw.

 


Figura 1. Primeiro modelo do projeto de pesquisa de longo prazo (novembro 2015). / First model of the long-term research project (November 2015).

 

Quando este modelo foi desenhado, eu tinha em mente a minha tese de doutorado e minha atividade de pesquisa de longo prazo. Sempre foi preponderante, pesquisa de longo prazo. Portanto, elevados graus de dificuldades não tinham muito importância. Eu estava bastante entusiasmado (e extremamente influenciado) pelo curso de Cognição dos Profs. Nizam Omar e Ismar Frango. O meu trabalho final do curso foi analise detalhada sobre o Watson𝑇𝑀 e a experiência com o Jeopardy! (FERRUCCI, 2012; GLIOZZO et al., 2013). A equipe do IBM Watson fez um trabalho invejável, consequentemente, a vontade em devorar essa experiência não teve limitações. Reuni toda a literatura, quase uma revisão sistemática, li os artigos principais, refleti sobre os resumos de todos os outros artigos e pratiquei uma leitura transversal em muitos. Participei dos cursos disponíveis e adicionei ao meu Codex (uma versão ingênua do Notebook de Feynman), umas trezentas e poucas páginas em Latex.

Assim, o modelo da Figura 1 saiu da minha ansiedade em entregar conhecimento aos meus agentes ou Elementos Inteligentes, do inglês IEs. Para isto ficou evidente que eles deveriam ter acesso a uma base de conhecimento (4). Na época e, ainda agora, não imagino como o conhecimento será utilizado pelos IEs. Nem consigo ser preciso na organização desta base de conhecimento, exceto o fato de que serão ontologias (ISOTAMI; BITTENCOURT, 2015).

Apesar da disponibilidade do conhecimento sobre as técnicas utilizadas no Watson, para tratar bases de dados multimodais e de alguns exercícios que fiz sobre elas decidi que não iria me aventurar além do repositório do RFC Editor, (1). Imediatamente comecei a exercitar sobre o repositório, principalmente depois de ler textos convenientes (INGERSOLL; MORTON; FARRIS, 2013). Em Python, como o Mathematica e tudo o mais que encontrava pela frente.

Refinamentos sucessivos e, particularmente a técnica de “dividir para conquistar” lembraram-me de que as atividades relacionadas com o léxico das RFCs, (2), deveriam produzir inúmeros arquivos para serem trabalhados pela etapa de destilação semântica, (3), que iria construir a base de conhecimentos.

Neste momento imaginei ser um destes arquivos resultantes das divisões, ao qual chamei wordIETF, semelhante ao WordNet (MILLER, 1995;
FELLBAUM, 1998). O wordIETF poderia ajudar diretamente os IEs do modelo A2RD e apoiar o desenvolvimento da base de conhecimento (MOREIRA; FILHO; OLIVEIRA, 2016). Estava começando a ideia de usar as técnicas de aprendizagem de máquina (Machine Learning), ou ML, daqui para frente.

Foi ai que surgiu a Figura 2, sem perceber que o pessoal do RFC Editor, para facilitar nossa vida, criou um arquivo em XML do seu repositório. Mais tarde utilizei este arquivo para facilitar e aperfeiçoar o wordIETF.

When this model was drawn, I had in mind my doctoral thesis and my long-term research activity. Always been preponderant, my long-term research. Therefore, high degrees of difficulty were not very important. I was very enthusiastic (and extremely influenced) by the Cognition lecture give by Prof. Nizam Omar and Prof. Ismar Frango. My final work of the course was detailed analysis on Watson𝑇𝑀 and the experience with Jeopardy! (FERRUCCI, 2012; GLIOZZO et al., 2013). The IBM Watson team did an enviable job, and consequently, the willingness in devouring Watson’s experience had no limitations. I gathered all the literature, almost a systematic review, read the main articles, reflected on the abstract of all the other articles and practiced a transversal reading in many. I participated in the courses available and added to my Codex (a naive version of Feynman’s Notebook), some three hundred and a few Latex pages.

Thus, the Figure 1 model came out of my anxiety to deliver knowledge to my agents or Intelligent Elements (IEs). For this it became evident that they should have access to a knowledge base (4). At the time, and even now, I can not imagine how the knowledge will be used by IEs. I can not even be precise about the organization of this knowledge base, except the fact that they will be ontologies (ISOTAMI; BITTENCOURT, 2015)

In spite of the availability of the knowledge about the techniques used in Watson, to treat multimodal databases and some exercises that I did on them, I decided that I would not venture beyond the RFC Editor repository. (1). Immediately I began to exercise on the repository, especially after reading convenient texts (INGERSOLL; MORTON; FARRIS, 2013). In Python, like Mathematica and everything else that lay ahead.

Successive refinements, and particularly the “divide and conquer” technique, reminded me that the activities related to the lexicon of the RFCs, (2), should produce numerous files to be worked through of semantic distillation, (3), which would build the knowledge base.

At the moment I imagined it to be one of these files resulting from the divisions, which I called wordIETF, similar to WordNet (MILLER, 1995;
FELLBAUM, 1998). wordIETF could directly support IEs A2RD model and support the development of the knowledge base (MOREIRA; FILHO; OLIVEIRA, 2016). I was starting the idea of using Machine Learning techniques, or ML, going forward.

This is where Figure 2 appeared, not realizing that RFC Editor’s staff, to make life easier, created a XML file of their repository. I later used this file to make easier and better the wordIETF.

 

O wordIETF

 

O WordNet foi o modelo gerador da ideia do wordIETF. Mas, não foi um modelo suficiente, no sentido de uma cópia idêntica. Além de uma referência léxica do domínio das RFCs, o wordIETF seria uma base fundamental para a construção da base de conhecimento, e também, uma entrada fundamental para aprendizagem dos IEs. Entretanto, naquele momento, a noção de conjunto de treinamento não estava claro, mas o apoio do wordIETF tanto para os IEs como para o destilador semântico estava. Assim, mesmo sem muitos detalhes, a presença do WordIETF apareceu no modelo (Figura 2) e aparentemente poderia auxiliar desenvolvimentos no âmbito da Infraestrutura da Internet.

 

wordIETF

 

WordNet was the template for the wordIETF idea. But it was not a sufficient model, in the sense of an identical copy. In addition to a lexical reference of the RFCs domain, wordIETF would be a fundamental basis for the construction of the knowledge base, as well as a key input for learning the IEs. However, at that time, the notion of training set was unclear, but the support of the wordIETF for both the IEs and the semantic distiller was. Thus, without much detail, the presence of WordIETF appeared in the model (Figure 2) and could help some developments in the scope of Internet Infrastructure.

 


Figura 2. A participação do wordIETF no conhecimento e aprendizagem dos IEs (setembro 2016). / The participation of wordIETF in the knowledge and learning of IEs (September 2016).

 

A necessidade do wordIETF foi amadurecendo durante os eventos do IETF, a começar em novembro de 2015 em Yokohama, Japão (IETF 94), quando iniciei a participação presencial no WG anima. Terminando o encontro aumentava o entusiasmo sobre o wordIETF e, em proporção direta, as dúvidas. Os dois sentimentos levaram-me a pensar em um espaço no WG anima para o próximo encontro do IETF, em Buenos Aires, Argentina (Abril, IETF 95). Isto não foi possível, mas em uma conversa, sobre as tendências do WG anima, com o Prof. Jéferson Campos Nobre, da Unisinos, a conversa do wordIETF fluiu naturalmente, do café no saguão do Hotel Hilton, algumas dúvidas ficaram desproporcionais ao entusiasmo. Em julho, durante o IETF 96, em Berlim, Alemanha, a noção de que o wordIETF iria contribuir para a aprendizagem dos IEs, ficou bastante clara. Então, surgiu a Figura 3.

The need for wordIETF was maturing during the IETF events, starting in November 2015 in Yokohama, Japan (94th IETF), when I began to take part in the WG anima. At the end of the meeting, my enthusiasm for wordIETF increased and, in direct proportion, the doubts. Both feelings led me to think for a space in the WG anima for the next IETF meeting in Buenos Aires, Argentina (April, IETF 95). This was not possible, but in a conversation, on the trends of WG anima, with Prof. Jéferson Campos Nobre, from Unisinos, the wordIETF conversation flowed naturally, from coffee in the lobby of the Hilton Hotel, some doubts were disproportionate to enthusiasm. So, Figure 3 emerged.

 


Figura 3. Participação do wordIETF na aprendizagem dos IEs (novembro 2016). / Participation of the wordIETF in IEs learning (November 2016)

 

Na realidade, após o IETF 97, em novembro em Seul, na Coréia do Sul (IETF 97), representei o wordIETF na aprendizagem dos IEs.

Mas este desenho ficou um pouco confuso. Portanto, foi necessário uma repaginação no projeto para que ficasse definitivamente claro, com suas seis etapas, como aparece na Figura 4.

In fact, after IETF 97, in November in Seoul, South Korea (IETF 97), I represented wordIETF in the learning of IEs.

But this drawing got a bit confusing. Therefore, a repagination was necessary in the project to be definitely clear, with its six steps, as shown in Figure 4.

 

tese-proposta08
Figura 4. O modelo aperfeiçoado (abril 2017). / The improved model (April 2017).

 

Eis as seis etapas e suas questões de pesquisas envolvidas:

  1. Captura e /ou atualização do repositório de RFCs local.
  2. Refinamento léxico e sintático das RFCs (Questão de Pesquisa 1).
  3. Conjunto de ferramentas a serem apropriadas e / ou desenvolvidas, com o objetivo de transformar os dados intermediários em Conjuntos de objetos e estes em Conjuntos de Dados de Treinamento. Também, ferramentas que apoiem a Destilação Semântica (item 4) na construção da base de conhecimento.
  4. Destilação semântica que constrói e / ou atualiza a base de conhecimento (Segunda Questão de Pesquisa).
  5. Algoritmos de Aprendizagem para os IEs.
  6. Uso da base de conhecimento pelos IEs.

 

Explorando o modelo

 

Para explorar o modelo vamos focar no wordIETF e supor que desejamos ensinar aos nossos IEs, como identificar um acrônimo e seu respectivo significado. Vamos construir um wordIETF, a partir do repositório de RFCs e preenchê-lo com dois tipos de elementos, aos quais, indistintamente, chamaremos de token: substantivos e acrônimos. Este processo de divisão de um texto ou de uma sentença, em tokens, é chamado de tokenization, em inglês. Assim, ao popular o wordIETF com os dois tipos de pares de tokens, a saber:

  • (substantivo, n), onde “n” é o número de vezes que o substantivo ocorre no texto.
  • (acrônimo, significado)
  • </ul

    Seja o seguinte trecho de uma RFC:

    This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG).

    Cada palavra ou símbolo que aparece no trecho acima é um token. Por exemplo, o “.” é um token. Como queremos somente nomes e siglas, vamos eliminar do texto, tudo o que não nos interessa, incluindo os verbos. Assim, o novo texto será:

    document Experimental Protocol Internet community document product Internet Engineering Task Force IETF consensus IETF community public review publication Internet Engineering Steering Group IESG

    A partir do texto acima, podemos separar os nomes e os acrônimos e os respectivos significados. Em ordem lexicográfica, o wordIETF ficará assim:

    community 2
    consensus 1
    document 2
    Experimental 1
    IESG Internet Engineering Steering Group
    IETF Internet Engineering Task Force
    Internet 1
    Protocol 1
    public 1
    publication 1
    review 1

    Com base na tabela acima, que representa o conteúdo do wordIETF é fácil concordar que os IEs serão capazes de identificar qualquer acrônimo, se todas as RFCs do repositório foram usadas para construí-lo.

    Na realidade, o exemplo que foi dado acima é didático e não corresponde à realidade da aplicação. A estrutura do wordIETF é bem mais complexo do que uma tabela com duas colunas. Para efetivamente presentear os IEs com conhecimento capaz de distinguir acrônimos usamos a técnica de aprendizagem supervisionada, na qual o chamado conjunto de treinamento será utilizado. Veremos mais sobre isto em outro texto.

Here are the six steps and their research questions involved:

  1. Capture to and / or update the local RFCs repository.
  2. Lexical and syntactic refinement of RFCs (Research Question 1).
  3. Set of tools to be appropriate and / or developed with the objective of transforming the intermediate data into Object Data Sets and so these into Training Data Sets. Also, these tools will support the Semantic Destillation (Step 4) in the construction of the knowledge base.
  4. Semantic Destillation and construction or updated the knowledge base (Research Question 2)
  5. Learning Algoritms for IES.
  6. Use of knowledge base by IEs (Research Question 3).

 

Exploring the model

 

To explore the model, let’s focus on wordIETF and assume that we want to teach our IEs how to identify an acronym and its meaning. Let’s build the wordIETF, from the repository of RFCs and fill it with two types of elements, which we will call the token: nouns and acronyms. This process of dividing a text or a sentence into tokens is called tokenization. Thus, to populate the wordIETF with the two types of pairs of tokens, namely:

  • (noun, n), where “n” is the number of times that the noun appear in text.
  • (acronym, mean)
  • </ul

    Be the following excerpt from an RFC:

    This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG).

    Each word or symbol that appears in the passage above is a token. For example, the “.” Is a token. Since we only want nouns and acronyms, we will eliminate from the text everything that does not interest us, including verbs. Thus, the new text will be:

    document Experimental Protocol Internet community document product Internet Engineering Task Force IETF consensus IETF community public review publication Internet Engineering Steering Group IESG

    From the above text, we can separate the names and acronyms and their meanings. In lexicographic order, the wordIETF will look like this:

    community 2
    consensus 1
    document 2
    Experimental 1
    IESG Internet Engineering Steering Group
    IETF Internet Engineering Task Force
    Internet 1
    Protocol 1
    public 1
    publication 1
    review 1

    Based on the table above, which represents the content of wordIETF it is easy to agree that IEs will be able to identify any acronym if all the RFCs in the repository were used to construct it.

    In fact, the example given above is didactic and does not correspond to the reality of the application. The wordIETF structure is much more complex than a two-column table. To effectively to gift IEs with knowledge able to distinguish acronyms we use the technique of supervised learning in which the so-called training set will be used. We will see more about this in another text.

 

Referências

 

  1. FELLBAUM, C. WordNet: An Electronic Lexical Database. Cambridge, MA: MIT Press, 1998.
  2. FERRUCCI, D. A. Introduction to “This is Watson”. IBM Journal of Research and Development, IBM, v. 56, n. 3.4, p. 1–1, 2012.
  3. GLIOZZO, A. et al. Semantic Technologies in IBM Watson𝑇𝑀. ACL 2013, Citeseer, p. 85, 2013.
  4. INGERSOLL, G. S.; MORTON, T. S.; FARRIS, A. L. Taming text: how to find, organize, and manipulate it. [S.l.]: Manning Publications Co., 2013.
  5. ISOTAMI, S.; BITTENCOURT, I. I. Dados abertos conectados. São Paulo, SP, Brasil: Novatec Editora, 2015.
  6. MILLER, G. A. WordNet: A Lexical Database for English. Communications of the ACM, ACM, v. 38, n. 11, p. 39–41, 1995.
  7. MOREIRA, A.; FILHO, J. L.; OLIVEIRA, A. de P. Automatic creation of
    ontology using a lexical database: An application for the energy sector. In:
    Natural Language Processing and Information Systems: 21st International
    Conference on Applications of Natural Language to Information Systems,
    NLDB 2016, Salford, UK, June 22-24, 2016, Proceedings. Cham: Springer
    International Publishing, 2016. p. 415–420. ISBN 978-3-319-41754-7.
  8. SHALEV-SHWARTZ, S.; BEN-DAVID, S. Understanding machine learning: From
    theory to algorithms. [S.l.]: Cambridge University Press, 2014.

Datas e outros assuntos

 

Introdução

 

Este texto tem caráter dinâmico, isto é, ele será modificado na medida do possível. Contem uma série de mapas conceituais relacionando eventos e suas respectivas datas, por século. Eventualmente, algumas descrições interessantes poderão ser adicionadas, bem como referências bibliográficas.

 

Século XXI

 

seculoxxi

 

Século XX

 

seculoXX

Alguns dados do Século XX foram obtidos em: Brief History of Machine Learning

 

Século XIX

 

seculoXIX

 

Século XVIII

 

seculoXVIII

 

Século XVII

 

 

Século XV

 

 

Referências

 

  1. Braga, J. P. e Nascimento, C. K., A visita de Marie Curie ao Brasil. Amazon, 2017

O Mathematica é bom de texto

 

Introdução

 

Visualização está em moda. Não é para menos! Há inúmeras ferramentas disponíveis para exibir incríveis representações e uma exemplar revisão sistemática (LENGLER; EPPLER, 2007) exibe A Periodic Table of Visualization Methods. O Mathematica1 (Wolfram Mathematica), com facilidades ampliadas, não fica para trás. Como o interesse deste documento é falar sobre textos, no Mathematica, a Figura 1 mostra algumas alternativas de produzir nuvens de palavras. Para todos os gostos e finalidades.

wordcloudsFigura 1. Variações de nuvens de texto, no Mathematica, sobre a RFC7892 após manipulações no texto original. A função que produz cada uma das variações estão acima da respectiva imagem.

Mas, o que interessa, na realidade é indicar como o Mathematica é incrivelmente apropriado para manipular textos. Alguns exercícios foram feitos durante os estudos preliminares para a construção do WordIETF. Eles serão apresentados, sem a intenção de ensinar o uso do Mathematica.

 

Exercícios sobre o Mathematica

 

Tais exercícios foram executados sobre uma única RFC, a RFC7892. Foi uma escolha arbitrária, a partir das mais recentes. E, mais ainda, não há nenhum propósito adicional, além de mostrar que o Mathematica é bom de texto. Interpretações complementares são deixadas para o leitor.

 

Construindo um dicionário

 

Um dicionário pode ser construido através do Association. Um .Association é contruído pelo Dataset. A figura abaixo ilustra as diversas alternativas de Association, que na realidade é uma List.

 construindoassociation

Sendo uma List, uma série de funções estão disponíveis para produzir procedimentos sofisticados para manipular um dicionário. Este esforço pode ser evitado ao aproveitar uma proposta completa feita em Mangano (2010). Existe, entretanto, alguns problemas na proposta do livro, que foram corrigidas aqui, com a versão apresentada na figura abaixo.

 

dicionariomangano

Uma olhada na figura abaixo permite entender o uso das principais funções desta proposta de dicionário, desde sua criação até sua destruição.

usandodicionario

 

Lendo arquivos textos

 

Entrada e saída é uma das primeiras coisas a se aprender em uma linguagem de programação. Na sua diversidade, o Mathematica é uma linguagem de programação. E ele tem muitos recursos relacionados com entrada e saída. Por exemplo, Import é uma função poderosa. Para este exercício a escolha foi pela ReadList que permite a leitura da RFC7892 em uma lista de “strings”, separadas por caracteres definidos através de WordSeparators. A aplicação está na figura abaixo, com um trecho do resultado.

readlist

 

Populando o WordIETF

 

A aplicação escolhida é simples por razões óbvias. Trata-se de popular o dicionário WordIETF com os acrônimos que aparecem na RFC7892. Pela figura acima vê-se que os acrônimos estão entre parênteses (por exemplo, IETF) e o significado deles, em tese, está nas tantas palavras que o antecedem (no exemplo do IETF, nas cinco palavras anteriores). Em linhas gerais, o nosso algoritmo deve seguir os seguintes passos:

  • Ler a RFC7892 em busca de acrônimos.
  • Determina o tamanho n do acrônimo encontrado
  • Se o acrônimo não estiver no WordIETF, captura as n palavras anteriores e inclui o acrônimo.
  • Remova o acrônimo e seu significado do conteúdo da RFC lida.
  • Repita até que não haja mais acrônimos

 

Na figura abaixo, a preparação para o algoritmo. Em particular, a preparação do WordIETF.

etapaspreliminaresalgoritmo

Duas funções foram criadas com o objetivo de facilitar o algoritmo: verifica se é um acrônimo e retorna na lista para capturar o significado do acrônimo. Elas estão na figura que segue.

funcoes

O algoritmo, que apesar de incorporar experiências pessoais, dispensa maiores comentários e está na figura a seguir.

algoritmo

O resultado da execução do algoritmo está na figura a seguir, em 7 repetições sobre o texto da RFC, com tempo insignificante. Na sequência, o estado do dicionário após a execução.

resultadoalgoritmo

 

wordietffinal

 

Comentários finais

 

Foram muitas as experiências com o Mathematica para manipulação de textos, até porque foi uma exigência parcial de minha última disciplina do doutorado “Tópicos Avançados de Sistemas Computacionais Adaptativos”, com o Prof. Dr. Pedro Paulo Balbi de Oliveira, a quem agradeço as orientações durante a oportunidade. Abaixo, algumas considerações adicionais da experiência e das infinitas possibilidades do Mathematica.

  • Na figura abaixo, um exercício para responder a questão “Como poderia ser organizado o WordIETF?

    wordietforganizacao

  • O Mathematica é uma linguagem de programação funcional2. A maior parte dos exemplos acima foram procedurais. O Mathematica é, também, uma linguagem de programação procedural! Mas, ela é mais eficiente em sua característica funcional. A partir da leitura da RFC, usando a função Map, para tentar retirar os acrônimos, obtemos o seguinte resultado.

    mapinicial

     

    Retirando as cadeias vazias:

    retirandostringsvazios

     

    Combinando as duas funções têm-se o problema resolvido funcionalmente:

    resultadofucional

  • Muitos recursos para acesso a dicionários e sítios importantes externos estão disponíveis, como por exemplo, a Wikipedia. Duas imagens abaixo ilustram algumas alternativas.

    consultaexterna1

    consultaexterna2

 

 

Referências

 

LENGLER, R.; EPPLER, M. J. Towards a periodic table of visualization methods for management. In: IASTED Proceedings of the Conference on Graphics and Visualization in Engineering (GVE 2007), Clearwater, Florida, USA. [S.l.: s.n.], 2007.

MANGANO, S. Mathematica Cookbook. [S.l.]: “O’Reilly Media, Inc.”, 2010.

 


     

  1. http://www.wolfram.com/mathematica/
  2. https://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming

 

s

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/

Categorias:Apache, IETF, Modelos, TCP/IP, WordIETF

Anaconda

 

Introdução

 

Anaconda é um ambiente fantástico para desenvolvimento. Aqui escrevo algumas dicas do uso individual em meu dia a dia.

 

Dicas diretas

 

  1. Escolha a instalação preferida (Python 3 ou Python2), em https://www.continuum.io/downloads. Eu escolhi a Python 3.
  2. Minha instalação foi em Windows 10, no diretório padrão C:\Users\jb\Anaconda3
  3. Como precisava da Python 2, instalei-a usando o comando conda create -n py27 python=2.7 anaconda. Com este comando, criei o ambiente py27. Portanto, fiquei com dois ambientes: o raiz (com a Python 3) e o ambiente py27 (com a Python 2). Ando nos dois ambientes usando os comandos activate e deactivate. A figura do prompt do DOS abaixo, exibe estes movimentos.

    ambientesanaconda

  4. Como preciso de trabalhar com os dois notebooks ao mesmo tempo, abro duas instâncias do meu navegador principal e dois prompts do DOS. Clico em uma das instâncias do navegador, vou no diretório de instalação e digito notebook jupyter. Tenho neste caso, o notebook com Python 3. Clico na segunda instância do navegador e no outro prompt do DOS digito activate py27 e em seguida notebook jupyter. Tenho então, os dois notebooks desejados. A figura abaixo exibe os dois ambientes.

    doisambientesanaconda

  5. Observem na figura acima, que a R foi instalada no ambiente py27. Foi uma escolha arbitrária da minha parte. Poderia ter sido no ambiente raiz. Típico caso em que o freguês é quem manda!
  6. Numerando as colunas do programa: Na célula, use a tecla L para alternar a numeração das linhas do programa.
  7. CTRL+Enter executa a célula; SHIFT+Enter executa a célula e abre uma nova célula, na sequência.

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/
%d blogueiros gostam disto: