DRIVER Guidelines v2 Final PT

Digital Repository Infrastructure Vision for European Research
Directrizes DRIVER 2.0

Directrizes para fornecedores de conteúdos -
Exposição de recursos textuais com o
protocolo OAI-PMH
[Novembro 2008]
[Directrizes para gestores e administradores de repositórios sobre como expor recursos

científicos digitais utilizado o protocolo OAI-PMH e metadados Dublin Core, criando
interoperabilidade através da homogeneização das saídas (output) dos repositórios.]
Versão portuguesa Serviços Documentação da Universidade do Minho (Abril 2009)

Directrizes DRIVER 2.0 Introdução
Resumo
Para a comunicação em geral, é importante que a pessoa B seja capaz de

compreender o que a pessoa A está a dizer. Para este entendimento mútuo é
necessária uma base comum, um léxico básico com o conhecimento do significado das
coisas. A partir desse ponto pode-se começar a raciocinar. Para apoiar a comunicação
científica com a utilização de repositórios, os repositórios deverão falar a mesma
língua e é portanto essencial criar uma base comum.
Em termos técnicos, criamos uma base comum promovendo a "interoperabilidade". A

Interoperabilidade pode ser gerida em diferentes camadas. Nas Directrizes DRIVER
tentamos basicamente alcançar a interoperabilidade em duas camadas, sintáctica
(Utilização do OAI-PMH e Uso de OAI_DC) e semântica (Utilização de vocabulários).
2/144 estado: final 2008-11-13

Índice de Conteúdos
Introdução ................................................................... 8
Agradecimentos e Colaboradores (versão 1.0) .............................................. 8
Agradecimentos e Colaboradores (versão 2.0) .............................................. 8
Editores ........................................................................................ 8
Peritos e Revisores ........................................................................... 8
Sobre o DRIVER .................................................................................. 9
O que é o DRIVER............................................................................. 9
DRIVER como infra-estrutura de dados...................................................10
O espaço de informação actual do DRIVER ..............................................10
Desafios..........................................................................................10
O que esperam os investigadores .........................................................10
O desafio do texto integral ................................................................11
O que se segue? .............................................................................11
Sobre as Directrizes DRIVER ..................................................................12
Porquê utilizar as Directrizes DRIVER? ...................................................12
Como cumprir as Directrizes DRIVER? (validação) ......................................12
E se não cumprir? ...........................................................................12
Existe suporte? ..............................................................................13
Âmbito das Directrizes DRIVER ............................................................13
Mais Recursos ................................................................................16
Esboço – Sumário das Directrizes DRIVER ...................................................18
PARTE A – Recursos Textuais ..............................................................18
PARTE B - Metadados .......................................................................19
PARTE C – Implementação OAI-PMH ......................................................20
O que é novo .............................................................. 22
Capítulo 1: Uso do OAI-PMH ..................................................................22
Atribuição de nome ao conjunto DRIVER ................................................22
Tamanho do lote de recolha ...............................................................23
Testemunho de reatamento (resumption token) .......................................23
3/144 estado: final 2008-11-13

Estratégia de registos eliminados .........................................................23

Capítulo 2: Uso de metadados OAI_DC ......................................................24
Identifier (Identificador) ...................................................................24
Date (Data) ...................................................................................24
Rights (Direitos) .............................................................................25
Language (Idioma) ..........................................................................25
Ver: ...........................................................................................25
Creator (Autor) ..............................................................................25
Source (Fonte) ...............................................................................26
Type (Tipo) ...................................................................................27
Format (Formato) ...........................................................................28
Capítulo 3: Utilização das práticas recomendadas para OAI_DC ........................28
Mapeamento tipos DRIVER .................................................................28
Mapeamento versões DRIVER ..............................................................28
Utilização de OAI_DC com teses ..........................................................29
DC:SOURCE e DC:RELATION ................................................................29
Capítulo 4: Uso de empacotamento de objecto composto ...............................29
Capítulo 5: Uso de vocabulários e semânticas .............................................33
Capítulo 6: Anexo: Uso de etiquetas de qualidade ........................................34
Capítulo 7: Anexo: Uso de identificadores persistentes ..................................34
Capítulo 8: Anexo: Intercâmbio de estatísticas de utilização ...........................35
Capítulo 9: Anexo: Uso de direitos de propriedade intelectual .........................35
Uso do protocolo OAI-PMH .............................................. 37
Introdução.......................................................................................37
Nota: ..........................................................................................37
Agradecimentos .............................................................................37
Fonte de informação........................................................................38
Definições e conceitos: item, registo e identificador único .............................38
Item e Registo ...............................................................................38
Identificador (identifier) ...................................................................39
Nomenclatura de prefixos de metadados (MetadataPrefix naming) ....................39
Documento DIDL .............................................................................40
4/144 estado: final 2008-11-13

Data de registo (Datestamp) .................................................................40

Sintaxe da data de registo ....................................................................41
Registos eliminados ............................................................................42
Testemunho de reatamento (Resumption token) .........................................43
Tamanho do lote de recolha..................................................................45
Atribuição de nome ao conjunto DRIVER ...................................................45
Definições do conteúdo do conjunto DRIVER...............................................46
Localização do conjunto (set) ................................................................47
Correio electrónico do administrador para feedback de erros ..........................47
Declaração de prefixo e espaço de nomes .................................................50
Validação XML ..................................................................................52
Comunicação para modificação nos repositórios ..........................................54
Uso de metadados OAI_DC .............................................. 55
Agradecimentos ................................................................................55
Definições .......................................................................................56
Notas introdutórias ............................................................................56
Âmbito ........................................................................................56
Requisitos mínimos .........................................................................57
Recomendações .............................................................................57
Os elementos: descrição abreviada .........................................................60
DC não qualificado: oai_dc ................................................................60
Os elementos: descrição completa ..........................................................62
Title (Título) .................................................................................62
Creator (Autor) ..............................................................................63
Subject (Assunto) ...........................................................................65
Description (Descrição).....................................................................67
Publisher (Editor) ...........................................................................68
Contributor (Colaborador) .................................................................69
Date (Data) ...................................................................................70
Type (Tipo) ...................................................................................72
Format (Formato) ...........................................................................75
Identifier (Identificador) ...................................................................77
5/144 estado: final 2008-11-13

Source (Fonte) ...............................................................................79

Language (Idioma) ..........................................................................80
Relation (Relação) ..........................................................................81
Coverage (Cobertura).......................................................................82
Rights (Direitos) .............................................................................83
Audience (Público) ..........................................................................85
Uso das práticas recomendadas com OAI_DC ....................... 87
Mapeamento de tipos DRIVER ................................................................87
Mapeamento de tipos DRIVER v1.1 para tipos DRIVER v2.0 ...........................88
Mapeamento de vocabulário de tipos E-Print para tipos DRIVER v2.0 ...............88
Mapeamento de versões DRIVER .............................................................90
Mapeamento de tipos de versões Eprints para tipos de versão DRIVER v2.0 .......90
Termos comuns de tipo de versões para tipos de versões DRIVER v2.0 .............90
Mapeamento dos tipos de versões do grupo de trabalho técnico Journal Article
Versions (JAV) para os tipos de versões das Directrizes DRIVER v2.0 ...............91
Uso do OAI_DC com teses .....................................................................92
Exemplo ......................................................................................93
DC:SOURCE e informação de citação ........................................................94
DC:RELATION e hiperligação de objectos relacionados ...................................94
Uso de MPEG-21 DIDL (xml-container) – Empacotamento do
objecto composto ........................................................ 96
Introdução e Objectivo ........................................................................96
Contextualização ...............................................................................97
Resposta OAI com um documento DIDL .....................................................97
DIDL como invólucro ou empacotador (wrapper) ..........................................99
Elemento raiz: documento DIDL atributo de identificação ...........................99
Descritores de item (opcional) .......................................................... 100
Declaração Descriptor: Item 'Identifier'................................................ 101
Declaração Descriptor: Item 'modified' ................................................ 102
Declaração Descriptor: Item „ObjectType‟ ............................................ 103
Elemento composto: representação do trabalho complexo......................... 104
Tipo de objecto (objectType): Item de metadados .................................. 106
6/144 estado: final 2008-11-13

Tipo objecto (objectType): Item objecto ............................................. 108

Tipo de objecto (objectType): Página de transição (Jump-off-page Item) ....... 110
Exemplo de um DIDL embutido em OAI-PMH ............................................. 111
Uso de vocabulários e semânticas .................................... 117
info:eu-repo – Um espaço de nomes para URI-fying esquemas e identificadores un-
URIfied......................................................................................... 117
Identificação de autor ....................................................................... 117
Formato de um DAI ....................................................................... 118
Persistência de um DAI ................................................................... 118
Classificação de assuntos ................................................................... 119
Vocabulário tipo de publicações ........................................................... 121
Vocabulário de versões ...................................................................... 126
Esquemas de codificação ................................................................... 127
Anexos: Futuros pontos de interesse ................................ 129
Anexo: Uso de etiquetas de qualidade .............................. 130
Anexo: Uso de identificadores persistentes ........................ 131
Plano de implementação para uso de identificadores persistentes URN:NBN .... 134
Anexo: Intercâmbio de estatísticas de utilização ................. 137
PIRUS: Publisher and Institutional Repository Usage Statistics ........................ 137
OA-Statistik ................................................................................... 138
Resultados preliminares do projecto OA-Statistik ....................................... 138
Objectivos de estatísticas OA ........................................................... 138
Informação necessária para gerar COUNTER, LogEc e IFABC ....................... 139
Informação adicional em conformidade com OpenURL Context Objects ......... 140
Sugestões adicionais ...................................................................... 140
Tabela de padrões de utilização Web .................................................. 141
Uso de direitos de propriedade intelectual ........................ 143
7/144 estado: final 2008-11-13

Introdução
Agradecimentos e Colaboradores (versão 1.0)
Martin Feijen, Maurice Vanderfeesten, Wolfram Horstmann, Friedrich Summann, Muriel

Foulonneau, Karen Van Godtsenhoven, Patrick Hochstenbach, Paolo Manghi, Bill
Hubbard.
Agradecimentos e Colaboradores (versão 2.0)
A criação das Directrizes DRIVER 2.0 contou com a experiência de muitas pessoas.
Todas essas pessoas são especialistas e gestores de repositórios. Este grupo tem
trabalhado em conjunto para conseguir a interoperabilidade para que possa ser
aplicada na prática. Neste contexto, as pessoas referidas em seguida, aprovam e
apoiam as Directrizes DRIVER 2.0.
Editores
 Maurice Vanderfeesten, (SURFfoundation, Países Baixos)

 Friedrich Summann, (University Bielefeld, Alemanha)
 Martin Slabbertje, (Utrecht University, Países Baixos)
Peritos e Revisores
 Stefania Biagioni, (CNR, Itália)

 Paolo Manghi, (CNR, Itália)
 Maria Bruna Baldacci, (CNR, Itália)
 Friedrich Summann, (University Bielefeld, Alemanha)
 Martin Slabbertje, (Utrecht University, Países Baixos)
 Thomas Place, (Tilburg University, Países Baixos)
 Benoit Pauwels, (Universite Libre de Bruxelles, Bélgica)
8/144 estado: final 2008-11-13

 Patrick Hochstenbach, (Ghent University, Bélgica)

 Karen van Godtsenhoven, (Ghent University, Bélgica)
 Niamh Brennan, (Trinity College Dublin, Irlanda)
 Phil Cross, (Intute and the Intute Repository Search project, Reino Unido)
 Mikael Karstensen Elbæk, (Danish Technical University (DTU), Dinamarca)
 Maurice Vanderfeesten, (SURFfoundation, Países Baixos)
 Susanne Dobratz, (Humbolt University, Berlin, Alemanha)
 Frank Scholze, (Stuttgart University Library, Alemanha)
 Wolfram Horstmann, (University Bielefeld, Alemanha)
 Barbara Levergood, (University Goettingen, CACAO project)
 Eloy Rodrigues, (Universidade do Minho, Portugal)
 Arjan Hoogenaar, (KNAW, Países Baixos)
 Armand Guicherit, (KNAW, Países Baixos)
 Ruud Bronmans, (KNAW, Países Baixos)
 Jos Odekerken, (University of Maastricht, Países Baixos)
 Alenka Kavcic-Colic, (Library Research Centre at National and University
Library, Eslovénia)
 Myriam Bastin, (University of Luik, Bélgica)
 Birgit Schmidt, (University of Goettingen, Alemanha)
Sobre o DRIVER
O que é o DRIVER
O DRIVER, “Digital Repository Infrastructure Vision for European Research”, é um

projecto dinamizado por um consórcio financiado pela União Europeia (UE) e que visa
a constituição de uma estrutura organizacional e tecnológica para implementar uma
camada de dados pan-europeia que permita o uso avançado de recursos de conteúdos
na área da investigação no ensino superior. O DRIVER desenvolve uma infra-estrutura
de serviços e uma infra-estrutura de dados. Ambas estão concebidas para instrumentar
os recursos e serviços existentes na rede de repositórios.
9/144 estado: final 2008-11-13

DRIVER como infra-estrutura de dados
A infra-estrutura de dados baseia-se em recursos alojados localmente, como

publicações científicas recolhidas em repositórios digitais de instituições e organismos
de investigação. Estes recursos serão recolhidos pelo DRIVER e agregados à escala
europeia. Para poder garantir uma elevada qualidade da agregação, o DRIVER
fornecerá os meios possíveis para a harmonizar e validar. O DRIVER respeitará a
proveniência dos recursos mediante a sua “marcação” com informação do repositório
local. Adicionalmente, quando um recurso for descarregado, o DRIVER irá remeter
para o repositório local ao invés de o fornecer directamente. Os dados do DRIVER
estarão disponíveis para reutilização via Open Archives Initiative Protocol for Metadata
Harvesting (OAI-PMH) por todos os parceiros da rede DRIVER de fornecedores de
conteúdos.
O espaço de informação actual do DRIVER
A fase inicial do DRIVER criou os pilares para uma rica e ambiciosa infra-estrutura pan-
europeia de repositórios. A paisagem dos repositórios digitais é multifacetada no que
concerne aos diferentes países, aos diferentes tipos de recursos como texto, dados ou
multimédia, às diferentes plataformas tecnológicas, às diferentes políticas de
metadados, etc. No entanto, existem bases comuns que se aplicam a grande parte
deste espectro: o tipo de recurso mais comum nos repositórios digitais é o texto e a
principal forma de oferecer estes recursos textuais é o protocolo OAI-PMH. Por esse
motivo, a fase actual do DRIVER centra-se nos recursos textuais que podem ser
recolhidos através do protocolo OAI-PMH.
Desafios
O que esperam os investigadores
Os investigadores e outros actuais utilizadores de sistemas de informação possuem

expectativas bastante elevadas relativamente ao fornecimento de conteúdos digitais.
A recuperação deve ser rápida, directa (acessível com poucos cliques) e versátil. A
10/144 estado: final 2008-11-13

cultura actual no panorama dos repositórios digitais não suporta completamente estas
expectativas. Embora muitos serviços de valor acrescentado tenham sido
implementados para pesquisar e recuperar registos bibliográficos (metadados), o
recurso em si mesmo é, por vezes, ocultado por detrás de várias páginas intermédias,
obscurecido por procedimentos de autorização, apresentado de forma incompleta ou
totalmente irrecuperável. No entanto, para conseguir uma comunicação científica
óptima seria necessário que o recurso fosse obtido com apenas um clique do rato.
Adicionalmente, uma recuperação simples do texto integral e dos metadados facilita o
tratamento automático do conteúdo. Nem o registo bibliográfico recolhido nem o
texto completo recuperado em separado - apenas a combinação de ambos - permitem
o desenvolvimento de serviços avançados e integrados, como a pesquisa por assuntos
combinada com a navegação através de classificações, análise de citações, etc.
O desafio do texto integral
Favorecer o acesso directo a recursos textuais foi identificado como um grande desafio
na fase de testes do DRIVER. Embora o consórcio DRIVER dedique todos os esforços
possíveis para abordar este desafio do ponto de vista tecnológico através do
processamento de dados agregados, os detentores de repositórios digitais podem
apoiar localmente o DRIVER através do fornecimento de conteúdos de uma forma
específica. As Directrizes DRIVER aqui apresentadas irão facultar orientações para que
os fornecedores de conteúdos locais saibam como disponibilizar os seus conteúdos.
O que se segue?
A recuperação de texto integral com dados bibliográficos é um passo básico mas

necessário para conseguir serviços ricos em informação baseados em repositórios
digitais. Futuras versões das Directrizes DRIVER relacionadas com o DRIVER II
abordarão os passos seguintes relativamente a outros tipos de informação, como dados
primários ou multimédia e objectos de informação mais complexos formados por vários
recursos.
11/144 estado: final 2008-11-13

Sobre as Directrizes DRIVER
Porquê utilizar as Directrizes DRIVER?
O documento, “Directrizes para Fornecedores de Conteúdos: Exposição de Recursos

Textuais com o Protocolo OAI-PMH” fornece orientação aos administradores de novos
repositórios na definição de políticas locais de gestão de dados, aos administradores
de repositórios já existentes na tomada de medidas para serviços melhorados e aos
programadores de plataformas de repositórios no acrescento de novas funcionalidades
de suporte em futuras versões.
Como cumprir as Directrizes DRIVER? (validação)
Num futuro próximo, o DRIVER oferecerá aos repositórios locais um modo para aferir o
grau de conformidade com as directrizes através de uma interface Web1. O DRIVER
também oferece suporte via Web (ver em baixo “Existe Suporte?”). Se os pontos
obrigatórios das Directrizes DRIVER forem cumpridos, o repositório recebe o estatuto
de fornecedor DRIVER validado. Se também forem cumpridos os pontos recomendados,
o repositório recebe o estatuto de fornecedor DRIVER certificado para o futuro. Os
repositórios DRIVER validados podem reutilizar dados do DRIVER para desenvolver
serviços locais. Passam a integrar a rede de fornecedores de conteúdos DRIVER.
E se não cumprir?
Não estar em conformidade com todos os pontos obrigatórios ou recomendados das

Directrizes DRIVER não significa necessariamente que os conteúdos de um repositório
não serão recolhidos ou agregados pelo DRIVER. Porém, em função dos serviços
específicos oferecidos através da infra-estrutura DRIVER, é possível que o conteúdo
destes repositórios simplesmente não seja recuperável. Por exemplo, um serviço de
pesquisa, que pretenda listar apenas registos que ofereçam um apontador para o texto
1
Para a validação das Directrizes DRIVER 1.0 ver:
http://validator.driver.research-infrastructures.eu/
12/144 estado: final 2008-11-13

integral não pode processar todo o conteúdo de um repositório que ofereça

unicamente registos de metadados ou que oculte os textos integrais através de
procedimentos de autorização. Estas directrizes ajudarão a distinguir esses registos. As
Directrizes DRIVER não determinarão, como é óbvio, que registos devem ser mantidos
num repositório local.
Existe suporte?
O DRIVER oferece suporte aos repositórios locais para que possam implementar as
directrizes numa base individual. O suporte pode ser obtido através da internet2 ou
pode ser pessoal3. O DRIVER está empenhado em qualquer solução possível que possa
realizar-se através do processamento central de dados. Não obstante, o caminho
sustentável, transparente e escalável para serviços melhorados passa pelos
repositórios locais.
Âmbito das Directrizes DRIVER
As Directrizes DRIVER são uma norma?
Não. Embora o uso de normas como o OAI-PMH proporcione certamente uma base
sólida para criar uma rede como o DRIVER, são necessárias directrizes adicionais. O
principal motivo é que as normas ainda dão lugar a interpretações e implementações
locais. Sem isso, uma norma não poderia existir. Porém esta abertura pode-se
converter num obstáculo para a obtenção de serviços de alta qualidade quando se
combinam implementações divergentes.
As Directrizes DRIVER equivalem a regras de catalogação?
Não. As directrizes são um instrumento para mapear (ou traduzir) os metadados

utilizados no repositório para os metadados em Dublin Core, tal como são recolhidos
2
Website de suporte DRIVER: http://www.driver-support.eu
3
Ver documento: “Advice for implementation of the DRIVER guidelines”,
www.driver-support.eu/documents/Advice_for_implementation_of_the_DRIVER_guidelines.pdf
13/144 estado: final 2008-11-13

pelo DRIVER. Não estão pensadas para serem utilizadas como instruções de introdução
de dados na inserção de metadados nos sistemas de repositório locais.
As Directrizes DRIVER possuem instruções do nível de qualidade científica?
Não. As directrizes não indicam que recursos possuem o nível de qualidade requerido
no que respeita ao conteúdo científico. Assumiremos que esta distinção já foi feita ao
nível dos repositórios, isto é, assumiremos que a qualidade dos recursos expostos
através da recolha é suficientemente boa.
Quais são os principais componentes das Directrizes DRIVER?
As Directrizes DRIVER focam basicamente cinco questões: colecções, metadados,

implementação do protocolo OAI-PMH, práticas recomendadas, vocabulários e
semânticas.
 No que respeita às colecções do repositório, é obrigatório utilizar “sets”

(conjuntos) que definam as colecções com texto integral. Se todos os recursos
do repositório forem textuais, incluírem não só os metadados, mas também o
texto integral e todos os recursos forem acessíveis sem autorização, o uso de
conjuntos é opcional.
 No que respeita ao protocolo OAI-PMH, foram definidas algumas características
obrigatórias e outras recomendadas para solucionar os problemas que surjam
nas diferentes implementações no repositório local.
 No que respeita aos metadados, foram definidas algumas características
obrigatórias e outras recomendadas para solucionar as dificuldades semânticas
que surjam de diferentes interpretações do DUBLIN CORE.
Quem criou as Directrizes DRIVER?
As Directrizes do DRIVER foram compiladas por profissionais com anos de experiência

na construção e manutenção de redes similares de repositórios interligados, como HAL
(França), DARE (Países Baixos), DINI (Alemanha), SHERPA (Reino Unido), e envolvem a
competência de fornecedores de serviços experientes, como o BASE, e organizações
comunitárias, como o grupo OAI Best-Practice.
14/144 estado: final 2008-11-13

O que se entende por recursos textuais?
Nesta fase do projecto DRIVER estamos focados nos recursos textuais. Como definições
de trabalho utilizamos as seguintes:
 Recurso textual: artigos científicos, teses de doutoramento, documentos de

trabalho, livros electrónicos e resultados similares de actividades de
investigação científica
 Open Access (ou Acesso Livre): acesso sem qualquer forma de pagamento,
licenciamento, controlo de acesso com palavra de acesso, controlo de acesso
mediante IP, etc.
Muitos repositórios são utilizados para depositar diferentes tipos de recursos, por
exemplo, artigos, livros, fotografias, vídeos, conjuntos de dados (data sets) ou
recursos de aprendizagem. Estes recursos possuem registos de metadados que os
descrevem. Normalmente, os recursos encontram-se em formato digital (mas nem
sempre) e estes ficheiros digitais são usualmente armazenados numa base de dados
que é parte do sistema do repositório (mas nem sempre). O acesso aos recursos é
geralmente livre (mas nem sempre). No DRIVER almejamos um subconjunto do vasto
domínio de recursos existentes nos repositórios europeus: focamos recursos textuais
em formato digital e que são de acesso livre.
Estudos indicam que deste modo poderemos cobrir mais de 80% de todos os recursos
disponíveis. Por este motivo, a primeira directriz obrigatória da Parte A refere: “o
repositório contém recursos textuais digitais”. Isto não significa que o repositório não
possa incluir outros materiais ou itens não-digitais. A afirmação é uma expressão do
foco do DRIVER em recursos textuais. Uma lista completa de recursos textuais é
apresentada no elemento dc:type nas directrizes de metadados no capítulo “Uso de
vocabulários e semânticas” secção “Vocabulário tipo de publicações”. Para a
implementação no dc:type ver capítulo “Uso de metadados OAI_DC” secção “Type
(Tipo)”. Ou para mapear os tipos de acordo com os mapeamentos actualmente
conhecidos ver secção “Mapeamento de tipos DRIVER” no capítulo “Uso das práticas
recomendadas com OAI_DC”.
15/144 estado: final 2008-11-13

