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.

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 Conceito⁴, 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 CMaps⁸ 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ônomos⁶ 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 IETF⁹. 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.

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.

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”⁵ 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:

Quando esta divisão foi feita, o provedor tinha em mente o RFC 6177³, 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:

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.

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.

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.

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:

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.

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

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?

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