Bancos de dados para a implementação do RDA: bancos de dados relacionais ou orientados a objeto

O Resource Description and Access (RDA) foi (e está sendo) desenvolvido pelo Joint Steering Committee (JSC). Dentre a documentação utilizada pelo JSC está o documento RDA Database Implementation Scenarios, que descreve três cenários para a implementação do RDA.

Já faz algum tempo que iniciei uma série de posts sobre esses três cenários:

Seguindo o post sobre o Cenário 2, falei um pouco sobre o FRBR e sobre o armazenamento de registros MARC 21. Tendo esses dois textos como background, finalizarei a série abordando neste post o Cenário 1 “Estrutura de banco de dados relacional ou orientado a objeto”.

Pretendo não entrar em detalhes técnicos sobre os bancos de dados relacionais e orientados a objeto. Tentarei mostrar mais ou menos como ficariam os dados registrados com o RDA nesse cenário.

Cenário 1: Estrutura de banco de dados relacional ou orientado a objeto

Assim como acontece no Cenário 2, os registros nos bancos de dados do Cenário 1 estão relacionados de forma explícita, ou seja, existem links entre os registros.

Cenário 1: Estrutura de banco de dados relacional ou orientado a objeto
Cenário 1: Estrutura de banco de dados relacional ou orientado a objeto

As vantagens que os relacionamentos entre os registros trouxeram ao Cenário 2 (facilidade na navegação, na busca e na gestão do catálogo) também estão presentes no Cenário 1.

O diferencial em relação ao Cenário 2 é que os dados que antes estavam divididos entre registros bibliográfico, de autoridade e de item agora estão divididos em registros de obra, expressão, manifestação, item, pessoa, entidade coletiva, etc.

Podemos dizer que há uma quebra na arquitetura do registro bibliográfico atual, sendo que os dados antes presentes em um único registro agora encontram-se distribuídos em diversos registros relacionados entre si (obra-expressão, expressão-manifestação, manifestação-item).

Essa estrutura, associada às tecnologias utilizadas na criação dos bancos de dados, permite fazer com que novos registros (de obra, de expressão, de manifestação, de item) possam ser adicionados fazendo uso dos dados já presentes no banco de dados.

Vamos a um exemplo!

Em sua instituição há um exemplar contendo a 1ª edição em português do livro “Introdução à retórica”. Esse recurso já está catalogado. Hoje você recebeu um exemplar contendo a 2ª edição desse recurso. É necessário catalogar o recurso recém chegado. O que provavelmente você fará:

No cenário 2: Criará um novo registro bibliográfico que, provavelmente, não estará vinculado ao registro bibliográfico representando a edição anterior. Você pode copiar o registro de outro catálogo ou então duplicar o registro e realizar as alterações necessárias. O resultado será: dois registros bibliográficos, cada um vinculado aos seus itens e aos registros de autoridade (nomes e assuntos).

Registros bibliográficos, de itens e de autoridade
Cenário 2: Dois registros bibliográficos, cada um vinculado aos seus itens e aos registros de autoridade.

No cenário 1: Acrescentará um registro de manifestação e o vinculará à expressão em português. Ao registro da manifestação será vinculado o registro do item.

Registros de obra, expressão, manifestação e item
Registros de obra, expressão, manifestação e item.

Diferentemente do Cenário 2, no Cenário 1 não há a necessidade de duplicar certos dados. Você não precisa criar um registro contendo títulos, autores, assuntos, etc. que já estão presentes em outro registro. Essas dados são comuns a todos os itens, manifestações e expressões de uma obra. Assim, se no registro da obra consta que o criador é Olivier Reboul, não é necessário que esse dado conste no registro de cada manifestação dessa obra.

Evitar a duplicação de dados ou de tarefas, no entanto, não é a principal questão que nos leva a pensar em um banco de dados bibliográficos modelado com o FRBR, como o mostrado no Cenário 1.