O que são “sets”?
Sets (conjuntos) são um componente normalizado do protocolo OAI-PMH e são

utilizados para apontar (filtrar) partes específicas de um repositório. Se o repositório
também contém itens não textuais, ou não digitais, ou itens de acesso pago ou registos
exclusivamente com metadados, pode utilizar o mecanismo de sets para filtrar esses
itens quando disponibilizar os conteúdos ao DRIVER
Mais Recursos
O que mais se deve considerar?
Foram utilizados recursos existentes como contributo para elaborar estas Directrizes
DRIVER e prestou-se particular atenção para evitar soluções especiais. Assim, poder-
se-á afirmar que as Directrizes DRIVER exploram ao máximo a experiência prática e
outras directrizes existentes a nível internacional.
 O DRIVER foi concebido seguindo a estrutura de redes operacionais e

distribuídas de fornecedores de conteúdos, particularmente a rede DARE na
Holanda. As directrizes DARE servem como modelo para o DRIVER. Ao invés de
indicar múltiplas referências para outras directrizes espalhadas por todo o
mundo, o DRIVER usou inicialmente as Directrizes DARE e aperfeiçoou estas
directrizes, adoptando as práticas recomendadas dos gestores de repositórios e
especialistas de todo o continente europeu. Os seguintes documentos foram um
ponto de partida importante, e essencial, para as Directrizes DRIVER:
o O documento USING SIMPLE DUBLIN CORE TO DESCRIBE EPRINTS, de
Andy Powell, Michael Dayy e Peter Cliff da UKOLN, Universidade de Bath
(versão 1.2), que foi adaptado para cumprir alguns requisitos específicos
do DARE, historicamente conhecido por “Uso DRIVER das directrizes OAI-
PMH” (Versão 2, Dezembro de 2006), foi ampliado nas Directrizes
DRIVER 2.0 com a colaboração de gestores de repositórios – ver capítulo
“Uso de metadados OAI_DC”
o A versão 2.0 do protocolo OAI-PMH (Open Archives Initiative Protocol for
Metadata Harvesting), que também foi adaptada aos requisitos
16/144 estado: final 2008-11-13

específicos do DARE e que está disponível como “Uso DRIVER das

directrizes OAI-PMH” (Versão 2, Dezembro de 2006) foi ampliada nas
Directrizes DRIVER 2.0 com a colaboração de gestores de repositórios –
ver capítulo “Uso do protocolo OAI-PMH”
o O DINI-Certificate “Document and Publication Services 2007” (Versão 2,
Septembro de 2006)4 oferece uma base sólida sobre o que se deve
considerar na operação de um repositório. Uma vez que o DRIVER
aborda os repositórios do ponto de vista de um agregador, as Directrizes
DRIVER não cobrem os aspectos descritos no certificado DINI, que está
desenhado como guia geral da operação local de um repositório. Ao
invés, as Directrizes DRIVER baseiam-se na suposição de que os critérios
do certificado DINI são considerados no funcionamento de um
repositório.
o O documento “Use of MODS for institutional repositories”5 foi criado
pelo grupo de especialistas de metadados do programa SURFshare e
utilizado por repositórios holandeses. Estas directrizes apresentam uma
lista prática de tipos de publicação que garante uma maior
interoperabilidade. Os tipos de publicação são baseados na lista de
publicações dc:type do documento "DARE use of DC", conjuntamente
com tipos e-prints e tipos de publicação usados no METIS no
desenvolvimento do Dutch Current Research Information System (CRIS).
o O Version Identification Framework6 forneceu uma versão taxionómica7
simples e prática para artigos de revista e mais. Isto proporcionou um
complemento para melhor descrever os tipos de publicações existentes
na comunicação científica.
4
http://www.dini.de/documents/dini-zertifikat2007-en.pdf
https://www.surfgroepen.nl/sites/oai/metadata/Shared%20Documents/Use%20of%20MODS%20f
or%20institutional%20repositories-version%201.doc
6
http://www.lse.ac.uk/library/vif/Framework/Essential/taxonomies.html
7
http://www.lse.ac.uk/library/versions/
17/144 estado: final 2008-11-13

Existe alguma solução que resolva de imediato vários problemas?
Sim, ver o capítulo “Uso de MPEG-21 DIDL (xml-container) – Empacotamento do

objecto composto”. No contexto do SURF DARE comprovou-se a utilidade de
implementar um “XML-Container” para cada recurso que permita a recolha de recursos
com OAI-PMH, proporcione um apontador inequívoco para o recurso (não mediante
uma página de acesso), suporte a indexação de texto integral e permita a
representação de documentos complexos compostos por vários ficheiros PDF. O XML-
Container é baseado na Digital Item Declaration Language (MPEG21-DIDL)8. Outras
soluções baseadas em DIDL também foram desenvolvidas (ex. aDORe9, e os perfis
METS10) e outras a publicar no futuro (ex. OAI-ORE11).
Esboço – Sumário das Directrizes DRIVER
O seguinte esboço resume as definições básicas DRIVER para os tópicos sobre recursos
textuais, utilização de metadados e implementação do protocolo OAI-PMH. Os detalhes
completos podem ser encontrados nos capítulos seguintes.
PARTE A – Recursos Textuais
obrigatório
 O repositório contém recursos digitais textuais (ver explicação “O que se

entende por recursos textuais?” na página 15)
 Os recursos textuais estão em formatos profusamente utilizados e difundidos
(PDF, TXT, RTF, DOC, TeX etc.)
 Os recursos textuais estão em acesso livre, disponíveis directamente do
repositório para qualquer utilizador sem restrições como autorizações ou
pagamento
8
http://xml.coverpages.org/mpeg21-didl.html
9
http://african.lanl.gov/aDORe/projects/adoreArchive/
10
http://www.loc.gov/standards/mets/mets-profiles.html
11
http://www.openarchives.org/ore/
18/144 estado: final 2008-11-13

 Os recursos textuais são descritos por registos de metadados

 Os recursos textuais e de metadados estão ligados entre si de tal modo, que um
utilizador final possa aceder ao recurso textual através do identificador
(normalmente um URL) no registo de metadados
 O URL de um recurso inscrito no registo de metadados está permanentemente
acessível e nunca se altera ou se atribui a outro recurso
 Um identificador único identifica o registo de metadados e o recurso textual
(não há apontadores para sistemas externos, como um sistema nacional de
bibliotecas ou uma editora)
recomendado
 Verificação transparente da integridade de um recurso textual

 Medidas de controlo de qualidade (do conteúdo cientifico) dos recursos textuais
expostos para limitá-los a, por exemplo, os recursos textuais incluídos no
relatório cientifico anual (ou equivalente).
 O URL de um recurso inscrito no registo de metadados baseia-se num esquema
de identificadores persistentes como: DOIs, URNs, ARKs
 O uso do DIDL XML-container para exposição de recursos textuais (capítulo “Uso
de MPEG-21 DIDL (xml-container) – Empacotamento do objecto composto”)
PARTE B - Metadados
obrigatório
 Os metadados são estruturados como Dublin Core não qualificado (ISO

15836:2003).
 Os elementos individuais de DC devem ser usados de acordo com o capítulo
“Uso de metadados OAI_DC” na página 55
recomendado
19/144 estado: final 2008-11-13

 Usar preferencialmente metadados estruturados de acordo com esquemas mais

completos como Dublin Core qualificado ou MODS. (Directrizes sobre estes
esquemas mais detalhados serão disponibilizados em futuras versões das
Directrizes DRIVER.12)
 O idioma recomendado é o inglês
 O idioma recomendado para o resumo (a inclusão de resumo é opcional) do
artigo é o inglês
PARTE C – Implementação OAI-PMH
obrigatório
 O repositório deve estar em conformidade com OAI-2.0 e deve estar de acordo

com as especificações no capítulo “Uso do protocolo OAI-PMH” na página 36
 Deve existir um identificador de repositório e deve utilizar-se o esquema de
identificador OAI
 Se (e apenas se) o repositório contém outros recursos para além dos que são
obrigatórios na “PARTE A – Recursos Textuais”, deve ser definido um OAI-set
que identifique a colecção de recursos textuais digitais com recursos em acesso
livre (ver explicações “Atribuição de nome ao conjunto DRIVER”, “Definições
do conteúdo do conjunto DRIVER” e “Localização do conjunto (set)” nas
páginas 45-47)
recomendado
 Disposições para a alteração do URL Base

 Resposta completa ao pedido „Identify‟, incluindo o uso opcional da declaração
Description
 Uso de estratégia de eliminação persistent ou transient
12
Antevisão das MODS guidelines
20/144 estado: final 2008-11-13

 Uso de um tamanho de lote de recolha com uma correspondente data de

expiração do testemunho de reatamento (resumption token).
21/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 O que é novo
O que é novo
Capítulo 1: Uso do OAI-PMH

Atribuição de nome ao conjunto DRIVER
Informação adicional para responder a questões sobre “Nomes de conjuntos

recomendados para "Open Access" e sub-colecções de acesso “Embargado/Acesso
Retardado" –
Ver Atribuição de nome ao conjunto DRIVER na página 45
Explicação: É recomendado que os repositórios híbridos com uma mistura de

metadados apenas e metadados com texto integral utilizem um conjunto DRIVER com
registos que contenham o texto integral em acesso livre. O conjunto DRIVER não deve
conter registos com acesso embargado, porque isso apenas conduz a confusão do
utilizador final, quando este espera encontrar recursos em acesso livre.
Não deverão existir recomendações DRIVER sobre conjuntos para e-Teses.
Explicação: As Directrizes DRIVER são para uma comunidade mais ampla. A recolha de
e-Teses deverá ser reconhecida através dos termos usados no vocabulário de tipos de
publicação.
22/144 estado: final 2008-11-13

Tamanho do lote de recolha
Aumentar o tamanho de lote de 100-200 registos por lote, para 100-500 registos por
lote. Ver: Tamanho do lote de recolha na página 45.
Explicação: A experiência diz-nos que os problemas com quebras na comunicação de

um OAI ListRecords acontecem muito raramente. O maior resultado observado até
hoje de registos por resposta foi cerca de 6.500 registos. A consequência positiva de
um tamanho do lote grande é a de que a actividade de recolha (harvesting) é muito
rápida e, portanto, esses repositórios possuem uma taxa de transferência alta.
Testemunho de reatamento (resumption token)
Melhor explicação sobre a necessidade da recomendação da longevidade de um

testemunho de reatamento. Ver: Testemunho de reatamento (Resumption token) na
página 43.
Explicação: Existe uma relação entre a longevidade, tamanho do lote e a taxa de

transferência. Se o débito de transferência é lento e tamanho do lote é pequeno, a
longevidade do testemunho de reatamento deve aumentar. Caso contrário, o harvester
continua a receber apenas o primeiro lote repetidamente.
Estratégia de registos eliminados
As Directrizes DRIVER explicam agora de forma mais clara porque razão uma estratégia
persistent/transient é valiosa tanto para o repositório como para o fornecedor de
serviços.
Explicação: A vantagem para o repositório em manter um registo de eliminações é a

de que o fornecedor de serviços não exibirá registos que já não estejam disponíveis no
repositório. Adicionalmente, esta estratégia permite que os harvesters evitem a
recolha completa do repositório de todas as vezes e torna o processo de recolha mais
eficiente.
Ver: Registos eliminados na página 42.
23/144 estado: final 2008-11-13

Capítulo 2: Uso de metadados OAI_DC
Identifier (Identificador)
Como lidar com outros identificadores que existam no repositório. Os identificadores

OAI são permitidos? Para onde deve apontar o identificador? Como devem ser
expostos?
Explicação: A identificação de um recurso foi alargada. O repositório pode usar

qualquer identificador que seja necessário para identificar o recurso. Contudo, deve
haver pelo menos um identificador accionável que aponte para a página de transição
(jump-off-page) com o texto integral do documento ou directamente para o texto
integral do documento. No caso de mais do que um identificador accionável, o
fornecedor de serviço irá utilizar, como padrão, o primeiro identificador accionável na
lista para direccionar o utilizador final. Ver: Identifier (Identificador) na página 77.
Date (Data)
O que fazer quando a data recomendada nas Directrizes DRIVER (data de criação) não
está disponível no repositório?
Nas Directrizes DRIVER: "Use o elemento DC „date‟ para o valor do qualificador: data
de publicação. A data preferencial é a data de publicação, porque é a data mais
significativa e útil para o utilizador final. Se a data de publicação não está disponível,
use outra data disponível. É sempre melhor usar uma data do que nenhuma." Ver: Date
(Data) na página 70.
Explicação: Ocorreram duas alterações:
1. A data de criação mudou para data de publicação; porque esta é a mais

significativa para o utilizador final
24/144 estado: final 2008-11-13

2. Se isto não se aplica, use a seguinte melhor data ou a mais apropriada: é
melhor usar uma data do que nenhuma!
O que fazer no caso de múltiplos campos de data?
No caso de OAI-DC, use apenas um campo data, preferencialmente a data de

publicação. Explicação: mais do que um campo data cria ambiguidade uma vez que o
DC simples não comporta qualificadores. Por defeito um fornecedor de serviços usa a
primeira data na lista para processamento, indexação e apresentação.
Ver: Date (Data) na página 70.
Rights (Direitos)
Explicação sobre como usar o campo dc:rights. Ver: Rights (Direitos) na página 83.
Language (Idioma)
A recomendação de codificação mudou para ISO 639-3. Ressegurando-se que a ISO 639-
1 e -2 ainda são permitidas, uma vez que podem ser mapeadas correctamente.
Explicação: A codificação ISO 639-3 possui muitos mais idiomas do que ISO 639-1,
mesmo idiomas históricos e idiomas sub-regionais. Isto torna a explicação de certas
publicações mais fácil. A ISO 639-2 possui dois tipos de codificação (b e t), o que a
torna mais ambígua quando utilizada em OAI-DC. A última não proporciona um
atributo que notifica qual dos dois esquemas de codificação foi utilizado.
Ver:
Language (Idioma) na página 80.
Creator (Autor)
25/144 estado: final 2008-11-13

De acordo com as Directrizes DRIVER: "Instrução de utilização quando o nome inicial e
completo estão ambos disponíveis use esta formatação: <dc:creator> Janssen, J.
(John)</dc:creator>"
COMENTÁRIO: No contexto da instrução de utilização, o que significa ambos

disponíveis?
Mudou o nome completo e o nome à frente para primeiro nome.
Explicação: Recomenda-se o uso de um estilo de escrita de nomes padronizado, por

isso utilize em primeiro lugar o estilo usado pelo editor. Quando isso não é aplicável
utilize o estilo bibliográfico APA como numa lista de referência quando aplicável.
Quando as iniciais e primeiro(s) nome(s) (referindo-se a essas iniciais) de uma pessoa
estão disponíveis, utilize o formato em que o primeiro nome está escrito entre
parênteses curvos após o estilo do nome APA. A sintaxe deveria ser então: {apelido},
{iniciais} ({primeiro nome})
Por exemplo
 John Kennedy passa para: Kennedy, J. (John)

 John F. Kennedy passa para: Kennedy, J.F. (John)
 John Fitzgerald Kennedy passa para: Kennedy, J.F. (John, Fitzgerald)
 e J.F. Kennedy passa para: Kennedy, J.F. porque o primeiro nome completo
não estava disponível.
Ver: Creator (Autor) na página 63.
Source (Fonte)
Hiperligação partida em Guidelines for Encoding Bibliographic Citation Information in

Dublin Core Metadata. Mudou de http://epub.mimas.ac.uk/DC/dc-citation-guidelines/
para http://dublincore.org/documents/dc-citation-guidelines/
26/144 estado: final 2008-11-13

Type (Tipo)
Mudança de vocabulário
Devido à confusão existente na comunidade internacional de repositórios sobre os

termos para os diferentes tipos de publicações, os especialistas das Directrizes DRIVER
desenvolveram dois vocabulários distintos. Um que explica o tipo de publicação
simples e outro que explica as versões utilizadas em comunicação científica. Os tipos
de versão podem ser adicionados aos tipos de publicação para criar maior
profundidade e para explicar ainda mais a publicação.
Os tipos publicação são tipos bem pensados que não explicam o tipo de documento,
mas o tipo de publicação. Estas publicações têm sido utilizadas em processos
académicos comuns. Os termos são escolhidos para criar um equilíbrio entre não muito
específicos (que só se aplicam a uma comunidade científica) e não muito genéricos.
Outra coisa que estava a faltar era um espaço de nome (namespace) que gerasse um
nível de autoridade de um vocabulário controlado. O URI espaço de nome info:eu-repo
foi especialmente concedido pelas autoridades para ser utilizado neste propósito.
O vocabulário para tipos de publicação do DRIVER foi produzido de acordo com estes
critérios.
Ver: Vocabulário tipo de publicações na página 121.
Para tipos de versões ver: Vocabulário de versões na página 126.
discussão sobre termos
Diferença entre Conference report e Conference lecture?
Explicação: As diferenças foram removidas abstraindo-se para um termo mais geral

"Conference Object".
Mapear entregáveis de projectos públicos para relatórios externos de investigação,

relatórios técnicos para documentos de trabalho, editoriais para artigo?
27/144 estado: final 2008-11-13

Explicação: Foram efectuados mapeamentos. Ver: Mapeamento de tipos DRIVER na
página 87. Foi disponibilizada a descrição dos termos.
Format (Formato)
Explicação: Sobre as limitações da lista de formatos. Esta lista é apenas um

subconjunto de todos os formatos comuns que poderiam ser utilizados neste campo.
Acrescentamos Open Document Text: vnd.oasis.opendocument.text. Uma lista mais
extensa pode ser encontrada em http://www.iana.org/assignments/media-types/
Ver: Format (Formato) na página 75.
Capítulo 3: Utilização das práticas recomendadas

para OAI_DC
Mapeamento tipos DRIVER
Explicação: como mapear [x] categorias locais para [y] categorias DRIVER.
Ver: Mapeamento de tipos DRIVER na página 87.
Mapeamento versões DRIVER
Explicação: como usar os diferentes estados/versões de publicações e como mapear

[x] categorias locais para [y] (versões) categorias DRIVER.
Ver: Mapeamento de versões DRIVER na página 90.
28/144 estado: final 2008-11-13

Utilização de OAI_DC com teses
Explicação: como usar OAI_DC com e-Teses e

Dissertações sem perder interoperabilidade. Ver
Uso do OAI_DC com teses na página 92.
DC:SOURCE e DC:RELATION
Explicação: como usar os campos DC:SOURCE e DC:RELATION no que concerne a

comunicação científica e repositórios.
Ver: DC:SOURCE e informação de citação na página 94 e DC:RELATION e hiperligação

de objectos relacionados na página 94.
Capítulo 4: Uso de empacotamento de objecto

composto
Foram efectuadas várias mudanças importantes
 Localização do esquema DIDL errada, validação não possível

 Modificar referência do espaço de nome info:eu-repo
 Modificações são também colocadas no exemplo
 Alterações para ir ao encontro do futuro transporte de identificadores de
autores (Author Identifiers)
29/144 estado: final 2008-11-13

Adicionar espaço de nome e alterar para localização de espaço de nome válida
<didl:DIDL
xmlns:didl="urn:mpeg:mpeg21:2002:02-DIDL-NS"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:diext="http://library.lanl.gov/2004-04/STB-RL/DIEXT"
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
urn:mpeg:mpeg21:2002:02-DIDL-NS http://purl.lanl.gov/STB-
RL/schemas/2004-08/DIDL.xsd urn:mpeg:mpeg21:2002:01-DII-NS
http://purl.lanl.gov/STB-RL/schemas/2003-09/DII.xsd
http://library.lanl.gov/2004-04/STB-RL/DIEXT http://purl.lanl.gov/STB-
RL/schemas/2004-04/DIEXT.xsd">
Passa para:
<didl:DIDL
xmlns:dip="urn:mpeg:mpeg21:2005:01-DIP-NS"
urn:mpeg:mpeg21:2002:02-DIDL-NS
http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-
21_schema_files/did/didl.xsd
urn:mpeg:mpeg21:2002:01-DII-NS
21_schema_files/dii/dii.xsd
urn:mpeg:mpeg21:2005:01-DIP-NS
21_schema_files/dip/dip.xsd">
30/144 estado: final 2008-11-13

Alterações no elemento container para possibilitar melhor interpretação semântica
<didl:DIDL>
<didl:Container>
<didl:Item>…</didl:Item>
</didl:Container>
</didl:DIDL>
Passa para:
<didl:DIDL>
<didl:Item>
<didl:Item>…/didl:Item>
</didl:Item>
</didl:DIDL>
Alterações da declaração Object type por item agregado
Passa para:
<didl:Descriptor>
<didl:Statement mimeType="text/plain">metadata</didl:Statement>
</didl:Descriptor>
<didl:Descriptor> 

<didl:Statement mimeType="application/xml">
<dip:ObjectType>info:eu-
repo/semantics/descriptiveMetadata</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
31/144 estado: final 2008-11-13

 'object' passa para 'objectFile'
 'Jump-off-Page‟ passa para 'humanStartPage'
A convenção de texto é camelCase (maiusculasInterioresSemEspaços) começado com

minúsculas.
Uso de identificadores persistentes no DIDL
Isto explica a posição do identificador persistente e a "Localização a ser utilizada para

mecanismos de resolução".
No nível superior do elemento item, deve ser adicionado um componente/elemento

que se refere ao URL accionável deste documento DIDL sem os elementos OAI-PMH.
Quando isto não é aplicável no momento, use o URL da página de transição (Human
Start Page).
<didl:DIDL>
<didl:Item>
<didl:Descriptor>
<dii:Identifier>urn:NBN:nl:ui:10-
1705/6748398729821</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
...
<didl:Component>

<didl:Resource mimeType="application/xml"
ref="http://localhost/xmlContainer-
v2.3.xml"/>
</didl:Component>
<didl:Item>...</didl:Item>
</didl:Item>
</didl:DIDL> 32/144 estado: final 2008-11-13

Prefixo de metadados genérico no OAI-PMH
Isto explica o uso real do DIDL e não um esquema derivado.
<request metadataPrefix="dare_didl"
Passa para:
<request metadataPrefix="didl"
Capítulo 5: Uso de vocabulários e semânticas
Foram produzidos dois vocabulários para reduzir a ambiguidade dos conceitos e termos
utilizados na comunicação científica na Europa.
Muitas outras questões foram assim solucionadas:
 Tipo de documento: Versões Preprint e Postprint

 Tipo de documento: Qual é a diferença entre “relatório de investigação
externo” e “relatório interno”?
 Melhoramento no vocabulário do tipo de documento
 Questão se bookChapter no vocabulário info:eu-repo deveria ser mais genérico
para uma interpretação optimizada pelos fornecedores de serviço – para uma
combinação de termos ex. chapter e partOf ? Resposta: NÃO.
 Versões de revistas científicas – modelo melhorado
Foi adicionado um capítulo sobre o uso de informação de classificação .
Recomenda-se o fornecimento de informações sobre o uso de classificação num

repositório na resposta ao Identify e transportar a classificação no elemento subject
(assunto) "URI-fied" utilizado um espaço de nome (namespace) de autoridade. Se não é
33/144 estado: final 2008-11-13

utilizado nenhum esquema de classificação específico, o DRIVER recomenda a Dewey
Decimal Classification.
Ver: Uso de vocabulários e semânticas na página 117.
Capítulo 6: Anexo: Uso de etiquetas de qualidade
Ver Anexo: Uso de etiquetas de qualidade na página 130 para um documento

preliminar.
As Directrizes DRIVER 2.0 apresentam informação básica sobre a importância da

qualidade e interoperabilidade. Etiquetas de qualidade podem ser utilizadas para
assegurar repositórios estáveis e fiáveis que durem mais tempo e que possuam um
propósito de arquivo de preservação a longo prazo.
Como exemplos de etiquetas de qualidade pode-se mencionar: o Data Seal of Approval

e o DINI Certificate.
Capítulo 7: Anexo: Uso de identificadores

