ANEXOS - DRIVER

Digital Repository Infrastructure Vision for European Research 

Directrizes para fornecedores de conteúdos 

Exposição textual de recursos com o 

protocolo OAI-PMH 

Aplicação Piloto 

Versão 1.1.1 

ANEXOS

Anexos – Directrizes sobre “Exposição textual de recursos com o protocolo OAI-PMH” 

Versão 1.1.1 

ÍNDICE DE CONTEÚDOS 

1 ANEXO: DIRECTRIZES ESPECÍFICAS PARA METADADOS DRIVER ........................... 3 

1.1 NOTAS INTRODUTÓRIAS............................................................................................................ 3 

1.2 OS ELEMENTOS: DESCRIÇÃO ABREVIADA ................................................................................. 5 

1.3 OS ELEMENTOS: DESCRIÇÃO COMPLETA ................................................................................... 8 

1.3.1 Title (Título) .............................................................................................................. 8 

1.3.2 Creator (Autor).......................................................................................................... 8 

1.3.3 Subject (Assunto)....................................................................................................... 9 

1.3.4 Description (Descrição) .......................................................................................... 10 

1.3.5 Publisher (Editor).................................................................................................... 11 

1.3.6 Contributor (Colaborador) ..................................................................................... 11 

1.3.7 Date (Data) ............................................................................................................. 12 

1.3.8 Type (Tipo) .............................................................................................................. 13 

1.3.9 Format (Formato) ................................................................................................... 14 

1.3.10 Identifier (identificador) .......................................................................................... 15 

1.3.11 Source (Fonte) ......................................................................................................... 16 

1.3.12 Language (Idioma) .................................................................................................. 16 

1.3.13 Relation (Relação)................................................................................................... 17 

1.3.14 Coverage (Cobertura) ............................................................................................. 18 

1.3.15 Rights (Direitos) ...................................................................................................... 19 

1.3.16 Audience (Público) .................................................................................................. 19 

2 ANEXO: DIRECTRIZES ESPECÍFICAS PARA USO DO PROTOCOLO OAI-PMH ....... 20 

2.1 DEFINIÇÕES E CONCEITOS: ITEM, REGISTO E IDENTIFICADOR ÚNICO ....................................... 20 

2.2 NOMENCLATURA DE PREFIXOS DE METADADOS (METADATAPREFIX NAMING) ...................... 21 

2.2.1 Documento DIDL ......................................................................................................... 22 

2.3 DATA DE REGISTO (DATESTAMP)............................................................................................ 22 

2.4 FORMATO DE DATA DE REGISTO (DATESTAMP) ...................................................................... 22 

2.5 REGISTOS ELIMINADOS ........................................................................................................... 23 

2.6 TEMPO DE VIDA DO TESTEMUNHO DE REATAMENTO (RESUMPTION TOKEN) ............................ 24 

2.7 TAMANHO DO LOTE DE RECOLHA ........................................................................................... 24 

2.8 NOMENCLATURA DE SETS (CONJUNTOS) DO DRIVER ........................................................... 24 

2.8.1 Definições do conteúdo do set DRIVER ....................................................................... 25 

2.8.2 Localização de Sets ...................................................................................................... 26 

2.9 CORREIO ELECTRÓNICO DO ADMINISTRADOR PARA FEEDBACK DE ERROS .......................... 26 

2.10 DECLARAÇÃO DE PREFIXO & ESPAÇO DE NOMES ............................................................... 27 

2.11 VALIDAÇÃO XML ............................................................................................................. 29 

2.12 COMUNICAÇÃO PARA MODIFICAÇÃO NOS REPOSITÓRIOS ................................................... 30 

3 ANEXO: DIRECTRIZES ESPECÍFICAS PARA USO DO MPEG-21 DIDL (XML- 

CONTAINER) ..................................................................................................................................... 31 

3.1 INTRODUÇÃO E OBJECTIVO ..................................................................................................... 31 

3.2 CONTEXTUALIZAÇÃO ............................................................................................................. 31 

3.3 RESPOSTA OAI COM UM DOCUMENTO DIDL .......................................................................... 32 

3.4 DIDL COMO INVÓLUCRO OU EMPACOTADOR (WRAPPER) ....................................................... 32 

3.4.1 Documento DIDL atributo identificação ...................................................................... 33 

3.4.2 Descritores de item (opcional) ..................................................................................... 34 

3.4.2.1 Declaração de Item 'Identifier' (identificador) ......................................................... 35 

3.4.2.2 Declaração de Item 'modified' (modificado) ............................................................ 35 

3.4.2.3 Declaração de Item „ObjectType‟ (tipo de objecto)................................................. 36 

3.4.3 Item composto – representação de trabalho complexo ................................................ 36 

3.4.3.1 Item de metadados ................................................................................................... 38 

3.4.3.2 Item de objecto ........................................................................................................ 39 

3.4.3.3 Item de página de transição (Jump-off-page Item) .................................................. 40 

3.5 EXEMPLO DE UM REGISTO OAI-PMH COMPLETO (THESIS) COMO MPEG-21 DIDL ............... 42 

2


Versão 1.1.1 

História do documento 

Versão Data Distribuição 

1.0 Maio de 2007 DRIVER consortium 

Geneva group 

1.1 Agosto de 2007 IR managers Europe 

Modificações na versão 1.1: para o elemento dc:language ISO 639-1 e 2 são 

substituídas por ISO-639-3. Todas as outras alterações são editoriais e/ou textuais. 

1 Anexo: Directrizes específicas para metadados 

DRIVER 

Agradecimentos Este documento está em grande medida baseado nas 

recomendações para o uso de metadados Dublin Core Simples descritas em: USING 

SIMPLE DUBLIN CORE TO DESCRIBE EPRINTS, de Andy Powell, Michael Day 

e Peter Cliff, UKOLN, University of Bath, versão 1.2 

[ver também: http:/ www.rdn.ac.uk/projects/eprints-uk/docs/simpledc-guidelines/ ] 

Definições: “Um repositório institucional (RI) é um serviço composto por hardware, 

software, dados e procedimentos, que contém recursos digitais que representam 

qualquer tipo de produção científica…” 

“recursos digitais = qualquer sequência de bits, independentemente do seu conteúdo 

ou formato, registado como produção científica por uma pessoa autorizada…” 

Neste documento, utilizaremos a palavra “recurso” para descrever o tipo de produção 

científica e a palavra “objecto” para referir à sequência de bits digital. 

1.1 Notas introdutórias 

Âmbito Estas directrizes foram produzidas principalmente para facilitar a troca de 

metadados entre os fornecedores de conteúdo do DRIVER e os serviços do DRIVER, 

de acordo com as definições do protocolo OAI-PMH tal como distribuído pela 

DCMI. Basicamente estas directrizes descrevem a conversão de um formato interno 

para a norma Unqualified Dublin Core para facilitar a recolha (harvesting). As 

directrizes não devem ser utilizadas como instruções de catalogação. 

3


Padrões mínimos 

Versão 1.1.1 

Os metadados estruturam-se segundo a norma Unqualified Dublin Core (ISO 

15836:2003). 

Os elementos individuais de DC devem ser utilizados de acordo com as 

directrizes tal como apresentadas neste apêndice. 

É obrigatória a utilização de Unicode. 

Os valores (isto é, os conteúdos reais) dos seguintes elementos não devem 

conter linguagem de marcação em HTML (ou XML). Podem conter 

comandos LaTeX, mas não existe um mecanismo explícito para indicar que 

se está a usar LaTeX. 

Recomendações 

Os metadados estão estruturados como Dublin Core Qualified 

O idioma dos metadados fica ao critério dos fornecedores de conteúdos. O 

idioma recomendado é o inglês. 

Apenas os refinamentos introduzidos pela DCMI devem ser utilizados como tal. 

Estes refinamentos também foram adicionados ao texto das directrizes em seguida. 

Quando um fornecedor de conteúdos implementa um elemento ou refinamento (não 

aprovado pela DCMI), é obrigado a eliminar esses elementos dos metadados durante 

o processo de recolha (harvesting). 

Deve utilizar-se apenas um registo de metadados nas diferentes manifestações de um 

objecto digital (ex. uma versão postscript e uma versão pdf), a não ser que o 

conteúdo intelectual das versões seja diferente. A regra geral é a criação de um novo 

registo de metadados quando o conteúdo intelectual é diferente. Isto acontece, por 

exemplo, quando uma nova “edição”, com modificações no conteúdo intelectual, é 

criada. Nesse caso, a boa prática recomendada é o uso do elemento „relation‟ para 

ligar a nova versão à anterior. 

Em alguns casos (como os elementos DC „subject‟ (assunto) e „type‟ (tipo)) facultar 