O conjunto de relacionamentos bibliográficos definido no FRBR e as tecnologias para a construção de bancos de dados podem prover aos usuários dos catálogos maiores possibilidades de navegação entre os dados catalográficos e, portanto, maior capacidade na descoberta de recursos informacionais. Essa sim deve ser uma das principais questões consideradas na modelagem de banco de dados utilizando como base o modelo conceitual FRBR.

Meu catálogo está em qual cenário?

Rotular um banco de dados bibliográficos como pertencente a um cenário não é algo simples, pois não basta observar somente os aspectos tecnológicos (não é porque o seu banco de dados é relacional que ele está no Cenário 1). É possível que o banco de dados possua características que o enquadrem em um determinado cenário, ao mesmo tempo em que outras características o enquadrem em outro.

O banco de dados utilizado no OpenBiblio é um exemplo:

  • Não possibilita registros de autoridade, consequentemente não é possível vincular de forma explícita os registros bibliográficos aos registros de autoridade, por isso pode ser caracterizado como pertencente ao Cenário 3;
  • Possibilita o vínculo entre registros bibliográficos e registros de item, o que o pode caracterizá-lo como pertencente ao Cenário 2;
  • É construído utilizando a tecnologia dos bancos de dados relacionais, o que pode categorizá-lo como pertencente ao Cenário 1.

Assim, além de trazer algumas ideias sobre a implementação do RDA, podemos dizer que os três cenários atuam também como linhas gerais para a análise ou para a modelagem de bancos de dados bibliográficos, independentemente da utilização do RDA ou do FRBR.

Aplicação dos FRBR na modelagem de catálogos bibliográficos digitais

Para saber mais sobre a utilização do FRBR na modelagem de bancos de dados você pode consultar o livro Aplicação dos FRBR na modelagem de catálogos bibliográficos digitais .

Para finalizar este post deixo um pensamento:

Você pode apresentar o catálogo de seus sonhos, com o menor detalhe de sofisticação incluído nos dados e em sua organização, mas, se as pessoas não o utilizarem porque não gostam dele ou porque não entendem seu funcionamento, então seu esforço terá sido bem e verdadeiramente desperdiçado. (Bryant, 1982, p. 3)

Referências

Bryant, P. The library catalogue: key or combination lock? Catalogue & Index, v. 67, p. 1-7, Winter 1982.

Delsey, T. RDA Database Implementation Scenarios. [S.l.]: Joint Steering Committee for Development of RDA, 2009.

Mey, E. S. A. Catalogação e descrição bibliográfica: contribuições a uma teoria. Brasília: ABDF, 1987.

O armazenamento de registros MARC 21 em bancos de dados bibliográficos, ou "Como não utilizamos as tecnologias atuais"

Formatos MARC 21

Em duas postagens anteriores abordei algumas das características das diferentes estruturas dos bancos de dados bibliográficos.

Na primeira postagem, Bancos de dados para implementação do RDA: estrutura “flat file”, abordei as estruturas “flat file” (arquivo simples). Os catálogos baseados em bancos de dados com essa estrutura, em geral, tendem a reproduzir – em ambiente digital – um catálogo em fichas: são armazenados blocos de dados (registros) sem vínculos explícitos (links) entre si.

Na segunda postagem, Bancos de dados para a implementação do RDA: registros bibliográficos e de autoridade vinculados, falei um pouco sobre a estrutura comumente encontrada nos atuais sistemas de gerenciamento de bibliotecas. Nos catálogos de tais sistemas, em geral, são criados links entre registros bibliográficos e registros de autoridade, entre registros de autoridade e entre registros bibliográficos e registros de itens (exemplares): blocos de dados com links entre si.

Esses blocos de dados (registros), com ou sem links entre si, na maior parte dos casos são construídos de acordo com um formato, tal como o MARC 21, o UNIMARC, etc.

Os Formatos MARC 21

Em 1965, Henriette Avram (7 de outubro de 1919 – 22 de abril de 2006) juntou-se ao Office of the Information Systems Specialist da Library of Congress (LC).

