Quando usar Dublin Core para descrever um recurso decide-o o trabalho que o registo tem de fazer, não o modelo. De todos os formatos que um catalogador maneja, o Dublin Core é o que menos pede. Quinze elementos —título, criador, matéria, descrição, editor, colaborador, data, tipo, formato, identificador, fonte, língua, relação, cobertura e direitos— e nenhum obrigatório. Essa economia não é um descuido: o Dublin Core nasceu para que recursos descritos por gente distinta, em sistemas distintos, pudessem encontrar-se e entender-se. A descrição fina deixa-se para o formato que corresponder; o comum denominador mantém-se deliberadamente curto.
Para que serve um formato simples
O caso em que o Dublin Core rende é o do intercâmbio. Um repositório institucional que expõe os seus registos para que outros os colham —via OAI-PMH, por exemplo— precisa de um formato que qualquer agregador entenda sem acordos prévios. Aí quinze elementos bastam e a simplicidade é a virtude: não há regras de subcampo a interpretar nem perfis locais a negociar.
Serve também como camada de descoberta sobre coleções heterogéneas. Se um acervo mistura documentos, imagens, dados e objetos de natureza distinta, um esquema comum permite listá-los e pesquisá-los em conjunto embora cada tipo, em separado, mereça uma descrição mais rica no seu próprio formato. O Dublin Core é então a vista partilhada, não o registo definitivo de cada peça.
Quando quinze elementos ficam curtos
O limite aparece quando a instituição precisa de exprimir algo que os
quinze elementos não distinguem. «Data» não separa a data de criação da de
publicação ou da de digitalização. «Relação» agrupa sob uma só etiqueta
vínculos que podem ser «é parte de», «é versão de» ou «substitui». Para
esses casos existe a versão alargada, os DCMI Metadata Terms: um
vocabulário mais amplo que refina os quinze elementos originais
—created, issued, isPartOf, hasVersion, spatial, temporal,
entre outros— sem abandonar o quadro do Dublin Core.
A extensão resolve a ambiguidade sem obrigar a saltar para um formato pesado. A decisão prática é identificar que distinções a instituição precisa de verdade antes de configurar o esquema, e acrescentar só esses termos. Um registo com três refinamentos bem usados comunica mais do que um que declara doze e preenche metade por inércia.
Quando convém outro formato
Escolher Dublin Core para o trabalho errado custa mais do que não o ter escolhido.
Para descrição bibliográfica fina —controlo de autoridades, pontos de
acesso, número de classificação, menção de responsabilidade estruturada—
existe o MARC21. O Dublin Core pode levar um
autor no elemento creator, mas não distingue autor de compilador de
tradutor com a precisão que um catálogo de biblioteca dá por assumida.
Como se produz esse registo está em Como gerar registos MARC21 e UNIMARC
com IA.
Para descrição arquivística —onde importam a proveniência, o contexto de produção e a hierarquia de fundo, secção e série— o formato indicado é o ISAD-G. O Dublin Core descreve o item isolado; não tem forma nativa de exprimir que um documento é uma peça dentro de uma série dentro de um fundo. Essa descrição está em Como descrever um arquivo em ISAD-G com IA.
O Dublin Core não compete com esses formatos: cobre um troço distinto. Serve para a descoberta ampla e o intercâmbio entre sistemas; não substitui o registo pormenorizado que cada tipo de acervo precisa por dentro. Muitas instituições usam os dois níveis ao mesmo tempo —MARC ou ISAD-G como registo completo, Dublin Core como a vista que se partilha para fora— e essa convivência é o uso mais comum.
Como o produz o Collect
O Janium Collect gera Dublin Core, na forma simples e na alargada, a partir do mesmo fluxo com que produz os outros formatos: lê o documento, propõe o registo e entrega-o para revisão. Dois cuidados são próprios deste trabalho.
O primeiro é a proteção de campos. Os valores que não devem alterar-se —identificadores, datas, nomes próprios— transferem-se; a leitura do documento não os reescreve. Um identificador que muda é uma ligação quebrada, e num formato pensado para o intercâmbio esse dano propaga-se a cada sistema que colheu o registo.
O segundo é a tradução seletiva do vocabulário descritivo. Quando o material está noutra língua, traduz-se o conteúdo descritivo —a matéria, a descrição, o tipo— enquanto o título original, os nomes e os dados de controlo se conservam tal qual. O objetivo é que o registo seja legível na língua da instituição sem falsear o que diz a fonte.
Nenhum desses dois passos converte o Dublin Core no que não é. Continua a ser um formato simples, e essa é a razão para o usar quando o trabalho pede um comum denominador interoperável. Quando pede descrição bibliográfica ou arquivística fina, o formato correcto é outro, e o Collect também o produz.
Limites
O Collect não decide pela instituição se o catálogo de trabalho é Dublin Core, MARC ou ISAD-G. Essa escolha fixa-a o uso: intercâmbio e descoberta, ou descrição fina. A versão alargada acrescenta distinções; não converte quinze elementos num formato bibliográfico.
O modelo de linguagem completa o registo com o que a fonte não trazia quando o pode sustentar, e deixa marcado o inferido: um dado inferido não se apresenta como verificado, e o que não se pode sustentar não se preenche para cumprir o esquema. A simplicidade do Dublin Core não é motivo para saltar essa marca.
Para continuar a conversa
Se a tua instituição expõe os seus registos para que outros os colham, ou mantém uma vista de descoberta sobre coleções de natureza distinta, e estás a decidir onde usar Dublin Core e onde convém um formato mais pormenorizado, escreve-nos para info@janium.com. Interessa-nos perceber como descreves o teu acervo hoje e o que precisas de intercambiar.