informação adicional pode revelar-se útil para quem procede à recolha (harvesting) 

e para o fornecedor de serviços. Tipicamente um provedor de serviços faculta este 

tipo de informação através do pedido „Identify‟ – ao nível do RI, não ao nível dos 

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 conhecer práticas recomendadas. 

Informação adicional também pode ser facultada sob a forma de documentação 

textual acerca da utilização dos elementos de metadados subject (assunto) e type 

4


Versão 1.1.1 

(tipo), por exemplo, informação sobre a classificação local ou palavras-chave, ou 

informação sobre as políticas de revisão locais. 

Informação sobre o uso de refinamentos (qualificadores). Quando se realiza a 

conversão para DC não qualificado, o fornecedor de conteúdo tem de fazer escolhas 

quando o formato interno é “mais rico” que o DC não qualificado. Isto significa que 

durante o processo de mapeamento, todos os refinamentos são simplesmente 

descartados (o princípio de simplificação da DCMI). O efeito que se produz com este 

princípio de simplificação é que o formato simples do elemento, isto é sem 

refinamento, é o predefinido. Por exemplo, quando o formato interno distingue entre 

o título principal e o título paralelo, seria apresentado da seguinte forma em DC: 

Formato interno 

245 $aTítulo principal$pTítulo paralelo 

DC qualificado 

Título principal 

Título paralelo 

DC simples 

Título principal, Título paralelo 

Não obstante, no DRIVER os valores seguintes são seleccionados como valores 

predefinidos para oai_dc simples: 

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

dc:date -> valor predefinido: “created” (criação) 

dc:audience -> valor predefinido: “education level” (nível de educação) 

No DRIVER, isto significa que o elemento „date‟ (data) está associado à data de 

criação, etc. Recomenda-se que todos os fornecedores de conteúdos facultem esta 

informação a harvesters externos como informação do seu repositório. 

1.2 Os Elementos: descrição abreviada 

No DRIVER o uso de elementos pode ser: 

obrigatório (mandatory – M na tabela seguinte) = o elemento deve estar sempre 

presente no registo de metadados 

obrigatório quando aplicável (mandatory when applicable – MA na tabela seguinte)= 

quando o elemento pode ser obtido, deve ser adicionado ao registo de metados 

(aplica-se mais à introdução de metadados e não tanto à recolha) 

recomendado (recommended – R na tabela seguinte) = o uso do elemento é 

recomendado 

opcional (optional – O na tabela seguinte) = não é muito relevante se elemento é 

usado ou não 

5


Versão 1.1.1 

O estatuto “obrigatório quando aplicável” (MA) é mais forte que o recomendado (R) 

e esta distinção é feita essencialmente para encorajar os utilizadores a inserirem 

certos elementos durante a criação do registo de metadados para melhorar os 

serviços. 

6


Versão 1.1.1 

DC simples: 

oai_dc 

Elemento básico Estatuto Esquemas de codificação 

Title (Título) M Nenhum 

Creator (Autor) M Nenhum 

Subject (Assunto) MA A escolha de palavras-chave e classificações é livre. 

Idioma das palavras-chave: inglês 

Description (Descrição) MA Nenhum 

“Abstract” (Resumo) é o valor predefinido para 

dc:description 

A prática recomendada é adicionar um resumo em 

inglês. 

Publisher (Editora) MA Nenhum 

Contributor (Colaborador) O Nenhum 

Date (Data) M Data | ISO 8601 W3C-DTF 

“Created” é o valor predefinido para dc:date 

Type (Tipo) M Definições de tipo da DCMI 

Format (Formato) R IANA list of MIME types 

Identifier (Identificador) M Identificadores persistentes como URN, URI, handle 

Source (Fonte) O Nenhum 

Language (Idioma) R ISO 639-3 

Relation (Relação) O Nenhum 

Coverage (Cobertura) O Período 

Rights (Direitos) R Nenhum 

Audience (Público) O Nenhum 

Se não se menciona nenhum valor predefinido nos elementos oai_dc, por favor 

descreva o uso específico dos elementos oai_dc na secção „Identify‟ do seu RI. 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 

7


Versão 1.1.1 

1.3 Os Elementos: descrição completa 

1.3.1 Title (Título) 

Nome do elemento 

Definição DCMI 

Uso 

Title 

Nome atribuído ao recurso. Normalmente, o título é o 

nome pelo qual o recurso é formalmente conhecido. 

Obrigatório 

Instruções de uso Conservar o nome original, a ordem e a ortografia do 

título do recurso. Utilizar maiúsculas apenas para nomes 

próprios. A pontuação não tem que reflectir o uso do 

original. Os subtítulos devem separar-se do título 

mediante dois pontos. Se for necessário, repetir este 

elemento para múltiplos títulos. 

Não confundir com - 

Exemplos 

Título principal : Título paralelo 

Estudos preliminares para "Investigações 

Filosóficas", conhecido normalmente como livros azul e 

castanho 

1.3.2 Creator (Autor) 



Uso 

Instruções de uso 

Creator 

A principal entidade responsável pela criação dos 

conteúdos do recurso. Normalmente, o nome de um 

„Creator‟ deverá ser utilizado para indicar a entidade. 

Obrigatório 

Uma pessoa, uma organização ou um serviço podem ser 

um „Creator‟. Se necessário, repetir este elemento para 

múltiplos autores. 

Utilizar a forma invertida do nome: apelido, nome, prefixo 

Janssen, J. 

Quando se dispõe da inicial e do nome completo, utilizar o 

seguinte formato: 

Janssen, J. (John) 

Os sufixos geracionais (Júnior, Filho, etc.) devem ser 

precedidos do nome de família. Em caso de dúvida, 

atribuir o nome tal como aparece, sem inverter. Omitir 

títulos (como “Dr.”, “Sr.ª”, etc.) 

No caso de organizações onde exista uma hierarquia 

definida, enumerar as partes da hierarquia por ordem 

decrescente e separadas com pontos. Se a existência de 

8


Versão 1.1.1 

uma hierarquia não é clara ou se não é clara a ordem 

hierárquica decrescente, atribuir o nome tal como aparece 

no recurso. Codificar apenas as organizações neste 

elemento para indicar autoria corporativa, não para indicar 

a afiliação de um indivíduo. 

Não confundir com 

Exemplos 

A inclusão de cabeçalhos de nomes de pessoas ou 

colectividades a partir de ficheiros de autoridade nacionais 

ou locais é opcional. 

No caso de responsabilidades secundárias, que não de 

autoria, utilizar dc:contributor. Se a natureza da 

responsabilidade é ambígua, a prática recomendada é 

utilizar dc:publisher para organizações e dc:creator para 

indivíduos. 

Contributor (ver também Instruções de uso acima). 

Publisher. 

O elemento DC „creator‟ descreve o(s) nome(s) do(s) 

criador(es)/autor(es) do recurso tal como consta no próprio 

recurso, enquanto o element DC „contributor‟ descreve o(s) 

investigador(es) que contribuíram para um resultado 

científico, não como criadores ou editoras (comerciais). 

Sulston, John E. 

Evans, R.J. 

Walker Jnr., John 

International Human Genome Sequencing 

Consortium 

Loughborough University. Department of 

Computer Science 

1.3.3 Subject (Assunto) 



Uso 


Subject 

O assunto do recurso. Normalmente, o elemento subject 

será expresso como palavras-chave, frases chave ou códigos 

de classificação que descrevam o conteúdo intelectual do 

recurso. 

Obrigatório se aplicável 

No elemento DC „subject’ admitem-se dois tipos de valores 

possíveis: pode-se registar uma palavra-chave ou uma 

classificação. Se ambos estão disponíveis, utilizar instâncias 

separadas deste elemento. 

Utilizar a primeira instância do elemento DC „subject’ para 

uma palavra-chave. 

Em geral, seleccionar as palavras mais significativas para as 

palavras-chave e evitar usar palavras demasiado gerais para 

descrever um recurso específico. Se o assunto do recurso é 

uma pessoa ou uma organização, utilizar o mesmo formato 

9


Versão 1.1.1 


Exemplos 

de nome que usaria se a pessoa ou a organização fossem o 

autor, mas não repetir o nome no elemento dc:„creator’. 

Nas palavras-chave não controladas por um vocabulário ou 

thesaurus (isto é, em texto livre), introduzir diferentes 

termos com um ponto e vírgula a separar cada palavrachave 

ou frase-chave, ou repetir o elemento para cada 

termo. Não há nenhum requisito relacionado com as 

maiúsculas nas palavras-chave, mas recomenda-se manter 

uma coerência interna (dentro do mesmo repositório). 

Quando os termos são retirados de um esquema de 

