Riunila Driver Guidelines v2 Final 2008-11-13 PT PT

Digital Repository Infrastructure Vision for European Research
Directrizes DRIVER 2.0

Directrizes para fornecedores de contedos -
Exposio de recursos textuais com o
protocolo OAI-PMH
[Novembro 2008]
[Directrizes para gestores e administradores de repositrios sobre como expor recursos

cientficos digitais utilizado o protocolo OAI-PMH e metadados Dublin Core, criando
interoperabilidade atravs da homogeneizao das sadas (output) dos repositrios.]
Verso portuguesa Servios Documentao da Universidade do Minho (Abril 2009)

Directrizes DRIVER 2.0 Introduo
Resumo
Para a comunicao em geral, importante que a pessoa B seja capaz de

compreender o que a pessoa A est a dizer. Para este entendimento mtuo
necessria uma base comum, um lxico bsico com o conhecimento do significado das
coisas. A partir desse ponto pode-se comear a raciocinar. Para apoiar a comunicao
cientfica com a utilizao de repositrios, os repositrios devero falar a mesma
lngua e portanto essencial criar uma base comum.
Em termos tcnicos, criamos uma base comum promovendo a "interoperabilidade". A

Interoperabilidade pode ser gerida em diferentes camadas. Nas Directrizes DRIVER
tentamos basicamente alcanar a interoperabilidade em duas camadas, sintctica
(Utilizao do OAI-PMH e Uso de OAI_DC) e semntica (Utilizao de vocabulrios).
2/144 estado: final 2008-11-13

ndice de Contedos
Introduo ................................................................... 8
Agradecimentos e Colaboradores (verso 1.0) .............................................. 8
Agradecimentos e Colaboradores (verso 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 espao de informao 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? (validao) ......................................12
E se no cumprir? ...........................................................................12
Existe suporte? ..............................................................................13
mbito das Directrizes DRIVER ............................................................13
Mais Recursos ................................................................................16
Esboo Sumrio das Directrizes DRIVER ...................................................18
PARTE A Recursos Textuais ..............................................................18
PARTE B - Metadados .......................................................................19
PARTE C Implementao OAI-PMH ......................................................20
O que novo .............................................................. 22
Captulo 1: Uso do OAI-PMH ..................................................................22
Atribuio 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

Estratgia de registos eliminados .........................................................23

Captulo 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
Captulo 3: Utilizao das prticas recomendadas para OAI_DC ........................28
Mapeamento tipos DRIVER .................................................................28
Mapeamento verses DRIVER ..............................................................28
Utilizao de OAI_DC com teses ..........................................................29
DC:SOURCE e DC:RELATION ................................................................29
Captulo 4: Uso de empacotamento de objecto composto ...............................29
Captulo 5: Uso de vocabulrios e semnticas .............................................33
Captulo 6: Anexo: Uso de etiquetas de qualidade ........................................34
Captulo 7: Anexo: Uso de identificadores persistentes ..................................34
Captulo 8: Anexo: Intercmbio de estatsticas de utilizao ...........................35
Captulo 9: Anexo: Uso de direitos de propriedade intelectual .........................35
Uso do protocolo OAI-PMH .............................................. 37
Introduo.......................................................................................37
Nota: ..........................................................................................37
Agradecimentos .............................................................................37
Fonte de informao........................................................................38
Definies 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
Atribuio de nome ao conjunto DRIVER ...................................................45
Definies do contedo do conjunto DRIVER...............................................46
Localizao do conjunto (set) ................................................................47
Correio electrnico do administrador para feedback de erros ..........................47
Declarao de prefixo e espao de nomes .................................................50
Validao XML ..................................................................................52
Comunicao para modificao nos repositrios ..........................................54
Uso de metadados OAI_DC .............................................. 55
Agradecimentos ................................................................................55
Definies .......................................................................................56
Notas introdutrias ............................................................................56
mbito ........................................................................................56
Requisitos mnimos .........................................................................57
Recomendaes .............................................................................57
Os elementos: descrio abreviada .........................................................60
DC no qualificado: oai_dc ................................................................60
Os elementos: descrio completa ..........................................................62
Title (Ttulo) .................................................................................62
Creator (Autor) ..............................................................................63
Subject (Assunto) ...........................................................................65
Description (Descrio) .....................................................................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 (Relao) ..........................................................................81
Coverage (Cobertura) .......................................................................82
Rights (Direitos) .............................................................................83
Audience (Pblico) ..........................................................................85
Uso das prticas recomendadas com OAI_DC ....................... 87
Mapeamento de tipos DRIVER ................................................................87
Mapeamento de tipos DRIVER v1.1 para tipos DRIVER v2.0 ...........................88
Mapeamento de vocabulrio de tipos E-Print para tipos DRIVER v2.0 ...............88
Mapeamento de verses DRIVER .............................................................90
Mapeamento de tipos de verses Eprints para tipos de verso DRIVER v2.0 .......90
Termos comuns de tipo de verses para tipos de verses DRIVER v2.0 .............90
Mapeamento dos tipos de verses do grupo de trabalho tcnico Journal Article
Versions (JAV) para os tipos de verses das Directrizes DRIVER v2.0 ...............91
Uso do OAI_DC com teses .....................................................................92
Exemplo ......................................................................................93
DC:SOURCE e informao de citao ........................................................94
DC:RELATION e hiperligao de objectos relacionados ...................................94
Uso de MPEG-21 DIDL (xml-container) Empacotamento do
objecto composto ........................................................ 96
Introduo e Objectivo ........................................................................96
Contextualizao ...............................................................................97
Resposta OAI com um documento DIDL .....................................................97
DIDL como invlucro ou empacotador (wrapper) ..........................................99
Elemento raiz: documento DIDL atributo de identificao ...........................99
Descritores de item (opcional) .......................................................... 100
Declarao Descriptor: Item 'Identifier'................................................ 101
Declarao Descriptor: Item 'modified' ................................................ 102
Declarao Descriptor: Item ObjectType ............................................ 103
Elemento composto: representao 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): Pgina de transio (Jump-off-page Item) ....... 110
Exemplo de um DIDL embutido em OAI-PMH ............................................. 111
Uso de vocabulrios e semnticas .................................... 117
info:eu-repo Um espao de nomes para URI-fying esquemas e identificadores un-
URIfied......................................................................................... 117
Identificao de autor ....................................................................... 117
Formato de um DAI ....................................................................... 118
Persistncia de um DAI ................................................................... 118
Classificao de assuntos ................................................................... 119
Vocabulrio tipo de publicaes ........................................................... 121
Vocabulrio de verses ...................................................................... 126
Esquemas de codificao ................................................................... 127
Anexos: Futuros pontos de interesse ................................ 129
Anexo: Uso de etiquetas de qualidade .............................. 130
Anexo: Uso de identificadores persistentes ........................ 131
Plano de implementao para uso de identificadores persistentes URN:NBN .... 134
Anexo: Intercmbio de estatsticas de utilizao ................. 137
PIRUS: Publisher and Institutional Repository Usage Statistics ........................ 137
OA-Statistik ................................................................................... 138
Resultados preliminares do projecto OA-Statistik ....................................... 138
Objectivos de estatsticas OA ........................................................... 138
Informao necessria para gerar COUNTER, LogEc e IFABC ....................... 139
Informao adicional em conformidade com OpenURL Context Objects ......... 140
Sugestes adicionais ...................................................................... 140
Tabela de padres de utilizao Web .................................................. 141
Uso de direitos de propriedade intelectual ........................ 143
7/144 estado: final 2008-11-13

Introduo
Agradecimentos e Colaboradores (verso 1.0)
Martin Feijen, Maurice Vanderfeesten, Wolfram Horstmann, Friedrich Summann, Muriel

Foulonneau, Karen Van Godtsenhoven, Patrick Hochstenbach, Paolo Manghi, Bill
Hubbard.
Agradecimentos e Colaboradores (verso 2.0)
A criao das Directrizes DRIVER 2.0 contou com a experincia de muitas pessoas.
Todas essas pessoas so especialistas e gestores de repositrios. Este grupo tem
trabalhado em conjunto para conseguir a interoperabilidade para que possa ser
aplicada na prtica. Neste contexto, as pessoas referidas em seguida, aprovam e
apoiam as Directrizes DRIVER 2.0.
Editores
Maurice Vanderfeesten, (SURFfoundation, Pases Baixos)

Friedrich Summann, (University Bielefeld, Alemanha)
Martin Slabbertje, (Utrecht University, Pases Baixos)
Peritos e Revisores
Stefania Biagioni, (CNR, Itlia)

Paolo Manghi, (CNR, Itlia)
Maria Bruna Baldacci, (CNR, Itlia)
Friedrich Summann, (University Bielefeld, Alemanha)
Martin Slabbertje, (Utrecht University, Pases Baixos)
Thomas Place, (Tilburg University, Pases Baixos)
Benoit Pauwels, (Universite Libre de Bruxelles, Blgica)
8/144 estado: final 2008-11-13

Patrick Hochstenbach, (Ghent University, Blgica)

Karen van Godtsenhoven, (Ghent University, Blgica)
Niamh Brennan, (Trinity College Dublin, Irlanda)
Phil Cross, (Intute and the Intute Repository Search project, Reino Unido)
Mikael Karstensen Elbk, (Danish Technical University (DTU), Dinamarca)
Maurice Vanderfeesten, (SURFfoundation, Pases 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, Pases Baixos)
Armand Guicherit, (KNAW, Pases Baixos)
Ruud Bronmans, (KNAW, Pases Baixos)
Jos Odekerken, (University of Maastricht, Pases Baixos)
Alenka Kavcic-Colic, (Library Research Centre at National and University
Library, Eslovnia)
Myriam Bastin, (University of Luik, Blgica)
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 consrcio financiado pela Unio Europeia (UE) e que visa
a constituio de uma estrutura organizacional e tecnolgica para implementar uma
camada de dados pan-europeia que permita o uso avanado de recursos de contedos
na rea da investigao no ensino superior. O DRIVER desenvolve uma infra-estrutura
de servios e uma infra-estrutura de dados. Ambas esto concebidas para instrumentar
os recursos e servios existentes na rede de repositrios.
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

publicaes cientficas recolhidas em repositrios digitais de instituies e organismos
de investigao. Estes recursos sero recolhidos pelo DRIVER e agregados escala
europeia. Para poder garantir uma elevada qualidade da agregao, o DRIVER
fornecer os meios possveis para a harmonizar e validar. O DRIVER respeitar a
provenincia dos recursos mediante a sua marcao com informao do repositrio
local. Adicionalmente, quando um recurso for descarregado, o DRIVER ir remeter
para o repositrio local ao invs de o fornecer directamente. Os dados do DRIVER
estaro disponveis para reutilizao via Open Archives Initiative Protocol for Metadata
Harvesting (OAI-PMH) por todos os parceiros da rede DRIVER de fornecedores de
contedos.
O espao de informao actual do DRIVER
A fase inicial do DRIVER criou os pilares para uma rica e ambiciosa infra-estrutura pan-
europeia de repositrios. A paisagem dos repositrios digitais multifacetada no que
concerne aos diferentes pases, aos diferentes tipos de recursos como texto, dados ou
multimdia, s diferentes plataformas tecnolgicas, s diferentes polticas de
metadados, etc. No entanto, existem bases comuns que se aplicam a grande parte
deste espectro: o tipo de recurso mais comum nos repositrios 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 atravs do protocolo OAI-PMH.
Desafios
O que esperam os investigadores
Os investigadores e outros actuais utilizadores de sistemas de informao possuem

expectativas bastante elevadas relativamente ao fornecimento de contedos digitais.
A recuperao deve ser rpida, directa (acessvel com poucos cliques) e verstil. A
10/144 estado: final 2008-11-13

cultura actual no panorama dos repositrios digitais no suporta completamente estas

expectativas. Embora muitos servios de valor acrescentado tenham sido
implementados para pesquisar e recuperar registos bibliogrficos (metadados), o
recurso em si mesmo , por vezes, ocultado por detrs de vrias pginas intermdias,
obscurecido por procedimentos de autorizao, apresentado de forma incompleta ou
totalmente irrecupervel. No entanto, para conseguir uma comunicao cientfica
ptima seria necessrio que o recurso fosse obtido com apenas um clique do rato.
Adicionalmente, uma recuperao simples do texto integral e dos metadados facilita o
tratamento automtico do contedo. Nem o registo bibliogrfico recolhido nem o
texto completo recuperado em separado - apenas a combinao de ambos - permitem
o desenvolvimento de servios avanados e integrados, como a pesquisa por assuntos
combinada com a navegao atravs de classificaes, anlise de citaes, 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 consrcio DRIVER dedique todos os esforos
possveis para abordar este desafio do ponto de vista tecnolgico atravs do
processamento de dados agregados, os detentores de repositrios digitais podem
apoiar localmente o DRIVER atravs do fornecimento de contedos de uma forma
especfica. As Directrizes DRIVER aqui apresentadas iro facultar orientaes para que
os fornecedores de contedos locais saibam como disponibilizar os seus contedos.
O que se segue?
A recuperao de texto integral com dados bibliogrficos um passo bsico mas

necessrio para conseguir servios ricos em informao baseados em repositrios
digitais. Futuras verses das Directrizes DRIVER relacionadas com o DRIVER II
abordaro os passos seguintes relativamente a outros tipos de informao, como dados
primrios ou multimdia e objectos de informao mais complexos formados por vrios
recursos.
11/144 estado: final 2008-11-13

Sobre as Directrizes DRIVER
Porqu utilizar as Directrizes DRIVER?
O documento, Directrizes para Fornecedores de Contedos: Exposio de Recursos

Textuais com o Protocolo OAI-PMH fornece orientao aos administradores de novos
repositrios na definio de polticas locais de gesto de dados, aos administradores
de repositrios j existentes na tomada de medidas para servios melhorados e aos
programadores de plataformas de repositrios no acrescento de novas funcionalidades
de suporte em futuras verses.
Como cumprir as Directrizes DRIVER? (validao)
Num futuro prximo, o DRIVER oferecer aos repositrios locais um modo para aferir o
grau de conformidade com as directrizes atravs de uma interface Web1. O DRIVER
tambm oferece suporte via Web (ver em baixo Existe Suporte?). Se os pontos
obrigatrios das Directrizes DRIVER forem cumpridos, o repositrio recebe o estatuto
de fornecedor DRIVER validado. Se tambm forem cumpridos os pontos recomendados,
o repositrio recebe o estatuto de fornecedor DRIVER certificado para o futuro. Os
repositrios DRIVER validados podem reutilizar dados do DRIVER para desenvolver
servios locais. Passam a integrar a rede de fornecedores de contedos DRIVER.
E se no cumprir?
No estar em conformidade com todos os pontos obrigatrios ou recomendados das

Directrizes DRIVER no significa necessariamente que os contedos de um repositrio
no sero recolhidos ou agregados pelo DRIVER. Porm, em funo dos servios
especficos oferecidos atravs da infra-estrutura DRIVER, possvel que o contedo
destes repositrios simplesmente no seja recupervel. Por exemplo, um servio de
pesquisa, que pretenda listar apenas registos que ofeream um apontador para o texto
1
Para a validao das Directrizes DRIVER 1.0 ver:
http://validator.driver.research-infrastructures.eu/
12/144 estado: final 2008-11-13

integral no pode processar todo o contedo de um repositrio que oferea

unicamente registos de metadados ou que oculte os textos integrais atravs de
procedimentos de autorizao. Estas directrizes ajudaro a distinguir esses registos. As
Directrizes DRIVER no determinaro, como bvio, que registos devem ser mantidos
num repositrio local.
Existe suporte?
O DRIVER oferece suporte aos repositrios locais para que possam implementar as
directrizes numa base individual. O suporte pode ser obtido atravs da internet2 ou
pode ser pessoal3. O DRIVER est empenhado em qualquer soluo possvel que possa
realizar-se atravs do processamento central de dados. No obstante, o caminho
sustentvel, transparente e escalvel para servios melhorados passa pelos
repositrios locais.
mbito das Directrizes DRIVER
As Directrizes DRIVER so uma norma?
No. Embora o uso de normas como o OAI-PMH proporcione certamente uma base
slida para criar uma rede como o DRIVER, so necessrias directrizes adicionais. O
principal motivo que as normas ainda do lugar a interpretaes e implementaes
locais. Sem isso, uma norma no poderia existir. Porm esta abertura pode-se
converter num obstculo para a obteno de servios de alta qualidade quando se
combinam implementaes divergentes.
As Directrizes DRIVER equivalem a regras de catalogao?
No. As directrizes so um instrumento para mapear (ou traduzir) os metadados

