Arquivo

Archive for the ‘W3C’ Category

Análise de participação nos encontros do IETF

 

Introdução

 

Há imenso interesse em saber como tem sido a participação da América Latina nas reuniões do Internet Engineering Task Force (IETF), que acontecem três vezes ao ano. Desde o encontro do IETF 72 (27 de julho a 1 de agosto de 2008) realizado em Dublin tem estado disponível os participantes de cada encontro. A URL de acesso a estas informações é padrão e coincide com a do IETF 100, a ser realizado em Singapura em 11-17 de dezembro de 2017, onde somente o número pode ser trocado para atingir o encontro desejado, como ilustra a Figura 1.

 

urlComum Figura 1. URL padrão dos encontros do IETF

A aparência da página mudou ao longo do tempo, mas não de forma radical, como se pode ver na Figura 2 observando o cabeçalho da tabela contida nos encontros 72 e 100, respectivamente.

 

paginaAttendees72-100
Figura 2. Visões dos encontros podem ser diferentes, como se pode ver nas páginas dos encontros IETF 72 e IETF 100, respectivamente.

 

Na página do encontro IETF 100, também aparece a referência “0 on Site“, o que não acontece na do IETF 72. Estas diferenças podem ocorrer em outros momentos sugerindo um cuidado especial no desenvolvimento de um processo automático para obter todos os dados, inclusive dos próximos encontros.

 

Adicionalmente, os recursos aqui tratados serão utilizados na construção do wordIETF, um repositório léxico, semântico e de bases de dados de aprendizagem para o projeto SKAU, ambos já comentados aqui no blogue e que serão revistos oportunamente.

 

Como automatizar o processo de captura dos dados

 

Existem várias formas de fazer isto. Várias técnicas e inúmeras linguagens. neste texto será usada a linguagem Python 3 e a facilidade do módulo Beautiful Soup1,2. Trata-se de uma escolha pessoal, que recaem, entretanto, sobre ferramentas universais. Colaboradores com habilidades mais apropriadas podem aperfeiçoar o que está sendo apresentado pois o material (dados e programas) estão disponíveis no GitHub,   https://github.com/juliaobraga/ietf, com este propósito.

 

Python e Beautiful Soup são ferramentas muito utilizadas e estão disponíveis na Internet com detalhes surpreendentes e não iremos nos preocupar em ensinar nenhuma das duas ferramentas. Apenas faremos comentários úteis sobre algumas facilidades disponíveis na Beautiful Soup.

 

Primeiros passos

 

Inicialmente será analisado o código HTML destas páginas, partindo da premissa que não há diferença entre elas, por enquanto. O código IETF01 da Figura 3 mostra a leitura e gravação do conteúdo da página do IETF 100, usando o “requests” como visto na linha 1.

ietf01-codigo
Figura 3. Código 01: usando o requests para ler o conteúdo HTML da página de inscritos no IETF 100 e gravando em aquivo, o resultado. Embora o módulo BeautifulSoup tenha sido chamado (linha 2), não foi usado neste código.

 

As Figuras 4 e 5 exibem trechos do arquivo gerado pelo código da Figura 3. O arquivo foi modificado manualmente para apresentar de forma clara a hierarquia dos marcadores da linguagem HTML, hierarquia esta, que interessa ao BeautifulSoup.

 

Ietf100-conteudo-01
Figura 4. Trecho inicial do conteúdo capturado. Este cabeçalho não tem nenhum valor para o objetivo desejado.

 

A Figura 4 exibe o cabeçalho do arquivo e o marcador a partir do qual estão as informações que interessam ao objetivo a ser conseguido, usando o BeautifulSoup.

 

Ietf100-conteudo-02
Figura 5. Em (a) mostra o inicio do trecho que interessa começando no segundo, exceto o cabeçalho. Em (b), o final do arquivo exibindo onde terminam os respectivos marcadores.

 

A solução de gravar o documento HTML lido pelo requests, para uma análise da hierarquia, não é a única. Alguns navegadores possuem recursos para tal análise. Por exemplo, o Firefox possui o HttpFox3, muito interessante, como pode-se ver na Figura 6.

 

http-fox
Figura 6. O HttpFox do Firefox, em ação.

 

O recurso Inspecionar do Chrome (do Opera, também) tem um visual e facilidades adicionais bastante atrativos, como mostra a Figura 7.

 

inspecionarChrome
Figura 7. O recurso Inspecionar do Chrome possui vantagens adicionais e visual apropriado para a análise humana, da hierarquia.

 