Designada para analisar dados catalográficos para determinar sua manipulabilidade por computador, ela mergulhou nos rudimentos da catalogação e rapidamente reconheceu o aspecto mais crucial da automação de bibliotecas: elaborar um meio de transporte padrão para a comunicação de dados bibliográficos. A culminação desses esforços resultou no MARC Pilot Project. (RATHER; WIGGINS, 1989, p. 856).

O MARC Pilot Project foi, então, iniciado no início de 1966 e, em novembro do mesmo ano, passou a operar.

Ao final do projeto piloto, em junho de 1968, a LC havia distribuído em fitas magnéticas aproximadamente 50.000 registros legíveis por máquina. O relatório final do projeto, publicado em 1968, além de apontar os resultados e a experiência das bibliotecas envolvidas no projeto, descrevia o MARC II.

Da década de 1970 aos dias de hoje, diversos foram os formatos criados sobre a base estabelecida por Avram durante o MARC Pilot Project:

Os Formatos MARC 21 atualmente compreendem cinco formatos:

  • MARC 21 Format for Bibliographic Data (Dados Bibliográficos)
  • MARC 21 Format for Authority Data (Dados de Autoridade)
  • MARC 21 Format for Holdings Data (Dados de Coleção)
  • MARC 21 Format for Classification Data (Dados de Classificação)
  • MARC 21 Format for Community Information (Dados de Comunidade).

O registro MARC 21

Este registro bibliográfico no Formato MARC 21 está pronto para ser intercambiado:

00595nam a2200205 a 45  0010010000000080041000100200013000510350016000 640400020000800410013001000820012001131000033001 252450069001582500013002272600048002403000013002 88440003200301500003400333650002200367 000259911 030128s1982    rjb           000 1 por d   a(Broch.)   aCM001775391   aBIBLIODATA bpor 1 apor heng   a823.914 1  aChristie, Agatha, d1890-1976 12 aA casa torta / cAgatha Christie ; tradução de Carmen Ballot. –   a8. ed. –   aRio de Janeiro, RJ : bNova Fronteira, c1982   a238 p. – 1 a(Coleção Agatha Christie)   aTradução de: Crooked house. 4 aFicção inglesa.

(Um registro MARC 21, aquele que você baixa da LC, Bibliodata, etc., é uma única linha contínua, aqui essa linha foi quebrada em várias linhas para possibilitar uma melhor visualização.)

A norma ISO 2709 Documentation – Format for Bibliographic Information Interchange on Magnetic Tape (Documentação – Formato para intercâmbio de informação bibliográfica em fita magnética) é utilizada como base para os Formatos MARC 21, ou seja, a estrutura dessa linha contínua (registro) é definida pela ISO 2709. Vale lembrar que, quando digo estrutura, nesse caso, estou falando das partes do registro (líder, diretório, campos) e não do significado de cada um dos campos e subcampos.

O registro acima, construído sobre “uma estrutura destinada especialmente para comunicações entre sistemas de processamento de dados e não para uso como formato de processamento pelos sistemas” (ISO 2709, p. 1), pode ser exportado em um sistema e importado em outro.

Ao receber o registro, o sistema que fará a importação localizará, por meio da estrutura definida na ISO 2709, o líder, o diretório e os campos dentro do registro. Após a localização das partes do registro será identificado, por meio da marcação dos códigos de campos e subcampos, o que é título, local de publicação, nome do publicador, etc.Este formato (linha contínua) deveria ser apenas o formato para o intercâmbio de registros, pois o MARC 21 é um formato de intercâmbio.

Penso que, em algum momento da história da catalogação dos últimos 50 anos, o MARC deixou de ser utilizado somente como um formato de intercâmbio, passando a ser utilizado também como um formato de armazenamento dos dados catalográficos, como um modelo para a construção (modelagem) de catálogos (bancos de dados) e, em muitos casos, como um condicionador do fazer do catalogador (você segue o MARC 21?).

