Identificador global com base na Internet:
Protocolo de comunicação com o resolvedor urlib.net
(Internet based global identifier IBGI or simply IBI)
Gerald Jean Francis Banon e Lise Christine Banon
Obsolescido por: <http://urlib.net/J8LNKB5R7W/3G2EKR5>
Última versão: 2009-04-24
Versão anterior: 2009-03-16 (inclusão do identificador opaco com base no IP)
Primeira versão: 2008-05-16
URLs persistentes deste documento:
<http://urlib.net/iconet.com.br/banon/2008/05.16.17.13>
<http://urlib.net/NENDTJMTKW/335L8GH>
<http://urlib.net/6RPa7umaZ/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.
Uma vez escolhido um sistema de identificação global
e por meio dele atribuido identificadores à documentos
ou a atores, vários problemas podem ser solucionados.
Entre eles, há a construção de hipervínculos persistentes.
A construção de hipervínculos persistentes passa
pelo uso de um resolvedor de identificação,
cujo papel consiste em redicionar cada URL, agora contendo apenas o
identificador global de um documento, para a URL contendo o seu
endereço físico.
Dois outros problemas importantes na Internet podem ser resolvidos.
O primeiro é 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 segundo é dirimir as dúvidas sobre qual de duas obras possue
a anterioridade.
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
pode tomar duas formas diferentes.
No caso de usar o nome de domínio, o prefixo
é formado a partir do nome do computador, do seu nome de
domínio e da porta em uso pelo provedor.
No caso de usar o IP, o prefixo é formado a partir do IP
e da porta em uso pelo provedor (acrescentando um número
par para distinguir entre possíveis hospedeiros virtuais).
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, no caso de recorrer
ao nome de domínio, podem ser encontrados
em [2, Seção 3].
Exemplo 1 (caso de recorrer ao nome de domínio):
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??
Exemplo 2 (caso de recorrer ao IP):
um provedor de dados hospedado em um computador
com IP 150.163.34.243
disponibilizando documentos na Internet como
hospedeiro virtual 800, terá como prefixo: 8JMKD3MGP8W
Depositando um novo documento em 16 de fevereiro de 2009
às 17 horas 46 minutos, será criado o sufixo:
34PGRBS
Desta forma o identificador global do documento será:
8JMKD3MGP8W/34PGRBS
e seu acesso na Internet (url persistente) será:
http://urlib.net/8JMKD3MGP8W/34PGRBS
O acesso aos metadados do documento será:
http://urlib.net/8JMKD3MGP8W/34PGRBS??
Observação: os exemplos acima são reais.
No ambiente da URLib, o identificador de documento apresentado
acima (padrão do exemplo 1) é 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)
- 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)
O resolvedor confronta estes dados com os dados dos outros
atores já registrados e caso não haja incompatibilidade,
registra o provedor e retorna uma página xml contendo:
- actorID (ex: sid.inpe.br/mtc-m18@80/2008/03.17.15.17)
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, por meio do
uso do nome de domínio).
Observação 2: o cadastro de um ator só se torna efetivo após um
pedido de cadastro de pelo menos um documento realizado com sucesso
(ver Seção 4.4, Oberservação 8).
Observação 3: um cadastro de um ator é cancelado após 2 anos caso as URLs
de todos os documentos registrados pelo ator cessam de funcionar.
Observação 4: nenhuma providência precisa ser tomada caso um provedor
muda de IP (desde que o seu nome de domínio se mantém o mesmo).
Observação 5: se o ator já estiver cadastrado, o resolvedor simplesmente
retorna o actorID já existente.
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: sid.inpe.br/mtc-m18@80/2008/03.17.15.17)
- 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: sid.inpe.br/mtc-m18@80/2008/03.17.15.17)
- 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: sid.inpe.br/mtc-m18@80/2008/03.17.15.17)
- password (ex: 12xY3z)
- documentID (optional, ex: 3D446S8B8W/34U55T2)
- 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)
- fingerprint (optional, fingerprint of the document as produced by the algorithm: message digest 5 (MD5))
- 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 metadataFormat metadataLanguage"
pode ser repetida. Exemplo:
metadataURL=http://mtc-m17.sid.inpe.br/col/lcp.inpe.br/ignes/2004/02.12.18.39.49/doc/mirrorget.cgi?metadatarepository=dpi.inpe.br/banon/2000/05.25.20.06
metadataLastUpdate=2009-03-12T16:20:53-03:00
metadataFormat=
metadataLanguage=pt-BR
metadataURL=http://mtc-m17.sid.inpe.br/col/lcp.inpe.br/ignes/2004/02.12.18.39.49/doc/mirrorget.cgi?metadatarepository=dpi.inpe.br/banon/1999/04.02.15.49
metadataLastUpdate=2009-03-12T16:20:53-03:00 2009:03.12.16.20.53
metadataFormat=
metadataLanguage=en
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.
Observação 8: ao confrontar os dados recebido do provedor, o resolvedor verifica
em particular, por meio do uso do comando nslookup, se as URLs fornecidas
pelo provedor estão pertencendo ao mesmo IP que o do ator. Caso uma URL
não pertencer, então o cadastro do documento não é efetivado.
4.5 Troca de ator de um documento
Uma troca de ator se aplica somente a documentos que não são 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/mtc-m18@80/2008/03.17.15.17)
- password (ex: 12xY3z)
- documentID (ex: 3D446S8B8W/34U55T2)
- newActorID (ex: sid.inpe.br/mtc-m19@80/2009/02.22.14.34)
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 1: para que a troca seja efetivada, o novo ator
deve ter previamente cadastrado o documento, e o pedido de
troca tem que ser feito pelo ator para o qual o documento
não é uma cópia.
Observação 2: 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 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 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/mtc-m18@80/2008/03.17.15.17)
- password (ex: 12xY3z)
- documentID (ex: 3D446S8B8W/34U55T2)
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/mtc-m19@80/2009/02.22.14.34)
- password (ex: 12xY3z)
- documentID (ex: 3D446S8B8W/34U55T2)
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>
--------------------------