Como se sabe que há diferenças nas páginas dos diferentes encontros (pelo menos encontramos diferenças entre o IETF 72 e o IETF 100, usaremos o Inspecionar do Chrome para resolver estas dúvidas.

 

Capturando as informações

 

Voltemos à Figura 5.  A segunda <table> tem o cabeçalho formado pela primeira <tr> seguida por marcadores <th> e na sequência, até o final, os  marcadores <tr> contem seis marcadores <td> seguidas por um marcador <th>.

 

A Figura 8 exibe o código Python do resultado final para captura dos dados dos inscritos no IETF 100. A reunião está indicada na linha 57. O trecho acrescentado para a captura corresponde à função analisa_html, compreendendo as linhas 26 a 52.

 


Figura 8. Código 02: aplicando o Beautiful Soup sobre o arquivo HTML obtido pelo código da Figura 3, considerando que se deseja o conteúdo do segundo marcador <table>.

 

Na linha 29 está a chamada do Beautiful Soup para a captura de todo o conteúdo da página de inscritos no encontro do IETF 100. Na linha 31,  o método find_all é executado para encontrar dentro do segundo marcador <table> (observar o índice), todas as ocorrências do marcador <tr> (um outro find_all). Este método find_all retorna uma lista (razão do índice [1] no <table>, já que o primeiro marcador <table> ([0]), não interessa. O for garante que a cada interação, a variável row tenha os marcadores <td> e <th> do marcador <tr>. Para cada row aplica-se, na linha 32, o find_all construindo uma lista (pTD) de seis (6) marcadores <td>. Por garantia, um if verifica se o tamanho da lista pTD é 6, para seguir à frente. A primeira coisa a fazer é obter, ainda de row, o marcador <th>. executando o método find, pois sabe-se que há somente um marcador <th> em row, que na linha 34 coloca na variável profile, o texto do marcador <th>. Se profile é a palavra Click, tem-se uma URL, em um marcador a. Isto está sendo feito nas linhas 36-39. O trecho de código das linhas 41-48, monta um dicionário e concatena cada row obtido na interação do for da linha 31.

 

Para terminar, o Pandas é usado (chamada na linha 3, para construir a tabela com base no dicionário construído pela função analisa_html e grava uma planilha Excel.

 

Considerações e recomendações

 

  • Na comparação feita entre o IETF 72 e o IETF 100 há diferenças no número de colunas, ou no número de marcadores <td> e/ou <th> dentro dos marcadores <tr> (na lista row).
  • Feita a alteração proposta no item anterior, na rotina principal basta um loop de 72 a 100.
  • Os encontros passados são invariáveis. Isto é, não há inconveniência que os dados estejam localmente. Só o encontro atual é variável e a recomendação é tratá-lo de forma diferenciada.
  • Com todos os encontros acessíveis (remotamente ou localmente) é possível responder questões tais como: fulano de tal participou de quantos eventos do IETF? Quais? Remotamente ou “on site“?
  • Expandir as estatísticas para todos os países é uma opção útil.
  • Disposição dos dados de forma a facilitar seu uso em tarefas que envolvam aprendizagem de máquina, por exemplo

 

Referências

 

    1. Leonardo Richardson. Beautiful Soup Documentation. Disponível em  https://www.crummy.com/software/BeautifulSoup/bs3/documentation.html. Acessado em 05/11/2007.
    2. Beautiful Soup Documentation. https://www.crummy.com/software/BeautifulSoup/bs4/doc/
    3. https://addons.mozilla.org/pt-BR/firefox/addon/httpfox/
Anúncios

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

XML na Infraestrutura da Internet

Jewish law prohibited farmers from harvesting every last item from their fields.
If something was missed in the first pass, they were to leave it for the poor to harvest.
This was called gleaning. Gleaning provides a metaphor for good writing and teaching.
Don’t explain everything in complete detail. Leave something for the reader or student to harvest on their own.
From John Cook => https://plus.google.com/u/0/+JohnCook/posts/4UpWuws59oU

 

Introdução

 

Tenho insistido na ideia da aplicação de Web Semântica na Infraestrutura da Internet. Durante o, ainda em desenvolvimento desta ideia, uma questão parece evidente: o domínio da Infraestrutura da Internet é enorme e inexplorado sob a ótica da Web Semântica! Basta uma olhada na Figura 1, uma representação simplificada e parcial deste domínio, na qual, os principais agentes aparecem com algumas relações básicas. Tais agentes são os produtores das informações, isto é, dados que são produzidos e guardados em repositórios, geralmente, no formato texto com uma estrutura mínima. Há um texto em inglês, Preliminaries essays to research in Semantic Web applied to Internet Infrastructure, disponível em PDF, no qual, entre outras coisas, esclarece como os administradores de Sistemas Autônomos consomem estes dados, através de ferramentas orientadas a este fim. No “Preliminaries essays…”, a localização de alguns dos repositórios está representado em um cenário mais abrangente.

 

VisaoEntrelaçadaIPv6

Figura 1. Representação simplificada e parcial do domínio da Infraestrutura da Internet.

 

Ao procurar fixar o cenário, a maneira de pensar varia do geral para o particular e muitas vezes, também, do particular para o geral. Uma troca, sem limites usando refinamentos sucessivos, tanto no pensamento “top->down” como no “bottom->up”. Neste vai e vem da forma de pensar, o Mapa de Conceito4, exerce um papel fundamental, já que sua característica principal é a facilidade de representar o domínio do problema (ou do conhecimento), visualmente, simplificado e, direto. Existem vários mapas de conceito disponíveis, nos quais incluem os mapas mentais, que também fazem um bom trabalho. Neste texto, usamos o CMaps8 descrito sob o ponto de vista de suas aplicações. A Figura 1 e muitas outras que seguem foram, também produzidas, no CMaps.

Além das preocupações com o tamanho do domínio, a ausência de um vocabulário direto e aplicável ao domínio há outras. Entre estas outras, a linguagem para representar e permitir fácil acesso aos repositórios é um dos aspectos mais importantes. A base para tratar as aplicações de Web Semântica está na eXtensible Markup Language (XML), definida em [6] e é sobre ela que trataremos neste primeiro artigo.

 

A XML e a aplicação na delegação de IPv6

 

Sistemas Autônomos6 na Internet são identificados por um número denominado ASN (Autonomous System Number). Este número é controlado e distribuído pelo IANA (Internet Assigned Numbers Authority). A IANA (http://www.iana.org/about) é um departamento do ICANN (Internet Corporation for Assigned Names and Numbers). A IANA, também controla a distribuição de números IPv4 e IPv6, entre outras funções. O mecanismo de distribuição do IANA é do tipo atacado, isto é, ela distribui os números de AS, IPv4 e IPv6 para os RIR (Regional Internet Register), que por sua vez distribuem para os NIR (National Internet Register) ou diretamente para os interessados, quando não existir um NIR. Os RIRs são em número de cinco, cada um responsável por uma região do mundo (http://www.iana.org/numbers). Os RIRs são: AfriNIC, APNIC, ARIN, LACNIC e RIPE NCC. A IANA está, também, intimamente conectado com o IETF9. ICANN, IANA, IETF, números IPv4, números IPv6, números de ASes, RIRs, NIRs, Empresas, Instituições, Países, Pessoas e muitas outras coisas são parte dos “conceitos” associados ao domínio Infraestrutura da Internet, ou em outras palavras, ao vocabulário do domínio.

Para a aplicação da XML trabalharemos sobre um sub-domínio da representação exibida na Figura 1 (em laranja). Com o CMaps obtemos facilmente a derivação que pode ser vista na Figura 2.

 

DetalheIPv6

Figura 2. Detalhe da destinação de um bloco IPv6.

 

A representação fala por si mesmo. Em resumo, uma Empresa (digamos, um provedor) recebe um bloco de IPv6 sobre o qual estamos interessados. De posse deste bloco, um /32, o provedor planeja e designa sub-blocos a seus clientes e/ou usuários. Partindo da premissa de que a empresa tem muitos clientes, há necessidade de se criar um repositório do recurso (bloco IPv6) recebido, juntamente com as informações a ele associadas. Sobre este repositório uma série de operações conhecidas devem estar disponíveis. Uma abstração deste repositório e suas relações podem ser vistos na Figura 3.

 

RepositorioAbstrato

Figura 3. Representação abstrata de um repositório de registro de designação IPv6 e suas respectivas operações.

 

A abstração indica que o tal repositório pode ser, desde folhas de papel até um local (digital), onde se pode usar processos mais so fisticados, que tenham, por exemplo, um gerenciador de banco de dados relacional (digamos, MySQL). Vamos eliminar as soluções trabalhosas, como as folhas de papel, para procurar alternativas mais apropriadas sob o ponto de vista do acesso ao repositório e proporcionais a expectativa de tamanho deste repositório.

Faremos uma incursão sobre as soluções tradicionais, para depois seguirmos as técnicas que envolvem Web Semântica, nosso objetivo neste texto. Passemos, então, à descrição do contexto do problema desejado, com alguns detalhes importantes descobertos no planejamento.

 

Planejamento da distribuição de um bloco /32

 

Então, o provedor recebeu, do Registro.br, um bloco IPv6, que iremos supor como sendo o bloco dddd:dd00::/32. Depois de ler o artigo “Preparing an IPv6 Address”5 e o RFC 59321, cuidadosamente planejou a sua distribuição. Ele trabalhou tendo em mãos o Guia didático de Endereçamento IPv6. Assim, os números envolvidos tornaram fáceis de encontrar.

Ele dividiu este /32 em 65.536 blocos /48. Em seguida, achou adequado separar os primeiros 32.768 blocos para uso futuro e passou a pensar na segunda metade. Insistente reservou a primeira metade deste conjunto de blocos /48 (16.384), também, para uso futuro e passou a pensar sobre a divisão dos outros 16.384, da segunda metade, para que fosse distribuida a seus Clientes. O provedor calculou que na sequência deste conjunto de /48s, ele teria 1.024 x 16 blocos /48. Chamou cada um destes /48 de Disponibilidades e montou o seguinte esquema de distribuição:

  • Disponibilidade 0: dddd:dd00:c000::/48 a dddd:dd00:c00f::/48
    • dddd:dd00:c000::/48 ) Uso interno
    • dddd:dd00:c001::/48 ) Liberado
    • dddd:dd00:c00f::/48 ) Liberado
  • Disponibilidade 1: dddd:dd00:c010::/48 a dddd:dd00:c01f::/48
    • dddd:dd00:c010::/48 ) Cliente/Localidade 1
    • dddd:dd00:c011::/48 ) Liberado
    • dddd:dd00:c01f::/48 ) Liberado
  • Disponibilidade 2: dddd:dd00:c020::/48 a dddd:dd00:c02f::/48
    • dddd:dd00:c020::/48 ) Cliente/Localidade 2
    • dddd:dd00:c021::/48 ) Liberado
    • dddd:dd00:c02f::/48 ) Liberado
  • Disponibilidade 3: dddd:dd00:c030::/48 a dddd:dd00:c03f::/48
    • dddd:dd00:c030::/48 ) Cliente/Localidade 3
    • dddd:dd00:c031::/48 ) Liberado
    • dddd:dd00:c03f::/48 ) Liberado
  • 

  • Disponibilidades 4 ate 511
  • Disponibilidade 512: dddd:dd00:c2f0::/48 a dddd:dd00:c2 ::/48
    • dddd:dd00:c2f0::/48 ) Cliente/Localidade 512
    • dddd:dd00:c2f1::/48 ) Liberado
    • dddd:dd00:c2 ::/48 ) Liberado
  • 

  • Disponibilidades 513 ate 1022
  • Disponibilidade 1023: dddd:dd00: f0::/48 a dddd:dd00: ::/48
    • dddd:dd00: f0::/48 ) Cliente/Localidade 1023
    • dddd:dd00: f1::/48 ) Liberado
    • dddd:dd00: ::/48 ) Liberado