No decorrer dos anos, em razão dos programas de catalogação centralizada, cooperativa e copiada e de outros fatores, os formatos como o MARC adquiriram uma enorme importância na catalogação e, consequentemente, no desenvolvimento de sistemas de gerenciamento de bibliotecas.

Há algum tempo, houve um momento em que, após a importação de um registro, retirar dele alguns elementos para possibilitar a busca e armazená-lo no banco de dados como um bloco de dados (Figura 1) tornou-se mais fácil que “quebrá-lo” em vários pedacinhos (dados) e armazenar cada um deles separadamente (Figura 2).

Figura 1 - Registros MARC 21 armazenados como "blocos de dados"
Figura 1 – Registros MARC 21 armazenados como “blocos de dados”
Figura 2 - Os dados de um registro armazenados separadamente:
Figura 2 – Os dados de um registro armazenados separadamente:

(As figuras foram feitas apenas para exemplificar o que disse, desse modo, não representam exatamente as tabelas do banco de dados de um sistemas de gerenciamento de bibliotecas.)

Assim, penso que muitos dos atuais sistemas de gerenciamento de bibliotecas têm seus bancos de dados modelados (projetados, planejados, etc.) para armazenar registros nos Formatos MARC 21 como “grandes blocos de dados”.

Por que fazer diferente?

Esses grandes blocos de dados, aliados a outros fatores, fazem com que não sejam exploradas todas as possibilidades de relacionamentos entre os dados que são oferecidas pelas atuais tecnologias.

Em um banco de dados como o apresentado na Figura 1, para cada catalogação de um livro cuja editora é a Nova Fronteira, eu terei “Nova Fronteira” armazenada no banco de dados ao menos duas vezes: uma no registro MARC e outra no campo publicador (utilizado para possibilitar as buscas). Assim, se forem catalogados 200 livros publicados pela editora Nova Fronteira, eu terei “Nova Fronteira” armazenado ao menos 400 vezes no banco de dados.

Já em um banco de dados como o exemplificado na Figura 2, eu terei armazenado apenas um “Nova Fronteira” para cada livro: 200 “Nova Fronteira” ao todo.

Fazendo uso das possibilidades oferecidas pelas tecnologias, eu poderia ter “Nova Fronteira” armazenado uma única vez no banco de dados. Poderia ser criada uma tabela para armazenar os nomes das editoras. Nessa tabela, cada editora receberia um código, Nova Fronteira receberia, por exemplo, “0005”. Assim, cada vez que um livro dessa editora fosse catalogado, no campo “publicador” seria armazenado “0005”. Se um dia eu precisasse alterar o nome dessa editora bastaria acessar a tabela “Editoras” e realizar a modificação uma única vez.

A eliminação de redundâncias no banco de dados é um dos diversos benefícios que uma utilização mais consciente dos padrões (neste caso do MARC) e das tecnologias podem proporcionar aos catálogos.

Neste post tentei apresentar algumas considerações sobre os Formatos MARC 21 e a relação deles com a estrutura dos bancos de dados bibliográficos (catálogos). Um longo e intenso trabalho ainda precisa ser feito até a catalogação alcançar um patamar condizente com a situação tecnológica atual. Felizmente, diversos grupos, principalmente internacionais, já estão empenhados nessa tarefa.

Na próxima postagem (antes do terceiro post da série “Bancos de dados para a implementação do RDA”) falarei um pouco sobre o modelo conceitual FRBR. Esse modelo tem provocado inúmeras discussões no cenário da catalogação descritiva, impactando no modo com que nossas regras de catalogação estão estruturadas, nossos bancos de dados bibliográficos (catálogos) são modelados e, consequentemente, no modo com que transmitimos dados via formatos de intercâmbio.

Referências

ISO 2709

RATHER, Lucia J.; WIGGINS, Beacher. Henriette D. Avram: close-up on the career of a towering figure in library automation and bibliographic control. American Libraries, p. 855-859, oct. 1989.

Livro: Aplicação dos FRBR na modelagem de catálogos bibliográficos digitais

Aplicação dos FRBR na modelagem de catálogos bibliográficos digitais
Aplicação dos FRBR na modelagem de catálogos bibliográficos digitais