utilizados no repositrio para os metadados em Dublin Core, tal como so 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. No esto pensadas para serem utilizadas como instrues de introduo
de dados na insero de metadados nos sistemas de repositrio locais.
As Directrizes DRIVER possuem instrues do nvel de qualidade cientfica?
No. As directrizes no indicam que recursos possuem o nvel de qualidade requerido

no que respeita ao contedo cientfico. Assumiremos que esta distino j foi feita ao
nvel dos repositrios, isto , assumiremos que a qualidade dos recursos expostos
atravs da recolha suficientemente boa.
Quais so os principais componentes das Directrizes DRIVER?
As Directrizes DRIVER focam basicamente cinco questes: coleces, metadados,

implementao do protocolo OAI-PMH, prticas recomendadas, vocabulrios e
semnticas.
No que respeita s coleces do repositrio, obrigatrio utilizar sets

(conjuntos) que definam as coleces com texto integral. Se todos os recursos
do repositrio forem textuais, inclurem no s os metadados, mas tambm o
texto integral e todos os recursos forem acessveis sem autorizao, o uso de
conjuntos opcional.
No que respeita ao protocolo OAI-PMH, foram definidas algumas caractersticas
obrigatrias e outras recomendadas para solucionar os problemas que surjam
nas diferentes implementaes no repositrio local.
No que respeita aos metadados, foram definidas algumas caractersticas
obrigatrias e outras recomendadas para solucionar as dificuldades semnticas
que surjam de diferentes interpretaes do DUBLIN CORE.
Quem criou as Directrizes DRIVER?
As Directrizes do DRIVER foram compiladas por profissionais com anos de experincia

na construo e manuteno de redes similares de repositrios interligados, como HAL
(Frana), DARE (Pases Baixos), DINI (Alemanha), SHERPA (Reino Unido), e envolvem a
competncia de fornecedores de servios experientes, como o BASE, e organizaes
comunitrias, 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 definies
de trabalho utilizamos as seguintes:
Recurso textual: artigos cientficos, teses de doutoramento, documentos de

trabalho, livros electrnicos e resultados similares de actividades de
investigao cientfica
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 repositrios so utilizados para depositar diferentes tipos de recursos, por

exemplo, artigos, livros, fotografias, vdeos, 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 so usualmente armazenados numa base de dados
que parte do sistema do repositrio (mas nem sempre). O acesso aos recursos
geralmente livre (mas nem sempre). No DRIVER almejamos um subconjunto do vasto
domnio de recursos existentes nos repositrios europeus: focamos recursos textuais
em formato digital e que so de acesso livre.
Estudos indicam que deste modo poderemos cobrir mais de 80% de todos os recursos
disponveis. Por este motivo, a primeira directriz obrigatria da Parte A refere: o
repositrio contm recursos textuais digitais. Isto no significa que o repositrio no
possa incluir outros materiais ou itens no-digitais. A afirmao uma expresso do
foco do DRIVER em recursos textuais. Uma lista completa de recursos textuais
apresentada no elemento dc:type nas directrizes de metadados no captulo Uso de
vocabulrios e semnticas seco Vocabulrio tipo de publicaes. Para a
implementao no dc:type ver captulo Uso de metadados OAI_DC seco Type
(Tipo). Ou para mapear os tipos de acordo com os mapeamentos actualmente
conhecidos ver seco Mapeamento de tipos DRIVER no captulo Uso das prticas
recomendadas com OAI_DC.
15/144 estado: final 2008-11-13

O que so sets?
Sets (conjuntos) so um componente normalizado do protocolo OAI-PMH e so

utilizados para apontar (filtrar) partes especficas de um repositrio. Se o repositrio
tambm contm itens no textuais, ou no digitais, ou itens de acesso pago ou registos
exclusivamente com metadados, pode utilizar o mecanismo de sets para filtrar esses
itens quando disponibilizar os contedos 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 ateno para evitar solues especiais. Assim, poder-
se- afirmar que as Directrizes DRIVER exploram ao mximo a experincia prtica e
outras directrizes existentes a nvel internacional.
O DRIVER foi concebido seguindo a estrutura de redes operacionais e

distribudas de fornecedores de contedos, particularmente a rede DARE na
Holanda. As directrizes DARE servem como modelo para o DRIVER. Ao invs de
indicar mltiplas referncias para outras directrizes espalhadas por todo o
mundo, o DRIVER usou inicialmente as Directrizes DARE e aperfeioou estas
directrizes, adoptando as prticas recomendadas dos gestores de repositrios 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
(verso 1.2), que foi adaptado para cumprir alguns requisitos especficos
do DARE, historicamente conhecido por Uso DRIVER das directrizes OAI-
PMH (Verso 2, Dezembro de 2006), foi ampliado nas Directrizes
DRIVER 2.0 com a colaborao de gestores de repositrios ver captulo
Uso de metadados OAI_DC
o A verso 2.0 do protocolo OAI-PMH (Open Archives Initiative Protocol for
Metadata Harvesting), que tambm foi adaptada aos requisitos
16/144 estado: final 2008-11-13

especficos do DARE e que est disponvel como Uso DRIVER das

directrizes OAI-PMH (Verso 2, Dezembro de 2006) foi ampliada nas
Directrizes DRIVER 2.0 com a colaborao de gestores de repositrios
ver captulo Uso do protocolo OAI-PMH
o O DINI-Certificate Document and Publication Services 2007 (Verso 2,
Septembro de 2006)4 oferece uma base slida sobre o que se deve
considerar na operao de um repositrio. Uma vez que o DRIVER
aborda os repositrios do ponto de vista de um agregador, as Directrizes
DRIVER no cobrem os aspectos descritos no certificado DINI, que est
desenhado como guia geral da operao local de um repositrio. Ao
invs, as Directrizes DRIVER baseiam-se na suposio de que os critrios
do certificado DINI so considerados no funcionamento de um
repositrio.
o O documento Use of MODS for institutional repositories5 foi criado
pelo grupo de especialistas de metadados do programa SURFshare e
utilizado por repositrios holandeses. Estas directrizes apresentam uma
lista prtica de tipos de publicao que garante uma maior
interoperabilidade. Os tipos de publicao so baseados na lista de
publicaes dc:type do documento "DARE use of DC", conjuntamente
com tipos e-prints e tipos de publicao usados no METIS no
desenvolvimento do Dutch Current Research Information System (CRIS).
o O Version Identification Framework6 forneceu uma verso taxionmica7
simples e prtica para artigos de revista e mais. Isto proporcionou um
complemento para melhor descrever os tipos de publicaes existentes
na comunicao cientfica.
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 soluo que resolva de imediato vrios problemas?
Sim, ver o captulo 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 inequvoco para o recurso (no mediante
uma pgina de acesso), suporte a indexao de texto integral e permita a
representao de documentos complexos compostos por vrios ficheiros PDF. O XML-
Container baseado na Digital Item Declaration Language (MPEG21-DIDL)8. Outras
solues baseadas em DIDL tambm foram desenvolvidas (ex. aDORe9, e os perfis
METS10) e outras a publicar no futuro (ex. OAI-ORE11).
Esboo Sumrio das Directrizes DRIVER
O seguinte esboo resume as definies bsicas DRIVER para os tpicos sobre recursos
textuais, utilizao de metadados e implementao do protocolo OAI-PMH. Os detalhes
completos podem ser encontrados nos captulos seguintes.
PARTE A Recursos Textuais
obrigatrio
O repositrio contm recursos digitais textuais (ver explicao O que se

entende por recursos textuais? na pgina 15)
Os recursos textuais esto em formatos profusamente utilizados e difundidos
(PDF, TXT, RTF, DOC, TeX etc.)
Os recursos textuais esto em acesso livre, disponveis directamente do
repositrio para qualquer utilizador sem restries como autorizaes 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 so descritos por registos de metadados

Os recursos textuais e de metadados esto ligados entre si de tal modo, que um
utilizador final possa aceder ao recurso textual atravs do identificador
(normalmente um URL) no registo de metadados
O URL de um recurso inscrito no registo de metadados est permanentemente
acessvel e nunca se altera ou se atribui a outro recurso
Um identificador nico identifica o registo de metadados e o recurso textual
(no h apontadores para sistemas externos, como um sistema nacional de
bibliotecas ou uma editora)
recomendado
Verificao transparente da integridade de um recurso textual

Medidas de controlo de qualidade (do contedo cientifico) dos recursos textuais
expostos para limit-los a, por exemplo, os recursos textuais includos no
relatrio 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 exposio de recursos textuais (captulo Uso
de MPEG-21 DIDL (xml-container) Empacotamento do objecto composto)
PARTE B - Metadados
obrigatrio
Os metadados so estruturados como Dublin Core no qualificado (ISO

15836:2003).
Os elementos individuais de DC devem ser usados de acordo com o captulo
Uso de metadados OAI_DC na pgina 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 sero disponibilizados em futuras verses das
Directrizes DRIVER.12)
O idioma recomendado o ingls
O idioma recomendado para o resumo (a incluso de resumo opcional) do
artigo o ingls
PARTE C Implementao OAI-PMH
obrigatrio
O repositrio deve estar em conformidade com OAI-2.0 e deve estar de acordo

com as especificaes no captulo Uso do protocolo OAI-PMH na pgina 36
Deve existir um identificador de repositrio e deve utilizar-se o esquema de
identificador OAI
Se (e apenas se) o repositrio contm outros recursos para alm dos que so
obrigatrios na PARTE A Recursos Textuais, deve ser definido um OAI-set
que identifique a coleco de recursos textuais digitais com recursos em acesso
livre (ver explicaes Atribuio de nome ao conjunto DRIVER, Definies
do contedo do conjunto DRIVER e Localizao do conjunto (set) nas
pginas 45-47)
recomendado
Disposies para a alterao do URL Base

Resposta completa ao pedido Identify, incluindo o uso opcional da declarao
Description
Uso de estratgia de eliminao persistent ou transient
12
Anteviso das MODS guidelines
20/144 estado: final 2008-11-13

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

expirao do testemunho de reatamento (resumption token).
21/144 estado: final 2008-11-13

Directrizes DRIVER 2.0 O que novo
O que novo
Captulo 1: Uso do OAI-PMH

Atribuio de nome ao conjunto DRIVER
Informao adicional para responder a questes sobre Nomes de conjuntos

recomendados para "Open Access" e sub-coleces de acesso Embargado/Acesso
Retardado"
Ver Atribuio de nome ao conjunto DRIVER na pgina 45
Explicao: recomendado que os repositrios hbridos 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 no deve
conter registos com acesso embargado, porque isso apenas conduz a confuso do
utilizador final, quando este espera encontrar recursos em acesso livre.
No devero existir recomendaes DRIVER sobre conjuntos para e-Teses.
Explicao: As Directrizes DRIVER so para uma comunidade mais ampla. A recolha de

e-Teses dever ser reconhecida atravs dos termos usados no vocabulrio de tipos de
publicao.
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 pgina 45.
Explicao: A experincia diz-nos que os problemas com quebras na comunicao de

um OAI ListRecords acontecem muito raramente. O maior resultado observado at
hoje de registos por resposta foi cerca de 6.500 registos. A consequncia positiva de
um tamanho do lote grande a de que a actividade de recolha (harvesting) muito
rpida e, portanto, esses repositrios possuem uma taxa de transferncia alta.
Testemunho de reatamento (resumption token)
Melhor explicao sobre a necessidade da recomendao da longevidade de um

testemunho de reatamento. Ver: Testemunho de reatamento (Resumption token) na
pgina 43.
Explicao: Existe uma relao entre a longevidade, tamanho do lote e a taxa de

transferncia. Se o dbito de transferncia lento e tamanho do lote pequeno, a
longevidade do testemunho de reatamento deve aumentar. Caso contrrio, o harvester
continua a receber apenas o primeiro lote repetidamente.
Estratgia de registos eliminados
As Directrizes DRIVER explicam agora de forma mais clara porque razo uma estratgia
persistent/transient valiosa tanto para o repositrio como para o fornecedor de
servios.
Explicao: A vantagem para o repositrio em manter um registo de eliminaes a

de que o fornecedor de servios no exibir registos que j no estejam disponveis no
repositrio. Adicionalmente, esta estratgia permite que os harvesters evitem a
recolha completa do repositrio de todas as vezes e torna o processo de recolha mais
eficiente.
Ver: Registos eliminados na pgina 42.
23/144 estado: final 2008-11-13

Captulo 2: Uso de metadados OAI_DC
Identifier (Identificador)
Como lidar com outros identificadores que existam no repositrio. Os identificadores

OAI so permitidos? Para onde deve apontar o identificador? Como devem ser
expostos?
Explicao: A identificao de um recurso foi alargada. O repositrio pode usar