Quando esta divisão foi feita, o provedor tinha em mente o RFC 61773, não deixando de pensar que um de seus clientes poderia dividir o bloco /48 em /56 ou /60. Indo um pouco mais além fez recomendações para que seus clientes distribuíssem a seus usuarios, blocos /64. Como em cada /48 estão disponveis 65.536 redes /64, ele fez as seguintes recomendacões a seus Clientes:

    

  • Usar o primeiro bloco /64 para Loopback.
  • 

  • Deixar pelo menos 15 redes contíguas ao /64 designado (da mesma forma que o /48, acima).
  • 

  • Avaliar o uso de su fíxos relativamente fáceis de lembrar, para a rede interna (por exemplo: CA5A, FACA, …).

Tudo isto está mostrado gráfi camente na Figura 4, onde P é o prefixo dddd:dd00 e, h, i, j são dígitos hexadecimais dentro dos limites escolhidos. Por outro lado, a base de um planejamento em Infraestrutura da Internet é a topologia. Neste caso usamos a topologia da Figura 2.8 do texto Topologias, Interconexões e Protocolos.

E assim, a divisão do IPv6 deixou de ser um problema. Agora, a questão é identifi car uma maneira de como controlar as informações relacionadas com a designação dos IPv6 aos Clientes. Sem dúvida, qualquer solução envolve um local de armazenamento das informações, isto é, um repositório para os dados. A visão mais abstrata capaz de ilustrar tal ambiente, onde pessoas (usuários) possuem acesso, é a mostrada na Figura 3.

 

DivisaoIPv6

Figura 4. Representando o plano de divisão do bloco /32, graficamente.

 

Construindo o repositório com a XML

 

XML é uma linguagem livre. São poucas as restrições (sintáticas!) sobre ela. Desta forma, o estilo, a experiência e a criatividade individuais determinam a estrutura do repositório. Para este texto, o repositório em XML foi proposto como abaixo, de forma parcial e resumida:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<empresaX>
  <designacao_ipv6>
    <ip prefixo="dddd:dd00::" masc="/32">
      <ip prefixo="dddd:dd00::" masc="/48">
        <designado_para>Livre</designado_para>
      </ip>
      <!-- ... -->
      <ip prefixo="dddd:dd00:8::" masc="/48">
        <ip prefixo="dddd:dd00:8000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <!-- 
            Grupo dos /48 designados 
        -->
        <ip prefixo="dddd:dd00:c001::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c002::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c003::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c010::" masc="/48">      
          <designado_para>Localidade 1</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c010:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 1</comentarios>          
          </ip>
          <ip prefixo="dddd:dd00:c010:0001::" masc="/64">
            <designado_para>Cliente 1</designado_para>
            <fone>37-xxxx-xxxx</fone>
            <responsavel_t>Fulano de Tal</responsavel_t>
            <email>nome AT SPAMFREE exemplo DOT com DOT br</email>
            <comentarios>Cliente do Provedor</comentarios>          
          </ip>
          <!-- ... -->
          <ip prefixo="dddd:dd00:c010:CA5A:" masc="/64">
            <designado_para>Rede Local</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Utilizado na rede local</comentarios>   
          </ip>
          <!-- ... -->
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c020::" masc="/48">      
          <designado_para>Localidade 2</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c020:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 2</comentarios> 
          </ip>
          <!-- ... -->
        </ip>
      </ip>
    </ip>
  </designacao_ipv6>
</empresaX>

Pode-se concluir que o repositório tende-se a tornar muito grande. Entretanto, a partir da escolha inicial da estrutura (ou conjunto de marcadores), da XML, o processo é repetitivo, o que facilita o trabalho. As linguagens de programação (qualquer uma e em especial JavaScript) estão preparadas para trabalhar de maneira trivial sobre repositórios XML, o que facilitaria em muito as operações desejadas (Figura 3). Da mesma forma, os navegadores, imediatamente, representam de forma estruturada um arquivo XML, como pode ser visto na Figura 5.

 

XMLnoChrome

Figura 5. Repositório XML exibido no Chrome.

 

Não se pode esquecer que a W3C possui um recurso para validar um texto XML, bastante útil, que pode ser usado em Markup Validation Service.

Por outro lado, um banco de dados (repositório) XML possui uma organização hierárquica, como mostra a Figura 6.

 

XML-hierarquia

Figura 6. Organização hierárquica de um repositório XML.

 

A eficiência sobre um repositório com tais características depende não somente da hierarquia (ou arranjo dos marcadores) mas, também, do sistema de gerenciamento (programa) do repositório. Durante a etapa de programação, eventualmente, a hierarquia poderá ser aperfeiçoada.

 

Aperfeiçoando as ideias e, o projeto

 

Suponhamos que a ideia de um repositório XML para controlar as designações de IPv6 de um provedor tenha sido um sucesso. A notícia se espalha e um habilidoso programador, digamos, o Pedro Paulo (nosso programador fictício preferido…) resolve desenvolver um repositório para:

  • Atender a vários provedores e,
  • Controlar IPv6 e IPv4

Em uma primeira tentativa, a organização do repositório poderia ter a seguinte organização

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP>
    <empresaX>
        <blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <cliente id="201311281745">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaX>
    
    <empresaY>
        <blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <cliente id="201311281754">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaY>
</repositorioIP>

 

Este segundo modelo altera a hierarquia do primeiro. O componente mais importante do repositório é o marcador <cliente>, mas exige-se que os blocos delegados de IPv6 e IPv4 estejam presentes, mas dando liberdade em relação à presença dos marcadores debaixo do marcador mais importante. Uma visão mas agradável é a do navegador, mostrada na Figura 7, logo abaixo.

 

XML-RepositorioPedroPaulo

Figura 7. O novo repositório exibido no Chrome.

 

Ou, mais agradável ainda, a visão gráfica da hierarquia mostrada na Figura 8.

 

XML-hierarquia-PedroPaulo

Figura 8. Visão gráfica da hierarquia do segundo modelo (Pedro Paulo).

 

Embora imediado é oportuno observar, que a Figura 8 representa uma árvore (estrutura de dados). Navegar nesta árvore é um processo eficiente. Por exemplo, se procuramos pelas informações da Empresa 1, basta seguir os ramos abaixo dela, ignorando o restante dos nós à sua direita. Ou seja, qualquer operação a ser feita sobre o repositório (indicadas pela Figura 3) é estritamente localizada, portanto, muitíssimo eficiente.