Confiram a mais recente publicação nacional na área da catalogação: “Aplicação dos FRBR na modelagem de catálogos bibliográficos digitais”, por Elvis Fusco.

“O livro Aplicação dos FRBR na modelagem de catálogos bibliográficos digitais, de Elvis Fusco, destina-se a alunos e professores das áreas da Ciência da Informação e Ciência da Computação que investigam a modelagem e a construção de catálogos bibliográficos e também para os profissionais que trabalham com ambientes informacionais digitais.

O trabalho apresenta, sob a premissa de que a catalogação, nos últimos anos, tem experimentado mudanças em suas práticas e teorias, afetadas pelas tecnologias de informação, um arcabouço conceitual cuja principal proposta é o entrelaçamento da modelagem com os Requisitos Funcionais para os Registros Bibliográficos (FBRB).

A concepção do FRBR é de um modelo lógico orientado para o objeto, e para a identificação de entidades e relacionamentos visando sua projeção em banco de dados. Segundo o autor, a entidade pode ser concreta ou abstrata e seus atributos referem-se às diversas características que ela possui, ou às propriedades descritivas de cada membro de um conjunto de entidades. Já o relacionamento é a associação entre uma ou várias entidades.”

Essa é mais uma publicação da Coleção digital da Pró-reitoria de Pós-Graduação da UNESP.

A edição digital do livro pode ser baixada gratuitamente em culturaacademica.com.br/catalogo-detalhe.asp?ctl_id=168.

Bancos de dados para a implementação do RDA: registros bibliográficos e de autoridade vinculados

Na postagem anterior, Bancos de dados para implementação do RDA: estrutura “flat file”, abordei o Cenário 3 de implementação do RDA. Falarei hoje sobre o Cenário 2: registros bibliográficos e de autoridade vinculados.

O Resource Description and Access (RDA) foi (e está sendo) desenvolvido pelo Joint Steering Committee (JSC). Dentre a documentação utilizada pelo JSC está o documento “RDA Database Implementation Scenarios“, de autoria de Tom Delsey.

Os cenários descritos nesse documento têm como objetivo apenas ilustrar algumas das potenciais implementações dos dados criados com o RDA em diversas estruturas de bancos de dados.

O documento descreve três cenários:

  • Cenário 1: Estrutura de banco de dados relacional ou orientado a objeto (Relational / object-oriented database structure)
  • Cenário 2: Registros bibliográficos e de autoridade vinculados (Linked bibliographic and authority records)
  • Cenário 3: Estrutura de banco de dados “flat file” (sem vínculos) (‘Flat file’ database structure (no links))

O principal motivo pelo qual decidi por abordar esses três cenários aqui no blog está na oportunidade de melhor conhecermos as estruturas dos catálogos (antigos, atuais e futuros) e refletirmos sobre as mesmas.

Ressalto que é de extrema importância que o catalogador conheça as estruturas dos catálogos (ao menos a do catálogo com que ele trabalha), pois essas estruturas estão relacionadas à própria catalogação, às vezes condicionam a atividade do catalogador e, certamente, influem sobre a relação usuário-catálogo, mais precisamente, no modo com que o usuário recupera a informação por meio das possibilidades de busca e de navegação.

Na postagem anterior abordei o Cenário 3. Hoje falarei sobre o Cenário 2.

Cenário 2: Registros bibliográficos e de autoridade vinculados

A estrutura dos bancos de dados do Cenário 2 é comumente utilizada pelos atuais sistemas de gerenciamento de bibliotecas. A principal diferença entre os bancos de dados desse cenário e os do Cenário 3 é que os desse cenário (2) possuem links entre registros bibliográficos e de autoridade, entre registros de autoridade e entre registros bibliográficos e registros de itens.

Os links entre registros bibliográficos e de autoridade apresentam grandes vantagens, tanto para o usuário não-catalogador (usuário final) quanto para o usuário catalogador. Ao usuário não-catalogador, os benefícios se concentram, dentre outros, na possibilidade de “clicar” sobre o nome de um autor ou assunto e obter como resultado os registros bibliográficos aos quais tal autor ou assunto está relacionado.