persistentes
Ver Anexo: Uso de identificadores persistentes na página 131 para um documento

preliminar.
Identificadores persistentes para recursos Web são necessários para criar uma infra-
estrutura estável e fiável. Isto não diz respeito a aspectos técnicos, mas,
principalmente, a acordos a um nível organizacional.
34/144 estado: final 2008-11-13

As Directrizes DRIVER podem produzir algumas recomendações sobre a implementação
para gestores de repositórios. Na base está o Relatório sobre Identificadores
Persistentes do projecto PILIN.
Foi disponibilizado um plano de implementação.
Capítulo 8: Anexo: Intercâmbio de estatísticas de

utilização
Ver Anexo: Intercâmbio de estatísticas de utilização na página 137 como documento

preliminar.
Para aferir valor do Acesso Livre e oferecer serviços adicionais aos seus autores, os
repositórios devem pensar na agregação de estatísticas de utilização.
Dois projectos irão ganhar dimensão e ajudarão a desenvolver directrizes para o

intercâmbio de dados de utilização: PIRUS e OA-Statistik
Capítulo 9: Anexo: Uso de direitos de propriedade

intelectual
Ver Uso de direitos de propriedade intelectual na página 143 para um documento

preliminar.
Este capítulo aborda uma temática importante sobre direitos de utilização e direitos
de depósito. Na prática, isto deve ser implementado. As Directrizes DRIVER devem
dizer algo sobre a forma como os direitos de utilização e direitos de acesso devem ser
expostos e formatados nos metadados.
35/144 estado: final 2008-11-13

36/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Uso do protocolo OAI-PMH
Uso do protocolo OAI-PMH
Introdução
Este capítulo explica como usar o OAI-PMH para que os repositórios e os fornecedores
de serviços possam trabalhar perfeitamente em conjunto, criando interoperabilidade
ao nível do protocolo.
Nota:
Os exemplos usados para DIDL, NÃO devem ser utilizados literalmente! Para o uso
correcto do documento DIDL ver a versão actual do documento especificações DIDL.
Esse documento irá sobrepor-se a todos os exemplos DIDL mencionados aqui.
Agradecimentos
Este documento é baseado em grande medida nas discussões entre gestores de

repositórios e o SURF. Eles ofereceram a sua experiência e sugestões para criar as
Directrizes DRIVER conforme apresentadas no presente documento.
37/144 estado: final 2008-11-13

Fonte de informação
As Directrizes DRIVER são baseadas em e referem-se ao Open Archives Initiative

Protocol for Metadata Harvesting, versão do protocolo 2.0.
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html
A ordem de apresentação das Directrizes DRIVER é a mesma que no texto do

protocolo. Quando útil, o texto do protocolo é citado. Nos casos em que o texto foi
alterado, por exemplo realçado a negrito para destacar alguma parte do texto, isso foi
indicado entre parênteses.
Definições e conceitos: item, registo e

identificador único
Item e Registo
É importante distinguir entre um Item e um Registo. O texto do protocolo refere o

seguinte:
“...Um item é conceptualmente um contentor (container) que armazena e gera

dinamicamente metadados relacionados com um único recurso em múltiplos formatos,
cada um dos quais pode ser recolhido como registos através do protocolo OAI-PMH
...Um registo são metadados reflectidos num formato único. Um registo é recuperado
num XML-encoded byte stream como resposta a um pedido OAI-PMH de metadados de
um item...”
No DRIVER, recomenda-se a construção do XML-encoded stream de acordo com

especificações XML-Container. Estas especificações são referidas em seguida.
38/144 estado: final 2008-11-13

Identificador (identifier)
O identificador único identifica um item num repositório. Não confundir este

identificador com o elemento dc:identifier no Dublin Core. O identificador OAI possui
uma função diferente: é utilizado para extrair metadados, enquanto o identificador DC
é utilizado para extrair o recurso. Esquematicamente:
Item com Identificador Único
Dentro do
repositório
Fora do Registo com Registo com

repositório metadados XML- metadados XML-
encoded, ex. em DC encoded, ex. em
simples MARC-21
Harvester A Harvester B
Nomenclatura de prefixos de metadados

(MetadataPrefix naming)
Ver:
http://www.openarchives.org/OAI/openarchivesprotocol.html#MetadataNamespaces
39/144 estado: final 2008-11-13

O protocolo OAI-PMH suporta a disseminação de registos em múltiplos formatos de

metadados de um repositório. O pedido (request) ListMetadataFormats apresenta
uma lista de todos os formatos de metadados. O argumento metadataPrefix utiliza-se
nos pedidos ListRecords, ListIdentifiers, e GetRecord para recuperar os
registos ou os cabeçalhos dos registos que incluem metadados no formato especificado
pelo metadataPrefix. Por razões de interoperabilidade, os repositórios devem
disseminar Dublin Core sem qualificadores. Por esse motivo, o protocolo reserva o
metadataPrefix „oai_dc’e a URL de um esquema de metadados para Dublin Core não
qualificado, que é http://www.openarchives.org/OAI/2.0/oai_dc.xsd. O URI do
namespace XML correspondente é http://www.openarchives.org/OAI/2.0/oai_dc/.
Documento DIDL
A comunidade DRIVER suporta a implementação dos prefixos de metadados „oai_dc‟ e

o metadataPrefix „didl‟. Cada repositório DRIVER que utilize o XML container deve
admitir este esquema „didl‟ de metadados. A especificação „didl’ do XML container
pode ser encontrada no capítulo Uso de MPEG-21 DIDL (xml-container) –
Empacotamento do objecto composto na página 96.
<OAI-PMH ...>
<...>
<record>
<metadata>
<didl:DIDL>
Data de registo (Datestamp)
De acordo com o protocolo, cada registo contém um cabeçalho com um registo de

data (datestamp) que contém "a data de criação, modificação ou eliminação do
registo para o propósito de harvesting selectivo."
40/144 estado: final 2008-11-13

O protocolo também explica a recolha (harvesting) selectiva da seguinte forma:
 “..modification - a resposta deve incluir registos, correspondentes ao

argumento metadataPrefix, que tenham sido modificados nos limites dos
argumentos from e until.
 creation - a resposta deve incluir registos correspondentes ao argumento
metadataPrefix, que tenham sido disponibilizados no repositório dentro dos
limites dos argumentos from e until.
 deletion - dependendo do nível a que o repositório mantenha informação
sobre os registos eliminados, a resposta pode incluir cabeçalhos de
registos, correspondentes ao argumento metadataPrefix, que foram
retirados do repositório dentro dos limites dos argumentos from e until. O
estado „eliminado‟ é indicado através do atributo de estado do elemento
header e não se incluem metadados...”
É muito, muito importante ter especial cuidado na implementação da data de registo

(datestamp) de acordo com as especificações do protocolo acima referenciadas. A
experiência diz-nos que muitos dos erros de recolha (harvesting) que ocorrem na
recolha incremental têm a sua origem na má interpretação da data de registo
(datestamp).
Sintaxe da data de registo
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Datestamp,
http://www.openarchives.org/OAI/openarchivesprotocol.html#Dates e
http://www.w3.org/TR/NOTE-datetime
O valor das datas de registo (datestamps) tanto nos pedidos como nas respostas deve
estar em conformidade com as especificações de UTCdatetime referida nesse
documento. O acordo DRIVER apoia o uso granular opcional no que concerne ao tempo
com segundos YYYY-MM- DDThh:mm:ssZ.
41/144 estado: final 2008-11-13

Este valor está de acordo com as especificações para o UTCdatetime nas secções 3.3.1
no documento do protocolo OAI-PMH. Registos de datas são codificados usando a
norma ISO8601 e expressos em UTC.
<OAI-PMH ...>
<...>
<GetRecord>
<record>
<header>
<datestamp>2001-12-14T12:01:45Z</datestamp>
Um repositório que suporte YYYY-MM-DDThh:mm:ssZ deverá indicar isto na resposta ao

„Identify‟.
<OAI-PMH ...>
<...>
<Identify>
<granularity>YYYY-MM-DDThh:mm:ssZ</granularity>
<...>
Registos eliminados
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#DeletedRecords
Se um registo deixa de estar disponível, considera-se eliminado. Os repositórios devem

declarar um dos três níveis de suporte relativamente a registos eliminados no
elemento „deletedRecord‟ da resposta ao „Identify‟:
 no - o repositório não mantém informação sobre as eliminações. Um

respositório que indique este nível de suporte não deve revelar um estatuto de
eliminação em qualquer resposta
 persistent - o repositório mantém informação sobre as eliminações sem
qualquer limite de tempo. Um repositório que indique este nível de suporte
42/144 estado: final 2008-11-13

deve manter sistematicamente um registo do historial das eliminações e
consistentemente revelar o estado de um registo eliminado ao longo do tempo
 transient - o repositório não garante a manutenção de uma lista de eliminações
de forma persistente e consistente. Um repositório que indique este nível de
suporte pode revelar o estado dos registos eliminados
As directrizes do DRIVER requerem que os repositórios DRIVER usem a opção

„transient‟. Mas a opção ’persistent‟ também poderá ser utilizada. Esta opção
facilita a detecção de registos eliminados pelo harvester.
A vantagem para o repositório em manter um registo de eliminações é a de que o

fornecedor de serviços não exibirá registos que já não estejam disponíveis no
repositório. Adicionalmente, esta estratégia permite que os harvesters evitem a
recolha completa do repositório de todas as vezes e torna o processo de recolha mais
eficiente.
Utilização do nível transient: Quando um registo é eliminado, o repositório deve

indicar a eliminação durante, pelo menos, um mês. Neste período, a maioria dos
harvesters actualizaram a sua base de dados incrementalmente (sem necessidade de
uma recolha – harvest - completa).
Se um repositório possui um registo das eliminações, então a data de registo

(datestamp) do registo eliminado deve ser a data e a hora em que foi eliminado. As
respostas ao pedido GetRecord e ListRecords de um registo eliminado devem
então incluir um header com o atributo status="deleted". Assim, a recolha
incremental detectará eliminações em repositórios que façam o seu registo.
Testemunho de reatamento (Resumption token)
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Idempotency
Os repositórios que implementem testemunhos de reatamento (resumptionTokens)

devem fazê-lo de tal forma que os harvesters possam retomar uma sequência de
43/144 estado: final 2008-11-13

pedidos para listas incompletas reenviando um pedido de lista com o resumptionToken
mais recente. O objectivo é permitir que os harvesters possam recuperar erros de rede
ou de outros erros que de outra forma implicariam o reinício da sequência de pedidos.
O protocolo não menciona o tempo de vida de um testemunho. A longevidade de um

testemunho é o tempo durante o qual um repositório o conserva em memória
conjuntamente com a informação de reatamento. Quando a longevidade é demasiado
pequena, o repositório não dá tempo suficiente para um harvester voltar e recolher a
informação. Quando isto acontece, o repositório não cumpre com o protocolo, ver em
cima: “devem fazê-lo de tal forma que os harvesters possam retomar...”.
Boa prática: o tempo razoável para que um testemunho seja conservado é de pelo
menos vinte e quatro (24) horas. Isto depende do tamanho do repositório e da
velocidade de processamento e por isso a longevidade do testemunho de reatamento
deverá aguentar o tempo suficiente para transportar o lote nesse período de tempo.
Conjuntamente com este tempo de vida existe um tamanho de lote óptimo - ver
secção “Tamanho do lote de recolha”.
Outro aspecto do uso do testemunho de reatamento (resumption token) é o atributo

opcional completeListSize. Isto deverá entregar o tamanho total de documentos da
resposta e, assim, esta informação pode ser utilizada durante o processo de recolha e
pode ser comparada com o resultado do tamanho total por razões de controlo (por
exemplo, a recolha está completa ou incompleta?). Além disso, as informações podem
ser úteis para a manutenção do processo de recolha com o fito de estimar o tempo
necessário.
O testemunho de reatamento numa resposta OAI poderia assemelhar-se ao seguinte (os

atributos expirationDate, completeListSize e cursor são opcionais):
<resumptionToken expirationDate="2008-07-14T23:00:24Z"
completeListSize="983" cursor="0">514284267</resumptionToken>
44/144 estado: final 2008-11-13

Tamanho do lote de recolha

O tamanho de lote é o número de registos que um repositório entrega ao harvester
para um testemunho de reatamento (resumption token) e determina quantos processos
de pedido têm de ser executados.
Está acordado que os repositórios DRIVER devem definir o tamanho do lote entre 100 a
500 registos.
Utilizando este tamanho de lote para todos os repositórios DRIVER, permitirá que o
harvester opere com um rendimento óptimo.
Atribuição de nome ao conjunto DRIVER
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Set
O documento do protocolo OAI-PMH refere o seguinte: Os repositórios podem organizar

os itens em conjuntos (sets). A organização dos conjuntos pode ser plana, isto é, uma
simples lista, ou hierárquica.
Está acordado que os repositórios DRIVER híbridos que possuem apenas metadados e
metadados acompanhados com recursos em texto integral devem suportar pelo menos
um conjunto (set) DRIVER. O conjunto DRIVER é plano e não possui nenhuma estrutura
hierárquica. O conteúdo do conjunto DRIVER é recursos de Acesso Livre, disponíveis
livremente. Recursos com acesso diferido ou embargados não devem estar nesta lista
para evitar confusão ao utilizador final. A tabela seguinte indica o setName e a
especificação setSpec que se podem utilizar para criar um conjunto DRIVER.
setName setSpec *
O conjunto DRIVER Open Access DRIVERset driver
*Um harvester apenas utiliza o pedido setSpec para realizar recolha selectiva. Os
caracteres devem estar em minúsculas.
45/144 estado: final 2008-11-13

Definições do conteúdo do conjunto DRIVER
O conteúdo específico do conjunto „driver‟ é determinado no repositório local. Um

repositório DRIVER que use este tipo de conjuntos deve estar em conformidade com as
seguintes regras ao inserir um registo no conjunto DRIVER:
 O conjunto DRIVER contém registos que devem conter recursos textuais digitais
de acesso livre
o Deve conter objectos de texto integral, não apenas metadados

o O conteúdo é de acesso livre
o O conteúdo não é protegido por firewall
o O conteúdo é também acessível fora do campus universitário
o O conteúdo não se encontra em websites que exijam pagamento
A figura seguinte mostra que é possível inserir um registo em diferentes conjuntos

(sets). Os registos em baixo, representados por um ponto azul, também existem no
conjunto „driver‟. Dois registos existem nos três sets. O conjunto de bioquímica
(biochemistry set), o conjunto de neurofísica (neurophysics set) e o conjunto „driver‟.
Os dois primeiros são conjuntos que indicam um assunto, o conjunto „driver‟ indica um
tipo (acesso livre). O cabeçalho de um registo pode conter zero ou mais setSpecs. Um
registo OAI pode assemelhar-se com o seguinte.
<record>
<header>
<identifier>oai:repository:it/0112017</identifier>
<datestamp>2002-02-28</datestamp>
<setSpec>biochemistry</setSpec>
<setSpec>neurophysics</setSpec>
<setSpec>driver</setSpec>
</header>
<metadata>
<oai_dc:dc xmlns:oai_dc="http ....
</record>
46/144 estado: final 2008-11-13

Ilustração:
Registos no conjunto
DRIVER Todos os registos no
repositório local
Registos no
conjunto
Biochemistry
Registos no conjunto
Neurophysics
Localização do conjunto (set)
O conjunto DRIVER e outros conjuntos podem estar localizados em diferentes

localizações/baseURls.
Correio electrónico do administrador para

feedback de erros
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Identify
O repositório deve proporcionar um endereço de correio electrónico do administrador

para o pedido Identify.
Num futuro próximo pretendemos que o harvester forneça uma resposta imediata ao
administrador do repositório para informar sobre os erros que este repositório DRIVER
47/144 estado: final 2008-11-13

esteja a gerar. Consulte a seguinte tabela para ver um exemplo de uma resposta ao
Identify e que inclui o endereço de correio electrónico do administrador.
<OAI-PMH ...>
<...>
<Identify>
<adminEmail>somebody@loc.gov</adminEmail>
<adminEmail>anybody@loc.gov</adminEmail>
<...>
O uso de um adminEmail no pedido Identify é obrigatório, e também é estipulado

no protocolo OAI-PMH. Ver em baixo:
“O pedido (verb) Identify é utilizado para recuperar informação acerca de um

repositório.”
“A resposta deve incluir uma ou várias instâncias do seguinte elemento:
 adminEmail : o endereço de correio electrónico de um administrador do

repositório.”
Informação descritiva de proveniência
O contentor (container) da descrição na resposta ao Identify pode ser utilizada para

fornecer informações adicionais sobre o repositório. Os fornecedores de serviços
podem olhar para isto e melhorar o processamento dos seus dados e os serviços
baseados nos metadados e na sua qualidade.
Boa prática: Use este contentor (container) para descrever o maior número possível de
informações comuns sobre o repositório quanto com inclusão de exemplos. Isto inclui
esquemas de classificação (em que formato em que elemento), vocabulários utilizados
(tipo, idioma), políticas e informações de contextualização.
48/144 estado: final 2008-11-13

Enquanto a resposta ao Identify se relaciona com o nível do repositório, o nível de
registos pode conter informação adicional no elemento about. Para permitir que os
fornecedores de serviços possam atribuir o material recolhido, pode ser utilizado o
sub-elemento provenance.
Boa prática: Use o elemento provenance na tag about dos metadados para
relacionar com o fornecedor do documento original.
Exemplo:
<about>
<provenance xmlns="http://www.openarchives.org/OAI/2.0/provenance"
xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/provenance
http://www.openarchives.org/OAI/2.0/provenance.xsd">
<originDescription harvestDate="2002-02-02T14:10:02Z" altered="true">
<baseURL>http://the.oa.org</baseURL>
<identifier>oai:r2.org:klik001</identifier>
<metadataNamespace>http://www.openarchives.org/OAI/2.0/oai_dc/</metadata
Namespace>
<originDescription harvestDate="2002-01-01T11:10:01Z" altered="false">
<baseURL>http://some.oa.org</baseURL>
<identifier>oai:r2.org:klik001</identifier>
<metadataNamespace>http://www.openarchives.org/OAI/2.0/oai_dc/</metadata
Namespace>
</originDescription>
</originDescription>
</provenance>
</about>
49/144 estado: final 2008-11-13

Declaração de prefixo e espaço de nomes

Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Record
Declarações de espaço de nomes (namespace declarations) –- declarações de espaços

de nomes utilizadas na parte dos metadados, são todas precedidas com o prefixo
xmlns. As declarações de espaço de nome nos metadados dividem-se em duas
categorias:
 metadata format specific namespace(s) - cada parte dos metadados deve

incluir um ou vários atributos com prefixo xmlns que definam a
correspondência entre um prefixo de formato -- ex. didl – e o URI do espaço de
nomes (tal como se define na especificação do espaço de nomes XML) do
formato de metados correspondente. Alguns formatos de metadados utilizam
etiquetas de vários espaços de nomes, requerendo vários atributos com prefixo
xmlns –- no exemplo, existem declarações de oai_dc e dc.
 xml schema namespace - cada parte de metadados deve incluir o atributo
xmlns:xsi, cujo valor deve ser o URI que aparece no exemplo, que é o URI do
espaço de nomes do esquema XML (XML schema).
 xsi:schemaLocation - o seu valor é um par “URI, URL”; o primeiro é o URI de
espaço de nome (conforme definido pela especificação de espaço de nomes
XML) dos metadados que o seguem nesta parte, o segundo é o URL do esquema
XML para validação dos metadados que o seguem.
O uso recomendado de prefixos e espaços de nomes indica que estas entidades devem
ser declaradas no primeiro elemento desse espaço de nomes. Com isto, evita-se
“dificuldades operacionais” conforme descritas em: http://www.w3.org/TR/REC-xml-
names/#ns-using.
“O uso de prefixos pode provocar dificuldades operacionais se o atributo de declaração

de espaço de nomes não se proporciona directamente na entidade do documento XML,
mas mediante um atributo predeterminado declarado numa entidade externa.”
Exemplos de usos recomendados de prefixos e espaços de nomes (namespaces).
50/144 estado: final 2008-11-13

<OAI-PMH
xmlns="http://www.openarchives.org/OAI/2.0/"
http://www.openarchives.org/OAI/2.0/
http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"
>
<...>
<metadata>
<didl:DIDL
http://standards.iso.org/.../didl.xsd
http://standards.iso.org/.../dii.xsd"
>
<...>
</didl:DIDL>
</metadata>
</...>
<OAI-PMH>
Outro argumento é, por exemplo, que um documento DIDL é considerado uma

entidade autónoma que pode existir fora de um registo OAI. Quando se faz um
pequeno extracto (snippet) deste documento DIDL ele deveria ser válido de acordo
com um validador XML. Por isso, não necessita de nenhum dos textos da declaração de
espaço de nomes que se deixou no xml do protocolo OAI-PMH.
Conforme é referido no mesmo documento (http://www.w3.org/TR/REC-xml-

names/#ns-using), o acordo no DRIVER indica que também é possível declarar prefixos
e espaços de nomes nos antecessores do documento.
“O prefixo do espaço de nomes (namespace prefix), a não ser que seja xml ou xmlns,
DEVE ter sido declarado num atributo da declaração de espaço de nomes na etiqueta
51/144 estado: final 2008-11-13

de abertura do elemento em que se utiliza o prefixo ou num elemento antepassado
(por exemplo, um elemento em cujo conteúdo se declara o prefixo).”
Exemplos dos usos opcionais de prefixos e espaços de nomes.
<OAI-PMH
http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd
http://standards.iso.org/.../didl.xsd
urn:mpeg:mpeg21:2002:01-DII-NS http://standards.iso.org/.../dii.xsd
"
>
<...>
<metadata>
<didl:DIDL>
<...>
</didl:DIDL>
</metadata>
</...>
<OAI-PMH>
Validação XML
O XML que o repositório disponibiliza como resultado será validado automaticamente

durante o processo de registo do repositório e pelo processo de recolha DRIVER. Um
repositório DRIVER deve disponibilizar XML válido de acordo com todos os esquemas
XML utilizados (OAI-PMH, DIDL, oai-dc, etc.)
52/144 estado: final 2008-11-13

A validação pode ser testada usando um validador XML (por exemplo, Altova:
www.altova.com) salvando o resultado do repositório como documento xml e abrindo-
o no validador.
Para que um validador possa validar um documento XML, deve ser utilizado dentro do
documento o xsi:schemaLocation(s).
Para o esquema <OAI-PMH> use:
<OAI-PMH
http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"
>
Para o esquema <oai_dc:dc> use:
<oai_dc:dc
xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
http://www.openarchives.org/OAI/2.0/oai_dc/
http://www.openarchives.org/OAI/2.0/oai_dc.xsd
http://purl.org/dc/elements/1.1/
http://dublincore.org/schemas/xmls/simpledc20021212.xsd"
>
Para o esquema <didl:DIDL> use:
53/144 estado: final 2008-11-13

<didl:DIDL
Para outros esquemas, utilizar a mesma lógica: conservar os metadados independentes

do protocolo OAI-PMH.
Comunicação para modificação nos repositórios
Modificação para baseURL, setSpec, metadataPrefix ou esquema de metados
Quando um repositório DRIVER alterar a baseURL, setSpec, metadataPrefix ou o

esquema de metadados que influenciam o ciclo de conteúdos do DRIVER, então o
administrador do repositório em questão deverá reportar isso à comunidade DRIVER e
ao administrador do harvester do DRIVER em particular.
(http://helpdesk.driver.research-infrastructures.eu/)
54/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Uso de metadados OAI_DC
Uso de metadados OAI_DC

Este capítulo descreve a visão do DRIVER relativamente à interoperabilidade para
comunicação científica. Isto significa correcção qualitativa dos metadados dos registos
baseada no uso de padrões.
Agradecimentos
Este documento é baseado em larga medida nas recomendações para o uso de

metadados Dublin Core não qualificados (simples) conforme descrito em: USING SIMPLE
DUBLIN CORE TO DESCRIBE EPRINTS, por Andy Powell, Michael Day e Peter Cliff,
UKOLN, University of Bath, Versão 1.2
Ver: http://www.intute.ac.uk/publications/eprints-uk/simpledc-guidelines.html
Informações adicionais, descrições, explicações, comentários, instruções de utilização

e práticas recomendadas foram cuidadosamente disponibilizadas com a ajuda de todos
os colaboradores das Directrizes DRIVER, com o intuito de criar interoperabilidade
sintáctica e semântica que seja adequada para a maioria dos repositórios europeus.
Definições
“Um repositório institucional (RI) é um serviço composto por hardware, software,
dados e procedimentos, que contém recursos digitais que representam qualquer tipo
de produção científica…”
“recursos digitais = qualquer sequência de bits, independentemente do seu conteúdo

ou formato, registado como produção científica por uma pessoa autorizada…”
Neste documento, utilizaremos a palavra “recurso” para descrever um exemplo de

produção científica e a palavra “objecto” para referir à sequência de bits digital.
Quando “Obrigatório” é referido pretendemos dizer: “1) algo requerido; uma

necessidade. 2) algo especificado como obrigatório.13”
Quando “Recomendado” é referido pretendemos dizer: “1) apresentado com