Há, contudo, uma questão importunando ao Pedro Paulo. Os nomes dos marcadores de cada empresa / provedor são os mesmos e isto pode causar problemas de consistência ou de conflitos. Se o repositório fosse controlado à mão (por um ser humano), certamente poderíamos trocar um marcador, sem perceber, já que eles são idênticos. Mesmo desenvolvendo procedimentos para manipular automaticamente o repositório, a inconsistência prevalecerá. A linguagem XML possui na sua especificação, um mecanismo importante para garantir a consistência dos marcadores. É a técnica denominada espaço de nomes (do inglês, namespaces). Falaremos sobre ela em seguida, mas uma ótima introdução ao conceito pode ser visto em XML Namespaces.

 

Espaço de nomes em XML

 

O objetivo do espaço de nomes em XML é eliminar conflitos entre marcadores ou, em outras palavras, estabelecer a unicidade dos marcadores. Isto é feito através do atributo xmlns que distinguirá os prefixos a serem usados nos marcadores. O formato deste atributo é, xmlns:prefixo=”URI” colocado(s) no marcador inicial (raiz). URI (Uniform Resource Identifier) é uma cadeia de caracteres que identifica um Recurso da Internet. A URL (Uniform Resource Locator), usualmente usado por nós é um caso particular da URI. Na XML, a URI é simplesmente a caracterização da unicidade e não transporta nenhuma informação adicional.

Nos artigos seguintes veremos um papel mais preponderante do espaço de nomes. Por hora, o segundo modelo do repositório proposto e, a Figura 9, ilustram como ele se transforma, ao usar espaço de nomes, que comparando com a Figura 7 torna-se o entendimento imediatamente intuitivo.

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP 
    xmlns:x="http://ws.org.br/empresa/X"
    xmlns:y="http://ws.org.br/empresa/Y">
    
    <x:empresa>
        <x:blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <x:blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <x:cliente id="201311281745">
            <x:nome></x:nome>
            <x:responsaveltecnico></x:responsaveltecnico>
            <x:fonenoc></x:fonenoc>
            <x:endereco>
                <x:logradouro></x:logradouro>
                <x:numero></x:numero>
                <x:complemento></x:complemento>
                <x:bairro></x:bairro>
                <x:cep></x:cep>
                <x:cidade></x:cidade>
                <x:estado></x:estado>
            </x:endereco>
            <x:ipv6designado></x:ipv6designado>
            <x:ipv4designado></x:ipv4designado>
            <x:observacoes></x:observacoes>
        </x:cliente>  
    
    </x:empresa>
    
    <y:empresa>
        <y:blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <y:blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <y:cliente id="201311281754">
            <y:nome></y:nome>
            <y:responsaveltecnico></y:responsaveltecnico>
            <y:fonenoc></y:fonenoc>
            <y:endereco>
                <y:logradouro></y:logradouro>
                <y:numero></y:numero>
                <y:complemento></y:complemento>
                <y:bairro></y:bairro>
                <y:cep></y:cep>
                <y:cidade></y:cidade>
                <y:estado></y:estado>
            </y:endereco>
            <y:ipv6designado></y:ipv6designado>
            <y:ipv4designado></y:ipv4designado>
            <y:observacoes></y:observacoes>
        </y:cliente>  
    
    </y:empresa>
</repositorioIP>

 

Olhando um pouco mais atentamente a XML acima, surge uma questão sobre a qual vale a pena pensar: será que o atributo id, incluído nos marcadores <cliente> faz sentido diante da presença do espaço de nomes?

 

XML-NS-RepositorioPedroPaulo

Figura 9. O segundo modelo, com a unicidade dos marcadores garantida pelo espaço de nomes, visto pelo Chrome.

 

Considerações finais

 

Nada foi dito no artigo sobre as técnicas de programação para manipular repositórios em XML. Foge do escopo do texto, que se preocupou em mostrar algumas facilidades para planejar o uso dos recursos de numeração (IPv6 / IPv4) e a alternativa de estrutura-los em um repositório usando XML. A XML é uma linguagem orientada, principalmente, ao entendimento computador-computador (ou melhor, programa-programa), muito embora ela seja acessível a humanos. Dada à sua forma livre de expressão, presta-se a inúmeras aplicações úteis, como a do exemplo, documentar a distribuição de IPv6.

Sob o ponto de vista da Web Semântica, a XML é muito restrita para a necessária expressividade semântica, apesar de ser a base para as alternativas que serão abordadas nos próximos textos.

 

Referências

  1. S. Kawamura amd M. Kawashima. A Recommendation for IPv6 Address Text Representation. RFC5952. December 2008. Disponível em: http://www.rfc-editor.org/rfc/rfc5952.txt. Acessado em 02/10/2013.
  2. IHMC. Cmap tools. http://ftp.ihmc.us/. Acessado em 02/10/2013.
  3. T. Narten and G. Huston ant L. Roberts. IPv6 Address Assignment to End Sites, March 2011. RFC6117.
  4. Joseph D. Novak and D. Bob Gowin. Learning how to learn. Cambridge University Press, Cambridge, UK, 1 edition, 1984.
  5. SurfNet. Preparing an IPv6 Address Plan. Disponível em: https://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf. Acessado em: 02/10/2013.
  6. BRAY, T. et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C, 26 November 2008. Disponivel em: http://www.w3.org/TR/REC-xml/. Acesso em: 22 maio 2013.
  7. BRAGA, J. Sistemas Autonomos, Empresas Autônomas. Infraestrutura da Internet, 03 mar. 2006. Disponivel em: https://ii.blog.br/2006/03/03/sistemas-autonomos-empresas-autonomas/. Acesso em: 22 maio 2013.
  8. CAÑAS, A. J. et al. A Summary of Literature Pertaining to the Use of Concept Mapping Techniques and Technologies for Education and Performance Support. The Institute for Human and Machine Cognition. Pensacola, FL: The Chief of Naval Education and Training. 2003. p. 108.
  9. BRAGA, J. A ISOC, o IETF e a infraestrutura da Internet. Infraestrutura da Internet, 03 Janeiro 2013. Disponivel em: https://ii.blog.br/2013/01/03/a-isoc-o-ietf-e-a-infraestrutura-da-infraestrutura-da-internet/. Acesso em: 22 maio 2013.

Semantic Web x Internet Infrasctruture

CMapProject1

English:

 

I wrote some preliminary ideas about a project of medium / long-term application of Semantic Web Infrastructure on the Internet named Preliminaries essays to research in Semantic Web applied to Internet Infrastructure.

The text is available in PDF (English): here.

Other useful information about the IETF is here.

I’m looking for researchers interested in this area. E-mail to: juliao SPAM FREE AT braga eti DOT DOT br.

Português:

 

Escrevi algumas ideias preliminares sobre um projeto de médio / longo prazos de Web Semântica aplicada a Infraestrutura da Internet, com o nome Preliminaries essays to research in Semantic Web applied to Internet Infrastructure.

O texto, em pdf está disponível (em inglês) aqui

Outras informações úteis sobre o IETF encontra-se em aqui.

Tenho grande interesse em contatos com pesquisadores interessados nesta área. E-mail para juliao AT SPAM FREE braga DOT eti DOT br.

 

Um Guia para modelar ontologias usando OWL-DL (GOL)

“…A atmosfera moral é magnífica para batráquios.
Não imaginas como andam propícios os tempos a todas as mediocridades. Estamos no período hilariante dos grandes homens-pulhas, dos Pachecos empavesados e dos Acácios triunfantes…”

Euclides da Cunha, em 1909, numa carta ao seu cunhado.

 

Apresentação

 

