Este texto aborda a proposta de alteração do campo MARC 856, indicando as sugestões e possível consequência à codificação de registros bibliográficos, em especial no trato de recursos eletrônico.

Salienta-se que o Comitê Consultivo do MARC (MAC - MARC Advisory Committee), é o responsável por assessorar o MARC Steering Group sobre mudanças nos formatos MARC 21 (Bibliográfico, Autoridade, Holdings, Classificação, e de Informações da comunidade). Adota, como método de trabalho, a submissão de propostas para discussão entre os membros. O MARC Steering Group é formado por representantes da Library of Congress, Library and Archives Canada, British Library, e o Deutsche Nationalbibliothek.

Em dezembro de 2019, foi submetida proposta de atualização ou substituição, do campo 856 – Localização e Acesso Eletrônico. Este campo fornece informações para a localização e o acesso de recursos eletrônicos. Desta forma, permite a transferência eletrônica de arquivos, publicações eletrônicas ou ligação com catálogos bibliográficos.

Em síntese, a proposta considera as opções de atualizar o campo 856 ou definir um novo campo 857; acrescidos do novo subcampo $e, orientado a indicar informações de acesso, uso e reprodução; e de também ressignificar o subcampo $7 – status de acesso.

O tema em pauta encontra-se relacionado à documentos anteriores (de propostas) que registram a evolução, no MARC, da inclusão de vínculos eletrônicos: 93-4; 97-1; 99-06; 2019-01; DP 49; DP 54; DP 69; 2018-DP11; Diretrizes para o uso do campo 856, revisado em 1999; Diretrizes para o uso do campo 856, revisado em 2002. Na proposta, uma breve retrospectiva destaca que, originalmente, a etiqueta 856 decorre da avaliação de informações da Internet, em 1993. Surge como forma de fornecer uma comunicação dos serviços de biblioteca mediados por computador; sendo publicada como documento da OCLC (Research Report OCLC ou RR-93/1).

Segundo o World Wide Web Consortium (W3C), o Internet Engineering Task Force (IETF) estabeleceu o Uniform Resource Identifiers Working Group para definir um conjunto de padrões orientados à codificação da localização de recursos eletrônicos, independentes do sistema e das informações de identificação no uso dos serviços de informações da Internet, em março de 1994. Na época em que a etiqueta 856 foi proposta, os URIs como são conhecidos na atualidade, nem sequer tinham um padrão definido.

A primeira proposta MARC 93-4, reconheceu esse fato ao destacar que os grupos de trabalho do IETF buscavam estabelecer uma maneira padronizada de codificar um indicador de recurso para qualquer sistema (Universal Resource Locator – URL), e formas padronizadas de identificar recursos (Uniform Resource Identifier – URI e Uniform Resource Number – URN; os nomes foram alterados e atualizados em 1992).

A URN equivale ao ISBN para recursos em rede. A definição de um identificador uniforme foi bastante discutida, uma vez que os padrões IETF foram desenvolvidos e implementados, exigindo incluir campos, no formato USMARC, para alguns ou todos os elementos de dados.

A volatilidade da localização eletrônica poderia ser um problema, se esses dados fossem incluídos em um registro USMARC. Assim, designadores de conteúdo foram propostos para permitir que a localização eletrônica e as informações de acesso estivessem contidas no registro. Também era esperado que, no momento de finalização do trabalho do IETF, para desenvolver Universal Resource Locator, e a sua implementação tornasse possível incluir vínculos (links) apropriados ao USMARC, esses campos poderiam não ser mais necessário.

O trabalho do IETF prometia uma solução útil; bem como identificadores de recursos eletrônicos eram necessários aos registros MARC, ainda que imperfeitos. A proposta 93-4, incluía vinte subcampos para o campo da etiqueta 856, mas nenhum deles se parecia com o que conhecemos na atualidade, como o subcampo $u (Uniform Resource Identifier), pelo simples motivo de que os URIs não existiam.

Na época da primeira proposta, foi publicado o "format integrated", 1994 Edition of the USMARC Format for Bibliographic Data, no qual o subcampo $u é definido como Uniform Resource Locator, e adicionado ao campo 856.

Esse documento foi substituído pelas diretrizes Guidelines for the Use of Field 856, revisado em 1999; incluía um anexo B: Subfield Use When Not Using $u (URL), com destaque aos subcampos prováveis e improváveis de serem usados. Este anexo tratou do uso e não uso do subcampo $u (URL), destacando:

Se: 1º indicador = 0 (e-mail) e uma URL não for registrada no subcampo $u, seriam utilizados os subcampos:
$a – Nome do Servidor (R)
$f – Nome eletrônico (R)
Poderia ser usado: $b, $h, $i, $m, $n, $s, $x, $z
Improvável o uso: $c, $d, $k, $l, $o, $p, $t, $2

Se: 1º indicador = 1 (ftp) e uma URL não for registrada no subcampo $u, seriam utilizados os subcampos:
$a – Nome do servidor (ou usar elementos exclusivos em $d e/ou $f abaixo e omitir $a)
$d – Caminho (R)
$f – Nome eletrônico (R)
Poderia também usar: $b, $c, $g, $i, $k, $l, $m, $n, $o, $p, $q, $s, $x, $3
Improvável o uso: $h, $t, $2

Se: 1º indicador = 2 (Login remoto) e uma URL não for registrada no subcampo $u, seriam utilizado o subcampo:
$a – Nome do servidor (R)
Poderia também usar: $b, $k, $l, $m, $n, $o, $p, $t, $x, $z, $3
Improvável o uso: $c, $d, $f, $g, $q, $s, $2

Estruturado a semelhança dos formatos MARC: Bibliográfico, Autoridade, Holdings,Classificação e Comunidade; embora a definição e o escopo apresentem diferenças entre os formatos. No formato bibliográfico atual, o campo é definido da seguinte forma:

856 - Localização e acesso eletrônicos (R): Contém informações necessárias para localizar e acessar um recurso eletrônico. Pode ser usado no registro bibliográfico de um recurso, quando esse recurso ou um subconjunto dele estiver disponível eletronicamente. Além disso, pode ser usado para localizar e acessar uma versão eletrônica do recurso não eletrônico, descrito no registro bibliográfico ou um recurso eletrônico relacionado. O campo é repetido se os elementos de dados do local variam (URL no subcampo $u ou quando usado nos subcampos $a, $b, $d). Também é repetido se mais de um método de acesso é utilizado; se diferentes partes do item estão disponíveis eletronicamente; se sites espelhados são registrados; se diferentes formatos com distintas URLs são indicadas; e itens relacionados são registrados. Pode também ser repetido, se o nome do arquivo eletrônico varia (subcampo $f), exceto quando uma única obra intelectual é dividida em deferentes partes para armazenamento ou recuperação on-line.

Indicadores

Códigos de subcampo

ASPECTOS SOBRE OS SUBCAMPOS DESIGNADORES DE CONTEÚDO

$g - Nome eletrônico - Fim do intervalo [redefinido, 1997]

$g - Uniform Resource Name - URN [obsoleto, 2000]: Como o subcampo $g (Nome Eletrônico - Fim do intervalo) raramente era usado, foi redefinido como URN (Nome Uniforme do Recurso), em 1997. Posteriormente, tornado obsoleto em favor do registro URN no subcampo $u.

$q - Modo de transferência de arquivos [redefinido, 1997]: O subcampo foi definido para conter a indicação do arquivo transferido como binário ou >ASCII. Foi redefinido para conter o tipo de formato eletrônico.

$u - Uniform Resource Identifier - URI [renomeado, 2000]: Antes de 1999, o subcampo $u era definido como repetível. Foi alterado para não repetível em favor da repetição do campo 856, devido à ambiguidade na determinação de quando o subcampo poderia ser repetível. O subcampo foi alterado novamente para repetível, e renomeado em 2000 para registrar URNs, depois que o subcampo $g foi tornado obsoleto.

$y - Texto de ligação [novo, 2000]

$7 - Status de acesso [novo, 2019]

No caso do campo 856, parecia adequado incluir o "Content Designator History” (Histórico dos Designadores de Conteúdo), que documenta as redefinições de subcampos e outras mudanças de interesse. Também pareceu relevante observar as pequenas variações no uso do campo, em cada um dos cinco formatos MARC 21:

• No registro bibliográfico, o campo 856 pode ser usado, quando o recurso ou um subconjunto dele estiver disponível eletronicamente. Também, pode ser usado para localizar e acessar a versão eletrônica de um recurso não eletrônico, descrito no registro bibliográfico, ou um recurso eletrônico relacionado.
  
  
• No registro de autoridade, o campo 856 pode fornecer informações suplementares disponíveis eletronicamente sobre a entidade para a qual o registro foi criado.
  
  
• No registro de holdings, o campo 856 identifica o endereço eletrônico que contém o recurso ou onde ele está disponível. Também contém as informações necessárias para recuperar o recurso pelo método de acesso identificado na primeira posição do indicador. As informações contidas no campo são suficientes para permitir a transferência eletrônica de um arquivo, acesso de um periódico eletrônico ou o login para um recurso eletrônico. Em alguns casos, apenas elementos de dados exclusivos são registrados, permitindo ao usuário acessar uma tabela de localização em um servidor, contendo as informações restantes necessárias para acessar o recurso.
  
  
• No registro de classificação, o campo 856 pode ser usado quando o recurso ou um subconjunto dele estiver disponível eletronicamente. Pode também ser usado para localizar e acessar a versão eletrônica de um recurso não eletrônico, descrito no registro de classificação, ou um recurso eletrônico relacionado. O campo ainda pode ser usado para vincular um recurso eletrônico destinado a complementar o esquema de classificação, por exemplo, a imagem de um mapa.
  
  
• No registro de informações da comunidade, o campo 856 contém as informações necessárias para localizar e acessar informações eletrônicas pertencentes a um serviço comunitário, como o site de serviços ou de eventos, ou ainda recursos relacionados.
  
  

Em relação a evolução do campo 856, ressalta-se a reunião promovida pela Library of Congress – LC, em junho de 2019, com representantes do Library of Congress Network Development and MARC Standards Office (), Deutsche Nationalbibliothek (DNB) e Online Computer Library Center (OCLC), para discutir a atualização MARC 21 (MARC 21 Update No. 28: Addendum). Os resultados da reunião foram documentados no MARC Proposal No. 2019-01.

Se no passado, o MARC Advisory Committee, e seu predecessor: Machine-Readable Bibliographic Information Committee (MARBI), em geral, relutavam redefinir um elemento MARC existente para algum uso específico; embora isso tenha sido feito, ocasionalmente. Entretanto, este documento apresentou três opções:

1. Tornar obsoletos os subcampos "não utilizados" no campo 856 para abrir espaço ao acesso completo e informações de uso.
   
   
2. Definir um novo campo 857, similar ao campo 856, mas usado apenas para URIs de Acesso Aberto. O novo campo contemplaria apenas os subcampos do campo 856, necessários para o acesso e uso.
   
   
3. 857, tornando o campo 856 obsoleto, mantendo apenas os subcampos atualmente necessários, e adicionando subcampos novos e necessários para o acesso e uso.

Em cada uma das opções, as informações completas de acesso e uso acrescentadas, seriam similares aos campos 506 (nota de acesso restrito) e 540 (nota de termos governando uso e reprodução). Como parte preparatória da reunião realizada em junho de 2019, as três instituições compilaram estatísticas sobre os respectivos usos dos elementos do campo 856, nos registros bibliográficos.

Recomenda-se observar, no quadro 1, que a coluna: Estatísticas DA-CH resume os dados coletados de várias instituições (incluindo as redes regionais de bibliotecas) na Alemanha, Áustria e Suíça, pela Biblioteca Nacional da Alemanha. O acrônimo DA-CH representa os três principais países de língua alemã: Alemanha (D – Deutschland), Áustria (A – Austria) e Suíça (CH – Confoederatio Helvetica)

Quadro 01 – Estatística de Uso dos Elementos do campo 856

O já anteriormente citado, anexo B: Subfield Use When Not Using $u (URL), oferece indicações dos motivos de certos subcampos raramente serem utilizados.

DAS JUSTIFICATIVAS PARA AS DELIBERAÇÕES SOBRE O CAMPO 856

Conforme deliberações contidas nas atas das reuniões do MARC Advisory Committee, em junho de 2019, a estrutura atual do campo 856 foi criado durante um período inicial da descrição e da conectividade dos recursos on-line; muitas das estruturas e valores definidos para o campo, não são mais aplicáveis no ambiente atual.

Um dos principais resultados, da reunião de junho de 2019, na LC, foi a necessidade de iniciar um processo de reexame completo do campo 856 visando incorporar condições de acesso e uso; além de excluir subcampos de pouca utilidade; e decidir quais das três opções descritas, ofereceria resultados vantajosos.

Entretanto, independente da opção escolhida, alguns dos subcampos existentes, e que não são mais úteis, tornam-se candidatos à exclusão ou redefinição. Baseado nas estatísticas de uso (quadro1), as maneiras pelas quais as políticas e práticas de acesso on-line evoluíram, e as recomendações da reunião de junho de 2019, sugeriram duas camadas de depreciação para os subcampos.

A primeira camada incluiu subcampos que considerados de pouco valor para a continuidade ou que são obsoletos:

$b - Número de acesso (R) – associado a um servidor. Pode conter o endereço numérico do Protocolo Internet (IP) se o item for um recurso da Internet; ou um número de telefone, se for acesso discado. Esses dados podem mudar, e podem ser gerados pelo sistema. Pode ser repetido, se todas as outras informações no campo foram aplicáveis.

$c – Informação de compressão (R) – informações sobre um arquivo, em particular, quando um programa específico é necessário para descompactá-lo. Pode ser repetível, se dois programas de compressão forem usados, observado a primeira compressão mais recente.

$g - Uniform Resource Name [Obsoleto, 2000]

$h – Processador de pesquisa (NR) ou processador da solicitação; em geral os dados que precedem o sinal de arroba (@) no endereço do servidor.

$j - Bits por segundo (NR): o menor e o maior número de bits (unidades binárias) de dados que podem ser transmitidos por segundo, quando conectados a um servidor. A sintaxe para registrar o número de bits por segundo (BPS) deve ser: < menor BPS > - < maior BPS >. Se houver apenas o menor valor: < menor BPS> -; Se houver apenas o maior valor: - .

$k – Password (NR): senha necessária para acessar o recurso eletrônico. Um site FTP pode requerer que o usuário digite um endereço de Internet ou uma senha específica. Catálogos acessados remotamente podem exigir senha. Esse subcampo é usado para registrar senhas de uso geral e não deve conter senhas de segurança. Instruções textuais sobre senhas devem estar no subcampo $z (Nota pública).

$l – Logon/Login (NR): passos necessários para se conectar a um recurso eletrônico ou FTP. Usado para registrar sequências de login de uso geral que não necessitam segurança especial. Um número de conta necessário para o login pode ser indicado.

$r – Definições (NR): usado para transferir dados. Incluídos nas definições estão: 1) Número de bits de dados (número de bits por caractere); 2) Número de stop bits (número de bits para sinalizar o fim de um byte); e 3) Paridade (na verificação da técnica usada). A sintaxe desses elementos é:
- -