Outro benefício ao usuário não-catalogador, é a possibilidade de consultar o arquivo de autoridade para tomar conhecimento do nome ou termo adotado pela instituição para representar um autor, um conceito, etc.

Além dessa consulta direta, o usuário pode utilizar o arquivo de autoridade sem ter consciência da existência dele. Isso ocorre quando o sistema, após o usuário “clicar em buscar”, analisa a expressão de busca, confrontando-a com os pontos de acesso (autorizados e remissivas) do arquivo de autoridade com o objetivo de identificar quais são as entidades buscadas pelo usuário e, assim, recuperar todos os registros associados a tais entidades.

As pesquisas, descobertas, teorias, etc. dão origem a novos conhecimentos. Assim como surgem novos conceitos, surgem também novos termos para representar conceitos já existentes, de modo que a terminologia de uma determinada área do conhecimento encontra-se em processo de modificação constante. Esse é um bom ponto para explicar as vantagens que os bancos de dados do Cenário 2 oferecem aos catalogadores. Suponha que a linguagem utilizada pelo usuário de sua instituição sofreu uma série de alterações ao longo do tempo: ele passou a referir-se a conceitos antigos utilizando novos termos. Assim, para ficarem em sintonia com a linguagem do usuário, os pontos de acesso de seu arquivo de autoridade de assunto precisam também sofrer modificações. E os registros bibliográficos que foram criados utilizando os termos antigos, o que fazer com eles?

Se o seu sistema for um catálogo de fichas (ou for digital e estiver simulando um catálogo de fichas) você provavelmente terá várias opções, uma delas será alterar todas as fichas nas quais os pontos de acesso antigos aparecem, substituindo esses antigos pelos novos. Se o seu sistema cria links entre os registros bibliográficos e os de autoridade, muito provavelmente você terá que fazer as modificações em apenas um lugar: no registro de autoridade. Por estarem vinculados (“linkados“) ao registro de autoridade, todos os registros bibliográficos serão atualizados automaticamente, sem que seja necessário ao catalogar editar registro por registro.

Um sistema de gerenciamento de biblioteca que cria links entre os registros (e que conheço como usuário catalogador) é o Koha. Como usuário não-catalogador conheço outros que penso que também criam tais vínculos, como é o caso  do Aleph, do Pergamum e do Voyager.

Links entre registros de autoridade

Em um arquivo de autoridade podem existir links entre registros de autoridade, os quais resultam das remissivas “ver também”. Essas remissivas vinculam um registro de autoridade ao registro de autoridade de uma entidade relacionada, por exemplo, o registro de autoridade representando um autor a um registro de autoridade representando seu pseudônimo. Um sistema de gerenciamento de bibliotecas que possibilita a criação de links entre registros de autoridade é o Koha.

Links entre registros bibliográficos e registros de item

Além de estabelecerem links entre registros bibliográficos e de autoridade, os bancos de dados do Cenário 2 possibilitam também links entre registros bibliográficos e registros de itens (exemplares, holdings): a instituição pode possuir cinco exemplares de uma mesma edição de um livro, assim, para que não seja necessário criar cinco registros bibliográficos, são criados cincos registros de item, cada um contendo informações específicas de cada item e vinculado a um registro bibliográfico.

Dentre os dados registrados em um registro de item está seu número de tombo, código de barras, modalidade de aquisição, valor de aquisição, etc., o que faz com que tais registros possam atuar como substitutos aos “livros de tombo”.

Os vínculos entre registros bibliográficos e registros de item são muito mais comuns nos sistemas de gerenciamento de bibliotecas do que os links entre registros bibliográficos e de autoridade. Alguns sistemas, o OpenBiblio, por exemplo, possibilita a criação de links “bibliográfico-item”, ao passo que não comportam os vínculos entre registros bibliográficos e de autoridade.