Web Ontology Language (OWL), (Hitzler, et al., 2009) é uma linguagem para Semantic Web, desenvolvida pelo World Wide Web Consortium (W3C) e está descrita formalmente por (Patel-Schneider, et al., 2004). A OWL é uma extensão da linguagem RDF Schema, (Hayes, 2004), com significativos recursos adicionais de expressividade, no aspecto da representação do conhecimento, objetivo da ontologia e usa a XML. Em relação à expressividade do conhecimento a OWL é classificada em OWL Full, OWL-DL e OWL Lite. A OWL Full é usada quando se deseja o máximo de expressividade e liberdade sintática, em relação à RDF Schema, mas que, na mesma proporção de seu poder, incorpora o fato de ser indecidível. A OWL-DL, menos poderosa do que a OWL Full, consegue compor recursos de expressividade satisfatórios, sem perder a completude e decidibilidade computacionais. Finalmente, a OWL Lite é uma linguagem com poder de expressividade extremamente pobre, muito embora seja de compreensão simples e é fácil de implementar em procedimentos automáticos. Neste contexto, a OWL-DL é a linguagem preferida para modelar ontologias.

Modelar, ou construir modelos que representem um domínio de interesse é um processo complicado e muitas vezes difícil. Isto se torna uma tarefa monumental e a recomendação é que seja um trabalho incremental (baseado em refinamentos sucessivos) e, sobretudo, que se siga um roteiro sistemático, o qual somente uma metodologia efetivamente consistente poderia satisfazer. Existem muitas propostas de metodologias e, a maioria delas é derivada de outras metodologias conhecidas, liderando com vantagens as áreas de desenvolvimento de software e de projetos em geral.

EagleOwl

O presente trabalho propõe um guia para o desenvolvimento de ontologias em OWL-DL, ao qual se dá o nome de GOL. Adicionalmente o trabalho segue o OpenStand descrito em (OpenStand, 2013) e, em seus princípios (OpenStand, 2012). Para estabelecer a proposta do GOL será desenvolvida uma abordagem orientada ao domínio de conhecimento associado à Infraestrutura da Internet.

O GOL responde às questões subjacentes à Figura 1, a qual exibe dois ambientes:

  • Seleção de ferramentas e técnicas para trabalhar na modelagem de ontologias.
  • Seleção e modificação de metodologias para o projeto, implementação e teste de ontologias.

 

guidetoModelOntology

Figura 1. As escolhas de um guia para modelar ontologias (GOL).

 

Os ambientes são derivados de metodologias conhecidas no desenvolvimento de sistemas e programas, como já foi dito acima, coincidindo o primeiro ambiente com o tópico Requirements and Analysis, e, o segundo ambiente associa-se ao tópico Design, Implement and Test, ambos baseados no Unified Process (UP), de (Jacobson, et al., 1999). Esta relação está bem caraterizada em uma das metodologias analisadas para o GOL, chamada Unified Process for ONtology (UPON), descrita por (Nicola, et al., 2009).

Após as avaliações sobre os recursos disponíveis nos dois ambientes, o trabalho propõe o GOL, conforme a Figura 2 com as escolhas possíveis entre as alternativas estudadas.

Por outro lado, o GOL, ao indicar uma metodologia, atenta para o fato de que ela seja versátil, o suficiente, e capaz de permitir mudanças, a critério das habilidades e perfis de grupos e pessoas envolvidas no desenvolvimento de ontologias sem, contudo descaracterizar o resultado final que se espera quando é usada a OWL-DL.

 

guidetoModelOntology-final

Figura 2. A estrutura final (enxuta), do EOWL.

 

Para validar o GOL, um projeto envolvendo um subdomínio do imenso domínio de conhecimento agregado à Infraestrutura da Internet. A escolha recai sobre os recursos de numeração, cuja atribuição / distribuição é feita pelo IANA. Propositalmente, a escolha origina um estudo para aplicação da Web Semântica, na direção de tornar os administradores de recursos da Internet, confortáveis diante de suas responsabilidades.

 

Bibliografia

 

  • Fernández López M. Overview of Methodologies For Building Ontologies [Conference] // Proceedings of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5) / ed. Benjamins V. R. [et al.]. – Stockholm, Sweden : [s.n.], August 2, 1999.
  • Hayes, P., 2004. RDF Semantics. [Online] Available at: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
    [Acesso em 18 maio 2013].
  • Hitzler, P., Krötzsch, M., Parsia, B. & Patel-Schneider, P. F., 2009. OWL 2 Web Ontology Language Primer. [Online] Available at: http://www.w3.org/TR/2009/REC-owl2-primer-20091027/ [Acesso em 19 maio 2013].
  • IANA, 2013. Autonomous System (AS) Numbers. [Online] Available at: http://www.iana.org/assignments/as-numbers/as-numbers.xml [Acesso em 17 maio 2013].
  • Jacobson, I., Booch, G. & Rumbaugh, J., 1999. The Unified Software Develop-. s.l.:Addison Wesley, USA.
  • Nicola, A. D., Missikoff, M. & Navigli, R., 2009. A Software Engineering Approach to Ontology Building. Information Systems, 34(2), Elsevier, pp. 258-275.
  • OpenStand, 2012. Principles. [Online] Available at: http://open-stand.org/principles/ [Acesso em 17 maio 2013].
  • OpenStand, 2013. About. [Online] Available at: http://open-stand.org/about-us/ [Acesso em 2013].
  • Patel-Schneider, P. F., Hayes, P. & Horrocks, I., 2004. OWL Web Ontology Language Semantics and Abstract Syntax. [Online] Available at: http://www.w3.org/TR/2004/REC-owl-semantics-20040210.

A ISOC, o IETF e a infraestrutura da Internet

By connecting the world,
collaborating with others,
and advocating for equal access to the Internet,
the Internet Society strives to make the world a better place.
At the foundation of our work are a vision and a mission.

The Internet is for everyone.

 

Introdução

 

Até agora, neste blogue tenho escrito sobre assuntos pontuais da Infraestrutura da Internet, em particular com o foco em Sistemas Autônomos e no principal protocolo envolvido, o BGP. Com a proximidade do IETF 86, em Orlando (Flórida) rever o processo de funcionamento da Infraestrutura da Internet, em detalhes e no seu aspecto global parece oportuno.

Ideogama yang-ying, do Taoismo

Este trabalho tem como sua principal motivação, o esforço de Paul Hoffman1, com uma versão em espanhol aqui. As regras desta referência estão descritas na RFC67222 seguindo aquelas do IETF, em relação às suas publicações. A primeira publicação de O Tao do IETF foi a RFC46773, em 2006.

Tao (pronuncia-se dao), no Taoismo4 (pronuncia-se daoismo), se refere a algo que é tanto a fonte quanto a força motriz por trás de tudo que existe. Seu ideogama é o yang-ying, representado pela conhecida figura à direita.

O Tao do IETF dá ênfase aos três eventos anuais no aspecto referente à organização, orientando o recém chegado sobre o comportamento esperado na ocasião. Das trinta e oito páginas, oito são dedicadas à organização da Infraestrutura da Internet e o restante, indiretamente exibe a forma como são construídos os padrões utilizados na Internet.

 

A sopa de termos

 

Aqui ou em qualquer lugar na Internet, em livros e documentos aparecerão acrônimos e abreviações que algumas vezes trará uma certa dificuldade de leitura. A tabela abaixo, adaptada de Hoffman1 e do Glossário do IETF, ajudará a torná-los mais conhecidos. Uma tradução livre, do significado em português foi adicionada, para facilitar a compreensão, e poderá sofrer mudanças à medida que as contribuições forem recebidas.

Também, na tabela, as referências para informações adicionais de cada item. Tais referências, básicas, não se esgotam na tabela, pelo contrário. A quantidade de informações é imensa!

Sigla Inglês Português
AD Area Director Diretor de Área. Cada área (dividida em WGs) possui uma AD com um ou mais membros. O AD é responsável pela orientação / gerenciamento dos respectivos WGs. Os membros de cada AD podem ser vistos aqui
BCP Best Current Practice Melhores práticas correntes
BOF Birds of a Feather

