Meta-informação de preservação digital: o caso de estudo da gestão de cursos no arquivo da FEUP

Bruno José Freitas do Rego Meta-informação de Preservação Digital: O caso de estudo da Gestão de Cursos no Arquivo da FEUP Dissertação realizada no âmbito do Mestrado em Ciência da Informação, orientada pela Professora Doutora Maria Cristina de Carvalho Alves Ribeiro Faculdade de Engenharia e Faculdade de Letras Universidade do Porto Julho de 2013 Meta-informação de Preservação Digital: O caso de estudo da Gestão de Cursos no Arquivo da FEUP Bruno José Freitas do Rego Dissertação realizada no âmbito do Mestrado em Ciência da Informação, orientada pela Professora Doutora Maria Cristina de Carvalho Alves Ribeiro Membros do Júri Professor Gabriel de Sousa Torcato David Faculdade de Engenharia - Universidade do Porto Professora Doutora Ana Alice Rodrigues Pereira Baptista Universidade do Minho Professora Doutora Maria Cristina de Carvalho Alves Ribeiro Faculdade de Engenharia - Universidade do Porto ______________________________________________________ 7 Agradecimentos Ao longo do desenvolvimento deste trabalho, muitos foram aqueles que deram um contributo direta ou indiretamente para o poder finalizar. A todas essas pessoas o meu grande obrigado. Mesmo assim gostaria de realçar o esforço e dedicação individual de algumas destas pessoas a seguir: À professora Cristina Ribeiro pela sua disponibilidade, orientação e revisão deste trabalho de dissertação. Foi com um enorme prazer que aceitei o desafio de fazer mais do que um trabalho académico e poder contribuir para melhorar a forma como se preserva a informação do SIGARRA. Ao Jorge Pópulo pelo acolhimento, documentação e entusiasmo pessoal. As conversas que tive ao longo deste estudo permitiram conhecer não só a forma como o Arquivo da FEUP está organizado mas também alcançar os desafios propostos. À Susana Gaio pela disponibilidade e explicações da forma como está desenvolvido a área da Gestão de Cursos no SIGARRA. O modelo de dados fornecido e o entendimento sobre o mesmo permitiu o alinhamento do mesmo com os objectivos para a sua preservação. Aos professores Lucas Soares, Fernanda Martins e Armando Malheiro pela orientação dada durante as aulas de seminário. Permitiram esclarecer muitas dúvidas que tinha e melhorar aspectos científicos deste estudo. A minha família, em especial à Carolina e meu filho Dinis pela compreensão e apoio que tive durante as horas que investi na elaboração deste trabalho de dissertação. 8 9 Resumo Garantir a integridade, autenticidade e o acesso à informação arquivada é um dos grandes desafios da preservação digital. Num ambiente tecnológico e organizacional em permanente mudança é importante desenvolver modelos e métodos que permitam garantir que a informação preservada possa produzir conhecimento de forma uniforme ao longo do tempo. O modelo OAIS e os esquemas de meta-informação Dublin Core, METS e PREMIS são os que neste momento respondem melhor aos desafios na preservação da informação. São estes desafios que atualmente incidem sobre o SIGARRA (sistema de informação que suporta funcionalmente a Universidade do Porto) e para o qual é importante encontrar soluções que permitam preservar de forma eficaz o seu conteúdo informacional. Atualmente a preservação da informação é efectuada através da criação de cópias de segurança dos ficheiros da base de dados do SIGARRA. Devido às preocupações existentes sobre a recuperação da informação arquivada, foi proposto pelo Arquivo da FEUP o desenvolvimento deste estudo com o foco na área da Gestão de Cursos, para analisar a meta-informação e propor melhorias no processo. Chegou-se à conclusão que as cópias de segurança não são apropriadas para preservação devido ao facto de estarem associadas a uma versão específica de um software de base de dados e não terem praticamente nenhuma informação sobre o significado dos dados armazenados. Assim, para se poder consultar a informação arquivada é necessário recriar o ambiente do SIGARRA em termos de software e hardware. Para solucionar este problema é proposto um modelo de preservação de arquivos com base no modelo OAIS e o esquema de meta-informação PREMIS. Para a recepção e envio de arquivos a entidades externas ao Arquivo da FEUP são também utilizados os esquemas de meta-informação Dublin Core e METS. Este modelo assenta num repositório independente com a capacidade de assimilar dados novos e associar informação interpretativa de acordo com o dia de submissão, criando ao mesmo tempo relações contextuais com outros arquivos de forma a espelhar o ambiente organizacional. Para demonstrar a exequibilidade do modelo foi desenvolvida uma prova de conceito que recorre a rotinas para importar e exportar a informação do SIGARRA para um repositório. O repositório é baseado numa estrutura simples de pastas e ficheiros que facilmente podem ser implementados em qualquer sistema operativo. Palavras-chave: Preservação Digital, OAIS, Dublin Core, METS, PREMIS, Gestão de Cursos, SIGARRA, Arquivo da FEUP 16 17 Lista de Abreviaturas e Siglas A3ES Agência de Avaliação e Acreditação do Ensino Superior AIP Archival Information Package (Pacote de Arquivo de Informação) CICA Centro de Informática Prof. Correia Araújo DC Elemento de Metadados do Dublin Core DGES Gabinetes de Acesso ao Ensino Superior DIP Dissemination Information Package (Pacote de Disseminação de Informação) FEUP Faculdade de Engenharia da Universidade do Porto GISA Gestão Integrada de Sistemas de Arquivo ISAD International Standard Archival Description (Norma Geral Internacional de Descrição Arquivística) METS Metadata Encoding and Transmission Standard (Standard de Metadados para Codificação e Transmissão) OAIS Open Archival Information System (Sistema de Informação de Arquivo Aberto) PREMIS PREservation Metadata: Implementation Strategies (Preservação de Metadados: Estratégias de Implementação) SDI Serviço de Documentação e Informação SERAC Serviços Académicos SIGARRA Sistema de Informação para a Gestão Agregada de Recursos e Registos Académicos SIP Submission Information Package (Pacote de Submissão de Informação) U.Porto Universidade do Porto UAS Unidade de Administração de Sistema 18 19 Glossário Acesso: Termos e condições para a disponibilização de conteúdos para uma determinada comunidade ou indivíduos. Arquivo: Entidade organizacional com o objectivo de garantir o acesso e a preservação da informação armazenada. ASCII: American Standard Code for Information Interchange. Conjunto de códigos em 7 bit vulgarmente utilizado para representar letras, dígitos e símbolos. Assinatura Digital: Informação criptográfica associada a objetos digitais por forma a garantirem a autenticidade, confiabilidade ou autoria dos mesmos. Autenticação: Processo responsável por assegurar que um objeto digital é aquilo que se supõe ser. AVI: Audio Video Interleave. Formato digital para representação de imagens em movimento com a possibilidade de ter associado sons. Catalogação: Processo de registo de descrições de documentos de acordo com as normas locais, nacionais e internacionais. Checksum: Código gerado sobre um conjunto de dados para garantir que não foi adulterado. Codec: Dispositivo ou programa de software que codifica e descodifica dados normalmente associados com vídeo ou som. Comunidade: Conjunto uniforme de utilizadores que acede à informação de um repositório. Conversão: Ver Migração. Cópia de Segurança: A cópia da informação que normalmente fica armazenada num local diferente daquele em que está o original, com o objectivo de evitar a perda de informação. Depósito: Recepção de objetos digitais num arquivo para preservação. Depositante: Uma entidade que entrega um objeto digital para depósito no arquivo. Descrição: Um processo que consiste na caracterização dos objetos digitais através da recolha de informações que o permitem distinguir em relação a outros por forma a ser identificável, localizável, gerável e relacionável. Digitalização: Processo responsável por criar objetos digitais a partir de objetos físicos. 20 Direitos de Cópia: Copyright. Um direito legal exclusivo concedido aos criadores de obras para a sua exploração e utilização. Emulador: Software capaz de simular o comportamento de um hardware ou software. Encapsulamento: Preservação juntamente com o objeto digital de informação representativa para permitir que possa ser acedido e compreendido no futuro. Estratégia de preservação digital: Abordagem técnica para garantir o acesso e evitar a perda de informação contida nos objetos digitais. Ficheiro: Objeto digital composto por um identificador e um bitstream. Podem utilizar-se pastas para grupar ficheiros ou outras pastas. Fluxo de Bits: Bitstream. Fluxo contínuo de dados binários. Hardware: Conjunto de elementos físicos reunidos para a visualização, processamento ou armazenamento de informação. Informação de Invariabilidade: Fixity Information. Informação associada a objetos digitais por forma a garantir que não houve alterações ao mesmo. Ingestão: Ingest. Processo responsável pela recepção e introdução de objetos digitais num repositório. Interface: Ponto de compatibilidade entre hardware, software ou utilizador para a transmissão de informação JPEG: Joint Photographic Experts Group. Formato digital para representação de imagens com perda de qualidade face ao original. Linux: Sistema Operativo. Log: Ficheiro com o registo cronológico de eventos referentes à execução de um software Material digital: Conjunto de objetos digitais. Metadados: Ver Meta-informação. Meta-informação: Informação utilizada para descrever um objeto digital por forma a obter o seu significado no futuro. Mídia: hardware com a capacidade de armazenar de informação. Migração: Transferência material digital de um tipo de software ou hardware para outro 21 MP3: Formato de áudio para representar sons ou música digital. Objeto digital: Todo e qualquer objeto de informação representado através de um bitstream. Oracle: Sistema de gestão de base de dados. PDF: Portable Document Format. Formato digital utilizado para representação de documentos de texto ou apresentações. PNG: Portable Network Graphics. Formato digital para representação de imagens sem perda de qualidade face ao original. Preservação digital: Conjunto de atividades responsáveis por garantir o acesso e a longevidade a objetos digitais. Recurso Digital: Informação codificada digitalmente e depositada no arquivo para acesso pelos seus utilizadores. Refrescamento: Cópia de informação de um mídia para outro mídia do mesmo tipo. Repositório digital: Sistema de informação responsável por receber, processar e preservar material digital. Sistema Antigo: Legacy System. Software antigo que ainda continua a ser utilizado mesmo com a presença de um novo com as mesmas funções. Software: Conjunto de instruções direcionadas para o controlo do hardware por forma a efetuar determinadas operações. Tape: Suporte de armazenamento de informação digital baseado em tecnologia magnética. É composto por fitas magnéticas enroladas em cartuchos ou cassetes. Têm elevada capacidade de armazenamento comparativamente aos discos ópticos ou rígido, com tempos de acesso elevados. Validação: Processo de garantia de qualidade com o objectivo de comprovar que os recursos digitais cumprem os requisitos de preservação pretendidos Windows: Sistema Operativo. ZIP: Formato digital para compressão de dados e arquivo. 22 23 Índice de Conteúdo Lista de ilustrações .................................................................................................................... 13 Lista de abreviaturas e siglas .................................................................................................... 17 Glossário .................................................................................................................................... 19 0. Introdução ........................................................................................................................... 27 0.1. Contexto e Definição do Problema ............................................................................... 28 0.2. Objeto de Estudo e Objectivos Gerais .......................................................................... 29 0.3. Abordagens e Metodologias ......................................................................................... 30 1. Preservação em Arquivos Digitais ........................................................................................ 31 1.1. Objeto Digital ................................................................................................................ 31 1.2. Preservação Digital ....................................................................................................... 34 1.2.1. Conceito ................................................................................................................. 34 1.2.2. Preservação a Longo Prazo .................................................................................... 36 1.2.3. Estratégias ............................................................................................................. 39 1.2.4. Autenticidade ........................................................................................................ 43 1.3. Meta-informação .......................................................................................................... 44 1.3.1. Dublin Core ........................................................................................................... 47 1.3.2. METS ..................................................................................................................... 49 1.3.3. PREMIS .................................................................................................................. 51 1.3.4. OAIS ...................................................................................................................... 54 1.4. Projetos de Referência .................................................................................................. 59 1.4.1. Archivematica ........................................................................................................ 59 1.4.2. Carolina Digital Repository ................................................................................... 60 1.4.3. SHAMAN ............................................................................................................... 60 1.4.4. IURIS Digital .......................................................................................................... 61 1.4.5. New Zealand Government Digital Archive ............................................................ 61 1.4.6. FCLA Digital Archive ............................................................................................. 62 1.4.7. Repositório de Objetos Digitais Autênticos (RODA) ............................................ 62 2. Análise Técnica do Objeto de Estudo .................................................................................. 63 2.1. Caracterização Organizacional da U.Porto e FEUP ..................................................... 63 2.2. Caracterização Funcional dos Processos do Arquivo da FEUP .................................... 67 2.3. Caracterização Funcional dos Processos na Gestão de Cursos .................................... 70 2.4. Identificação da meta-informação no Modelo de Dados ............................................. 72 3. Estratégia de Preservação Digital ......................................................................................... 77 3.1. Modelo de preservação ................................................................................................. 78 3.2. Repositório ................................................................................................................... 80 3.3. Armazenamento de Arquivos ........................................................................................ 81 24 3.4. Base de Conhecimento ................................................................................................. 84 3.5. Geração de Pacotes de Submissão ................................................................................ 85 3.5.1. Cabeçalho do METS .............................................................................................. 89 3.5.2. Metadados Descritivos .......................................................................................... 89 3.5.3. Metadados Administrativos .................................................................................. 90 3.5.4. Secção de Ficheiros ............................................................................................... 90 3.5.5. Mapa Estrutural ..................................................................................................... 91 3.5.6. Ligação Estrutural e Secção Comportamental ....................................................... 91 3.6. Processo de Ingestão .................................................................................................... 92 3.6.1. Objeto de Dados .................................................................................................... 95 3.6.2. Informação de Representação ............................................................................... 98 3.6.3. Informação Contextual .......................................................................................... 99 3.6.4. Informação de Autenticidade .............................................................................. 100 3.6.5. Informação sobre Proveniência ........................................................................... 101 3.6.6. Informação Identificativa .................................................................................... 102 3.6.7. Informação sobre AIP ..........................................................................................103 3.7. Acesso ......................................................................................................................... 104 4. Conclusão ........................................................................................................................... 107 4.1. Resultados Obtidos...................................................................................................... 107 4.2. Questões de investigação ............................................................................................ 108 4.3. Desenvolvimentos Futuros ......................................................................................... 109 4.4. Comentário Final ......................................................................................................... 110 Referências Bibliográficas ........................................................................................................ 111 Anexo ....................................................................................................................................... 115 Anexo 1. Ficheiro em XML utilizando Dublin Core Simples ............................................... 117 Anexo 2. Ficheiro em XML utilizando Dublin Core Qualificado ........................................ 119 Anexo 3. Atividades do subprocesso de arquivo "Gerar Documento" ................................ 121 Anexo 4. Atividades do subprocesso de arquivo "Obter Documento" ................................ 123 Anexo 5. Atividades do subprocesso de arquivo "Processar Documento" .......................... 125 Anexo 6. Atividades do subprocesso de arquivo "Manter Documento" .............................. 127 Anexo 7. Fluxo de trabalho para criação de novos cursos ................................................... 129 Anexo 8. Lista descritiva dos campos das tabelas de Cursos .............................................. 133 Anexo 9. Definição da entidade intelectual de um item ...................................................... 143 Anexo 10. Código Perl para gerar SIP’s de Cursos (sipgen.pl) ............................................ 145 Anexo 11. Ficheiro log referente à criação de um SIP ......................................................... 153 Anexo 12. Exemplo de um ficheiro sip.xml ......................................................................... 157 Anexo 13. Código Perl para efetuar a ingestão de SIP’s (ingest.pl) ..................................... 161 Anexo 14. Ficheiro log referente à criação de um AIP ......................................................... 177 25 Anexo 15. Objeto XSD Schema de Representation Information num AIP ........................ 183 Anexo 16. Representation Information num AIP ............................................................... 185 Anexo 17. Context Information num AIP ........................................................................... 201 Anexo 18. Fixity Information num AIP ............................................................................. 203 Anexo 19. Provenance Information num AIP .................................................................... 207 Anexo 20. Reference Information num AIP ....................................................................... 211 Anexo 21. Packaging Information num AIP ....................................................................... 215 Anexo 22. Exemplo de um ficheiro dip.xml ........................................................................ 218 32 existentes entre as linhas das tabelas e a especificidade do seu conteúdo, estas irão gerar objetos digitais em XML para efeitos de preservação. Objetos digitais são inerentemente ilegíveis, pois são codificados de uma forma que exige a mediação da tecnologia para tornar o seu conteúdo de informação acessível. (Parliamentary Archives 2009). A representação da informação do objeto envolve a conversão das sequências de bits em informação significativa. Isto é feito através da descrição do formato ou conceitos na estrutura dos dados, que deve ser aplicado às sequências de bits e que por sua vez resultam em valores mais significativos tais como caracteres, números, matrizes de pixéis, tabelas, etc. Os tipos de dados comuns, as agregações dos tipos de dados e regras de mapeamento (…) são necessários para entender o objeto digital e são referidos como a estrutura informacional do objeto de informação representado. A estrutura da informação é muitas vezes referida como o "formato" do objeto digital (Giaretta 2011). A representação da informação torna-se ainda mais relevante quanto estamos a falar de sistemas de informação proprietários como o SIGARRA, onde o local que melhor traduz o seu significado é nesse mesmo sistema de informação específico. Ao mesmo tempo a evolução desse sistema pode condicionar o acesso ao conteúdo informacional do objeto digital, sendo este um dos desafios na preservação de objetos digitais. Por forma a entender os formatos dos objetos digitais para efeitos de preservação, Giaretta desenvolveu uma extensiva classificação com vários tipos para aquilo que um objeto digital pode ser. Sendo assim, os objetos digitais podem ser classificados como (Giaretta 2011): a) Simples vs. Complexo: É importante fazer esta distinção porque se pode simplificar o desafio de preservação de um objeto complexo em componentes menores, tornando a tarefa de preservação mais simples. Um documento do Word pode ser tratado normalmente como um simples objeto. Na verdade ele é internamente muito complexo, contendo informações sobre estilos e esquema de página, etc. No entanto é normal ignorar isso porque o software que usamos lida com o ficheiro do Word como um todo. b) Renderizados vs. Não-renderizados: Há objetos digitais que normalmente são processados por um software para produzir uma renderização, sendo esta apresentada a um utilizador humano que pode então interpretar o que ele/ela vê/ouve/sente/gosta. Isto pode incluir documentos, imagens, vídeos e sons. Estes são referidos como objetos digitais renderizados. Por outro lado podemos ter um objeto digital que não é necessário renderizar, mas para o qual é necessário saber o significado do conteúdo de modo a ser capaz de continuar a processá-lo. 33 c) Estático vs. Dinâmico: Objetos estáticos são aqueles que a não ser que sejam transformados, são sequências de bits inalteradas. Por outro lado podemos pensar sobre os ficheiros de base de dados que naturalmente mudam ao longo do tempo, quando as entradas são alteradas. Tais objetos digitais referem-se como objetos digitais dinâmicos. d) Ativo vs. Passivo: Um objeto digital ativo faz algo. Por exemplo, a aplicação de processamento de texto ou um software de análise astronómica (…) podem ser objetos digitais a serem preservados. Pretende-se através de objeto digital passivo afirmar sobre a forma como as coisas são feitas, por exemplo, usadas por outras aplicações para fazer alguma coisa. Por exemplo, um ficheiro documental é utilizado por um programa de processamento de texto para imprimir o documento ou exibi-lo no ecrã. e) Múltiplas Classificações: As classificações não são mutuamente exclusivas, e de facto pode-se pensar num objeto simples-renderizado-estático-passivo, sendo uma imagem jpeg um exemplo disso. Também podemos ter um objeto complexo-não-renderizado-dinâmico-ativo como uma base de dados contendo internamente queries que criam novas linhas. O ficheiro executável Word.exe pode ser pensado como um objeto complexo-não-renderizado-estático-ativo. No caso da informação contida na base de dados do SIGARRA, referente à Gestão de Cursos, os objetos podem-se classificar como complexo-não-renderizado-dinâmico-passivo. A informação é naturalmente complexa e necessita da camada de apresentação do SIGARRA para lhe dar significado, estando esta ao mesmo tempo sujeita a alterações constantes. Para efeitos de preservação é relevante neste tipo de objetos torna-los simples e estáticos. Isto pode ser feito através da desagregação do objeto complexo em simples e criar múltiplas imagens ao longo do tempo por forma a espelhar as atualizações informacionais. O objectivo está em ter-se sempre objetos simples-não-renderizado-estático-passivo. Os objetos digitais também podem ser classificados pela forma como foram gerados, os arquivos do parlamento britânico desenvolveram a seguinte classificação (Parliamentary Archives 2009): a) Nascido-Digital: recursos, que foram criados e geridos electronicamente para fins do negócio. b) Criado-Digital: recursos que foram criados de forma não digital mas foram posteriormente convertidos para o formato digital com um dos seguintes fins: a. Negócio b. Preservação c. Acesso 34 c) Recriado: recursos digitais que foram criados digitalmente e são geridos de forma não-digital para fins do negócio (ex.: seguindo uma política "impressão em papel"), mas foram posteriormente re-digitalizados com fins de preservação do negócio ou de acesso. No presente estudo irá trabalhar-se na sua maioria com objetos nascido-digital. Isto acontece porque a informação relativa aos cursos foi inserida diretamente através da plataforma do SIGARRA, que por sua vez é digital. Poderão ocorrer exceções para os ficheiros que são adicionados na plataforma e ai estes podem ser recriados ou nascido-digital. A identificação do conceito e a classificação dos objetos digitais permitem identificar a melhor forma de preservar o conhecimento neles contido. É importante realçar que o objeto digital também é um meio de transporte do conhecimento ao longo do tempo e o objeto digital deve-se adaptar às alterações tecnológicas que vão surgindo por forma a ser interpretado e conceptualizado a qualquer momento pelo ser humano. Tal como nos indica Miguel Ferreira em 2006, do ponto de vista do ser humano o objeto conceptual constitui aquilo que deve ser preservado (Ferreira 2006). 1.2. Preservação Digital No senso comum, o ato de preservar envolve um conjunto de atividades para garantir que um determinado objeto físico permanece inalterado ao longo do tempo. Isso permite que a experimentação obtida com o objeto preservado seja sempre a mesma com o passar dos anos. Quando se trata de um objeto digital, o objectivo é garantir que a percepção do objeto digital permanece uniforme através da camada tecnológica envolvida. É esta tentativa de garantir a uniformidade da experiência humana do objeto digital através da tecnologia e a rápida obsolescência desta que criaram os principais desafios na preservação digital. 1.2.1. Conceito A preservação digital é um processo de gestão ativa pelo qual podemos garantir que um objeto digital seja acessível no futuro. O intervalo de tempo é muito curto e sujeito a uma mudança rápida na tecnologia e sistemas que atuam diretamente sobre nós, sendo também potencialmente vasto dado que não temos ideia até que ponto os outros vão querer continuar a aceder à nossa produção digital do século XXI. Quando acederem é possível que grande parte da infraestrutura técnica que usamos para criar e ler os nossos dados possa estar indisponível (Beagrie, et al. 2008). Segundo Miguel Ferreira, a preservação digital consiste na capacidade de garantir que a informação digital permanece acessível e com qualidades de autenticidade suficientes para 35 que possa ser interpretada no futuro recorrendo a uma plataforma tecnológica diferente da utilizada no momento da sua criação (Ferreira 2006). A preservação digital é definida pelo projeto DigitalPreservationEurope como "um conjunto de atividades necessárias para se certificar que os objetos digitais podem ser localizados, renderizados, utilizados e compreendidos no futuro". A curadoria digital é um termo mais abrangente e frequentemente usado em paralelo com a preservação digital. Este tem uma cobertura mais ampla e envolve "a manutenção, preservação e agregação de valor aos dados digitais em todo o seu ciclo de vida". O desafio-chave na preservação da usabilidade dos objetos digitais ao longo do tempo está na superação da obsolescência da tecnologia (Dobreva e Ruusalepp 2012). Perante a extensão e complexidade na definição de preservação digital, a (Association for Library Collections & Technical Services 2007) apresentou três definições para definir este conceito: a) Definição Curta: A preservação digital combina políticas, estratégias e ações que assegurem o acesso a conteúdos digitais ao longo do tempo. b) Definição Média: A preservação digital combina políticas, estratégias e ações para garantir o acesso a conteúdo reformatado e nascido digital, independentemente dos desafios da falha de mídia e mudança tecnológica. O objectivo da preservação digital é a composição precisa do conteúdo autenticado com o tempo. c) Definição Longa: A preservação digital combina políticas, estratégias e ações para garantir a composição precisa do conteúdo autenticado ao longo do tempo, independentemente dos desafios da falha de mídia e mudança tecnológica. A preservação digital aplica-se tanto ao conteúdo re-digitalizado como ao nascido digital. As políticas de preservação digital documentam o compromisso da organização com a preservação de conteúdo digital para uso futuro, especificação de formatos de ficheiro a serem preservados e o nível de preservação a ser fornecido, bem como assegurar o cumprimento das normas e melhores práticas para a gestão responsável da informação digital. Apesar de cada autor ter uma definição própria da preservação digital, não existe uma grande divergência entre elas. O principal foco está na tecnologia mas é igualmente relevante que haja uma organização humana, de forma permanente, que garanta a preservação dos conteúdos digitais no suporte tecnológico. Essa preservação deve ter em conta o acesso permanente à informação e garantir a qualidade e autenticidade ao longo do tempo. 36 1.2.2. Preservação a Longo Prazo A importância de manter os objetos digitais é bem compreendida. O hardware e obsolescência da mídia, a falta de suporte em formatos de computador mais antigos, erro humano, software malicioso; tudo isto pode levar à perda de objetos digitais. A preservação no entanto não está preocupada apenas com a manutenção simples de objetos digitais. Para serem utilizados de forma significativa no futuro, os objetos digitais devem ser preservados num contexto que a torna compreensível para os futuros utilizadores. Diz-se frequentemente que a preservação digital é a interoperabilidade com o tempo, no entanto esta formulação tem um elemento de especulação. Não podemos estar conscientes do futuro hardware, software e modalidades de negócios quando a tarefa de preservação a longo prazo tem por definição a incerteza dentro dela (Dobreva e Ruusalepp 2012). Podemos assim aferir que a preservação não é uma ciência exata, apenas probabilística. A empresa de conteúdo de informação Corbus teve uma taxa de perda de 150 de 1 milhão de imagens em sistemas de armazenamento em 1999. Quais serão as taxas máximas de perda aceitável? Métricas quantitativas devem incluir uma análise de custo/benefício (Chen 2001). Podemos olhar por analogia ao mesmo efeito no papel, onde mesmo em ambientes com as condições ideais existe sempre uma potencial perda e normalmente a percentagem de perda é inversamente proporcional ao investimento efectuado. Sendo assim é expectável que no caso da informação preservada do SIGARRA haja igualmente perdas. A este conjunto de problemas que pode gerar perdas, Clay Shirky rotulou de "playback drift" que é a tendência de um conjunto de dados binários fixo poder parar de funcionar ou ser interpretado da forma inesperada devido ao complexo ecossistema de aplicações, sistemas operativos e mudanças de hardware; mesmo que os dados tenham sido perfeitamente armazenados ao longo de décadas. Com efeito, a melhor preservação do bit a longo prazo torna maior o perigo de Playback Drift (Shirky 2005). Dos vários problemas encontrados, Giaretta fez um estudo sobre os principais riscos para a preservação digital através de 1190 correspondentes, apresentando-os no seguinte gráfico. Ilustração 2: Principais riscos à preservação digital (Giaretta 2011) 0% 20% 40% 60% 80% 100% Instabilidade Política Outros Não sabe Desastres naturais Continuidade da organização Falta de fundos estruturais Erros humanos 37 Por forma a fazer face às perdas de informação, a empresa Tessela Technology & Consulting identificou um conjunto desafios de acesso a longo prazo à informação, para os quais neste momento as organizações estão lentamente a dar atenção. Os desafios chave são os seguintes (Tessella 2010): a) Obsolescência do Mídia: A informação é mantida em postos locais sem gestão (ex.: portáteis, discos ópticos, servidores de ficheiros locais) ou postos centrais onde o seu valor não é reconhecido (servidores de ficheiros centrais, tapes de backup). Em cada caso os dados podem ser perdidos por causa da mídia que é utilizada para armazenar quando esta se torna ilegível ou é substituída. b) Distribuição e Organização de Dados Desarticulada: O facto de não existir um registo sobre a localização e o valor da informação armazenada torna muito difícil a sua descoberta e utilização. Este desafio é agravado pela informação armazenada em diversos sistemas de TI através de várias organizações. c) Obsolescência do Formato de Ficheiro: Este desafio é uma criação da era digital, onde a informação importante é guardada em ficheiros que podem não ser interpretados pelo software futuro. Como a informação se torna mais complexa e integrada, esta ameaça tem tendência a aumentar. Alguns desafios descritos pela Tessela Technology & Consulting podem ainda ser agravados devido a natureza efémera da informação digital, sendo um problema focado por Adrienne Muir “A informação pode mudar ou desaparecer antes de ser capturada e conservada. A informação é disseminada em novas formas e modelos de negócios que também estão mudando. Cada vez mais a informação deixa de ser comprada mas alugada por meio do acesso licenciado em vez de posse física de um artefacto informacional” (Muir 2004). O facto de o SIGARRA ser um sistema permanentemente acessível e alterável, se no intervalo temporal para arquivo da informação tiverem ocorrido diversas atualizações num dado registo, essas alterações ficarão perdidas pois só fica visível a última. É relevante nestes casos definir uma política sobre o que é relevante preservar para acesso futuro. A criação de repositórios digitais é uma forma de responder às preocupações definidas anteriormente. Repositórios digitais são sistemas de computador que ingerem, armazenam, gerem, preservam e fornecem acesso ao conteúdo digital a longo prazo. Isto obriga a ir além do simples arquivo ou preservação de bitstream. Eles devem concentrar-se em preservar a informação e não apenas a representação baseada no ficheiro corrente desta informação. É o conteúdo de informação real de um documento, conjunto de dados, som ou gravação de vídeo 38 que deve ser preservado, não o arquivo do Microsoft Word, a folha de Excel, ou o filme em QuickTime (Dappert e Enders 2010). Valdo Pasqui identificou um conjunto mínimo de propriedades que um repositório digital deve ter para ser confiável (Pasqui 2007): a) Autenticidade: É a certeza de que um ativo digital foi criado pelo indivíduo que afirma tê-lo criado. Autenticidade proporciona a certeza de que o criador de um ativo digital, não pode negar que é o criador. Assinaturas digitais e marcas d'água digitais são técnicas que garantam a autenticidade dos objetos digitais. b) Integridade: A capacidade de manter a exatidão e a integridade dos dados, evitando alterações maliciosas ou acidentais (ex.: a corrupção de dados). Gerando e guardando um checksum do bit/byte utilizando como exemplo o MD5, é uma técnica básica para detectar se qualquer modificação afectou um objeto digital após o seu depósito inicial no arquivo. c) Fiabilidade e Disponibilidade: Fiabilidade refere-se à capacidade dos componentes de hardware e software para executarem de acordo com a sua especificação, livre de erros ou bugs (totalmente em teoria e na prática assegurando uma elevada percentagem). Disponibilidade é a percentagem de tempo que um sistema, aplicação ou componente está regularmente a funcionar em função do tempo total em que é necessário funcionar. Cópias de segurança, software de antivírus, firewalls, patches do sistema operativo, atualizações de software aplicacionais, componentes de hardware redundantes e tolerantes a falhas são algumas das técnicas mais comuns utilizadas para garantir percentagens de alto nível de fiabilidade e disponibilidade. d) Capacidade para reutilização: A capacidade de aceder a um recurso digital enquanto a instituição/arquivo decidir suportar. Ativos digitais com valor duradouro devem ser devidamente recuperados e reutilizados, mesmo que por um período de tempo longo (ex.: identificadores persistentes e manutenção de mídia e formatos). Com a utilização de repositórios digitais, abre-se a possibilidade de utilizar outros processos para aumentar as garantias de preservação do conteúdo informacional a longo prazo. Um desses processos é o da curadoria digital. Tal como indica Giaretta, a Curadoria Digital envolve a manutenção, preservação e agregação de valor aos dados da investigação digital em todo seu ciclo de vida (Giaretta 2011). Muita da informação obtida referente aos dados do SIGARRA está intimamente ligada à forma como são disponibilizados na camada de apresentação. Sendo assim, é relevante para preservação a longo prazo enriquecer esses dados com informação anexa, a explicar a forma como eram processados ou visualizados na 39 altura de arquivo. Desta forma, deve-se preservar tudo o que seja relevante para perceber o significado e que tenha influência nas tomadas de decisão. A preservação digital a longo prazo é assim um conjunto de processos, estratégias e ferramentas utilizadas para armazenar e aceder a dados digitais por longos períodos de tempo; durante o qual as tecnologias, formatos, hardware, software e comunidades técnicas têm probabilidade de mudar. O problema da preservação digital a longo prazo inclui aspectos de preservação do bit e preservação lógica. Preservação de bits é a capacidade de repor os bits de um objeto de dados, onde existe degradação dos meios de armazenamento, obsolescência do hardware e/ou catástrofes. Preservação lógica implica a preservação do conteúdo intelectual dos dados face a futuras mudanças tecnológicas e do conhecimento. A preservação lógica ainda é uma área de pesquisa em aberto que apresenta um grande desafio, pois precisa de permitir a interpretação futura dos dados preservados por parte dos consumidores, que podem utilizar tecnologias atualmente desconhecidas e obter uma base de conhecimento diferente dos produtores de dados (Reshef, et al. 2009). 1.2.3. Estratégias Uma estratégia para a preservação digital implica preservar a informação digital no formato digital mais simples possível, de modo a minimizar os requisitos de software de recuperação específicos e para evitar problemas de obsolescência de software. A informação digital deve ser transferida através de sucessivas gerações de tecnologia num formato "independente de software", como arquivos de texto ASCII ou em arquivos simples com estruturas simples e uniformes (Hedstrom 1998). As estratégias são normalmente aplicadas quando um formato digital chega a um ponto de ruptura, podendo correr o risco de não ser interpretado, nesta fase têm de se desenvolver ações para garantir o acesso à informação. Essas ações devem estar definidas dentro de um plano que por sua vez é composto por um conjunto de métodos, sendo estes executadas sobre os objetos digitais. A estratégia a ser definida deve ser aplicada a todos os objetos do mesmo tipo ou categoria por forma a evitar conflitos no acesso posterior à informação. A estratégia adoptada deve sempre garantir a qualquer momento a autenticidade e a integridade do conteúdo dos objetos digitais para que o entendimento e o significado dos mesmos não mudem. Miguel Ferreira identificou oito ações estratégicas, apresentadas na Ilustração 3, por forma a garantir o aceso contínuo à informação e a evitar a perda da mesma. 40 Ilustração 3: Classificação das estratégias de preservação digital (Ferreira 2006) A migração é definida no relatório CPA/RLG como um conjunto de tarefas organizadas, concebidas para conseguir a transferência periódica de material digital a partir de uma configuração de hardware/software para o outro, ou de uma geração de tecnologia de computador para uma geração seguinte (Bide, Potter e Watkinson 1999). Permite transferir informação de uma plataforma para outra, adaptando os recursos digitais ao ambiente de chegada quando o software e/ou hardware se tornam obsoletos ou ainda antes de isso acontecer (Proença e Lopes 2004). Usando a terminologia OAIS, a migração é precisamente transformação e envolve mudar as sequências de bits do original para outro. O OAIS reconhece que se essa transformação é reversível, então pode-se ter certeza de que nenhuma informação foi perdida. Por outro lado, transformações não reversíveis irão provavelmente perder informação e alguém tem que assumir a responsabilidade de confirmar que a transformação mantém de forma adequada a informação "importante" (Giaretta 2011). Ao contrário da migração, a encapsulação permite manter o formato original do recurso digital, contudo este deve fazer-se acompanhar por um conjunto de instruções que permitam interpretar os formatos do ficheiro e o conteúdo da informação (Proença e Lopes 2004). Um pacote de informação, conforme definido pelo modelo OAIS, representa uma forma de encapsulamento em que o objeto digital é embalado juntamente com a representação da informação necessária para interpretar os bits apropriados para o acesso e a preservação da informação descritiva que inclui informações sobre o contexto, proveniência, referência e invariabilidade (Paradigm 2008). Emulação é uma abordagem que mantém a fonte de objetos digital no seu formato de dados original, mas recria alguns ou todos os processos (ex.: a configuração do hardware ou aplicações de software, tais como sistemas de funcionamento), permitindo ser recriado em 41 computadores atuais. Um exemplo de emulação é escrever um programa para um sistema operacional de Macintosh para rodar em um sistema operacional Linux (Davis e Wilson 2002). A atração deste método de preservação está pelo menos em parte, na perspectiva de oferecer a manutenção do "look and feel" - em teoria, pelo menos, a funcionalidade completa do recurso (Bide, Potter e Watkinson 1999). Nem sempre é possível a sua utilização, por exemplo ao nível do software é difícil descrever aplicações para que posteriormente se proceda à sua reprodução e este problema acentua-se ainda mais quando se trata de multimédia e hipermédia (Proença e Lopes 2004). Uma outra variação de emulação que tem sido amplamente discutido na comunidade de preservação digital é a baseada no conceito de uma máquina virtual. Considerando um emulador tradicional que imita uma máquina antiga que realmente existiu, uma máquina virtual emula um computador que nunca tenha realmente existido como hardware. Programas são escritos para executar na máquina virtual em vez de um computador específico, se a máquina virtual for implementada em diferentes computadores, os programas escritos para a máquina virtual pode ser executados em qualquer um desses computadores (Paradigm 2008). No refrescamento um recurso de dados completo é simplesmente copiado de um meio físico para outro. Esta é uma solução de curto prazo, quando é simplesmente o meio (como o CD) e não o hardware ou o software como tendo probabilidade em falhar (Bide, Potter e Watkinson 1999). A frequente verificação da integridade dos suportes físicos, assim como o seu refrescamento periódico, são consideradas atividades vitais num contexto de preservação digital (Ferreira 2006). Na preservação de tecnologia é necessário que quer o software, quer o hardware se mantenham em condições que permitam consultar a informação aí guardada. Trata-se de uma estratégia dispendiosa e complexa a nível tecnológico. Encontra-se em declínio apesar de ser utilizada ainda por algumas empresas (Proença e Lopes 2004). O povo egípcio deixou uma infindável quantidade de vestígios da sua presença na Terra. No entanto, só a partir do século XIX foi possível decifrar os seus escritos hieroglíficos. Tudo aconteceu em 1799 quando um grupo de soldados franceses descobriu no delta do Nilo um bloco de granito que ficou conhecido como a Pedra de Rosetta. Nele encontrava-se escrito em três línguas distintas (egípcio hieroglífico, egípcio cursivo e grego clássico) um decreto emitido em 196 a.C. por Ptolomeu V Epifânio. Heminger e Robertson propõem a utilização de uma estratégia semelhante para recuperar objetos digitais para os quais não existe informação suficiente sobre o seu formato. Nesta estratégia, em vez de se preservar as regras que permitem descodificar o objeto digital, são reunidas amostras de objetos que sejam representativas do formato que se pretende recuperar (Ferreira 2006). 48 O Dublin Core simples “Dublin Core Metadata Element Set (DCMES)” consiste em quinze elementos de metadados (Dublin Core Metadata Initiative 2012): a) Título b) Criador c) Sujeito d) Descrição e) Editor f) Contribuidor g) Data h) Tipo i) Formato j) Identificador k) Fonte l) Linguagem m) Relação n) Cobertura o) Direitos Os elementos de metadados do Dublin Core simples podem ser utilizados dentro de ficheiros ou em colunas de tabelas de bases de dados. No Anexo 1 está um exemplo de um ficheiro que utiliza a linguagem XML para definir meta-informação. Devido à sua simplicidade, o Dublin Core simples será utilizado para descrever todos os ficheiros que são enviados do SIGARRA para serem arquivados e para todos os pedidos de recuperação ou consulta de informação do repositório de arquivo. Após a especificação do Dublin Core simples houve um esforço para refinar e estender o mesmo, surgindo o Dublin Core Qualificado. O Dublin Core Qualificado utiliza dois tipos de classes de qualificadores (Dublin Core Metadata Initiative 2012): a) Refinação do elemento: Estes qualificadores tornam o significado do elemento mais estreito ou mais específico. Um elemento refinado partilha do significado do elemento não qualificado mas com um foco mais restrito. b) Esquema de codificação: Estes qualificadores identificam os esquemas que ajudam na interpretação do valor do elemento. Estes esquemas incluem um vocabulário controlado e notações formais ou regras de separação. Um valor expresso utilizando um esquema de codificação, será sempre um símbolo selecionado de um vocabulário controlado. 49 O Dublin Core Qualificado também pode ser utilizado através de uma estrutura em XML, tal como é apresentado no Anexo 2. Este esquema não será utilizado na estratégia para preservação devido ao facto de serem utilizados os esquemas METS e o PREMIS que para além de terem conflito com alguns elementos, conseguem preencher outros requisitos. Um exemplo disto são as relações entre objetos e propriedades de objetos, no qual o PREMIS não só consegue efetuar tudo o que o Dublin Core Qualificado faz mas também permite definir outras relações semânticas relacionadas com agentes e eventos que este não permite. Assim, em vez de se utilizar dois esquemas para os mesmos dados, só é necessário um, simplificando a preservação. 1.3.2. METS O METS (Metadata Encoding and Transmission Standard) é uma especificação para troca e armazenamento de metadados, independente das necessidades específicas do projeto (Dappert e Enders 2010). Fornece um formato de documento baseado em XML para codificação de metadados na gestão e troca de objetos de bibliotecas digitais. A iniciativa adaptou a definição de um documento XML desenvolvido por MOA2 para criar um XML schema (The Cedars Project 2002). É projetado com a finalidade de criar instâncias de documentos XML que expressem uma estrutura hierárquica dos objetos digitais da biblioteca, os nomes e as localizações dos arquivos que compõem os objetos digitais e os metadados associados à descrição e administração (Cundiff 2004). Ilustração 4: A arquitetura do METS (Dappert e Enders 2010) 50 Tal como é apresentado na Ilustração 4, um documento METS pode ter até sete subsecções principais (Cundiff 2004): a) um cabeçalho METS (metsHdr) b) uma secção de metadados descritivos (dmdSec) c) uma secção de metadados administrativos (amdSec) d) uma secção de ficheiro (fileSec) e) um mapa estrutural (structMap) f) links estruturais (structLink) g) uma secção de comportamento (behaviorSec) A única secção obrigatória em METS é a secção structMap. Os objetos digitais podem ser descritos a partir de perspectivas diferentes, resultando em seções structMap diferentes. A perspectiva física pode descrever páginas, colunas, as áreas de texto e a sua disposição relativamente um ao outro. A perspectiva lógica pode descrever sequências, como a sequência de músicas em um CD, ou de contenção, como a contenção de um capítulo de um livro. Estas perspectivas são capturadas em diferentes estruturas de árvores hierárquicas. Objetos em secções structMap podem estar ligados uns aos outros. Eles também podem ser ligados à secção de ficheiro que descreva os ficheiros correspondentes. Ficheiros na secção de ficheiros podem ser organizados em um ou mais grupos de ficheiros. Os ficheiros podem ser agrupados de acordo com as necessidades do utilizador, por exemplo, formato de ficheiro, resolução de imagem, ou a utilização prevista para o arquivo (preservação cópia, cópia de acesso, miniaturas, etc.) Cada objeto definido na secção structMap, bem como todos os ficheiros, podem ter metadados descritivos ou administrativos (dividido pela fonte de proveniência, e técnico ou metadados direitos dentro METS) descrevendo-os fora do structMap ou secção de ficheiro. Mesmo que o METS aprove o uso de esquemas de extensão específicos, suporta todo o tipo de XML bem formado nessas seções. O METS usa o mecanismo de ligação ID XML / IDREF para fixar a secção de metadados ao objeto (Dappert e Enders 2010). O METS será o esquema de meta-informação base para suportar a submissão de arquivos do SIGARRA para o Arquivo e do Arquivo para outras entidades. A simplicidade e a capacidade de incorporar outros esquemas tornam-no ideal na transmissão de dados a organizações que não partilham do mesmo sistema de informação. Devido à probabilidade de existirem alterações nos dados durante a transmissão, este esquema também suporta chaves de hash para garantir a autenticidade dos dados. 51 1.3.3. PREMIS PREMIS (PREservation Metadata: Implementation Strategies) é uma tentativa de especificar as unidades semânticas necessárias para suportar funções de preservação centrais. A preservação de metadados é importante para uma gama ampla de sistemas e contextos de preservação digital, sendo o que "a maioria dos repositórios de preservação tendem a saber" para preservar material digital a longo prazo. Isto inclui metadados administrativos mas também metadados técnicos genéricos que são compartilhados por todos os tipos de conteúdo. Ele permite a especificação das relações estruturais que são relevantes para as funções de preservação, mas também permite aos utilizadores escolher em vez de isso as relações estruturais oferecidas pelas especificações dos seus metadados especificações (Dappert e Enders 2010). O PREMIS define metadados de preservação como "as informações que um repositório usa para apoiar o processo(s) de preservação digital" que são necessários para assegurar que um objeto digital permanece viável, renderizável, compreensível, autêntico e identificável (Gewirtz, et al. 2006). Ilustração 5: Modelo de Dados do PREMIS (PREMIS Committee 2008) O PREMIS define um modelo de dados comum para incentivar uma forma compartilhada de pensar e de organizar metadados de preservação (Dappert e Enders 2010). O PREMIS descreve cinco elementos associados com os processos de preservação digital (PREMIS Committee 2008): a) Intellectual entity: um conjunto de conteúdo que para efeitos de gestão intelectual e descrição é considerado como uma única unidade: ex.: um determinado livro, mapa, fotografia, base de dados, etc. Uma Intellectual entity pode incluir outras Intellectual entity, ex.: um site pode incluir uma página Web, uma página da Web pode incluir uma imagem. Uma entidade intelectual pode ter um ou mais representações digitais b) Objects: uma unidade discreta de informação na forma digital. A entidade Object tem três subtipos: 52 a. File: é uma sequência ordenada de bytes que é conhecida por um sistema operativo através de um nome. Um ficheiro pode ter zero ou mais bytes e tem um formato de ficheiro, permissões de acesso e características do sistema de ficheiros como tamanho e data da última modificação b. Bitstream: são dados contíguos ou não contíguos dentro de um ficheiro que tem propriedades com significado comum para fins de preservação. Um fluxo de bits não pode ser transformado num ficheiro independente sem a adição de uma estrutura de ficheiro (cabeçalhos, etc.) e/ou reformatar o bitstream para cumprir com algum formato de ficheiro específico c. Representation: é o conjunto de ficheiros, incluindo metadados estruturais necessários para uma completa e interpretação razoável de uma Intellectual entity. Por exemplo, um artigo de jornal pode ser completa num arquivo PDF, este único ficheiro constitui a Representation. Outro artigo de jornal pode consistir num ficheiro SGML e dois ficheiros de imagem, estes três ficheiros constituem a Representation. c) Events: uma ação que envolve ou afecta pelo menos um Object ou Agent associado ou conhecido pelo repositório de preservação d) Agents: organização, pessoa ou programas de software/sistema associado com Events da vida de um Object, ou com os Rights (direitos) ligados a um Object e) Rights: afirmações de um ou mais direitos ou permissões referentes a um Object e/ou Agent O Dicionário de Dados do PREMIS define unidades semânticas e não elementos de metadados. A distinção é subtil mas importante. A unidade semântica é uma peça de informação ou conhecimento. Um elemento de metadados é uma forma definida de representar essas informações num registo de metadados, esquema ou base de dados. O PREMIS não especifica a forma como os metadados devem ser representados em qualquer sistema, ele só define o que o sistema precisa de conhecer e deve ser capaz de exportar para outros sistemas. Então, para se ser um purista PREMIS é necessário pensar em termos de unidades semânticas bastante abstractas. As unidades semânticas do PREMIS têm um mapeamento direto para os elementos de metadados definidos no PREMIS XML schema e pode ter um mapeamento menos direta com metadados noutros schema. Os nomes das unidades semânticas PREMIS são palavras em "camel case". Isto é, as palavras não são separadas por espaços mas por letras maiúsculas: objectIdentifier, relatedEventIdentification (Caplan 2009). 53 O Dicionário de Dados baseia-se no Sistema de Informação de Arquivo Aberto (OAIS). O modelo OAIS fornece uma base conceptual através de uma taxonomia de objetos de informação e pacotes de objetos arquivados, e a estrutura dos seus metadados associados. O PREMIS framework pode ser visto como a elaboração de um modelo de informação OAIS, explicada por meio do mapeamento de metadados de preservação numa estrutura conceptual. O PREMIS e OAIS usam terminologia diferente. As diferenças geralmente refletem o fato das unidades semânticas do PREMIS exigirem mais especificidade que as definições OAIS, o que é de se esperar quando se deslocam de uma framework conceitual para uma implementação (Gewirtz, et al. 2006). Ilustração 6: Unidade semântica do PREMIS (Dappert e Enders 2010) Este Dicionário de Dados contém uma secção sobre o que significa para um repositório estar em conformidade com o PREMIS. Essencialmente existem três requisitos (Caplan 2009): a) Se o repositório implementa (guarda ou exporta) um elemento de dados que pretende ser uma unidade semântica do PREMIS, o elemento de dados deve ter a mesma definição, limitações de dados e aplicabilidade tal como é definido na unidade semântica PREMIS b) Se o repositório implementa uma unidade semântica PREMIS, se a repete e a obrigação deve ser mais rigorosa mas não mais liberal do que o PREMIS requer. Isto é, uma unidade repetitiva semântica pode ser implementada como não repetível mas não o inverso e um elemento obrigatório não pode ser feito opcional 54 c) Se o repositório exporta informações para uso de outro repositório, ele deve fornecer valores para todas as unidades semânticas que são obrigatórias no Dicionário de Dados. Existe alguma flexibilidade no presente pois para os repositórios não é requerido suportar obrigatoriamente as unidades semânticas para os tipos de entidades que não suportam. Por outras palavras, um repositório é livre para apoiar ou não agentes PREMIS, mas se utilizar então o agentIdentifier é obrigatório. Da mesma forma, um determinado repositório pode não suportar objetos bitstream, por isso não tem de fornecer o identificador de bitstream obrigatório. O PREMIS é um modelo semântico cada vez mais referenciado pela comunidade científica, não só pelo apoio e estandardização que está a ter mas também pela integração que tem com o modelo de dados do OAIS. Este modelo cria uma nova camada informacional sobre o repositório que permite fornecer conhecimento sobre o mesmo. É este esquema que irá estar na base do repositório para o modelo de preservação definido neste estudo e irá interligar com tudo resto. 1.3.4. OAIS O Modelo de Referência OAIS define o Open Archival Information System (OAIS), como "um arquivo, consistindo na organização de pessoas e sistemas, que tem a responsabilidade de preservar informação e torná-lo disponível para uma Comunidade Designada". Este modelo fornece uma especificação funcional completa e as informações de um repositório e "estabelece as responsabilidades obrigatórias que uma organização deve descarregar a fim de operar um arquivo OAIS" (Pasqui 2007). Este modelo define uma framework com um vocabulário comum e fornece um modelo funcional e informacional para a preservação na comunidade, mas não define qual os metadados específicos que devem ser recolhidos ou como devem ser implementados de forma a apoiar as metas de preservação (Dappert e Enders 2010). Segundo Giaretta, o modelo de referência OAIS fornece (Giaretta 2011): a) uma estrutura para a compreensão e uma maior sensibilização dos conceitos de arquivo necessárias para preservação da informação digital a longo prazo e acesso b) os conceitos necessários para organizações que não sejam de arquivo para serem participantes efetivos no processo de preservação c) uma estrutura, incluindo a terminologia e conceitos para descrever e comparar arquiteturas e operações em arquivos existentes e futuros d) uma estrutura para descrever e comparar diferentes estratégias de preservação a longo prazo e técnicas 55 e) uma base para comparar os modelos de dados de informação digital preservada pelos arquivos e discutir como os modelos de dados e as informações de base podem mudar ao longo do tempo f) uma estrutura que pode ser expandida por outros esforços para cobrir a preservação a longo prazo da informação que não está em formato digital (ex.: meios físicos e amostras físicas) g) expande o consenso sobre os elementos e processos para a preservação da informação digital a longo prazo e acesso, e promove um mercado maior que os vendedores podem suportar h) guia a identificação e produção de standards OAIS relacionados Ilustração 7: Modelo Open Archival Information System (OAIS) (Ferreira 2006) A entidade de Ingestão (Ingest) fornece serviços e funções para aceitar Submission Information Packages (SIP’s) dos Produtores (ou de elementos internos sob controle da Administração) e preparar o conteúdo para o armazenamento e gestão dentro do arquivo. As funções de Ingestão incluem receber os SIP’s, garantir a qualidade dos SIP’s e gerar o Archival Information Package (AIP) em conformidade com a formatação de dados do arquivo e padrões de documentação, extraindo a informação descritiva dos AIP’s para a inclusão na base de dados do arquivo e coordenar atualizações para a Gestão de Dados e Armazenamento do Arquivo (Giaretta 2011). Na entidade de Repositório de Dados (Archival Storage) fornece-se serviços e funções para o armazenamento, manutenção e recuperação da AIP. Funções de armazenamento do 56 repositório incluem o receber o AIP da Ingestão e adicioná-los para o armazenamento permanente, gestão da hierarquia do repositório, refrescamento do mídia onde os dados estão armazenados, realização rotineira de verificação de erros, providenciar capacidades de recuperação de desastres e fornecendo acesso ao AIP para cumprir pedidos (Giaretta 2011). A entidade de Gestão de Dados (Data Management) fornece serviços e funções para preencher, manter e aceder tanto à informação descritiva que identifica e documenta localizações no repositório, e dados administrativos utilizados para gerir o repositório. Funções de gestão de dados incluem a administração das funções de base de dados do repositório (esquema de manutenção, definições de visualização e integridade das referências), realizando atualizações da base de dados (carregamento de nova informação descritiva ou dados administrativos do repositório), realizar consultas sobre os dados, da gestão de dados para gerar respostas a consultas e produção de relatórios das respostas a consultas (Giaretta 2011). A entidade de Administração (Administration) fornece serviços e funções para o funcionamento geral do sistema de arquivo. Funções de administração incluem a solicitação e negociação de acordos de submissão com Produtores, auditorias para assegurar que eles cumprem as normas do repositório, e manter a gestão da configuração de sistema do hardware e software. Ele fornece também funções de engenharia de sistemas para monitorizar e melhorar as operações de arquivo, inventário, informar e migrar/atualizar o conteúdo do repositório. Também é responsável por estabelecer e manter standards e políticas do repositório, fornecendo suporte ao cliente e ativar pedidos armazenados (Giaretta 2011). A entidade de Planeamento e de Preservação (Preservation Planning) fornece serviços e funções para monitorizar o ambiente OAIS, apresentando recomendações e planos de preservação para garantir que a informação armazenada no OAIS permanece acessível e compreensível pela comunidade designada a longo prazo, mesmo que o ambiente de computação original se torne obsoleto. Funções de planeamento de preservação incluem avaliar o conteúdo do repositório e periodicamente recomendando atualizações de informações de repositório, migração de ficheiros do repositório atual, desenvolvimento de recomendações para as normas e políticas do repositório, fornecer relatórios de análise periódica de risco e monitorizar as mudanças no ambiente tecnológico e exigências de serviços na comunidade designada e base de conhecimento. Planeamento de preservação também desenha modelos de pacotes de informação e fornece assistência no desenho e revisão para especializar os modelos em SIP’s e AIP’s para submissões específicas. O planeamento de preservação também desenvolve planos de migração detalhados, protótipos 57 de software e planos de teste para permitir a implementação de metas de migração da Administração (Giaretta 2011). A entidade de Acesso (Access) fornece serviços e funções que suportam os consumidores na determinação da existência, descrição, localização e disponibilidade da informação armazenada no OAIS, e permitindo aos consumidores solicitar e receber produtos de informação. Funções de acesso incluem comunicação com os consumidores para receber pedidos, aplicando controlos para limitar o acesso à informação especialmente protegida, coordenando a execução de pedidos para a conclusão bem-sucedida, gerando respostas (Dissemination Information Package, respostas a consultas, relatórios) e entregar as respostas para os consumidores (Giaretta 2011). No presente estudo, para o modelo de preservação serão focadas principalmente as entidades de Ingestão, Repositório de Dados, Acesso. De forma complementar serão apresentadas algumas informações nas áreas de Planeamento e Preservação, e Gestão de Dados. A partir do modelo de referência descrito na ilustração 8, o OAIS descreve um modelo de informação do objeto informacional composto pelos dados e metadados a preservar. Este modelo de informação foi descrito pelo OCLC/RLG Working Group em 2002. Ilustração 8: Modelo de Informação do OAIS (OCLC/RLG Working Group 2002) No contexto do OAIS a informação pode existir em duas formas: como um Physical Object (por exemplo, um documento em papel, uma amostra de solo) ou como um Digital 64 Faculdade de Engenharia aprovasse os seus primeiros estatutos onde foi fixada a sua autonomia administrativa, financeira e pedagógica (FEUP 2012). A Universidade do Porto tem como órgão superior e executivo a Reitoria, sendo à data o Reitor Professor Doutor José Carlos Marques dos Santos seu dirigente máximo. Por sua vez é composta por unidades orgânicas de ensino e investigação as faculdades/institutos, dotadas de autogoverno e com autonomia científica, pedagógica, administrativa e financeira, tendo por objectivos o ensino, a investigação e a prestação de serviços nos domínios das suas atribuições específicas (Universidade do Porto 2012). Estas unidades orgânicas podem ser de ensino e investigação (com a sua divisão em faculdades e sendo o local onde se insere a FEUP), exclusivas de investigação e escola doutoral para promoção dos programas doutorais da universidade. A Reitoria também tem sob sua alçada os serviços autónomos da universidade onde se insere o SASUP (Serviços de Ação Social da Universidade do Porto) e CRSCUP (Centro de Recursos e Serviços Comuns da Universidade do Porto). Por forma a cumprir os desígnios para os quais a Universidade foi instituída, a direção da universidade é composta por órgãos de governo que se devem orientar pelos princípios de democraticidade, representatividade e de participação comunitária de acordo com a Lei de Bases do Sistema Educativo n.º 49/2005, de 30 de Agosto. A governação da universidade em relação ao estado goza de autonomia científica, pedagógica, administrativa e financeira podendo eventualmente ser fiscalizada por forma a garantir o cumprimento da lei. A Universidade do Porto tem um sistema organizacional envolvendo vários órgãos de governo, estruturados hierarquicamente tal como é apresentado na Ilustração 12. Ilustração 11: Organização da U.Porto (Universidade do Porto 2012) 65 Ilustração 12: Órgãos de Governo da U.Porto (Universidade do Porto 2012) Esta organização no topo da pirâmide a fundação que por sua vez tem abaixo deste o Conselho de Curadores para aprovar os Estatutos do Estabelecimento de Ensino, eleger o seu Presidente, proceder à homologação das deliberações do Conselho Geral de designação e destituição do Reitor, e nomear ou destituir o Conselho de Gestão. Como órgãos de governos existe o Conselho Geral para decidir sobre os Estatutos, eleger o seu Presidente e o Reitor. O Reitor é o órgão superior de governo e representante externo da Universidade. O Conselho de Gestão conduz a gestão administrativa, patrimonial e financeira, bem como a gestão dos Recursos Humanos da Universidade do Porto. Existem ainda outros órgãos como o Senado que age como um órgão consultivo, a Provedoria que tem como missão defender e promover os direitos e interesses legítimos de toda a comunidade académica. O Fiscal Único é designado por despacho conjunto do ministro responsável pela área das finanças e do ministro da tutela e compete-lhe controlar a legalidade, regularidade e boa gestão financeira e patrimonial da Universidade (Universidade do Porto 2012). Dentro da estrutura organizacional da Universidade do Porto surge a FEUP como uma faculdade que tem como missão “A FEUP é uma instituição de criação, transmissão e difusão do conhecimento, da tecnologia e da cultura na área da engenharia, e tem, como componente relevante, a preparação de jovens para o exercício da profissão de engenheiro a um nível internacional, sustentada em Investigação e Desenvolvimento de excelência, contemplando as vertentes científica, técnica, ética e cultural” (FEUP 2012). Para cumprir os desígnios para a qual foi instituída, a FEUP é composta por Órgãos de Gestão Central e dividida em Departamentos e Serviços Centrais. Os Órgãos de Gestão Central são constituídos pelo Conselho de Representantes, Diretor, Conselho Executivo, Conselho Científico, Conselho Pedagógico e um Órgão de fiscalização. Os departamentos estão divididos pelas áreas do conhecimento em engenharia sendo os seguintes: Engenharia Civil, Engenharia Electrotécnica e de Computadores, Engenharia Industrial e Gestão, Engenharia Mecânica, Engenharia Metalúrgica e de Materiais, Engenharia Informática, Engenharia de Minas, Engenharia Química e Engenharia Física. (FEUP 2012). 66 Por forma a sustentar os processos que regem a operacionalidade da FEUP, esta é composta por oito serviços centrais (FEUP 2012): a) Centro de Informática Prof. Correia Araújo (CICA): disponibiliza e assegura a operacionalidade de recursos e serviços de informática para toda a comunidade da FEUP, promovendo a sua utilização e inovação b) Divisão de Recursos Humanos (DRH): recrutamento, a seleção e a integração, a gestão e o desenvolvimento dos recursos humanos da FEUP c) Serviço de Documentação e Informação (SDI): disponibiliza a informação de suporte às atividades pedagógicas, de investigação e inovação da FEUP, a par da salvaguarda e difusão do seu património cultural e científico d) Serviços Académicos (SERAC): garante as atividades no âmbito da administração, gestão e apoio na área de gestão de curso; a área do acesso, ingresso e certificação; a área de gestão de estudante e na unidade de orientação e integração, de acordo com as instruções tutelares e as diretivas dos Órgãos de Gestão, constituindo a relação com o estudante o vetor essencial da sua atuação e) Serviços de Imagem, Comunicação e Cooperação (SICC): Promover as atividades de ensino e I&D, fomentar a cooperação com o exterior e dinamizar internamente a comunicação e a utilização eficiente da informação f) Serviços Económico-Financeiros (SEF): assegurar a atividade económica e financeira da FEUP, de acordo com as instruções tutelares e as diretivas dos Órgãos de Gestão g) Serviços Técnicos e de Manutenção (STM): efetua a gestão e manutenção dos espaços e dos equipamentos da Escola, de modo a garantir as melhores condições para o ensino de excelência na área das engenharias. h) Unidade de Apoio à Direção (UAD): exerce a sua atividade no âmbito do apoio aos órgãos de gestão. Para o âmbito do objeto de estudo desta dissertação, esta irá focar-se em três entidades: o SERAC por ser a entidade que efetua a gestão da documentação referente à Gestão de Cursos; o CICA que suporta informaticamente toda a informação e o SDI que tem sob sua alçada o Arquivo da FEUP para efetuar o arquivo da informação enviada pelo CICA. É igualmente abordado a Reitoria e Senado da UP por serem organismos responsáveis na criação de cursos para Universidade. É esta ligação entre a Reitoria, Senado da UP, SERAC, CICA e Arquivo da FEUP e a meta-informação utilizada e distribuída por cada um deles, que será isolada do ponto de vista organizacional. 67 2.2. Caracterização Funcional dos Processos do Arquivo da FEUP O Arquivo da FEUP é uma unidade pertencente ao SDI, exercendo a sua atividade no âmbito da gestão da informação administrativa. Este é composto por uma colectânea de serviços relevantes para a praxis administrativa e para a investigação sobre as memórias da instituição e respectiva exploração cultural. As funções do Arquivo abraçam o acompanhamento e racionalização da produção e ressecção da informação, a sua recolha, seleção, descrição, acondicionamento, instalação, acesso e difusão (Arquivo da FEUP 2013). Dos vários processos inerentes ao Arquivo e para se efetuar a caracterização do mesmo, irá focar-se unicamente no processo de “Gerir Documento”. Este processo tem sob sua responsabilidade a gestão documental na geração, obtenção, processamento e manutenção de documentos. Este é também o processo que é instanciado sempre que surgem pedidos relacionados com a preservação digital de informação sobre a Gestão de Cursos do SIGARRA. Neste momento o Arquivo efetua apenas a conservação dos ficheiros recepcionados pelo CICA, mas no futuro mais atividades poderão ser desenvolvidas ao agir ativamente sobre a informação recepcionada. A informação utilizada para caracterizar funcionalmente os processos de arquivo tem com base o documento “QualiFEUP – Descrição das Atividades do Arquivo de 2007”. Apesar de ser um documento com cinco anos, ainda está atual e é o que serve de orientação no Arquivo da FEUP. O documento QualiFEUP descreve o processo “Gerir Documento” que é composto por quatro subprocessos: “Gerar Documento”, “Obter Documento”, “Processar Documento” e “Manter Documento”. O subprocesso “Gerar Documento” é composto por cinco atividades que devem ser executadas sempre que se efetua a geração de um documento. Estas têm como objectivo a análise do quadro legal e normativo, caracterização das atividades, definição da produção e os fluxos de informação, estruturação dos metadados e a integração da estrutura do documento no modelo de arquivo. No Anexo 3 podem ser visualizadas as atividades em detalhe. O subprocesso “Obter Documento” é suportado por oito atividades para efetuar a obtenção de um documento. Estas têm como objectivo solicitar um pedido de transferência para o Arquivo Central, fazer a aceitação do pedido de transferência, receber e incorporar os documentos do Arquivo Central, comunicar e aceitar ofertas de doação documental e no caso de serem aceites efetua-se a sua recepção e incorporação. Estas atividades têm como âmbito de aplicação a transferência de documentação dos serviços produtores para o Arquivo Central e sua incorporação e a doação de espécies documentais. No Anexo 4 está uma tabela com detalhes sobre a definição pormenorizada de cada um. 68 No subprocesso “Processar Documento” existem quatro atividades a executar para se efetuar o processamento de um documento. Estas têm como objectivo efetuar uma imagem sumária identificativa e representativa do documento, aplicar a tabela de seleção documental, definida a cota dos documentos e eventualmente com o reacondicionamento das espécies documentais, e disponibilizar o documento para posterior acesso à informação. Os âmbitos de aplicação destas atividades inserem-se na criação de informação representativa do documento, filiação e armazenamento, gestão da informação e disponibilização do acesso. Esta informação pode ser visualizada em detalhe no Anexo 5. O subprocesso “Manter Documento” é composto por três atividades para a manutenção de documentos. Estas têm como objectivo verificar e validar a representação da informação realizada no tratamento técnico, as cotas atribuídas aos documentos e as medidas para conservar a integridade dos documentos. Tem como âmbito o controle da qualidade dos serviços e a conservação e preservação da informação. Estas atividades podem ser vistas em detalhe no Anexo 6. Para a gestão sistemas de arquivo a FEUP utiliza o GISA (Gestão Integrada de Sistemas de Arquivo). O GISA foi concebido a partir de 2002, por um consórcio de entidades, designadamente, pelas Câmaras Municipais do Porto, Vila Nova de Gaia, de Espinho, de Vila do Conde e ainda pela Reitoria da Universidade do Porto. Atualmente, o GISA encontra-se na versão 2.0, agregando um conjunto de módulos base (Controlo de Autoridade, Unidades Físicas, Unidades Informacionais, estatística, Administração de Utilizadores) e de módulos opcionais (Gestão de Requisições, Gestão de Depósitos) (Pópulo 2010). Em termos orgânicos e funcionais, o GISA está adstrito aos SDI, na sua valência Arquivo, assumindo-se como auxiliar na gestão de informação de arquivo, facilitando o desenvolvimento de atividades como a construção e registo de meta-informação de contexto e de representação de informação possibilitando a criação de pontos de acesso à informação, promovendo a sua pesquisa e recuperação, para apoio à gestão administrativa, pedagógica, científica, cultural e histórica da instituição (Pópulo 2010). No caso dos ficheiros recebidos pelo CICA, referente ao SIGARRA e mais propriamente nesta dissertação à componente de Gestão de Cursos, o Arquivo limita-se a efetuar tarefas dentro da preservação/conservação das tapes. Essa conservação deve garantir que o bitstream dos ficheiros não é alterado e os mesmos são disponibilizados sempre que forem solicitados. Sendo o GISA vocacionado para a gestão documental e não para um sistema de informação específico, no caso da preservação das tapes este não é utilizado. 69 Os ficheiros enviados pelo CICA são cópias de segurança do SIGARRA, para as quais o arquivo adopta uma tipologia de backups que conjuga tipos e periodicidades de backups diversos (Pópulo 2010): a) Diária incremental b) Semanal, semestral e anual, total Em termos práticos, procuram garantir uma permanente e integral disponibilidade de reposição da informação por recurso a realização de backups diários, parciais, incrementais (salvaguarda da informação nova ou alterada nas ultimas 24 horas), em complemento com os semanais totais (salvaguarda de toda a informação do sistema). A semestral e anual produz também cópias completas da informação. Os backups diário e semanal são eliminados e os suportes reutilizados passado um mês após a sua execução. Para os semestrais está prevista uma conservação por ano e meio e o anual é guardado permanentemente (Pópulo 2010). O procedimento de backup dirigido pela UAS concretiza-se por duas vias (Pópulo 2010): a) Para os servidores centrais da Faculdade, onde se encontram, nomeadamente, as áreas pessoais (estudantes e funcionários) e o GIAF, para os servidores onde estão instalados o Portal do Candidato e os Websites Temáticos e para os sistemas informáticos geridos pela UAS - o Correio Electrónico, o SharePoint, o Sistema de Controlo RFID, o GISA, o In Arte, o Moodle - faz-se a cópia de toda a informação - configurações, ficheiros, bases de dados, sistemas operativos, aplicações, logs; b) Para os demais sistemas informáticos, faz-se o backup das áreas e informação definidas e de responsabilidade dos respectivos gestores. Tipicamente o processo desenvolve-se em dois momentos complementares: a. Um primeiro momento de backup em disco de servidor, para determinadas pastas ou diretórios, interno aos sistemas b. De seguida, os robots do mecanismo central de backup são orientados, por configuração do software, para acederem a essas pastas ou diretórios dos servidores desses sistemas e canalizarem a informação a depositar para as drives de gravação em tape O CICA faz igualmente o envio dos mesmos ficheiros de backup para a Reitoria que por sua vez tem uma política similar de arquivo e tipologia. Este facto resulta da centralidade administrativa que a Reitoria tem face às faculdades da Universidade do Porto e o facto de o SIGARRA ter sido desenvolvido na FEUP, daí ainda não se ter unificado estes dois processos 70 de preservação dos backups. Foi detectado que o CICA tem algumas tapes em sua posse não efectuado por vezes o seu envio. Este estudo não pretende substituir os backups da base de dados do SIGARRA por um modelo de repositório. Estes backups devem continuar a existir mas só devem ter como único propósito a salvaguarda da operacionalidade do SIGARRA no caso de algum evento provocar a corrupção da informação. É pretendido com este documento a criação de modelo de repositório adaptado à preservação a longo prazo, da informação contida no SIGARRA e do significado da mesma, sendo este um requisito organizacional que os backups não conseguem cobrir na sua plenitude. 2.3. Caracterização Funcional dos Processos na Gestão de Cursos Por forma a suportar todos os processos inerentes à gestão da universidade, a Universidade do Porto desenvolveu o SIGARRA - Sistema de Informação para a Gestão Agregada dos Recursos e dos Registos Académicos. O SIGARRA agrega as componentes de Gestão Académica (GA), Gestão de Recursos Humanos (GRH) e SI que é a componente agregadora, tendo ficado disponível em 2003 na sequência de um projeto desenvolvido pela FEUP e a Reitoria da universidade. É no SIGARRA que todas as atividades relacionadas com a gestão de cursos são efectuadas através dos serviços académicos e pelos seus docentes. O SERAC é o organismo que efetua a gestão documental referente à Gestão de Cursos, desenvolvendo para isso várias atividades. É o responsável pela gestão documental da criação, alteração e gestão de cursos. Esta gestão documental envolve o tratamento de pedidos para unidades curriculares, desenvolvimento de várias atividades referentes à gestão dos horários e leccionamento de aulas, sendo feito através do planeamento de aulas, preenchimento de sumários e disponibilização de conteúdos. É também efectuada a gestão da marcação de exames e das avaliações, quer sejam dos alunos ou dos próprios cursos. A criação de um novo curso é um dos processos de maior complexidade e relevância na faculdade. Mesmo com a maioria das atividades a serem efectuadas sem a necessidade de utilizar a área da Gestão de Cursos do SIGARRA, a compreensão dos fluxos deste processo é importante para a compreensão da meta-informação que posteriormente é adicionada quando um novo curso é criado no SIGARRA. Até 2007 todo este processo era desenvolvido entre a universidade e Direção-Geral do Ensino Superior (DGES), tendo passado depois a ser assegurado pela Agência de Avaliação e Acreditação do Ensino Superior (A3ES). Esta agência tem como objectivo efetuar a acreditação e avaliação das instituições do ensino superior e seus cursos, por forma a garantir a qualidade dos mesmos no espaço europeu. 71 Tendo em conta que praticamente todos os cursos presentemente no SIGARRA foram criados através do processo anterior à existência do A3ES, serão descritas as principais fases e atividades que levaram ao surgimento dessa informação e que neste momento está a ser estudada para efeitos de preservação. Clarisse Sousa identificou quatro fases principais no processo de criação de novos cursos. A primeira fase está relacionada com a intenção de criar um novo curso na FEUP, onde internamente à faculdade são desenvolvidas várias atividades por parte dos conselhos Científico, Pedagógico e Diretivo para a proposta. Existe uma segunda fase que envolve o Senado e a Reitoria da Universidade do Porto que juntamente com o Ministério do Ensino Superior e Ciência e Tecnologia aprovam e é posteriormente publicado em Diário da República. O SERAC tem como missão nesta fase verificar a publicação em DR e publicar o regulamento no SIGARRA. É através da nomeação do diretor de curso e atribuição das credenciais no SIGARRA que serão despoletados todos os processos para que se possa efetuar a gestão do mesmo. Na tabela 1 está representada de forma sucinta as várias fases. Tabela 1: Principais fases do processo de criação de novos cursos (Sousa 2008) No Anexo 7 é apresentado de forma detalhada o fluxo de trabalho envolvido para cada uma das fases descritas na Tabela 1. Estão igualmente representadas as várias entidades envolvidas e as interações existentes em cada uma delas. O diretor de curso é o responsável por efetuar a manutenção do curso ao longo dos vários anos lectivos no SIGARRA. Esta manutenção envolve a inclusão e atualização de dados gerais sobre o curso como sigla, grau académico, tipo de cursos, inicio e duração. É desenvolvido o plano de estudos através da definição dos semestres e unidades curriculares com as várias unidades orgânicas. Definição de diplomas, número de créditos, requisitos de acesso, numerus clausus e comissão científica. É também efectuada a gestão referente às candidaturas de ingresso e todo o processo de seleção de novos alunos. 1ª Fase: Elaboração e aprovação interna do novo curso 2ª Fase: Aprovação externa e publicação em DR do novo curso 3ª Fase: Nomeação dos Órgãos de Gestão do novo curso 4ª Fase: Registo da informação do curso nas bases de dados 72 Toda a informação gerada na página do SIGARRA é guardada numa base de dados ORACLE que está sobre a supervisão do CICA. É igualmente este centro que efetua a manutenção técnica do SIGARRA e desenvolve as novas funcionalidades de acordo com os requisitos organizacionais. 2.4. Identificação da meta-informação no Modelo de Dados Por forma a armazenar na base de dados toda a informação referente à gestão de cursos, o CICA desenvolveu o modelo de dados apresentado na Ilustração 13. Este modelo de dados é composto por 25 tabelas, tendo como tabelas principais “cur_cursos” com informações referentes ao nome, duração, inicio, fim, acreditações e se tem estatuto bolonha; “cur_sis_funcionamento” com informações referentes aos créditos, o início e fim do ano lectivo e do ano corrente; “cur_instituicoes” nome das instituições que estão relacionadas com os cursos e “cur_diplomas” informações relativo aos diplomas do curso. Ilustração 13: Modelo de dados referente à gestão de cursos1 1 Modelo de dados cedido pelo CICA, da autoria de Marco Nunes com a última actualização em 4 Julho de 2012 73 No modelo de dados do SIGARRA, as tabelas referentes à Gestão de Cursos têm o prefixo “cur_” no seu nome. Este elemento será utilizado na diferenciação da informação enviada para o Arquivo. Tendo em conta que para todos os cursos existe uma estrutura de meta-informação comum, todos estes arquivos irão ser considerados como uma coleção de cursos para efeitos de preservação. O nome também é utilizado para identificar determinadas relações hierárquicas entre as tabelas, como por exemplo a “cur_cursos” e “cur_cursos_sucessao” têm uma relação de “1 para N”, tendo a tabela “cur_cursos_sucessao” informação especializada sobre “cur_cursos”. Estas relações entre os dados das tabelas irão estar definidas no repositório como informação representativa. Existem no entanto outras relações que são efectuadas para outros dados que não são referentes aos cursos. Estes casos irão ser tratados como relações contextuais e irão ser definidas através de identificadores para os arquivos que contenham essa informação. O modelo de dados rege-se principalmente por um esquema em pirâmide, para o qual temos como a tabela mais generalista a “cur_cursos” que depois se vai especializando nas suas vertentes. Para efeitos de preservação, o modelo a apresentar vai conter este mesmo esquema para cada um dos cursos representados. Sendo assim, em vez de se fragmentar o conteúdo para cada curso, pode-se agregar num só de forma atómica num pacote informacional. Desta forma quem for consultar a informação, não tem de estar a recuperar elementos separados. A tabela “cur_cursos” tem um registo para cada curso e tem os elementos básicos que o definem como o nome, sigla, tipo, etc. Por forma a especificar o tipo, existe uma relação com a tabela “cur_tipos” que indica qual o nome do tipo de curso, qual o seu estatuto e grau académico máximo. Existe uma relação com a tabela “cur_orga_creditos” para indicar a organização do tipo de créditos com definição do ano lectivo de início e de fim. Um curso tem áreas científicas predominantes para as quais estão definidas utilizando a tabela “cur_areas_cient_predomina”. Um curso pode ter sido sucedido através de outro, estando esta relação mapeada na tabela “cur_cursos_sucessao”. Neste caso como estamos a relacionar cursos diferentes, esta relação irá ser considerada uma relação contextual entre diferentes pacotes informacionais. Igualmente, um curso também está relacionado com outras instituições através da tabela “cur_instituicoes_cursos”. Considera-se que as instituições são uma coleção por si só, separadas da coleção de cursos. Como tal, irão ter também relações contextuais entre pacotes. 80 disseminados. Devido ao facto do PREMIS ter muitos elementos que se sobrepõem aos do METS e Dublin Core é preferível ter apenas este a estruturar o repositório, tornando-o mais simples e facilitando a sua manutenção. É importante relembrar que a estrutura dos pacotes de submissão e disseminação é definida de acordo com as entidades e programas que os vão processar, sendo por isso feitos à medida e podendo evitar ao mesmo tempo inconsistências. Sendo o PREMIS um esquema generalista para estruturação do conhecimento de um repositório, este irá utilizar outros esquemas dados específicos que no caso do presente estudo serão relativos à Gestão de Cursos. Para a preservação dos arquivos foram investigados alguns programas livres para efetuarem a gestão do repositório como o DAITSS e Archivematica mas não foram utilizados devido ao facto de não preencherem alguns requisitos. Um dos problemas encontrados está no facto de não suportarem várias versões do mesmo objeto digital. Estão baseados num modelo de preservação em que os objetos finalizados e para os quais não se prevê alterações no futuro, são enviados para conservação no arquivo. É um modelo que “copia” o processo de preservação de objetos físicos para objetos digitais e não tem em conta o arquivo temporal de informação que ainda está cativa. Ou seja, não permitem ter várias versões para o mesmo objeto temporal e efetuar o relacionamento entre eles. Outro facto negativo relativamente a estes programas, está no suporte total do dicionário de dados do PREMIS, sendo por isso uma enorme desvantagem na interpretação e relação da informação arquivada. O modelo apresentado neste estudo é construído com base num esquema de pastas e ficheiros, por forma a representar os conceitos pretendidos para a preservação digital. Apesar de estar baseado num sistema de ficheiros, não dignifica que não possa ser transposto para um sistema de base de dados relacional ou por uma aplicação para a gestão de conteúdo como o Fedora Commons. 3.2. Repositório A base do arquivo de informação é constituída por um conjunto de pastas e ficheiros no sistema operativo. A pasta principal é o Repository (repositório), tal como está representado na Ilustração 15. Esta pasta tem como objectivo estruturar toda a informação recebida (Ingest), arquivada (ArchivalStorage) e enviada para os utilizadores (Access). Igualmente tem toda a informação necessária para que os dados arquivados no presente possam ser compreendidos em qualquer momento no tempo (KnowledgeBase). Desta forma pretende-se responder a um dos desafios da preservação digital relacionado com a mutabilidade da base de conhecimento dos utilizadores. Esta mutabilidade acontece devido a alterações na organização, mudanças tecnológicas, ou outras que possam fazer com que um utilizador do repositório tenha uma percepção diferente daquilo que era na altura de arquivo. 81 Ilustração 15: Estrutura principal do repositório Dentro da pasta Repository, podemos visualizar na Ilustração 15 o Information Object (environment_variables_[di].xml) do tipo Descriptive Information. Este ficheiro está estruturado na linguagem XML contém variáveis do ambiente do repositório. Estas variáveis permitem várias informações como o último AIP a ser inserido, qual o número da sequência de inserção e chave de hash do último AIP que permite garantir a autenticidade de todos os AIP’s inseridos até ao momento. Sendo todo o repositório constituído por um conjunto de pastas e ficheiros, este pode ser implementado praticamente em qualquer sistema operativo atual e futuro. Tendo em conta que o sistema de ficheiros é algo que acompanha a evolução dos computadores desde o início, é natural que dificilmente seja substituído ou não venha a deixar de ter suporte. Funcionalmente o repositório utiliza a linguagem Perl para suportar todos os processos para o arquivo e acesso da informação. Esta linguagem foi selecionada por não ser proprietária e ao mesmo tempo poder ser instalada em qualquer sistema operativo atual. Tendo em conta que atualmente nos ambientes Unix e mais especificamente no Linux, o Perl já está de tal forma enraizado no sistema operativo que este já não funciona sem esta linguagem. Todos estes factores aliados ao facto de ser uma linguagem de referência para o desenvolvimento de scripts, torna-a ideal para utilização na preservação a longo prazo. 3.3. Armazenamento de Arquivos O Armazenamento de Arquivos (Archival Storage do OAIS) é o responsável por preservar a informação e garantir a sua integridade e autenticidade ao longo do tempo. Na prova de conceito apresentada, esta informação fica inserida dentro da pasta ArchivalStorage no Repository sob a forma de ficheiros AIP’s. O ArchivalStorage está dividido em três partes: coleções, items e versões de items. Uma coleção é um conjunto de arquivos que partilham a mesma estrutura de dados e o mesmo tema. No estudo efectuado relativo à caracterização funcional da Universidade do Porto, identificou-se vários grupos de informação com a mesma natureza, como os Cursos, Docentes, Departamentos, etc. Tendo em conta a especificidade e estrutura de dados de cada 82 um destes grupos, foram definidos algumas coleções, tal como é apresentado na Ilustração 16. Para este estudo só irá ser focada a coleção referente aos Cursos. Refere-se ainda que estas coleções apresentadas são a título de exemplo e para as quais não foi efectuado um estudo prévio para fundamentar a sua existência com exceção da coleção de Cursos. Ilustração 16: Coleções do Arquivo Cada coleção é por sua vez composta por vários items. Um item corresponde a uma entidade funcional do sistema organizacional da FEUP, tal como é apresentado na Ilustração 17. Com o tempo os estados e aspectos funcionais das entidades vão mudando à medida que interagem com a organização. Devido a estas constantes mudanças, é importante definir o quê e quando se deve preservar. Para isso é importante desenvolver um estudo sobre o conjunto de informação que tem valor histórico e aplicar a política de preservação adequada. Isto significa que pode haver situações em que um curso tem tantas mudanças na informação que faça sentido arquivar sempre que os dados mudem. Mas também se pode definir outro tipo de políticas periódicas para cursos que não tenham tantas mudanças, onde por exemplo uma preservação no início de cada mês seja suficiente. Apesar de este modelo de arquivo permitir diferentes tipos de estratégia de forma independente ao nível de um item específico, uma política de preservação ao nível da coleção é suficiente. Ilustração 17: Items de uma coleção Os items de uma coleção podem ser referenciados dentro do repositório utilizando o PREMIS, onde o Object Identifier Type deve ser “REPOSITORY” e o identificador deve ter o formato “<coleção>_<item>_[<tipo de objeto do OAIS>]”. Tomando como exemplo o curso de Mestrado em Biotecnologia (mib), dentro da pasta “mib” existe um ficheiro com o nome “item_entity_[io.ip.aip].xml”, representado na Ilustração 18, que contém a descrição para a 83 entidade intelectual “cursos_mib_[io.ip.aip]”. O nome da entidade intelectual é utilizado por outros arquivos (AIP’s) para criar relações contextuais com este. A criação da entidade intelectual envolve não só a definição de um nome mas também a associação com as várias versões do item aí localizado. Este processo é feito através da relação lógica da entidade intelectual do item com as entidades intelectuais para cada versão de item que está no repositório. A forma como isto é efectuado pode ser visualizada no Anexo 9. Um item é composto por versões de items, onde cada versão representa o estado dos dados no momento em que estes foram recolhidos do sistema de informação, sendo neste caso o SIGARRA. Assim, cada versão de um item corresponde a um SIP submetido no repositório, gerando por sua vez um AIP com toda a informação necessária para poder interpretar os seus dados. A resolução temporal máxima das versões de items é o dia, isto significa que se forem inseridos dois SIP’s para um item no mesmo dia, só o ultimo a ser inserido será utilizado em termos de acesso. A raridade deste evento e a simplificação que apresenta no acesso ao repositório, é por si só uma vantagem. Na Ilustração 18 está representado um conjunto de versões em ficheiros zip para o item “mib”, juntamente com ficheiro “item_entity_[io.ip.aip].xml” para identificar a entidade intelectual do item. Ilustração 18: AIP's correspondentes a várias versões de um item O Archival Storage permite relações entre as entidades intelectuais mas apenas podem existir relações unidirecionais entre uma versão de item para um item. É permitido e até recomendado efetuar relações entre versões de items e items pertencentes a coleções diferentes por forma a enriquecer o repositório. Um exemplo deste tipo de relações pode ser entre a versão de item “cursos_mib_20121015_761_[ip.ip.aip]” da coleção de Cursos, com o item “estudantes_mib17544_[ip.ip.aip]” da coleção de Estudantes. Esta informação fica guardada no ficheiro de informação contextual, dentro do AIP. De forma similar às relações entre as entidades intelectuais do repositório, existem relações entre os objetos dentro de um AIP. Estes objetos são descritos com o Object Identifier Type “LOCAL” e a visibilidade do seu identificador limita-se ao próprio AIP. Só 84 podem existir relações entre objetos “LOCAL” e entre estes objetos e a entidade intelectual que identifica o AIP, definida no ficheiro de informação do pacote no AIP. Por forma a garantir a autenticidade e integridade da informação armazenada no repositório, este adopta um mecanismo criptográfico para detectar qualquer alteração nos AIP’s. Para cada AIP inserido no repositório é atribuído um número de uma sequência única e ao mesmo tempo é registado dentro dele uma chave em hash, gerada a partir do AIP inserido anteriormente. Este processo é feito recursivamente de uns AIP’s para outros e no caso de existir alguma alteração, basta confrontar a geração da hash do AIP com a chave registada no AIP a seguir. No caso de as chaves serem diferentes significa que houve uma alteração. Visto que o AIP também tem chaves em hash dos ficheiros utilizados internamente, é relativamente fácil descobrir qual foi alterado. Para garantir a autenticidade do repositório como um todo, basta que o gestor do repositório tenha na sua posse a hash gerada para o último AIP. Na ilustração 19 é apresentado um exemplo do esquema do funcionamento do processo de autenticação descrito. Ilustração 19: Processo de autenticação do repositório A única forma de adulterar o repositório sem ser notado pelos processos internos, teria obrigatoriamente de passar pela geração de todas as chaves a partir do AIP que foi alterado. Mas mesmo esta situação seria detectável com a chave guardada do último AIP pelo gestor do repositório. 3.4. Base de Conhecimento Para se poder compreender os dados armazenados no repositório é importante perceber o seu significado. Mas o significado que os dados nos apresentam vai mudando à medida que a base de conhecimento que a comunidade tem relativo ao seu ambiente organizacional muda. Por vezes, também acontece que o significado perde-se no tempo, tornando-se praticamente impossível o entendimento a informação arquivada. Desta forma, é relevante passar ao utilizador do repositório toda a informação que lhe permita criar uma base mental para poder interpretar corretamente o objeto digital, independentemente da 85 época em que este se encontre. Esta informação deve ser precisa o suficiente para “transportar” o utilizador para o momento em que o arquivo foi gerado e este possa “vivenciar” a organização e todas as influências que sobre ela atuaram. Isto ao mesmo tempo em que a interpretação dos dados é aproximada da forma como a generalidade das pessoas interpretaria naquela altura. Na pasta KnowledgeBase está depositado toda a informação necessária para se poder compreender, no futuro, os objetos que estão sendo arquivados no presente. Este conhecimento é incluído em cada AIP, mais precisamente na pasta de Representation Information. O conhecimento que acompanha o AIP está adaptado à informação arquivada e descreve a sua semântica e a forma como está estruturada. Este conhecimento é composto por ficheiros específicos para o propósito a que se destinam. Ficheiros normalizados de XML Schema (extensão XSD) descrevem as regras para as quais os ficheiros em XML devem obedecer para poderem ser considerados válidos. Igualmente indicam qual o tipo de dados de meta-informação e padrões específicos para poder validar. Ficheiros em PDF para descrever a estrutura da meta-informação mas também para apresentarem o significado dos valores e estados, descrição dos processos e outras relações que tenham tido influência nos dados apresentados. Também deve estar descrito o sistema de informação, nomeadamente a forma como este apresenta os dados para o utilizador e ações desenvolvidas sobre o mesmo. Isto pretende dar uma visão realista da forma como os dados eram utilizados e tirar conclusões sobre a tomada de decisão efectuada com base nos mesmos. Os ficheiros no KnowledgeBase devem igualmente ter a informação sobre a forma como alguns objetos digitais se podem renderizar. Existem ficheiros muito específicos que podem ser anexados aos cursos, como por exemplo para modelação 3D, para os quais é necessário determinados programas e muitas vezes versões específicas destes para se poder visualizar a informação. Tendo em conta que o conhecimento específico para determinada aplicação a longo prazo tem tendência a perder-se, é necessário criar um documento em PDF com um conjunto de passos para o poder visualizar na sua plenitude. 3.5. Geração de Pacotes de Submissão A inserção de informação no repositório é feita através da recepção de pacotes de submissão, denominados SIP’s (Submission Information Package). O conteúdo e a estrutura do SIP devem ser acordados entre a entidade que vai enviar e o Arquivo da FEUP. No caso particular deste estudo, foi definida uma estrutura baseada no modelo de dados do SIGARRA para a Gestão de Cursos e os esquemas de metadados do Dublin Core e METS. Sendo uma estrutura já pré-definida, o SIP não necessita de trazer toda a informação para o interpretar. 86 O Arquivo já deve ter no seu KnowledgeBase e software adaptado para cobrir a maioria dos requisitos para descodificar o Data Object, mantendo assim o foco do SIP no envio de dados. Podem acontecer situações onde várias entidades enviam informação para o mesmo item mas essa informação deve ser sempre complementar, por forma a evitar conflitos. No caso da informação relativa aos cursos, podemos utilizar como exemplo o “Programa Doutoral em Media Digitais” que tem um protocolo com a Universidade do Texas em Austin. Para este curso o CICA poderia enviar a informação que está no SIGARRA e a Universidade do Texas iria enviar meta-informação específica do curso que existe nessa universidade. O Arquivo iria receber a informação das duas fontes e iria agregar no repositório. Esta agregação é feita através da junção da informação recebida por uma das fontes, com a informação complementar contida no último AIP para esse item, que através da sua combinação gera um novo AIP para arquivo. Cada pacote pode ter informação total ou parcial da mesma fonte, sendo depois o processo de ingestão a efetuar a sua inclusão no repositório. Mesmo assim é recomendável que cada pacote seja completo por forma a simplificar o processo de ingestão e evitar custos suplementares na sua manutenção. O software para a geração de SIP’s deve estar localizado nos servidores da entidade que vai enviar a informação para o Arquivo da FEUP. Este deve ter na sua organização quatro pastas fundamentais, sendo estas o bin, log, output e temp tal como é representado na Ilustração 20. Ilustração 20: Estrutura do programa para geração de SIP's A pasta de bin irá ter os binários ou scripts para a geração dos SIP’s, sendo neste caso composto por um script em linguagem Perl, apresentado no Anexo 10. Durante a geração do SIP será extraída informação da base de dados do SIGARRA, ficando esta temporariamente localizada na pasta temp. Quando todos os ficheiros tiverem sido gerados na pasta temp, a informação será compactada num ficheiro zip, que conceptualmente passará a ser designado como SIP. O SIP é enviado para a pasta output, sendo posteriormente removida toda a informação necessária para a sua criação na pasta temp. Todas as operações realizadas durante a criação de um SIP ficarão registadas cronologicamente na pasta log, através da geração de ficheiros diários com o formato “sipgen_<dia da geração>.log”, como por exemplo “sipgen_20130515.log”. No Anexo 11 pode ser visualizado o conteúdo de um destes ficheiros. 87 O SIP tem toda a informação referente a um determinado curso, sendo identificado pelo nome do ficheiro com o formato “<fonte dos dados>_<coleção>_<item>_<data e hora da geração>_[<tipo de objeto do OAIS>].<formato de compressão>”, como por exemplo “sigarra_cursos_apl_20130515005639_[io.ip.sip].zip”. Este formato de nome de ficheiro tem a vantagem de permitir na ordenação alfabética o agrupamento dos ficheiros pela fonte de dados e sub-agrupar pela coleção, item e geração. A fonte dos dados designa o sistema de informação para o qual os dados foram recolhidos. A inclusão deste tipo em primeiro lugar permite ao gestor do repositório facilmente identificar os SIP’s de acordo com a sua fonte. A coleção e o item representam o tipo de informação para submissão no arquivo mas também o local onde o arquivo para preservação irá estar. Assim, no exemplo apresentado anteriormente, os “cursos” são a coleção e o “apl” refere-se um curso específico. O campo data e hora da geração permitem não só indicar o momento em que o pacote foi gerado mas também a ordenação temporal dos arquivos pela sua geração. A remoção dos separadores da data e hora evita incompatibilidades com os File Systems, ao mesmo tempo que o identifica unicamente em relação a outros pacotes que possam existir com a mesma fonte, coleção e item. O “tipo de objeto” serve para posicionar este objeto dentro do modelo de arquivo OAIS, sendo o SIP um Information Object (io), especializado num Information Package (ip), que por sua vez se especifica num Submission Information Package (sip). A opção de apresentar o posicionamento estrutural no OAIS tem apenas como propósito a melhor compreensão da prova de conceito, podendo ser simplificado pondo apenas “sip”. Na extensão do ficheiro optou-se por apresentar o formato de compressão e não a sigla “SIP” do OAIS. Isto permite ao utilizador e ao sistema operativo identificar mais facilmente o programa para descodificar o ficheiro. Sendo assim, o campo “formato de compressão” deve corresponder à sigla utilizada para a tecnologia que irá agrupar os vários ficheiros num só e reduzir o seu tamanho para a transmissão. A opção pela utilização do ZIP prende-se com o facto de ser um dos formatos mais reconhecidos em todo o mundo, pela sua antiguidade e utilização. Estes factores dão mais garantias da sua interpretação no futuro. A informação que está presente no nome do SIP não deve ser utilizada para identificar ou tomar decisões no processo de ingestão. Este processo só deve utilizar a informação que está contida dentro do SIP e é a partir daí que encaminha o pacote através do processo de arquivo. Esta recomendação deve-se ao facto de a informação no nome do SIP nem sempre corresponder fielmente ao seu conteúdo, devido a limitações dos sistemas de ficheiro 88 utilizados nos sistemas operativos. Sendo assim, o nome do ficheiro deve ser utilizado como um auxiliar para o gestor de arquivo. Um exemplo desta limitação está na representação de letras com acentos, onde em algumas situações poderiam aparecer sem acento ou apenas com um rectângulo. Todos os ficheiros SIP têm na sua composição um ficheiro sip.xml que identifica e descreve o próprio SIP e todos os outros ficheiros dentro dele. O ficheiro sip.xml é o único que tem a obrigatoriedade de existir dentro do SIP, estando este estruturado através da linguagem XML e o esquema de meta-informação METS. Como complemento ao METS é utilizado o esquema de meta-informação Dublin Core. Na Ilustração 21 temos um exemplo de um pacote de submissão juntamente com os seus ficheiros e parte do sip.xml. Ilustração 21: Exemplo de um pacote de submissão e estrutura do sip.xml Internamente o ficheiro sip.xml é composto por uma declaração inicial sobre as regras de codificação e por um único elemento METS. Esta declaração indica ser um ficheiro XML que segue a especificação 1.0 e onde todos os caracteres utilizados estão sob o sistema de codificação UTF-8. Um exemplo completo deste ficheiro pode ser visualizado no Anexo 12. O elemento METS é composto pelos seguintes quatro tipos de atributos: • Os namespaces servem para identificar unicamente os elementos de XML através do uso de um prefixo, evitando desta forma possíveis conflitos com os 89 nomes. Isto é feito através da sintaxe “xmlns:prefixo="URI"”, onde o prefixo pode ser para METS, Dublin Core ou xlink e o seu correspondente Uniform Resource Identifier (URI). O URI é um conjunto de caracteres utilizados para identificar um recurso na internet que neste caso será a informação referente aos vários esquemas utilizados. • O object id é o identificador único deste objeto no repositório e corresponde ao nome do ficheiro sem a sua extensão. • O label que corresponde a uma legenda referente ao conteúdo que será submetido. • O atributo type indica o tipo de conteúdo presente no SIP para o poder interpretar. Este segue as regras definidas para os Internet media types que foram herdadas dos Multipurpose Internet Mail Extensions (MIME). Neste caso, o type utilizado para os SIP’s é “application/sip.curso+xml”, indicando ser um ficheiro geral do tipo SIP, mais especificamente referente aos cursos e está representado em XML. Por forma a descrever o conteúdo informacional do SIP, o elemento do METS utiliza cinco secções: METS Header (metsHdr), Descriptive Metadata Section (dmdSec), Administrative Metadata Section (amdSec), File Section (fileSec) e Structural Map (structMap). 3.5.1. Cabeçalho do METS No METS Header é apresentado uma breve descrição do pacote SIP como a data de criação, qual o estado do pacote e os agentes que tiveram intervenção no SIP. Para o caso da prova de conceito, no estado dos pacotes é sempre completo devido ao facto de não existirem SIP’s parciais. No caso dos agentes é identificado o CICA como a organização que teve o papel de criadora do SIP. 3.5.2. Metadados Descritivos Na secção de Descriptive Metadata optou-se por utilizar o esquema de metainformação do Dublin Core Simples por forma a fornecer informação relativo ao SIP. Este processo é feito através de um elemento mdWrap que permite associar o METS a outros esquemas. Visto que o Dublin Core está definido sobre as secções do METS, os quinze elementos deste tiveram de ser distribuídos pelas várias secções. No caso da secção de Descriptive Metadata foram utilizados os seguintes elementos: Title, Creator, Subject, Description, Publisher, Contributor, Date, Identifier, Language, Relation e Coverage. Parte destes elementos vão ver fundamentais no processo de Ingest para a criação do AIP. Após o processamento do SIP, estes elementos irão permitir gerar relatórios e pesquisas na entidade 96 Schema permite confirmar se todas as regras para a criação do ficheiro XML foram cumpridas. No Anexo 15 pode ser visualizado um exemplo deste tipo de ficheiro. Ilustração 26: Objeto de dados em XML referente à tabela de Cursos Para além da informação da base de dados, os cursos podem ter outros tipos de objetos submetidos. Neste momento no SIGARRA, com exceção dos ficheiros de imagem, não existe nenhuma normalização para o tipo de ficheiros que se podem submeter. Tendo em conta que muitos destes objetos são extremamente complexos, como os ficheiros do Microsoft Office, a garantia da sua legibilidade no futuro não é garantida. A diversidade de formatos é considerada um entrave para a preservação, pois implica ter as versões dos programas específicos para os poderem renderizar. Uma estratégia para resolver este problema está na conversão destes formatos para a versão mais recente através da migração. Mas sempre que se efetua uma conversão existe sempre a probabilidade de perda. Assim, a melhor forma de se preservar estes documentos a longo prazo está em efetuar a normalização dos mesmos para formatos mais estáveis, reduzindo o número de conversões e de suporte futuro para múltiplas versões de software. Tendo em conta que os ficheiros arquivados só podem ser lidos, isto facilita a seleção de formatos para canonização. Na Tabela 3 está uma recomendação de normalização de formatos de ficheiros a ocorrer durante o processo de ingestão ou mesmo efectuado através da aplicação do SIGARRA. Esta normalização foi desenvolvida com base em vários projetos de preservação estudados e na experiência pessoal através da utilização destes arquivos. 97 Tabela 3: Normalização recomendada para os tipos de objetos Tipo de Objeto Objeto Inicial Objeto Final Texto TXT, XML, CSV, … Texto em XML Imagem Estática JPG ou JPEG Imagem Estática em JPG Imagem Estática BMP, PNG, TIFF, … Imagem Estática em PNG Imagem Vectorial CDR, CMX, SVG, WMF, … Imagem em SVG Áudio MP3 Áudio em MP3 Áudio WAV, MIDI, AIFF, WMA, … Áudio em WAV Vídeo AVI, MKV, MPG, MPEG, MOV, RM, WMV, … Vídeo em AVI com codec de vídeo H.264 e codec de áudio em Mp3 Documentos DOC, DOCX, XLS, XLSX, PPT, PPTX, … Formato de preservação Adobe PDF/A-2 em PDF Documentos PDF Formato de preservação Adobe PDF/A-2 em PDF Base de Dados MDB, DB, DAT, GDB, ODB, … Texto em XML Arquivos Comprimidos ZIP, 7Z, ARJ, RAR, … Não são permitidos arquivos comprimidos no Data Object visto que o AIP já é comprimido Imagens de dispositivos de armazenamento IMG, ISO, NRG, DMG, DSK, … Não são permitidos imagens dispositivos de armazenamento, tendo estas que ser descomprimidas Páginas Web Estáticas HTM, HTML, MAF, MHT, MHTML, … Páginas em HTML cumprindo as especificações da W3C Páginas Web Dinâmicas ASP, ASPX, CGI, JSP, PHP, … Criar sempre que possível páginas estáticas em HTML cumprindo as especificações da W3C Com a canonização dos objetos simplifica-se a manutenção do repositório e reduz-se ao mesmo tempo a probabilidade de perda de informação. A gestão de um pequeno grupo de formatos permite acompanhar a evolução dos mesmos e detectar impactos para a integridade dos dados no futuro. Para o caso de não ser possível a conversão do formato de ficheiro para um mais recente, recomenda-se a criação de uma máquina virtual para cada versão de software que tenha ficado obsoleto. Assim no repositório pode-se ter uma coleção com máquinas virtuais e criar de seguida uma relação contextual das versões de items para cada um destes items. A vantagem da utilização de máquinas virtuais está no facto de não estar dependente da 98 plataforma em que está a ser executada, ao mesmo tempo que emula um ambiente virtual que se mantem constante ao longo do tempo. 3.6.2. Informação de Representação A informação de representação (Representation Information no OAIS) é necessária para tornar compreensíveis os Data Objects para a organização a que se destinam. Esta pasta irá conter todos os ficheiros necessários para explicar, validar a estrutura dos Data Objects e apresentar relações e informações semânticas nos mesmos. Os ficheiros aqui localizados podem vir diretamente do SIP ou do KnowledgeBase. O relacionamento e descrição de todo o Content Information é efectuado através do esquema de meta-informação PREMIS no ficheiro “representation_information_[io.ip.aip.ci.ri].xml”. Em relação à informação estrutural é efectuada a descrição dos tipos de dados, significado, relações, conteúdo e documentação para que os mesmos possam ser entendidos pelo utilizador. O PREMIS já tem definido no seu dicionário elementos que apresentam estas relações informativas utilizando o elemento “relationship”, sendo efectuada a relação entre dois objetos locais do AIP com a indicação do tipo de relação (estrutural, explicativa, etc). As relações podem ser entre Data Objects ou entre Data Objects e Representation Information Objects. Para efetuar estas relações é definido um UUID (Identificador Único e Universal) que depois é utilizado nas relações, podendo ser visualizado no Anexo 16. Para cada objeto digital são recolhidas características do objeto como o seu tamanho e formato. Em relação ao formato é definido no elemento “formatName” o Internet Media Type e inseridas algumas notas em relação ao mesmo. No caso dos ficheiros em XML optouse por incluir a versão. É também efectuada a descrição para os Data Objects sobre as necessidades de software e hardware necessários para os renderizar. O PREMIS apresenta o elemento “environment” para efetuar a descrição do ambiente necessário para poder visualizar e as dependências do conteúdo do objeto digital. Dentro do elemento environment é indicado a característica, o propósito e algumas notas; que no caso de um ficheiro XML sobre cursos informa sobre o que é recomendado para a visualização da informação. Visto ser um XML, este está dependente do XML Schema para o poder validar e garantir que está cumprir as regras de estruturação dos dados. É assim definido no elemento “dependency” o local do ficheiro XSD que permite garantir que o objeto é válido. Para a visualização do objeto digital são definidos nos elementos de software e hardware os seus requisitos. Tratando-se neste caso de ficheiro de texto simples, um editor de texto como o Notepad em qualquer computador x86 são suficientes para visualizar. Mas 99 podemos ter objetos mais complexos como os de Autocad que necessitam de versões específicas de software e hardware igualmente especializado como placas gráficas, processador e memória adequados para se poder renderizar o objeto. Toda esta informação deve estar definida, tal como é visualizado em detalhe na Ilustração 27. Ilustração 27: Descrição do ambiente para renderização utilizando o PREMIS Em relação à informação semântica é importante ter objetos que descrevam informação sobre a língua em que os Data Objects estão armazenados. O significado de determinados estados ou parâmetros e igualmente relações que não pareçam óbvias à partida mas são fundamentais para entender os dados e tomadas de decisão que foram efectuadas com base neles. Um exemplo deste tipo de informação pode estar na disposição da informação apresentada no ecrã, agrupamentos ou até modos de inserção. Este tipo de informação deve estar descrito num ficheiro para que possa ser anexada e visualizada mais tarde pelo utilizador do repositório. Isto significa que para se poder obter o conhecimento de um determinado campo na sua plenitude, é relevante acompanhar com o AIP um documento que explique todos os aspectos do significado dos símbolos, palavras e expressões na altura em que o AIP foi gerado. 3.6.3. Informação Contextual Os AIP’s devem ter relações com outros AIP’s para que possam enriquecer a sua informação. Estas relações são importantes para perceber não só toda a sua envolvência, mas também para quem utiliza a informação do repositório por forma a poder recolher informação que no princípio parece não estar relacionada. Um curso pode ter relações com items das coleções de docentes, estudantes ou até publicações sobre o ambiente organizacional, económico e político no momento de arquivo. Estas relações contextuais nunca podem apontar para uma versão de item mas sim para o item genérico. Na altura em que o utilizador está a aceder à informação, o repositório irá selecionar os AIP’s específicos de acordo com a data definida pelo utilizador para sua extração. 100 A informação contextual está definida num ficheiro com o nome “context_information_[io.ip.aip.pdi.ci].xml”, localizado dentro da pasta de Preservation Description Information. No Anexo 17 temos um exemplo de relações, onde o “objectIdentifierType” aponta para objetos AIP do repositório. Para o caso do curso a ser gerado, o “cursos_mib_20130430_1_[io.ip.aip]” indica ter uma relação estrutural com o estudante “estudantes_mib13471_[io.ip.aip]”. Desta forma torna-se perceptível que o estudante com o código mib13471 frequentou o curso de Mestrado Integrado em Bioengenharia (“mib”). 3.6.4. Informação de Autenticidade Garantir que um objeto é o que diz ser, é um dos elementos mais importantes na preservação. Ao longo do tempo a informação armazenada no repositório é permissível a alterações no conteúdo informacional devido a erros de mídia, conversões de ficheiros ou adulterações. No caso de existirem erros de mídia ou adulterações, deve existir um mecanismo que os permita detectar e repor a autenticidade através da substituição por uma cópia de segurança. No caso de não existir uma cópia de segurança válida, o objeto digital deve ser anulado ou garantir que alguém o possa autenticar como verdadeiro. Na situação de haver a necessidade de conversão de ficheiros, deve haver um agente (pessoa ou software) que garanta a autenticidade do objeto convertido. Para garantir a autenticidade e igualmente a sua integridade, são utilizadas chaves de hash geradas a partir dos dados do objeto digital. Se o objeto digital for mudado, a geração de uma nova hash vai retornar uma mensagem diferente da que foi registada inicialmente. A informação de hash está armazenada no ficheiro “fixity_information_[io.ip.aip.pdi.fi].xml” dentro da pasta Preservation Description Information do AIP. Na Ilustração 25 está apresentada a informação de autenticidade para um determinado objeto. O ficheiro pode ser visualizado na íntegra no Anexo 18. Ilustração 28: Informação sobre a autenticidade de um objeto digital Devido à evolução dos programas de geração de chaves, o PREMIS fornece um campo para indicar o algoritmo utilizado “messageDigestAlgorithm” e o programa que o originou 101 “messageDigestOriginator”, para garantir que a chave não é diferente devido a alterações no programa. É assim recomendável que não sejam feitas atualizações do programa para gerar chaves sob pena de perder a garantia no repositório como um todo. Tendo em conta que com alguma regularidade são detectadas falhas de segurança nestes algoritmos, é recomendável fazer a sua substituição sempre que isto acontece. 3.6.5. Informação sobre Proveniência A informação sobre a proveniência (Provenance Information no OAIS) documenta toda a história do Content Information. Esta informação fica guardada no ficheiro “provenance_information_[io.ip.aip.pdi.pi].xml” dentro da pasta Preservation Description Information do AIP. Neste local são identificados todos os agentes (pessoas, organizações ou software) que tiveram uma ação direta sobre a informação e as permissões sobre o uso da informação. Um exemplo completo deste ficheiro pode ser consultado no Anexo 19. Um agente é definido utilizando o elemento “agent” e para o qual é definido um identificador único para todo o AIP. Associado ao identificador do “agent” é definido um nome e o tipo. Na Ilustração 29 está apresentada a forma como é descrito através do PREMIS. Ilustração 29: Identificação de um agente Ao longo de todo o processo de ingestão são realizadas várias operações sobre os dados para a construção do AIP. Essas operações são registadas utilizando o elemento “event”, podendo cada evento ter vários agentes relacionados. Ilustração 30: Definição de um evento 102 Na Ilustração 30 temos um exemplo de um evento do processo de ingestão para o carregamento da informação do SIP, no qual o agente “ingest.pl” irá fazer o seu processamento e o agente “mailto:[email protected]” efetua a sua verificação. A informação arquivada tem direitos a nível da forma como é utilizada e dos agentes que o podem fazer. A descrição dos direitos é efectuada através do elemento “rights” que permite definir quatro tipos de direitos diferentes: copyright, licenças ou outros direitos legais a definir. Na ilustração 31 está um exemplo de direitos de acesso. Este indica que a informação é do domínio público mas só pode ser consultada dentro da Universidade, estando sob a jurisdição portuguesa e tendo sido determinado em 1 de Junho de 2013. Informa ainda que está em vigor deste 10 de Junho de 2013 até 10 de Junho de 2014. Ilustração 31: Definição de direitos sobre a informação É ainda possível efetuar a relação dos direitos com um item existente no repositório para a descrever em detalhe, sendo neste caso o “regulamentos_copyrightSigarra_[io.ip.aip]”. Na definição dos direitos é indicado em detalhe qual o agente que detém o direito e sobre que objetos. É igualmente indicado que tipo de ações são permitidas durante o período de vigência dos direitos definidos. 3.6.6. Informação Identificativa Na informação identificativa (Reference Information do OAIS) são enumerados e descritos todos os identificadores assignados ao Data Objects no Content Information. Os 103 identificadores ficam armazenados no ficheiro “reference_information_[io.ip.aip.pdi.pi].xml” dentro da pasta Preservation Description Information do AIP. Para cada identificador é gerado um código universal único e relacionado com o ficheiro armazenado localmente no AIP. Este tipo de código foi escolhido por fazer parte do standard ISO/IEC 11578:1996 "Information technology – Open Systems Interconnection – Remote Procedure Call (RPC)", sendo por isso reconhecido e utilizado por diversos tipos de software. Este identificador permite que depois seja utilizado em outras áreas através dos elementos de “Object Identifier”, por forma a criar relações semânticas. Um exemplo deste tipo de conteúdo está no Anexo 20. 3.6.7. Informação sobre AIP É no Packaging Informtion do OAIS que é criada a unidade atómica do AIP, através da identificação e agrupamento de todos objetos, ficando esta informação localizada na raiz do AIP no ficheiro “packaging_information_[io.ip.aip.pi].xml”. Ilustração 32: Exemplo de Packaging Information do AIP O PREMIS permite criar entidades intelectuais que não são mais do que a representação de um conjunto de objetos digitais e meta-informação por forma a criar uma nova supra-entidade. Esta entidade é definida através do elemento “object”, onde o atributo “type” é definido como “representation”. Na Ilustração 32 é definido o tipo de objeto, estando neste caso ao nível do repositório e o nome do AIP. Depois de definido o objeto são identificadas as relações da nova entidade intelectual, o AIP. Sendo esta uma entidade correspondente a uma versão de item, só poderá ter relações locais ao AIP. Parte desta informação descritiva relacionada com o AIP, vai ser inserida numa base de dados para suportar a gestão do repositório, fazendo assim parte do Data Management. 104 Por fim é calculada a chave de hash para o AIP anterior a este e a chave é armazenada dentro deste pacote. Todos os ficheiros são compactados num único ficheiro zip e enviado para a preservação permanente no ArchivalStorage de acordo com a coleção e item correspondentes. 3.7. Acesso O acesso à informação do repositório é efectuado através do elemento funcional do OAIS Access. Neste elemento são fornecidos serviços e funções para suportar os pedidos dos utilizadores a nível da requisição da informação. A informação enviada para fora do repositório vai sempre sobre a forma de pacotes de disseminação, denominados DIP’s (Dissemination Information Package). O conteúdo e a estrutura de um DIP são acordados entre a entidade que vai receber o arquivo e o Arquivo da FEUP. Este acordo permite não só que a informação seja adaptada ao cliente a que se destina mas ao mesmo tempo que cumpra os direitos de utilização que sobre ela imperam. O software para a geração de DIP’s está localizado na pasta Access dentro do Repository. Este deve ter na sua organização quatro pastas fundamentais, sendo estas o bin, log, output e temp, tal como é representado na Ilustração 33. Ilustração 33: Estrutura do programa para geração de DIP's A pasta bin irá ter os binários ou scripts para a geração dos DIP’s de cada utilizador. Esta diferenciação por utilizador é importante na entrega do DIP de forma personalizada. Durante a geração do DIP, é selecionado o AIP com a informação a extrair, sendo retirado do AIP apenas a informação necessária para a construção do DIP na pasta temp. Quando toda a informação tiver sido gerada na pasta temp, esta será compactada num ficheiro zip, que conceptualmente passará a ser designado como DIP. O DIP é enviado para a pasta output, sendo posteriormente removida toda a informação necessária para a sua criação da pasta temp. Todas as operações realizadas durante a criação de um DIP ficarão registadas cronologicamente na pasta log, através da geração de ficheiros diários com o formato “<script>_<dia da geração>.log”, como por exemplo “sigarra_20130515.log”. O DIP irá ter toda a informação referente ao pacote pedido e de acordo com a estrutura definida. Assim, este será identificado pelo nome do ficheiro com o formato “<utilizador>_<coleção>_<item>_<dia de referência>_[<tipo de objeto do OAIS>]. <formato de compressão>”, ex.: “sigarra_cursos_apl_20130701_[io.ip.dip].zip”. O utilizador 105 identifica a entidade que fez o pedido para recepção de informação, que no caso do exemplo definido pode ser informação para ser novamente carregada no SIGARRA. O campo do dia de referência, é o dia que o utilizador definiu para a recolha de informação do repositório. O “tipo de objeto” e de forma similar ao SIP e AIP, representa o posicionamento no modelo do OAIS, onde neste caso tem como diferença a sigla “dip” que significa ser um dissemination information package. Por forma a exemplificar-se a construção de um DIP, teve-se como princípio um utilizador que faz um acesso generalista ao repositório e pretende toda a informação arquivada para cada AIP para posteriormente ser visualizado no SIGARRA. Visto ser um ficheiro para ser transmitido a outras entidades, é utilizado como base o esquema de metainformação METS juntamente com o Dublin Core Simples para efetuar a sua caracterização. Ilustração 34: Pacote de Disseminação (DIP) Tendo o utilizador pedido um DIP com toda a informação do AIP, foi inserido neste toda a informação do AIP sem o ficheiro do “packaging_information_[io.ip.aip.pi].xml”, que é substituído pelo “dip.xml”. Na Ilustração 34 está um exemplo de um ficheiro deste tipo. No Anexo 22 está um exemplo de um ficheiro “dip.xml” onde é efectuada a identificação do DIP com base no Dublin Core e descrita a estruturação do DIP e autenticação dos ficheiros utilizando o esquema METS. 112 FEUP. Apresentação da FEUP. 28 de Junho de 2012. http://sigarra.up.pt/feup/pt/web_base.gera_pagina?p_pagina=1182 (acedido em 25 de Março de 2013). Gewirtz, David, Rebekah Irwin, Matthew Beacom, Kevin Glick, e Paula Ball. Recommendation to Adopt PREMIS as a Preservation Metadata Model for the Yale University Library. 2006. Giaretta, David. Advanced Digital Preservation. Dorset, Reino Unido: Springer, 2011. Hedstrom, Margaret. Digital Preservation: A Time Bomb for Digital Libraries. Michigan, EUA: Kluwer Academic Publishers, 1998. Kavčič-Čolić, Alenka. Approaching Digitisation Through a Digital Preservation Perspective. Ljubljana, Eslovénia: National and University Library, Ljubljana, Slovenia, 2012. Lee, Christopher. Defining Digital Preservation Work: A Case Study of the Development of the Reference Model for an Open Archival Information System. University of Michigan, 2005. Muir, Adrienne. “Digital preservation: awareness, responsibility and rights issues.” Journal of Information Science, 2004. National Library of Australia. Guidelines for the Preservation of Digital Heritage. National Library of Australia, 2003. OCLC/RLG Working Group. A Metadata Framework to Support the Preservation of Digital Objects. Dublin, Ohio, EUA: OCLC Online Computer Library Center, Inc., 2002. Paradigm. Workbook on Digital Private Papers. Oxford, Reino Unido: Oxford University Library Services, 2008. Parliamentary Archives. A Digital Preservation Policy for Parliament. Londres, Reino Unido: Parliamentary Archives, 2009. Pasqui, Valdo. “Digital Preservation and Open Access Archives: Persistent access to open access digital assets.” Digital Preservation Europe, 2007. Pópulo, Jorge. O Sistema de Informação Digital da FEUP na Perspectiva da Preservação da Informação. Porto, Portugal: Faculdade de Engenharia da Universidade do Porto, 2010. PREMIS Committee. PREMIS Data Dictionary for Preservation Metadata: PREMIS version 2.0. PREMIS Editorial Committee, 2008. Proença, Ana, e Sandra Lopes. Digital Preservation. Covilhã, Portugal: Universidade da Beira Interior, 2004. QualiFEUP. DEscrição das Actividades de Arquivo. Porto: FEUP, 2007. 113 Reshef, Petra, et al. Authenticity and Provenance in Long Term Digital Preservation: Modeling and Implementation in Preservation Aware Storage. Haifa, Israel e Urbino, Italia, 2009. Saramago, Maria de Lurdes. Metadados para preservação digital e aplicação do modelo OAIS. Lisboa, Portugal, 2004. SHAMAN. SHAMAN Framework. 21 de Junho de 2013. http://shaman-ip.eu/node/10 (acedido em 21 de Junho de 2013). Shirky, Clay. Archive Ingest and Handling Test (AIHT) . Library of Congress, 2005. Sousa, Clarisse. Avaliação e Implementação de Sistemas Integrados de Gestão de Conteúdos e de Gestão Documental. 2008. Strodl, Stephan. (Semi-)Automated Digital Preservation Archives for Small Institutions and Private Users. Viena, Austria: Vienna University of Technology, 2010. Tessella. The Long-Term Preservation of Digital Information. Tessela Technology & Consulting, 2010. The Cedars Project. Cedars Guide to Preservation Metadata. The Cedars Project, 2002. Universidade do Porto. Sobre a Universidade do Porto. 23 de Janeiro de 2012. http://sigarra.up.pt/up/pt/web_base.gera_pagina?p_pagina=122225 (acedido em 25 de Março de 2013). University of North Carolina. Carolina Digital Repository. 2013. http://www.lib.unc.edu/cdr/ (acedido em 31 de Março de 2013). 114 115 Anexo 116 117 Anexo 1. Ficheiro em XML utilizando Dublin Core Simples Exemplo de um ficheiro em XML utilizando o esquema de meta-informação Dublin Core simples (Dublin Core Metadata Initiative 2012) <?xml version="1.0"?> <metadata xmlns="http://example.org/myapp/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://example.org/myapp/ http://example.org/myapp/schema.xsd" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:title> UKOLN </dc:title> <dc:description> UKOLN is a national focus of expertise in digital information management. It provides policy, research and awareness services to the UK library, information and cultural heritage communities. UKOLN is based at the University of Bath. </dc:description> <dc:publisher> UKOLN, University of Bath </dc:publisher> <dc:identifier> 2001-07-18 </dcterms:modified> <dc:format xsi:type="dcterms:IMT"> text/html </dc:format> <dcterms:extent> 14 Kbytes </dcterms:extent> </metadata> 118 119 Anexo 2. Ficheiro em XML utilizando Dublin Core Qualificado Exemplo de um ficheiro em XML utilizando o esquema de meta-informação Dublin Core qualificado (Dublin Core Metadata Initiative 2012) <?xml version="1.0"?> <metadata xmlns="http://example.org/myapp/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://example.org/myapp/ http://example.org/myapp/schema.xsd" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <dc:title> UKOLN </dc:title> <dcterms:alternative> UK Office for Library and Information Networking </dcterms:alternative> <dc:subject> national centre, network information support, library community, awareness, research, information services,public library networking, bibliographic management, distributed library systems, metadata, resource discovery, conferences,lectures, workshops </dc:subject> <dc:subject xsi:type="dcterms:DDC"> 062 </dc:subject> <dc:subject xsi:type="dcterms:UDC"> 061(410) </dc:subject> <dc:description> UKOLN is a national focus of expertise in digital information management. It provides policy, research and awareness services to the UK library, information and cultural heritage communities. UKOLN is based at the University of Bath. </dc:description> <dc:description xml:lang="fr"> UKOLN est un centre national d'expertise dans la gestion de l'information digitale. </dc:description> <dc:publisher> UKOLN, University of Bath </dc:publisher> <dcterms:isPartOf xsi:type="dcterms:URI"> http://www.bath.ac.uk/ </dcterms:isPartOf> <dc:identifier xsi:type="dcterms:URI"> http://www.ukoln.ac.uk/ </dc:identifier> <dcterms:modified xsi:type="dcterms:W3CDTF"> 2001-07-18 </dcterms:modified> <dc:format xsi:type="dcterms:IMT"> text/html </dc:format> <dcterms:extent> 14 Kbytes </dcterms:extent> </metadata> 120 121 Anexo 3. Atividades do subprocesso de arquivo "Gerar Documento" Quadro referente às atividades do subprocesso de arquivo "Gerar Documento" (QualiFEUP 2007) Atividade Definição Âmbito de Aplicação Execução Analisar Quadro Legal e Normativo A análise do quadro legal e normativo consiste na pesquisa, recolha e estudo dos diplomas legais e outros instrumentos normativos e reguladores da constituição orgânica e funcional da entidade que produz a informação. Respeita ainda a síntese dos requisitos legais e os fundamentos da missão, organização e funcionamento institucional que sustentam as atividades desenvolvidas pela entidade e permitem compreender e contextualizar a informação. Contexto legal e normativo da constituição orgânica e funcional de entidades. Estudo da evolução das entidades produtoras de arquivo. Técnico Superior de Arquivo Caracterizar Atividades Este exercício materializa-se na identificação, definição e caracterização do conjunto de atividades e processos organizacionais desenvolvidos pela entidade para prossecução da sua missão e objectivos e cumprimento das competências atribuídas pelo quadro legal e normativo. Enquadramento e caracterização das atividades e dos processos organizacionais desenvolvidos por entidades produtoras de informação. Documentar o comportamento da entidade relativamente ao seu quadro legal e normativo. Técnico Superior de Arquivo Definir a Produção e os Fluxos da Informação Trata-se de fazer o enquadramento, a identificação e a definição da produção da informação, como suporte e evidência das atividades desenvolvidas pela entidade, e do circuito da informação, quer no contexto de fluxo de trabalho dessas mesmas atividades (tramitação) quer no contexto de integração e transferência da informação (circulação). Análise de produção da informação e do sistema de circulação e circuitos da informação. Técnico Superior de Arquivo Estruturar Metadados do Documento Consiste na definição, estruturação e descrição dos dados necessários a reter para possibilitar a corporização da informação num suporte e criar assim o(s) documento(s). A estruturação dos dados em documento permite a inteligibilidade e preservação da informação produzida no desenvolvimento das atividades, bem como a sua recuperação eficaz e a compreensão do contexto organizacional e funcional de onde resulta. Estruturação dos dados em documento e fixação da informação em meios que permitam o seu registo, a sua caracterização, comunicação, preservação e exploração. Técnico Superior de Arquivo Integrar Estrutura do Documento no Modelo de Arquivo Integração do documento em quadro de classificação com base no contexto orgânico-funcional da entidade, em séries documentais e em unidades de instalação e respectivos suportes de acondicionamento. Estabelecer uma organização dos documentos de arquivo por recurso à caracterização da natureza que lhe serviu de génese e à adopção de um plano lógico de classificação. Concepção e gestão dos arquivos correntes das unidades e sectores orgânicos da entidade. Elaboração de instrumentos de acesso e de recuperação de informação. Técnico Superior de Arquivo 128 129 Anexo 7. Fluxo de trabalho para criação de novos cursos Tabela referente ao fluxo de trabalho da primeira fase do processo relativo a criação de novos cursos, relativo à elaboração e aprovação interna do novo curso (Sousa 2008) Proponentes Elaborar e submeter proposta Conselho Científico da FEUP Analisar e pronunciar-se sobre a proposta Conselho Pedagógico da FEUP Emitir parecer sobre a proposta Conselho diretivo da FEUP Aprovar proposta SERAC Elaborar ofício de acompanhamento da proposta Enviar proposta à Reitoria Diretor da FEUP Assinar ofício e proposta 130 Tabela referente ao fluxo de trabalho da segunda fase do processo relativo a criação de novos cursos, relativo à aprovação externa e publicação em DR do novo curso (Sousa 2008) Secção Permanente do Senado da U.Porto Deliberar sobre a proposta DGES Aprovar a proposta e atribuir n.º de registo Reitoria da U.Porto Recepcionar despacho de deferimento e enviar à FEUP Publicar em DR SERAC Recepcionar despacho e informar Direção e Proponentes Analisar o DR Publicar o regulament o do curso no sistema de informação Proponentes Verificar a publicação do novo curso em DR OCES 131 Tabela referente ao fluxo de trabalho da terceira fase do processo relativo a criação de novos cursos, relativo à nomeação dos órgãos de gestão do novo curso (Sousa 2008) Diretor da FEUP Designar Diretor do Curso Assinar o Termo de Posse Homologar Comissão Científica Diretor de Curso Designar Comissão Científica Comissão Científica do Curso Nomear a Comissão de Acompanhamento do Curso Tabela referente ao fluxo de trabalho da terceira fase do processo relativo a criação de novos cursos, relativo ao registo da informação do curso nas bases de dados (Sousa 2008) DGES Atualizar ficheiro SERAC Verificar atualização Inserir no GAUP o novo curso CICA 132 133 Anexo 8. Lista descritiva dos campos das tabelas de Cursos Tabela da BD "cur_areas_cient_predomina" com o registo das áreas científicas predominantes no curso Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Não Identificador do registo area_cient_id Numérico Sim Identificador da área científica curso_id Numérico Sim Identificador do curso a_lect_inicio Numérico Sim Início do ano lectivo a_lect_fim Numérico Não Fim do ano lectivo ts_actualizado Data Sim Ultima atualização do registo Tabela da BD "cur_cursos" com o registo dos cursos Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Sim Identificador do registo codigo Texto Não Código oficial do curso sigla Texto Sim Identificador do curso nome Texto Sim Início do ano lectivo name Texto Não Fim do ano lectivo duracao_anos_curr Numérico Não Duração do Curso convertido em anos curriculares duracao Numérico Não Duração do curso duracao_tipo Texto Não Tipo de duração a_lect_inicio Numérico Sim Ano lectivo do inicio de funcionamento do curso a_lect_fim Numérico Não Ano lectivo do fim de funcionamento do curso modo_funcionamento Texto Sim Modo de funcionamento do curso estatuto_bolonha Texto Não Se o curso tem estatuto bolonha a_lect_bolonha Numérico Não Ano lectivo em que o Curso foi criado ou adaptado e Bolonha ciclo_inicio Texto Não Início do ciclo de estudos ciclo_fim Texto Não Fim do ciclo de estudos nome_abreviado Texto Não Nome abreviado do curso 134 ts_actualizado Data Sim Ultima atualização do registo tipo Texto Não Tipo de curso: Bacharelato, Licenciatura, Mestrado integrado, Mestrado, Doutoramento, Atualização, Especialização, Estudos avançados, ... duracao_horas Numérico Não Duração em horas do curso d_aprovacao Data Não Data de aprovação acreditacao_a3es Texto Não Se o curso tem acreditação A3ES d_acreditacao_a3es Data Não Data da acreditação A3ES a_lect_acreditacao_a3es Numérico Não Ano lectivo da acreditação A3ES formula_id Numérico Não Fórmula de calculo da média Tabela da BD "cur_cursos_global" com o registo global de cursos Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Sim Identificador do registo instituicao_id Numérico Sim Identificação da Instituição curso_id Numérico Não Identificador do curso codigo Texto Não Código nome Texto Sim Nome a_lect_inicio Numérico Não Data de início do ano lectivo a_lect_fim Numérico Não Data de fim do ano lectivo ts_actualizado Data Sim Ultima atualização do registo ciclo_inicio Texto Não Grau de inicio ciclo_fim Texto Não Grau de fim Tabela da BD "cur_cursos_sucessao" com o registo da sequência sucessiva de cursos Nome da Coluna Tipo de Dados Obrigatório Descrição curso_id Numérico Sim Identificador do curso curso_anterior_id Numérico Sim Identificador do curso anterior ts_actualizado Data Sim Ultima atualização do registo 135 Tabela da BD "cur_cursos_tipos" com a indicação do tipo de cursos Nome da Coluna Tipo de Dados Obrigatório Descrição nome Texto Sim Nome estatuto Texto Sim Estatuto grau_academico_max Texto Não Máximo de grau académico creditos_ects_min Numérico Não Mínimo de créditos ECTS creditos_ects_max Numérico Não Máximo de créditos ECTS ciclo_min Texto Não Grau Mínimo ciclo_max Texto Não Grau Máximo obs Texto Não Observações ts_actualizado Data Sim Ultima atualização do registo sigla Texto Sim Sigla name Texto Não Nome em Inglês Tabela da BD "cur_dipl_componentes" com a indicação das componentes dos diplomas Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Sim Identificador do registo diploma_id Numérico Sim Identificador do diploma componente_id Numérico Não Identificador da componente unidade_curricular_id Numérico Não Identificador da unidade curricular ts_actualizado Data Sim Ultima atualização do registo acurr_inicio Numérico Não Inicio do Ano Corrente acurr_fim Numérico Não Fim do ano Corrente ucurr_tipo Texto Não Tipo de unidade curricular Tabela da BD "cur_diplomas" com os registos dos diplomas Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Sim Identificador do registo curso_id Numérico Sim Identificador do Curso nome Texto Sim Nome 136 name Texto Não Nome em Inglês curso_conclusao Texto Sim Indica se o diploma corresponde à conclusão de curso a_lect_inicio Numérico Sim Data de início do ano lectivo a_lect_fim Numérico Não Data de fim do ano lectivo nivel_academico_id Numérico Sim Identificador do nível académico percurso_alt_id Numérico Não Identificador do percurso alternativo ciclo Texto Não Ciclo de estudos duracao Numérico Não Duração duracao_tipo Texto Não Tipo de duração ts_actualizado Data Sim Ultima atualização do registo creditos_min Numérico Não Nª mínimo de créditos do diploma componentes_aprovar Texto Não Componentes a aprovar estrutura_curricular Texto Não Diploma de tronco comum creditos_inst_min Numérico Não Créditos mínimos na instituição formula_id Numérico Não Fórmula de Calculo da média Tabela da BD "cur_diplomas_suplementos" com o registo dos suplementos dos diplomas Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Sim Identificador do registo diploma_id Numérico Sim Identificador do diploma estatuto_prof Texto Não Estatuto do profissional prof_status Texto Não Estatuto do profissional req_prog_estudos Texto Não Requisitos para o programa prog_requirements Texto Não Requisitos para o programa acesso_nivel_sup Texto Não A que nível este grau dá acesso access_further_study Texto Não A que nível este grau dá acesso req_acesso Texto Não Requisitos de acesso access_requirements Texto Não Requisitos de acesso a_lect_inicio Numérico Sim Data de início do ano lectivo a_lect_fim Numérico Não Data de fim do ano lectivo 137 ts_actualizado Data Sim Ultima atualização do registo Tabela da BD "cur_edicoes" com o registo das edições dos cursos Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Sim Identificador do registo curso_id Numérico Sim Identificador do Curso a_lect_inicio Numérico Sim Ano lectivo do inicio da e admissão de candidatos a_lect_fim Numérico Não Ano lectivo de fim de admissão de candidatos fase Numérico Sim Nº de fase na edição d_inicio Data Não Data de início d_fim Data Não Data de fim calend_desfas_periodo Texto Não Posicionamento do início da edição relativamente ao calendário escolar n_min_estudantes Numérico Não Nº min de estudantes para a edição poder funcionar minor Texto Não Esta edição pode ser oferecida como “minor” a algum estudante? regime_horario Texto Não Regime a nível de horário regime_presenca Texto Não Regime a nível de presenças ts_actualizado Data Sim Ultima atualização do registo edicao_func Texto Sim Edição de funcionamento seriacao_percurso_alt Texto Não Critérios de seleção e seriação n_clausus Numérico Não Numero máximo de alunos propina Numérico Não Valor da propina regime_dedicacao Texto Não Regime de dedicação req_acesso Texto Não Regime de acesso crit_sel_seriacao Texto Não Critérios de seleção e seriação obs Texto Não Observações Tabela da BD "cur_instituicoes" com o registo das instituições Nome da Coluna Tipo de Dados Obrigatório Descrição id Numérico Sim Identificador do registo 144 145 Anexo 10. Código Perl para gerar SIP’s de Cursos (sipgen.pl) #!/usr/bin/perl -w # Name: SIPGen # Description: Submission Information Package Generator for FEUP courses # Creator: Bruno Rego # Crate Date: 2013/04/07 use warnings; use strict; use POSIX qw(strftime); use DBI; use Text::CSV; use Cwd; use Digest::SHA1 qw(sha1); $ENV{'NLS_LANG'} = 'PORTUGUESE_PORTUGAL.AL32UTF8'; my $version = "1.0"; my $logItLevelError = 'ERROR'; my $logItLevelWarning = 'WARN'; my $logItLevelInformation = 'INFO'; my $logItLevelLine = ''; my $courseAcronym = ''; my $scriptPath = getcwd.'/../'; my $tempPath = $scriptPath.'temp/'; my $logPath = $scriptPath.'log/'; my $outputPath = $scriptPath.'output/'; my $tempDir = ''; my $sipName = ''; my $dbConn = undef; my $dbInfo = ''; my $dbLogin = ''; my %fileInfo; my $startDatetime = time; # Create temporary dir and make database connection sub PrepareExport { $sipName = "sigarra_cursos_".$courseAcronym."_".strftime("%Y%m%d%H%M%S", localtime($startDatetime))."_[io.ip.sip]"; # create temporary dir $tempDir = $sipName.'/'; unless(mkdir $tempPath.$tempDir) { LogItDie("Unable to create directory '".$tempPath.$tempDir."'"); } LogIt($logItLevelInformation, "Created the directory '".$tempPath.$tempDir."'"); # create connection to database $dbConn = DBI->connect('dbi:Oracle:'.$dbInfo, $dbLogin) or LogItDie("Unable to connect to oracle database with ".$dbInfo); # set session parameters $dbConn->do("ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD\"T\"HH24:MI:SS'") or LogItDie("Unable to set session NLS_DATE_FORMAT"); $dbConn->do("ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD\"T\"HH24:MI:SS'") or LogItDie("Unable to set session NLS_TIMESTAMP_FORMAT"); $dbConn->do("ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ', '") or LogItDie("Unable to set session NLS_NUMERIC_CHARACTERS"); $dbConn->do("ALTER SESSION SET TIME_ZONE = 'Europe/Lisbon'") or LogItDie("Unable to set session TIME_ZONE"); LogIt($logItLevelInformation, "Connected to oracle database with ".$dbInfo); return 0; } # Get table information and insert into CSV file sub ExportSQLTable { 146 my ( $csvFilename, $sql ) = @_; my $csvFullPath = $tempPath.$tempDir.$csvFilename; my $csv = Text::CSV->new( { binary => 1, eol => "\015\012" } ) or LogItDie("Cannot use CSV: ".Text::CSV->error_diag()); open my $csvFile, ">:raw", $csvFullPath or LogItDie("Cannot open CSV file '".$csvFullPath."'"); LogIt($logItLevelInformation, "Created the CSV file '".$csvFullPath."'"); my $query = $dbConn->prepare($sql); LogIt($logItLevelInformation, "Execute the query '".$sql."'"); $query->execute(); $csv->print($csvFile, $query->{NAME}); while(my $row = $query->fetchrow_arrayref) { $csv->print($csvFile, [ map { $_ } @$row ]); } close $csvFile or LogItDie("Cannot close CSV file '".$csvFullPath."'"); LogIt($logItLevelInformation, "Closed CSV file '".$csvFullPath."'"); LogIt($logItLevelInformation, "Calculate SHA1 hash key."); open(CSVFILE, "<".$csvFullPath) or LogItDie("Cannot open CSV file '".$csvFullPath."'"); binmode(CSVFILE); my $sha1 = Digest::SHA1->new; $sha1->addfile(*CSVFILE); $fileInfo{$csvFilename}{SHA1} = $sha1->hexdigest(); close(CSVFILE); $fileInfo{$csvFilename}{CREATEDATE} = strftime("%Y-%m-%dT%H:%M:%S", localtime(time)); $fileInfo{$csvFilename}{SIZE} = -s $csvFullPath; } #Get all the tables information sub ExecuteExport { ExportSQLTable("cur_cursos.csv","SELECT * FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_cursos_sucessao.csv","SELECT * FROM cur_cursos_sucessao WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_cursos_tipos.csv","SELECT * FROM cur_cursos_tipos WHERE sigla IN (SELECT tipo FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_orga_creditos.csv","SELECT * FROM cur_orga_creditos WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_cursos_global.csv","SELECT * FROM cur_cursos_global WHERE codigo IN (SELECT codigo FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_instituicoes_cursos.csv","SELECT * FROM cur_instituicoes_cursos WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_edicoes.csv","SELECT * FROM cur_edicoes WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_areas_cient_predomina.csv","SELECT * FROM cur_areas_cient_predomina WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_sis_funcionamento.csv","SELECT * FROM cur_sis_funcionamento WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_sfunc_niveis_ucurr.csv","SELECT csnu.* FROM cur_sfunc_niveis_ucurr csnu JOIN cur_sis_funcionamento csf ON (csnu.sis_funcionamento_id = csf.id) JOIN cur_cursos cc ON (csf.curso_id = cc.id) WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_sfunc_periodos.csv","SELECT csp.* FROM cur_sfunc_periodos csp JOIN cur_sis_funcionamento csf ON (csp.sis_funcionamento_id = csf.id) JOIN cur_cursos cc ON (csf.curso_id = cc.id) WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_sfunc_ano_curr_acesso.csv","SELECT csaca.* FROM cur_sfunc_ano_curr_acesso csaca JOIN cur_sis_funcionamento csf ON (csaca.sis_funcionamento_id = csf.id) JOIN cur_cursos cc ON (csf.curso_id = cc.id) WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_diplomas.csv","SELECT * FROM cur_diplomas WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); ExportSQLTable("cur_niveis_academicos.csv","SELECT cna.* FROM cur_niveis_academicos cna JOIN cur_diplomas cd ON (cd.nivel_academico_id = cna.id) JOIN cur_cursos cc ON (cd.curso_id = cc.id) WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_diplomas_suplementos.csv","SELECT cds.* FROM cur_diplomas_suplementos cds JOIN cur_diplomas cd ON (cds.diploma_id = cd.id) JOIN cur_cursos cc ON (cd.curso_id = cc.id) WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_dipl_componentes.csv","SELECT cdc.* FROM cur_dipl_componentes cdc JOIN cur_diplomas cd ON (cdc.diploma_id = cd.id) JOIN cur_cursos cc ON (cd.curso_id = cc.id) WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_mencoes.csv","SELECT cm.* FROM cur_mencoes cm JOIN cur_diplomas cd ON (cm.diploma_id = cd.id) JOIN cur_cursos cc ON (cd.curso_id = cc.id) WHERE lower(sigla) = '".$courseAcronym."'"); ExportSQLTable("cur_percursos_alternativos.csv","SELECT * FROM cur_percursos_alternativos WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = '".$courseAcronym."')"); } # Create METS file for SIP package (sip.xml) sub CreateMETSFile { 147 my $metsFile = "sip.xml"; my $currentDay = strftime("%Y-%m-%d", localtime($startDatetime)); my $currentISODatetime = strftime("%Y-%m-%dT%H:%M:%S", localtime($startDatetime)); open(METSFILE, ">".$tempPath.$tempDir.$metsFile) or LogItDie("Cannot open METS file '".$tempPath.$metsFile."'"); print METSFILE qq^<?xml version="1.0" encoding="UTF-8"?> <METS:mets xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:METS="http://www.loc.gov/METS/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd http://purl.org/dc/elements/1.1/ http://www.dublincore.org/schemas/xmls/simpledc20021212.xsd" OBJID="$sipName" LABEL="Informação detalhada do curso $courseAcronym para o dia $currentDay" TYPE="application/sip.curso+xml"> <METS:metsHdr CREATEDATE="$currentISODatetime" RECORDSTATUS="Complete"> <METS:agent ROLE="CREATOR" TYPE="ORGANIZATION"> <METS:name>CICA</METS:name> </METS:agent> </METS:metsHdr> <METS:dmdSec ID="dmd1"> <METS:mdWrap MIMETYPE="text/xml" MDTYPE="DC" LABEL="Simple Dublin Core"> <METS:xmlData> <dc:title>Descritor do SIP referente ao curso $courseAcronym</dc:title> <dc:creator>CICA</dc:creator> <dc:subject>SIP, Curso $courseAcronym, Universidade do Porto</dc:subject> <dc:description>Este pacote contem informação detalhada sobre o curso $courseAcronym. É uma extração com toda a informação que estava presente no dia da geração deste pacote.</dc:description> <dc:publisher>Universidade do Porto</dc:publisher> <dc:contributor>CICA</dc:contributor> <dc:date>$currentISODatetime</dc:date> <dc:identifier>$sipName.zip</dc:identifier> <dc:language>pt-PT</dc:language> <dc:relation>Faz parte dos Cursos da Universidade do Porto</dc:relation> <dc:coverage></dc:coverage> </METS:xmlData> </METS:mdWrap> </METS:dmdSec> <METS:amdSec> <METS:techMD ID="amdt1"> <METS:mdWrap MIMETYPE="text/xml" MDTYPE="DC" LABEL="Simple Dublin Core"> <METS:xmlData> <dc:type>Text</dc:type> <dc:format>application/sip.curso+xml</dc:format> </METS:xmlData> </METS:mdWrap> </METS:techMD> <METS:rightsMD ID="amdr1"> <METS:mdWrap MIMETYPE="text/xml" MDTYPE="DC" LABEL="Simple Dublin Core"> <METS:xmlData> <dc:rights>Acesso limitado ao CICA e Arquivo da FEUP</dc:rights> </METS:xmlData> </METS:mdWrap> </METS:rightsMD> <METS:sourceMD ID="amds1"> <METS:mdWrap MIMETYPE="text/xml" MDTYPE="DC" LABEL="Simple Dublin Core"> <METS:xmlData> <dc:source>SIGARRA</dc:source> </METS:xmlData> </METS:mdWrap> </METS:sourceMD> <METS:digiprovMD ID="amdd1"> <METS:mdWrap MIMETYPE="text/xml" MDTYPE="DC" LABEL="Simple Dublin Core"> <METS:xmlData> <dc:creator>CICA</dc:creator> </METS:xmlData> </METS:mdWrap> </METS:digiprovMD> </METS:amdSec> 148 <METS:fileSec> <METS:fileGrp ID="fgrp1" USE="Submission Information Package"> <METS:file ID="fid1" MIMETYPE="text/csv" SEQ="1" CREATED="$fileInfo{'cur_cursos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_cursos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_cursos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_cursos.csv"/> </METS:file> <METS:file ID="fid2" MIMETYPE="text/csv" SEQ="2" CREATED="$fileInfo{'cur_cursos_sucessao.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_cursos_sucessao.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_cursos_sucessao.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_cursos_sucessao.csv"/> </METS:file> <METS:file ID="fid3" MIMETYPE="text/csv" SEQ="3" CREATED="$fileInfo{'cur_cursos_tipos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_cursos_tipos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_cursos_tipos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_cursos_tipos.csv"/> </METS:file> <METS:file ID="fid4" MIMETYPE="text/csv" SEQ="4" CREATED="$fileInfo{'cur_orga_creditos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_orga_creditos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_orga_creditos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_orga_creditos.csv"/> </METS:file> <METS:file ID="fid5" MIMETYPE="text/csv" SEQ="5" CREATED="$fileInfo{'cur_cursos_global.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_cursos_global.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_cursos_global.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_cursos_global.csv"/> </METS:file> <METS:file ID="fid6" MIMETYPE="text/csv" SEQ="6" CREATED="$fileInfo{'cur_instituicoes_cursos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_instituicoes_cursos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_instituicoes_cursos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_instituicoes_cursos.csv"/> </METS:file> <METS:file ID="fid7" MIMETYPE="text/csv" SEQ="7" CREATED="$fileInfo{'cur_edicoes.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_edicoes.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_edicoes.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_edicoes.csv"/> </METS:file> <METS:file ID="fid8" MIMETYPE="text/csv" SEQ="8" CREATED="$fileInfo{'cur_areas_cient_predomina.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_areas_cient_predomina.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_areas_cient_predomina.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_areas_cient_predomina.csv"/> </METS:file> <METS:file ID="fid9" MIMETYPE="text/csv" SEQ="9" CREATED="$fileInfo{'cur_sis_funcionamento.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_sis_funcionamento.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_sis_funcionamento.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_sis_funcionamento.csv"/> </METS:file> <METS:file ID="fid10" MIMETYPE="text/csv" SEQ="10" CREATED="$fileInfo{'cur_sfunc_niveis_ucurr.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_sfunc_niveis_ucurr.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_sfunc_niveis_ucurr.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_sfunc_niveis_ucurr.csv"/> </METS:file> <METS:file ID="fid11" MIMETYPE="text/csv" SEQ="11" CREATED="$fileInfo{'cur_sfunc_periodos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_sfunc_periodos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_sfunc_periodos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_sfunc_periodos.csv"/> </METS:file> <METS:file ID="fid12" MIMETYPE="text/csv" SEQ="12" CREATED="$fileInfo{'cur_sfunc_ano_curr_acesso.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_sfunc_ano_curr_acesso.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_sfunc_ano_curr_acesso.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_sfunc_ano_curr_acesso.csv"/> </METS:file> <METS:file ID="fid13" MIMETYPE="text/csv" SEQ="13" CREATED="$fileInfo{'cur_diplomas.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_diplomas.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_diplomas.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_diplomas.csv"/> </METS:file> <METS:file ID="fid14" MIMETYPE="text/csv" SEQ="14" CREATED="$fileInfo{'cur_niveis_academicos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_niveis_academicos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_niveis_academicos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_niveis_academicos.csv"/> </METS:file> <METS:file ID="fid15" MIMETYPE="text/csv" SEQ="15" CREATED="$fileInfo{'cur_diplomas_suplementos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_diplomas_suplementos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_diplomas_suplementos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_diplomas_suplementos.csv"/> </METS:file> 149 <METS:file ID="fid17" MIMETYPE="text/csv" SEQ="17" CREATED="$fileInfo{'cur_dipl_componentes.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_dipl_componentes.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_dipl_componentes.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_dipl_componentes.csv"/> </METS:file> <METS:file ID="fid18" MIMETYPE="text/csv" SEQ="18" CREATED="$fileInfo{'cur_mencoes.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_mencoes.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_mencoes.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_mencoes.csv"/> </METS:file> <METS:file ID="fid19" MIMETYPE="text/csv" SEQ="19" CREATED="$fileInfo{'cur_percursos_alternativos.csv'}{CREATEDATE}" SIZE="$fileInfo{'cur_percursos_alternativos.csv'}{SIZE}" CHECKSUM="$fileInfo{'cur_percursos_alternativos.csv'}{SHA1}" CHECKSUMTYPE="SHA1"> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="cur_percursos_alternativos.csv"/> </METS:file> </METS:fileGrp> </METS:fileSec> <METS:structMap ID="sm1" TYPE="logical"> <METS:div TYPE="Submission Information Package" LABEL="pacote com informação descritiva do curso $courseAcronym" DMDID="dmd1"> <METS:div TYPE="Informação Geral" LABEL="Informação do curso"> <METS:div TYPE="Informação Geral" LABEL="Informação geral do curso"> <METS:fptr FILEID="fid1" /> </METS:div> <METS:div TYPE="Informação Específica" LABEL="Informação especifica do curso"> <METS:div TYPE="Informação Geral" LABEL="Organização dos créditos do curso"> <METS:fptr FILEID="fid4" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Tipos de cursos"> <METS:fptr FILEID="fid3" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Descrição das edições do curso"> <METS:fptr FILEID="fid2" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Sucessão do curso"> <METS:fptr FILEID="fid7" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Instituições relacionadas com o curso"> <METS:fptr FILEID="fid6" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Lista de cursos global"> <METS:fptr FILEID="fid5" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Áreas científicas predominantes"> <METS:fptr FILEID="fid8" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Percursos alternativos do curso"> <METS:fptr FILEID="fid19" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Informação geral dos sistemas de funcionamento do curso"> <METS:div TYPE="Informação Geral" LABEL="Sistema de funcionamento do curso"> <METS:fptr FILEID="fid9" /> </METS:div> <METS:div TYPE="Informação Específica" LABEL="Informação específica dos sistemas de funcionamento do curso"> <METS:div TYPE="Informação Geral" LABEL="Níveis currentes"> <METS:fptr FILEID="fid10" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Periodos"> <METS:fptr FILEID="fid11" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Ano currente de acesso"> <METS:fptr FILEID="fid12" /> </METS:div> </METS:div> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Informação geral dos diplomas do curso"> <METS:div TYPE="Informação Geral" LABEL="Diplomas do curso"> <METS:fptr FILEID="fid13" /> </METS:div> <METS:div TYPE="Informação Específica" LABEL="Informação específica dos diplomas do curso"> <METS:div TYPE="Informação Geral" LABEL="Níveis académicos"> <METS:fptr FILEID="fid14" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Suplementos ao diploma"> <METS:fptr FILEID="fid15" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Menções"> 150 <METS:fptr FILEID="fid18" /> </METS:div> <METS:div TYPE="Informação Geral" LABEL="Componentes do diploma"> <METS:fptr FILEID="fid17" /> </METS:div> </METS:div> </METS:div> </METS:div> </METS:div> </METS:div> </METS:structMap> </METS:mets> ^; close(METSFILE); LogIt($logItLevelInformation, "Created the METS file for SIP package '".$tempPath.$metsFile."'"); } # Create SIP Package in output directory sub CreateSIP { !system("zip -qXr9Dj ".$tempPath.$sipName.".zip ".$tempPath."'".$sipName."'/* && mv ".$tempPath.$sipName.".zip ".$outputPath) or LogItDie("Unable to zip the files and create the SIP package"); LogIt($logItLevelInformation, "Created the SIP file '".$outputPath.$sipName.".zip'"); } # Terminate database connection and removes the temporary directory sub TerminateExport { if (defined $dbConn) { $dbConn->disconnect; $dbConn = undef; LogIt($logItLevelInformation, "Closed the connection to database"); } if ($tempDir ne '') { my $dir = $tempDir; $tempDir = ''; !system("rm -rf ".$tempPath.$dir) or LogItDie("Unable to remove the directory '".$tempPath.$dir."'"); LogIt($logItLevelInformation, "Removed the directory '".$tempPath.$dir."'"); } } # Verify command line arguments sub VerifyArguments { if ($#ARGV != 5 ) { print "SIPGen ".$version."\nusage: sipgen <course acronym> <host> <port> <sid> <login> <password>\n"; LogIt($logItLevelError, "Invalid number of arguments"); LogIt($logItLevelInformation, "End SIPGen"); exit; } else { $courseAcronym = lc($ARGV[0]); $dbInfo = 'host='.$ARGV[1].';sid='.$ARGV[3].';port='.$ARGV[2]; $dbLogin = $ARGV[4].'/'.$ARGV[5]; LogIt($logItLevelInformation, "Processing data for course acronym '".$courseAcronym."'"); } } # Logs the information and dies afterwards sub LogItDie { my ( $message ) = @_; 151 LogIt($logItLevelError, $message); TerminateExport(); LogIt($logItLevelInformation, "End SIPGen"); exit 1; } # Logs all the information on log directory sub LogIt { my ( $level, $message ) = @_; my $logFile = $logPath."sipgen_".strftime("%Y%m%d", localtime($startDatetime)).".log"; open(LOGFILE, ">>".$logFile) or die "Cannot open file ".$logFile; if ($level eq $logItLevelLine) { print LOGFILE "\n"; } elsif ($level eq $logItLevelError) { print LOGFILE strftime("%Y-%m-%d %H:%M:%S", localtime(time))." ".$level." ".$message."\n"; } else { print LOGFILE strftime("%Y-%m-%d %H:%M:%S", localtime(time))." ".$level." ".$message."\n"; } close(LOGFILE); } # Main function to start sub Main { LogIt($logItLevelLine, ""); LogIt($logItLevelInformation, "Start SIPGen ".$version); VerifyArguments(); PrepareExport(); ExecuteExport(); CreateMETSFile(); CreateSIP(); TerminateExport(); LogIt($logItLevelInformation, "End SIPGen"); } Main(); exit 0; 152 153 Anexo 11. Ficheiro log referente à criação de um SIP 2013-05-15 00:56:08 INFO Start SIPGen 1.0 2013-05-15 00:56:08 ERROR Invalid number of arguments 2013-05-15 00:56:08 INFO End SIPGen 2013-05-15 00:56:21 INFO Start SIPGen 1.0 2013-05-15 00:56:21 INFO Processing data for course acronym 'dce' 2013-05-15 00:56:21 INFO Created the directory '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/' 2013-05-15 00:56:23 INFO Connected to oracle database with host=localhost;sid=ubuntu;port=1521 2013-05-15 00:56:23 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos.csv' 2013-05-15 00:56:23 INFO Execute the query 'SELECT * FROM cur_cursos WHERE lower(sigla) = 'dce'' 2013-05-15 00:56:23 INFO Closed CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos.csv' 2013-05-15 00:56:23 INFO Calculate SHA1 hash key. 2013-05-15 00:56:23 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos_sucessa o.csv' 2013-05-15 00:56:24 INFO Execute the query 'SELECT * FROM cur_cursos_sucessao WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = 'dce')' 2013-05-15 00:56:24 INFO Closed CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos_sucessa o.csv' 2013-05-15 00:56:24 INFO Calculate SHA1 hash key. 2013-05-15 00:56:24 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos_tipos.cs v' 2013-05-15 00:56:24 INFO Execute the query 'SELECT * FROM cur_cursos_tipos WHERE sigla IN (SELECT tipo FROM cur_cursos WHERE lower(sigla) = 'dce')' 2013-05-15 00:56:24 INFO Closed CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos_tipos.cs v' 2013-05-15 00:56:24 INFO Calculate SHA1 hash key. 2013-05-15 00:56:24 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_orga_creditos.c sv' 2013-05-15 00:56:24 INFO Execute the query 'SELECT * FROM cur_orga_creditos WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = 'dce')' 2013-05-15 00:56:24 INFO Closed CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_orga_creditos.c sv' 2013-05-15 00:56:24 INFO Calculate SHA1 hash key. 2013-05-15 00:56:24 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos_global.c sv' 2013-05-15 00:56:24 INFO Execute the query 'SELECT * FROM cur_cursos_global WHERE codigo IN (SELECT codigo FROM cur_cursos WHERE lower(sigla) = 'dce')' 2013-05-15 00:56:24 INFO Closed CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_cursos_global.c sv' 2013-05-15 00:56:24 INFO Calculate SHA1 hash key. 2013-05-15 00:56:24 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_instituicoes_cu rsos.csv' 2013-05-15 00:56:24 INFO Execute the query 'SELECT * FROM cur_instituicoes_cursos WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = 'dce')' 2013-05-15 00:56:24 INFO Closed CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_instituicoes_cu rsos.csv' 2013-05-15 00:56:24 INFO Calculate SHA1 hash key. 2013-05-15 00:56:24 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_edicoes.csv' 2013-05-15 00:56:24 INFO Execute the query 'SELECT * FROM cur_edicoes WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = 'dce')' 2013-05-15 00:56:24 INFO Closed CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_edicoes.csv' 2013-05-15 00:56:24 INFO Calculate SHA1 hash key. 2013-05-15 00:56:24 INFO Created the CSV file '/home/oracle/dissertacao/sip_cursos_gen/bin/../temp/sigarra_cursos_dce_20130515005621_[io.ip.sip]/cur_areas_cient_pr edomina.csv' 2013-05-15 00:56:24 INFO Execute the query 'SELECT * FROM cur_areas_cient_predomina WHERE curso_id IN (SELECT id FROM cur_cursos WHERE lower(sigla) = 'dce')'