5.4.1 EADPART
O esquema de metainforma¸c˜ao descritiva usado no RODA ´e o EAD
[The Library of Congress, 2002b]. Um ficheiro EAD descreve um fundo na sua totalidade, no entanto para a estrutura interna do reposit´orio foi decido usar um modelo de dados que consiste numa ´arvore de Objectos de Des- cri¸c˜ao (OD) em que cada um dos nodos da ´arvore cont´em um componente do EAD, algo que designamos por EADPART (ver figura 16). Um ficheiro EADPART descreve um n´ıvel de descri¸c˜ao, i.e. um fundo, uma s´erie ou um documento simples. Os ficheiros EADPART s˜ao ficheiros XML com uma gram´atica derivada da gram´atica de um EAD. Um ficheiro EADPART para al´em de descrever apenas um n´ıvel de descri¸c˜ao, n˜ao pode conter todos os campos de um ficheiro EAD. Os campos permitidos s˜ao apenas os necess´arios tendo em considera¸c˜ao a natureza dos materiais a descrever (objectos digi- tais). Apresenta-se na tabela 2 uma listagem dos campos permitidos num documento EADPART e as limita¸c˜oes em rela¸c˜ao `a gram´atica oficial do EAD.
Identifica¸c˜ao
<eadpart> @otherlevel Este atributo ´e obrigat´orio e o seu va- lor ´e um dos seguintes F, SF, C, SC, SR, SSR, DC, D
<unitid> @countrycode Este elemento ´e ´unico e obrigat´orio. @repositorycode
<unititle> Pode conter apenas texto.
<unitdate> @normal O elemento n˜ao pode conter texto. O
atributo @normal ´e obrigat´orio. <physdesc>
<dimensions>
@unit Pode conter apenas texto e o atributo
@unit. <physdesc>
<physfacet>
@unit Pode conter apenas texto e o atributo
@unit. <physdesc>
<date>
@normal O atributo @normal ´e obrigat´orio e n˜ao pode conter texto, tal como o elemento <unitdate>.
<physdesc> <extent>
@unit Pode conter apenas texto e o atributo
@unit.
<physdesc> <p> Pode conter apenas texto.
Contexto
<bioghist> <p> Pode conter apenas texto. <bioghist>
<chronlist>
Pode conter v´arios <chronitem>.
<chronitem> Tem que conter um elemento <date>
e um <event> ou <eventgrp>. O <eventgrp> pode conter v´arios ele- mentos <event>.
<custodhist> <p> Pode conter apenas texto.
<acqinfo> <p> Pode conter apenas texto.
Conte´udo Estrutura <scopecontent>
<p>
Pode conter apenas texto.
<appraisal> <p> Pode conter apenas texto.
<accruals> <p> Pode conter apenas texto.
<arrangement> <p>
Pode conter apenas texto. <arrangement>
<table>
Condi¸c˜oes Acesso e Utiliza¸c˜ao <accessrestrict>
<p>
Pode conter apenas texto. <userestrict>
<p>
Pode conter apenas texto.
<langmaterial> Pode conter v´arios elemen-
tos <language>. Os elementos <language> podem conter apenas texto.
<phystech> <p> Pode conter apenas texto.
<materialspec> Pode conter apenas texto.
<physfacet> Pode conter apenas texto (ver em
cima).
<physloc> Pode conter apenas texto.
<daogrp> Pode conter 1 ou mais sub-elementos
<daoloc>. <otherfindaid>
<p>
Pode conter apenas texto. Documenta¸c˜ao Associada
<relatedmaterial> <p>
Pode conter apenas texto. <bibliography>
<p>
Pode conter apenas texto. Notas
<notes> <p> Pode conter apenas texto.
Controlo de Descri¸c˜ao <processinfo>
<p>
Pode conter apenas texto.
<descrules> Este elemento aparece dentro do
elemento <profiledesc> que por sua vez aparece dentro do elemento <eadheader> e este dentro do ele- mento <ead> que n˜ao existe nos nosso <eadpart>. ´E preciso ver se ´e poss´ıvel passar esta informa¸c˜ao para outro ele- mento. Neste momento este elemento n˜ao ´e suportado.
<processinfo> <date>
Pelo schema actual do EAD o ele- mento <processinfo> n˜ao pode conter como ”filho”um elemento <date>. Podemos ter <date> como filho de <p> e este como filho de <processinfo>. Neste momento ´e poss´ıvel ter <processinfo> <p> <date>.
<prefercite> <p> Pode conter apenas texto. Tabela 2: Elementos de um documento EADPART
5.4.2 PREMIS
O PREMIS ´e bastante permissivo em rela¸c˜ao aos valores poss´ıveis para v´arios campos chave, como objectCategory, relationshipType, relationshipSubType, etc. Como estes valores s˜ao essenciais para que seja poss´ıvel validar o PRE- MIS ´e necess´ario definir vocabul´arios controlados para estes campos.
e bitstream para este campo. Esta sugest˜ao ser´a uma obrigatoriedade para o PREMIS do RODA.
relationshipType o PREMIS Data Dictionary sugere structural para re- ferˆencias a partes de um objecto e derivation para referˆencias a ob- jectos do qual este objecto derivou. Mais uma vez estas sugest˜oes ser˜ao obrigatoriedades no RODA.
relationshipSubType PREMIS Data Dictionary sugere v´arios valores, en- tre eles has root, has part. Tal como nos casos anteriores iremos seguir estas sugest˜oes como obrigat´orias. has root ser´a usado para referenciar o ficheiro que ´e o ponto de entrada de uma representa¸c˜ao, caso esta tenha mais do que um ficheiro. has part ser´a usado para referenciar um ficheiro que faz parte de uma representa¸c˜ao, mas n˜ao ´e o ponto de entrada.
eventType o PREMIS Data Dictionary sugere capture, compression, deaccession, decompression, decryption, deletion, digital signature validation, dissemination, fixity check, ingestion, message digest calculation, migration, normalization, replication, validation, virus check. No RODA, e at´e `a data, existem apenas dois eventos: o evento de in- gest˜ao e o de verifica¸c˜ao de integridade; para estes s˜ao usados os termos ingestion e fixity check, respectivamente.