Grupo de debate informal. Geralmente precede a formação de um WG. Um BOF pode ser convocado para debates sobre uma questão que, eventualmente, não será transformada em um WG.

FAQ Frequently Asked Question(s) Perguntas mais frequentes
FYI For Your Information Para sua informação
IAB6,9,10 Internet Architecture Board Conselho de arquitetura da Internet. Na criação de WGs, o IAB recomenda ou “aconselha”, a respeito.
IAD IETF Administrative Director Diretor administrativo do IETF
IANA Internet Assigned Numbers Authority Autoridade para atribuição de números da Internet
IAOC IETF Administrative Oversight Committee Comitê administrativo de supervisão do IETF.
IASA12 IETF Administrative Support Activity Atividade administrativa de suporte ao IETF
ICANN Internet Corporation for Assigned Names and Numbers Corporação da Internet para atribuição de nomes e números
I-D Internet Draft

Esboço da Internet. São os documentos de trabalho do IETF, de suas áreas, e de seus grupos. Durante o desenvolvimento de uma especificação, versões preliminares do documento estarão disponíveis no diretório de I-Ds do IETF, para revisão informal e comentários. Isso faz com que um documento de trabalho esteja disponível a um público amplo facilitando o processo de avaliação, revisão e, consequentemente, de evolução. No diretórios estão os I-Ds atuais e passados.

IEPG24 Internet Engineering and Planning Group

Grupo de Engenharia e Planejamento da Internet. É um encontro informal que se reúne no domingo, antes das reuniões da IETF em que são abordados temas de relevância operacional, além de avaliar outros temas, que despertam interesse, no momento.

IESG6,9,10 Internet Engineering Steering Group

Grupo de direção de engenharia da Internet. O IESG é responsável pelo gerenciamento técnico das atividades do IETF e do processo de desenvolvimento de padrões. Como parte da ISOC o IESG administra os processos de acordo com as regras e procedimentos ratificados pelos membros da administração superior da ISOC. O IESG é diretamente responsável pelas ações associadas ao acompanhamento do movimento dos padrões, incluindo a aprovação final das especificações.

IETF Internet Engineering Task Force Força de tarefas de engenharia da Internet
IPR Intellectual Property Rights Direitos de propriedade intelectual
IRSG Internet Research Steering Group Grupo de orientação de pesquisa da Internet
IRTF23 Internet Research Task Force

Força tarefa de pesquisa da Internet. A missão da IRTF é promover investigação de importância para a evolução da Internet do futuro, criando focos, grupos de pesquisa de longo e curto prazos, que trabalham em temas relacionados aos protocolos de Internet, aplicações, arquitetura e tecnologia.

ISOC7 Internet Society

Internet Society. É uma associação sem fins lucrativos, criada em 1992, com atuação internacional, que tem por objetivo promover liderança no desenvolvimento dos padrões Internet, bem como fomentar iniciativas educacionais e políticas públicas ligadas à rede mundial entre computadores. O escritório brasileiro da ISOC possui diversas informações adicionais, entre as quais, os estatutos e formas de associação.

NomCom5,6,8 Nominating Committee

Comitê de nomeação. Seu objetivo é analisar cada posição (cargo) em aberto no IESG, IAB e IAOC e nomear respectivos candidatos. Ele é composto de pelo menos um coordenador (“chair”), nomeado pelo Presidente da ISOC, 10 voluntários votantes, 2 a 3 membros de contatos (“liaisons”), e um assessor. O presidente do NomCom é apontado entre as primeira e segunda reuniões do ano, e um novo NomCom começa oficialmente o seu trabalho. Associar-se à ISOC é o primeiro passo para participar, efetivamente, do IETF, muito embora não seja mandatório.

RFC Request for Comments RFC
STD Standard (RFC) Padrões (RFC)
W3C World Wide Web Consortium Consórcio do WWW.
WG Working Group

Grupo de trabalho. É onde tudo começa no IETF. WGs são o mecanismos primários para o desenvolvimento de especificações do IETF e diretrizes, muitas das quais se destinam a ser os padrões ou recomendações. WGs são tipicamente criados para resolver um problema específico ou para a produção de um ou mais resultados específicos (uma diretriz, especificação de normas, etc.).Um WG possui uma existência temporária e é mantido o histórico dos WGs concluídos aqui. Em 05/01/2013 haviam 126 WGs ativos: veja aqui.

WGLC Working Group Last Call

Grupo de Trabalho Última Chamada. É uma última chamada dentro de um WG (realizada na lista), antes de um documento ser enviado ao IESG para consideração.

 

Interação entre as atividades

 

Este texto tem como objetivo a descrição do processo de formação dos padrões da Internet. Isto significa que o principal foco está no funcionamento do IETF. O IETF está relacionado com um conjunto de outras organizações e/ou atividades, as quais, incluindo o IETF possuem forte ligação funcional com a ISOC. A Figura 1 exibe as relações entre as que mais interessam para este texto, onde a ISOC é a peça fundamental, em todo o conjunto.

 

ISOC-ICANN-W3C

Figura 1. A relação da ISOC e as atividades que influenciam no comportamento da Internet.

 

A relação mostradas na Figura 1 é complexa. Muitas vezes a comunidade age, simplificando, com o objetivo de facilitar o entendimento, como por exemplo, referir-se ao IETF como sendo a representação do próprio IETF, em conjunto com IAB, IESG, IRSG, IRTF e RFC Editor. A principal referência que esclarece, detalhadamente, os mecanismos e caminhos da padronização é a RFC202619. ICANN e W3C são independentes, e possuem protocolos assinados com a ISOC para compor seus interesses, inclusive de autonomia e independência. A W3C é abrigada pelo MIT enquanto que a IANA foi entregue à administração da ICANN pelo governo dos EEUU, que não interfere diretamente. Alexis Simoneli20, descreve cada um dos componentes da Figura 1, com razoável detalhe e complementa este texto, neste quesito.

A ISOC representa uma blindagem completa sobre a capacidade de auto-gestão, do IETF. O modelo foi arquitetado de forma inteligente e serena pelo grupo de pessoas que participaram da criação inicial dos componentes técnicos envolvendo redes de computadores e os protocolos TCP/IP, muito bem abordado no texto escrito por nove deles, “Brief history of the Internet”14, onde mostram a linha de tempo, reproduzida na Figura 2.

 

Figura 2. Linha do tempo da formação da estrutura mostrada na Figura 1. Reproduzida de [14].

 

A Figura 2, mostra a formação do primeiro grupo de trabalho em 1968 (ARPANET WG) e a evolução até a fundação da ISOC, com o estrito objetivo de garantir a independência da Internet, culminando com a criação do W3C.

 

O funcionamento do IETF

 