classificação normalizado: registar cada termo num 

elemento separado. Inscrever o descritor completo do 

assunto segundo o esquema correspondente. Utilizar as 

maiúsculas e a pontuação segundo o esquema original. 

Type. 

O elemento DC „subject‟ descreve o(s) assunto(s) de um 

recurso; o elemento DC „type‟ descreve o tipo de 

publicação/resultado académico que o recurso representa. 

polar oceanography; boundary current; mass 

transport; 

water masses; halocline; mesoscale eddies 

World War, 1939-1945-- 

Germany 

Germany--History--1933-1945 

Hitler, Adolf, 1889-45 

1.3.4 Description (Descrição) 

Nome do elemento Description 

Definição DCMI Informação sobre o conteúdo do recurso. A descrição pode 

incluir, mas não se limita a: um resumo, sumários, 

referencias a representações gráficas do conteúdo ou texto 

livre com informação do conteúdo. 

Uso 

Obrigatório quando aplicável 

Instruções de uso Este elemento é utilizado para uma descrição textual do 

conteúdo. Quando um recurso consiste em vários ficheiros 

de objectos físicos independentes, não usar dc:description 

para listar os URL‟s destes ficheiros. 


Exemplos 

Prefácio [por] Hazel Anderson; Introdução; 

The scientific heresy: transformation of a society; 

Consciousness as causal reality [etc] 

A number of problems in quantum state and 

system identification are addressed. 

10


Versão 1.1.1 

1.3.5 Publisher (Editor) 

Nome do elemento Publisher 

Definição DCMI Uma entidade responsável pela disponibilização dos 

recursos. Uma pessoa, uma organização ou um serviço 

podem constituir exemplos de Editor. Normalmente, o nome 

de um Editor deverá ser utilizado para mencionar a entidade. 

Uso 

Obrigatório se aplicável 

Instruções de uso O Editor (comercial ou não-comercial) do recurso e não a 

instituição à qual o autor está afiliado. O Editor utiliza-se 

unicamente no sentido bibliográfico/funcional, não num 

sentido organizacional. Utilizar apenas o nome completo 

(comercial) do Editor, não o de uma organização ou instituto 

que esteja associado (num sentido mais amplo) ao autor. 

No caso de publicações universitárias, colocar o nome da 

faculdade, da escola ou do grupo de investigação depois do 

nome da universidade. 

No caso de organizações onde exista claramente uma 

hierarquia presente, enumerar as partes da hierarquia por 

ordem decrescente, separadas com pontos. Se não é clara a 

existência de uma hierarquia, ou se a ordem hierárquica 

decrescente não é clara, atribuir o nome tal como aparece no 

documento. 

O uso de nomes de Editores a partir de listas de autoridade 

locais ou nacionais é opcional. 

Não confundir com - Contributor 

- Creator 

Na maior parte dos casos o editor e o autor não são o 

mesmo. 

Exemplos 



University of Cambridge. Department of 

Earth Sciences 

University of Oxford. Museum of the History 

of Science 

University of Reading. Rural History 

Centre 

University of Exeter. Institute of Cornish 

Studies 

European Bioinformatics 

Institute 

John Wiley & Sons, Inc. (US) 

1.3.6 Contributor (Colaborador) 

Nome do elemento Contributor 

Definição DCMI Uma entidade responsável colabora na elaboração de 

conteúdos do recurso. Uma pessoa, uma organização ou um 

11


Versão 1.1.1 

Uso 


serviço podem constituir exemplos de um colaborador. 

Normalmente, o nome de um colaborador deverá ser utilizado 

para referenciar a entidade. 

Opcional 

Exemplos de colaboradores: orientadores, editores, técnicos 

ou colectores de dados. 

Nomes pessoais deverão ser listados como: ver instruções em 

„Creator‟. 

Um “orientador”, isto é um professor que oriente o trabalho 

de um aluno para obtenção de um grau de doutoramento é 

considerado um colaborador no seu papel de 

orientador/avaliador. 

No caso das organizações: ver instruções em „Creator‟. 

A inclusão de cabeçalhos de nomes de pessoas ou 

colectividades a partir de ficheiros de autoridade nacionais ou 

locais é opcional. 


Exemplos 

- Creator 

- Publisher 

O elemento DC „contributor‟ descreve o(s) investigador(es) 

que contribuíram para o resultado cientifico, não como autor 

principal ou editor (comercial).. 

Sulston, John E. 

Evans, R. J 

International Human Genome Sequencing 

Consortium 



1.3.7 Date (Data) 



Uso 


Date 

A data associada a um evento no ciclo de vida do recurso. 

Normalmente, a Data está associada à criação ou 

disponibilização do recurso. A prática recomendada para 

codificar o valor data é definido na norma ISO 8601 

[W3CDTF] e segue o formato YYYY-MM-DD. 

Obrigatório 

O formato da data deverá estar de acordo com as W3C 

encoding rules for dates and times: 

Data completa: 

YYYY-MM-DD (ex. 1997-07-16) 

12


Versão 1.1.1 

onde: 

YYYY [ano com quatro dígitos] é obrigatório 

MM [mês com dois dígitos (01=Janeiro, etc.)] é opcional 

DD [dia do mês com dois dígitos (de 01 até 31)] é opcional 

Utilizar o elemento DC „date‟ para o valor [do qualificador]: 

„date created‟. 

Extras como “Zulu time” (ex. no Dspace) não deverão constar 

nos metadados. 


Exemplos 

2000-12-25 

1.3.8 Type (Tipo) 



Uso 


Type 

O tipo de resultado científico do qual o recurso é uma 

manifestação. No elemento DC „type‟, descreve-se o tipo de 

divulgação ou o tipo de conteúdo intelectual do recurso. 

Utiliza-se para explicar ao utilizador que tipo de recurso está a 

visualizar. Se é um livro ou um artigo. Se foi escrito para uso 

interno ou externo. Etc. 

Obrigatório. Deve-se utilizar um elemento DC „type‟ em todos 

os registos de metadados. 

Utilizar a primeira instância do elemento DC „type‟ para 

indicação do tipo de resultado científico. 

Utilizar o texto exacto conforme listado em baixo. 


Article 

Book 

Conference lecture 

Conference report 

Contribution for newspaper or weekly magazine 

Doctoral thesis 

Master thesis 

Bachelor thesis 

External research report 

Lecture 

Internal report 

Newsletter 

Part of book or chapter of book 

Research paper 

Format 

O elemento DC „type‟ descreve o tipo de resultado académico 

do qual o recurso é uma representação. O elemento DC 

„format‟ descreve o tipo de meio do recurso. 

13


Versão 1.1.1 

Exemplos 

Article 

1.3.9 Format (Formato) 



Uso 


Format 

Manifestação física ou digital do recurso. Normalmente, o 

elemento „Format‟ pode incluir o tipo de meio ou as dimensões 

do recurso. O elemento „Format‟ pode utilizar-se para 

determinar o software, o hardware ou outro equipamento 

necessário para mostrar ou operar o recurso. Exemplos de 

dimensões são o tamanho e a duração. A prática recomendada é 

seleccionar um valor de um vocabulário controlado (por 

exemplo, a lista de tipos de meios da Internet [MIME] que 

define os formatos para os equipamentos informáticos). 

Recomendado 

Baseado em práticas recomendas, utiliza-se a lista registada da 

IANA de tipos de meios da Internet (tipos MIME) para 

seleccionar uma designação. Um subconjunto desta lista de 

tipos MIME bastará para as necessidades do DRIVER. 

O formato deverá ser o seguinte: type/subtype (tipo/subtipo) 

Tipo 

Subtipo 

---- ------- 

text 

plain 

richtext 

enriched 

tab-separated-values 

html 

sgml 

xml 

application 

image 

octet-stream 

postscript 

rtf 

applefile 

mac-binhex40 

wordperfect5.1 

pdf 

zip 

macwriteii 

msword 

sgml 

ms-excel 

ms-powerpoint 

ms-project 

ms-works 

jpeg 

14


Versão 1.1.1 

gif 

tiff 

png 

jpeg2000 

sid 

audio 

video 

wav 

mp3 

quicktime 

mpeg1 

mpeg2 

mpeg3 

avi 

Se um recurso específico (uma instância de um documento 

científico) tem mais de um formato físico (por exemplo, 

postscript e pdf) armazenados como ficheiros de objecto 

distintos, todos os formatos deverão ser mencionados no 

elemento DC „format‟, por exemplo: 


Exemplos 

Esquema 

application/pdf 

application/postscript 

Type 

O elemento DC „format‟ descreve o tipo de meio do recurso. O 

elemento DC „type‟ descreve o tipo de resultado/publicação 

científica do qual o recurso é uma manifestação. 

