Identificador global com base na Internet:
Protocolo de comunicação com o resolvedor urlib.net
(Internet based global identificator IBGI or simply IBI)
Gerald Jean Francis Banon e Lise Christine Banon
Última atualização: 2008-10-31
URLs persistentes deste documento:
<http://urlib.net/iconet.com.br/banon/2008/05.16.17.13>
<http://urlib.net/LK47B6W/335L8GH>
<http://urlib.net/APM77Z/UaJFT>
CONTEÚDO
1. Objetivo
2. Justificativa
3. Identificador global usado na plataforma URLib
4. Protocolo de comunicação com o resolvedor urlib.net
5. Comparação com o Handle System® e o DOI®
6. Referências
1. Objetivo
O objetivo desta nota é apresentar o identificador
global usado na plataforma URLib, assim como, um projeto
de protocolo de comunicação com o resolvedor de identificação
urlib.net
2. Justificativa
Os hipervínculos (hyperlinks), elementos essenciais
na navegação entre unidades de informação ou documentos
disponíveis na Internet devem ter seu funcionamento
preservado por longo prazo.
A solução para tornar os hipervínculos persistentes
consiste em usar sistemas de identificação global [1].
Um sistema de identificação global consiste em associar
de forma permanente, a cada documento, um único identificador,
de maneira que, documentos distintos sejam associados
a identificadores distintos.
O sistema de endereçamento físico de um documento na Web
por meio de uma URL (Uniform Resource Locator), não é
um sistema de identificação global, pois, com o tempo,
um determinado documento pode mudar de localização,
fazendo com que a associação documento/URL não fique
permanente.
Por este motivo, a implementação de um sistema de identificação
global passa pelo uso de um resolvedor de identificação,
cujo papel consiste em redicionar cada URL, agora contendo o
identificador global de um documento, para a URL contendo o seu
endereço físico.
Adicionalmente, o uso de um sistema de identificação global pode
solucionar também dois outros problemas importantes na Internet.
Primeiro ele pode informar quem é o proprietário dos direitos
patrimoniais de um documento e conseqüentemente, garantir ao
usuário final que o documento que ele está abrindo é o original.
O identificador global usado na plataforma URLib apresenta-se
como uma alternativa simples, quando comparado a outras soluções
como, por exemplo, o PURL ou o DOI®.
3. Identificador global usado na plataforma URLib
Antecipando o crescimento de um sistema de geração de
identificadores, este sistema deve permitir a sua manutenção
por atores distintos, e mesmo assim garantir que documentos
distintos receberão identificadores distintos.
Sendo assim, cada ator deve ser identificado de forma única,
ou seja deve receber um prefixo (usando a terminologia do
Handle System®). A solução apresentada aqui, e colocada em
prática desde 1995 no INPE por meio do uso da plataforma
URLib, consiste em reaproveitar a infra-estrutura
já existente da Internet e simplesmente considerar que
cada ator é identificado pelo seu atual endereço na
Internet.
Em geral, o ator (provedor de dados) está hospedado num
computador ligado à Internet. Para este caso, o prefixo
é formado a partir do nome do computador, do seu nome de
domínio e da porta em uso pelo provedor. Quando o computador
não está ligado à Internet, o prefixo é formado a partir
do endereço de e-mail do responsável pelo provedor de dados.
Para maior praticidade e simplicidade, cada ator
na Internet cria (ou manda criar) os identificadores
dos seus documentos, acrescentando ao prefixo, um
sufixo (usando novamente a terminologia do Handle System®)
formado a partir da data e hora de depósito do documento.
A escolha da data e hora, em vez de uma numeração seqüencial
por exemplo, simplifica ao máximo a manutenção quando um
prefixo muda de proprietário.
Mais alguns detalhes sobre a regra de criação do
identificador usado na URLib podem ser encontrados
em [2, Seção 3].
Exemplo: um provedor de dados hospedado em um computador
denominado md-m09, com o nome de domínio sid.inpe.br e
disponibilizando documentos na Internet a partir da porta
80, terá como prefixo: sid.inpe.br/md-m09@80
Depositando um novo documento em 14 de abril
de 2008 às 11 horas 53 minutos, será criado o sufixo:
2008/04.14.11.53
Desta forma o identificador global do documento será:
sid.inpe.br/md-m09@80/2008/04.14.11.53
e seu acesso na Internet (url persistente) será:
http://urlib.net/sid.inpe.br/md-m09@80/2008/04.14.11.53
O acesso aos metadados do documento será:
http://urlib.net/sid.inpe.br/md-m09@80/2008/04.14.11.53??
Observação: o exemplo acima é real.
No ambiente da URLib, o identificador de documento apresentado
acima é chamado de "repositório" porque ele é usado
para definir uma seqüência de diretórios que servem para
armazenar o documento no sistema de arquivo.
Observa-se que a granularidade do prefixo é extremamente
fina. Quanto a granularidade do sufixo ela pode ser
aumentada sem dificuldade, acrescentando por exemplo
os segundos.
4. Protocolo de comunicação com o resolvedor urlib.net
O resolvedor de identificação global urlib.net atende atualmente
a todos os provedores de dados que usam o software
URLibService. No futuro, este resolvedor poderá atender
qualquer provedor de dados por meio do protocolo apresentado
abaixo.
4.1 Cadastramento de um ator
Caso o ator for um provedor de dados hospedado num computador
ligado à Internet, este provedor submeterá via método GET ou POST
do HTTP/1.0 os seguintes dados:
- verb = RegisterActor
- computerName (name of the computer hosting the data provider, ex: hermes)
- ip (ip of the computer hosting the data provider, ex: 150.163.2.14)
- domainName (domain name of the computer hosting the data provider, ex: dpi.inpe.br)
- port (httpd port used by the data provider, ex: 80)
- eMailAddress (e-mail address of the data provider administrator, ex: banon@dpi.inpe.br)
- password (ex: 12xY3z)
- actorID (optional, ex: dpi.inpe.br/banon/2001/01.11.16.21)
O resolvedor confronta os dados com a resposta do nslookup e caso haja concordância,
registra o provedor e retorna uma página xml contendo:
- actorID (ex: dpi.inpe.br/banon/2001/01.11.16.21)
caso contrário, retorna uma página xml contendo:
- error message
Observação 1: o resolvedor de identificação usa a mesma regra
para identificar um documento e um ator (neste caso um provedor
de dados hospedado num computador ligado à Internet). Observa-se
também que o ator pode, ele mesmo, fornecer opcionalmente seu ID
(desde que ele siga o modo padrão de geração do identificador).
Observação 2: um cadastro de um ator é cancelado após 2 anos caso as URLs
de todos os documentos registrados pelo ator cessam de funcionar.
4.2 Troca da senha
O seguintes dados devem ser submetidos via método GET ou POST do HTTP/1.0:
- verb = ChangePassword
- actorID (ex: dpi.inpe.br/banon/2001/01.11.16.21)
- password (ex: 12xY3z)
- newPassword (ex: a2xY3z)
O resolvedor confronta estes dados com os dados registrados e
caso haja concordância, retorna uma página xml de confirmação:
- confirmation message
caso contrário, retorna uma página xml contendo:
- error message
4.3 Troca do endereço de e-mail
O seguintes dados devem ser submetidos via método GET ou POST do HTTP/1.0:
- verb = ChangeEMailAddress
- actorID (ex: dpi.inpe.br/banon/2001/01.11.16.21)
- password (ex: 12xY3z)
- newEmailAddress (ex: banon@iconet.com.br)
O resolvedor confronta estes dados com os dados registrados e
caso haja concordância, retorna uma página xml de confirmação:
- confirmation message
caso contrário, retorna uma página xml contendo:
- error message
4.4 Cadastramento de um documento
O seguintes dados devem ser submetidos via método GET ou POST do HTTP/1.0:
- verb = RegisterDocument
- actorID (ex: dpi.inpe.br/banon/2001/01.11.16.21)
- password (ex: 12xY3z)
- documentID (optional, ex: dpi.inpe.br/banon/2002/10.10.08.39)
- originalDocument (optional, its value is "yes" or "no", "no" means that the actor has not the copyright - default is "no")
- documentURL (url of the document, optional, ex: http://mtc-m17.sid.inpe.br/col/sid.inpe.br/mtc-m17%4080/2007/12.07.10.48/doc/paginadeacesso)
- documentLastUpdate {last update date and time of the document, required if documentURL is present, ex: 2008-07-17T17:22:06-03:00)
- metadataURL (url of metadata, optional, ex: http://mtc-m17.sid.inpe.br/col/iconet.com.br/banon/2003/11.21.21.08/doc/oai.cgi?verb=GetRecord&identifier=oai:sid.inpe.br:sid.inpe.br/mtc-m17@80/2007/12.07.10.48.20-0&metadataPrefix=mtd2-br)
- metadataLastUpdate {last update date and time of the metadata, required if metadataURL is present, ex: 2008-07-17T17:44:57-03:00)
- metadataFormat (optional, ex: mtd2-br)
- metadataLanguage (optional)
- previousEditionURL (url of the previous edition of the document, optional)
- nextEditionURL (url of the next edition of the document, optional)
O resolvedor confronta estes dados com os dados registrados e
caso haja concordância, retorna uma página xml contendo:
- documentID
caso contrário, retorna uma página xml contendo:
- error message
Observação 1: considera-se que num determinado provedor de dados nunca
devem existir dois documentos iguais, ou seja um provedor de dados nunca
disponibiliza cópia de um documento já disponibilizado por ele anteriormente.
Caso ele disponibilize cópias, os documentos que deram origem a estas cópias
advêm de outros provedores. Quando o documento não é uma cópia, o
ator pode informar por meio do argumento originalDocument se o documento
é original, isto é, se o autor do documento transferiu os direitos
patrimoniais ao ator.
Observação 2: opcionalmente o ator pode, ele mesmo, fornecer o ID do
documento (desde que ele siga o modo padrão de geração do identificador).
Observação 3: o argumento documentURL é opcional, tornando possível o
registro de apenas os metadados de um documento por meio do argumento metadataURL
(no entanto, as duas urls não podem ser omitidas juntamente).
Observação 4: o argumento nextEditionURL pode permitir que o resolvedor
de identificação retorne a última edição de um documento.
Observação 5: a sequência "metadataURL metadataLastUpdate format language"
pode ser repetida.
Observação 6: para o resolvedor de identificação, um documento não é uma cópia
se ele estiver hospedado no provedor que o cadastrou primeiro. Caso originalDocument
seja "yes" o documento não pode ser uma cópia, caso contrário o resolvedor
retorna uma mensagem de erro.
Observação 7: alterações nos documentos ou nos metadados devem ser notificados
por meio de um novo cadastramento. O novo cadastro sobescreve o anterior.
4.5 Troca de ator de um documento
Uma troca se aplica tanto a um documento quanto às suas cópias.
Quando o documento é o original, esta troca é equivalente a uma
transferência de direitos patrimoniais, ou seja o original muda
de ator.
O seguintes dados devem ser submetidos via método GET ou POST do HTTP/1.0:
- verb = ChangeActor
- actorID (ex: sid.inpe.br/banon/2001/03.09.09.16)
- password (ex: 12xY3z)
- documentID (ex: sid.inpe.br/md-m09@80/2008/06.04.14.39)
- newActorID (ex: sid.inpe.br/bibdigital@80/2006/04.07.15.50)
O resolvedor confronta estes dados com os dados registrados e
caso haja concordância, retorna uma página xml de confirmação:
- confirmation message
caso contrário, retorna uma página xml contendo:
- error message
Observação: após a troca, o antigo ator pode ou não manter o
documento em seu domínio, caso ele mantiver, o documento se
torna uma cópia (caso ele não fosse já uma cópia). Caso o
antigo ator não mantiver o documento em seu domínio, ele
deverá cancelar o cadastro do documento usando o serviço da
Seção 4.6. Caso o documento trocado não fosse uma cópia e o
novo ator já tivesse uma cópia, esta perde automaticamente
a condição de cópia.
4.6 Cancelamento do cadastro de um documento
Um cancelamento se aplica tanto a um documento quanto às suas cópias.
O seguintes dados devem ser submetidos via método GET ou POST do HTTP/1.0:
- verb = DeleteDocumentRegistration
- actorID (ex: sid.inpe.br/bibdigital@80/2006/04.07.15.50)
- password (ex: 12xY3z)
- documentID (ex: sid.inpe.br/md-m09@80/2008/06.04.14.39)
O resolvedor confronta estes dados com os dados registrados e
caso haja concordância, retorna uma página xml de confirmação:
- confirmation message
caso contrário, retorna uma página xml contendo:
- error message
Observação: o pedido de cancelamento de cadastro de um documento
deve acontecer antes do documento ser retirado do provedor.
O cadastro de um documento poderá ser cancelado somente após
o cancelamento do cadrastro de todas as suas cópias. Caso
o documento possua cópias, a mensagem de error contem a lista
de todos os atores que possuêm uma cópia.
4.7 Exibição do registro de um identificador
O registro completo de um identificador pode ser exibido
usando o verbo DisplayIDRegistration.
O seguintes dados devem ser submetidos via método GET ou POST do HTTP/1.0:
- verb = DisplayIDRegistration
- actorID (ex: sid.inpe.br/bibdigital@80/2006/04.07.15.50)
- password (ex: 12xY3z)
- documentID (ex: sid.inpe.br/md-m09@80/2008/06.04.14.39)
O resolvedor confronta estes dados com os dados registrados e
caso haja concordância, retorna uma página xml exibindo o registro
completo do identificador:
- full registration data
caso contrário, retorna uma página xml contendo:
- error message
Segue abaixo um exemplo genérico de registro de identificador.
documentID
actorID
originalDocument
documentURL documentLastUpdate
metadataURL metadataLastUpdate metadataFormat
metadataURL metadataLastUpdate metadataFormat
actorID
documentURL documentLastUpdate
metadataURL metadataLastUpdate
Neste exemplo temos dois tipos de metadados no primeiro
acervo e uma cópia do documento num segundo acervo.
5. Comparação com o Handle System® e o DOI®
Como no Handle System®, o identificador usado na URLib 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 URLib, 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 URLib
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 URLib,
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 URLib, 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 URLib 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 (ver um exemplo em [1]).
6. Referências
[1] Banon, G. J. F.
Hiperdocumentos versus URLib
Disponivel em: <http://urlib.net/dpi.inpe.br/banon/2002/10.10.08.39>
[2] Banon, G. J. F. & Banon, L. C.
O que é a URLib?
Disponivel em: <http://urlib.net/iconet.com.br/banon/2001/05.25.16.44>
[3] International DOI Foundation
DOI® Handbook
Disponivel em: <http://dx.doi.org/10.1000/182>
--------------------------