O IETF foi criado em 1986 e é constituído de pessoas, não por empresas. O trabalho no IETF é dividido em áreas (atualmente 8) e cada área, em grupos de trabalho (WGs) ativos (atualmente, 126). Alguns grupos de trabalho foram concluídos e continuam disponíveis para acesso. Existem listas que não são WGs. Eis alguns pontos que ilustram como o IETF se comporta:

  1. É constituído de participantes e não de membros.
  2. Os padrões que saem do trabalho executado pelo IETF, não são padrões impostos sobre uma área técnica ou sobre instituições públicas ou privadas. São padrões porque as pessoas ou organizações, simplesmente, os usam. Por outro lado, instituições oficiais / formais, criadas para definir padrões no mundo acabam recomendando ou “oficializando” os resultados do IETF.
  3. Existe um coordenador, nomeado pela comunidade, que é também membro do IAB e o AD da área geral (General Area).
  4. Cada área possui dois ADs, exceto a General Area. São responsáveis pela coordenação, e aprovam a criação de BOFs e WGs, além revisar os documentos do WG antes de serem enviados ao IESG.
  5. A administração do IETF é de responsabilidade da IASA que, não possui autoridade sobre os procedimentos que desenvolvem padrões.
  6. O trabalho do IETF é feito nos WGs ou durante os encontros, por iniciativa dos participantes e segue um esquema de baixo para cima, muitas vezes iniciando-se em um BOF (mas, não necessariamente).
  7. O BOF, geralmente precede um WG e é criado a partir do interesse de um grupo de participantes (ou mesmo de um só participante), por um determinado assunto.

  8. Para se criar um BOF é necessário convencer um AD. Feito isto o BOF é agendado e, usualmente ocorre uma única reunião. No final, o BOF pode resultar ou não, na criação de um WG.
  9. O WG é formado por participantes. Nada é votado em um WG. A aprovação é por consenso (ou um código funcionando), e não há necessidade de unanimidade, pois o coordenador é quem decide se há consenso (apesar de ser um fato reconhecido pelos participantes). Se houver disputas, então prevalece o debate entre os participantes, na lista do grupo ou nos encontros do IETF. A última palavra, entretanto é da comunidade (isto é, de todo o IETF e não somente do WG).
  10. A língua oficial do IETF é o inglês. A “linguagem” das listas é o ASCII ou em formatos reconhecidos e aceitáveis.
  11. Proposta técnica de um WG é publicada como um I-D, e enviada ao IESG após a avaliação do AD do WG. Uma vez revisada pelo IESG poderá ser retornada ao WG, para se tornar uma RFC.
  12. Todo documento do IETF é público. I-D é o documento de trabalho do IETF e, também, documento do WG. O I-D permanece arquivado no IETF por 6 meses (pode haver exceções por parte do IESG), de onde é automaticamente excluído do ambiente original. Um I-D, após avaliado, favoravelmente, em várias instâncias da comunidade dá origem a uma RFC.
  13. Existem vários tipos de RFCs e nem toda RFC é um padrão. RFCs são caracterizadas pelo RFC Editor.
  14. O IETF é uma meritocracia. Algumas vozes (técnicas, não políticas) são mais importantes do que outras. Grandes esforços podem ser barrados por razão de uma opinião técnica relevante.

 

ietfxWG

Figura 3. BOFs e WGs. Fonte: Elaborado pelo autor, com base nas informações em [10] e [17].

 

A formação de um WG depende de um bom projeto e de massa crítica (um grupo de pessoas interessadas). Para convencer um AD ou vários é necessário um projeto bastante claro sobre a ideia envolvida. A forma adequada de fazer isto é escrever um I-D, estruturado objetivamente. Em alguns casos, o I-D é acompanhado por um código que funcione. O texto, mais o código já são suficientes para garantir sucesso, na aprovação do WG. Se, entretanto conseguir interessados, o processo pode ser bem mais rápido, intensificado pela estrutura da ideia no I-D. O caminho para o WG pode ser longo, mas o BOF é um dos ambientes mais propícios a avançar. Às vezes a criação formal do BOF é antecedida por apresentações locais e / ou BOFs informais (o BOF formal, em um encontro do IETF, geralmente é de uma única sessão).

Um exemplo interessante e que pode ser acompanhado é a proposta que está sendo elaborada por Danton Nunes21. Danton, está preocupado em recomendar algumas alternativas para melhorar o protocolo SPF: “…um mecanismo para endereço IP pode ou não enviar email de um dado domínio”. Após perfeiçoado sua ideia, Danton colocou-a na lista do GTER e recebeu inúmeras sugestões que lhe permitiu refiná-la. Sua próxima etapa foi desenvolver um código para testar a recomendação. Feito isto, apresentou o projeto na segunda reunião anual do GTER de maneira bastante consistente. O próximo passo, certamente será um BOF em encontro do IETF, pois ele já possui o I-D (ainda não formatado nos padrões desejáveis pelo IETF). A criação do WG será bem rápida, imagina-se. Mais rápido ainda, se ele fizer um debate informal com alguns participantes do IETF que foram importantes no desenvolvimento do protocolo original, pois sob a ótica da meritocracia do IETF, a opinião deles será relevante!

No exemplo do parágrafo anterior, a formatação do I-D será fundamental. O IETF divulga um conjunto de ferramentas, desenvolvidas por seus participantes, para facilitar o trabalho do autor, nesta etapa, e que podem ser vistas em IETF Tools.

Um exemplo final, que ilustra a informalidade das ideias dentro do IETF, na expectativa de que os participantes trabalhem sobre elas está em um I-D disponibilizado por Ammar J. Salih, relacionado com a adição de localização por GPS no cabeçalho do IPv6 e que pode ser visto aqui: Adding GPS location to IPv6 header. Ammar divulgou seu projeto no Linkedin, no grupo do IETF. Apesar de bastante claro, o I-D está, ainda, escrito informalmente, o que é admissível. Como se pode ver, o I-D permanecerá no sítio do IETF, por 6 meses, caso não siga em frente, da forma exibida na Figura 3.

Como se pode verificar, o BOF é um componente importantíssimo no processo. Ele ajuda a consolidar a ideia, nos arredores do problema. A RFC543422 é o documento que recomenda o que se deve fazer para que o BOF seja um sucesso. No LACNIC XVIII vi propostas de algumas sessões de BOF, o que indica o fato de que o BOF pode ser considerado informal (isto é, fora dos encontros do IETF). Voltemos ao exemplo do Danton Nunes. A sua palestra foi, de certa forma, um BOF, do qual “compulsoriamente” pessoas de diversas correntes de pensamento participaram. Alguns, portanto, sem interesse no assunto. A ausência da noção de existência ou não de massa crítica no Brasil, não foi respondida naquele momento. O GTER poderia pensar na possibilidade de permitir os “GTER-GTS-BOFs”, sem prejuízo da apresentação normal. A recomendação partiria do interessado ou da coordentação do GTER / GTS. Isto poderia estimular a participação da comunidade brasileira no IETF. Se o assunto for considerado relevante, pela comunidade presente, o Nic.br poderia apoiar a participação do(s) “dono(s)” da ideia, no IETF. A proposta do Danton, não foi a única apresentada no GTER, e provavelmente, no GTS.


Nota 1: S. Moonesamy, da República do Maurício, ISOC Fellow e, bastante ativo no IETF, lembrou que já existe um WG para o SPF. Moonesamy, também, recomendou algumas correções importantes no texto, a quem o autor agradece.


 

Como participar do IETF

 

Existem, basicamente, duas maneiras de participar no IETF: encontros e WGs. A Figura 4, abaixo apresenta um resumo geral e os pré-requisitos (quando for o caso). Complementarmente, a Figura 4 exibe os locais nos quais ocorrerão os três eventos principais durante os anos de 2013 e 2014.

 

Participacoes

Figura 4. Como participar do IETF e os eventos programados (2013 / 2014). Fonte: Adaptado de vários textos do IETF.

 

Os encontros (“meetings”), do IETF são as oportunidades em que os participantes dos WGs encontram-se para consolidar as idéias e se conhecerem. A participação pode ser remota. As várias formas de participação remota estão descritas na documentação de cada encontro, como por exemplo, em “Agendas and Meeting Materials” do IETF 86 que, aos poucos vai se delineando. Um panorama dos recursos que são colocados para a participação remota pode ser visto, quando da realização do IETF 85.

A participação presencial, além da forma tradicional (inscrever, pagar, viajar e participar), a ISOC oferece bolsas (“Fellowships”) para que diversos tipos de pessoas tenham oportunidade de participar, até em duas oportunidades. Estas bolsas incluem a estada no hotel do encontro, despesas de passagem e uma ajuda de custos. Todas as informações estão disponíveis em “Education and Leadership Programmes“. Há alguns pré-requisitos para concorrer a uma bolsa que estão descritos em “Selection Criteria for Fellowships to the IETF“. Um dos mais importantes é ser associado da ISOC, onde existe uma forma de se associar, sem necessidade de contribuição.

