\documentclass{article} \usepackage[english,portuguese]{babel} \RequirePackage{ae} \RequirePackage{color} %% essencial %% aplicar cores no texto \RequirePackage{multirow} \RequirePackage{dcolumn} %\RequirePackage[english]{babel} \RequirePackage{tabularx} \RequirePackage{graphicx} \RequirePackage{subfigure} \RequirePackage{amssymb} % \mathbb{R} \RequirePackage{amsmath} % \circledR \RequirePackage{amsrefs} %\RequirePackage{txfonts} \definecolor{bblue}{rgb}{0,0,.4} %% tom azul mais escuro \RequirePackage[colorlinks=true,linkcolor=bblue,urlcolor=bblue,pdfpagemode=None,pdfstartview=FitH]{hyperref} %\usepackage{courier} \hypersetup{pdfstartpage=6} %\usepackage{arial} % NÃO FUNCIONOU - ficou times %\usepackage[scaled]{uarial} % NÃO FUNCIONOU - ficou times %\renewcommand{\rmdefault}{phv} % Arial %\renewcommand{\sfdefault}{phv} % Arial \setlength{\parindent}{0pt} \setlength{\parskip}{6pt} \begin{document} \begin{center} \Large Identificador com base na Internet \normalsize (Internet Based Identifier -- IBI) Projeto 08:001.06 - 100 \end{center} \begin{flushleft} Resumo \end{flushleft} Esta Norma apresenta as várias formas em que um identificador global pode vir a ser utilizado para identificar e prover acesso consistente e perene a diversos tipos de itens de informação (documentos, mapas, imagens, etc.) armazenados em acervos, sejam eles repositórios ou arquivos digitais. A implantação e a utilização deste identificador global requerem, de forma direta, a infra-estrutura já existente na Internet, portanto, sem custo adicional, neste aspecto. O identificador global pode ser utilizado em associação com o processo de armazenamento de informação em acervos. O que torna simples a criação de cópias em acervos distintos e, também, a própria migração de itens de informação entre eles. As diversas aplicações de um identificador global desta natureza são de particular interesse em sistemas de dados espaciais e de informação. \begin{flushleft} CONTEÚDO \end{flushleft} \section{Objetivo} Esta Norma estabelece as regras de construção de um identificador com base na Internet, assim como suas várias formas de apresentação. \section{Justificativa} Os hipervínculos (\textsl{hyperlinks}) ou simpelsmente vínculos ou ponteiros, elementos essenciais na navegação entre itens de informação (documentos, mapas, imagens, etc.) disponíveis na Internet devem ter seu funcionamento preservado por longo prazo. A solução para tornar os ponteiros persistentes encontra-se no uso de um sistema de identificação global. Um sistema de identificação consiste em associar de forma permanente, cada item de informação, à um único identificador, de maneira que, itens distintos sejam associados à identificadores distintos. O sistema de endereçamento físico de um item de informação na Web por meio de uma URL (Uniform Resource Locator), não é um sistema de identificação, pois, com o tempo, um determinado item de informação pode mudar de localização, fazendo com que a associação item de informação $\mapsto$ URL não fique permanente. Uma vez escolhido um sistema de identificação e por meio dele atribuido identificadores à itens de informação, o problema da construção de ponteiros persistentes pode ser solucionado por meio do uso de um resolvedor de identificação, cujo papel consiste em redicionar cada URL, agora contendo apenas o identificador de um item de informação, para a URL contendo o seu endereço físico. O sistema de identificação descrito nesta Norma apresenta-se como uma alternativa simples, quando comparada a outras soluções como, por exemplo, o PURL ou o DOI$^\circledR$. Ele está sendo extensivamente usado na plataforma UR{\slshape Lib}. \section{Construção de um sistema de identificação} Como prerequisito à construção de um sistema de identificação, supõe-se que o conjunto dos itens de informação é enumerável, desta forma, os itens de informação poderão ser identificados por sequências finitas de símbolos (em número finito) chamado aqui de ``rótulo''. Ao associar um determinado item de informação à um rótulo, esse rótulo passa a ser chamado de ``identificador'' do item de informação. Nessa condição, a solução geral para identificar itens de informações consiste em associar cada novo item à um rótulo qualquer ainda não utilizado como identificador. Considerando que o sistema de identificação é um processo dinámico (i.e., que ocorre ao longo do tempo), uma solução particular consiste em utilizar como rótulo, a data e hora na qual é feita a associação, sendo a granularidade da data suficiente para distinguir entre duas associações sucessivas. No entanto, as soluções anteriores, pressupõem um sistema de identificação centralizado, sob a responsabilidade de um único ator, para o qual toda requisição de nova identificação deve ser encaminhada, tornando o sistema de identificação de itens de informação relativamente vulnerável. Por este motivo, uma solução segura deve levar à um sistema de identificação hierárquico em dois níveis. O primeiro nível consiste em um único sistema enquanto o segundo nível consiste em vários subsistemas cada um sob a responsabilidade de um ator distinto. Num primeiro momento, cada subsistema receba do sistema do primeiro nível, um identificador, e num segundo momento, cada item de informação receba, de um determinado subsistema, um identificador. A concatenação destes dois identificadores constitue a identificador final do item de informação. Enquanto o identificador de um item de informação fornecido por um determinado subsistema tem validade apenas dentre do escopo deste subsistema, o identificador obtido por concatenação, tem validade dentre do escopo global do sistema de identificação dos subsitemas. O Handle System$^\circledR$, por exemplo, funciona desta maneira. Usando a terminologia deste sistema, a identificação final é a concatenação de um prefixo identificando um subsistema e de um sufixo identificando um item de informação no escopo deste subsistema. A solução apresentada aqui, implementada na plataforma UR{\slshape Lib} usada no INPE desde 1995, consiste em reaproveitar a infra-estrutura já existente da Internet para identificar os subsitemas, portanto, sem custo adicional, neste aspecto. Supondo que cada subsistema seja hospedado em um computador ligado à Internet com IP (\textsl{Internet Protocol}) fixo, ele é naturalmente identificado pelo seu endereço nesta rede, fornecendo assim, de forma simples, o prefixo. Afim de desburocratizar ainda mais o sistema de identificação como um todo, o sufixo, fornecido por um subsistema, segue uma regra comum a todos os subsistemas, e consiste na data e hora da associação do item de informação ao sufixo. Esta escolha facilita o reuso de um identificador de subsistema quando este passa sob o controle de um novo ator. Na solução objeto desta Norma, dois tipos de prefixo herdado da Internet são considerados. O primeiro tipo consiste em adotar como identificador de um subsistema, isto é como prefixo, o nome de domínio \cite{Mockapetris:2009:DoNaCo} do computador que o hospeda, assim como sua porta de acesso. P. Mockapetris (November 1987). "Name space specifications and terminology". Domain names - concepts and facilities. IETF. sec. 3.1. RFC 1034. Retrieved 2008-08-03.\url{http://tools.ietf.org/html/rfc1034#section-3.1} No segundo tipo, o prefixo é obtido trocando o nome de domínio do computador pelo IP. Os exemplos reais a seguir antecipam alguns detalhes sobre a formação dos identificadores que serão dados nas seções seguintes. % Exemplo 1 \begin{flushleft} \textbf{Exemplo 1} (identificador com base no nome de domínio). \end{flushleft} A associação do item de informação ao sufixo, ocorrida em 14 de abril de 2008 às 11 horas 53 minutos, resultou no sufixo: \begin{center}\texttt{2008/04.14.11.53}\end{center} O subsistema emitindo este sufixo era hospedado em um computador denominado \texttt{md-m09}, pertencendo ao domínio \texttt{sid.inpe.br}, e acessível a partir da porta \texttt{80}, levando ao uso do prefixo: \begin{center}\texttt{sid.inpe.br/md-m09@80}\end{center} Desta forma, o identificador para o item de informação passou a ser: \begin{center}\texttt{sid.inpe.br/md-m09@80/2008/04.14.11.53}\end{center} Usando, por exemplo, o resolvedor de identificação \texttt{urlib.net}, o ponteiro (URL) persistente para este item é: \begin{center}\texttt{\href{http://urlib.net/sid.inpe.br/md-m09@80/2008/04.14.11.53}{http://urlib.net/sid.inpe.br/md-m09@80/2008/04.14.11.53}}\end{center} Adicionalemente, o ponteiro (URL) persistente para os metadados deste item é: \begin{center}\texttt{\href{http://urlib.net/sid.inpe.br/md-m09@80/2008/04.14.11.53??}{http://urlib.net/sid.inpe.br/md-m09@80/2008/04.14.11.53??}}\end{center} Observa-se, que mesmo que o nome de domínio \texttt{sid.inpe.br} passe a ser abandonado ou muda de dono, ou ainda que o nome do computador \texttt{md-m09} deixa de existir, isto não inviabiliza o identificador criado. O importante, apenas, é que estes dados eram pertinente no contexto da Internet na data e hora da associação entre o item de informação e o identificador. Esta observação vale também para o segundo exemplo a seguir. % Exemplo 2 \begin{flushleft} \textbf{Exemplo 2} (identificador opaco com base no IP). \end{flushleft} A associação do item de informação com o sufixo, ocorrida em 16 de fevereiro de 2009 às 17 horas 46 minutos, resultou no sufixo opaco: \begin{center}\texttt{34PGRBS}\end{center} O subsistema emitindo este sufixo era hospedado em um computador com IP \texttt{150.163.34.243}, e acessível a partir da porta \texttt{800}, levando ao uso do prefixo opaco: \begin{center}\texttt{8JMKD3MGP8W}\end{center} Desta forma, o identificador para o item de informação passou a ser: \begin{center}\texttt{8JMKD3MGP8W/34PGRBS}\end{center} Usando, por exemplo, o resolvedor de identificação \texttt{urlib.net}, o ponteiro (URL) persistente para este item é: \begin{center}\texttt{\href{http://urlib.net/8JMKD3MGP8W/34PGRBS}{http://urlib.net/8JMKD3MGP8W/34PGRBS}}\end{center} Adicionalemente, o ponteiro (URL) persistente para os metadados deste item é: \begin{center}\texttt{\href{http://urlib.net/8JMKD3MGP8W/34PGRBS??}{http://urlib.net/8JMKD3MGP8W/34PGRBS??}}\end{center} Observa-se que a granularidade do prefixo é extremamente fina já que os subsistemas são atrelados à números de porta de computador possuindo nome de domínio ou IP. Quanto a granularidade do sufixo ela pode ser aumentada sem dificuldade, acrescentando por exemplo os segundos. Os sistemas de identificação apresentados a seguir são agrupados em duas categorias. Na primeira, o identificador exibe o nome de domíno, e é chamado de ``repositório uniforme''. Na segunda categoria, o identificador é construido com base no IP e é chamado de opaco porque não exibe nem o IP, nem a data e hora da criação do identificador. \section{Regras de construção do identificador como repositório uniforme} No sistema de identificação apresentado nesta seção, o identificador é chamado também de ``repositório uniforme'' porque ele pode ser usado para definir uma seqüência de quatro diretórios servindo para armazenar, num sistema de arquivos, o item de informação sendo identificado. Os repositórios são chamados de uniforme porque eles são criados usando uma mesma regra de construção por todos os subsistemas. Desta forma, qualquer repositório pode ser instalado em qualquer subsistema, debaixo de um mesmo diretório, sem conflito de nome. Num identificador como repositório uniforme, o prefixo e o sufixo são separados por \texttt{/} e cada um é, por sua vez, subdividida em duas partes separadas também por \texttt{/}. Assim, o identificador é constituida de quatro partes, correspondendo, nesta ordem, a: - um nome de subdomínio, - a palavra \texttt{www} ou um rótulo, e eventualemente um número de porta, separados por ``\texttt{.}'' ou por ``\texttt{@}'', - um ano e - um mês, dia, hora, minuto, e eventualmente segundo, separados por ``\texttt{.}''. Em outros termos, a sintaxe de um repositório uniforme é a concatenação das quatro linhas abaixo: \texttt{/} \texttt{(|)[.|@]/} \texttt{/} \texttt{...[.]} Aqui vão dois exemplos de repositório uniforme: \texttt{dpi.inpe.br/banon/1995/09.01.10.50} \texttt{sid.inpe.br/iris@1912/2005/07.20.00.37.33}. De forma a garantir que o caminho acima seja único dentro de todos os caminhos criados até agora e todos os caminhos que serão criados no futuro, as seguintes regras devem ser observadas. - A expressão \texttt{(|).} deve ser o nome de domínio do computador hospedando o acervo local, e o \texttt{} deve ser a porta http que dá acesso a esse acervo local. Nos exemplos acima, os repositórios foram criados em acervos locais cujas URLs de acesso eram (no momento da criação do repositório) respectivamente, \texttt{banon.dpi.inpe.br} e \texttt{banon-pc2.dpi.inpe.br:1905}. - O \texttt{} e o \texttt{...[.]}, expressos numericamente, devem corresponder à data/hora GMT da criação do repositório, de forma a resolver o problema da migração de um acervo local entre fusos horários. %\subsection*{Regras com base no endereço de e-mail} ... \section{Comparação com o Handle System® e o DOI®} Como no Handle System®, o identificador usado na UR{\slshape Lib} possui um prefixo e um sufixo separado por uma barra "/". No entanto, a principal diferença reside no modo de geração do prefixo. No sistema de identificação usado na UR{\slshape Lib}, o cadastramento dos provedores de dados junto ao resolvedor de identificação não é um pre-requisto para os provedores de dados começarem a trocar dados entre si, por meio de importação de cópias e inclusão de vínculos relativos. Isto é possível porque no identificador usado na UR{\slshape Lib} o cadastramento dos prefixos é herdado do próprio funcionamento da Internet como meio de comunicação entre atores já previamente registrados. Com isto, a geração dos identificadores pode ser feita pelos próprios provedores de dados, sem necessidade de prévio cadastramento junto ao resolvedor de identificação. Por exemplo, considerando um caso real, antes mesmo de se registrar junto ao resolvedor de identificação, o provedor com prefixo iconet.com.br/banon pôde importar, sem conflito de nomes, do provedor com prefixo dpi.inpe.br/banon uma cópia do documento identificado por dpi.inpe.br/banon/1998/08.02.08.56. No provedor com prefixo iconet.com.br/banon, foi também possível incluir no arquivo: iconet.com.br/banon/2003/11.21.21.08/doc/cgi/oai.tcl, um vínculo relativo para o documento importado mencionado acima e contendo o arquivo doc/utilities1.tcl. Este vínculo apresenta-se da seguinte forma: ../../../../../../dpi.inpe.br/banon/1998/08.02.08.56/doc/utilities1.tcl. Neste exemplo, observa-se que, usando o identificador global usado na UR{\slshape Lib}, foi possível, sem necessidade de recorrer ao sistema de resolução de nome, estabelecer um vínculo entre dois documentos originalmente depositados em dois provedores distintos. O modo de geração do sufixo também é diferente. No caso do Handle System®, o modo de geração é livre e por conta do ator registrado neste sistema. No sistema de identificação usado na UR{\slshape Lib}, o modo de geração é padrão e o mesmo para todos os atores (ver Seção 3). Este último sistema é interessante, pois prevê inclusive os casos em que um novo ator se apropria de um prefixo caído em desuso. Naquele momento, este novo ator não precisa tomar conhecimento do sistema de geração dos identificadores utilizado pelo antigo ator, nem ter o cuidado de continuar a usá-lo, basta utilizar o sistema de geração padrão. Finalmente, em comparação com o DOI® 3, observa-se que tanto o DOI® quanto o identificador usado na UR{\slshape Lib} possuem múltiplos níveis de resolução. No entanto, este último resolve também a distinção entre um documento e suas cópias, oferecendo para o usuário final a garantia que o documento acessado é sempre o mesmo, seja ele uma cópia ou não. \bibliography{./reference} \hypertarget{references}{} \end{document}