aprovação como sendo adequado para uma finalidade ou papel. 2) aconselhado como
uma acção a seguir. 3) apelativo ou desejável.13”
Notas introdutórias
Âmbito
As Directrizes DRIVER foram produzidas primordialmente para facilitar a troca de

metadados entre os fornecedores de conteúdo do DRIVER e serviços do DRIVER, de
acordo com as definições DCMI para Dublin Core não qualificado (simples) conforme
descrito nas especificações OAI-PMH.14 Basicamente estas directrizes descrevem o
mapeamento de um formato interno para Dublin Core não qualificado (simples) para
13
Compact Oxford Dictionary of Current English third edition
14
Especificações OAI-PMH “For purposes of interoperability, repositories must disseminate
Dublin Core, without any qualification.”
http://www.openarchives.org/OAI/openarchivesprotocol.html#MetadataNamespaces
56/144 estado: final 2008-11-13

facilitar a recolha (harvesting). As directrizes não devem ser utilizadas como
instruções de catalogação.
Nestas Directrizes DRIVER os gestores de repositórios devem aceitar o facto de que

nem tudo pode ser expresso com DC não qualificado, estas directrizes, irão pois,
concentrar-se nas informações mais importantes na perspectiva do utilizador final,
que não é um bibliotecário.
Requisitos mínimos
 Os metadados estruturam-se segundo a norma Unqualified Dublin Core (ISO

15836:2003)
 Os elementos individuais de DC devem ser utilizados de acordo com as

directrizes tal como apresentadas neste apêndice
 É obrigatória a utilização de Unicode
 Os valores (isto é, os conteúdos reais) dos seguintes elementos DC não devem

conter linguagem de marcação em HTML (ou XML). Podem conter comandos
LaTeX, mas não existe um mecanismo explícito para indicar que se está a usar
LaTeX.
Recomendações
 Utilize os metadados numa estrutura granular superior como Dublin Core

qualificado ou MODS. (Trabalho futuro, adições às Directrizes DRIVER)
 As directrizes de metadados DRIVER apenas se referem aos metadados como
um formato de troca. Não explicitam (hard code) as recomendações feitas nas
Directrizes DRIVER nem usam um mapeamento entre as estruturas granulares
superiores de metadados implementadas localmente e as recomendações
DRIVER.
 O idioma recomendado para informação descritiva é o inglês, para que o
utilizador final possa obter documentos reconhecíveis que de outro modo
estariam “fechados” num contexto nacional.
57/144 estado: final 2008-11-13

Edições e diferença no conteúdo intelectual
Apenas um registo de metadados deve ser utilizado para diferentes manifestações de

um objecto digital (por exemplo um postscript e uma versão pdf), a menos que o
conteúdo intelectual seja diferente. A prática comum é a de criar um novo registo de
metadados quando o conteúdo intelectual é diferente. Isto acontece por exemplo,
quando uma nova "edição", com modificações no conteúdo intelectual, é criada. Nesse
caso, a prática recomendada é usar o elemento relação (relation) para ligar a versão
mais recente para a mais antiga.
Esquemas de classificação e Políticas de revisão
Em alguns casos, informação adicional sobre políticas de revisão local, o uso de

elementos de metadados dc:subject e dc:type em esquemas de classificação local ou
vocabulário controlado de palavras-chave, pode ser útil para a parte da recolha
(harvesting) e fornecedor de serviços. Um fornecedor de conteúdos apresenta
tipicamente este tipo de informação através do „Identify request‟ ao nível do
repositório; não ao nível de metadados. Ver por exemplo: 3. Guidelines for Optional
Containers em: http://www.openarchives.org/OAI/2.0/guidelines.htm e:
http://arXiv.org/oai2?verb=Identify para práticas recomendadas. Ao nível do elemento
dc isto pode ser feito adicionando um URI a um termo. Para esquemas de classificação
que ainda não possuem um espaço de nome (namespace) adicionando um sub-espaço
de nomes ao info-uri namespace pode ajudar. (ver www.info-uri.info)
Simplificação e Qualificadores
Informação sobre o uso de refinamentos (qualificadores). Quando se realiza a

conversão para DC não qualificado, o fornecedor de conteúdo tem de fazer escolhas
quando o formato interno é “mais rico” que o DC não qualificado. Isto significa que
durante o processo de mapeamento, todos os refinamentos são simplesmente
descartados (o princípio de simplificação da DCMI). O efeito que se produz com este
princípio de simplificação é que o formato simples do elemento, isto é sem
58/144 estado: final 2008-11-13

refinamento, é o predefinido. Por exemplo, quando o formato interno distingue entre
o título principal e o título paralelo, seria apresentado da seguinte forma em DC:
Formato interno
245 $aMain title$sSub-title
DC Qualificado
<dc:title>Main title</dc:title>
<dcterms:alternative>Sub- title</dcterms:alternative>
DC Não qualificado
<dc:title>Main title:Sub-title </dc:title>
Interpretações predefinidas de elementos dc
Contudo, no DRIVER os seguintes valores são seleccionados como valores predefinidos

para oai_dc
dc:description -> valor predefinido “abstract” (resumo)

dc:date -> valor predefinido “published” (publicação)
dc:audience -> valor predefinido “education level” (nível de educação)
No DRIVER, isto significa que o elemento „date‟ (data) está sempre associado à data de
publicação, etc. Recomenda-se que todos os fornecedores de conteúdos facultem esta
informação a harvesters externos como informação sobre seu repositório (na resposta
ao Identify OAI-PMH).
Tabela 1: exemplo de notificação ao fornecedor de serviço sobre a interpretação dos

campos dos elementos dc.
<OAI-PMH>
<Identify>
<description>
<eprints>
<metadataPolicy>
oai_dc:dc:description(default “abstract”);
oai_dc:dc:date(default “published”);
oai_dc:dc:audience(default “education level”);
</metadataPolicy>
</eprints>
59/144 estado: final 2008-11-13

</description>
</Identify>
</OAI-PMH>
Os elementos: descrição abreviada
No DRIVER o uso de elementos pode ser:
 obrigatório (mandatory – M na tabela seguinte) = o elemento deve estar

sempre presente no registo de metadados. Um elemento vazio não é permitido.
 obrigatório quando aplicável (mandatory when applicable – MA na tabela
seguinte) = quando o elemento pode ser obtido, deve ser apresentado no
registo de metados
 recomendado (recommended – R na tabela seguinte) = o uso do elemento é
recomendado
 opcional (optional – O na tabela seguinte) = não é muito relevante se o
elemento é ou não usado
O estatuto recomendado é apresentado essencialmente para incentivar os utilizadores

a introduzir alguns elementos no momento da criação de um registo de metadados
para melhorar serviços.
DC não qualificado: oai_dc
Elemento Estatuto Esquema de codificação