A participação efetiva e duradoura é através dos WGs. Como já foi dito, o IETF divide suas atividades operacionais em 8 áreas às quais são associados respectivos WGs. A Figura 4 exibe as oito áreas, com uma pequena descrição dos interesses relacionados. Detalhes, entretanto, dos interesses de cada área e respectivos grupos podem ser encontrados em “Active IETF Working Groups“.

Às vezes, a interpretação do domínio de uma das oito áreas do IETF pode parecer confusa, principalmente, durante as sessões de um encontro. Existe um conjunto de tutoriais que ajudam no entendimento de tópicos específicos. Alvaro Retana e Fernando Gont, em [18] comentam sobre as áreas e fatos interessantes dos respectivos grupos, incluindo estatísticas.

 

Conclusões

 

Este é um texto introdutório sobre o IETF, seu funcionamento, sua relação com a ISOC e demais organizações associadas, além de mostrar como são construídos os documentos que dão origem às RFCs. As regras do IETF são bem definidas e oferecem uma flexibilidade suficiente para que os participantes se sintam à vontade livres para desenvolver o trabalho, que não é pequeno. Há anos funciona muito bem e as idéias são consolidadas em um ambiente de “múltiplas partes interessadas”. Um verdadeiro caos organizado! O IETF tira o máximo do conhecimento de milhares de pessoas, que agem soberana, e prazeirosamente, em benefício dos usuários da Internet.

O assunto não se esgota já que é bastante complexo. Os três encontros anuais do IETF constituem o exercício culminante dos esforços que são feitos pela comunidade que deles participam, antes e durante. O próximo será o IETF 86, em Orlando, Flórida. A sua organização já está em franco andamento e pode ser vista aqui, em constante e rápida atualização.

Este texto, além de ser uma introdução incompleta do funcionamento do IETF, contêm referências que, também, não são completas. A quantidade de material disponível, seja em RFCs, no sítio do IETF ou em outras fontes, são inesgotáveis. Em The IETF Process: an Informal Guide, editado por Brian Carpenter tem-se uma excelente referência complementar, como ele mesmo diz diz: “…is an informal guide to various IETF process documents, intended mainly to assist IETF participants in navigating the labyrinth. …”, que vale a pena acompanhar.

Já é possível antever que – antes, durante e depois do IETF 86 -, a experiência será maravilhosa! Sob o ponto de vista técnico, uma oportunidade dos Deuses que, minimamente deve ser divulgada, e recomendado, para quem ainda não o fez, que se associe à ISOC: aqui e / ou aqui.

Em resumo, vale esclarecer que a exposição acima é a visão de um “First Time Fellow” preparando-se para o que será uma experiência inesquecível.

 

Artigos relacionados

 

 

Referências

 

  1. Paul Hoffman (Editor). The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force. IETF 2012. Acessado em 08/11/2012.
  2. RFC6722, Publishing the “Tao of the IETF” as a Web Page P. Hoffman [ August 2012 ] (TXT = 6192) (Obsoletes RFC4677) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.
  3. RFC4677, The Tao of IETF – A Novice’s Guide to the Internet Engineering Task Force P. Hoffman, S. Harris [ September 2006 ] (TXT = 127383) (Obsoletes RFC3160) (Obsoleted-By RFC6722) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.
  4. Wikipédia. Taoismo. Acessado em 08/11/2012.
  5. RFC3797. Publicly Verifiable Nominations Committee (NomCom) Random Selection D. Eastlake 3rd [ June 2004 ] (TXT = 39883) (Obsoletes RFC2777) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.
  6. RFC3777. IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin [ June 2004 ] (TXT = 76395) (Obsoletes RFC2727) (Updated-By RFC5078, RFC5633, RFC5680) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: nomcom). Acessado em 08/11/2012.
  7. ISOC Escritório Brasileiro. http://www.isoc.org.br/. Acessado em 08/11/2012.
  8. Messages from the IAB/IESG Nominating Committee. https://datatracker.ietf.org/ann/nomcom/. Acessado em 08/11/2012.
  9. List of IAB/IESG Nominating Committee Members (by year). https://www.ietf.org/nomcom/committee.html/. Acessado em 08/11/2012.
  10. Scott Bradner. IETF Structure and Internet Standards Process. 85th IETF Atlanta, Georgia, USA, 2012. Disponível em: http://www.ietf.org/proceedings/85/slides/slides-85-edu-newcomers-0.pdf. Acessado em 02/01/2013.
  11. RFC4071 (BCP101). Structure of the IETF Administrative Support Activity (IASA) R. Austein, B. Wijnen [ April 2005 ] (TXT = 48614) (Updated-By RFC4371) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.
  12. RFC2026. The Internet Standards Process — Revision 3 S. Bradner [ October 1996 ] (TXT = 86731) (Obsoletes RFC1602, RFC1871) (Updated-By RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC5657, RFC5742, RFC6410) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: poised95). Acessado em 10/11/2012.
  13. Vint Cerf. IETF and the Internet Society: A bit of history. 18 July, 1995. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/ietf-and-internet-society. Acessado em 10/11/2012.
  14. Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Larry G. Roberts, Stephen Wolff. Brief History of the Internet. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet. Acessado em 10/11/2012.
  15. IETF. A Brief History of the Internet & Related Networks. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet-related-networks. Acessado em 10/11/2012.
  16. Bruce Sterling. February 1993. Short History of the Internet. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/short-history-internet. Acessado em 10/11/2012.
  17. Thomas Narten. IETF 81, Quebec City, Quebec. July 24, 2011. Bringing New Work to the IETF. Disponível em http://www.ietf.org/edu/documents/81IETF-New-Work.pdf. Acessado em 02/01/2012.
  18. Alvaro Retana, Fernando Gont. Areas y Grupos de Trabajo en IETF. Lacnic XVIII, 2012. Disponível em https://www.dropbox.com/sh/4358z9df8dykn8l/GHZSPMjoSj/Acosta_28102012_IETF.pdf. Acessado em 03/01/2013.
  19. RFC2026. The Internet Standards Process — Revision 3 S. Bradner [ October 1996 ] (TXT = 86731) (Obsoletes RFC1602, RFC1871) (Updated-By RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC5657, RFC5742, RFC6410) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: poised95). Acessado em 03/01/2013.
  20. Alexis Simoneli. A Concise Guide to the Major Internet Bodies. January 2005. Disponível em http://ubiquity.acm.org/article.cfm?id=1071915. Acessado em 02/01/2012.
  21. Danton Nunes. Proposta de um novo protocolo anti−spam
    complementar ao SPF. 34ª Reunião do GETER, 07/12/2012, São Paulo, SP. Disponível em ftp://ftp.registro.br/pub/gter/gter34/03-SPFrev.pdf. Acessado em 06/01/2013.
  22. RFC5434. Considerations for Having a Successful Birds-of-a-Feather (BOF) Session T. Narten [ February 2009 ] (TXT = 33887) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 07/01/2013.
  23. RFC2014. IRTF Research Group Guidelines and Procedures A. Weinrib, J. Postel [ October 1996 ] (TXT = 27507) (Also BCP0008) (Status: BEST CURRENT PRACTICE) (Stream: Legacy). Acessado em 13/01/2013.
  24. RFC1690. Introducing the Internet Engineering and Planning Group (IEPG) G. Huston [ August 1994 ] (TXT = 3013) (Status: INFORMATIONAL) (Stream: Legacy) . Acessado em 10/02/2013.
Categorias:IAB, IANA IPv4, IESG, IETF, ISOC, TCP/IP, W3C Tags:, ,
%d blogueiros gostam disto: