AAA - Arquivo Aberto de trabalhos de Alunos

Projeto Integrado de Engenharia de Linguagens 2013/2014

José Carlos Ramalho

Historial:

---

Índice

1. Introdução
2. O Repositório
3. SIP e o processo de Ingestão
   1. Validação do SIP
   2. Armazenamento do SIP
4. AIP e o armazenamento de projectos
5. DIP e a disseminação/publicação de conteúdos
6. Processo de Administração

---

Introdução

[Voltar ao índice]

No dia a dia de uma instituição universitária produzem-se centenas de trabalhos, com mais ou menos profundidade, pelos alunos dessa instituição.

Muitos desses trabalhos acabam na prateleira do professor uma vez avaliados.

Neste projecto, pretende-se arquivar de forma segura esses projectos e garantir o acesso continuado a toda esta informação. Desta forma, poderemos promover a troca de ideias e dar alguma visibilidade a projectos e alunos que de outra forma seriam ignorados.

O Repositório

[Voltar ao índice]

O A3 deverá ser implementado seguindo as orientações do modelo OAIS (figura 1).

Figura 1: Modelo de referência OAIS

Como se pode ver pela figura, o sistema terá de interagir com três tipos de actores:

Produtor:

Corresponde a todos os que produziram um trabalho e que o querem e vão depositar no A3. No nosso contexto, os produtores serão os alunos individualmente ou os grupos de alunos quando estes se organizarem em grupo;

Administrador:

Como o próprio nome indica é alguém com capacidade de mudar e de introduzir alterações ao funcionamento do sistema: ativar um workflow para a submissão de um trabalho, criar utilizadores e disciplinas,etc. Este papel será maioritariamente desempenhado pelos docentes;

Consumidor:

Corresponde ao futuro utilizador do repositório. Dirigir-se-á a este para consultar e pesquisar informação relativa aos projectos arquivados. Pode ser qualquer utilizador do universo Web.

Em termos funcionais, o sistema é constituído por 3 megaprocessos:

Ingestão:

Processo responsável pela recepção/depósito de materiais a arquivar;

Administração:

Processo responsável pela gestão interna do sistema: gestão dos objectos arquivados, gestão de utilizadores, produção de estatísticas, etc.

Disseminação:

Processo responsável pela disseminação/distribuição/publicação dos objectos arquivados. Um disseminador tanto pode fornecer ao consumidor final um ZIP com a informação pretendida como pode gerar um website que permita áquele navegar no repositório e visualizar a informação pública.

De acordo com o OAIS, temos três tipos de pacotes de informação a circular no sistema:

SIP ("Submission Information Package"):

Pacote que é enviado pelo produtor ao sistema para ser processado e arquivado. A sua estrutura terá de ser especificada no início do projecto.

AIP ("Archival Information Package"):

Pacote arquivado, ou seja, um SIP depois de processado e armazenado torna-se num AIP. Este terá uma determinada estrutura que irá depender da forma como será armazenado: base de dados relacional, ficheiro XML, conjunto de pares atributo valor, etc.

DIP ("Dissemination Information Package"):

Pacote oferecido ao consumidor. Tanto poderá ser um website a partir do qual aquele consiga navegar nos conteúdos como pode ser um ficheiro ZIP com um conjunto de conteúdos previamente seleccionados.

Nas secções seguintes iremos detalhar um pouco os requisitos pretendidos para o projecto. Como estes estão muito relacionados com os pacotes de informação que circulam no sistema vamos começar por definir o que se pretende para cada um deles.

SIP e o processo de Ingestão

[Voltar ao índice]

Começamos por definir o ponto de entrada no sistema, o SIP e o processo de ingestão que lhe está associado.

Nas primeiras aulas, discutiu-se a estrutura que deveria ter este pacote o que resultou na seguinte especificação:

• Um SIP é ficheiro comprimido no formato ZIP;
• O ZIP contem um conjunto de ficheiros onde um deles funciona como manifesto, descrevendo a estrutura e os restantes ficheiros que constituem o pacote;
• O manifesto foi designado por "Projecto Record (PR)" e depois de algum "trabalho de casa", numa das primeiras aulas, foi especificado um XML Schema que especifica o formato XML do PR: XML Schema do Project Record;
• Ficou também definido que o PR virá sempre num ficheiro de nome pr.xml;
• Todos os outros ficheiros do pacote deverão estar ao nível do PR e deverão ser referenciados por este.

O processo de ingestão deverá receber o ficheiro ZIP, validá-lo e armazená-lo.

Validação do SIP

[Voltar ao índice]

A validação do SIP poderá ser constituída pelas seguintes tarefas (outras poderão ser acrescentadas):

• Verificar se o pr.xml existe;
• Verificar se todos os ficheiros referenciados no pr.xml existem no pacote enviado;
• Verificar se os checksum dos ficheiros conferem;
• etc...

Armazenamento do SIP

[Voltar ao índice]

O armazenamento do SIP deverá ser alvo de estudo por parte da equipe de implementação. Solução final poderá ser híbrida: parte da informação numa base de dados relacional (por ex. a metainformação), parte da informação no file system numa área gerida pela aplicação (por ex. os ficheiros), parte da informação em ficheiro XML ou JSON (por ex. os logs).

Depois do processo de ingestão a informação do SIP foi armazenada e aquele foi convertido num AIP.

AIP e o armazenamento de projectos

[Voltar ao índice]

AIP é a designação que se dá ao objecto intelectual depois deste ter ficado devidamente arquivado.

Neste projecto, o AIP irá corresponder a uma solução híbrida, com uma parte da informação a ser guardada numa base de dados relacional, outra no file system e outra num ficheiro XML.

A metainformação relativa ao projecto, ou seja, a informação contida no pr.xml, poderá ser guardada numa base de dados relacional. Os alunos deverão especificar o modelo de entidades e relacionamentos e o esquema da base de dados relacional.

Os ficheiros resultantes de cada projecto deverão ser guardados numa zona "especial" do file system. Foi pedido aos alunos que pensassem numa maneira de fazer isto e que pensassem numa forma de manter a ligação entre estes ficheiros e a respectiva informação guardada na base de dados.

A componente de registo de logs no sistema será guardada num ficheiro XML cuja estrutura e processamento serão abordados durante as aulas.

Os modelos desenvolvidos nas aulas e publicados juntamente com este enunciado são apenas para orientação. Em muitas situações o aluno terá de estender os modelos apresentados. Ou seja, não se limitem ao que foi discutido nas aulas, aproveitem essa informação e tentem ir mais além!

DIP e a disseminação/publicação de conteúdos

[Voltar ao índice]

Um DIP corresponde à forma como se irão disponibilizar os conteúdos armazenados.

Para já, pretende-se que o consumidor/utilizador do sistema tenha à sua disposição um website a partir do qual possa explorar os conteúdos armazenados: listar os projectos, consultar a informação relativa a um projecto, descarregar um dos ficheiros do projecto, etc.

Uma outra forma de DIP será a possibilidade de exportação de um projecto. Neste caso, o DIP corresponderá a um ficheiro ZIP com uma estrutura semelhante ao SIP.

Processo de Administração

[Voltar ao índice]

Ao nível da administração deverá existir um conjunto de funcionalidades, comum a todas as entidades presentes no sistema, designado normalmente por CRUP (create/remove/update/print).

Assim e a título de exemplo eis algumas das operações que se espera encontrar:

• Administração de utilizadores: registo, edição, remoção, listagem;
• Administração de projectos (AIPs): edição, remoção, listagem, exportação;
• Estatísticas de utilização: processamento dos logs (ainda a ser discutido nas aulas).

---

--- Generated by tp2html-v2.xsl 2013-11-26Z ---