básico
Title (Título) M Nenhum, texto livre.
Creator M Estilo bibliográfico APA como numa lista de referências.
(Autor) Sintaxe: apelido, iniciais (primeiro nome)
[http://en.wikipedia.org/wiki/Apa_style#Reference_list]
Subject MA A escolha de palavras-chave e classificações pode ser
60/144 estado: final 2008-11-13

(Assunto) texto livre (preferencialmente em inglês) e definidas por
um esquema URI (preferencialmente info:eu-
repo/classification).
Description MA Nenhum, texto livre. A prática recomendada é a de incluir
(Descrição) um resumo em inglês. “Abstract” é a interpretação
predefinida para o valor dc:description
Publisher R Nenhum
(Editora)
Contributor O Estilo bibliográfico APA como numa lista de referências.
(Colaborador) Sintaxe: apelido, iniciais (primeiro nome)
Date (Data de M Data | ISO 8601 W3C-DTF - “Published” é a interpretação
publicação) predefinida para o valor dc:date
Type (Tipo) M Tipo de publicação e tipo de versão podem ser texto livre
(preferencialmente em inglês) e definidas por um esquema
URI (preferencialmente info:eu-repo/semantics).
Format R IANA registered list of Internet Media Types (MIME types)
(Formato) [http://www.iana.org/assignments/media-types/]
Identifier M Esquema URI, hiperligação para identificadores
(Identificador) persistentes (URN, handle, DOI), documento de texto
integral ou página de transição (human start page).
Source (Fonte) O Guidelines for Encoding Bibliographic Citation Information
in Dublin Core Metadata
[http://dublincore.org/documents/dc-citation-
guidelines/] conforme dcterms:bibliographicCitation
Language R ISO 639-3
(Idioma)
Relation O Nenhum
(Relação)
Coverage O “Period” é a interpretação predefinida para o valor
(Cobertura) dc:coverage.
Encoding: DCMI Period
[http://dublincore.org/documents/2000/07/28/dcmi-
61/144 estado: final 2008-11-13

period/]
Para mais esquemas de codificação ver capítulo 5 Uso de
vocabulários e semânticas.
Rights R Nenhum
(Direitos)
Audience O Nenhum. “Education level” é a interpretação predefinida
(Público) para o valor dc:audience.
Se nenhuma interpretação predefinida é mencionada nos elementos oai_dc na tabela

em cima, por favor descreva o uso específico dos elementos oai_dc na secção
„Identify‟ do seu repositório. Ver por exemplo: 3. Guidelines for Optional Containers
em: http://www.openarchives.org/OAI/2.0/guidelines.htm e:
http://arXiv.org/oai2?verb=Identify
Os elementos: descrição completa
Em seguida apresenta-se descrições completas dos elementos.
As definições DCMI provêm do documento de directrizes DCMI: “Using Dublin Core -

The Elements”. Ver: http://dublincore.org/documents/usageguide/elements.shtml .
Title (Título)
Nome do Title
elemento
Definição Nome atribuído ao recurso. Normalmente, o título é o nome pelo qual o
DCMI recurso é formalmente conhecido.
Uso Obrigatório
Instruções Conservar o texto original, a ordem e a ortografia do título do recurso.
de uso Utilizar maiúsculas apenas para nomes próprios. A pontuação não tem
que reflectir o uso do original. Os subtítulos devem separar-se do título
62/144 estado: final 2008-11-13

mediante dois pontos. Esta instrução resulta em Título:Subtítulo (sem
espaços). Se necessário, repetir este elemento para múltiplos títulos.
Não
confundir (n.a.)
com
Exemplos <dc:title>Título principal : Título paralelo</dc:title>
<dc:title>Dewey Classificatie in Archief systemen:Dewey
Classification in Archival systems</dc:title>
<dc:title>Preliminary studies for the "Philosophical
Investigations", generally known as the blue and brown books
</dc:title>
Creator (Autor)
Nome do Creator
elemento
Definição A principal entidade responsável pela criação dos conteúdos do recurso.
DCMI Normalmente, o nome de um „Creator‟ deverá ser utilizado para indicar
a entidade.
Uso Obrigatório
Instruções Uma pessoa, uma organização ou um serviço podem ser um „Creator‟. Se
de uso necessário, repetir este elemento para múltiplos autores.
Utilizar a forma invertida do nome: “apelido”, “nome” (“primeiro

nome”), “prefix”
Por exemplo Jan Hubert de Smit fica
<dc:creator> Smit, J.H.(John) de</dc:creator>
Dentro do âmbito do DC não qualificado recomenda-se a utilização de

um estilo de escrita normalizado para os nomes, utilize o estilo utilizado
pela editora, quando esteja disponível. Quando não esteja disponível
utilize a codificação da APA bibliographic writing style as in a reference
list quando aplicável. (fora do âmbito do DC não qualificado métodos de
63/144 estado: final 2008-11-13

formatação mais precisos e granulares estão disponíveis).
Quando se dispõe da inicial e do nome completo, utilizar o seguinte

formato:
<dc:creator> Janssen, J. (John)</dc:creator>
Os sufixos geracionais (Júnior, Filho, etc.) devem ser precedidos do

apelido. Em caso de dúvida, atribuir o nome tal como aparece, sem
inverter. Omitir títulos (como “Dr.”, “Sr.ª”, etc.)
Por exemplo: “Dr. John H. de Smit Jr.” fica
<dc:creator> Smit Jr., J.H. (John) de </dc:creator>
No caso de organizações onde exista uma hierarquia definida, enumerar

as partes da hierarquia por ordem decrescente e separadas com pontos
finais.
Por exemplo:
<dc:creator> Utrecht University. Department of Computer
Sciences </dc:creator>
Se a existência de uma hierarquia não é clara ou se não é clara a ordem

hierárquica decrescente, atribuir o nome tal como aparece no recurso.
Codificar apenas as organizações neste elemento para indicar autoria

corporativa, não para indicar a afiliação de um indivíduo.
A inclusão de cabeçalhos de nomes de pessoas ou colectividades a partir

de ficheiros de autoridade nacionais ou locais é opcional.
Recomenda-se a codificação de thesauri com um URI, para que os

fornecedores de serviço reconheçam o esquema de thesaurus.
Por exemplo:
<dc:creator> urn:NationalOrgThesaurus:nl/234 </dc:creator>
Nos casos de responsabilidades secundárias, que não de autoria, utilizar
64/144 estado: final 2008-11-13

dc:contributor. Se a natureza da responsabilidade é ambígua, a prática
recomendada é utilizar dc:publisher para organizações e dc:creator para
indivíduos.
Não  Contributor (ver também Instruções de uso acima).
confundir  Publisher.
com O elemento DC „creator‟ descreve o(s) nome(s) do(s)
criador(es)/autor(es) do recurso tal como consta no próprio recurso,
enquanto o elemento DC „contributor‟ descreve o(s) investigador(es) que
contribuíram para um resultado científico, não como criadores ou
editoras (comerciais).
Exemplos <dc:creator>Evans, R.J.</dc:creator>
<dc:creator>Walker Jnr., John</dc:creator>
<dc:creator>International Human Genome Sequencing
Consortium</dc:creator>
<dc:creator>Loughborough University. Department of Computer
Science</dc:creator>
Subject (Assunto)
Nome do Subject
elemento
Definição O assunto do recurso. Normalmente, o elemento „subject‟ será expresso
DCMI como palavras-chave, frases chave ou códigos de classificação que
descrevam o conteúdo intelectual do recurso.
Uso Obrigatório se aplicável
Instruções No elemento DC „subject‟ admitem-se dois tipos de valores possíveis:
de uso pode-se registar uma palavra-chave ou uma classificação. Se ambos estão
disponíveis, utilizar instâncias separadas deste elemento.
Utilizar a primeira instância do elemento DC „subject‟ para uma palavra-

chave.
Em geral, seleccionar as palavras mais significativas para as palavras-

chave e evitar usar palavras demasiado gerais para descrever um recurso
65/144 estado: final 2008-11-13

específico. Se o assunto do recurso é uma pessoa ou uma organização,
utilizar o mesmo formato de nome que usaria se a pessoa ou a
organização fossem o autor, mas não repetir o nome no elemento
dc:creator.
Nas palavras-chave não controladas por um vocabulário ou thesaurus (isto

é, em texto livre), introduzir diferentes termos com um ponto e vírgula a
separar cada palavra-chave ou frase-chave, ou repetir o elemento para
cada termo. Não há nenhum requisito relacionado com as maiúsculas nas
palavras-chave, mas recomenda-se manter uma coerência interna (dentro
do mesmo repositório).
Quando os termos são retirados de um esquema de classificação

normalizado: registar cada termo num elemento separado. Inscrever o
descritor completo do assunto segundo o esquema correspondente.
Utilizar as maiúsculas e a pontuação segundo o esquema original.
Recomenda-se a utilização de um URI quando se utiliza esquemas de

classificação ou vocabulários controlados especialmente quando são
utilizados esquemas codificados DDC ou UDC. Os fornecedores de serviços
podem considerar esquemas de codificação mais fáceis quando o
esquema é "URI-fied" por um espaço de nome (namespace) de
autoridade. Quando o esquema de classificação é codificado, utilize um
texto de leitura humana do código, de preferência em inglês,
directamente por baixo do elemento codificado. Por exemplo:
<dc:subject>info:eu-repo/classification/ddc/641</dc:subject>
<dc:subject>Anatomy</dc:subject>
Se não é utilizado nenhum esquema de classificação específico

recomendamos o Dewey Decimal Classification (DDC). Os primeiros 1000
termos são designados por Dewey Decimal Classification Summary e
podem ser descarregados em:
http://www.oclc.org/dewey/resources/summaries/ se alguém concordar
com os seguintes termos e condições:
66/144 estado: final 2008-11-13

http://www.oclc.org/research/researchworks/ddc/terms.htm
Não  Type
confundir
com O elemento DC „subject‟ descreve o(s) assunto(s) de um recurso; o
elemento DC „type‟ descreve o tipo de publicação/resultado académico
que o recurso representa.
Esquema Para mais informação sobre classificação de assuntos, ver a secção
Classificação de assuntos na página 119 no capítulo “Uso de
vocabulários e semânticas”.
Exemplos <dc:subject>polar oceanography; boundary current; mass
transport; water masses; halocline; mesoscale
eddies</dc:subject>
<dc:subject>Germany--History--1933-1945</dc:subject>
Description (Descrição)
Nome do Description
elemento
Definição Informação sobre o conteúdo do recurso. A descrição pode incluir, mas
DCMI não se limita a: um resumo, sumários, referências a representações
gráficas do conteúdo ou texto livre com informação do conteúdo.
Instruções Este elemento é utilizado para uma descrição textual do conteúdo.
de uso Quando um recurso consiste em vários ficheiros de objectos físicos
independentes, não usar dc:description para listar os URL‟s destes
ficheiros.
Predefinido = abstract
Não
confundir (n.a.)
com
Exemplos <dc:description>Prefácio [por] Hazel Anderson;
67/144 estado: final 2008-11-13

Introduction; The scientific heresy: transformation of a
society; Consciousness as causal reality
[etc]</dc:description>
<dc:description>A number of problems in quantum state and

system identification are addressed. </dc:description>
Publisher (Editor)
Nome do Publisher
elemento
Definição Uma entidade responsável pela disponibilização dos recursos. Uma
DCMI pessoa, uma organização ou um serviço podem constituir exemplos de
Editor. Normalmente, o nome de um Editor deverá ser utilizado para
mencionar a entidade.
Instruções O Editor (comercial ou não-comercial) do recurso e não a instituição à
de uso qual o autor está afiliado. O Editor utiliza-se unicamente no sentido
bibliográfico/funcional, não num sentido organizacional. Utilizar apenas
o nome completo (comercial) do Editor, não o de uma organização ou
instituto que esteja associado (num sentido mais amplo) ao autor.
No caso de publicações universitárias, colocar o nome da faculdade, da

escola ou do grupo de investigação depois do nome da universidade. No
caso de organizações onde exista claramente uma hierarquia presente,
enumerar as partes da hierarquia por ordem decrescente, separadas
com pontos. Se não é clara a existência de uma hierarquia, ou se a
ordem hierárquica decrescente não é clara, atribuir o nome tal como
aparece no documento.
O uso de nomes de Editores a partir de listas de autoridade locais ou

nacionais é opcional.
Não  Contributor
confundir
68/144 estado: final 2008-11-13

com  Creator
Na maioria dos casos o Editor e o Autor não são o mesmo.

Exemplos <dc:publisher>Loughborough University. Department of
Computer Science</dc:publisher>
<dc:publisher>University of Cambridge. Department of Earth
Sciences</dc:publisher>
<dc:publisher>University of Oxford. Museum of the History of
Science</dc:publisher>
<dc:publisher>University of Reading. Rural History
Centre</dc:publisher>
<dc:publisher>University of Exeter. Institute of Cornish
Studies</dc:publisher>
<dc:publisher>European Bioinformatics
Institute</dc:publisher>
<dc:publisher>John Wiley & Sons, Inc. (US)</dc:publisher>
Contributor (Colaborador)
Nome do Contributor
elemento
Definição Uma entidade responsável por realizar contributos para o conteúdo do
DCMI recurso. Uma pessoa, uma organização ou um serviço podem constituir
exemplos de um colaborador. Normalmente, o nome de um colaborador
deverá ser utilizado para referenciar a entidade.
Uso Opcional
Instruções Exemplos de colaboradores: orientadores, editores, técnicos ou
de uso colectores de dados.
Nomes pessoais deverão ser listados como: ver instruções em

„Creator‟. Um “orientador”, isto é um professor que oriente o trabalho
de um aluno para obtenção de um grau de doutoramento é considerado
um colaborador no seu papel de orientador/avaliador. Em DC não
qualificado é difícil expressar todos os papéis em diferentes contextos.
69/144 estado: final 2008-11-13

Na Tese de Doutoramento (TD) como um documento, as principais
figuras são o autor e o orientador. No processo global de uma TD estão
envolvidos outros papéis, como os membros da comissão científica do
júri e do presidente do júri, mas no DC não qualificado estes papéis não
são comportados.
No caso das organizações: ver instruções em „Creator‟. A inclusão de

cabeçalhos de nomes de pessoas ou colectividades a partir de ficheiros
de autoridade nacionais ou locais é opcional.
Não  Creator
confundir  Publisher
com
O elemento DC „contributor‟ descreve o(s) investigador(es) que
contribuíram para o resultado cientifico, não como autor principal ou
(editor (comercial)).
Exemplos <dc:contributor>Sulston, John E.</dc:contributor>
<dc:contributor>Evans, R. J.</dc:contributor>
<dc:contributor>International Human Genome Sequencing
Consortium</dc:contributor>
<dc:contributor>Loughborough University. Department of
Computer Science</dc:contributor>
Date (Data)
Nome do Date
elemento
Definição A data associada a um evento no ciclo de vida do recurso. Normalmente,
DCMI a Data está associada à criação ou disponibilização do recurso. A prática
recomendada para codificar o valor data é definido na norma ISO 8601
[W3CDTF] e segue o formato YYYY-MM-DD.
Uso Obrigatório
Instruções O formato da data deverá estar de acordo com as W3C encoding rules
de uso for dates and times:
70/144 estado: final 2008-11-13

Data completa:
- YYYY-MM-DD (ex. 1997-07-16)
onde:
- YYYY [ano com quatro dígitos] é obrigatório
- MM [mês com dois dígitos (01=Janeiro, etc.)] é opcional
- DD [dia do mês com dois dígitos (de 01 até 31)] é opcional
Um campo de data – Data de publicação:

Frequentemente os repositórios possuem mais do que um campo data
com diferentes propósitos. Data de criação, publicação, modificação,
promoção, etc. O DC não qualificado não é capaz de expressar todas
essas datas, e do ponto de vista do utilizador final gera confusão a
obtenção de mais datas a partir do fornecedor de serviços. O fornecedor
de serviços deve efectuar uma escolha do campo data que pretende
expor. Preferencialmente, na perspectiva dos utilizadores finais a data
mais lógica e significativa é a data de publicação.
Para reduzir a ambiguidade da existência de um número de campos data
sem qualificador, recomendamos a redução do número de campos e
apresentar a data mais significativa ao fornecedor de serviços. Na
maioria dos casos, esta é a data da publicação. Em outros casos, esta é a
data de defesa de uma tese/dissertação.
A data de publicação não está disponível:

Se a data de publicação não está disponível, utilize outra data. É melhor
usar uma data do que nenhuma.
Datas de registo adicionais:

Extras como “Zulu time” NÃO deverão constar nos metadados.
Datas imprecisas:
Para datas imprecisas utilizar um ano lógico que melhor represente o
período em causa, ex. "1650" ao invés de “Século 17”
71/144 estado: final 2008-11-13

Para expressar mais acerca desse período temporal, podemos utilizar o
campo dc:coverage. Um período temporal pode ser expresso numa
forma padronizada quando definido precisamente (ver Coverage
(Cobertura)) ou quando “imprecisa” ou incerta por expressões de texto
livre.
Um fornecedor de serviços é capaz de ordenar datas com base em
padrões de datas como W3CDTF. Como não existe norma para termos de
datas imprecisas como "Renascença" ou "Século 17", estes simplesmente
não aparecerão nos resultados de pesquisa de data.
Não
confundir
com
Esquema ISO 8601 [W3CDTF] http://www.w3.org/QA/Tips/iso-date
Exemplos <dc:date>2000-12-25</dc:date>
<dc:date>1978-02</dc:date>
<dc:date>1650</dc:date>
Type (Tipo)
Nome do Type
elemento
Definição O tipo de resultado científico do qual o recurso é uma manifestação. No
DCMI elemento DC „type‟, descreve-se o tipo de divulgação ou o tipo de
conteúdo intelectual do recurso. Utiliza-se para explicar ao utilizador
que tipo de recurso está a visualizar. Se é um livro ou um artigo. Se foi
escrito para uso interno ou externo. etc.
Uso O elemento DC „type‟ é utilizado com três propósitos:
1. Obrigatório: Tipo de publicação (controlado): para indicar o tipo
de publicação baseado no vocabulário controlado de tipo de
publicações DRIVER,
2. Opcional: Tipo de publicação (livre): para indicar o tipo de
publicação baseado num vocabulário de repositório local
3. Recomendado: Versão (controlado): para indicar o estado do
72/144 estado: final 2008-11-13

processo de publicação.
Instruções 1. Tipos de publicação (controlado):
de uso
A primeira ocorrência do elemento DC 'type' é obrigatória e deverá ser
utilizada para a indicação do tipo de produção científica baseada no
vocabulário de tipos DRIVER. Utilizar a sequência exacta de caracteres
conforme apresentado na lista em baixo. Os termos são explicados em
detalhe no capítulo sobre vocabulários e semânticas. Info:eu-repo é um
espaço de nome (namespace) onde os tipos de publicação DRIVER são
registados.
 info:eu-repo/semantics/article
 info:eu-repo/semantics/bachelorThesis
 info:eu-repo/semantics/masterThesis
 info:eu-repo/semantics/doctoralThesis
 info:eu-repo/semantics/book
 info:eu-repo/semantics/bookPart
 info:eu-repo/semantics/review
 info:eu-repo/semantics/conferenceObject
 info:eu-repo/semantics/lecture
 info:eu-repo/semantics/workingPaper
 info:eu-repo/semantics/preprint
 info:eu-repo/semantics/report
 info:eu-repo/semantics/annotation
 info:eu-repo/semantics/contributionToPeriodical
 info:eu-repo/semantics/patent
 info:eu-repo/semantics/other
2. Tipos de publicação (texto livre):
A segunda ocorrência do elemento DC 'type' é opcional e deverá ser

utilizada para indicar o subtipo da produção científica.
3. Versão (controlado):
73/144 estado: final 2008-11-13

A última ocorrência do elemento DC 'type' é recomendada e deverá ser
utilizada para indicar a versão da produção científica baseada no
vocabulário de versões DRIVER. Utilizar o texto exacto conforme
apresentado na lista em baixo. Para mais informação sobre o modelo de
versões ver: http://www.lse.ac.uk/library/versions/
 info:eu-repo/semantics/draft
 info:eu-repo/semantics/submittedVersion
 info:eu-repo/semantics/acceptedVersion
 info:eu-repo/semantics/publishedVersion
 info:eu-repo/semantics/updatedVersion
Mapeamento e conversão retrospectiva:
Para o mapeamento dos tipos DRIVER a partir das Directrizes DRIVER 1.0
ver Mapeamento de tipos DRIVER.
Não  Format
confundir
com O elemento DC „type‟ descreve o tipo de produção académica do qual o
recurso é uma representação. O elemento DC „format‟ descreve o tipo
de meio do recurso.
Esquemas Tipos de publicação: ver a secção Vocabulário tipo de publicações na
página 121 no capítulo “Uso de vocabulários e semânticas”.
Vocabulário de versões: ver a secção Vocabulário de versões na página

126 no capítulo “Uso de vocabulários e semânticas”.
Mapeamento: ver a secção Mapeamento de tipos DRIVER na página 87 no

capítulo “Uso das práticas recomendadas com OAI_DC”.
Exemplos <dc:type>info:eu-repo/semantics/article</dc:type>
<dc:type>info:eu-repo/semantics/publishedVersion</dc:type>
ou
<dc:type>info:eu-repo/semantics/other</dc:type> 
<dc:type>image</dc:type>
74/144 estado: final 2008-11-13

<dc:type>info:eu-repo/semantics/updatedVersion</dc:type> <!-
-3-->
Format (Formato)
Nome do Format
elemento
Definição Manifestação física ou digital do recurso. Normalmente, o elemento
DCMI „Format‟ pode incluir o tipo de meio ou as dimensões do recurso. O
elemento „Format‟ pode utilizar-se para determinar o software, o
hardware ou outro equipamento necessário para mostrar ou operar o
recurso. Exemplos de dimensões são o tamanho e a duração. A prática
recomendada é seleccionar um valor de um vocabulário controlado (por
exemplo, a lista de tipos de meios da Internet [MIME] que define os
formatos para os equipamentos informáticos).
Uso Recomendado
Instruções Baseado em práticas recomendas, utiliza-se a lista registada da IANA de
de uso tipos de meios da Internet (tipos MIME) para seleccionar uma designação.
Para a lista completa ver o esquema de localização em baixo. Em seguida
apresenta-se uma lista de IANA MIME types:
Tipo Subtipo
text  plain
 richtext
 enriched
 tab-separated-values
 html
 sgml
 xml
application  octet-stream
 postscript
 rtf
 applefile
75/144 estado: final 2008-11-13

 mac-binhex40
 wordperfect5.1
 pdf
 vnd.oasis.opendocument.text
 zip
 macwriteii
 msword
 sgml
 ms-excel
 ms-powerpoint
 ms-project
 ms-works
 xhtml+xml
 xml
image  jpeg
 gif
 tiff
 png
 jpeg2000
 sid
audio  wav
 mp3
 quicktime
video  mpeg1
 mpeg2
 mpeg3
 avi
Se um recurso específico (uma instância de um documento científico) tem
mais de um formato físico (por exemplo, postscript e pdf) armazenados
como ficheiros de objecto distintos, todos os formatos deverão ser
mencionados no elemento DC „format‟, por exemplo:
 <dc:format>application/pdf</dc:format>
76/144 estado: final 2008-11-13

 <dc:format>application/postscript</dc:format>
 <dc:format>application/vnd.oasis.opendocument.text</dc:format>
Não  Type
confundir  Identifier
com
O elemento DC „format‟ descreve o tipo de meio do recurso. O elemento
DC „type‟ descreve o tipo de resultado/publicação científica do qual o
recurso é uma manifestação. O elemento DC „identifier‟ e utilizado para
representar manifestações de recursos digitais.
Esquema the IANA registered list of Internet Media Types (MIME types) -
http://www.iana.org/assignments/media-types/
Exemplos <dc:format>video/quicktime</dc:format>
<dc:format>application/pdf</dc:format>
<dc:format>application/xml</dc:format>
<dc:format>application/xhtml+xml</dc:format>
<dc:format>application/html</dc:format>
<dc:format>application/vnd.oasis.opendocument.text</dc:format>
Identifier (Identificador)
Nome do Identifier
elemento
Definição Referência inequívoca do recurso num contexto determinado.
DCMI
Uso Obrigatório
Instruções Recomenda-se a identificação do recurso mediante uma sequência ou
de uso número de acordo com um sistema de identificação formal. Alguns
exemplos de sistemas de identificação formal incluem o Uniform Resource
Identifier (URI) (incluindo o Uniform Resource Locator (URL), o Digital
Object Identifier (DOI) e o URN:NBN
O uso ideal deste elemento consiste na utilização de uma hiperligação

directa (URL persistente) do dc:identifier no registo de metadados a um
77/144 estado: final 2008-11-13

recurso digital ou uma página de transição (jump-off-page).
Prática recomendada:
# utilizar URL's estáveis
 apresentar todos os identificadores que conseguir encontrar.

o (URL, DOI, URN:NBN, ISBN, ISSN, etc.)
 colocar o identificador "mais adequado" sob a forma de um URL no
topo da lista dos identificadores. Em quase todos os casos, este é o
único que será utilizado por um fornecedor de serviços para permitir
que um utilizador final o cite. Pode ser uma hiperligação para uma
página de transição (jump-off-page) ou um link directo para o ficheiro.
Também pode ser um URL directo, ou um URL de redireccionamento,
como PURL, HANDLE ou outros mecanismos internacionais de
resolução.
Não  dc:relation (Utilizar dc:relation para relacionar uma versão do
confundir recurso com outra.)
com  dc:source (Utilizar dc:source para citação bibliográfica do recurso
de origem.)
Exemplos Neste exemplo, os identificadores são ordenados e os URL's são
apresentados em primeiro lugar. O primeiro URL será considerado "mais
apropriado" e será utilizado por exemplo no DRIVER para deixar um
utilizador final redireccionar. Neste caso, o handle redirecciona para a
página de transição (jump-off-page). A página de transição é uma boa
forma de citar. O utilizador final tem a oportunidade de ver mais
informações sobre o(s) objecto(s) que encontrou, ver o contexto e
desfrutar de outros serviços que um repositório local tem para oferecer.
<oai_dc:dc>
...
<dc:identifier>http://hdl.handle.net/1234/5628
</dc:identifier>
<dc:identifier>http://arno.unimaas.nl/show.cgi?fid=5628
</dc:identifier>
<dc:identifier>http://n2t.info/urn:nbn:nl:ui:14-
78/144 estado: final 2008-11-13

123456789</dc:identifier>
<dc:identifier>urn:nbn:nl:ui:13-123456789</dc:identifier>
<dc:identifier>urn:isbn:123456789</dc:identifier>
<dc:identifier>info:doi:10-123456789</dc:identifier>
...
</oai_dc:dc>
Source (Fonte)
Nome do Source
elemento
Definição Referência a um recurso do qual deriva o recurso actual.
DCMI
Uso Opcional
Instruções O recurso actual pode derivar total ou parcialmente do recurso fonte
de uso (Source). A prática recomendada consiste em referenciar o recurso
através de uma sequência ou um número em conformidade com um
sistema de identificação formal.
Prática recomendada: Utilizar apenas se o recurso descrito for resultado

da digitalização de originais não digitais. Caso contrário, utilizar o
elemento „Relation‟. Opcionalmente, podem-se adicionar metadados
sobre a localização actual e número de registo da publicação
digitalizada.
Utilizar: Guidelines for Encoding Bibliographic Citation Information in

Dublin Core Metadata ([http://dublincore.org/documents/dc-citation-
guidelines/]).
Não  dc:relation
confundir  dc:identifier
com
Exemplos <dc:source>Ecology Letters (1461023X) vol.4
(2001)</dc:source>
<dc:source>ISSN: 0928-0987</dc:source>
79/144 estado: final 2008-11-13

Language (Idioma)
Nome do Language
elemento
Definição Idioma do conteúdo intelectual do recurso.
DCMI
Uso Recomendado
Instruções Um recurso específico (uma instância de um resultado/publicação
de uso científica) é escrito num ou vários idiomas humanos. Nestes casos, todos
os idiomas utilizados são descritos no elemento DC „language‟. Se um
recurso específico (uma instância de um resultado/publicação científica)
está escrito numa linguagem humana e é traduzido para outros idiomas
legíveis, as traduções diferenciam-se da versão original e por conseguinte
são descritas separadamente.
Recomendado: ISO 639-x, onde x pode ser 1,2 ou 3.
Prática recomendada: Utilizamos a norma ISO 639-3 e ao fazê-lo

seguimos o que está estipulado em:
[http://www.sil.org/ISO639-3/codes.asp]
Se necessário, repetir este elemento para indicar diferentes idiomas.
Se ISO 639-2 e 639-1 forem suficientes para os conteúdos de um

repositório podem ser usadas alternadamente. Uma vez que existe um
único mapeamento isto pode ser efectuado durante um processo de
agregação.
Não  Código de países ISO 3166-1
confundir http://www.iso.org/iso/country_codes/iso_3166_code_lists/
com english_country_names_and_code_elements.htm
Esquema ISO 639-3 http://www.sil.org/ISO639-3/codes.asp
Exemplos <dc:language>eng</dc:language>
<dc:language>deu</dc:language>
80/144 estado: final 2008-11-13

<dc:language>nld</dc:language>
<dc:language>nld/dut</dc:language>
<dc:language>dut</dc:language>
<dc:language>nl</dc:language>
Relation (Relação)
Nome do Relation
elemento
Definição Referência a um recurso relacionado.
DCMI
Uso Opcional
Instruções A prática recomendada consiste em relacionar o recurso através de uma
de uso sequência ou um número em conformidade com um sistema de
identificação formal. O elemento DC „relation‟ pode ser utilizado para
indicar distintos tipos de relações entre vários registos de metadados. Se
as relações entre os registos de metadados se tornam visíveis através do
uso de metadados o seguinte serve para a distinção entre versões (versão
do autor e versão da editor, preprint, postprint, etc.):
 Um registo de metadados contém-se em si mesmo

 Diferentes manifestações do mesmo recurso (uma instância de um
resultado/publicação cientifica que pode descrever-se
exactamente com os mesmos metadados bibliográficos, excepto
no elemento DC „format‟) são ligadas a um único registo de
metadados utilizando dc:relation.
Outras alterações nos metadados para além do elemento DC „format‟

implicam a criação de um novo registo de metadados para esta nova
instância do resultado/publicação científica, que cumpre todos requisitos
formulados neste documento e tem um valor no elemento DC „relation‟.
Não dc:identifier e dc:source.
confundir
81/144 estado: final 2008-11-13

com
Exemplos <dc:relation>http://hdl.handle.net/10 </dc:relation>
O valor de dc:relation é o identificador de outro documento.
Ligando dois documentos:

---Documento A:---
<dc:type>info:eu-repo/semantics/submittedVersion</dc:type>
<dc:identifier> http://hdl.handle.net/10</dc:identifier>
<dc:relation>http://hdl.handle.net/20</dc:relation>
---Documento B:---
<dc:type>info:eu-repo/semantics/acceptedVersion</dc:type>
<dc:identifier> http://hdl.handle.net/20</dc:identifier>
<dc:relation>http://hdl.handle.net/10</dc:relation>
Coverage (Cobertura)
Nome do Coverage
elemento
Definição Extensão ou âmbito do conteúdo do recurso. Normalmente, a cobertura
DCMI inclui a localização espacial (nome do lugar ou coordenadas geográficas),
um período temporal (etiqueta de período, data ou intervalo de datas) ou
a jurisdição (por exemplo, o nome de uma entidade administrativa).
Uso Opcional
Instruções A prática recomendada consiste na selecção do valor de um vocabulário
de uso controlado (por exemplo, o Getty Thesaurus of Geographic Names ou
TGN) e quando for apropriado, utilizar preferencialmente nomes de
locais ou períodos de tempo em vez de identificadores numéricos, como
por exemplo, conjuntos de coordenadas ou intervalos de datas. Se
necessário, repetir este elemento para inserir múltiplas localizações ou
períodos.
Não
confundir
com
82/144 estado: final 2008-11-13

Esquema  ISO 3166 [http://www.iso.ch/iso/en/prods-
services/iso3166ma/02iso-3166-code-lists/index.html]
 Box [http://dublincore.org/documents/dcmi-box/]
 TGN [http://www.getty.edu/research/tools/vocabulary/tgn/]
 DCMI Period
[http://dublincore.org/documents/2000/07/28/dcmi-period/]
Exemplos Exemplo espacial: ISO 3166

<dc:coverage>NL</dc:coverage>
Exemplo espacial: BOX

<dc:coverage> name=Western Australia; northlimit=-13.5;
southlimit=-35.5; westlimit=112.5;
eastlimit=129</dc:coverage>
Nota sobre BOX: A sintaxe utilizada aqui é provisória e encontra-se

actualmente em processo de revisão como parte do trabalho da DCMI
para produzir recomendações sintácticas de coordenadas para HTML,
XML, e RDF. Estas recomendações e alterações editoriais mínimas serão
repercutidas neste documento futuramente. Apontar
http://dublincore.org/documents/dcmi-point/
Rights (Direitos)
Nome do Rights
elemento
Definição Informação sobre os direitos no recurso e sobre o recurso.
DCMI
Uso Recomendado
Instruções Normalmente, o elemento „Rights‟ conterá uma declaração dos direitos
de uso para aceder ou utilizar o objecto ou uma referência a um serviço que
proporcione essa informação. A informação de direitos abrange,
frequentemente, direitos de propriedade intelectual, copyright e outros
83/144 estado: final 2008-11-13

direitos de propriedade.
É preferível referir-se a um serviço de direitos onde os direitos de

reutilização são claros para o utilizador final utilizando um URL. Por
exemplo, a organização Creative Commons criou URIs para as suas
diversas licenças nas diferentes jurisdições. Isto pode ser aplicado para
criar licenças para leitura automática por computador.
Não
confundir
com
Exemplos <dc:rights>(c) University of Bath, 2003</dc:rights>
<dc:rights>(c) Andrew Smith, 2003</dc:rights>
O uso de licenças Creative Commons torna o uso de direitos de utilização

muito mais claros para o utilizador final. Para mais informação ver Use of
Intellectual Property Rights. Neste caso, Andrew Smith, utilizando a
licença: http://creativecommons.org/licenses/by-sa/2.0/uk/


<dc:rights>http://creativecommons.org/licenses/by-
sa/2.0/uk/</dc:rights>
O URL aponta para a localização onde a licença pode ser lida. Com
licenças Creative Commons o tipo de licença pode ser reconhecido na
própria denominação do URL. A vantagem de possuir uma licença que
aponte para um URL desta forma, é a de ser usada automaticamente por
computador.


<dc:rights>cc-by-sa, Andrew Smith</dc:rights>
A sequência cc-by-sa fornece o tipo de licença em sentido bruto. O nome
é a pessoa ou parte à qual os direitos se aplicam.


<dc:rights>cc-by-sa, info:eu-repo/dai/nl/344568</dc:rights>
ou
<dc:rights>cc-by-nc-sa, urn:isni:234562-2</dc:rights>
Também um DAI (Digital Author Identifier) ou ISNI (International Standard
84/144 estado: final 2008-11-13

Name Identifier) podem ser utilizados a nível mundial para identificar
pessoas e organizações e relacionar estes nomes com os direitos
apropriados.
Audience (Público)
Nome do Audience
elemento
Definição Um tipo de entidade para a qual o recurso é dirigido ou útil.
DCMI
Uso Opcional
Instruções Um tipo de entidade poderá ser determinado pelo autor ou editor ou por
de uso um terceiro. No website Metadata Reference do U.S. Department of
Education, são apresentados exemplos de públicos:
http://www.ed.gov/admin/reference/index.jsp
 Administrators
 Community Groups
 Counsellors
 Federal Funds Recipients and Applicants
 Librarians
 News Media
 Other
 Parents and Families
 Policymakers
 Researchers
 School Support Staff
 Student Financial Aid Providers
 Students
 Teachers
Não
confundir
com
85/144 estado: final 2008-11-13

Exemplos <dc:audience>Researchers</dc:audience>
<dc:audience>Students</dc:audience>
86/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Uso das práticas recomendadas para OAI_DC
Uso das práticas recomendadas com

OAI_DC
Este capítulo aborda problemas comuns com que os administradores de repositórios se
deparam no processo de instalação de um repositório. Estas práticas não são
obrigatórias, mas constituem a melhor solução possível para problemas comuns. Estas
soluções provêm de boas práticas de outros administradores repositório que já lidaram
com estes tipos de problemas anteriormente. O principal foco aqui é a
interoperabilidade e facilidade de implementação em termos do ciclo de vida do
processo de comunicação científica.
Mapeamento de tipos DRIVER
Mapeamento de listagens de outros tipos de Publicação com o que é apresentado na

secção Vocabulário tipo de publicações na página 121 no capítulo “Uso de
vocabulários e semânticas”. Nessa secção pode-se encontrar definições detalhadas dos
termos utilizados nesses vocabulários para efectuar mapeamentos à medida.
87/144 estado: final 2008-11-13

Mapeamento de tipos DRIVER v1.1 para tipos DRIVER v2.0
Apresenta-se em seguida o mapeamento entre os tipos de documentos utilizados na

versão 1.1 da Directrizes DRIVER comparados com os tipos da versão 2.0 das
Directrizes DRIVER.
Tipos DRIVER v1.0 mapeado Tipos DRIVER v2.0

para
Article >> article
Bachelor thesis >> bachelorThesis
Master thesis >> masterThesis
Doctoral thesis >> doctoralThesis
Book >> book
Part of book or chapter of book >> bookPart
inexistente nos tipos DRIVER v1.1! >> review
Conference lecture >> conferenceObject
Conference report >> conferenceObject
Lecture >> lecture
Research paper >> preprint or
workingPaper
External research report >> report
Internal report >> report
inexistente nos tipos DRIVER v1.1! >> annotation
Contribution for newspaper or weekly >> contributionToPeriodical
magazine
Newsletter >> contributionToPeriodical
inexistente nos tipos DRIVER v1.1! >> patent
inexistente nos tipos DRIVER v1.1! >> other
Mapeamento de vocabulário de tipos E-Print para tipos DRIVER v2.0
Apresenta-se em seguida o mapeamento entre os tipos de documentos utilizados no

vocabulário e-print comparados com os da versão 2.0 das Directrizes DRIVER.
88/144 estado: final 2008-11-13

Como apresentar um artigo com 2 ficheiros de objecto, um primeiro „aceite para
publicação‟, um segundo a versão „publicada‟?
Vocabulário de tipos e-print mapeado Tipos DRIVER v2.0 Versões

para DRIVER
JournalArticle >> article aceite /
publicado /
actualizado
JournalItem >> article aceite /
publicado /
actualizado
SubmittedJournalArticle >> preprint ou workingPaper submetido
Thesis (sentido lato) >> bachelorThesis
Thesis (sentido lato) >> masterThesis
Thesis (sentido lato) >> doctoralThesis
Book >> book
BookItem >> bookPart
BookReview >> review
ConferencePaper >> conferenceObject
ConferenceItem >> conferenceObject
ConferencePoster >> conferenceObject
inexistente no vocabulário >> lecture
de tipos e-print!
WorkingPaper >> workingPaper
ScholarlyText >> other ??? (demasiado
genérico)
Report (sentido lato) >> report
inexistente no vocabulário >> annotation
de tipos e-print!
NewsItem >> contributionToPeriodical
Patent >> patent
inexistente no vocabulário >> other
de tipos e-print!
89/144 estado: final 2008-11-13

Mais informação sobre o vocabulário de tipos e-print pode ser encontrada em:
http://purl.org/eprint/type/
Mapeamento de versões DRIVER
Em seguida apresenta-se o mapeamento do esquema de versões DRIVER

comparativamente com outras versões de esquemas da comunidade mundial de
bibliotecas e repositórios. Mais informação sobre versões DRIVER na secção
Vocabulário de versões na página 126 no capítulo “Uso de vocabulários e
semânticas”.
Mapeamento de tipos de versões Eprints para tipos de versão

DRIVER v2.0
Apresenta-se em seguida o mapeamento entre os tipos de versões dos documentos

utilizados no Eprints comparados com os da versão 2.0 das Directrizes DRIVER.
Versões e-print mapeado para Versões Directrizes DRIVER v2.0

non-peer reviewed >> draft
non-peer reviewed >> submittedVersion
peer reviewed >> acceptedVersion
peer reviewed >> publishedVersion
peer reviewed >> updatedVersion
Termos comuns de tipo de versões para tipos de versões DRIVER

v2.0
Apresenta-se em seguida o mapeamento entre os tipos de documentos usados em

termos científicos comuns comparados com os da versão 2.0 das Directrizes DRIVER.
90/144 estado: final 2008-11-13

Versões tradicionais mapeado para Versões Directrizes DRIVER v2.0
Working paper >> draft
Pre print >> submittedVersion
Post print >> acceptedVersion
Journal article >> publishedVersion
Reprint >> updatedVersion
Mapeamento dos tipos de versões do grupo de trabalho técnico

Journal Article Versions (JAV) para os tipos de versões das
Directrizes DRIVER v2.0
Estas recomendações proporcionam uma forma simples e prática de descrever as

versões dos artigos científicos de revistas que tipicamente aparecem online antes,
durante e após a publicação formal em revistas. Os termos recomendados e definições
para versões de artigos de revista (JAV) em sete etapas.
JAV mapeado para Versões Directrrizes DRIVER v2.0

Author‟s Original >> draft
Submitted Manuscript Under >> submittedVersion
Review
Accepted Manuscript >> acceptedVersion
Proof >> acceptedVersion
Version of Record >> publishedVersion
Corrected Version of Record >> publishedVersion
Enhanced Version of Record >> updatedVersion
Mais informação sobre JAV: http://www.niso.org/publications/rp/RP-8-2008.pdf
91/144 estado: final 2008-11-13

Uso do OAI_DC com teses
Esta recomendação é baseada no relatório do estudo: "A PORTAL FOR DOCTORAL E-

THESES IN EUROPE; Lessons Learned from a Demonstrator Project"
Este estudo visa serviços genéricos de comunicação científica que recolham OAI_DC.
No contexto específico de serviços e-teses recomendamos a utilização de outros
esquemas de metadados, para além do OAI_DC onde todos os aspectos relativos a e-
teses sejam proporcionados.
A prática comum quando se utiliza o OAI_DC dc:type com o conteúdo "info:eu-

repo/semantics/doctoralThesis", é a de que deve tomar particular atenção ao
seguinte:
 O campo dc:date field deve conter sempre a data de publicação (não a data
de defesa. A data de defesa é significativa em contextos específicos de serviços
de e-teses)
 Utilizar apenas um campo data. Mais campos de data serão considerados
ambíguos, porque o DC não comporta a especificação de outros tipos de datas.
 O campo dc:contributor deve conter sempre o nome do orientador.
(Utilizando campos contributor com nomes de outros perfis será considerado. O
DC não comporta a especificação de outros perfis de contributor.)
 Os restantes campos deverão seguir exactamente as Directrizes DRIVER. Ter em
atenção que o campo dc:language dever estar preferencialmente codificado em
iso639-3. Notar por favor que campo dc:identifier é o único que contém um
URL que aponta para um documento com o texto integral de uma tese ou uma
página intermédia de acesso livre ao documento com o texto integral de uma
tese. O campo dc:date deve estar de acordo com a norma ISO8601 (YYYY-MM-
DD). Os campos dc:creator e dc:contributor são formatados seguindo o estilo
"apelido, nome".
92/144 estado: final 2008-11-13

Exemplo
Nesta secção é apresentado um exemplo para uma tese electrónica. Neste caso é uma
"Habilitation" um tipo de tese alemã que é usada quando uma pessoa se torna
Professor. Este é um trabalho académico que é considerado ainda mais do que uma
Tese de Doutoramento na Alemanha. Nas Directrizes DRIVER apenas suportamos os
termos utilizados na convenção de Bolonha, para que o gestor de repositório possa
usar a regra "tudo igual e superior a uma Tese de doutoramento será colocado na
categoria doctoralThesis". Nas Directrizes DRIVER é permitido colocar a informação
adicional "habilitation", com o intuito de manter particularidades locais.
Para mais informação sobre os termos do nível de diploma ver:

http://en.wikipedia.org/wiki/Diplom
O XML que é usado pode assemelhar-se ao seguinte (os comentários entre 
não deve estar for a do XML, mas servem como uma ajuda de leitura.):
<oai_dc:dc >
<dc:title>Mixing Oil and Water : </dc:title>
<dc:creator>Stage, Jesper</dc:creator> 
<dc:date>2003-12-02</dc:date> 
<dc:contributor>Crane, Walter</dc:contributor> 
<dc:type>info:eu-repo/semantics/doctoralThesis</dc:type> 
<dc:type>habilitation</dc:type> 
<dc:type>info:eu-repo/semantics/publishedVersion</dc:type> 
<dc:identifier>http://some.url.to/the_jump-off_page.html
</dc:identifier>
...
</oai_dc:dc>
DC:SOURCE e informação de citação
Nas publicações utilizar o campo DC:SOURCE para inserir informação que uma pessoa
possa utilizar para efectuar uma citação do registo que encontrou. Utilizar
preferencialmente o estilo APA para elaborar referências.
Por exemplo
<dc:source>Ecology Letters (1461023X), vol.4 (2001)</dc:source>
DC:RELATION e hiperligação de objectos

relacionados
O campo DC:RELATION pode ser usado tipicamente para descrever relações para
outras expressões ou versões do documento.
Por exemplo a versão publicada de um artigo e a versão de autor de um artigo. Estas

podem ser referenciadas mutuamente através da utilização do identificador "mais
apropriado” que é accionável (URL). Por exemplo:
Este registo com ID 1111, é um trabalho que foi submetido para revisão
científica. Este trabalho possui uma relação com o artigo com revisão
científica com o ID 2222.
94/144 estado: final 2008-11-13

<oai_dc:dc >
<de:identifier>http://hdl.handle.net/1234/1111</dc:identifier>
<dc:type>info:eu-repo/semantics/paper</dc:type>
<dc:type>info:eu-repo/semantics/submittedVersion</dc:type>
<dc:relation>http://hdl.handle.net/1234/2222</dc:relation>
</oai_dc:dc>
O seguinte registo de metadados apresenta o registo do artigo com o ID

2222. Este artigo possui uma relação com o trabalho submetido.
<oai_dc:dc >
<de:identifier>http://hdl.handle.net/1234/2222</dc:identifier>
<dc:type>info:eu-repo/semantics/article</dc:type>
<dc:type>info:eu-repo/semantics/publishedVersion</dc:type>
<dc:relation>http://hdl.handle.net/1234/1111</dc:relation>
</oai_dc:dc>
95/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Uso de MPEG-21 DIDL (xml-container)
Uso de MPEG-21 DIDL (xml-container)

– Empacotamento do objecto composto
Introdução e Objectivo
Este documento é um anexo ao documento de especificação DIDL existente para

repositórios utilizado presentemente pelas universidades holandesas, na Koninklijke
Bibliotheek, Biblioteca Nacional da Holanda e no DAREnet. O objectivo deste
documento é clarificar o uso do DIDL de forma inequívoca através da descrição da:
1. A natureza das diferentes partes de “metadados”, “objectos” e “ páginas de

transição”
2. O que é identificação
3. O que é data de modificação
Quando usada correctamente, esta especificação irá criar um registo XML MPEG-21
DIDL válido para uso com respostas OAI-PMH. Esta especificação de documento DIDL
para repositórios é baseada em decisões propostas inicialmente durante o
desenvolvimento deste formato XML para utilizar MPEG-21 DIDL. A proposta constituiu
um esboço de um formato de empacotamento (wrapper) com espaço para recursos de
96/144 estado: final 2008-11-13

metadados, objectos e páginas de transição. Esta especificação é um trabalho de maior
precisão.
Contextualização
O DIDL foi originalmente desenvolvido no âmbito do programa DARE promovido pelo

SURF como uma primeira implementação de MPEG-21 DIDL. Os motivos para este
desenvolvimento foram:
 Uma solução para a recolha (harvesting) de recursos mediante o protocolo OAI-

PMH para transportar recursos digitais (PDF‟s etc.) desde repositórios locais
para a Biblioteca Nacional para introduzir os recursos num sistema de depósito
electrónico para a sua preservação a longo prazo
 Uma solução para recolha de recursos mediante o protocolo OAI-PMH para
transportar recursos digitais (PDF‟s etc.) desde repositórios locais para
fornecedores de serviços (ex. um portal de pesquisa que indexe documentos de
texto integral)
 Uma solução (parcial) para representar documentos complexos. Numa primeira
fase focada em teses que possuam vários ficheiros de recursos digitais
 Uma solução para evitar a utilização confusa do elemento dc:identifier no
caso de uma hiperligação a uma página de transição (jump-off-page (JOP)).
Muitos repositórios colocam uma hiperligação para uma página de transição no
elemento dc:identifier ao invés de inserir uma hiperligação directa ao ficheiro
do recurso digital.
O DIDL está em uso no DARE desde o verão de 2006. Um dos resultados é que conteúdo
de todos os repositórios holandeses faz agora parte do E-Depot da Koninklijke
Bibliotheek, Biblioteca Nacional dos Países Baixos.
Resposta OAI com um documento DIDL
O documento DIDL faz parte de uma resposta OAI-PMH. O documento DIDL será
devolvido dentro de um registo OAI quando se utiliza didl como valor do pedido
metadataPrefix. Isto permite que o repositório possa gerar o formato DIDL concreto
97/144 estado: final 2008-11-13

que se descreve no documento em baixo. Na estrutura XML do OAI, o DIDL reside no
elemento metadados. Ver em baixo:
<OAI-PMH ...>
...
<request ... metadataPrefix="didl_document">
...
<record>
<header>...</header>
<metadata>
<didl:DIDL
...
</didl:DIDL>
</metadata>
<about>...</about>
</record>
...
</OAI-PMH>
Observações:
1. Não esquecer a etiqueta DIDL na resposta OAI-PMH.
98/144 estado: final 2008-11-13

2. Produza uma declaração dos espaços de nome (namespaces) didl, dii, dip e
dcterms aqui, na etiqueta DIDL. Estes espaços de nome são necessários ao
longo de todo o documento DIDL. Não crie estes espaços de nome na etiqueta
<OAI-PMH>, porque a razão de ser de um documento DIDL é a possibilidade de
existir fora do contexto do protocolo OAI-PMH como uma entidade autónoma.
3. O elemento about é opcional no protocolo OAI-PMH
DIDL como invólucro ou empacotador (wrapper)
O DIDL XML container, conforme definido no DRIVER, é um documento com um

elemento Item ao nível superior. O Item contém vários elementos Item derivados.
Estes elementos derivados aparecem em três tipos distintos. Em seguida, entre
parênteses mostra-se a cardinalidade dos elementos XML:
<metadata>
DIDL[1..1]
<didl:DIDL ...>
Item[1..1]
<didl:Item> Item[1..∞] (of type 1 metadata)
Item[1..∞] (of type 2 objectFile)
Item[0..1] (of type 3 start page)
</didl:Item>
</didl:DIDL>
</metadata>
Elemento raiz: documento DIDL atributo de identificação
O elemento raiz DIDL contém um attribute; nomeadamente DIDLDocumentID. Este

attribute disponibiliza informação sobre o identificador do invólucro (wrapper) DIDL
como uma entidade autónoma. Este identificador NÃO serve para identificar o trabalho
intelectual, mas para identificar a serialização do DIDL XML.
<didl:DIDL
DIDLDocumentId="urn:nbn:nl:ui:10-15290" 
...
>
99/144 estado: final 2008-11-13

...
</didl:DIDL>
O atributo DIDLDocumentId contém o ID do invólucro (wrapper) DIDL. PODE coincidir

com o identificador OAI que se utiliza para obter um registo. O invólucro DIDL pode-se
utilizar como entidade autónoma fora do contexto OAI-PMH, porque um DIDL não é o
mesmo que um registo OAI. Futuramente, existe necessidade de identificadores
persistentes para objectos digitais (Obrigatório para o projecto OAI-ORE.).
No caso de bibliotecas, recomenda-se o uso de urn:nbn:{country code}:{isil library
code}15- {object id}. {object id} pode ser o número da base de dados. Recomenda-se o
armazenamento deste número num campo individual e não auto-gerá-lo a partir do
identificador (id) da base de dados, uma vez que uma actualização futura da base de
dados alterará estes números e a persistência pode ser perdida.
Observações:
1. Este DIDLDocumentId tem em primeiro lugar um identificador distinto do

identificador OAI para este registo. O motivo deve-se ao facto que um
documento DIDL é considerado uma entidade autónoma que pode existir fora de
um registo OAI de forma independente. Não obstante, para facilitar a
implementação operacional, permite-se o uso do identificador utilizado no
registo OAI se o registo OAI e o documento DIDL estiverem intrinsecamente
ligados.
Descritores de item (opcional)
Os elementos Item podem OPCIONALMENTE conter dois ou três elementos

Descriptor. Um elemento Descriptor descreve a data de modificação do elemento
Item. Para comparar elementos Item similares recolhidos na data de modificação,
deve-se adicionar um identificador.
Exemplo no nível um:
15
ISO/NP 15511: International Standard Identifier for Libraries and Related Organizations (ISIL)
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52666
100/144 estado: final 2008-11-13

<didl:DIDL ...>
<didl:Item>
<didl:Descriptor>...</didl:Descriptor> 
<didl:Descriptor>...</didl:Descriptor> 
...
</didl:Item>
</didl:DIDL>
Exemplo no nível dois; Tipo de objecto adicionado:
<didl:Item> 

<didl:Item> 
<didl:Descriptor>...</didl:Descriptor> 
<didl:Descriptor>...</didl:Descriptor> 
<didl:Descriptor>...</didl:Descriptor> 
...
</didl:Item>
...
</didl:Item>
</didl:DIDL>
Declaração Descriptor: Item 'Identifier'
O primeiro elemento Descriptor contém o ID dos elementos Item. Utiliza-se,

sobretudo, para identificar de forma exclusiva o objecto digital (por exemplo, com um
DOI). O ID empacota-se num Statement com um elemento DII Identifier. Por
exemplo:
101/144 estado: final 2008-11-13

<didl:Item>
<didl:Item>
<didl:Descriptor>
<dii:Identifier>urn:nbn:nl:ui:10-6748398729821</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
...
</didl:Item>
...
</didl:Item>
Observações:
1. No caso de elementos Item derivados do elemento Item raiz indica que este
elemento Identifier NÃO é igual ao OAI identifier ou DIDL identifier
utilizados.
2. O atributo Identifier do elemento Item raiz PODE coincidir com os
identificadores DIDL ou OAI Identifier, embora não seja recomendado
3. O espaço de nomes (namespace) para dii deve ser declarado na etiqueta DIDL.
4. O identificador DEVE ESTAR descrito, quando aplicável, como um URI.
Declaração Descriptor: Item 'modified'
O segundo Descriptor contém uma data de modificação. Quando algo muda dentro de
um elemento Item, este elemento data de modificação deve ser actualizado. Esta data
de modificação especifica-se mediante o elemento modified do espaço de nome
dcterms:
<didl:Item>
<didl:Item>
...
<didl:Descriptor>
<dcterms:modified>2006-12-20T10:29:12Z</dcterms:modified>
</didl:Statement>
102/144 estado: final 2008-11-13

</didl:Descriptor>
...
</didl:Item>
...
</didl:Item>
Observações:
1. Declarar o espaço de nomes dcterms na etiqueta DIDL

2. O formato da data é Zulu-time, o que significa que pode ser ordenado como
texto
3. Apenas pode haver um elemento Statement num elemento Descriptor, o que
significa que dii:identifier e dcterms:modified residem em elementos
Descriptor independentes.
Declaração Descriptor: Item „ObjectType‟
O terceiro descriptor contém o tipo de objecto. Este tipo de objecto aparece no

seguindo nível dos elementos Item. Noutras palavras: apenas se aplica em elementos
Item derivados do primeiro elemento Item. Este tipo de objecto especifica-se através
do elemento ObjectType do espaço de nomes de MPEG-21 Digital Item Processing (DIP)
que descreve uma arquitectura pertencente à disseminação dos Digital Item Documents
(DIDs).
<didl:Item>
<didl:Item>
...
<didl:Descriptor>
<dip:ObjectType>info:eu-repo/semantics/descriptiveMetadata
</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
...
</didl:Item>
...
</didl:Item>
103/144 estado: final 2008-11-13

Na secção Elemento composto: representação do trabalho complexo a
representação do trabalho complexo desta declaração tipo de objecto (ObjectType
statement) será mais elaborada.
Observações:
1. Declarar o espaço de nomes dip na etiqueta DIDL.

2. O elemento ObjectType na declaração Descriptor DEVE ESTAR descrito como
um URI.
3. A arquitectura de processamento que se utiliza para a disseminação aplicar-se-á
aos repositórios gerais europeus. O URI está localizado no info namespace
como info:eu-repo (http://info-uri.info/). Entretanto, utiliza-se como um
padrão não oficial no seio da comunidade DRIVER.
Elemento composto: representação do trabalho complexo
O elemento Item de topo contém pelo menos dois tipos de objectos (ObjectTypes)
obrigatórios do elemento Item. Estes tipos de objectos do Item são expressões do Item
raiz: um para os metadados e outro para o ficheiro do objecto digital (por exemplo, um
ficheiro PDF), tal como se descreve nos metadados. Opcionalmente, pode existir um
terceiro tipo de objecto do elemento Item para uma página de transição (jump-off-
page). Uma página de transição é uma página HTML intermédia que se utiliza para
apresentações legíveis para o ser humano quando um Item contém mais de um ficheiro
digital. Normalmente, esta situação ocorre com dissertações com ficheiros
independentes (ex. quando a tese consiste num agrupamento de artigos previamente
publicados). Também ocorre quando o fornecedor de conteúdo tem uma versão PDF,
MS Word DOC e HTML do mesmo artigo.
<didl:DIDL ...>
<didl:Item>
<didl:Item>...</didl:Item> 
<didl:Item>...</didl:Item> 
<didl:Item>...</didl:Item> 
</didl:Item>
</didl:DIDL>
104/144 estado: final 2008-11-13

O primeiro elemento Item contém os metadados como Dublin Core (DC) (obrigatório)
que é normalmente utilizado no formato OAI_DC de acordo com as directrizes de
metadados que pertencem a uma arquitectura Digital Item Processing. O segundo
elemento Item contém uma ou mais ligações para os objectos digitais e o terceiro Item
contém uma hiperligação para uma página de transição.
<didl:Item>
<didl:Item> 
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
...
</didl:Item>
<didl:Item> 
<didl:Descriptor>
repo/semantics/objectFile</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
...
</didl:Item>
<didl:Item> 
<didl:Descriptor>
<dip:ObjectType>
info:eu-repo/semantics/humanStartPage</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
...
</didl:Item>
</didl:Item>
105/144 estado: final 2008-11-13

Os URI‟s serão processados sem ter em conta o uso de maiúsculas. Recomenda-se o uso
da escrita camelCase (maiusculasInterioresSemEspaços). É MUITO importante utilizar
exactamente a mesma combinação de caracteres, caso contrário, não será possível
realizar o processamento automático. Para conseguir a máxima clareza, utilizam-se os
seguintes URI‟s:
 info:eu-repo/semantics/descriptiveMetadata
(Este Item ocorre 1 ou várias vezes)
 info:eu-repo/semantics/objectFile
(Este Item ocorre 1 ou várias vezes)
 info:eu-repo/semantics/humanStartPage
(Este Item ocorre 0 ou 1 time)
Observações:
 O espaço de nomes (namespace) info:eu-repo é utilizado com a seguinte

sintaxe:
info:eu-repo/_type_/_identifier_
Para mais informação ver
http://info-uri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg&identifier=info:eu-repo/
 A semântica dos tipos de objecto (ObjectTypes) implica, por exemplo, que este
Item indique que o primeiro sub-Item tem ou contém metadados descritivos.
Tipo de objecto (objectType): Item de metadados
O primeiro elemento Item ObjectType contém os metadados. Os metadados são

introduzidos num elemento Resource. Cada elemento Resource contém o espaço de
nomes (namespace) de um formato de metatados que foi utilizado. Deste modo o
formato será reconhecido por fornecedores de serviço. De acordo com o protocolo OAI
é obrigatório utilizar 'oai_dc'. Para simplificar a implementação pode-se usar OAI_DC
como metadados, uma vez que OAI_DC é um requerimento básico do OAI-PMH. Cada
item de metadados pode, opcionalmente, ter o seu próprio elemento Identifier e
modified num elemento Descriptor:
106/144 estado: final 2008-11-13

<didl:Item>
<didl:Descriptor>
<dip:ObjectType>
info:eu-repo/semantics/descriptiveMetadata</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
1 <didl:Descriptor> 
<dii:Identifier>info:doi/10.1705/74836724783</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
2 <didl:Descriptor> 
</didl:Statement>
</didl:Descriptor>
<didl:Component>
3 <didl:Resource mimeType="application/xml"> 

<oai_dc:dc
xmlns:dc="http://purl.org/dc/elements/1.1/"
xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/
http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
<dc:creator>...</dc:creator>
<dc:creator>...</dc:creator>
<dc:title> ... </dc:title>
...
</oai_dc:dc>
</didl:Resource>
</didl:Component>
</didl:Item>
107/144 estado: final 2008-11-13

Observações:
1. (Obrigatório quando aplicável) Recomenda-se a identificação de cada

componente separado, para futura referência ou propósito de reconstrução.
Este conjunto de metadados possui o seu próprio identificador, que NÃO é o
mesmo do identificador DIDL.
2. Se a data dos metadados foi alterada, assegure-se que a data de modificação do
Item raiz também é modificada.
3. Declarar o espaço de nomes (namespace) dc na etiqueta de início do elemento
Resource no qual se utiliza se utiliza Dublin Core.
Tipo objecto (objectType): Item objecto
O segundo Item ObjectType contém uma hiperligação para um objecto digital. Isto é
sempre “by-reference” para limitar o tamanho do ficheiro, quando usada para
propósitos de transferência de metadados. (“by-value” é possível mas aumenta o
tamanho do ficheiro e toca no assunto da propriedade, usar codificação base64, não
exemplificada aqui), e o elemento Item possui uma declaração ObjectType com um
URI info:eu-repo/semantics/objectFile. Um Item objectFile pode ocorrer mais do
que uma vez. Ver o seguinte:
<didl:Item>
...

<didl:Item> 
<didl:Descriptor>
<dip:ObjectType>info:eu-repo/semantics/objectFile</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
...
<didl:Component>
<didl:Resource mimeType="application/pdf"
ref="http://my.server.nl/report.pdf"/></didl:Component>
108/144 estado: final 2008-11-13

</didl:Item>
<didl:Item> 
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
...
<didl:Component>
ref="http://my.server.nl/appendix.pdf"/><didl:Component>
</didl:Item>
<didl:Item> 
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
...
<didl:Component>
ref="http://my.server.nl/datasheets.xls"/><didl:Component>
</didl:Item>
</didl:Item>
Como se pode verificar pelo exemplo anterior, as localizações do elemento „Resource‟

não aparecem em vários componentes dentro de um Item, mas cada localização do
„Resource‟ é introduzida num elemento Item. Isto deve-se ao facto de cada bitstream
do ficheiro poder ter o seu próprio identificador. Nos três pontos ”...” (dado nos
exemplos), pode-se incluir nas etiquetas „Identifier‟ e „modified‟, o que é similar ao
elemento Item dos metadados.
Observações:
1. A ordem dos componentes do objecto deve seguir uma ordem lógica de leitura!
O Item com o capítulo 1 deve ser seguido do elemento imediato que contém o
capítulo 2, etc... Deste modo, o fornecedor de serviços poderá realizar uma
109/144 estado: final 2008-11-13

melhor apresentação. Na próxima versão da especificação será definido como
tornar explícita a ordem mediante a inclusão de números de sequência.
2. Se existem datas de modificação importantes no elemento „Resource‟, propagar
estas modificações nas datas em sentido ascendente até elementos Item
origem que encapsulam o elemento Item modificado derivado.
3. Adicionar identificadores apenas quando realmente existam.
4. Se não existir nenhum identificador para os elementos Item do tipo de objecto
(ObjectType), o fornecedor de serviços utilizará o identificador do elemento
DIDL.
5. Utilizar para um elemento modified ou Identifier uma estrutura separada
<Descriptor> <Statement> para a construção de elementos.
6. A regra geral é a de que se um bitstream ou um ficheiro dispõe do seu próprio
identificador, o invólucro (wrapper) será um elemento Item. Para não eliminar
a possibilidade de um bitstream conter um Identificador, utilizamos o elemento
Item como invólucro predefinido da localização do recurso.
Tipo de objecto (objectType): Página de transição (Jump-off-page

Item)
O terceiro elemento ObjectType Item contém uma hiperligação para uma página de
transição. Isto é realizado da mesma forma que para o elemento „Object Item‟.
Actualmente, isto está restringido a 1 Item deste tipo; não existem elementos de data
„identifier‟ ou „modification‟ presentes. Este elemento Item é opcional:
<didl:Item>
...

<didl:Item>
<didl:Descriptor>
<dip:ObjectType>
info:eu-repo/semantics/humanStartPage
</dip:ObjectType>
</didl:Statement>
110/144 estado: final 2008-11-13

</didl:Descriptor>
...
<didl:Component>
<didl:Resource mimeType="application/html"
ref="http://my.server.nl/mypub.html"/></didl:Component>
</didl:Item>
</didl:Item>
Exemplo de um DIDL embutido em OAI-PMH

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="DIDL_documentHTML.xsl"?>
<OAI-PMH
http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
<responseDate>2006-12-20T10:29:11Z</responseDate>
<request identifier="oai:dspace.library.uu.nl:1874/15290" metadataPrefix="didl" verb="GetRecord">
http://dspace.library.uu.nl:8080/dspace-oai/request
</request>
<GetRecord>
<record>
<header>
<identifier>oai:dspace.library.uu.nl:1874/15290</identifier>
<datestamp>2006-12-06T19:00:49Z</datestamp>
<setSpec>hdl_1874_69</setSpec>
<setSpec>hdl_1874_12233</setSpec>
</header>
<metadata>



<didl:DIDL DIDLDocumentId="urn:NBN:nl:ui:10-6748398729821"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
111/144 estado: final 2008-11-13


<didl:Item>
<didl:Descriptor>
<dii:Identifier>urn:NBN:nl:ui:10-6748398729821</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
<didl:Component>


<didl:Resource mimeType="application/xml"
ref="http://dspace.library.uu.nl:8080/dspace-oai/request?verb=GetRecord
&metadataPrefix=didl&identifier=oai%3Adspace.library.uu.nl%3A1874%2F15290"/>
</didl:Component>

<didl:Item>
<didl:Descriptor>

</didl:Statement>
</didl:Descriptor>
<didl:Component>

<didl:Resource mimeType="application/xml">
<oai_dc:dc xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dc="http://purl.org/dc/elements/1.1/" xsi:schemaLocation="
http://www.openarchives.org/OAI/2.0/oai_dc/
http://www.openarchives.org/OAI/2.0/oai_dc.xsd
http://purl.org/dc/elements/1.1/
http://dublincore.org/schemas/xmls/simpledc20021212.xsd">
<dc:title>Neonatal Glucocorticoid Treatment and Predisposition
to Cardiovascular Disease in Rats</dc:title>
<dc:creator>Bal, M.P.</dc:creator>
112/144 estado: final 2008-11-13

<dc:subject>Geneeskunde</dc:subject>
<dc:subject>glucocorticoid</dc:subject>
<dc:subject>dexamethasone</dc:subject>
<dc:subject>

</dc:subject>
<dc:subject>cellular hypertrophy</dc:subject>
<dc:subject>contractile proteins</dc:subject>
<dc:description>The present thesis describes the issue of
"neonatal glucocorticoid
treatment and predisposition to cardiovascular disease in rats".
</dc:description>
<dc:publisher>Utrecht University</dc:publisher>
<dc:date>2006-12-12</dc:date>
<dc:type>Doctoral thesis</dc:type>
<dc:format>image/jpeg</dc:format>
<dc:format>image/pdf</dc:format>
<dc:format>image/pdf</dc:format>
<dc:format>

</dc:format>
<dc:identifier>
http://igitur-archive.library.uu.nl/dissertations/2006-1206-
200250/UUindex.html
</dc:identifier>
<dc:language>en</dc:language>
<dc:rights>(c) Bal, M.P., 2006</dc:rights>
</oai_dc:dc>
</didl:Resource>
</didl:Component>
</didl:Item>

<didl:Item>
<didl:Descriptor>

</didl:Statement>
</didl:Descriptor>
<didl:Component>
<didl:Resource mimeType="application/xml">
<mods version="3.2"
xmlns="http://www.loc.gov/mods/v3"
xsi:schemaLocation="http://www.loc.gov/mods/v3
http://www.loc.gov/standards/mods/v3/mods-3-2.xsd">
<titleInfo xml:lang="en">
113/144 estado: final 2008-11-13

<title> Neonatal Glucocorticoid Treatment and Predisposition
to Cardiovascular Disease in Rats </title>
</titleInfo>
<name type="personal" ID="n1">
<namePart type="family"> Bal </namePart>
<namePart type="given">M.P.</namePart>
<role>
<roleTerm authority="marcrelator" type="code">aut</roleTerm>
</role>
</name>
<name type="personal" ID="n2">
<namePart type="family">Winter, de</namePart>
<namePart type="given">R.J.</namePart>
<role>
<roleTerm authority="marcrelator" type="code">aut</roleTerm>
</role>
</name>
<extension>
<daiList xmlns:dai="info:eu-repo/dai" xsi:schemaLocation="info:eu-
repo/dai
http://www.surfgroepen.nl/sites/oai/metadata/Shared%20Documents/dai-
extension.xsd">
<identifier IDref="n2" authority="info:eu-
repo/dai/nl">157455590</identifier>
<identifier IDref="n1" authority="info:eu-
repo/dai/nl">123456678</identifier>
</daiList>
</extension>
</mods>
</didl:Resource>
</didl:Component>
</didl:Item>


<didl:Item>
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
<didl:Component>

<didl:Resource mimeType="text/html"
ref="https://dspace.library.uu.nl:8443/bitstream/1874/15290/18/index.htm"/>
</didl:Component>
</didl:Item>
114/144 estado: final 2008-11-13

<didl:Item>
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
<didl:Component>
<didl:Resource mimeType="image/jpeg"
ref="https://dspace.library.uu.nl:8443/bitstream/1874/15290/16/bal.jpg"/>
</didl:Component>
</didl:Item>

<didl:Item>
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
<didl:Component>
ref="https://dspace.library.uu.nl:8443/bitstream/1874/15290/15/c1.pdf"/>
</didl:Component>
</didl:Item>
<didl:Item>
<didl:Descriptor>
</didl:Statement>
</didl:Descriptor>
<didl:Component>
ref="https://dspace.library.uu.nl:8443/bitstream/1874/15290/14/c2.pdf"/>
</didl:Component>
</didl:Item>


<didl:Item>
<didl:Descriptor>
<dip:ObjectType>info:eu-repo/semantics/humanStartPage</dip:ObjectType>
</didl:Statement>
115/144 estado: final 2008-11-13

</didl:Descriptor>
<didl:Component>

<didl:Resource mimeType="text/html"
ref="http://igitur-archive.library.uu.nl/dissertations/2006-1206-
200250/UUindex.html"/>
</didl:Component>
</didl:Item>
</didl:Item>
</didl:DIDL>
</metadata>
</record>
</GetRecord>
</OAI-PMH>
116/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Uso de vocabulários e semânticas
Uso de vocabulários e semânticas
info:eu-repo – Um espaço de nomes para URI-fying

esquemas e identificadores un-URIfied
O espaço de nomes (namespace) info:eu-repo está registado em http://info-uri.info
Este espaço de nomes é uma marca de autoridade para termos semânticos,

vocabulários controlados e identificadores.
Utilizando este espaço de nomes todos os termos utilizados possuem uma "presença
Web". Nesse sentido já não é uma sequência arbitrária, pois comporta significado. Esta
utilização torna-o válido para o futuro.
Identificação de autor
(esta informação é citada e modificada do projecto europeu NEEO16)
16
Network of European Economists Online (NEEO): informações do projecto em
http://www.nereus4economics.info/neeo.html. Para informação sobre DAI ver especificações:
http://homepages.ulb.ac.be/~bpauwels/NEEO/WP5/WP5%20Technical%20guidelines.pdf
117/144 estado: final 2008-11-13

Construir listas dinâmicas de publicações por autor requer que estes autores sejam
identificados inequivocamente. A melhor forma para fazer isto é através da atribuição
de um identificador a cada um do(s) autor(es) de uma obra. Esse identificador de
autor é designado por DAI (Digital Autor Identifier).
Um DAI pode ser atribuído aos autores a nível nacional (como nos Países Baixos, onde
cada autor recebe um identificador único no sistema METIS), ou a um nível
institucional. É da exclusiva responsabilidade de cada RI garantir que um autor pode
ser identificado através de um DAI e que cada DAI atribuído é único num Repositório
Institucional (RI).
Formato de um DAI
Cada RI poderá entregar os seus DAI's, no formato que entender, desde que a parte
autoridade que funciona como uma Agência de Registo possa ser reconhecida no
esquema. No entanto, recomenda-se a utilização do número International Standard for
Name Identification (ISNI)17. Todos DAI's devem ser globalmente únicos. Isto é
alcançado através da combinação do DAI com a sua autoridade (valor do atributo de
autoridade do elemento identificador) ou fazer o DAI um URI completo que é único.
Alguns exemplos de codificações válidas de um DAI:
info:eu-repo/dai/nl/12456454
http://staff.university.eu/19262
urn:isni:1234567-2
Persistência de um DAI
Os DAI's devem ser identificadores persistentes: uma mudança do DAI de um autor

poderá contribuir para obtenção de um resultado incoerente pelos fornecedores de
serviços em todo o mundo e as listas de publicação podem também tornar-se
incompletas. Por exemplo, parte de uma lista de publicações seria atribuída ao DAI X,
17
(ISNI): norma em desenvolvimento, nenhuma Agência de Registo implementada até ao
momento. O projecto termina em 2009. Os números DAI nos Países Baixos são compatíveis com
ISNI devido ao seu envolvimento via OCLC.
http://www.collectionscanada.gc.ca/iso/tc46sc9/docs/sc9n429.pdf
118/144 estado: final 2008-11-13

outra parte ao DAI Y, embora os dois DAI‟s reportando-se ao mesmo autor. Estatísticas
de downloads de publicações por autor iriam tornar-se também incorrectas. Se uma
instituição tiver de mudar os DAI's dos seus autores, por qualquer motivo, uma recolha
(harvest) completa do RI deverá ser efectuada por todos os fornecedores de serviços e
servidores de ligações (link resolvers) à escala global, a fim de, por exemplo, obter
listas de publicações correctas novamente. Os erros nas estatísticas de utilização dos
serviços seriam provavelmente irrecuperáveis. O conselho é o de que os DAI‟s
claramente não devem mudar, uma vez atribuídos aos autores.
Classificação de assuntos
Os metadados entregues via OAI-PMH, contêm uma ampla gama de cabeçalhos de

assuntos e informação de classificação. A classificação utilizada e sistemas de
cabeçalhos de assuntos, bem como a apresentação dos formatos variam amplamente.
Na maioria dos casos, esta informação aparece em formato dc simples no elemento
assunto (subject). A informação de classificação num repositório é frequentemente
utilizada para agrupar items por áreas disciplinares. Por conseguinte, tais informações
aparecem frequentemente no elemento OAI setSpec. Os repositórios EPrints
(classificação LOC) e repositórios certificados DINI (DDC) são exemplos desta
abordagem.
Os esquemas de classificação utilizados no contexto OAI são
 Library of Congress Classification18

 Dewey Decimal Classification (DDC)19
 Universal Decimal Classification20
Sistemas de cabeçalhos de assuntos usados frequentemente no contexto OAI são:
18
http://www.loc.gov/catdir/cpso/lcco/
19
http://www.oclc.org/dewey/
20
http://www.udcc.org/
119/144 estado: final 2008-11-13

 Library of Congress Subject Headings (LCSH)
 Schlagwortnormdatei (SWD)
Além disto, metadados OAI contêm códigos de classificação de áreas disciplinares a

partir de esquemas como Mathematics Subject Classification (MSC) e do Medical
Subject Headings (MeSH), mas também diferentes de informações de classificação
local.
Actualmente, os serviços baseados nestas informações possuem sérios problemas para

extrair as informações a partir dos dados entregues de forma apropriada. O primeiro
passo para melhorar a situação deverá focar-se em tornar a técnica utilizada e o
esquema de classificação transparente para o fornecedor de serviços.
O DRIVER recomenda que o repositório transporte as informações relacionadas ao uso

de classificação e cabeçalhos de assuntos no elemento descrição (description) da
resposta Identify. Quando uma classificação é utilizada para a estruturação do
repositório através de conjuntos, a parte da classificação deve ser repetida no
elemento assunto.
A prática recomendada é transportar a classificação no elemento assunto "URI-field"

utilizando um espaço de nome de autoridade, com o fim de apoiar o reconhecimento
do esquema de classificação. Com base nesta informação os fornecedores de serviços
podem utilizá-lo para a implementação de serviços como a navegação por
classificação. Isto inclui a substituição de códigos de classificação por termos em
inglês, tradução de termos para outros idiomas e fazer uma junção dos códigos de
classificação utilizando regras de mapeamento.
Recomenda-se a utilização de um URI quando se utilizar esquemas de classificação ou

vocabulários controlados, especialmente quando são utilizados esquemas codificados
DDC ou UDC. Os fornecedores de serviços podem reconhecer esquemas codificação
mais facilmente quando o esquema é "URI-fied" por um espaço de nomes de
autoridade. Quando o esquema de classificação é codificado, utilizar um texto de
leitura humana do código, de preferência em Inglês, directamente por baixo do
elemento codificado. Por exemplo:
120/144 estado: final 2008-11-13

Se nenhum sistema de classificação específico é utilizado recomendamos o Dewey

Decimal Classification (DDC). Os primeiros 1000 termos são designados sumário Dewey
Decimal Classification Síntese e podem ser descarregados em
http://www.oclc.org/dewey/resources/summaries/ se concordar com os seguintes
termos e condições: http://www.oclc.org/research/researchworks/ddc/terms.htm
Vocabulário tipo de publicações
O vocabulário dos tipos de publicações listados em baixo tem uma história bastante
enraizada na comunidade de repositórios europeia. É uma combinação dos tipos de
utilizados pelo DARE das directrizes DC, dos tipos enumerados no certificado DINI e dos
tipos de publicações e-Prints21. Com base na autoridade destas directrizes, foram
produzidas directrizes melhoradas para o DRIVER "Uso do MODS para repositórios
institucionais”22, que está em consonância com os tipos de publicação utilizados
usualmente pelos Current Research Information Systems (CRIS) como o METIS. Esse
documento foi a base para os tipos de publicação apresentados em baixo.
Os tipos de publicação listados em baixo têm uma forte incidência na

interoperabilidade europeia entre os repositórios para propósito de troca apenas. Os
tipos de publicação são utilizados para fechar a lacuna semântica, criando uma base
comum e fornecendo um significado para os diferentes tipos. Os termos e descrições
são escolhidas de forma a abranger os tipos usados na comunicação científica,
suficientemente diversificados para distinguir entre os diferentes itens utilizados na
comunicação científica, suficientemente genéricos para comportarem um
21
Vocabulário do perfil de aplicação Eprints (Scholarly Works Application Profile - SWAP)
http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Type_Vocabulary_Encoding_Scheme
22
121/144 estado: final 2008-11-13

mapeamento adequado a realizar pelos gestores de repositório e não muito específicos
que só se apliquem a uma comunidade.
Observação: Os tipos de publicações em baixo são desenvolvidos para a troca de

metadados com os fornecedores de serviços que visem a comunicação científica em
geral e não são destinados para uso interno de repositórios. Uma publicação interna
local deverá ser passível de mapeamento com os tipos listados em baixo. As descrições
são cuidadosamente construídas com a ajuda de especialistas de metadados e
administradores de repositórios. Estas descrições irão ajudar no processo de
mapeamento do repositório local.
Para os tipos publicação é usado um espaço de nome especial para que seres humanos
e máquinas possam reconhecer o vocabulário que é utilizado. Este nome é o espaço de
nomes “info:eu-repo/semantics/” (ver a primeira coluna da tabela seguinte). O URI é
utilizado como um prefixo para o termo que representa um tipo de publicação. Por
exemplo, o URI de artigos é “info:eu repo/semantics/article”. A terceira coluna
contém as descrições dos tipos de publicações. Isso deverá facilitar as decisões de
mapeamento que devem ser feitas nos repositórios locais.
A segunda coluna contém as versões que descrevem o estado do documento. Isto

possibilita a descrição do tipo de publicação, sem misturar os termos com a versão ou
informações do estado. O termo “PeerReviewedArticle” é separado por exemplo em
info:eu repo/semantics/article e info:eu repo/semantics/accepted.
info:eu-repo/semantics/ Versão permitida Descrição

article aceite / Artigo ou um editorial publicado
publicado / numa revista científica
actualizado
bachelorThesis aceite / Dissertação de Licenciatura
publicado / (mestrado integrado). Ver também
actualizado http://en.wikipedia.org/wiki/Diplom
masterThesis aceite / Dissertação de mestrado. Nível
publicado / intermédio de uma dissertação
actualizado (normalmente após quatro ou cinco
122/144 estado: final 2008-11-13

anos de estudo). Ver também
. Este tipo também se refere às
dissertações do período pré-Bolonha
para graus académicos que agora são
reconhecidos como grau de mestre.
doctoralThesis aceite / Tese de doutoramento. O nível mais
publicado / elevado de uma tese, normalmente
actualizado depois de mais de quatro ou cinco
anos de estudo. Ver também
Também, qualquer grau igual ou mais
elevado do que Tese de
doutoramento, que não segue a
“Convenção de Bologna Convention”,
será colocado na categoria
doctoralThesis. Um campo de texto
livre possibilitará a oportunidade de
especificar mais este último.
book aceite / Livro ou monografia
publicado /
actualizado
bookPart aceite / Parte ou capítulo de um livro
publicado /
actualizado
review rascunho / Recensão de livro ou de artigo. Não
submetido / confundir com artigo de revisão.
aceite /
publicado /
actualizado
conferenceObject rascunho / Todo o tipo de documentos
submetido / relacionados com uma conferência,
aceite / ex. artigos de conferências,
123/144 estado: final 2008-11-13

publicado / relatórios de conferências, palestras
actualizado em conferências, artigos publicados
em proceedings de conferências,
relatórios de abstracts de artigos de
conferência e posters de
conferências.
lecture rascunho / Palestra (Lecture) ou apresentação
submetido / realizada durante um evento
aceite / académico, ex. uma palestra de
publicado / abertura. Excluem-se palestras em
actualizado conferências (ver conferenceItem).
workingPaper rascunho / Um documento científico ou técnico
submetido / preliminar que é publicado numa
série da instituição onde a
investigação é conduzida. Também
conhecido como trabalho de
investigação, memorando de
investigação ou trabalho de reflexão.
A diferença relativamente a um
Preprint é que um workingPaper é
publicado numa série institucional.
Exemplos: documentos de trabalho,
trabalhos de investigação,
memorandos de investigação e
trabalhos de reflexão.
preprint rascunho / Tal como um workingPaper este é um
submetido / documento científico ou técnico
preliminar, mas que não é publicado
numa série institucional. O
documento destina-se a ser publicado
numa revista científica ou como um
capítulo num livro. Também, artigo
que ainda não foi avaliado e revisto
124/144 estado: final 2008-11-13

(peer-reviewed) e ainda não foi
aceite para publicação por uma
revista científica.
report rascunho / Este é um type mais ou menos lato e
submetido / compreende relatórios de comissão,
aceite / memorandos, relatórios de
publicado / investigação externos, relatórios
actualizado internos, relatórios estatísticos,
relatórios para agências de
financiamento, documentação
técnica, deliverables de projectos,
etc. Excluem-se relatórios de
conferências (ver conferenceItem).
annotation rascunho / Anotações a decisões jurisprudenciais
submetido /
aceite /
publicado /
actualizado
contributionToPeriodical rascunho / Artigo publicado em jornal, magazine
submetido / semanal ou em outro tipo de
aceite / periódicos não académicos
publicado /
actualizado
patent rascunho / Patente
submetido /
aceite /
publicado /
actualizado
other rascunho / Especialmente indicado para dados
submetido / não publicados como: dados
aceite / científicos, materiais audiovisuais,
publicado / animações, etc.
actualizado
125/144 estado: final 2008-11-13

Derivado de:
 Vocabulário de tipos e-print http://purl.org/eprint/type/
Exemplos de utilização com a sequência completa incluindo o URI info:eu-repo:
<dc:type>info:eu-repo/semantics/article</dc:type>
<dc:type>info:eu-repo/semantics/accepted</dc:type>
A sequência "info:eu-repo" está sempre associada ao termo. Define portanto, a

autoridade do vocabulário controlado utilizado.
O espaço de nomes info:eu-repo está registado em: http://info-uri.info
Mais sobre a utilização de DC:type com versões ver secção Type (Tipo) na página 72
no capítulo “Uso de metadados OAI_DC”.
Vocabulário de versões
Esta secção é sobre as versões que descrevem o estado de um documento.

Introduzimos informações sobre a versões para tornar possível a descrição do tipo de
publicação, sem misturar os termos com a versão ou informações do estado. Por
exemplo, o termo "PeerReviewedArticle" pode ser dividido em info:eu
repo/semantics/article e info:eu repo/semantics/accepted.
O vocabulário de versões é derivado de http://www.lse.ac.uk/library/versions/, que

se trata de um projecto financiado pelo JISC e designado por VERSIONS (Versões do
Eprints - um Estudo e Investigação de Utilizador dos Requisitos das Necessidades de
Normalização). Este projecto aborda os problemas e as incertezas relativas às versões
de textos científicos em repositórios digitais. VERSIONS visa ajudar na criação de
confiança do acesso livre aos conteúdos, entre todas as partes envolvidas e tem
126/144 estado: final 2008-11-13

desenvolvido um conjunto de ferramentas que podem ser encontradas em:
http://www.lse.ac.uk/library/versions/VERSIONS_Toolkit_v1_final.pdf
info:eu- Descrição
repo/semantics/
draft A versão inicial colocada em circulação como trabalho em
progresso
submittedVersion A versão que foi submetida a uma revista para revisão
científica
acceptedVersion A versão produzida pelo autor que incorpora comentários de
revisão científica e que foi aceite para versão de publicação
publishedVersion A versão produzida pelo Editor e publicada
updatedVersion A versão actualizada desde a publicação
Esquemas de codificação
As Directrizes DRIVER utilizam os seguintes esquemas de codificação:
Nome Campo Esquema

Autor dc:creator Formato bibliográfico APA conforme uma lista de
referências. Sintaxe: apelido, nome (primeiro nome)
Colaborador dc:contributor Formato bibliográfico APA conforme uma lista de
referências. Sintaxe: apelido, nome (primeiro nome)
Idiomas dc:language ISO 639-3 Sintaxe: 3 caracteres
[http://www.sil.org/ISO639-3/codes.asp]
Datas dc:date ISO 8601 [W3CDTF] Sintaxe: YYYY-MM-DD , MM e DD são
opcionais [http://www.w3.org/QA/Tips/iso-date]
Formatos dc:format IANA registered list of Internet Media Types (MIME types)
[http://www.iana.org/assignments/media-types/]
Território dc:coverage ISO 3166 (Países) [http://www.iso.ch/iso/en/prods-
127/144 estado: final 2008-11-13

services/iso3166ma/02iso-3166-code-lists/index.html]
Área dc:coverage Box [http://dublincore.org/documents/dcmi-box/]
Nomes dc:coverage TGN
Geográficos [http://www.getty.edu/research/tools/vocabulary/tgn/]
Período dc:coverage Período DCMI
temporal [http://dublincore.org/documents/2000/07/28/dcmi-
period/]
Informação dc:source Guidelines for Encoding Bibliographic Citation
de citação Information in Dublin Core Metadata
[http://dublincore.org/documents/dc-citation-
guidelines/] como em dcterms:bibliographicCitation
128/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Anexos: Futuros pontos de interesse
Anexos: Futuros pontos de interesse
Digital Repository Infrastructure Vision for European Research
129/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Anexo: Uso de etiquetas de qualidade
Anexo: Uso de etiquetas de qualidade
As Directrizes DRIVER 2.0 apresentam informação básica sobre a importância da

qualidade e interoperabilidade. Etiquetas de qualidade podem ser utilizadas para
assegurar repositórios estáveis e fiáveis que durem mais tempo e que possuam um
propósito de arquivo de preservação a longo prazo.
Como exemplos de etiquetas de qualidade pode-se mencionar: o Data Seal of Approval

e o DINI Certificate.
130/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Anexo: Uso de identificadores persistentes
Anexo: Uso de identificadores

persistentes
Os identificadores persistentes para recursos Web são necessários para criar uma infra-
estrutura estável e fiável. Isto não diz respeito a aspectos técnicos, mas
principalmente acordos a um nível organizacional.
As Directrizes DRIVER podem fazer algumas recomendações sobre a implementação

para gestores de repositórios. Isto é baseado no Report on Persistent Identifiers of the
PILIN project.
Um plano de implementação foi disponibilizado em seguida.
Deve ficar claro como isto encaixa na troca de metadados oai_dc.
Na era do papel, foi desenvolvido o International Standard Book Number (ISBN), um

identificador numérico de livros comercial único. A cada edição e variação (excepto a
reimpressão) de um livro é atribuído um ISBN. Na era digital, há uma crescente
necessidade de um identificador numérico único, identificador também para
publicações digitais. Mais ainda, não apenas para as publicações, mas para todos os
tipos de objectos digitais.
131/144 estado: final 2008-11-13

Na Internet, consideramos o URL como o identificador de um objecto digital. Contudo,
estamos todos familiarizados com ligações partidas ou mortas que apontam para
páginas da Web que estão permanentemente indisponíveis.
Um URL pode mudar ao longo do tempo, devido a migrações de servidor e outras

razões de ordem técnica. Com consequências indesejáveis para as ligações e citações
no seio da comunicação científica.
Portanto um "identificador persistente” é necessário com um objecto digital ao qual é

permanentemente associado. Este número de identificação persistente refere-se
sempre ao objecto digital ao qual foi atribuído, independentemente da tecnologia
subjacente de localização (no momento estes são endereços Web, no futuro, contudo,
a localização de um objecto pode ser completamente diferente).
Em vários países, tem sido desenvolvido um sistema para um destes tipos de

identificador persistente e foram criados „servidores nacionais'. Um servidor é um
serviço de transformação e redirecção, que transforma uma sequência de caracteres
num URL, e é alojado por uma organização nacional. Identificadores comuns no caso
da comunicação científica são DOI, Handle e URN:NBN. No caso de DOI e Handle o
mecanismo servidor está sedeado nos US no CNRI23. No caso do URN:NBN os
mecanismos servidores alojados por uma organização nacional, frequentemente pela
pela Biblioteca Nacional.
A cada objecto digital é atribuído um número que representa esse objecto Ad

Eternum. Mesmo que a tecnologia evolua, a organização nacional irá garantir que os
documentos possam ser lidos. Mas os documentos devem ser recuperáveis também. O
identificador persistente garante que ele possa ser localizado. Uma infra-estrutura de
informação estável faz das citações de investigação muito mais fiáveis.
Actualmente, o URN:NBN e os Handle são populares em termos de identificadores

persistentes. Uma vez que o espaço de nomes URN:NBN são distribuídos de uma forma
controlada, seria de esperar que sejam reconhecido como autoridade assim como o
DOI possui uma reputação.
23
CNRI: http://www.cnri.reston.va.us/
132/144 estado: final 2008-11-13

As diferenças entre identificadores persistentes são descritas por Hans-Werner Hilse e
Jochen Kothe em Implementing Persistent Identifiers24. Existe também um artigo
Persistent Identifiers: Considering the Options25 na revista Ariadne, número 56, por
Emma Tonkin.
A utilização de identificadores persistentes comporta a obrigação dos repositórios

sustentarem a persistência do identificador durante um longo período de tempo! Esta
persistência pode ser garantida nos chamados "repositórios confiáveis", com a devida
certificação. Ver capítulo Anexo: Uso de etiquetas de qualidade na página 130.
para mais informação ver http://www.persistent-identifier.de
e https://www.pilin.net.au/
Os países escandinavos, a Alemanha, a República Checa e os Países Baixos usam URN:

NBN. A principal razão da escolha de urns é porque se trata de uma norma de Internet
que estará comprovada futuramente. O único inconveniente é que um urn não é
accionável sem utilizar um endereço de um servidor http como um prefixo. É
necessário mais trabalho para integrar URN no sistema DNS26 utilizando registos
NAPTR27 que também são utilizados para chamadas VOIP.
Recentemente a Noruega, a Suécia, a Finlândia e os Países Baixos alcançaram uma

proposta promissora para um servidor global de identificadores persistentes (URN:
NBN). Em cooperação com representantes das Universidades Hopkins e Berkeley (US.)
uma prova de conceito28 funcional para um servidor global (GRRS) foi desenvolvida.
Este GRRS integra quatro servidores nacionais diferentes num único servidor global. O
24
Hilse, H., Kothe, J., Implementing Persistent Identifiers, KNAW,
http://www.knaw.nl/ecpa/publ/pdf/2732.pdf
25
Tonkin, E., Persistent Identifers: Considering the Options, Ariadne, issue 56,
http://www.ariadne.ac.uk/issue56/tonkin/
26
DNS-URN integration
http://www.persistent-identifier.de/english/335-project-proposal.php#URNscope
27
NAPTR Record: http://en.wikipedia.org/wiki/NAPTR_record
28
Global Resolution Proof of Concept:
http://www.surfgroepen/sites/surfshare/public/software/pihandler
133/144 estado: final 2008-11-13

GSRS (n2t.info) recebe o identificador de um navegador plug-in e redirecciona-o para
o servidor nacional adequado onde o navegador redirecciona novamente para a
localização actual do recurso Web. A arquitectura deste processo multi-sistema é
descrita em baixo.
Plano de implementação para uso de identificadores persistentes

URN:NBN
Em primeiro lugar, gostaríamos de referir que a persistência de identificadores e

recursos Web não se sustenta na tecnologia que utilizam, mas na organização e em
modelos de gestão sustentáveis. Para obter mais informações sobre políticas de
identificadores persistentes ver o bem sucedido projecto Persistent Identifier Linking
(PILIN)29 na Austrália, parte do projecto ARROW30.
29
Projecto Persistent Identifier Linking Infrastructure: https://www.pilin.net.au/
30
Projecto ARROW: http://www.arrow.edu.au/
134/144 estado: final 2008-11-13

Para configurar um programa de identificadores persistentes baseado em National
Bibliographic Numbers (NBN), identificadores URN e um servidor deve-se seguir os
seguintes passos:
1. Grupo de trabalho: Criar um grupo de trabalho que faça a gestão de todos os

detalhes técnicos e organizacionais de um projecto dessa natureza. Pensar também
sobre a sintaxe que irá ser utilizada. Por exemplo urn:nbn:{country}:{sub-
namespace}:{repositoryid}-{localid}. Country é o nome abreviado do país, sub-
namespace representa recursos Web provenientes de repositórios, repositoryid é uma
representação de dois dígitos do repositório e local id é o identificador gerado no
repositório. Isto pode, por exemplo, resultar na seguinte no seguinte identificador
para uma publicação urn:nbn:ie:ui:21-1234/5678.
2. Formalidades: Uma vez que o espaço de nomes urn:nbn:ie é por predefinição

reclamado pela Biblioteca Nacional, deve-se acordar com a Biblioteca Nacional a
utilização de um sub-espaço de nomes para produção científica. Esse nome deve ser
curto e não possuir nenhum significado semântico. Por exemplo urn:nbn:ie:ui, ou
urn:nbn:ie:oa, ou urn:nbn:ie:sp.
3. Agência Registo: Criar um registo no qual são atribuídos aos repositórios um

número curto e aleatório de dois dígitos. Isto vai criar um sub-espaço de nome onde
um repositório possa distribuir autonomamente identificadores persistentes para as
suas publicações. Por exemplo, Trinity College Dublin (TCD) é registado como 21. O
espaço de nomes para o TCD operar será urn:nbn:ie:ui:21.
4. Implementação a nível local: Cada repositório deve gerar identificadores

persistentes para cada publicação no seu espaço de nome que é disponibilizado e
armazenar esse identificador na base de dados de registos. Por exemplo, TCD pode
usar identificadores existentes para adicionar depois dos seus espaços de nome
seguido por um hífen. No caso de o TCD utilizar Handle, o identificador de uma
publicação pode assemelhar-se ao seguinte urn:nbn:ie:ui:21-1234/5678. No caso de o
TCD utilizar números de base de dados urn:nbn:ie:ui:21-15874. (Certifique-se de
armazenar o identificador e não gerá-los on-the-fly. No caso de migração de base de
dados estes números podem mudar e a persistência é perdida.)
135/144 estado: final 2008-11-13

5. Transporte de identificadores e URL‟s: Cada repositório deve gerar um pacote
DIDL onde o URN e URL são incluídos. Ver a secção MPEG-21 DIDL no relatório
principal.
6. Serviço de Resolução Nacional: Um serviço de resolução nacional pode ser

implementado através da recolha de pacotes DIDL de cada repositório onde o URL e
URL bindings são extraídos e armazenados. Uma localização Web deve ser criada onde
a máquina ou utilizador possam ir para a resolução do identificador. Por exemplo
http://resolver.ie onde o utilizador pode inserir um identificador e receber a
localização actual do recurso Web.
Por exemplo http://resolver.ie/urn:nbn:ie:ui:21-1234/5678 resolvido para

http://repository.tcd.ie/1234/5678
136/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Anexo: Uso de intercâmbio de estatísticas de utilização
Anexo: Intercâmbio de estatísticas de

utilização
A contribuição para esta secção será feita a partir das experiências e práticas
recomendadas provenientes de dois projectos europeus que recolhem relatórios
COUNTER a partir de repositórios para apresentar estatísticas a um nível agregado.
PIRUS: Publisher and Institutional Repository Usage

Statistics
"O objectivo deste projecto é desenvolver relatórios de uso Counter-compliant ao nível

individual dos artigos e que podem ser implementadas por qualquer entidade (editor,
agregador, RI, etc.) que aloja artigos de revista online e que permitirá que a utilização
dos resultados da investigação seja registada, reportada e consolidada a nível global
de uma forma padronizada."
Citado de: http://www.jisc.ac.uk/whatwedo/programmes/pals3/pirus.aspx
Contacto do projecto: Peter Sheperd - pshepherd@projectcounter.org
137/144 estado: final 2008-11-13

OA-Statistik
“A facilidade de acesso experienciada com publicações Open Access desprovida de

qualquer necessidade de autenticação, transacções financeiras ou de identificação
pessoal faz com que seja muito mais fácil para atingir um nível que satisfação
acolhedor na comunidade científica. Esta e hipóteses semelhantes podem ser
investigadas através de análises empíricas.
1. Que dados necessitam ser recolhidos?

2. Como podem ser transferidos para o fornecedor de estatísticas?
Open-Access-Statistics (OA-S) é um projecto conjunto que aborda estas questões. A

partir de Julho de 2008 será construída uma infra-estrutura para a acumulação
normalizada de dados de registos Web heterogéneos com ênfase em repositórios
institucionais. Em colaboração estreita com a Network of Open Access Repositories
(OA-N) serão disponibilizados aos utilizadores vários serviços de valor acrescentado."
Citado de: http://www.dini.de/projekte/oa-statistik/
Contacto do projecto: Nils K. Windisch - windisch@sub.uni-goettingen.de
Resultados preliminares do projecto OA-Statistik
Objectivos de estatísticas OA
O nosso objectivo é produzir um documento válido e fiável de estatísticas de

utilização, baseado apenas em informações recolhidas a partir da camada HTTP.
Existem duas questões primordiais abordadas por todas as normas existentes que
geram a maior parte das correcções necessárias:
 Identificação de acesso não humano

 Correcção multi-clique
138/144 estado: final 2008-11-13

Além disto, investigamos a quantidade de dados e o esforço necessário para produzir
estatísticas complexas, por exemplo, sequências de cliques, sem violar leis de
privacidade. Na parte final desta secção é apresentado um quadro comparativo,
incluindo ligações para todas as normas mencionadas. Uma descrição pormenorizada
da OA-S pode ser encontrada em: http://www.dini.de/projekte/oa-statistik/#c1203
Estatísticas de utilização - e ainda mais importante, dados brutos de utilização -

devem ser descritos de forma abstracta. Não é suficiente definir um derivado do
Apache Access Log, pois existe uma multiplicidade de diferentes soluções de software
em uso para operar com repositórios de texto integral. Muitas nem sequer produzem
um ficheiro de registo sozinho utilizável num servidor Apache.
Informação necessária para gerar COUNTER, LogEc e IFABC
Nota: Os nomes dos campos podem ainda estar sujeitos a alterações à medida que o
projecto evoluir.
Nomes dos Descrição COUNTER LogEc IFABC|-

campos OA-S
Identificador Etiqueta não- necessário necessário necessário|-
do Documento ambígua a identificar
o texto integral
Formato do Formato do ficheiro necessário necessário necessário|-
ficheiro da resposta do
servidor (ex. HTML
ou PDF)
Tipo Serviço Natureza da resposta necessário necessário -|-
do servidor (ex.
texto integral,
resumo)
Tempo do Tempo de resposta necessário necessário necessário|-
pedido ao segundo
IP Endereço IP do necessário necessário Se o Identificador de
utilizador (Cliente) sessão não está
139/144 estado: final 2008-11-13

disponível:
necessário|-
Identificador Etiqueta de opcional - Se o IP no não está
de Sessão Sessão/Visita não- disponível:
ambígua gerada pelo necessário|-
servidor
User Agent Sequência User- necessário necessário Se o ID de sessão
Agent do cliente não está disponível:
requerente necessário|-
Código de Código de estado do necessário necessário necessário|-
estado HTTP servidor dos pedidos
HTTP
Bytes enviados Tamanho de resposta - - Se o formato de
do servidor ficheiro não é HTML:
necessário
Informação adicional em conformidade com OpenURL Context

Objects
Os seguintes campos são importantes para os nossos interesses de pesquisa avançada e

por isso implementados desde o início.
Referência original Identificador não-ambíguo do servidor que criou o

(Referrer) ContextObject|-
Entidade de referência Etiqueta não-ambígua da origem do objecto (ex. a página
(Referring Entity) do resumo que liga para o ficheiro de texto integral)
Sugestões adicionais
Declarações e propriedades do software do repositório têm de ser entregues a partir

dos dados disponíveis.
Exemplos:
 Página de destaque na vista dos resultados de pesquisa
140/144 estado: final 2008-11-13

 ID do documento actual
 Procurar argumentos e apresentação do resultado
 Página resumo vs página texto integral
 Acções administrativas
 Carregamento do documento
 Atribuição de metadados
Deve haver informação fiável sobre a origem do cliente (ou seja, a referência
original). Por exemplo, deveria ser possível dizer se um cliente acedeu ao ficheiro
através da página principal ou através de uma hiperligação do RSS-Feed do repositório.
No caso de múltiplos registos de servidor é obrigatório sincronizar a hora do sistema

em todos os servidores associados ao repositório.
Tabela de padrões de utilização Web
Fonecedor Cláusula de Longevidade Identificação Cláusula Crawler Identificação Relatório

URL contagem Multi-Clique User Crawler contagem
Crawler
Counter Code Estado do Para HTML Pelo menos Robots, prefetches, Lista negra, Relatório
of Practice código HTTP é 10s; para PDF IP, de caching, pesquisas cabeçalho separado
Draft 3 200 ou 304. 30s preferência federadas (n.e.) client HTTP
Sessão
About LogEc Estado do Um IP Robots, downloads Acessos ao Coluna
código HTTP é calendário automáticos (wget) robots.txt; # separada
200, 206, 301, mês de pedidos no
302 ou 304. 10,000 relatório
itens/mês;
acessos C-
Class 10% do
stock; robot-
Domínio/IP
conhecido
Interoperable Estado do 24 horas IP Motores de pesquisa
Repository código HTTP é indexadores
Statistics 200 no (crawlers) +
resumo ou automático|lista
página de negra AWStats'
texto integral |descartado
AWStats Predefinido: Predefinido: 1 IP Motores de pesquisa Lista negra Coluna
Códigos de hora indexadores separada
141/144 estado: final 2008-11-13

estado http (crawlers) no
{200;304} relatório
IFABC HTML: Cada IP+User- Motores de pesquisa Lista negra Descartado
Rastreamento Pageview é Agent; sessão indexadores proprietária
Pixel; Outro: contada Cookie, (crawlers);
bytes apenas uma sessão downloads
transferidos vez por visita. autenticada automáticos
95% do Visita (opcional)
tamanho do significa serie
ficheiro de cliques
provenientes
de um
número de
IP/Sessão ID
separadas por
menos de 30
minutos.
142/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Anexo: Uso de direitos de propriedade intelectual
Uso de direitos de propriedade

intelectual
Este secção aborda uma temática importante sobre direitos de utilização e direitos de
depósito. Na prática, isto deve ser implementado. As Directrizes DRIVER devem dizer
algo sobre a forma como os direitos de utilização e direitos de acesso devem ser
expostos e formatados nos metadados.
A base para esta secção será a Copyright Toolbox desenvolvida pela fundação SURF e
pelo JISC e que reflecte os princípios Zwolle.
Ver: http://copyrighttoolbox.surf.nl/copyrighttoolbox/ para mais informação.
Para mais informação sobre copyright e as licenças para depositar, usar e reusar, ver:
http://www.surffoundation.nl/smartsite.dws?ch=AHO&id=13591
Com o Open Access (Acesso Livre), os direitos de propriedade intelectual devem ser
geridos de uma forma correcta. Mesmo que um documento esteja em Acesso Livre, o
copyright pode limitar o uso do material que foi encontrado. As licenças Creative
Commons (CC) propiciam ferramentas gratuitas que permitem a autores, cientistas,
artistas e educadores marcar facilmente o seu trabalho criativo com o grau de
143/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 Anexo: Uso de direitos de propriedade intelectual
liberdade que lhe pretendam aplicar. Pode usar as CC para mudar os termos de
copyright de “Todos os Direitos Reservados” para "Alguns Direitos Reservados”.
Para a ciência, poder disseminar o conhecimento da forma mais livre possível, sem
perder noção de propriedade, pode-se usar a Licença Creative Commons BY-SA na área
jurisdicional em causa.
Isto significa:
 SA (Partilha nos Termos da Mesma Licença): a utilização da obra é livre,

podendo os utilizadores fazer dela uso comercial ou criar obras derivadas a
partir da obra original.
o Observação 1: todas as partes, comercial ou não, têm de licenciar nos
mesmos termos em que o foi a obra original para produzir trabalhos
derivados. Como resultado: o conhecimento não será bloqueado.
o Observação 2: contudo, a velocidade de inovação pode ser protelada,
porque algumas partes não querem usar o mesmo modelo de
licenciamento a aquando da produção de trabalhos derivados.
 BY (Atribuição): é necessário conceder o devido crédito ao autor original
(assim também terá créditos como colaborador).
Se usa o copyright, recomendamos que utilize com uma boa descrição de utilização.
Por exemplo http://creativecommons.org/licenses/by-sa/3.0/nl/
No Dublin Core não qualificado as licenças são de leitura digital da seguinte forma:
<dc:rights>http://creativecommons.org/licenses/by-
sa/2.0/uk/</dc:rights>
<dc:rights>cc-by-sa, Andrew Smith</dc:rights>
Para uma visão técnica completa ver secção Rights (Direitos) na página 83.
Para mais informação ver também:
 http://copyrighttoolbox.surf.nl/copyrighttoolbox/
 http://sciencecommons.org/projects/publishing/
 http://creativecommons.org
 http://www.surffoundation.nl/smartsite.dws?ch=AHO&id=13591
144/144 estado: final 2008-11-13

DRIVER Guidelines v2 Final PT

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

DRIVER Guidelines v2 Final PT

Enviado por

Direitos autorais:

Formatos disponíveis

Digital Repository Infrastructure Vision for European Research

Directrizes DRIVER 2.0

[Directrizes para gestores e administradores de repositórios sobre como expor recursos

Versão portuguesa Serviços Documentação da Universidade do Minho (Abril 2009)

Para a comunicação em geral, é importante que a pessoa B seja capaz de

Em termos técnicos, criamos uma base comum promovendo a "interoperabilidade". A

2/144 estado: final 2008-11-13

3/144 estado: final 2008-11-13

Estratégia de registos eliminados .........................................................23

4/144 estado: final 2008-11-13

Data de registo (Datestamp) .................................................................40

5/144 estado: final 2008-11-13

Source (Fonte) ...............................................................................79

6/144 estado: final 2008-11-13

Tipo objecto (objectType): Item objecto ............................................. 108

7/144 estado: final 2008-11-13

Agradecimentos e Colaboradores (versão 1.0)

Martin Feijen, Maurice Vanderfeesten, Wolfram Horstmann, Friedrich Summann, Muriel

Agradecimentos e Colaboradores (versão 2.0)

 Maurice Vanderfeesten, (SURFfoundation, Países Baixos)

 Stefania Biagioni, (CNR, Itália)

8/144 estado: final 2008-11-13

 Patrick Hochstenbach, (Ghent University, Bélgica)

O DRIVER, “Digital Repository Infrastructure Vision for European Research”, é um

9/144 estado: final 2008-11-13

DRIVER como infra-estrutura de dados

A infra-estrutura de dados baseia-se em recursos alojados localmente, como

O espaço de informação actual do DRIVER

O que esperam os investigadores

Os investigadores e outros actuais utilizadores de sistemas de informação possuem

10/144 estado: final 2008-11-13

O desafio do texto integral

A recuperação de texto integral com dados bibliográficos é um passo básico mas

11/144 estado: final 2008-11-13

Sobre as Directrizes DRIVER

Porquê utilizar as Directrizes DRIVER?

O documento, “Directrizes para Fornecedores de Conteúdos: Exposição de Recursos

Como cumprir as Directrizes DRIVER? (validação)

Não estar em conformidade com todos os pontos obrigatórios ou recomendados das

12/144 estado: final 2008-11-13

integral não pode processar todo o conteúdo de um repositório que ofereça

Âmbito das Directrizes DRIVER

As Directrizes DRIVER são uma norma?

As Directrizes DRIVER equivalem a regras de catalogação?

Não. As directrizes são um instrumento para mapear (ou traduzir) os metadados

13/144 estado: final 2008-11-13

As Directrizes DRIVER possuem instruções do nível de qualidade científica?

Quais são os principais componentes das Directrizes DRIVER?

As Directrizes DRIVER focam basicamente cinco questões: colecções, metadados,

 No que respeita às colecções do repositório, é obrigatório utilizar “sets”

Quem criou as Directrizes DRIVER?

As Directrizes do DRIVER foram compiladas por profissionais com anos de experiência

14/144 estado: final 2008-11-13

O que se entende por recursos textuais?

 Recurso textual: artigos científicos, teses de doutoramento, documentos de

15/144 estado: final 2008-11-13

O que são “sets”?

Sets (conjuntos) são um componente normalizado do protocolo OAI-PMH e são

O que mais se deve considerar?

 O DRIVER foi concebido seguindo a estrutura de redes operacionais e

16/144 estado: final 2008-11-13

específicos do DARE e que está disponível como “Uso DRIVER das

17/144 estado: final 2008-11-13

Existe alguma solução que resolva de imediato vários problemas?