Muitos dos atuais sistemas de gerenciamento de bibliotecas do Cenário 2 têm seus bancos de dados modelados para armazenar registros nos Formatos MARC 21. Assim, muitas vezes, esses registros são armazenados como “grandes blocos de dados”, o que, de certo modo, faz com que não sejam exploradas todas as possibilidades de relacionamento existentes entre tais registros.

Em 1998, foi publicado o Functional Requirements for Bibliographic Records (FRBR), um modelo conceitual que tem provocado inúmeras discussões no cenário da catalogação descritiva, impactando no modo com que nossas regras de catalogação estão estruturadas, nossos bancos de dados bibliográficos (catálogos) são modelados e, consequentemente, no modo com que transmitimos dados (bibliográficos e de autoridade) via formatos de intercâmbio.

Assim, diante do FRBR, tornou-se necessário também refletir sobre como conduzimos a catalogação nas últimas décadas frente aos avanços das Tecnologias de Informação e Comunicação (TIC). “O que é FRBR?” e “Como estão nossos dados?” são questões que pretendo abordar nas próximas postagens, antes mesmo de seguirmos para os bancos de dados do Cenário 1.

___________

Obrigado ao Marcelo Votto da Universidade de Caxias do Sul e do blog Processo Técnico BICE/UCS pelos prints screen do catálogo do Sistema de Bibliotecas da UCS.

Referências

DELSEY, T. RDA Database Implementation Scenarios. [S.l.]: Joint Steering Committee for Development of RDA, 2009.

Imagens utilizadas: Oxygen Icons by Oxygen Team e catálogo do Sistema de Bibliotecas da UCS.

Bancos de dados para implementação do RDA: estrutura "flat file"

O Resource Description and Access (RDA) foi (e está sendo) desenvolvido pelo Joint Steering Committee (JSC). Dentre a documentação utilizada pelo JSC está o documento “RDA Database Implementation Scenarios“, de autoria de Tom Delsey.

Os cenários descritos nesse documento têm como objetivo apenas ilustrar algumas das potenciais implementações dos dados criados com o RDA em diversas estruturas de bancos de dados.

O documento descreve três cenários:

  • Cenário 1: Estrutura de banco de dados relacional ou orientado a objeto (Relational / object-oriented database structure)
  • Cenário 2: Registros bibliográficos e de autoridade vinculados (Linked bibliographic and authority records)
  • Cenário 3: Estrutura de banco de dados “flat file” (sem vínculos) (‘Flat file’ database structure (no links))

O principal motivo pelo qual decidi por abordar esses três cenários aqui no blog está na oportunidade de melhor conhecermos as estruturas dos catálogos (antigos, atuais e futuros) e refletirmos sobre as mesmas.

Ressalto que é de extrema importância que o catalogador conheça as estruturas dos catálogos (ao menos a do catálogo com que ele trabalha), pois essas estruturas estão relacionadas à própria catalogação, às vezes condicionam a atividade do catalogador e, certamente, influem sobre a relação usuário-catálogo, mais precisamente, no modo com que o usuário recupera a informação por meio das possibilidades de busca e de navegação.

Para tornar a explicação dos três cenários mais compreensível e esclarecedora, dedicarei três postagens ao tema, começando hoje pelo Cenário 3, o qual entendo como o mais simples.

Cenário 3: Estrutura de banco de dados “flat file” (sem vínculos)

O Cenário 3, embora seja encontrado também em catálogos digitais, ilustra uma estrutura a muito tempo conhecida na catalogação: a dos catálogos de fichas. Para compreender esse cenário, retomaremos um pouco a estrutura desses catálogos.

De modo geral, cada ficha (ou mais de uma, caso a descrição exceda os 7,5 x 12,5 cm) contém a descrição bibliográfica de um recurso informacional e um ponto de acesso autorizado (cabeçalho) que permite à descrição ser encontrada no catálogo.