qualquer identificador que seja necessrio para identificar o recurso. Contudo, deve
haver pelo menos um identificador accionvel que aponte para a pgina de transio
(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 accionvel, o
fornecedor de servio ir utilizar, como padro, o primeiro identificador accionvel na
lista para direccionar o utilizador final. Ver: Identifier (Identificador) na pgina 77.
Date (Data)
O que fazer quando a data recomendada nas Directrizes DRIVER (data de criao) no
est disponvel no repositrio?
Nas Directrizes DRIVER: "Use o elemento DC date para o valor do qualificador: data
de publicao. A data preferencial a data de publicao, porque a data mais
significativa e til para o utilizador final. Se a data de publicao no est disponvel,
use outra data disponvel. sempre melhor usar uma data do que nenhuma." Ver: Date
(Data) na pgina 70.
Explicao: Ocorreram duas alteraes:
1. A data de criao mudou para data de publicao; porque esta a mais

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

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

publicao. Explicao: mais do que um campo data cria ambiguidade uma vez que o
DC simples no comporta qualificadores. Por defeito um fornecedor de servios usa a
primeira data na lista para processamento, indexao e apresentao.
Ver: Date (Data) na pgina 70.
Rights (Direitos)
Explicao sobre como usar o campo dc:rights. Ver: Rights (Direitos) na pgina 83.
Language (Idioma)
A recomendao de codificao mudou para ISO 639-3. Ressegurando-se que a ISO 639-
1 e -2 ainda so permitidas, uma vez que podem ser mapeadas correctamente.
Explicao: A codificao ISO 639-3 possui muitos mais idiomas do que ISO 639-1,
mesmo idiomas histricos e idiomas sub-regionais. Isto torna a explicao de certas
publicaes mais fcil. A ISO 639-2 possui dois tipos de codificao (b e t), o que a
torna mais ambgua quando utilizada em OAI-DC. A ltima no proporciona um
atributo que notifica qual dos dois esquemas de codificao foi utilizado.
Ver:
Language (Idioma) na pgina 80.
Creator (Autor)
25/144 estado: final 2008-11-13

De acordo com as Directrizes DRIVER: "Instruo de utilizao quando o nome inicial e
completo esto ambos disponveis use esta formatao: <dc:creator> Janssen, J.
(John)</dc:creator>"
COMENTRIO: No contexto da instruo de utilizao, o que significa ambos

disponveis?
Mudou o nome completo e o nome frente para primeiro nome.
Explicao: 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 no aplicvel
utilize o estilo bibliogrfico APA como numa lista de referncia quando aplicvel.
Quando as iniciais e primeiro(s) nome(s) (referindo-se a essas iniciais) de uma pessoa
esto disponveis, utilize o formato em que o primeiro nome est escrito entre
parnteses curvos aps o estilo do nome APA. A sintaxe deveria ser ento: {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
no estava disponvel.
Ver: Creator (Autor) na pgina 63.
Source (Fonte)
Hiperligao 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)
Mudana de vocabulrio
Devido confuso existente na comunidade internacional de repositrios sobre os

termos para os diferentes tipos de publicaes, os especialistas das Directrizes DRIVER
desenvolveram dois vocabulrios distintos. Um que explica o tipo de publicao
simples e outro que explica as verses utilizadas em comunicao cientfica. Os tipos
de verso podem ser adicionados aos tipos de publicao para criar maior
profundidade e para explicar ainda mais a publicao.
Os tipos publicao so tipos bem pensados que no explicam o tipo de documento,

mas o tipo de publicao. Estas publicaes tm sido utilizadas em processos
acadmicos comuns. Os termos so escolhidos para criar um equilbrio entre no muito
especficos (que s se aplicam a uma comunidade cientfica) e no muito genricos.
Outra coisa que estava a faltar era um espao de nome (namespace) que gerasse um
nvel de autoridade de um vocabulrio controlado. O URI espao de nome info:eu-repo
foi especialmente concedido pelas autoridades para ser utilizado neste propsito.
O vocabulrio para tipos de publicao do DRIVER foi produzido de acordo com estes
critrios.
Ver: Vocabulrio tipo de publicaes na pgina 121.
Para tipos de verses ver: Vocabulrio de verses na pgina 126.
discusso sobre termos
Diferena entre Conference report e Conference lecture?
Explicao: As diferenas foram removidas abstraindo-se para um termo mais geral

"Conference Object".
Mapear entregveis de projectos pblicos para relatrios externos de investigao,

relatrios tcnicos para documentos de trabalho, editoriais para artigo?
27/144 estado: final 2008-11-13

Explicao: Foram efectuados mapeamentos. Ver: Mapeamento de tipos DRIVER na
pgina 87. Foi disponibilizada a descrio dos termos.
Format (Formato)
Explicao: Sobre as limitaes 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 pgina 75.
Captulo 3: Utilizao das prticas recomendadas

para OAI_DC
Mapeamento tipos DRIVER
Explicao: como mapear [x] categorias locais para [y] categorias DRIVER.
Ver: Mapeamento de tipos DRIVER na pgina 87.
Mapeamento verses DRIVER
Explicao: como usar os diferentes estados/verses de publicaes e como mapear

[x] categorias locais para [y] (verses) categorias DRIVER.
Ver: Mapeamento de verses DRIVER na pgina 90.
28/144 estado: final 2008-11-13

Utilizao de OAI_DC com teses
Explicao: como usar OAI_DC com e-Teses e

Dissertaes sem perder interoperabilidade. Ver
Uso do OAI_DC com teses na pgina 92.
DC:SOURCE e DC:RELATION
Explicao: como usar os campos DC:SOURCE e DC:RELATION no que concerne a

comunicao cientfica e repositrios.
Ver: DC:SOURCE e informao de citao na pgina 94 e DC:RELATION e hiperligao

de objectos relacionados na pgina 94.
Captulo 4: Uso de empacotamento de objecto

composto
Foram efectuadas vrias mudanas importantes
Localizao do esquema DIDL errada, validao no possvel

Modificar referncia do espao de nome info:eu-repo
Modificaes so tambm colocadas no exemplo
Alteraes para ir ao encontro do futuro transporte de identificadores de
autores (Author Identifiers)
29/144 estado: final 2008-11-13

Adicionar espao de nome e alterar para localizao de espao de nome vlida
<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

Alteraes no elemento container para possibilitar melhor interpretao semntica
<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>
Alteraes da declarao 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 conveno de texto camelCase (maiusculasInterioresSemEspaos) comeado com

minsculas.
Uso de identificadores persistentes no DIDL
Isto explica a posio do identificador persistente e a "Localizao a ser utilizada para

mecanismos de resoluo".
No nvel superior do elemento item, deve ser adicionado um componente/elemento

que se refere ao URL accionvel deste documento DIDL sem os elementos OAI-PMH.
Quando isto no aplicvel no momento, use o URL da pgina de transio (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 genrico no OAI-PMH
Isto explica o uso real do DIDL e no um esquema derivado.
<request metadataPrefix="dare_didl"
Passa para:
<request metadataPrefix="didl"
Captulo 5: Uso de vocabulrios e semnticas
Foram produzidos dois vocabulrios para reduzir a ambiguidade dos conceitos e termos
utilizados na comunicao cientfica na Europa.
Muitas outras questes foram assim solucionadas:
Tipo de documento: Verses Preprint e Postprint

Tipo de documento: Qual a diferena entre relatrio de investigao
externo e relatrio interno?
Melhoramento no vocabulrio do tipo de documento
Questo se bookChapter no vocabulrio info:eu-repo deveria ser mais genrico
para uma interpretao optimizada pelos fornecedores de servio para uma
combinao de termos ex. chapter e partOf ? Resposta: NO.
Verses de revistas cientficas modelo melhorado
Foi adicionado um captulo sobre o uso de informao de classificao .
Recomenda-se o fornecimento de informaes sobre o uso de classificao num

repositrio na resposta ao Identify e transportar a classificao no elemento subject
(assunto) "URI-fied" utilizado um espao de nome (namespace) de autoridade. Se no
33/144 estado: final 2008-11-13

utilizado nenhum esquema de classificao especfico, o DRIVER recomenda a Dewey
Decimal Classification.
Ver: Uso de vocabulrios e semnticas na pgina 117.
Captulo 6: Anexo: Uso de etiquetas de qualidade
Ver Anexo: Uso de etiquetas de qualidade na pgina 130 para um documento

preliminar.
As Directrizes DRIVER 2.0 apresentam informao bsica sobre a importncia da

qualidade e interoperabilidade. Etiquetas de qualidade podem ser utilizadas para
assegurar repositrios estveis e fiveis que durem mais tempo e que possuam um
propsito de arquivo de preservao a longo prazo.
Como exemplos de etiquetas de qualidade pode-se mencionar: o Data Seal of Approval

e o DINI Certificate.
Captulo 7: Anexo: Uso de identificadores

persistentes
Ver Anexo: Uso de identificadores persistentes na pgina 131 para um documento

preliminar.
Identificadores persistentes para recursos Web so necessrios para criar uma infra-
estrutura estvel e fivel. Isto no diz respeito a aspectos tcnicos, mas,
principalmente, a acordos a um nvel organizacional.
34/144 estado: final 2008-11-13

As Directrizes DRIVER podem produzir algumas recomendaes sobre a implementao
para gestores de repositrios. Na base est o Relatrio sobre Identificadores
Persistentes do projecto PILIN.
Foi disponibilizado um plano de implementao.
Captulo 8: Anexo: Intercmbio de estatsticas de

utilizao
Ver Anexo: Intercmbio de estatsticas de utilizao na pgina 137 como documento

preliminar.
Para aferir valor do Acesso Livre e oferecer servios adicionais aos seus autores, os
repositrios devem pensar na agregao de estatsticas de utilizao.
Dois projectos iro ganhar dimenso e ajudaro a desenvolver directrizes para o

intercmbio de dados de utilizao: PIRUS e OA-Statistik
Captulo 9: Anexo: Uso de direitos de propriedade

intelectual
Ver Uso de direitos de propriedade intelectual na pgina 143 para um documento

preliminar.
Este captulo aborda uma temtica importante sobre direitos de utilizao e direitos
de depsito. Na prtica, isto deve ser implementado. As Directrizes DRIVER devem
dizer algo sobre a forma como os direitos de utilizao 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
Introduo
Este captulo explica como usar o OAI-PMH para que os repositrios e os fornecedores
de servios possam trabalhar perfeitamente em conjunto, criando interoperabilidade
ao nvel do protocolo.
Nota:
Os exemplos usados para DIDL, NO devem ser utilizados literalmente! Para o uso
correcto do documento DIDL ver a verso actual do documento especificaes DIDL.
Esse documento ir sobrepor-se a todos os exemplos DIDL mencionados aqui.
Agradecimentos
Este documento baseado em grande medida nas discusses entre gestores de

repositrios e o SURF. Eles ofereceram a sua experincia e sugestes para criar as
Directrizes DRIVER conforme apresentadas no presente documento.
37/144 estado: final 2008-11-13

Fonte de informao
As Directrizes DRIVER so baseadas em e referem-se ao Open Archives Initiative

Protocol for Metadata Harvesting, verso do protocolo 2.0.
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html
A ordem de apresentao 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 realado a negrito para destacar alguma parte do texto, isso foi
indicado entre parnteses.
Definies 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 mltiplos formatos,
cada um dos quais pode ser recolhido como registos atravs do protocolo OAI-PMH
...Um registo so 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... [negrito adicionado por MF]
No DRIVER, recomenda-se a construo do XML-encoded stream de acordo com

especificaes XML-Container. Estas especificaes so referidas em seguida.
38/144 estado: final 2008-11-13

Identificador (identifier)
O identificador nico identifica um item num repositrio. No confundir este

identificador com o elemento dc:identifier no Dublin Core. O identificador OAI possui
uma funo diferente: utilizado para extrair metadados, enquanto o identificador DC
utilizado para extrair o recurso. Esquematicamente:
Item com Identificador nico
Dentro do
repositrio
Fora do Registo com Registo com

repositrio 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 disseminao de registos em mltiplos formatos de

metadados de um repositrio. 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 cabealhos dos registos que incluem metadados no formato especificado
pelo metadataPrefix. Por razes de interoperabilidade, os repositrios devem
disseminar Dublin Core sem qualificadores. Por esse motivo, o protocolo reserva o
metadataPrefix oai_dce a URL de um esquema de metadados para Dublin Core no
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 implementao dos prefixos de metadados oai_dc e

o metadataPrefix didl. Cada repositrio DRIVER que utilize o XML container deve
admitir este esquema didl de metadados. A especificao didl do XML container
pode ser encontrada no captulo Uso de MPEG-21 DIDL (xml-container)
Empacotamento do objecto composto na pgina 96.
<OAI-PMH ...>
<...>
<record>
<metadata>
<didl:DIDL>
Data de registo (Datestamp)
De acordo com o protocolo, cada registo contm um cabealho com um registo de

data (datestamp) que contm "a data de criao, modificao ou eliminao do
registo para o propsito de harvesting selectivo."
40/144 estado: final 2008-11-13

O protocolo tambm 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 repositrio dentro dos
limites dos argumentos from e until.
deletion - dependendo do nvel a que o repositrio mantenha informao
sobre os registos eliminados, a resposta pode incluir cabealhos de
registos, correspondentes ao argumento metadataPrefix, que foram
retirados do repositrio dentro dos limites dos argumentos from e until. O
estado eliminado indicado atravs do atributo de estado do elemento
header e no se incluem metadados...
muito, muito importante ter especial cuidado na implementao da data de registo

(datestamp) de acordo com as especificaes do protocolo acima referenciadas. A
experincia diz-nos que muitos dos erros de recolha (harvesting) que ocorrem na
recolha incremental tm a sua origem na m interpretao 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 especificaes 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 especificaes para o UTCdatetime nas seces 3.3.1
no documento do protocolo OAI-PMH. Registos de datas so codificados usando a
norma ISO8601 e expressos em UTC.
<OAI-PMH ...>
<...>
<GetRecord>
<record>
<header>
<datestamp>2001-12-14T12:01:45Z</datestamp>
Um repositrio 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 disponvel, considera-se eliminado. Os repositrios devem

declarar um dos trs nveis de suporte relativamente a registos eliminados no
elemento deletedRecord da resposta ao Identify:
no - o repositrio no mantm informao sobre as eliminaes. Um

respositrio que indique este nvel de suporte no deve revelar um estatuto de
eliminao em qualquer resposta
persistent - o repositrio mantm informao sobre as eliminaes sem
qualquer limite de tempo. Um repositrio que indique este nvel de suporte
42/144 estado: final 2008-11-13

deve manter sistematicamente um registo do historial das eliminaes e
consistentemente revelar o estado de um registo eliminado ao longo do tempo
transient - o repositrio no garante a manuteno de uma lista de eliminaes
de forma persistente e consistente. Um repositrio que indique este nvel de
suporte pode revelar o estado dos registos eliminados
As directrizes do DRIVER requerem que os repositrios DRIVER usem a opo

transient. Mas a opo persistent tambm poder ser utilizada. Esta opo
facilita a deteco de registos eliminados pelo harvester.
A vantagem para o repositrio em manter um registo de eliminaes a de que o

fornecedor de servios no exibir registos que j no estejam disponveis no
repositrio. Adicionalmente, esta estratgia permite que os harvesters evitem a
recolha completa do repositrio de todas as vezes e torna o processo de recolha mais
eficiente.
Utilizao do nvel transient: Quando um registo eliminado, o repositrio deve

indicar a eliminao durante, pelo menos, um ms. Neste perodo, a maioria dos
harvesters actualizaram a sua base de dados incrementalmente (sem necessidade de
uma recolha harvest - completa).
Se um repositrio possui um registo das eliminaes, ento 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
ento incluir um header com o atributo status="deleted". Assim, a recolha
incremental detectar eliminaes em repositrios que faam o seu registo.
Testemunho de reatamento (Resumption token)
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Idempotency
Os repositrios que implementem testemunhos de reatamento (resumptionTokens)

devem faz-lo de tal forma que os harvesters possam retomar uma sequncia 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 reincio da sequncia de pedidos.
O protocolo no menciona o tempo de vida de um testemunho. A longevidade de um

testemunho o tempo durante o qual um repositrio o conserva em memria
conjuntamente com a informao de reatamento. Quando a longevidade demasiado
pequena, o repositrio no d tempo suficiente para um harvester voltar e recolher a
informao. Quando isto acontece, o repositrio no cumpre com o protocolo, ver em
cima: devem faz-lo de tal forma que os harvesters possam retomar....
Boa prtica: o tempo razovel para que um testemunho seja conservado de pelo
menos vinte e quatro (24) horas. Isto depende do tamanho do repositrio e da
velocidade de processamento e por isso a longevidade do testemunho de reatamento
dever aguentar o tempo suficiente para transportar o lote nesse perodo de tempo.
Conjuntamente com este tempo de vida existe um tamanho de lote ptimo - ver
seco 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 informao pode ser utilizada durante o processo de recolha e
pode ser comparada com o resultado do tamanho total por razes de controlo (por
exemplo, a recolha est completa ou incompleta?). Alm disso, as informaes podem
ser teis para a manuteno do processo de recolha com o fito de estimar o tempo
necessrio.
O testemunho de reatamento numa resposta OAI poderia assemelhar-se ao seguinte (os

atributos expirationDate, completeListSize e cursor so 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 nmero de registos que um repositrio entrega ao harvester
para um testemunho de reatamento (resumption token) e determina quantos processos
de pedido tm de ser executados.
Est acordado que os repositrios DRIVER devem definir o tamanho do lote entre 100 a
500 registos.
Utilizando este tamanho de lote para todos os repositrios DRIVER, permitir que o
harvester opere com um rendimento ptimo.
Atribuio de nome ao conjunto DRIVER
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Set
O documento do protocolo OAI-PMH refere o seguinte: Os repositrios podem organizar

os itens em conjuntos (sets). A organizao dos conjuntos pode ser plana, isto , uma
simples lista, ou hierrquica.
Est acordado que os repositrios DRIVER hbridos 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 no possui nenhuma estrutura
hierrquica. O contedo do conjunto DRIVER recursos de Acesso Livre, disponveis
livremente. Recursos com acesso diferido ou embargados no devem estar nesta lista
para evitar confuso ao utilizador final. A tabela seguinte indica o setName e a
especificao 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 minsculas.
45/144 estado: final 2008-11-13

Definies do contedo do conjunto DRIVER
O contedo especfico do conjunto driver determinado no repositrio local. Um

repositrio 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 contm registos que devem conter recursos textuais digitais
de acesso livre
o Deve conter objectos de texto integral, no apenas metadados

o O contedo de acesso livre
o O contedo no protegido por firewall
o O contedo tambm acessvel fora do campus universitrio
o O contedo no se encontra em websites que exijam pagamento
A figura seguinte mostra que possvel inserir um registo em diferentes conjuntos

(sets). Os registos em baixo, representados por um ponto azul, tambm existem no
conjunto driver. Dois registos existem nos trs sets. O conjunto de bioqumica
(biochemistry set), o conjunto de neurofsica (neurophysics set) e o conjunto driver.
Os dois primeiros so conjuntos que indicam um assunto, o conjunto driver indica um
tipo (acesso livre). O cabealho 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

Ilustrao:
Registos no conjunto
DRIVER Todos os registos no
repositrio local
Registos no
conjunto
Biochemistry
Registos no conjunto
Neurophysics
Localizao do conjunto (set)
O conjunto DRIVER e outros conjuntos podem estar localizados em diferentes

localizaes/baseURls.
Correio electrnico do administrador para

feedback de erros
Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Identify
O repositrio deve proporcionar um endereo de correio electrnico do administrador

para o pedido Identify.
Num futuro prximo pretendemos que o harvester fornea uma resposta imediata ao
administrador do repositrio para informar sobre os erros que este repositrio 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 endereo de correio electrnico do administrador.
<OAI-PMH ...>
<...>
<Identify>
<adminEmail>somebody@loc.gov</adminEmail>
<adminEmail>anybody@loc.gov</adminEmail>
<...>
O uso de um adminEmail no pedido Identify obrigatrio, e tambm estipulado

no protocolo OAI-PMH. Ver em baixo:
O pedido (verb) Identify utilizado para recuperar informao acerca de um

repositrio.
A resposta deve incluir uma ou vrias instncias do seguinte elemento:
adminEmail : o endereo de correio electrnico de um administrador do

repositrio.
Informao descritiva de provenincia
O contentor (container) da descrio na resposta ao Identify pode ser utilizada para

fornecer informaes adicionais sobre o repositrio. Os fornecedores de servios
podem olhar para isto e melhorar o processamento dos seus dados e os servios
baseados nos metadados e na sua qualidade.
Boa prtica: Use este contentor (container) para descrever o maior nmero possvel de
informaes comuns sobre o repositrio quanto com incluso de exemplos. Isto inclui
esquemas de classificao (em que formato em que elemento), vocabulrios utilizados
(tipo, idioma), polticas e informaes de contextualizao.
48/144 estado: final 2008-11-13

Enquanto a resposta ao Identify se relaciona com o nvel do repositrio, o nvel de
registos pode conter informao adicional no elemento about. Para permitir que os
fornecedores de servios possam atribuir o material recolhido, pode ser utilizado o
sub-elemento provenance.
Boa prtica: 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

Declarao de prefixo e espao de nomes

Ver: http://www.openarchives.org/OAI/openarchivesprotocol.html#Record
Declaraes de espao de nomes (namespace declarations) - declaraes de espaos

de nomes utilizadas na parte dos metadados, so todas precedidas com o prefixo
xmlns. As declaraes de espao de nome nos metadados dividem-se em duas
categorias:
metadata format specific namespace(s) - cada parte dos metadados deve

incluir um ou vrios atributos com prefixo xmlns que definam a
correspondncia entre um prefixo de formato -- ex. didl e o URI do espao de
nomes (tal como se define na especificao do espao de nomes XML) do
formato de metados correspondente. Alguns formatos de metadados utilizam
etiquetas de vrios espaos de nomes, requerendo vrios atributos com prefixo
xmlns - no exemplo, existem declaraes 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
espao de nomes do esquema XML (XML schema).
xsi:schemaLocation - o seu valor um par URI, URL; o primeiro o URI de
espao de nome (conforme definido pela especificao de espao de nomes
XML) dos metadados que o seguem nesta parte, o segundo o URL do esquema
XML para validao dos metadados que o seguem.
O uso recomendado de prefixos e espaos de nomes indica que estas entidades devem
ser declaradas no primeiro elemento desse espao 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 declarao

de espao de nomes no se proporciona directamente na entidade do documento XML,
mas mediante um atributo predeterminado declarado numa entidade externa.
Exemplos de usos recomendados de prefixos e espaos 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 autnoma que pode existir fora de um registo OAI. Quando se faz um
pequeno extracto (snippet) deste documento DIDL ele deveria ser vlido de acordo
com um validador XML. Por isso, no necessita de nenhum dos textos da declarao de
espao 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 tambm possvel declarar prefixos
e espaos de nomes nos antecessores do documento.
O prefixo do espao de nomes (namespace prefix), a no ser que seja xml ou xmlns,
DEVE ter sido declarado num atributo da declarao de espao 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 contedo se declara o prefixo).
Exemplos dos usos opcionais de prefixos e espaos 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>
Validao XML
O XML que o repositrio disponibiliza como resultado ser validado automaticamente

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

A validao pode ser testada usando um validador XML (por exemplo, Altova:
www.altova.com) salvando o resultado do repositrio 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 lgica: conservar os metadados independentes

do protocolo OAI-PMH.
Comunicao para modificao nos repositrios
Modificao para baseURL, setSpec, metadataPrefix ou esquema de metados
Quando um repositrio DRIVER alterar a baseURL, setSpec, metadataPrefix ou o

esquema de metadados que influenciam o ciclo de contedos do DRIVER, ento o
administrador do repositrio em questo 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 captulo descreve a viso do DRIVER relativamente interoperabilidade para
comunicao cientfica. Isto significa correco qualitativa dos metadados dos registos
baseada no uso de padres.
Agradecimentos
Este documento baseado em larga medida nas recomendaes para o uso de

metadados Dublin Core no qualificados (simples) conforme descrito em: USING SIMPLE
DUBLIN CORE TO DESCRIBE EPRINTS, por Andy Powell, Michael Day e Peter Cliff,
UKOLN, University of Bath, Verso 1.2
Ver: http://www.intute.ac.uk/publications/eprints-uk/simpledc-guidelines.html
Informaes adicionais, descries, explicaes, comentrios, instrues de utilizao

e prticas recomendadas foram cuidadosamente disponibilizadas com a ajuda de todos
os colaboradores das Directrizes DRIVER, com o intuito de criar interoperabilidade
sintctica e semntica que seja adequada para a maioria dos repositrios europeus.
Definies
Um repositrio institucional (RI) um servio composto por hardware, software,
dados e procedimentos, que contm recursos digitais que representam qualquer tipo
de produo cientfica
recursos digitais = qualquer sequncia de bits, independentemente do seu contedo

ou formato, registado como produo cientfica por uma pessoa autorizada
Neste documento, utilizaremos a palavra recurso para descrever um exemplo de

produo cientfica e a palavra objecto para referir sequncia de bits digital.
Quando Obrigatrio referido pretendemos dizer: 1) algo requerido; uma

necessidade. 2) algo especificado como obrigatrio.13
Quando Recomendado referido pretendemos dizer: 1) apresentado com