application/pdf 

video/quicktime 

IANA registered list of Internet Media Types (MIME types) 

http://www.iana.org/assignments/media-types/ 

1.3.10 Identifier (identificador) 



Uso 


Identifier 

Referência inequívoca do recurso num contexto determinado. 

Obrigatório 

Recomenda-se a identificação do recurso mediante uma 

sequência ou número de acordo com um sistema de 

identificação formal. 

Alguns exemplos de sistemas de identificação formal incluem o 

Uniform Resource Identifier (URI) (incluindo o Uniform 

Resource Locator (URL), o Digital Object Identifier (DOI) e o 

URN:NBN 

O uso ideal deste elemento consiste na utilização de uma 

ligação directa (URL persistente) do dc:identifier no registo de 

15


Versão 1.1.1 

metadados a um recurso digital, ex. um ficheiro PDF. 


Exemplos 

Se uma ligação directa não for possível, ex. quando uma página 

de transição é utilizada, o uso do XML-container é 

recomendado (ver Apendice 3). 

dc:source and dc:relation 

Utilizar dc:relation para relacionar uma versão do recurso com 

outra. 

Utilizar dc:source para citação bibliográfica do recurso de 

origem. 

 

http://arno.unimaas.nl/show.cgi?fid=5628 

1.3.11 Source (Fonte) 



Uso 


Source 

Referência a um recurso do qual deriva o recurso actual. 

Opcional 

O recurso actual pode derivar total ou parcialmente do recurso 

source. A prática recomendada consiste em referenciar o 

recurso através de uma sequência ou um número em 

conformidade com um sistema de identificação formal. 

Prática recomendada: Utilizar apenas se o recurso descrito for 

resultado da digitalização de originais não digitais. Caso 

contrário, utilizar o elemento „Relation‟. Opcionalmente, podese 

adicionar metadados sobre a localização actual e número de 

registo da publicação digitalizada. 


Exemplos 

Utilizar: Guidelines for Encoding Bibliographic Citation 

Information in Dublin Core Metadata 

(http://epub.mimas.ac.uk/DC/dc-citation-guidelines/) para as 

referências bibliográficas de artigos de revistas e para 

referências bibliográficas de um recurso nos seus proprios 

metadados. 

dc:relation and dc:identifier 

Ecology Letters (1461023X) vol.4 

(2001) 

ISSN: 0928-0987 

1.3.12 Language (Idioma) 

Nome do elemento Language 

Definição DCMI Idioma do conteúdo intelectual do recurso. 

Uso 

Recomendado 

Instruções de uso Um recurso específico (uma instância de um 

16



Exemplos 

Esquema ISO 639-3 

Versão 1.1.1 

resultado/publicação científica) é escrito em um ou vários 

idiomas legíveis pelo ser humano. Nestes casos, todos os 

idiomas utilizados são descritos no elemento DC „language‟. Se 

um recurso específico (uma instância de um 

resultado/publicação científica) está escrito numa linguagem 

legível pelo ser humano e é traduzido para outros idiomas 

legíveis, as traduções diferenciam-se da versão original e por 

conseguinte são descritas separadamente. 

Prática recomendada: Utilizamos a norma ISO 639-3 e ao fazêlo 

seguimos o que está estipulado em: 

http://www.sil.org/ISO639-3/codes.asp 

Se necessário, repetir este elemento para indicar diferentes 

idiomas. 

eng 

deu 

1.3.13 Relation (Relação) 

Nome do elemento Relation 

Definição DCMI Referência a um recurso relacionado. 

Uso 

Opcional 

Instruções de uso A prática recomendada consiste em relacionar o recurso através 

de uma sequência ou um número em conformidade com um 

sistema de identificação formal. O elemento DC „relation‟ pode 

ser utilizado para indicar distintos tipos de relações entre vários 

registos de metadados. 

Se as relações entre os registos metadados se tornam visíveis 

através do uso de metadados, devem ser observadas as 

seguintes situações: 

Um registo de metadados contém-se em si mesmo 

Diferentes manifestações do mesmo recurso (uma 

instância de um resultado/publicação cientifica) [que 

pode descrever-se exactamente com os mesmos 

metadados bibliográficos, excepto no elemento DC 

„format‟] são ligadas a um único registo de metadados 

Outras alterações nos metadados para além do elemento DC 

„format‟ implicam a criação de um novo registo de metadados 

para esta nova instância do resultado/publicação científica, que 

cumpre todos requisitos formulados neste documento e tem um 

valor no elemento DC „relation‟. 


Exemplos 

dc:identifier and dc:source. 

uri 

17


Versão 1.1.1 

http://hdl.handle.net/1765/1473 

Onde uri é o valor do elemento DC „identifier‟ do registo de 

metadados relacionado. 

1.3.14 Coverage (Cobertura) 



Uso 


Coverage 

Extensão ou âmbito do conteúdo do recurso. Normalmente, a 

cobertura inclui a localização espacial (nome do lugar ou 

coordenadas geográficas), um período temporal (etiqueta de 

período, data ou intervalo de datas) ou a jurisdição (por 

exemplo, o nome de uma entidade administrativa). 

Opcional 

A prática recomendada consiste na selecção do valor de um 

vocabulário controlado (por exemplo, o Getty Thesaurus of 

Geographic Names ou TGN) e quando for apropriado, utilizar 

preferencialmente nomes de locais ou períodos de tempo em 

vez de identificadores numéricos, como por exemplo, conjuntos 

de coordenadas ou intervalos de datas. 

Se necessário, repetir este elemento para inserir múltiplas 

localizações ou períodos. 


Exemplos Exemplo espacial – ISO 3166 

NL 

Exemplo espacial – BOX 

name=Western Australia; northlimit=-13.5; 

southlimit=-35.5; westlimit=112.5; 

eastlimit=129 

Esquema 

Nota sobre BOX: A sintaxe utilizada aqui é provisória e 

encontra-se actualmente em processo de revisão como parte do 

trabalho da DCMI para produzir recomendações sintácticas de 

coordenadas para HTML, XML, e RDF. Estas recomendações 

e alterações editoriais mínimas serão repercutidas neste 

documento futuramente. 

Point http:/ dublincore.org/documents/dcmi-point/ 

ISO 3166 http:/ www.iso.ch/iso/en/prodsservices/iso3166ma/02iso-3166-code-lists/index.html 

Box http:/ dublincore.org/documents/dcmi-box/ 

TGN http:/ www.getty.edu/research/tools/vocabulary/tgn/ 

Period 

18


Versão 1.1.1 

1.3.15 Rights (Direitos) 

Nome do elemento Rights 

Definição DCMI Informação sobre os direitos no recurso e sobre o recurso. 

Uso 

Recomendado 

Instruções de uso Normalmente, o elemento „Rights‟ conterá uma declaração dos 

direitos para aceder ou utilizar o objecto ou uma referência a 

um serviço que proporcione essa informação. A informação de 

direitos abrange, frequentemente, direitos de propriedade 

intelectual (Intellectual Property Rights - IPR), copyright e 

outros direitos de propriedade. 


Exemplos 

(c) University of Bath, 2003 

(c) Andrew Smith, 2003 

1.3.16 Audience (Público) 



Uso 



Exemplos 

Audience 

Um tipo de entidade para a qual o recurso é dirigido ou útil. 

Opcional 

Um tipo de entidade poderá ser determinado pelo autor ou 

editor ou por um terceiro. 

No website Metadata Reference do U.S. Department of 

Education, são dados exemplos de públicos: 

http:/ www.ed.gov/admin/reference/index.jsp 

Administrators 

Community Groups 

Counsellors 

Federal Funds Recipients and Applicants 

Librarians 

News Media 

Other 

Parents and Families 

Policymakers 

Researchers 

School Support Staff 

Student Financial Aid Providers 

Students 

Teachers 

Researchers 

Students 

19


Versão 1.1.1 

2 Anexo: directrizes específicas para uso do 

protocolo OAI-PMH 

Nota: Os exemplos utilizados são para DIDL; não devem ser utilizados literalmente! 

Para conhecer o uso concreto do documento DIDL, consultar a versão actual da 

especificação do documento DIDL. O referido documento prevalecerá sobre todos os 

exemplos aqui apresentados. 

Agradecimentos Este documento baseia-se em grande parte nos debates produzidos 

entre administradores de repositórios e o SURF. A sua experiência e as suas 

sugestões foram de grande utilidade na produção das directrizes contidas neste 

documento. 

Fonte de informação As directrizes são baseadas e referem-se ao Open Archives 

Initiative Protocol for Metadata Harvesting, Protocol versão 2.0. Ver: 

http://www.openarchives.org/OAI/openarchivesprotocol.html 

A ordem de apresentação destas directrizes coincide com o texto do protocolo. 

Nos casos pertinentes, o texto do protocolo é citado. Nos casos em que o texto foi 

modificado, por exemplo, utilização de negrito para realçar alguma parte do texto, 

isso é indicado entre parênteses. 

2.1 Definições e conceitos: item, registo e identificador 

único 

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

seguinte: 

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

dinamicamente metadados relacionados com um único recurso em múltiplos 

formatos, cada um dos quais pode ser recolhido como registos através do protocolo 

OAI-PMH [...] Um registo são metadados reflectidos num formato único. Um registo 

é recuperado num XML-encoded byte stream como resposta a um pedido OAI-PMH 

de metadados de um item...[negrito adicionado por MF] 

No DRIVER, o XML-encoded stream é construído de acordo com especificações 

XML-Container. Estas especificações são referidas de seguida. 

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

identificador com o elemento dc:identifier no Dublin Core. O identificador OAI 

possui uma função diferente: é utilizado para extrair metadados, enquanto o 

identificador DC é utilizado para extrair o recurso. 

Esquematicamente: 

20


Versão 1.1.1 

Item com identificador 

único 

Dentro do 

repositório 

Fora do 

repositório 

Registo com 

metadados XMLencoded, 

ex. em 

DC simples 

Registo com 

metadados XMLencoded, 

ex. em 

MARC-21 

Harvester A 

Harvester B 

2.2 Nomenclatura de prefixos de metadados (MetadataPrefix 

naming) 

Ver em: 

http://www.openarchives.org/OAI/openarchivesprotocol.html#MetadataNamespaces 

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

metadados de um repositório. O pedido (request) ListMetadataFormats 

apresenta uma lista de todos os formatos de metadados. 

O argumento metadataPrefix utiliza-se nos pedidos ListRecords, 

ListIdentifiers e GetRecord para recuperar os registos ou os cabeçalhos 

dos registos que incluem metadados no formato especificado pelo metadataPrefix. 

Por razões de interoperabilidade, os repositórios devem disseminar Dublin Core sem 

qualificadores. Por esse motivo, o protocolo reserva o metadataPrefix „oai_dc‟ e a 

URL de um esquema de metadados para Dublin Core não qualificado, que é 

http://www.openarchives.org/OAI/2.0/oai_dc.xsd. O URI do namespace XML 

correspondente é http://www.openarchives.org/OAI/2.0/oai_dc/. 

21


Versão 1.1.1 

2.2.1 Documento DIDL 

A comunidade DRIVER suporta a implementação dos prefixos de metadados 

„oai_dc‟ e „DIDL_document‟. Cada repositório DRIVER que utilize o XML 

container deve admitir este esquema de metadados „DIDL_document‟. 

A especificação do XML container do DIDL_document encontra-se no anexo 3 deste 

documento. 

 

 

 

 

 

... 

2.3 Data de registo (Datestamp) 

De acordo com o protocolo, cada registo contém um cabeçalho com um registo de 

data (datestamp) que contém "the date of creation, modification or deletion of the 

record for the purpose of selective harvesting." 

O protocolo também explica a recolha (harvesting) selectiva do seguinte modo: 

“..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 disponibilizadas dentro dos limites dos 

argumentos from e until. 

deletion – dependendo do nível a que o repositório mantenha informação 

sobre os registos eliminados, a resposta pode incluir cabeçalhos de registos 

(correspondentes ao argumento metadataPrefix), que foram retirados do 

repositório dentro dos limites dos argumentos from e until. O estado 

„eliminado‟ é indicado através do atributo de estado do elemento header e não 

se incluem metadados...” 

É muito, muito importante ter cuidado na implementação da data de registo 

(datestamp) de acordo com o protocolo como acima mencionado. A experiência tem 

revelado que muitos dos erros de recolha (harvesting) que ocorrem na recolha 

incremental têm a sua origem na má interpretação da data de registo (datestamp). 

2.4 Formato de data de registo (Datestamp) 

Ver em: 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 

devem estar em conformidade com as especificações de UTCdatetime referida neste 

22


Versão 1.1.1 

documento. O acordo DRIVER apoia o uso granular opcional no que concerne ao 

tempo com segundos YYYY-MM-DDThh:mm:ssZ. 

Este valor está de acordo com as especificações para o UTCdatetime nas secções 

3.3.1 no documento do protocolo OAI-PMH. Registos de datas são codificados 

usando a norma ISO8601 e expressos em UTC. 

 

 

 

 

 

2001-12-14T12:01:45Z 

Um repositório que suporte YYYY-MM-DDThh:mm:ssZ deverá indicar este facto 

na resposta a „Identify‟. 

 

 

 

YYYY-MM-DDThh:mm:ssZ 

 

2.5 Registos eliminados 

Ver em: 

http://www.openarchives.org/OAI/openarchivesprotocol.html#DeletedRecords 

Se um registo deixa de estar disponível, considera-se eliminado. Os repositórios 

devem declarar um dos três níveis de suporte relativamente a registos eliminados no 

elemento „deletedRecord‟ da resposta ao „Identify‟: 

• no – o repositório não mantém informação sobre as eliminações. Um 

respositório que indique este nível de suporte não deve revelar um estatuto de 

eliminação em qualquer resposta. 

• persistent – o repositório mantém informação sobre as eliminações sem 

qualquer limite de tempo. Um repositório que indique este nível de suporte 

deve sistematicamente manter um registo do historial das eliminações e 

consistentemente revelar o estado de um registo eliminado ao longo do 

tempo. 

• transient – o repositório não garante a manutenção de uma lista de 

eliminações de forma persistente e consistente. Um repositório que indique 

este nível de suporte pode revelar o estado dos registos eliminados. 

As directrizes do DRIVER requerem que os repositórios DRIVER usem a opção 

„transient‟. Mas a opção „persistent‟ também poderá ser utilizada. Esta 

opção facilita a detecção de registos eliminados pelo harvester. 

Um repositório ao manter um registo de eliminações não necessita de efectuar uma 

nova recolha e assim diminui a sobrecarga na rede 

Utilização do nível transient: Quando um registo é eliminado, o repositório deve 

indicar a eliminação durante, pelo menos, um mês. Neste período, a maioria dos 

23


Versão 1.1.1 

harvesters actualizaram a sua base de dados incrementalmente (sem necessidade de 

uma recolha – harvest - completa). 

Se um repositório possui um registo das eliminações, a data de registo (datestamp) 

do registo eliminado deve ser a data e a hora em que foi eliminado. As respostas ao 

pedido GetRecord de um registo eliminado devem então incluir um header com 

o atributo status=deleted. Assim, o harvesting incremental detectará 

eliminações em repositórios que façam o seu registo. 

2.6 Tempo de vida do testemunho de reatamento 

(resumption token) 

Ver em: http://www.openarchives.org/OAI/openarchivesprotocol.html#Idempotency 

Os repositórios que implementem testemunhos de reatamento (resumptionTokens) 

devem fazê-lo de tal forma que os harvesters possam retomar uma sequência de 

pedidos de listas incompletas reenviando um pedido de lista com o resumptionToken 

mais recente. O objectivo é permitir que os harvesters possam recuperar erros de 

rede ou de outros erros que de outra forma implicariam o reinício da sequência de 

pedidos. 

O protocolo não menciona o tempo de vida de um testemunho. O tempo de um 

testemunho é o tempo durante o qual um repositório o conserva em memória 

conjuntamente com a informação de reatamento. Quando o tempo de vida é 

demasiado pequeno, o repositório não dá tempo suficiente para um harvester voltar e 

recolher a informação. Quando isto acontece, o repositório não cumpre com o 

protocolo, ver em cima: “devem fazê-lo de tal forma que os harvesters possam 

retomar...”. 

Por experiência: o tempo razoável para que um testemunho seja conservado é de pelo 

menos vinte e quatro (24) horas. 

Juntamente com este tempo de vida existe um tamanho de lote óptimo: ver secção 

“Tamanho do lote de recolha ”. 

2.7 Tamanho do lote de recolha 

O tamanho de lote é o número de registos que um repositório entrega ao harvester 

para um testemunho de reatamento (resumption token). 

Está acordado que os repositórios DRIVER devem definir o tamanho do lote entre 

100 a 200 registos. 

Utilizando este tamanho de lote para todos os repositórios do DRIVER, permitir-se-á 

que o harvester opere com um rendimento óptimo. 

2.8 Nomenclatura de Sets (conjuntos) do DRIVER 

Ver em: http://www.openarchives.org/OAI/openarchivesprotocol.html#Set 

24


Versão 1.1.1 

O documento do protocolo OAI-PMH refere o seguinte: 

Os repositórios podem organizar os items em conjuntos (sets). A organização dos 

conjuntos pode ser plana, isto é uma simples lista, ou hierárquica. 

Está acordado que os repositórios DRIVER, suportem pelo menos o conjunto (set) 

DRIVER.O set DRIVER é plano e não tem nenhuma estrutura hierárquica. O 

contéudo do set DRIVER é apresentado de seguida. 

A tabela seguinte indica o setName e a especificação setSpec preferenciais que se 

podem utilizar no set do DRIVER. 

setName setSpec * 

O set DRIVER Open Access DRIVERset Driver 

*Um harvester apenas utiliza o pedido setSpec para realizar recolha selectiva. Os caracteres devem estar em minúsculas. 

2.8.1 Definições do conteúdo do set DRIVER 

O conteúdo específico de setSpec é determinado no repositório local. 

Um repositório DRIVER que use este tipo de sets deve estar em conformidade com 

as seguintes regras ao inserir um registo no set DRIVER. O DRIVER utiliza esta 

directriz para definir globalmente o conteúdo destes sets: 

• O set DRIVER contém registos que devem conter recursos textuais digitais de 

acesso livre 

o Deve conter objectos de texto integral, não apenas metadados. 

o O conteúdo é de acesso livre 

o O conteúdo não é protegido por firewall 

o O conteúdo é também acessível fora do campus universitário 

o O conteúdo não se encontra em websites pagos 

• Podem existir Outros sets (com nomes exclusivos) que contenham registos, 

que não incluam nenhum objecto e que contenham apenas metadados. Se 

contêm um objecto, não têm que estar em acesso livre, mas recomenda-se que 

assim seja. O DRIVER não utilizará estes sets. 

A figura seguinte mostra que é possível inserir um registo em diferentes 

conjuntos (sets). Os registos seguintes, representados por um ponto azul, também 

existem no set DRIVER. Dois registos existem nos três sets. O set de bioquímica 

(biochemistry set), o set de neurofísica (neurophysics set) e o set DRIVER. Os 

dois primeiros sets indicam um assunto, o set DRIVER indica um tipo (acesso 

livre). 

O cabeçalho de um registo pode conter zero ou mais setSpecs. Um registo OAI 

pode assemelhar-se com o seguinte. 

 

 

oai:repository:it/0112017 

2002-02-28 

biochemistry 

neurophysics 

driver 

 

 

25


Versão 1.1.1 


Versão 1.1.1 

“O pedido (verb) Identify é utilizado para recuperar informação acerca de um 

repositório.” 

“A resposta deve incluir uma ou várias instâncias do seguinte elemento: 

• adminEmail : o endereço de correio electrónico do administrador do 

repositório.” 

2.10 Declaração de Prefixo & espaço de nomes 

Ver em: http://www.openarchives.org/OAI/openarchivesprotocol.html#Record 

Declarações de espaço de nomes (namespace declarations) – declarações de espaços 

de nomes utilizadas nos metadados, são todas precedidas de xmlns. As declarações 

de espaço de nome nos metadados dividem-se em duas categorias: 

• espaço(s) de nomes específicos de metadados (metadata format specific 

namespace(s)) – cada parte dos metadados deve incluir um ou vários 

atributos com prefixo xmlns que definam a correspondência entre um prefixo 

de formato -- ex. Didl_document – e o URI do espaço de nomes (tal como se 

define na especificação do espaço de nomes XML) do formato de metados 

correspondente. Alguns formatos de metadados utilizam etiquetas de vários 

espaços de nomes, requerendo vários atributos com prefixo xmlns – no 

exemplo, existem declarações de oai_dc e dc. 

• espaço de nomes esquema xml (xml schema namespace) – cada parte de 

metadados deve incluir o atributo xmlns:xsi, cujo valor deve ser o URI que 

aparece no exemplo, que é o URI do espaço de nomes do esquema XML 

(XML schema). 

• xsi:schemaLocation – o seu valor é um par URI/URL; o primeiro é o URI de 

espaço de nome (conforme definido pela especificação de espaço de nomes 

XML) dos metadados que o seguem nesta parte, o segundo é o URL do 

esquema XML para validação dos metadados que o seguem. 

O uso recomendado de prefixos e espaços de nomes indica que estas entidades 

devem ser declaradas no primeiro elemento desse espaço de nomes. Com isto, evitase 

“dificuldades operacionais” conforme descritas em: http://www.w3.org/TR/RECxml-names/#ns-using 

. 

―O uso de prefixos pode provocar dificuldades operacionais se o atributo de 

declaração de espaço de nomes não se proporciona directamente na entidade do 

documento XML, mas mediante um atributo predeterminado declarado numa entidade 

externa.‖ 

Exemplos de usos recomendados de prefixos e espaços de nomes. 

 

 

 


Versão 1.1.1 

xmlns:dcterms="http://purl.org/dc/terms/" 

xsi:schemaLocation=" 

urn:mpeg:mpeg21:2002:02-DIDL-NS 

http://standards.iso.org/.../didl.xsd 

urn:mpeg:mpeg21:2002:01-DII-NS 

http://standards.iso.org/.../dii.xsd" 

> 

 

 

 

 

 

Outro argumento é, por exemplo, que um documento DIDL é considerado uma 

entidade anónima que pode existir fora de um registo OAI. Quando se faz um 

pequeno extracto (snippet) deste documento DIDL ele deveria ser válido em si 

próprio de acordo com um validador XML. Por isso, não necessita nenhum dos 

textos da declaração do espaço de nomes que se deixaram no xml do protocolo OAI- 

PMH. 

Conforme é referido no mesmo documento (http://www.w3.org/TR/REC-xmlnames/#ns-using), 

o acordo no DRIVER indica que também é possível declarar 

prefixos e espaços de nomes nos antepassados do documento. 

―O prefixo do espaço de nomes (namespace prefix), a não ser que seja xml ou xmlns, 

DEVE ter sido declarado num atributo da namespace declaration na etiqueta de abertura 

do elemento em que se utiliza o prefixo ou num elemento antepassado (por exemplo, um 

elemento em cujo conteúdo se declara o prefixo).‖ 

Exemplos dos usos opcionais de prefixos e espaços de nomes. 

 

 

 

 

 

 

 

 

 

28


Versão 1.1.1 

2.11 Validação XML 

O XML que o repositório disponibiliza como resultado deve ser validado 

inicialmente pelo administrador do repositório DRIVER e pelo administrador do 

harvester DRIVER na primeira recolha. 

Um repositório DRIVER deve disponibilizar um XML valido de acordo com o 

esquema OAI-PMH e também segundo o esquema DIDL_document. 

A validação pode ser feita usando um validador XML (ex. Altova: www.altova.com) 

salvando o resultado do repositório como documento xml e abrindo-o no validador. 

Para que um validador possa validar um documento XML, deve ser utilizado dentro 

do documento o xsi:schemaLocation(s). 

For the schema use: 

 


 


 

Para outros esquemas, utilizar a mesma lógica: conservar os 

metadados independentes do protocolo OAI-PMH. 

29


Versão 1.1.1 

2.12 Comunicação para modificação nos repositórios 

Modificação de baseURL, setSpec, metadataPrefix ou esquema de metadados 

Quando um repositório DRIVER alterar a baseURL, setSpec, metadataPrefix ou o 

esquema de metadados, influenciando o ciclo de conteúdos do DRIVER, então: o 

administrador do repositório em questão deverá reportar isso à comunidade 

DRIVER e ao administrador do harvester do DRIVER em particular. 

30


Versão 1.1.1 

3 Anexo: Directrizes específicas para uso do MPEG- 

21 DIDL (xml-container) 

3.1 Introdução e objectivo 

Este documento é um anexo ao documento de especificação DIDL existente para 

repositórios utilizado presentemente pelas universidades holandesas, na Koninklijke 

Bibliotheek, Biblioteca Nacional da Holanda e no DAREnet. O objectivo deste 

documento é clarificar o uso do DIDL de forma inequívoca através da descrição da: 

1. natureza das diferentes partes de “metadados”, “objectos” e “ páginas de 

transição” 

2. o que é identificação. 

3. o que é data de modificação. 

Quando usada correctamente, esta especificação irá criar um registo XML MPEG-21 

DIDL válido para uso com respostas OAI-PMH. 

Esta especificação de documento DIDL para repositórios é baseada em decisões 

propostas inicialmente durante o desenvolvimento deste formato XML para utilizar 

MPEG-21 DIDL. A proposta constituiu um esboço de um formato de 

empacotamento (wrapper) com espaço para recursos de metadados, objectos e 

páginas de transição. 

Esta especificação é um trabalho de maior precisão. 

3.2 Contextualização 

O DIDL foi originalmente desenvolvido no seio do programa DARE promovido pelo 

SURF como uma primeira implementação de MPEG-21 DIDL. 

Os motivos para este desenvolvimento foram: 

uma solução para a recolha (harvesting) de recursos mediante o protocolo OAI- 

PMH para transportar recursos digitais (PDF‟s etc.) desde repositórios locais para 

a Biblioteca Nacional para introduzir os recursos num sistema de depósito 

electrónico para a sua preservação a longo prazo 

uma solução para recolha de recursos mediante o protocolo OAI-PMH para 

transportar recursos digitais (PDF‟s etc) desde repositórios locais para 

fornecedores de serviços (ex. um portal de pesquisa que indexe documentos de 

texto integral) 

uma solução (parcial) para representar documentos complexos. Numa primeira 

fase focada em teses que possuam vários ficheiros de recursos digitais 

uma solução para evitar a utilização confusa do elemento dc:identifier no caso de 

um ligação a uma página de transição (jump-off page (JOP)); muitos repositórios 

colocam uma ligação para uma página de transição no elemento dc:identifier ao 

invés de inserir uma ligação directa ao ficheiro do recurso digital. 

O DIDL está em uso no DARE desde o verão de 2006. Um dos resultados é que 

conteúdo de todos os repositórios holandeses faz agora parte do E-Depot da 

Koninklijke Bibliotheek, Biblioteca Nacional da Holanda. 

31


Versão 1.1.1 

3.3 Resposta OAI com um documento DIDL 

O documento DIDL faz parte de uma resposta OAI-PMH. O documento DIDL será 

devolvido dentro de um registo OAI quando se utiliza didl como valor do pedido 

metadataPrefix. Isto permite que o repositório possa gerar o formato DIDL concreto 

que se descreve no documento seguinte. 

Na estrutura XML do OAI, o DIDL reside no elemento metadados. Ver abaixo: 

 

... 

 

... 

 

... 

 

 

... 

 

 

... 

 

... 

 

3.3.1.1.1 Observações: 

1. Não esquecer a etiqueta DIDL na resposta OAI-PMH. 

2. Produza uma declaração dos espaços de nome (namespaces) didl , dii, dip e 

dcterms aqui, na etiqueta DIDL. Estes espaços de nome são necessários ao 

longo de todo o documento DIDL. 

a. Não crie estes espaços de nome na etiqueta , porque a 

razão de ser de um documento DIDL é a possibilidade de existir fora 

do contexto do protocolo OAI-PMH. 

3. O elemento about é opcional no protocolo OAI-PMH 

3.4 DIDL como invólucro ou empacotador (wrapper) 

O DIDL é um documento com um elemento Item ao nível superior. O Item contém 

vários elementos Item “filhos”. Estes elementos “filhos” aparecem em três tipos 

32


Versão 1.1.1 

distintos. Em seguida, entre parênteses mostra-se a cardinalidade dos elementos 

XML: 

 

 

 

... 

... 

... 

 

 

 

DIDL[1] 

Item[1] 

Item[1..∞] (of type 1) 

Item[1..∞] (of type 2) 

Item[0..1] (of type 3) 

O DIDL pode ser resumido no modelo FRBR que o perfil de aplicação e-prints 

utiliza (SWAT). 

the eprint (an 

abstract concept) 

ScholarlyWork 

 

isExpressedAs 

the ‘version of 

record’ 

or 

the ‘french 

version’ 

or 

‘version 2.1’ 

0..8 

Expression 

 

isManifestedAs 

the PDF 

format of the 

version of 

record 

AffiliatedInstitution 

isSupervisedBy 

isFundedBy 

isCreatedBy 

0..8 

0..8 

isEditedBy 

Manifestation 

 

isAvailableAs 

isPublishedBy 

Copy 

 

Figura 1: Fonte: www.ukoln.ac.uk/ukoln/staff/j.allinson/eprints-ap-openscholarship.ppt 

(esta ligação já não está activa) 

O Item raiz DIDL pode ser considerado como o elemento Scholarlywork no modelo 

FRBR. 

As partes do elemento Item raiz têm distintas relações semânticas. Estes Items são 

expressos como tipo 1,2 e 3. Os items (tanto os items de raiz como os subitems) 

frequentemente possuem o seu próprio identificador para converter-se numa entidade 

autónoma auto-suficiente. 

O componente no DIDL pode ser visto como manifestação no modelo FRBR. 

O recurso do DIDL pode ser visto como cópia no modelo FRBR. 

3.4.1 Documento DIDL atributo identificação 

O elemento raiz DIDL contém um attribute adicional. Este attribute disponibiliza 

informação sobre o identificador do invólucro (wrapper) DIDL como uma entidade 

autónoma. 

0..8 

0..8 

0..8 

0..8 

Agent 

the author or 

publisher or … 

the publisher’s copy 

of the PDF … 

33


Versão 1.1.1 

 

... 

... 

... 

... 

... 

 

 

 

 

 

... 

... 

... 

... 

 

... 

... 

... 

... 

34


Versão 1.1.1 

 

 

3.4.2.1 Declaração de Item 'Identifier' (identificador) 

O primeiro elemento Descriptor contém o ID dos elementos Item. Utiliza-se, 

sobretudo, para identificar de forma exclusiva o objecto digital (por exemplo, com 

um DOI). O ID empacota-se num Statement com um elemento DII Identifier. Por 

exemplo: 

 

 

 

 

info:doi/10.1705/6748398729821 

 

 

... 

 

... 

 


1. No caso de elementos Item ”filhos” do elemento Item raíz indica que este elemento 

Identifier NÃO é igual ao OAI identifier ou DIDL identifier utilizados. 

2. O atributo Identifier do elemento Item raíz PODE coincidir com os identificadores 

DIDL ou OAI Identifier, embora não se recomende. 

3. O espaço de nomes (namespace) para dii deve ser declarado na etiqueta DIDL. 

4. O identificador DEVE ESTAR descrito, quando aplicável, como um URI. 

3.4.2.2 Declaração de Item 'modified' (modificado) 

O segundo Descriptor contém uma data de modificação. Quando algo muda dentro de 

um elemento Item, este elemento data de modificação deve ser actualizado. Esta data 

de modificação especifica-se mediante o elemento modified do dcterms: 

 

 

... 

 

 

2006-12-20T10:29:12Z 

 

 

... 

 

... 

 

3.4.2.2.1 Obervações: 

1. Declarar o espaço de nomes dcterms na etiqueta DIDL. 

2. O formato da data é Zulu-time, o que significa que pode ser ordenado como 

texto. 

3. Apenas pode haver um elemento Statement num elemento Descriptor, o que 

significa que dii:identifier e dcterms:modified residem em elementos 

Descriptor independentes. 

35


Versão 1.1.1 

3.4.2.3 Declaração de Item „ObjectType‟ (tipo de objecto) 

O terceiro descriptor contém o tipo de objecto. Este tipo de objecto aparece no 

seguindo nível dos elementos Item. Noutras palavras: apenas se aplica em elementos 

Item “filhos” do primeiro elemento Item. 

Este tipo de objecto especifica-se através do elemento ObjectType do espaço de 

nomes de MPEG-21 Digital Item Processing (DIP) que descreve uma arquitectura 

pertencente à disseminação dos Digital Item Documents (DIDs). 

 

 

... 

 

 

info:eu-repo/semantics/descriptiveMetadata 

 

 

... 

 

... 

 

Na secção 3.4.3 esta declaração ObjectType será descrita de forma mais detalhada. 


1. Declarar o espaço de nomes dip na etiqueta DIDL. 

2. O elemento ObjectType DEVE ESTAR descrito como um URI. 

3. A arquitectura de processamento que se utiliza para a disseminação aplicarse-á 

aos repositórios gerais europeus. O URI será substituído em breve no 

info namespace como info:eu-repo (http://info-uri.info/). Entretanto, utilizase 

como um padrão não oficial no seio da comunidade DRIVER. 

3.4.3 Item composto – representação de trabalho complexo 

O elemento Item de topo contém pelo menos dois tipos de objectos (ObjectTypes) 

obrigatórios do elemento Item. Estes tipos de objectos do Item são expressões do 

Item raiz: um para os metadados e outro para o ficheiro do objecto digital (por 

exemplo, um ficheiro PDF), tal como se descreve nos metadados. 

Opcionalmente, pode existir um terceiro tipo de objecto do elemento Item para uma 

página de transição (jump-off-page): uma página de transição é uma página HTML 

intermédia que se utiliza para apresentações legíveis para o ser humano quando um 

Item contém mais de um ficheiro digital. Normalmente, esta situação ocorre com 

dissertações com ficheiros independentes (ex. quando a tese consiste num 

agrupamento de artigos previamente publicados). Também ocorre quando o 

fornecedor de conteúdo tem uma versão PDF, MS Word DOC e HTML do mesmo 

artigo. 

 

 

... 

... 

... 

 

 

36


Versão 1.1.1 

O primeiro elemento Item contém os metadados como Dublin Core (DC) 

(obrigatório) que é normalmente utilizado no formato OAI_DC de acordo com as 

directrizes de metadados que pertencem a uma arquitectura Digital Item Processing. 

O segundo elemento Item contém uma ou mais ligações para os objectos digitais e o 

terceiro Item contém uma ligação para uma página de transição. 

 

 

 

 


 

 

... 

 

 

 

 

info:eu-repo/semantics/objectFile 

 

 

... 

 

 

 

 

 

info:eu-repo/semantics/humanStartPage 

 

 

... 

 

 

Os URI‟s serão processados sem ter em conta o uso de maiúsculas. Recomenda-se o 

uso da escrita camelCase (maiusculasInterioresSemEspaços). É MUITO importante 

utilizar exactamente a mesma combinação de caracteres, caso contrário, não será 

possível realizar o processamento automático. Para conseguir a máxima clareza, 

utilizam-se os seguintes URI‟s: 

– info:eu-repo/semantics/descriptiveMetadata 

(anteriormente conhecido com o nome de etiqueta „metadata‟ (metadados) no 

projecto DARE) 

(Este Item ocorre uma ou mais vezes) 

– info:eu-repo/semantics/objectFile 

(anteriormente conhecido com o nome de etiqueta „objects‟ (objectos) no 

projecto DARE) 

(Este Item ocorre uma ou mais vezes) 

– info:eu-repo/semantics/humanStartPage 

– (anteriormente conhecido com o nome de etiqueta „jump-off-page‟ (página de 

transição) no projecto DARE) 

(Este Item ocorre zero ou uma vez) 

37


Versão 1.1.1 

– Observações: 

o O espaço de nomes info:eu-repo utiliza-se com a seguinte sintaxe: 

info:eu-repo/_type_/_identifier_ 

como em info:lanl-repo. Para mais informações ver http://infouri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg& 

identifier=info:lanl-repo/ 

o A semântica dos tipos de objecto (ObjectTypes) implica, por exemplo, 

que este Item indique que o primeiro sub-Item tem ou contém 

metadados descritivos. 

3.4.3.1 Item de metadados 

O primeiro elemento Item ObjectType contém os metadados. Os metadados são 

introduzidos num elemento Resource. Cada elemento Component (essencialmente um) 

tem uma etiqueta com o nome do formato de metadados utilizado. De acordo com o 

protocolo OAI é obrigatório utilizar 'oai_dc'. Cada item de metadados pode, 

opcionalmente, ter o seu próprio elemento Identifier e modified num elemento 

Descriptor ao nível do elemento Component: 

 

 

 

 


 

 

1 

 

 

info:doi/10.1705/74836724783 

 

 

2 

 

 

2006-12-20T10:29:12Z 

 

 

 

3 

 

... 

... 

... 

... 

 

 

38


Versão 1.1.1 

 

 


1. (opcional) Inserir apenas um elemento Identifier para o pacote de metadados 

quando também for útil no OAI-PMH. Este conjunto de metadados tem o seu 

próprio identificador, mas NÃO se trata do mesmo identificador que o do 

DIDL. 

2. Se a data dos metadados foi alterada, assegure-se que a data de modificação 

do Item raiz também é modificada. 

3. Declarar o espaço de nomes (namespace) dc na etiqueta de início do elemento 

Resource no qual se utiliza se utiliza Dublin Core. 

3.4.3.2 Item de objecto 

O segundo Item ObjectType contém uma ligação para um objecto digital. Trata-se de 

'by ref', e o elemento Item tem uma declaração ObjectType com um URI info:eurepo/semantics/objectFile 

URI. Um Item ResourceLocation pode ocorrer mais do que 

uma vez. Ver o seguinte: 

 

... 

 

 

 

 


 

 

... 

 

 

 

 

 

 


 

 

... 

 

 

 

39


Versão 1.1.1 

 

 

 


 

 

... 

 

 

 

 

Como se pode verificar no exemplo anterior, as localizações do elemento Resource 

não aparecem em vários componentes dentro de um Item, mas cada localização do 

recurso é introduzida num elemento Item. Isto deve-se ao facto de cada bitstream do 

ficheiro poder ter o seu próprio identificador. 

Nos..., pode-se incluir nas etiquetas Identifier e modified, o que é similar ao 

elemento Item dos metadados. 


1. A ordem dos componentes do objecto deve seguir uma ordem lógica de 

leitura! O Item com o capítulo 1 deve ser seguido do elemento imediato que 

contém o capítulo 2, etc... Deste modo, o fornecedor de serviços poderá 

realizar uma melhor apresentação. Na próxima versão da especificação será 

definido como tornar explícita a ordem mediante a inclusão de números de 

sequência. 

2. Se existem datas de modificação importantes no elemento Resource, propagar 

estas modificações nas datas em sentido ascendente até alcançar o atributo 

DIDLDocumentModified na etiqueta DIDL. 

3. Adicionar identificadores apenas quando exista algum na realidade. 

4. Se não existir nenhum identificador para os elementos Item do tipo de objecto 

(ObjectType), o fornecedor de serviços utilizará o identificador do elemento 

DIDL. 

5. Nos elementos modified ou Identifier, utilizar uma estrutura de elementos 

separada . 

6. A regra geral é que se um bitstream ou um ficheiro dispõe do seu próprio 

identificador, o invólucro (wrapper) será um elemento Item. Para não 

eliminar a possibilidade de um bitstream conter um Identificador, 

utilizaremos o elemento Item como invólucro predefinido da localização do 

recurso. 

3.4.3.3 Item de página de transição (Jump-off-page Item) 

O terceiro elemento ObjectType Item contém uma ligação para uma página de 

transição. Isto é realizado da mesma forma que para o elemento Object Item. 

Actualmente, isto está restringido a 1 Item deste tipo; não existem elementos de data 

identifier ou modification presentes. Este elemento Item é opcional: 

40


Versão 1.1.1 

 

... 

 

 

 

 

 


 

 

 

... 

 

 

 

 

41


Versão 1.1.1 

3.5 Exemplo de um registo OAI-PMH completo (thesis) como 

MPEG-21 DIDL 

Ver a apresentação Web deste registo através da página de transição: 

http://igitur-archive.library.uu.nl/dissertations/2006-1206-200250/UUindex.html 

 

 

2006-12-20T10:29:11Z 

 

http://dspace.library.uu.nl:8080/dspace-oai/request 

 

 

 

 

oai:dspace.library.uu.nl:1874/15290 

2006-12-06T19:00:49Z 

hdl_1874_69 

hdl_1874_12233 

 

 

 

 

 

 

 

 

 

info:doi/10.1705/6748398729821 

 

42


Versão 1.1.1 

 

 

 

2006-12-20T10:29:12Z 

 

 

 

 

 

 


 

 

 

 

 

Neonatal Glucocorticoid Treatment and Predisposition to Cardiovascular Disease 

in Rats 

Bal, M.P. 

Geneeskunde 

glucocorticoid 

dexamethasone 

 

cellular hypertrophy 

contractile proteins 

The present thesis describes the issue of “neonatal glucocorticoid 

treatment and predisposition to cardiovascular disease in rats”. 

Utrecht University 

2006-12-12 

Doctoral thesis 

image/jpeg 

image/pdf 

image/pdf 

 

http://igitur-archive.library.uu.nl/dissertations/2006-1206- 

200250/UUindex.html 

en 

(c) Bal, M.P., 2006 

 

 

 

 

 

 

 

 

 


 

 

 

 

info:doi/10. 1874/15290/18 

 

 

 

 

43


Versão 1.1.1 

2006-12-20T10:29:12Z 

 

 

 

 

 

 

 

 

 

 


 

 

 

 

urn:nbn:nl:ui:10-15290/16 

 

 

 

 

2006-12-20T10:29:12Z 

 

 

 

 

 

 

 

 

 

 


 

 

 

 

urn:nbn:nl:ui:10-15290/15 

 

 

 

 

2006-12-20T10:29:12Z 

 

 

 

 

 

 

 

 

 

 


 

 

 

44


Versão 1.1.1 

 

urn:nbn:nl:ui:10-15290/14 

 

 

 

 

2006-12-20T10:29:12Z 

 

 

 

 

 

 

 

 

 

 

 


 

 

 

 

 

 

 

 

 

 

 

 

45

ANEXOS - DRIVER

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?