Em um catálogo de fichas, as fichas representando dois ou mais recursos informacionais associados a uma mesma pessoa, entidade coletiva, conceito, etc. (dois livros escritos por um mesmo autor, por exemplo) serão dispostas (arquivadas) de forma subsequente, seguindo uma alfabetação.

Nesse caso, por mais que as fichas estejam próximas, não há qualquer vínculo explícito entre elas, cabendo ao usuário a tarefa de notar a semelhança existente. Assim, cabe ao usuário traçar conscientemente ou inconscientemente o relacionamento existente entre os recursos.

Se o usuário tem à disposição um arquivo de autoridade como um instrumento de apoio à utilização do catálogo, ele pode checar em tal arquivo qual o ponto de acesso adotado pela instituição para uma determinada pessoa, entidade coletiva, conceito, etc.

Se o arquivo de autoridade está construído sobre a tecnologia da ficha catalográfica (sim, a ficha catalográfica é uma tecnologia!) não há vínculos explícitos entre um ponto de acesso autorizado do arquivo de autoridade e as fichas do catálogo, cabendo novamente ao usuário a tarefa de traçar os relacionamentos.

As remissivas “ver” e “ver também”, se inseridas no catálogo ou no arquivo de autoridade, atuam de forma semelhante: indicam vínculos não explícitos.

Deixar ao usuário a tarefa de traçar o relacionamento existente entre duas ou mais fichas catalográficas parece-me que foi a solução mais adequada dentre as existentes no contexto tecnológico da criação dos catálogos de fichas.

Para entender a estrutura do banco de dados do Cenário 3 basta transpor um catálogo de fichas para o ambiente digital, com alguns “ajustes terminológicos”, claro. No ambiente digital, chamaremos as fichas catalográficas de “registros bibliográficos“, os vínculos explícitos de “links” e o catálogo de “banco de dados“. Dessa forma, os bancos de dados do Cenário 3 contêm registros sem links entre si.

Tradução de Delsey (2009, p. 5)*

No Cenário 3 não há links entre registros bibliográficos e de autoridade, nem entre os registros de autoridade. Os registros são dispostos em uma mera listagem, assim como as fichas são ordenadas em uma gaveta. Nesse Cenário, o arquivo de autoridade pode estar em outro banco de dados, em outro armário (no caso da utilização de fichas) ou ser uma lista impressa de cabeçalhos de assunto.

No ambiente digital, os links entre os registros podem oferecer algumas vantagens, como veremos nos cenários 1 e 2. A não utilização desses links, como ocorre no Cenário 3, apresenta algumas desvantagens, dentre elas o fato de que, caso seja necessário atualizar um ponto de acesso autorizado (inserir uma data de nascimento ou de morte de um autor ou alterar o termo escolhido para representar um conceito, por exemplo) será necessário atualizar todos os registros bibliográficos em que o referido ponto de acesso autorizado está registrado, o que pode demandar muito tempo e esforço.

O fato dos bancos de dados do Cenário 3 não apresentarem links (relacionamentos) entre os registros faz com que sejam chamados de “flat file databases” (bancos de dados de arquivo simples). Os bancos de dados que estabelecem links entre registros bibliográficos e de autoridade estão enquadrados no Cenário 2, o qual será abordado em uma postagem futura.

______________

* Os atributos indicados com asterisco (*) são definidos no RDA como “core elements” (elementos essenciais). É recomendado que tais elementos seja registrados se forem aplicáveis a entidade que está sendo descrita.

Os registros de autoridade de nome-título são utilizados para pontos de acesso de representando obras e expressões.

Referências

BURGER, R. H. Authority work: the creation, use, maintenance, and evaluation of authority records and files. Littleton: Libraries Unlimited, 1985.

DELSEY, T. RDA Database Implementation Scenarios. [S.l.]: Joint Steering Committee for Development of RDA, 2009.

JIMÉNEZ PELAYO, J.; GARCÍA BLANCO, R. El catálogo de autoridades: creación y gestión en unidades documentales. Gijón: Trea, 2002.

Imagem utilizada para a ficha catalográfica: “Found” por idogcow.