aprovao como sendo adequado para uma finalidade ou papel. 2) aconselhado como
uma aco a seguir. 3) apelativo ou desejvel.13
Notas introdutrias
mbito
As Directrizes DRIVER foram produzidas primordialmente para facilitar a troca de

metadados entre os fornecedores de contedo do DRIVER e servios do DRIVER, de
acordo com as definies DCMI para Dublin Core no qualificado (simples) conforme
descrito nas especificaes OAI-PMH.14 Basicamente estas directrizes descrevem o
mapeamento de um formato interno para Dublin Core no qualificado (simples) para
13
Compact Oxford Dictionary of Current English third edition
14
Especificaes 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 no devem ser utilizadas como
instrues de catalogao.
Nestas Directrizes DRIVER os gestores de repositrios devem aceitar o facto de que

nem tudo pode ser expresso com DC no qualificado, estas directrizes, iro pois,
concentrar-se nas informaes mais importantes na perspectiva do utilizador final,
que no um bibliotecrio.
Requisitos mnimos
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 apndice
obrigatria a utilizao de Unicode
Os valores (isto , os contedos reais) dos seguintes elementos DC no devem

conter linguagem de marcao em HTML (ou XML). Podem conter comandos
LaTeX, mas no existe um mecanismo explcito para indicar que se est a usar
LaTeX.
Recomendaes
Utilize os metadados numa estrutura granular superior como Dublin Core

qualificado ou MODS. (Trabalho futuro, adies s Directrizes DRIVER)
As directrizes de metadados DRIVER apenas se referem aos metadados como
um formato de troca. No explicitam (hard code) as recomendaes feitas nas
Directrizes DRIVER nem usam um mapeamento entre as estruturas granulares
superiores de metadados implementadas localmente e as recomendaes
DRIVER.
O idioma recomendado para informao descritiva o ingls, para que o
utilizador final possa obter documentos reconhecveis que de outro modo
estariam fechados num contexto nacional.
57/144 estado: final 2008-11-13

Edies e diferena no contedo intelectual
Apenas um registo de metadados deve ser utilizado para diferentes manifestaes de

um objecto digital (por exemplo um postscript e uma verso pdf), a menos que o
contedo intelectual seja diferente. A prtica comum a de criar um novo registo de
metadados quando o contedo intelectual diferente. Isto acontece por exemplo,
quando uma nova "edio", com modificaes no contedo intelectual, criada. Nesse
caso, a prtica recomendada usar o elemento relao (relation) para ligar a verso
mais recente para a mais antiga.
Esquemas de classificao e Polticas de reviso
Em alguns casos, informao adicional sobre polticas de reviso local, o uso de

elementos de metadados dc:subject e dc:type em esquemas de classificao local ou
vocabulrio controlado de palavras-chave, pode ser til para a parte da recolha
(harvesting) e fornecedor de servios. Um fornecedor de contedos apresenta
tipicamente este tipo de informao atravs do Identify request ao nvel do
repositrio; no ao nvel 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 prticas recomendadas. Ao nvel do elemento
dc isto pode ser feito adicionando um URI a um termo. Para esquemas de classificao
que ainda no possuem um espao de nome (namespace) adicionando um sub-espao
de nomes ao info-uri namespace pode ajudar. (ver www.info-uri.info)
Simplificao e Qualificadores
Informao sobre o uso de refinamentos (qualificadores). Quando se realiza a

converso para DC no qualificado, o fornecedor de contedo tem de fazer escolhas
quando o formato interno mais rico que o DC no qualificado. Isto significa que
durante o processo de mapeamento, todos os refinamentos so simplesmente
descartados (o princpio de simplificao da DCMI). O efeito que se produz com este
princpio de simplificao 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 ttulo principal e o ttulo 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 No qualificado
<dc:title>Main title:Sub-title </dc:title>
Interpretaes predefinidas de elementos dc
Contudo, no DRIVER os seguintes valores so seleccionados como valores predefinidos

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

dc:date -> valor predefinido published (publicao)
dc:audience -> valor predefinido education level (nvel de educao)
No DRIVER, isto significa que o elemento date (data) est sempre associado data de
publicao, etc. Recomenda-se que todos os fornecedores de contedos facultem esta
informao a harvesters externos como informao sobre seu repositrio (na resposta
ao Identify OAI-PMH).
Tabela 1: exemplo de notificao ao fornecedor de servio sobre a interpretao 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: descrio abreviada
No DRIVER o uso de elementos pode ser:
obrigatrio (mandatory M na tabela seguinte) = o elemento deve estar

sempre presente no registo de metadados. Um elemento vazio no permitido.
obrigatrio quando aplicvel (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) = no muito relevante se o
elemento ou no usado
O estatuto recomendado apresentado essencialmente para incentivar os utilizadores

a introduzir alguns elementos no momento da criao de um registo de metadados
para melhorar servios.
DC no qualificado: oai_dc
Elemento Estatuto Esquema de codificao