Se apenas a paridade for fornecida, os outros elementos da definição e seus hífens relacionados são omitidos (por exemplo, ). Se um dos dois outros elementos for fornecido, o hífen do elemento ausente será registrado em sua posição correta (por exemplo, - ou - -). Os valores para Paridade são: O (Desemparelhado), E (Equilibrado), N (Nenhum), S (Espaço) e M (Meta).

$t - Emulação de terminal (R): geralmente é especificada para login remoto (o primeiro indicador contém o valor 2 (Login remoto (Telnet)). O segundo nível inclui subcampos que podem ser considerados de valor questionável, mas que podem ser mantidos ou, pelo menos, discutidos.

$i - Instrução (R): ou comando necessário para processar uma pesquisa em servidor remoto.

$n - Nome do local do servidor (NR): nome convencional da localização do servidor, no subcampo $a, incluindo sua localização física (geográfica).

$p - Porta (NR): parte do endereço que identifica um processo ou servidor.

$s - Tamanho do arquivo (R), armazenado sob um nome indicado no subcampo $f e, geralmente, expresso em termos 8 – bit – bytes (octetos). Pode ser repetido nos casos em que o nome do arquivo se repete, e segue diretamente o subcampo $f ao qual se aplica. Esta informação não é fornecida para periódicos, uma vez que o campo 856 se refere ao título completo, e não a uma edição em particular.

DEFINIÇÃO DE NOVOS SUBCAMPOS

A proposta MARC nº 2019-01 sugere o acréscimo de um novo subcampo $e no campo 856, e que foi temporariamente reservado para consideração como parte de sua reformulação.

O subcampo $e, no campo 856, foi considerado equivalente aos subcampos $a, $f e $u, nos campos 506 (nota de acesso restrito) e 540 (nota de termos governando uso e reprodução). Com a possível liberação de subcampos nos campos 856 e/ou 857, provavelmente mais útil. A opção de analisar as várias características de dados foram combinados no subcampo proposto $e em subcampos separados.

Opção 1: Dependendo da opção de campo escolhida, um novo subcampo $e pode ser definido para o campo 856 e/ou 857:

$e - Informações governando acesso, uso e reprodução (R): o subcampo fornece informações sobre direitos de acesso, direitos de uso e direitos de reprodução. Pode conter um termo em texto livre; um termo padronizado; ou uma URI.

Exemplo: 856

 Exemplo: 856

Opção 2: subcampos específicos para cada dado ou dados selecionados, de informações que podem ser definidas. Equivalente a alguns dos subcampos definidos no campo 506, contendo informações restritivas ao acesso dos materiais descritos, e no campo 540, contendo termos que regulam o uso dos materiais, após o acesso ser fornecido, podem ser analisados quando informações semelhantes forem necessárias no contexto de uma URI. Os subcampos relevantes são apresentados para fins de discussão, e sobre quais podem ser úteis para definir separadamente ou em combinação, no campo 856 e/ou 857.

506 $a Termos definindo o acesso

506 $f Terminologia padronizada para restrição de acesso

506 $g Data de disponibilidade

506 $q Agência fornecedora

506 $u Identificador uniforme de recursos (URI) para restrição de acesso

506 $2 Fonte do termo

540 $a Termos governando uso e reprodução

540 $f Direitos de uso e reprodução

540 $g Data de disponibilidade

540 $q Agência fornecedora

540 $u Identificador uniforme de recursos (URI) para uso e reprodução

540 $2 Fonte do termo

A SITUAÇÃO DO SUBCAMPO $7 NO CAMPO 856

O subcampo $7 fazia parte da Proposta MARC no. 2019-01, como um subcampo de controle de duas posições. Foi implementado como: “Status de Acesso”, estando definido no MARC 21:

$7 – status de acesso (NR), indica a disponibilidade de acesso ao recurso eletrônico, cujo endereço aparece no subcampo $u. O subcampo $7 se aplica a todos os subcampos $u presentes nos campos MARC:

0 - Acesso aberto: O recurso eletrônico é acessível online e aberto a todos, sem restrição, login ou pagamento.

1 - Acesso restrito: O recurso eletrônico não pode ser acessado online de forma aberta.

u - Não especificado

z - Outro

Exemplo: 856

1º ind.	2º ind.	subcampos
4	0	$3 Biblioteca digital HathiTrust, Visualização completa $u http://catalog.hathitrust.org/api/volumes/oclc/1654047.html $7 0

A escolha do subcampo numérico $7 para a função pode não ter sido ideal, mas foi pensada como necessária pela ausência de opções de subcampos, naquele momento.

No documento da proposta é justificado que o subcampo $7 foi definido e usado, nos registros bibliográficos, para indicar características especiais da entrada vinculada nos campos 76X-78X (tipos de entrada principal, formas de nome, tipos de registros e nível bibliográfico), e nos campos 800, 810, 811 e 830 (Tipo de registro e nível bibliográfico). No campo bibliográfico 533 (Nota de reprodução), o subcampo $7 contém informações codificadas relativas à reprodução (Tipo de data / status da publicação; Data 1; Data 2; Local de publicação, produção ou execução; Frequência; Regularidade e Forma do item). Em todos os casos, a definição de cada código depende da sua posição.

Nos caso dos campos: 7XX e 8XX, o uso do subcampo $7 foi limitado às características estruturais do MARC, correspondentes a um indicador de campo existente ou ao valor do campo Leader. No caso do campo 533, os elementos de dados codificados correspondem a várias posições existentes no campo 008, que são características estruturais do MARC e refletem substancialmente o próprio recurso.

O uso do subcampo $7, no contexto desta proposta deve ser visto como uma extensão da sua utilização no campo 533, no sentido de conter dados codificados que refletem o próprio recurso. Com a eliminação de vários subcampos alfabéticos no campo 856, a escolha do subcampo $7 pode agora ser reavaliada.

AS OPÇÕES DE CAMPO: 856 ou 857

A escolha sobre quais subcampos existentes devem ser mantidos ou tornados obsoletos é uma questão em aberto, e de discussão cuidadosa. De forma resumida, descreve-se as três opções de campo, em pauta:

• Opção 1: somente Campo 856: propõe tornar obsoletos os subcampos atuais "não utilizados", para abrir espaço ao acesso completo e uso das informações. A ideia nesta opção é manter um campo 856 simplificado, sem subcampos obsoletos, mas com um novo subcampo para acessar e usar informações.
  
• Opção 2: dois campos: 856 e 857. Nesta opção, define-se um novo campo 857, similar ao campo 856, mas que deve ser usado apenas para URIs de Acesso Aberto. O novo campo transportaria apenas os subcampos do campo 856 que são necessários para adicionar o acesso e uso. A opção mantém intacto o campo 856 e define o novo campo 857, mas com menos subcampos descontinuados. O novo campo 857 conteria subcampo para informações de acesso e uso; sendo usado apenas para URIs de acesso aberto.
  
• Opção 3: somente Campo 857: propõe definir um novo campo 857, e tornar obsoleto o campo 856. Manteria os subcampos atualmente necessários e adicionaria outros novos para o acesso e uso. A opção descontinua o campo 856, mas define o novo campo 857, no qual apenas os subcampos adequados para uso atual são adicionados.
  

CONSIDERAÇÕES

Na leitura das propostas de alterações dos campos e subcampos do formato MARC 21, encontra-se a permanente influência do BIBFRAME (Bibliographic Framework). Assim, a intenção de excluir campos ou subcampos, e de definir apenas elementos relevantes objetiva melhorar o processo de conversão dos registros bibliográficos entre os formatos: MARC e BIBFRAME. Os elementos considerados desnecessários, provavelmente não serão transferidos para o ambiente BIBFRAME. Sob está perspectiva, os bibliotecários da catalogação precisam estar atentos com essas mudanças para ajustarem suas bases bibliográficas estruturadas em MARC, caso busquem migração para o futuro protocolo de codificação de dados.