bsico
Title (Ttulo) M Nenhum, texto livre.
Creator M Estilo bibliogrfico APA como numa lista de referncias.
(Autor) Sintaxe: apelido, iniciais (primeiro nome)
[http://en.wikipedia.org/wiki/Apa_style#Reference_list]
Subject MA A escolha de palavras-chave e classificaes pode ser
60/144 estado: final 2008-11-13

(Assunto) texto livre (preferencialmente em ingls) e definidas por
um esquema URI (preferencialmente info:eu-
repo/classification).
Description MA Nenhum, texto livre. A prtica recomendada a de incluir
(Descrio) um resumo em ingls. Abstract a interpretao
predefinida para o valor dc:description
Publisher R Nenhum
(Editora)
Contributor O Estilo bibliogrfico APA como numa lista de referncias.
(Colaborador) Sintaxe: apelido, iniciais (primeiro nome)
Date (Data de M Data | ISO 8601 W3C-DTF - Published a interpretao
publicao) predefinida para o valor dc:date
Type (Tipo) M Tipo de publicao e tipo de verso podem ser texto livre
(preferencialmente em ingls) 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, hiperligao para identificadores
(Identificador) persistentes (URN, handle, DOI), documento de texto
integral ou pgina de transio (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
(Relao)
Coverage O Period a interpretao 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 codificao ver captulo 5 Uso de
vocabulrios e semnticas.
Rights R Nenhum
(Direitos)
Audience O Nenhum. Education level a interpretao predefinida
(Pblico) para o valor dc:audience.
Se nenhuma interpretao predefinida mencionada nos elementos oai_dc na tabela

em cima, por favor descreva o uso especfico dos elementos oai_dc na seco
Identify do seu repositrio. 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: descrio completa
Em seguida apresenta-se descries completas dos elementos.
As definies DCMI provm do documento de directrizes DCMI: Using Dublin Core -

The Elements. Ver: http://dublincore.org/documents/usageguide/elements.shtml .
Title (Ttulo)
Nome do Title
elemento
Definio Nome atribudo ao recurso. Normalmente, o ttulo o nome pelo qual o
DCMI recurso formalmente conhecido.
Uso Obrigatrio
Instrues Conservar o texto original, a ordem e a ortografia do ttulo do recurso.
de uso Utilizar maisculas apenas para nomes prprios. A pontuao no tem
que reflectir o uso do original. Os subttulos devem separar-se do ttulo
62/144 estado: final 2008-11-13

mediante dois pontos. Esta instruo resulta em Ttulo:Subttulo (sem
espaos). Se necessrio, repetir este elemento para mltiplos ttulos.
No
confundir (n.a.)
com
Exemplos <dc:title>Ttulo principal : Ttulo 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
Definio A principal entidade responsvel pela criao dos contedos do recurso.
DCMI Normalmente, o nome de um Creator dever ser utilizado para indicar
a entidade.
Uso Obrigatrio
Instrues Uma pessoa, uma organizao ou um servio podem ser um Creator. Se
de uso necessrio, repetir este elemento para mltiplos 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 no qualificado recomenda-se a utilizao de

um estilo de escrita normalizado para os nomes, utilize o estilo utilizado
pela editora, quando esteja disponvel. Quando no esteja disponvel
utilize a codificao da APA bibliographic writing style as in a reference
list quando aplicvel. (fora do mbito do DC no qualificado mtodos de
63/144 estado: final 2008-11-13

formatao mais precisos e granulares esto disponveis).
Quando se dispe da inicial e do nome completo, utilizar o seguinte

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

apelido. Em caso de dvida, atribuir o nome tal como aparece, sem
inverter. Omitir ttulos (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 organizaes 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 existncia de uma hierarquia no clara ou se no clara a ordem

hierrquica decrescente, atribuir o nome tal como aparece no recurso.
Codificar apenas as organizaes neste elemento para indicar autoria

corporativa, no para indicar a afiliao de um indivduo.
A incluso de cabealhos de nomes de pessoas ou colectividades a partir

de ficheiros de autoridade nacionais ou locais opcional.
Recomenda-se a codificao de thesauri com um URI, para que os

fornecedores de servio reconheam o esquema de thesaurus.
Por exemplo:
<dc:creator> urn:NationalOrgThesaurus:nl/234 </dc:creator>
Nos casos de responsabilidades secundrias, que no de autoria, utilizar
64/144 estado: final 2008-11-13

dc:contributor. Se a natureza da responsabilidade ambgua, a prtica
recomendada utilizar dc:publisher para organizaes e dc:creator para
indivduos.
No Contributor (ver tambm Instrues 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 prprio recurso,
enquanto o elemento DC contributor descreve o(s) investigador(es) que
contriburam para um resultado cientfico, no 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
Definio O assunto do recurso. Normalmente, o elemento subject ser expresso
DCMI como palavras-chave, frases chave ou cdigos de classificao que
descrevam o contedo intelectual do recurso.
Uso Obrigatrio se aplicvel
Instrues No elemento DC subject admitem-se dois tipos de valores possveis:
de uso pode-se registar uma palavra-chave ou uma classificao. Se ambos esto
disponveis, utilizar instncias separadas deste elemento.
Utilizar a primeira instncia 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

especfico. Se o assunto do recurso uma pessoa ou uma organizao,
utilizar o mesmo formato de nome que usaria se a pessoa ou a
organizao fossem o autor, mas no repetir o nome no elemento
dc:creator.
Nas palavras-chave no controladas por um vocabulrio ou thesaurus (isto

, em texto livre), introduzir diferentes termos com um ponto e vrgula a
separar cada palavra-chave ou frase-chave, ou repetir o elemento para
cada termo. No h nenhum requisito relacionado com as maisculas nas
palavras-chave, mas recomenda-se manter uma coerncia interna (dentro
do mesmo repositrio).
Quando os termos so retirados de um esquema de classificao

normalizado: registar cada termo num elemento separado. Inscrever o
descritor completo do assunto segundo o esquema correspondente.
Utilizar as maisculas e a pontuao segundo o esquema original.
Recomenda-se a utilizao de um URI quando se utiliza esquemas de

classificao ou vocabulrios controlados especialmente quando so
utilizados esquemas codificados DDC ou UDC. Os fornecedores de servios
podem considerar esquemas de codificao mais fceis quando o
esquema "URI-fied" por um espao de nome (namespace) de
autoridade. Quando o esquema de classificao codificado, utilize um
texto de leitura humana do cdigo, de preferncia em ingls,
directamente por baixo do elemento codificado. Por exemplo:
<dc:subject>info:eu-repo/classification/ddc/641</dc:subject>
<dc:subject>Anatomy</dc:subject>
Se no utilizado nenhum esquema de classificao especfico

recomendamos o Dewey Decimal Classification (DDC). Os primeiros 1000
termos so designados por Dewey Decimal Classification Summary e
podem ser descarregados em:
http://www.oclc.org/dewey/resources/summaries/ se algum concordar
com os seguintes termos e condies:
66/144 estado: final 2008-11-13

http://www.oclc.org/research/researchworks/ddc/terms.htm
No Type
confundir
com O elemento DC subject descreve o(s) assunto(s) de um recurso; o
elemento DC type descreve o tipo de publicao/resultado acadmico
que o recurso representa.
Esquema Para mais informao sobre classificao de assuntos, ver a seco
Classificao de assuntos na pgina 119 no captulo Uso de
vocabulrios e semnticas.
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 (Descrio)
Nome do Description
elemento
Definio Informao sobre o contedo do recurso. A descrio pode incluir, mas
DCMI no se limita a: um resumo, sumrios, referncias a representaes
grficas do contedo ou texto livre com informao do contedo.
Instrues Este elemento utilizado para uma descrio textual do contedo.
de uso Quando um recurso consiste em vrios ficheiros de objectos fsicos
independentes, no usar dc:description para listar os URLs destes
ficheiros.
Predefinido = abstract
No
confundir (n.a.)
com
Exemplos <dc:description>Prefcio [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
Definio Uma entidade responsvel pela disponibilizao dos recursos. Uma
DCMI pessoa, uma organizao ou um servio podem constituir exemplos de
Editor. Normalmente, o nome de um Editor dever ser utilizado para
mencionar a entidade.
Instrues O Editor (comercial ou no-comercial) do recurso e no a instituio
de uso qual o autor est afiliado. O Editor utiliza-se unicamente no sentido
bibliogrfico/funcional, no num sentido organizacional. Utilizar apenas
o nome completo (comercial) do Editor, no o de uma organizao ou
instituto que esteja associado (num sentido mais amplo) ao autor.
No caso de publicaes universitrias, colocar o nome da faculdade, da

escola ou do grupo de investigao depois do nome da universidade. No
caso de organizaes onde exista claramente uma hierarquia presente,
enumerar as partes da hierarquia por ordem decrescente, separadas
com pontos. Se no clara a existncia de uma hierarquia, ou se a
ordem hierrquica decrescente no 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.
No Contributor
confundir
68/144 estado: final 2008-11-13

com Creator
Na maioria dos casos o Editor e o Autor no so 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
Definio Uma entidade responsvel por realizar contributos para o contedo do
DCMI recurso. Uma pessoa, uma organizao ou um servio podem constituir
exemplos de um colaborador. Normalmente, o nome de um colaborador
dever ser utilizado para referenciar a entidade.
Uso Opcional
Instrues Exemplos de colaboradores: orientadores, editores, tcnicos ou
de uso colectores de dados.
Nomes pessoais devero ser listados como: ver instrues em

Creator. Um orientador, isto um professor que oriente o trabalho
de um aluno para obteno de um grau de doutoramento considerado
um colaborador no seu papel de orientador/avaliador. Em DC no
qualificado difcil expressar todos os papis em diferentes contextos.
69/144 estado: final 2008-11-13

Na Tese de Doutoramento (TD) como um documento, as principais
figuras so o autor e o orientador. No processo global de uma TD esto
envolvidos outros papis, como os membros da comisso cientfica do
jri e do presidente do jri, mas no DC no qualificado estes papis no
so comportados.
No caso das organizaes: ver instrues em Creator. A incluso de

cabealhos de nomes de pessoas ou colectividades a partir de ficheiros
de autoridade nacionais ou locais opcional.
No Creator
confundir Publisher
com
O elemento DC contributor descreve o(s) investigador(es) que
contriburam para o resultado cientifico, no 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
Definio A data associada a um evento no ciclo de vida do recurso. Normalmente,
DCMI a Data est associada criao ou disponibilizao do recurso. A prtica
recomendada para codificar o valor data definido na norma ISO 8601
[W3CDTF] e segue o formato YYYY-MM-DD.
Uso Obrigatrio
Instrues 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 dgitos] obrigatrio
- MM [ms com dois dgitos (01=Janeiro, etc.)] opcional
- DD [dia do ms com dois dgitos (de 01 at 31)] opcional
Um campo de data Data de publicao:

Frequentemente os repositrios possuem mais do que um campo data
com diferentes propsitos. Data de criao, publicao, modificao,
promoo, etc. O DC no qualificado no capaz de expressar todas
essas datas, e do ponto de vista do utilizador final gera confuso a
obteno de mais datas a partir do fornecedor de servios. O fornecedor
de servios deve efectuar uma escolha do campo data que pretende
expor. Preferencialmente, na perspectiva dos utilizadores finais a data
mais lgica e significativa a data de publicao.
Para reduzir a ambiguidade da existncia de um nmero de campos data
sem qualificador, recomendamos a reduo do nmero de campos e
apresentar a data mais significativa ao fornecedor de servios. Na
maioria dos casos, esta a data da publicao. Em outros casos, esta a
data de defesa de uma tese/dissertao.
A data de publicao no est disponvel:

Se a data de publicao no est disponvel, utilize outra data. melhor
usar uma data do que nenhuma.
Datas de registo adicionais:

Extras como Zulu time NO devero constar nos metadados.
Datas imprecisas:
Para datas imprecisas utilizar um ano lgico que melhor represente o
perodo em causa, ex. "1650" ao invs de Sculo 17
71/144 estado: final 2008-11-13

Para expressar mais acerca desse perodo temporal, podemos utilizar o
campo dc:coverage. Um perodo temporal pode ser expresso numa
forma padronizada quando definido precisamente (ver Coverage
(Cobertura)) ou quando imprecisa ou incerta por expresses de texto
livre.
Um fornecedor de servios capaz de ordenar datas com base em
padres de datas como W3CDTF. Como no existe norma para termos de
datas imprecisas como "Renascena" ou "Sculo 17", estes simplesmente
no aparecero nos resultados de pesquisa de data.
No
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
Definio O tipo de resultado cientfico do qual o recurso uma manifestao. No
DCMI elemento DC type, descreve-se o tipo de divulgao ou o tipo de
contedo 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 trs propsitos:
1. Obrigatrio: Tipo de publicao (controlado): para indicar o tipo
de publicao baseado no vocabulrio controlado de tipo de
publicaes DRIVER,
2. Opcional: Tipo de publicao (livre): para indicar o tipo de
publicao baseado num vocabulrio de repositrio local
3. Recomendado: Verso (controlado): para indicar o estado do
72/144 estado: final 2008-11-13

processo de publicao.
Instrues 1. Tipos de publicao (controlado):
de uso
A primeira ocorrncia do elemento DC 'type' obrigatria e dever ser
utilizada para a indicao do tipo de produo cientfica baseada no
vocabulrio de tipos DRIVER. Utilizar a sequncia exacta de caracteres
conforme apresentado na lista em baixo. Os termos so explicados em
detalhe no captulo sobre vocabulrios e semnticas. Info:eu-repo um
espao de nome (namespace) onde os tipos de publicao DRIVER so
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 publicao (texto livre):
A segunda ocorrncia do elemento DC 'type' opcional e dever ser

utilizada para indicar o subtipo da produo cientfica.
3. Verso (controlado):
73/144 estado: final 2008-11-13

A ltima ocorrncia do elemento DC 'type' recomendada e dever ser
utilizada para indicar a verso da produo cientfica baseada no
vocabulrio de verses DRIVER. Utilizar o texto exacto conforme
apresentado na lista em baixo. Para mais informao sobre o modelo de
verses 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 converso retrospectiva:
Para o mapeamento dos tipos DRIVER a partir das Directrizes DRIVER 1.0
ver Mapeamento de tipos DRIVER.
No Format
confundir
com O elemento DC type descreve o tipo de produo acadmica do qual o
recurso uma representao. O elemento DC format descreve o tipo
de meio do recurso.
Esquemas Tipos de publicao: ver a seco Vocabulrio tipo de publicaes na
pgina 121 no captulo Uso de vocabulrios e semnticas.
Vocabulrio de verses: ver a seco Vocabulrio de verses na pgina

126 no captulo Uso de vocabulrios e semnticas.
Mapeamento: ver a seco Mapeamento de tipos DRIVER na pgina 87 no

captulo Uso das prticas 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
Definio Manifestao fsica ou digital do recurso. Normalmente, o elemento
DCMI Format pode incluir o tipo de meio ou as dimenses do recurso. O
elemento Format pode utilizar-se para determinar o software, o
hardware ou outro equipamento necessrio para mostrar ou operar o
recurso. Exemplos de dimenses so o tamanho e a durao. A prtica
recomendada seleccionar um valor de um vocabulrio controlado (por
exemplo, a lista de tipos de meios da Internet [MIME] que define os
formatos para os equipamentos informticos).
Uso Recomendado
Instrues Baseado em prticas recomendas, utiliza-se a lista registada da IANA de
de uso tipos de meios da Internet (tipos MIME) para seleccionar uma designao.
Para a lista completa ver o esquema de localizao 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 especfico (uma instncia de um documento cientfico) tem
mais de um formato fsico (por exemplo, postscript e pdf) armazenados
como ficheiros de objecto distintos, todos os formatos devero 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>
No Type
confundir Identifier
com
O elemento DC format descreve o tipo de meio do recurso. O elemento
DC type descreve o tipo de resultado/publicao cientfica do qual o
recurso uma manifestao. O elemento DC identifier e utilizado para
representar manifestaes 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
Definio Referncia inequvoca do recurso num contexto determinado.
DCMI
Uso Obrigatrio
Instrues Recomenda-se a identificao do recurso mediante uma sequncia ou
de uso nmero de acordo com um sistema de identificao formal. Alguns
exemplos de sistemas de identificao 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 utilizao de uma hiperligao

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

recurso digital ou uma pgina de transio (jump-off-page).
Prtica recomendada:
# utilizar URL's estveis
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 servios para permitir
que um utilizador final o cite. Pode ser uma hiperligao para uma
pgina de transio (jump-off-page) ou um link directo para o ficheiro.
Tambm pode ser um URL directo, ou um URL de redireccionamento,
como PURL, HANDLE ou outros mecanismos internacionais de
resoluo.
No dc:relation (Utilizar dc:relation para relacionar uma verso do
confundir recurso com outra.)
com dc:source (Utilizar dc:source para citao bibliogrfica do recurso
de origem.)
Exemplos Neste exemplo, os identificadores so ordenados e os URL's so
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
pgina de transio (jump-off-page). A pgina de transio uma boa
forma de citar. O utilizador final tem a oportunidade de ver mais
informaes sobre o(s) objecto(s) que encontrou, ver o contexto e
desfrutar de outros servios que um repositrio 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
Definio Referncia a um recurso do qual deriva o recurso actual.
DCMI
Uso Opcional
Instrues O recurso actual pode derivar total ou parcialmente do recurso fonte
de uso (Source). A prtica recomendada consiste em referenciar o recurso
atravs de uma sequncia ou um nmero em conformidade com um
sistema de identificao formal.
Prtica recomendada: Utilizar apenas se o recurso descrito for resultado

da digitalizao de originais no digitais. Caso contrrio, utilizar o
elemento Relation. Opcionalmente, podem-se adicionar metadados
sobre a localizao actual e nmero de registo da publicao
digitalizada.
Utilizar: Guidelines for Encoding Bibliographic Citation Information in

Dublin Core Metadata ([http://dublincore.org/documents/dc-citation-
guidelines/]).
No 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
Definio Idioma do contedo intelectual do recurso.
DCMI
Uso Recomendado
Instrues Um recurso especfico (uma instncia de um resultado/publicao
de uso cientfica) escrito num ou vrios idiomas humanos. Nestes casos, todos
os idiomas utilizados so descritos no elemento DC language. Se um
recurso especfico (uma instncia de um resultado/publicao cientfica)
est escrito numa linguagem humana e traduzido para outros idiomas
legveis, as tradues diferenciam-se da verso original e por conseguinte
so descritas separadamente.
Recomendado: ISO 639-x, onde x pode ser 1,2 ou 3.
Prtica 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 necessrio, repetir este elemento para indicar diferentes idiomas.
Se ISO 639-2 e 639-1 forem suficientes para os contedos de um

repositrio podem ser usadas alternadamente. Uma vez que existe um
nico mapeamento isto pode ser efectuado durante um processo de
agregao.
No Cdigo de pases 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 (Relao)
Nome do Relation
elemento
Definio Referncia a um recurso relacionado.
DCMI
Uso Opcional
Instrues A prtica recomendada consiste em relacionar o recurso atravs de uma
de uso sequncia ou um nmero em conformidade com um sistema de
identificao formal. O elemento DC relation pode ser utilizado para
indicar distintos tipos de relaes entre vrios registos de metadados. Se
as relaes entre os registos de metadados se tornam visveis atravs do
uso de metadados o seguinte serve para a distino entre verses (verso
do autor e verso da editor, preprint, postprint, etc.):
Um registo de metadados contm-se em si mesmo

Diferentes manifestaes do mesmo recurso (uma instncia de um
resultado/publicao cientifica que pode descrever-se
exactamente com os mesmos metadados bibliogrficos, excepto
no elemento DC format) so ligadas a um nico registo de
metadados utilizando dc:relation.
Outras alteraes nos metadados para alm do elemento DC format

implicam a criao de um novo registo de metadados para esta nova
instncia do resultado/publicao cientfica, que cumpre todos requisitos
formulados neste documento e tem um valor no elemento DC relation.
No 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
Definio Extenso ou mbito do contedo do recurso. Normalmente, a cobertura
DCMI inclui a localizao espacial (nome do lugar ou coordenadas geogrficas),
um perodo temporal (etiqueta de perodo, data ou intervalo de datas) ou
a jurisdio (por exemplo, o nome de uma entidade administrativa).
Uso Opcional
Instrues A prtica recomendada consiste na seleco do valor de um vocabulrio
de uso controlado (por exemplo, o Getty Thesaurus of Geographic Names ou
TGN) e quando for apropriado, utilizar preferencialmente nomes de
locais ou perodos de tempo em vez de identificadores numricos, como
por exemplo, conjuntos de coordenadas ou intervalos de datas. Se
necessrio, repetir este elemento para inserir mltiplas localizaes ou
perodos.
No
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 provisria e encontra-se

actualmente em processo de reviso como parte do trabalho da DCMI
para produzir recomendaes sintcticas de coordenadas para HTML,
XML, e RDF. Estas recomendaes e alteraes editoriais mnimas sero
repercutidas neste documento futuramente. Apontar
http://dublincore.org/documents/dcmi-point/
Rights (Direitos)
Nome do Rights
elemento
Definio Informao sobre os direitos no recurso e sobre o recurso.
DCMI
Uso Recomendado
Instrues Normalmente, o elemento Rights conter uma declarao dos direitos
de uso para aceder ou utilizar o objecto ou uma referncia a um servio que
proporcione essa informao. A informao de direitos abrange,
frequentemente, direitos de propriedade intelectual, copyright e outros
83/144 estado: final 2008-11-13

direitos de propriedade.
prefervel referir-se a um servio de direitos onde os direitos de

reutilizao so claros para o utilizador final utilizando um URL. Por
exemplo, a organizao Creative Commons criou URIs para as suas
diversas licenas nas diferentes jurisdies. Isto pode ser aplicado para
criar licenas para leitura automtica por computador.
No
confundir
com
Exemplos <dc:rights>(c) University of Bath, 2003</dc:rights>
<dc:rights>(c) Andrew Smith, 2003</dc:rights>
O uso de licenas Creative Commons torna o uso de direitos de utilizao

muito mais claros para o utilizador final. Para mais informao ver Use of
Intellectual Property Rights. Neste caso, Andrew Smith, utilizando a
licena: 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 localizao onde a licena pode ser lida. Com
licenas Creative Commons o tipo de licena pode ser reconhecido na
prpria denominao do URL. A vantagem de possuir uma licena que
aponte para um URL desta forma, a de ser usada automaticamente por
computador.


<dc:rights>cc-by-sa, Andrew Smith</dc:rights>
A sequncia cc-by-sa fornece o tipo de licena 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>
Tambm um DAI (Digital Author Identifier) ou ISNI (International Standard
84/144 estado: final 2008-11-13

Name Identifier) podem ser utilizados a nvel mundial para identificar
pessoas e organizaes e relacionar estes nomes com os direitos
apropriados.
Audience (Pblico)
Nome do Audience
elemento
Definio Um tipo de entidade para a qual o recurso dirigido ou til.
DCMI
Uso Opcional
Instrues 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, so apresentados exemplos de pblicos:
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
No
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 prticas recomendadas para OAI_DC
Uso das prticas recomendadas com

OAI_DC
Este captulo aborda problemas comuns com que os administradores de repositrios se
deparam no processo de instalao de um repositrio. Estas prticas no so
obrigatrias, mas constituem a melhor soluo possvel para problemas comuns. Estas
solues provm de boas prticas de outros administradores repositrio que j lidaram
com estes tipos de problemas anteriormente. O principal foco aqui a
interoperabilidade e facilidade de implementao em termos do ciclo de vida do
processo de comunicao cientfica.
Mapeamento de tipos DRIVER
Mapeamento de listagens de outros tipos de Publicao com o que apresentado na

seco Vocabulrio tipo de publicaes na pgina 121 no captulo Uso de
vocabulrios e semnticas. Nessa seco pode-se encontrar definies detalhadas dos
termos utilizados nesses vocabulrios 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

verso 1.1 da Directrizes DRIVER comparados com os tipos da verso 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 vocabulrio de tipos E-Print para tipos DRIVER v2.0
Apresenta-se em seguida o mapeamento entre os tipos de documentos utilizados no

vocabulrio e-print comparados com os da verso 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
publicao, um segundo a verso publicada?
Vocabulrio de tipos e-print mapeado Tipos DRIVER v2.0 Verses

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 vocabulrio >> lecture
de tipos e-print!
WorkingPaper >> workingPaper
ScholarlyText >> other ??? (demasiado
genrico)
Report (sentido lato) >> report
inexistente no vocabulrio >> annotation
de tipos e-print!
NewsItem >> contributionToPeriodical
Patent >> patent
inexistente no vocabulrio >> other
de tipos e-print!
89/144 estado: final 2008-11-13

Mais informao sobre o vocabulrio de tipos e-print pode ser encontrada em:
http://purl.org/eprint/type/
Mapeamento de verses DRIVER
Em seguida apresenta-se o mapeamento do esquema de verses DRIVER

comparativamente com outras verses de esquemas da comunidade mundial de
bibliotecas e repositrios. Mais informao sobre verses DRIVER na seco
Vocabulrio de verses na pgina 126 no captulo Uso de vocabulrios e
semnticas.
Mapeamento de tipos de verses Eprints para tipos de verso

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

utilizados no Eprints comparados com os da verso 2.0 das Directrizes DRIVER.
Verses e-print mapeado para Verses 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 verses para tipos de verses DRIVER

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

termos cientficos comuns comparados com os da verso 2.0 das Directrizes DRIVER.
90/144 estado: final 2008-11-13

Verses tradicionais mapeado para Verses Directrizes DRIVER v2.0
Working paper >> draft
Pre print >> submittedVersion
Post print >> acceptedVersion
Journal article >> publishedVersion
Reprint >> updatedVersion
Mapeamento dos tipos de verses do grupo de trabalho tcnico

Journal Article Versions (JAV) para os tipos de verses das
Directrizes DRIVER v2.0
Estas recomendaes proporcionam uma forma simples e prtica de descrever as

verses dos artigos cientficos de revistas que tipicamente aparecem online antes,
durante e aps a publicao formal em revistas. Os termos recomendados e definies
para verses de artigos de revista (JAV) em sete etapas.
JAV mapeado para Verses Directrrizes DRIVER v2.0

Authors 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 informao 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 recomendao baseada no relatrio do estudo: "A PORTAL FOR DOCTORAL E-

THESES IN EUROPE; Lessons Learned from a Demonstrator Project"
Este estudo visa servios genricos de comunicao cientfica que recolham OAI_DC.
No contexto especfico de servios e-teses recomendamos a utilizao de outros
esquemas de metadados, para alm do OAI_DC onde todos os aspectos relativos a e-
teses sejam proporcionados.
A prtica comum quando se utiliza o OAI_DC dc:type com o contedo "info:eu-

repo/semantics/doctoralThesis", a de que deve tomar particular ateno ao
seguinte:
O campo dc:date field deve conter sempre a data de publicao (no a data
de defesa. A data de defesa significativa em contextos especficos de servios
de e-teses)
Utilizar apenas um campo data. Mais campos de data sero considerados
ambguos, porque o DC no comporta a especificao 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 no comporta a especificao de outros perfis de contributor.)
Os restantes campos devero seguir exactamente as Directrizes DRIVER. Ter em
ateno que o campo dc:language dever estar preferencialmente codificado em
iso639-3. Notar por favor que campo dc:identifier o nico que contm um
URL que aponta para um documento com o texto integral de uma tese ou uma
pgina intermdia 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 so formatados seguindo o estilo
"apelido, nome".
92/144 estado: final 2008-11-13

Exemplo
Nesta seco apresentado um exemplo para uma tese electrnica. Neste caso uma
"Habilitation" um tipo de tese alem que usada quando uma pessoa se torna
Professor. Este um trabalho acadmico que considerado ainda mais do que uma
Tese de Doutoramento na Alemanha. Nas Directrizes DRIVER apenas suportamos os
termos utilizados na conveno de Bolonha, para que o gestor de repositrio possa
usar a regra "tudo igual e superior a uma Tese de doutoramento ser colocado na
categoria doctoralThesis". Nas Directrizes DRIVER permitido colocar a informao
adicional "habilitation", com o intuito de manter particularidades locais.
Para mais informao sobre os termos do nvel de diploma ver:

http://en.wikipedia.org/wiki/Diplom
O XML que usado pode assemelhar-se ao seguinte (os comentrios entre 
no 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 informao de citao
Nas publicaes utilizar o campo DC:SOURCE para inserir informao que uma pessoa
possa utilizar para efectuar uma citao do registo que encontrou. Utilizar
preferencialmente o estilo APA para elaborar referncias.
Por exemplo
<dc:source>Ecology Letters (1461023X), vol.4 (2001)</dc:source>
DC:RELATION e hiperligao de objectos

relacionados
O campo DC:RELATION pode ser usado tipicamente para descrever relaes para
outras expresses ou verses do documento.
Por exemplo a verso publicada de um artigo e a verso de autor de um artigo. Estas

podem ser referenciadas mutuamente atravs da utilizao do identificador "mais
apropriado que accionvel (URL). Por exemplo:
Este registo com ID 1111, um trabalho que foi submetido para reviso
cientfica. Este trabalho possui uma relao com o artigo com reviso
cientfica 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 relao 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
Introduo e Objectivo
Este documento um anexo ao documento de especificao DIDL existente para

repositrios 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 inequvoca atravs da descrio da:
1. A natureza das diferentes partes de metadados, objectos e pginas de

transio
2. O que identificao
3. O que data de modificao
Quando usada correctamente, esta especificao ir criar um registo XML MPEG-21

DIDL vlido para uso com respostas OAI-PMH. Esta especificao de documento DIDL
para repositrios baseada em decises propostas inicialmente durante o
desenvolvimento deste formato XML para utilizar MPEG-21 DIDL. A proposta constituiu
um esboo de um formato de empacotamento (wrapper) com espao para recursos de
96/144 estado: final 2008-11-13

metadados, objectos e pginas de transio. Esta especificao um trabalho de maior
preciso.
Contextualizao
O DIDL foi originalmente desenvolvido no mbito do programa DARE promovido pelo

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

PMH para transportar recursos digitais (PDFs etc.) desde repositrios locais
para a Biblioteca Nacional para introduzir os recursos num sistema de depsito
electrnico para a sua preservao a longo prazo
Uma soluo para recolha de recursos mediante o protocolo OAI-PMH para
transportar recursos digitais (PDFs etc.) desde repositrios locais para
fornecedores de servios (ex. um portal de pesquisa que indexe documentos de
texto integral)
Uma soluo (parcial) para representar documentos complexos. Numa primeira
fase focada em teses que possuam vrios ficheiros de recursos digitais
Uma soluo para evitar a utilizao confusa do elemento dc:identifier no
caso de uma hiperligao a uma pgina de transio (jump-off-page (JOP)).
Muitos repositrios colocam uma hiperligao para uma pgina de transio no
elemento dc:identifier ao invs de inserir uma hiperligao directa ao ficheiro
do recurso digital.
O DIDL est em uso no DARE desde o vero de 2006. Um dos resultados que contedo
de todos os repositrios holandeses faz agora parte do E-Depot da Koninklijke
Bibliotheek, Biblioteca Nacional dos Pases 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 repositrio 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>
Observaes:
1. No esquecer a etiqueta DIDL na resposta OAI-PMH.
98/144 estado: final 2008-11-13

2. Produza uma declarao dos espaos de nome (namespaces) didl, dii, dip e
dcterms aqui, na etiqueta DIDL. Estes espaos de nome so necessrios ao
longo de todo o documento DIDL. No crie estes espaos de nome na etiqueta
<OAI-PMH>, porque a razo de ser de um documento DIDL a possibilidade de
existir fora do contexto do protocolo OAI-PMH como uma entidade autnoma.
3. O elemento about opcional no protocolo OAI-PMH
DIDL como invlucro ou empacotador (wrapper)
O DIDL XML container, conforme definido no DRIVER, um documento com um

elemento Item ao nvel superior. O Item contm vrios elementos Item derivados.
Estes elementos derivados aparecem em trs tipos distintos. Em seguida, entre
parnteses 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 identificao
O elemento raiz DIDL contm um attribute; nomeadamente DIDLDocumentID. Este

attribute disponibiliza informao sobre o identificador do invlucro (wrapper) DIDL
como uma entidade autnoma. Este identificador NO serve para identificar o trabalho
intelectual, mas para identificar a serializao do DIDL XML.
<didl:DIDL
DIDLDocumentId="urn:nbn:nl:ui:10-15290" 
...
>
99/144 estado: final 2008-11-13

...
</didl:DIDL>
O atributo DIDLDocumentId contm o ID do invlucro (wrapper) DIDL. PODE coincidir

com o identificador OAI que se utiliza para obter um registo. O invlucro DIDL pode-se
utilizar como entidade autnoma fora do contexto OAI-PMH, porque um DIDL no o
mesmo que um registo OAI. Futuramente, existe necessidade de identificadores
persistentes para objectos digitais (Obrigatrio 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 nmero da base de dados. Recomenda-se o
armazenamento deste nmero num campo individual e no auto-ger-lo a partir do
identificador (id) da base de dados, uma vez que uma actualizao futura da base de
dados alterar estes nmeros e a persistncia pode ser perdida.
Observaes:
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 autnoma que pode existir fora de
um registo OAI de forma independente. No obstante, para facilitar a
implementao 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 trs elementos

Descriptor. Um elemento Descriptor descreve a data de modificao do elemento
Item. Para comparar elementos Item similares recolhidos na data de modificao,
deve-se adicionar um identificador.
Exemplo no nvel 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 nvel 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>
Declarao Descriptor: Item 'Identifier'
O primeiro elemento Descriptor contm 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>
Observaes:
1. No caso de elementos Item derivados do elemento Item raiz indica que este
elemento Identifier NO 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 no seja recomendado
3. O espao de nomes (namespace) para dii deve ser declarado na etiqueta DIDL.
4. O identificador DEVE ESTAR descrito, quando aplicvel, como um URI.
Declarao Descriptor: Item 'modified'
O segundo Descriptor contm uma data de modificao. Quando algo muda dentro de
um elemento Item, este elemento data de modificao deve ser actualizado. Esta data
de modificao especifica-se mediante o elemento modified do espao 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>
Observaes:
1. Declarar o espao 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.
Declarao Descriptor: Item ObjectType
O terceiro descriptor contm o tipo de objecto. Este tipo de objecto aparece no

seguindo nvel dos elementos Item. Noutras palavras: apenas se aplica em elementos
Item derivados do primeiro elemento Item. Este tipo de objecto especifica-se atravs
do elemento ObjectType do espao de nomes de MPEG-21 Digital Item Processing (DIP)
que descreve uma arquitectura pertencente disseminao 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 seco Elemento composto: representao do trabalho complexo a
representao do trabalho complexo desta declarao tipo de objecto (ObjectType
statement) ser mais elaborada.
Observaes:
1. Declarar o espao de nomes dip na etiqueta DIDL.

2. O elemento ObjectType na declarao Descriptor DEVE ESTAR descrito como
um URI.
3. A arquitectura de processamento que se utiliza para a disseminao aplicar-se-
aos repositrios gerais europeus. O URI est localizado no info namespace
como info:eu-repo (http://info-uri.info/). Entretanto, utiliza-se como um
padro no oficial no seio da comunidade DRIVER.
Elemento composto: representao do trabalho complexo
O elemento Item de topo contm pelo menos dois tipos de objectos (ObjectTypes)
obrigatrios do elemento Item. Estes tipos de objectos do Item so expresses 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 pgina de transio (jump-off-
page). Uma pgina de transio uma pgina HTML intermdia que se utiliza para
apresentaes legveis para o ser humano quando um Item contm mais de um ficheiro
digital. Normalmente, esta situao ocorre com dissertaes com ficheiros
independentes (ex. quando a tese consiste num agrupamento de artigos previamente
publicados). Tambm ocorre quando o fornecedor de contedo tem uma verso 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 contm os metadados como Dublin Core (DC) (obrigatrio)
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 contm uma ou mais ligaes para os objectos digitais e o terceiro Item
contm uma hiperligao para uma pgina de transio.
<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 URIs sero processados sem ter em conta o uso de maisculas. Recomenda-se o uso
da escrita camelCase (maiusculasInterioresSemEspaos). MUITO importante utilizar
exactamente a mesma combinao de caracteres, caso contrrio, no ser possvel
realizar o processamento automtico. Para conseguir a mxima clareza, utilizam-se os
seguintes URIs:
info:eu-repo/semantics/descriptiveMetadata
(Este Item ocorre 1 ou vrias vezes)
info:eu-repo/semantics/objectFile
(Este Item ocorre 1 ou vrias vezes)
info:eu-repo/semantics/humanStartPage
(Este Item ocorre 0 ou 1 time)
Observaes:
O espao de nomes (namespace) info:eu-repo utilizado com a seguinte

sintaxe:
info:eu-repo/_type_/_identifier_
Para mais informao ver
http://info-uri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg&identifier=info:eu-repo/
A semntica dos tipos de objecto (ObjectTypes) implica, por exemplo, que este
Item indique que o primeiro sub-Item tem ou contm metadados descritivos.
Tipo de objecto (objectType): Item de metadados
O primeiro elemento Item ObjectType contm os metadados. Os metadados so

introduzidos num elemento Resource. Cada elemento Resource contm o espao de
nomes (namespace) de um formato de metatados que foi utilizado. Deste modo o
formato ser reconhecido por fornecedores de servio. De acordo com o protocolo OAI
obrigatrio utilizar 'oai_dc'. Para simplificar a implementao pode-se usar OAI_DC
como metadados, uma vez que OAI_DC um requerimento bsico do OAI-PMH. Cada
item de metadados pode, opcionalmente, ter o seu prprio 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

Observaes:
1. (Obrigatrio quando aplicvel) Recomenda-se a identificao de cada

componente separado, para futura referncia ou propsito de reconstruo.
Este conjunto de metadados possui o seu prprio identificador, que NO o
mesmo do identificador DIDL.
2. Se a data dos metadados foi alterada, assegure-se que a data de modificao do
Item raiz tambm modificada.
3. Declarar o espao de nomes (namespace) dc na etiqueta de incio do elemento
Resource no qual se utiliza se utiliza Dublin Core.
Tipo objecto (objectType): Item objecto
O segundo Item ObjectType contm uma hiperligao para um objecto digital. Isto
sempre by-reference para limitar o tamanho do ficheiro, quando usada para
propsitos de transferncia de metadados. (by-value possvel mas aumenta o
tamanho do ficheiro e toca no assunto da propriedade, usar codificao base64, no
exemplificada aqui), e o elemento Item possui uma declarao 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 localizaes do elemento Resource

no aparecem em vrios componentes dentro de um Item, mas cada localizao do
Resource introduzida num elemento Item. Isto deve-se ao facto de cada bitstream
do ficheiro poder ter o seu prprio identificador. Nos trs pontos ... (dado nos
exemplos), pode-se incluir nas etiquetas Identifier e modified, o que similar ao
elemento Item dos metadados.
Observaes:
1. A ordem dos componentes do objecto deve seguir uma ordem lgica de leitura!
O Item com o captulo 1 deve ser seguido do elemento imediato que contm o
captulo 2, etc... Deste modo, o fornecedor de servios poder realizar uma
109/144 estado: final 2008-11-13

melhor apresentao. Na prxima verso da especificao ser definido como
tornar explcita a ordem mediante a incluso de nmeros de sequncia.
2. Se existem datas de modificao importantes no elemento Resource, propagar
estas modificaes 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 no existir nenhum identificador para os elementos Item do tipo de objecto
(ObjectType), o fornecedor de servios utilizar o identificador do elemento
DIDL.
5. Utilizar para um elemento modified ou Identifier uma estrutura separada
<Descriptor> <Statement> para a construo de elementos.
6. A regra geral a de que se um bitstream ou um ficheiro dispe do seu prprio
identificador, o invlucro (wrapper) ser um elemento Item. Para no eliminar
a possibilidade de um bitstream conter um Identificador, utilizamos o elemento
Item como invlucro predefinido da localizao do recurso.
Tipo de objecto (objectType): Pgina de transio (Jump-off-page

Item)
O terceiro elemento ObjectType Item contm uma hiperligao para uma pgina de
transio. Isto realizado da mesma forma que para o elemento Object Item.
Actualmente, isto est restringido a 1 Item deste tipo; no 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 vocabulrios e semnticas
Uso de vocabulrios e semnticas
info:eu-repo Um espao de nomes para URI-fying

esquemas e identificadores un-URIfied
O espao de nomes (namespace) info:eu-repo est registado em http://info-uri.info
Este espao de nomes uma marca de autoridade para termos semnticos,

vocabulrios controlados e identificadores.
Utilizando este espao de nomes todos os termos utilizados possuem uma "presena
Web". Nesse sentido j no uma sequncia arbitrria, pois comporta significado. Esta
utilizao torna-o vlido para o futuro.
Identificao de autor
(esta informao citada e modificada do projecto europeu NEEO16)
16
Network of European Economists Online (NEEO): informaes do projecto em
http://www.nereus4economics.info/neeo.html. Para informao sobre DAI ver especificaes:
http://homepages.ulb.ac.be/~bpauwels/NEEO/WP5/WP5%20Technical%20guidelines.pdf
117/144 estado: final 2008-11-13

Construir listas dinmicas de publicaes por autor requer que estes autores sejam
identificados inequivocamente. A melhor forma para fazer isto atravs da atribuio
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 atribudo aos autores a nvel nacional (como nos Pases Baixos, onde
cada autor recebe um identificador nico no sistema METIS), ou a um nvel
institucional. da exclusiva responsabilidade de cada RI garantir que um autor pode
ser identificado atravs de um DAI e que cada DAI atribudo nico num Repositrio
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 Agncia de Registo possa ser reconhecida no
esquema. No entanto, recomenda-se a utilizao do nmero International Standard for
Name Identification (ISNI)17. Todos DAI's devem ser globalmente nicos. Isto
alcanado atravs da combinao 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 codificaes vlidas de um DAI:
info:eu-repo/dai/nl/12456454
http://staff.university.eu/19262
urn:isni:1234567-2
Persistncia de um DAI
Os DAI's devem ser identificadores persistentes: uma mudana do DAI de um autor

poder contribuir para obteno de um resultado incoerente pelos fornecedores de
servios em todo o mundo e as listas de publicao podem tambm tornar-se
incompletas. Por exemplo, parte de uma lista de publicaes seria atribuda ao DAI X,
17
(ISNI): norma em desenvolvimento, nenhuma Agncia de Registo implementada at ao
momento. O projecto termina em 2009. Os nmeros DAI nos Pases Baixos so compatveis 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 DAIs reportando-se ao mesmo autor. Estatsticas
de downloads de publicaes por autor iriam tornar-se tambm incorrectas. Se uma
instituio 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 servios e
servidores de ligaes (link resolvers) escala global, a fim de, por exemplo, obter
listas de publicaes correctas novamente. Os erros nas estatsticas de utilizao dos
servios seriam provavelmente irrecuperveis. O conselho o de que os DAIs
claramente no devem mudar, uma vez atribudos aos autores.
Classificao de assuntos
Os metadados entregues via OAI-PMH, contm uma ampla gama de cabealhos de

assuntos e informao de classificao. A classificao utilizada e sistemas de
cabealhos de assuntos, bem como a apresentao dos formatos variam amplamente.
Na maioria dos casos, esta informao aparece em formato dc simples no elemento
assunto (subject). A informao de classificao num repositrio frequentemente
utilizada para agrupar items por reas disciplinares. Por conseguinte, tais informaes
aparecem frequentemente no elemento OAI setSpec. Os repositrios EPrints
(classificao LOC) e repositrios certificados DINI (DDC) so exemplos desta
abordagem.
Os esquemas de classificao utilizados no contexto OAI so
Library of Congress Classification18

Dewey Decimal Classification (DDC)19
Universal Decimal Classification20
Sistemas de cabealhos de assuntos usados frequentemente no contexto OAI so:
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)
Alm disto, metadados OAI contm cdigos de classificao de reas disciplinares a

partir de esquemas como Mathematics Subject Classification (MSC) e do Medical
Subject Headings (MeSH), mas tambm diferentes de informaes de classificao
local.
Actualmente, os servios baseados nestas informaes possuem srios problemas para

extrair as informaes a partir dos dados entregues de forma apropriada. O primeiro
passo para melhorar a situao dever focar-se em tornar a tcnica utilizada e o
esquema de classificao transparente para o fornecedor de servios.
O DRIVER recomenda que o repositrio transporte as informaes relacionadas ao uso

de classificao e cabealhos de assuntos no elemento descrio (description) da
resposta Identify. Quando uma classificao utilizada para a estruturao do
repositrio atravs de conjuntos, a parte da classificao deve ser repetida no
elemento assunto.
A prtica recomendada transportar a classificao no elemento assunto "URI-field"

utilizando um espao de nome de autoridade, com o fim de apoiar o reconhecimento
do esquema de classificao. Com base nesta informao os fornecedores de servios
podem utiliz-lo para a implementao de servios como a navegao por
classificao. Isto inclui a substituio de cdigos de classificao por termos em
ingls, traduo de termos para outros idiomas e fazer uma juno dos cdigos de
classificao utilizando regras de mapeamento.
Recomenda-se a utilizao de um URI quando se utilizar esquemas de classificao ou

vocabulrios controlados, especialmente quando so utilizados esquemas codificados
DDC ou UDC. Os fornecedores de servios podem reconhecer esquemas codificao
mais facilmente quando o esquema "URI-fied" por um espao de nomes de
autoridade. Quando o esquema de classificao codificado, utilizar um texto de
leitura humana do cdigo, de preferncia em Ingls, directamente por baixo do
elemento codificado. Por exemplo:
120/144 estado: final 2008-11-13

Se nenhum sistema de classificao especfico utilizado recomendamos o Dewey

Decimal Classification (DDC). Os primeiros 1000 termos so designados sumrio Dewey
Decimal Classification Sntese e podem ser descarregados em
http://www.oclc.org/dewey/resources/summaries/ se concordar com os seguintes
termos e condies: http://www.oclc.org/research/researchworks/ddc/terms.htm
Vocabulrio tipo de publicaes
O vocabulrio dos tipos de publicaes listados em baixo tem uma histria bastante
enraizada na comunidade de repositrios europeia. uma combinao dos tipos de
utilizados pelo DARE das directrizes DC, dos tipos enumerados no certificado DINI e dos
tipos de publicaes e-Prints21. Com base na autoridade destas directrizes, foram
produzidas directrizes melhoradas para o DRIVER "Uso do MODS para repositrios
institucionais22, que est em consonncia com os tipos de publicao utilizados
usualmente pelos Current Research Information Systems (CRIS) como o METIS. Esse
documento foi a base para os tipos de publicao apresentados em baixo.
Os tipos de publicao listados em baixo tm uma forte incidncia na

interoperabilidade europeia entre os repositrios para propsito de troca apenas. Os
tipos de publicao so utilizados para fechar a lacuna semntica, criando uma base
comum e fornecendo um significado para os diferentes tipos. Os termos e descries
so escolhidas de forma a abranger os tipos usados na comunicao cientfica,
suficientemente diversificados para distinguir entre os diferentes itens utilizados na
comunicao cientfica, suficientemente genricos para comportarem um
21
Vocabulrio do perfil de aplicao 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 repositrio e no muito especficos
que s se apliquem a uma comunidade.
Observao: Os tipos de publicaes em baixo so desenvolvidos para a troca de

metadados com os fornecedores de servios que visem a comunicao cientfica em
geral e no so destinados para uso interno de repositrios. Uma publicao interna
local dever ser passvel de mapeamento com os tipos listados em baixo. As descries
so cuidadosamente construdas com a ajuda de especialistas de metadados e
administradores de repositrios. Estas descries iro ajudar no processo de
mapeamento do repositrio local.
Para os tipos publicao usado um espao de nome especial para que seres humanos
e mquinas possam reconhecer o vocabulrio que utilizado. Este nome o espao 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 publicao. Por
exemplo, o URI de artigos info:eu repo/semantics/article. A terceira coluna
contm as descries dos tipos de publicaes. Isso dever facilitar as decises de
mapeamento que devem ser feitas nos repositrios locais.
A segunda coluna contm as verses que descrevem o estado do documento. Isto

possibilita a descrio do tipo de publicao, sem misturar os termos com a verso ou
informaes do estado. O termo PeerReviewedArticle separado por exemplo em
info:eu repo/semantics/article e info:eu repo/semantics/accepted.
info:eu-repo/semantics/ Verso permitida Descrio

article aceite / Artigo ou um editorial publicado
publicado / numa revista cientfica
actualizado
bachelorThesis aceite / Dissertao de Licenciatura
publicado / (mestrado integrado). Ver tambm
actualizado http://en.wikipedia.org/wiki/Diplom
masterThesis aceite / Dissertao de mestrado. Nvel
publicado / intermdio de uma dissertao
actualizado (normalmente aps quatro ou cinco
122/144 estado: final 2008-11-13

anos de estudo). Ver tambm
. Este tipo tambm se refere s
dissertaes do perodo pr-Bolonha
para graus acadmicos que agora so
reconhecidos como grau de mestre.
doctoralThesis aceite / Tese de doutoramento. O nvel mais
publicado / elevado de uma tese, normalmente
actualizado depois de mais de quatro ou cinco
anos de estudo. Ver tambm
Tambm, qualquer grau igual ou mais
elevado do que Tese de
doutoramento, que no segue a
Conveno 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 captulo de um livro
publicado /
actualizado
review rascunho / Recenso de livro ou de artigo. No
submetido / confundir com artigo de reviso.
aceite /
publicado /
actualizado
conferenceObject rascunho / Todo o tipo de documentos
submetido / relacionados com uma conferncia,
aceite / ex. artigos de conferncias,
123/144 estado: final 2008-11-13

publicado / relatrios de conferncias, palestras
actualizado em conferncias, artigos publicados
em proceedings de conferncias,
relatrios de abstracts de artigos de
conferncia e posters de
conferncias.
lecture rascunho / Palestra (Lecture) ou apresentao
submetido / realizada durante um evento
aceite / acadmico, ex. uma palestra de
publicado / abertura. Excluem-se palestras em
actualizado conferncias (ver conferenceItem).
workingPaper rascunho / Um documento cientfico ou tcnico
submetido / preliminar que publicado numa
srie da instituio onde a
investigao conduzida. Tambm
conhecido como trabalho de
investigao, memorando de
investigao ou trabalho de reflexo.
A diferena relativamente a um
Preprint que um workingPaper
publicado numa srie institucional.
Exemplos: documentos de trabalho,
trabalhos de investigao,
memorandos de investigao e
trabalhos de reflexo.
preprint rascunho / Tal como um workingPaper este um
submetido / documento cientfico ou tcnico
preliminar, mas que no publicado
numa srie institucional. O
documento destina-se a ser publicado
numa revista cientfica ou como um
captulo num livro. Tambm, artigo
que ainda no foi avaliado e revisto
124/144 estado: final 2008-11-13

(peer-reviewed) e ainda no foi
aceite para publicao por uma
revista cientfica.
report rascunho / Este um type mais ou menos lato e
submetido / compreende relatrios de comisso,
aceite / memorandos, relatrios de
publicado / investigao externos, relatrios
actualizado internos, relatrios estatsticos,
relatrios para agncias de
financiamento, documentao
tcnica, deliverables de projectos,
etc. Excluem-se relatrios de
conferncias (ver conferenceItem).
annotation rascunho / Anotaes a decises jurisprudenciais
submetido /
aceite /
publicado /
actualizado
contributionToPeriodical rascunho / Artigo publicado em jornal, magazine
submetido / semanal ou em outro tipo de
aceite / peridicos no acadmicos
publicado /
actualizado
patent rascunho / Patente
submetido /
aceite /
publicado /
actualizado
other rascunho / Especialmente indicado para dados
submetido / no publicados como: dados
aceite / cientficos, materiais audiovisuais,
publicado / animaes, etc.
actualizado
125/144 estado: final 2008-11-13

Derivado de:
Vocabulrio de tipos e-print http://purl.org/eprint/type/
Exemplos de utilizao com a sequncia 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 sequncia "info:eu-repo" est sempre associada ao termo. Define portanto, a

autoridade do vocabulrio controlado utilizado.
O espao de nomes info:eu-repo est registado em: http://info-uri.info
Mais sobre a utilizao de DC:type com verses ver seco Type (Tipo) na pgina 72
no captulo Uso de metadados OAI_DC.
Vocabulrio de verses
Esta seco sobre as verses que descrevem o estado de um documento.

Introduzimos informaes sobre a verses para tornar possvel a descrio do tipo de
publicao, sem misturar os termos com a verso ou informaes do estado. Por
exemplo, o termo "PeerReviewedArticle" pode ser dividido em info:eu
repo/semantics/article e info:eu repo/semantics/accepted.
O vocabulrio de verses derivado de http://www.lse.ac.uk/library/versions/, que

se trata de um projecto financiado pelo JISC e designado por VERSIONS (Verses do
Eprints - um Estudo e Investigao de Utilizador dos Requisitos das Necessidades de
Normalizao). Este projecto aborda os problemas e as incertezas relativas s verses
de textos cientficos em repositrios digitais. VERSIONS visa ajudar na criao de
confiana do acesso livre aos contedos, 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- Descrio
repo/semantics/
draft A verso inicial colocada em circulao como trabalho em
progresso
submittedVersion A verso que foi submetida a uma revista para reviso
cientfica
acceptedVersion A verso produzida pelo autor que incorpora comentrios de
reviso cientfica e que foi aceite para verso de publicao
publishedVersion A verso produzida pelo Editor e publicada
updatedVersion A verso actualizada desde a publicao
Esquemas de codificao
As Directrizes DRIVER utilizam os seguintes esquemas de codificao:
Nome Campo Esquema

Autor dc:creator Formato bibliogrfico APA conforme uma lista de
referncias. Sintaxe: apelido, nome (primeiro nome)
Colaborador dc:contributor Formato bibliogrfico APA conforme uma lista de
referncias. 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 so
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/]
Territrio dc:coverage ISO 3166 (Pases) [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
Geogrficos [http://www.getty.edu/research/tools/vocabulary/tgn/]
Perodo dc:coverage Perodo DCMI
temporal [http://dublincore.org/documents/2000/07/28/dcmi-
period/]
Informao dc:source Guidelines for Encoding Bibliographic Citation
de citao 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 informao bsica sobre a importncia da

qualidade e interoperabilidade. Etiquetas de qualidade podem ser utilizadas para
assegurar repositrios estveis e fiveis que durem mais tempo e que possuam um
propsito de arquivo de preservao 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 so necessrios para criar uma infra-
estrutura estvel e fivel. Isto no diz respeito a aspectos tcnicos, mas
principalmente acordos a um nvel organizacional.
As Directrizes DRIVER podem fazer algumas recomendaes sobre a implementao

para gestores de repositrios. Isto baseado no Report on Persistent Identifiers of the
PILIN project.
Um plano de implementao 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 numrico de livros comercial nico. A cada edio e variao (excepto a
reimpresso) de um livro atribudo um ISBN. Na era digital, h uma crescente
necessidade de um identificador numrico nico, identificador tambm para
publicaes digitais. Mais ainda, no apenas para as publicaes, 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 ligaes partidas ou mortas que apontam para
pginas da Web que esto permanentemente indisponveis.
Um URL pode mudar ao longo do tempo, devido a migraes de servidor e outras

razes de ordem tcnica. Com consequncias indesejveis para as ligaes e citaes
no seio da comunicao cientfica.
Portanto um "identificador persistente necessrio com um objecto digital ao qual

permanentemente associado. Este nmero de identificao persistente refere-se
sempre ao objecto digital ao qual foi atribudo, independentemente da tecnologia
subjacente de localizao (no momento estes so endereos Web, no futuro, contudo,
a localizao de um objecto pode ser completamente diferente).
Em vrios pases, tem sido desenvolvido um sistema para um destes tipos de

identificador persistente e foram criados servidores nacionais'. Um servidor um
servio de transformao e redireco, que transforma uma sequncia de caracteres
num URL, e alojado por uma organizao nacional. Identificadores comuns no caso
da comunicao cientfica so 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 organizao nacional, frequentemente pela
pela Biblioteca Nacional.
A cada objecto digital atribudo um nmero que representa esse objecto Ad

Eternum. Mesmo que a tecnologia evolua, a organizao nacional ir garantir que os
documentos possam ser lidos. Mas os documentos devem ser recuperveis tambm. O
identificador persistente garante que ele possa ser localizado. Uma infra-estrutura de
informao estvel faz das citaes de investigao muito mais fiveis.
Actualmente, o URN:NBN e os Handle so populares em termos de identificadores

persistentes. Uma vez que o espao de nomes URN:NBN so distribudos de uma forma
controlada, seria de esperar que sejam reconhecido como autoridade assim como o
DOI possui uma reputao.
23
CNRI: http://www.cnri.reston.va.us/
132/144 estado: final 2008-11-13

As diferenas entre identificadores persistentes so descritas por Hans-Werner Hilse e
Jochen Kothe em Implementing Persistent Identifiers24. Existe tambm um artigo
Persistent Identifiers: Considering the Options25 na revista Ariadne, nmero 56, por
Emma Tonkin.
A utilizao de identificadores persistentes comporta a obrigao dos repositrios

sustentarem a persistncia do identificador durante um longo perodo de tempo! Esta
persistncia pode ser garantida nos chamados "repositrios confiveis", com a devida
certificao. Ver captulo Anexo: Uso de etiquetas de qualidade na pgina 130.
para mais informao ver http://www.persistent-identifier.de
e https://www.pilin.net.au/
Os pases escandinavos, a Alemanha, a Repblica Checa e os Pases Baixos usam URN:

NBN. A principal razo da escolha de urns porque se trata de uma norma de Internet
que estar comprovada futuramente. O nico inconveniente que um urn no
accionvel sem utilizar um endereo de um servidor http como um prefixo.
necessrio mais trabalho para integrar URN no sistema DNS26 utilizando registos
NAPTR27 que tambm so utilizados para chamadas VOIP.
Recentemente a Noruega, a Sucia, a Finlndia e os Pases Baixos alcanaram uma

proposta promissora para um servidor global de identificadores persistentes (URN:
NBN). Em cooperao 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
localizao actual do recurso Web. A arquitectura deste processo multi-sistema
descrita em baixo.
Plano de implementao para uso de identificadores persistentes

URN:NBN
Em primeiro lugar, gostaramos de referir que a persistncia de identificadores e

recursos Web no se sustenta na tecnologia que utilizam, mas na organizao e em
modelos de gesto sustentveis. Para obter mais informaes sobre polticas de
identificadores persistentes ver o bem sucedido projecto Persistent Identifier Linking
(PILIN)29 na Austrlia, 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 faa a gesto de todos os

detalhes tcnicos e organizacionais de um projecto dessa natureza. Pensar tambm
sobre a sintaxe que ir ser utilizada. Por exemplo urn:nbn:{country}:{sub-
namespace}:{repositoryid}-{localid}. Country o nome abreviado do pas, sub-
namespace representa recursos Web provenientes de repositrios, repositoryid uma
representao de dois dgitos do repositrio e local id o identificador gerado no
repositrio. Isto pode, por exemplo, resultar na seguinte no seguinte identificador
para uma publicao urn:nbn:ie:ui:21-1234/5678.
2. Formalidades: Uma vez que o espao de nomes urn:nbn:ie por predefinio

reclamado pela Biblioteca Nacional, deve-se acordar com a Biblioteca Nacional a
utilizao de um sub-espao de nomes para produo cientfica. Esse nome deve ser
curto e no possuir nenhum significado semntico. Por exemplo urn:nbn:ie:ui, ou
urn:nbn:ie:oa, ou urn:nbn:ie:sp.
3. Agncia Registo: Criar um registo no qual so atribudos aos repositrios um

nmero curto e aleatrio de dois dgitos. Isto vai criar um sub-espao de nome onde
um repositrio possa distribuir autonomamente identificadores persistentes para as
suas publicaes. Por exemplo, Trinity College Dublin (TCD) registado como 21. O
espao de nomes para o TCD operar ser urn:nbn:ie:ui:21.
4. Implementao a nvel local: Cada repositrio deve gerar identificadores

persistentes para cada publicao no seu espao 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 espaos de nome
seguido por um hfen. No caso de o TCD utilizar Handle, o identificador de uma
publicao pode assemelhar-se ao seguinte urn:nbn:ie:ui:21-1234/5678. No caso de o
TCD utilizar nmeros de base de dados urn:nbn:ie:ui:21-15874. (Certifique-se de
armazenar o identificador e no ger-los on-the-fly. No caso de migrao de base de
dados estes nmeros podem mudar e a persistncia perdida.)
135/144 estado: final 2008-11-13

5. Transporte de identificadores e URLs: Cada repositrio deve gerar um pacote
DIDL onde o URN e URL so includos. Ver a seco MPEG-21 DIDL no relatrio
principal.
6. Servio de Resoluo Nacional: Um servio de resoluo nacional pode ser

implementado atravs da recolha de pacotes DIDL de cada repositrio onde o URL e
URL bindings so extrados e armazenados. Uma localizao Web deve ser criada onde
a mquina ou utilizador possam ir para a resoluo do identificador. Por exemplo
http://resolver.ie onde o utilizador pode inserir um identificador e receber a
localizao 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 intercmbio de estatsticas de utilizao
Anexo: Intercmbio de estatsticas de

utilizao
Esta seco no ser apresentada na distribuio final das Directrizes DRIVER 2.0. A
contribuio para esta seco ser feita a partir das experincias e prticas
recomendadas provenientes de dois projectos europeus que recolhem relatrios
COUNTER a partir de repositrios para apresentar estatsticas a um nvel agregado.
PIRUS: Publisher and Institutional Repository Usage

Statistics
"O objectivo deste projecto desenvolver relatrios de uso Counter-compliant ao nvel

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 utilizao
dos resultados da investigao seja registada, reportada e consolidada a nvel 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 publicaes Open Access desprovida de

qualquer necessidade de autenticao, transaces financeiras ou de identificao
pessoal faz com que seja muito mais fcil para atingir um nvel que satisfao
acolhedor na comunidade cientfica. Esta e hipteses semelhantes podem ser
investigadas atravs de anlises empricas.
1. Que dados necessitam ser recolhidos?

2. Como podem ser transferidos para o fornecedor de estatsticas?
Open-Access-Statistics (OA-S) um projecto conjunto que aborda estas questes. A

partir de Julho de 2008 ser construda uma infra-estrutura para a acumulao
normalizada de dados de registos Web heterogneos com nfase em repositrios
institucionais. Em colaborao estreita com a Network of Open Access Repositories
(OA-N) sero disponibilizados aos utilizadores vrios servios 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 estatsticas OA
O nosso objectivo produzir um documento vlido e fivel de estatsticas de

utilizao, baseado apenas em informaes recolhidas a partir da camada HTTP.
Existem duas questes primordiais abordadas por todas as normas existentes que
geram a maior parte das correces necessrias:
Identificao de acesso no humano

Correco multi-clique
138/144 estado: final 2008-11-13

Alm disto, investigamos a quantidade de dados e o esforo necessrio para produzir
estatsticas complexas, por exemplo, sequncias de cliques, sem violar leis de
privacidade. Na parte final desta seco apresentado um quadro comparativo,
incluindo ligaes para todas as normas mencionadas. Uma descrio pormenorizada
da OA-S pode ser encontrada em: http://www.dini.de/projekte/oa-statistik/#c1203
Estatsticas de utilizao - e ainda mais importante, dados brutos de utilizao -

devem ser descritos de forma abstracta. No suficiente definir um derivado do
Apache Access Log, pois existe uma multiplicidade de diferentes solues de software
em uso para operar com repositrios de texto integral. Muitas nem sequer produzem
um ficheiro de registo sozinho utilizvel num servidor Apache.
Informao necessria para gerar COUNTER, LogEc e IFABC
Nota: Os nomes dos campos podem ainda estar sujeitos a alteraes medida que o
projecto evoluir.
Nomes dos Descrio COUNTER LogEc IFABC|-

campos OA-S
Identificador Etiqueta no- necessrio necessrio necessrio|-
do Documento ambgua a identificar
o texto integral
Formato do Formato do ficheiro necessrio necessrio necessrio|-
ficheiro da resposta do
servidor (ex. HTML
ou PDF)
Tipo Servio Natureza da resposta necessrio necessrio -|-
do servidor (ex.
texto integral,
resumo)
Tempo do Tempo de resposta necessrio necessrio necessrio|-
pedido ao segundo
IP Endereo IP do necessrio necessrio Se o Identificador de
utilizador (Cliente) sesso no est
139/144 estado: final 2008-11-13

disponvel:
necessrio|-
Identificador Etiqueta de opcional - Se o IP no no est
de Sesso Sesso/Visita no- disponvel:
ambgua gerada pelo necessrio|-
servidor
User Agent Sequncia User- necessrio necessrio Se o ID de sesso
Agent do cliente no est disponvel:
requerente necessrio|-
Cdigo de Cdigo de estado do necessrio necessrio necessrio|-
estado HTTP servidor dos pedidos
HTTP
Bytes enviados Tamanho de resposta - - Se o formato de
do servidor ficheiro no HTML:
necessrio
Informao adicional em conformidade com OpenURL Context

Objects
Os seguintes campos so importantes para os nossos interesses de pesquisa avanada e

por isso implementados desde o incio.
Referncia original Identificador no-ambguo do servidor que criou o

(Referrer) ContextObject|-
Entidade de referncia Etiqueta no-ambgua da origem do objecto (ex. a pgina
(Referring Entity) do resumo que liga para o ficheiro de texto integral)
Sugestes adicionais
Declaraes e propriedades do software do repositrio tm de ser entregues a partir

dos dados disponveis.
Exemplos:
Pgina de destaque na vista dos resultados de pesquisa
140/144 estado: final 2008-11-13

ID do documento actual
Procurar argumentos e apresentao do resultado
Pgina resumo vs pgina texto integral
Aces administrativas
Carregamento do documento
Atribuio de metadados
Deve haver informao fivel sobre a origem do cliente (ou seja, a referncia
original). Por exemplo, deveria ser possvel dizer se um cliente acedeu ao ficheiro
atravs da pgina principal ou atravs de uma hiperligao do RSS-Feed do repositrio.
No caso de mltiplos registos de servidor obrigatrio sincronizar a hora do sistema

em todos os servidores associados ao repositrio.
Tabela de padres de utilizao Web
Fonecedor Clusula de Longevidade Identificao Clusula Crawler Identificao Relatrio

URL contagem Multi-Clique User Crawler contagem
Crawler
Counter Code Estado do Para HTML Pelo menos Robots, prefetches, Lista negra, Relatrio
of Practice cdigo HTTP 10s; para PDF IP, de caching, pesquisas cabealho separado
Draft 3 200 ou 304. 30s preferncia federadas (n.e.) client HTTP
Sesso
About LogEc Estado do Um IP Robots, downloads Acessos ao Coluna
cdigo HTTP calendrio automticos (wget) robots.txt; # separada
200, 206, 301, ms de pedidos no
302 ou 304. 10,000 relatrio
itens/ms;
acessos C-
Class 10% do
stock; robot-
Domnio/IP
conhecido
Interoperable Estado do 24 horas IP Motores de pesquisa
Repository cdigo HTTP indexadores
Statistics 200 no (crawlers) +
resumo ou automtico|lista
pgina de negra AWStats'
texto integral |descartado
AWStats Predefinido: Predefinido: 1 IP Motores de pesquisa Lista negra Coluna
Cdigos de hora indexadores separada
141/144 estado: final 2008-11-13

estado http (crawlers) no
{200;304} relatrio
IFABC HTML: Cada IP+User- Motores de pesquisa Lista negra Descartado
Rastreamento Pageview Agent; sesso indexadores proprietria
Pixel; Outro: contada Cookie, (crawlers);
bytes apenas uma sesso downloads
transferidos vez por visita. autenticada automticos
95% do Visita (opcional)
tamanho do significa serie
ficheiro de cliques
provenientes
de um
nmero de
IP/Sesso 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 seco aborda uma temtica importante sobre direitos de utilizao e direitos de
depsito. Na prtica, isto deve ser implementado. As Directrizes DRIVER devem dizer
algo sobre a forma como os direitos de utilizao e direitos de acesso devem ser
expostos e formatados nos metadados.
A base para esta seco ser a Copyright Toolbox desenvolvida pela fundao SURF e
pelo JISC e que reflecte os princpios Zwolle.
Ver: http://copyrighttoolbox.surf.nl/copyrighttoolbox/ para mais informao.
Para mais informao sobre copyright e as licenas 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 licenas 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 cincia, poder disseminar o conhecimento da forma mais livre possvel, sem
perder noo de propriedade, pode-se usar a Licena Creative Commons BY-SA na rea
jurisdicional em causa.
Isto significa:
SA (Partilha nos Termos da Mesma Licena): a utilizao da obra livre,

podendo os utilizadores fazer dela uso comercial ou criar obras derivadas a
partir da obra original.
o Observao 1: todas as partes, comercial ou no, tm de licenciar nos
mesmos termos em que o foi a obra original para produzir trabalhos
derivados. Como resultado: o conhecimento no ser bloqueado.
o Observao 2: contudo, a velocidade de inovao pode ser protelada,
porque algumas partes no querem usar o mesmo modelo de
licenciamento a aquando da produo de trabalhos derivados.
BY (Atribuio): necessrio conceder o devido crdito ao autor original
(assim tambm ter crditos como colaborador).
Se usa o copyright, recomendamos que utilize com uma boa descrio de utilizao.
Por exemplo http://creativecommons.org/licenses/by-sa/3.0/nl/
No Dublin Core no qualificado as licenas so 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 viso tcnica completa ver seco Rights (Direitos) na pgina 83.
Para mais informao ver tambm:
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

Riunila Driver Guidelines v2 Final 2008-11-13 PT PT

Enviado por

Dados do documento

Título original

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

Riunila Driver Guidelines v2 Final 2008-11-13 PT 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 repositrios sobre como expor recursos

Verso portuguesa Servios Documentao da Universidade do Minho (Abril 2009)

Para a comunicao em geral, importante que a pessoa B seja capaz de

Em termos tcnicos, criamos uma base comum promovendo a "interoperabilidade". A

2/144 estado: final 2008-11-13

3/144 estado: final 2008-11-13

Estratgia 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 (verso 1.0)

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

Agradecimentos e Colaboradores (verso 2.0)

Maurice Vanderfeesten, (SURFfoundation, Pases Baixos)

Stefania Biagioni, (CNR, Itlia)

8/144 estado: final 2008-11-13

Patrick Hochstenbach, (Ghent University, Blgica)

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 espao de informao actual do DRIVER

O que esperam os investigadores

Os investigadores e outros actuais utilizadores de sistemas de informao possuem

10/144 estado: final 2008-11-13

cultura actual no panorama dos repositrios digitais no suporta completamente estas

O desafio do texto integral

A recuperao de texto integral com dados bibliogrficos um passo bsico mas

11/144 estado: final 2008-11-13

Sobre as Directrizes DRIVER

Porqu utilizar as Directrizes DRIVER?

O documento, Directrizes para Fornecedores de Contedos: Exposio de Recursos

Como cumprir as Directrizes DRIVER? (validao)

No estar em conformidade com todos os pontos obrigatrios ou recomendados das

12/144 estado: final 2008-11-13

integral no pode processar todo o contedo de um repositrio que oferea

mbito das Directrizes DRIVER

As Directrizes DRIVER so uma norma?

As Directrizes DRIVER equivalem a regras de catalogao?

No. As directrizes so um instrumento para mapear (ou traduzir) os metadados

13/144 estado: final 2008-11-13

As Directrizes DRIVER possuem instrues do nvel de qualidade cientfica?

No. As directrizes no indicam que recursos possuem o nvel de qualidade requerido

Quais so os principais componentes das Directrizes DRIVER?

As Directrizes DRIVER focam basicamente cinco questes: coleces, metadados,

No que respeita s coleces do repositrio, obrigatrio utilizar sets

Quem criou as Directrizes DRIVER?

As Directrizes do DRIVER foram compiladas por profissionais com anos de experincia

14/144 estado: final 2008-11-13

O que se entende por recursos textuais?

Recurso textual: artigos cientficos, teses de doutoramento, documentos de

Muitos repositrios so utilizados para depositar diferentes tipos de recursos, por

15/144 estado: final 2008-11-13

Sets (conjuntos) so um componente normalizado do protocolo OAI-PMH e so

O que mais se deve considerar?

O DRIVER foi concebido seguindo a estrutura de redes operacionais e

16/144 estado: final 2008-11-13