FEB – Federação de Repositórios Educa Brasil UFRGS/UNISINOS

Equipe proponente Rosa Maria Vicari (IA, OA) Liane Tarouco (OA, Redes) Raymundo Ferreira Filho (OA, Redes, TVDigital) João Carlos Gluz (IA, Redes, TVDigital) Bolsistas: João Mossmann (Redes) Cassio Andrade (Redes) Carla Fillmann (IA)

Área de Pesquisa Descoberta e acesso a conteúdo distribuído e heterogêneo na Web.

P&D Desafios Definir um modelo para federação de repositórios que encaminhe uma solução eficiente para o reuso de objetos de aprendizagem a partir de um único ponto de busca, contemplando as plataformas Web, Wap e dispositivos móveis. Avaliar a possibilidade de interatividade, com plataformas de TV Digital visto que, atualmente, no padrão brasileiro, não se tem a possibilidade de interatividade via upload de informações. Implementar uma federação de repositórios com a finalidade de auxiliar na descoberta e acesso a conteúdos de aprendizagem (único ponto de acesso com armazenamento dos metadados dos repositórios da federação)

Objetivos Objetivo => criar uma infra-estrutura para federação de repositórios de conteúdo digital. Propor um modelo para federação de repositórios de objetos de aprendizagem (planejamento e documentação) e Desenvolver uma infra-estrutura operacional (protótipo) que inclua múltiplas implementações de repositórios e a federação desses repositórios.

Problema Com o aumento da produção de objetos de aprendizagem em inúmeras instituições, no Brasil e no mundo, percebeu-se que estes conteúdos não seriam de grande utilidade para os possíveis usuários, a menos que pudesse ser descoberto, localizado e recuperado de forma eficiente e globalizada.

Problema As federações podem variar em normas específicas de metadados, políticas de acesso, princípios organizacionais, implementação, etc. Para aplicações educacionais, estas variações técnicas devem ser imperceptíveis aos seus usuários. Lacuna =>não existe, atualmente, uma infra-estrutura global de apoio à busca e recuperação de conteúdos de aprendizagem. Esta lacuna abre uma vertente de pesquisa e de contribuição para a área com relevância internacional.

Metodologia Partindo-se da tecnologia existente, o modelo e o protótipo serão definidos em termos da diversidade de formas de implementação de repositórios e das necessidades dos usuários (busca e uso dos objetos de aprendizagem).

Metodologia O modelo de federação de repositórios será norteado por um padrão de referência uma coleção de especificações de interoperabilidade detalhando as características e comportamento da federação. A intenção é permitir que usuários implementem a sua federação, com a definição de suas tecnologias, políticas e regras e possam adaptar o modelo proposto, as suas necessidades, sem perder a interoperabilidade.

Metodologia - requisitos Requisitos relevantes para a interoperabilidade entre os padrões: =>Adaptabilidade: possibilitar que a mesma descrição de um recurso seja utilizada de forma interoperável, adaptando-se às características de cada plataforma (WEB,Móveis e TV-Digital). Compatibilidade com os padrões existentes: O padrão deve buscar manter a compatibilidade com o que existe no mundo ou permitir uma adaptação automática.

Metodologia (etapas) As principais etapas deste processo metodológico são: Estudo dos padrões existentes atualmente (SCORM, Dublin Core, LOM) para o estabelecimento de repositórios de OA. Estudo detalhado a respeito dos padrões, protocolos e tecnologias dos repositórios definidos nesse projeto; Estudo de padrões, protocolos e tecnologia para implementação de federações de repositórios e interface de busca (o grupo optou por seguir dois caminhos em paralelo):

Alternativa 1: Federação baseada no protocolo LDAP LDAP – Light Directory Access Protocol Software: Open LDAP Mecanismo de encaminhamento de consultas intrínseco

Alternativa LDAP: premissas Implementação de midleware baseado no protocolo LDAP Mapeamento entre conjuntos de metadados usados nos inicialmente considerados (existentes e em regime de produção) Dublin Core extendido LUME (UFRGS) BIOE (MEC) LOM (Learning Object Metadata) CESTA (UFRGS) SCORM – facilitar portabilidade futura para AVAs

Estágio atual da solução LDAP Análise e consolidação dos metadados O servidor OpenLDAP foi instalado, testado e configurado Interoperação entre os servidores LDAP Colheita de metadados nos repositórios existentes Repositórios LUME e BIOE Utilizam software DSPACE que oferece acesso via protocolo OAI-PMH (Open Archives Initiative Protocol of Metadata Harvesting)

Encadeamento de consultas Um servidor encaminha uma consulta para outro servidor que poderá completar a consulta e depois de receber as respostas entrega ao cliente Funcionamento pretendido para a federação de repositórios baseada em uma estrutura de diretórios distribuída.

CESTA LDAP server LUME BIOE Repositório existente Em fase de definição Reencaminha- mento de consultas CESTA LDAP server Interface OAI Interface genérico LUME BIOE Engeo Protocolo OAI Protocolo LDAP Repositório existente Em fase de definição e testes Negociações Iniciadas Este slide seguinte ilustra o estágio das etapas desta atividade Com o primeiro servidor LDAP já instalado e em regime de produção, inicialmente foi considerado mais apropriado tentar implantar a infraestrutura de comunicação que apoiará a federação de repositórios usando o próprio OpenLDAP. Como o repositório de conteúdo usado na UFRGS e no projeto RIVED utilizam o software DSpace foi iniciado o estudo e teste do protocolo OAI. Consultas foram criadas e enviadas para o servidor LUME da UFRGS e as respostas analisadas. Existem ainda algumas dúvidas sobre a forma de extrair informações sob demanda de um servidor DSpace. As conversações com a equipe do MEC foram estabelecidas mas eles pediram para esperarmos até depois de 15 de abril pois estão sobrecarregados como lançamento de um novo serviço. Também estão sendo estudadas e testadas formas de configurar o servidor LDAP para que faça o encadeamento de consultas para os outros servidores.

Alternativa – LDAP - etapas Definição de software (livre) para desenvolvimento do modelo de federação (SO free BSD e open LDAP e Apache com extensão LDAP) Protocolo OAI para repositórios que são compatíveis com OAI-PMH e as demais interfaces programadas em Java); Testes com as várias propostas existentes; Implementação de um protótipo integrando acesso aos repositórios CESTA, LUME e BIOE (teste de conceito);

Investigação preliminar Coleta de metadados sob demanda Potenciais problemas de performance fora do alcance da federação Limitação no protocolo OAI – consultas pré-definidas Colheita de metadados periódica Performance do sistema controlável (recursos dos servidores da federação podem ser ampliados) Redundância

Arquitetura do protótipo da federação de repositórios

Elementos da Arquitetura do Midleware LDAP Conjunto de servidores LDAP Um servidor LDAP no topo da hierarquia envia as requisições (em paralelo) aos demais servidores LDAP da federação. Cada um dos servidores LDAP, contem uma interface para uma ou mais Bases de Dados Locais. Na Base de Dados Local são coletados (off-line) as informações dos repositórios de objetos de aprendizagem: CESTA, LUME, BIOE (metadados)

Modelo lógico do midleware LDAP Junção de árvores de diretórios isoladas em um única árvore. O Servidor LDAP no topo da hierarquia age como um intermediário (proxy) As requisições são redirecionadas a múltiplos servidores remotos. Midleware consolida respostas recebidas apresentando ao usuário

Modelo da Federação Mapeamento LOM & Dublin Core

Protótipo da Federação de repositórios operando sobre LDAP RIVED

Interface do protótipo do midleware implementado

Metodologia alternativa LDAP (etapas por realizar) Teste da federação acessando repositórios em servidores dispersos geograficamente, com características de rede variadas e com configurações heterogêneas de hardware e software e da interface de busca (acessada via Wap e Web) Organização processo de colheita periódica de metadados Interface para repositórios que não utilizem o protocolo OAI-PMH (ENGEO e OBAA) Análise dos resultados obtido e documentação. Mecanismo de gerência da federação

Metodologia 2 -Visão Geral Agentes e Ontologias oferecem as tecnologias chave para implementar o Serviço de Catálogo de Objetos de Aprendizagem (OAs) Ontologias especificam as propriedades do domínio, mas não oferecem ou implementam os elementos ativos de um sistema Agentes de software são os elementos computacionalmente ativos e precisam das ontologias para a comunicação Criam aplicações concretas através de sistemas multiagente Agentes Ontologias Viabilizam a comunicação entre os agentes

Metodologia 2 - Premissas Específicas Catálogo de informações sobre OAs implementado sobre o serviço de diretórios definidos pelos padrões FIPA (Serviço DF) O Serviço DF da FIPA opera em modo federado permitindo a criação de redes de diretórios, com busca automática em toda a rede Criação de ontologias OWL para especificar as características dos metadados dos OAs Especificação, acesso e inferência sobre ontologias através da ferramenta Protege-OWL e do framework JENA

Metodologia 2 Premissas Específicas Implementação dos agentes sobre a plataforma JADE compatível com os padrões FIPA Possibilidade de interoperação com outros serviços de diretórios como LDAP através de agente gateway Interface dos agentes com usuários através de páginas Web Interface dos agentes com outros agentes através de protocolos de interação FIPA Persistência do catálogo implementada através de servidor SQL e interface JDBC

Metodologia2 - implementação Especificação de ontologias OWL para metadados nos formatos: IEEE LOM Dublin Core OBAA Implementação de agentes para as seguintes funcionalidades: Coleta de informações sobre OAs armazenados em repositórios externos e cadastro destas informações no serviço DF da FIPA Pesquisa por OAs baseada nos metadados cadastrados no serviço DF Interoperação com outros serviços de diretórios (como LDAP). Agentes MILOS Librarian Finder Inter-Librarian

Federação de Diretórios RIVED CESTA HTTP-MTP HTTP-MTP Internet Federação de DFs HTTP-MTP LUME

Coleta de Informações de OAs Repositório de OAs Milos Librarian Agent OAI-PMH Repositório de OAs OAI-PMH Middleware FIPA/JADE Biblioteca Digital Interface Web/JSP Z39.50 Diretório Local DF Agent Cadastro manual

Busca no Catálogo Outros Agentes ... Finder Milos Agent Diretório FIPA-Query Protocol Outros Agentes Milos Finder Agent ... Interface Web/JSP Consulta manual Middleware FIPA/JADE Diretório Local DF Agent

Interoperação com outros Serviços de Diretórios/Catálogos Servidor OpenLDAP LDAP Milos Librarian Agent Milos Inter-Librarian Agent LDAP Middleware FIPA/JADE Servidor ApacheDS Diretório Local DF Agent

Persistência do Catálogo Middleware FIPA/JADE JDBC DF Agent Base de Dados do Diretório Local Servidor SQL

Interface Web/JSP para Agentes Milos Librarian Agent F I P A / J D E Página JSP Página JSP Facilidades de Interface Web/JSP Milos Inter-Librarian Agent Página JSP ... Milos Finder Agent Página JSP Servidor Apache/Tomcat

Desafios e Questões Solução: Implementar extensão compatível do serviço DF da FIPA – o Serviço DF2 com suporte a recursos e atualização incremental DF da FIPA apenas registra serviços prestados por agents, porém OAs (ou índices/referênas a OAs) não são serviços, mas recursos computacionais DF da FIPA não permite inclusões/ exclusões incrementais de registros Implementação dos protocolos OAI-PMH e Z39.50 é complexa: Ficar restrito apenas a OAI-PMH (estado da arte)? Semântica de busca do agente Finder restrita a ontologias de metadados: Necessidade de ontologias sobre domínios de aprendizagem? Um agente de busca mais sofisticado? Interoperação com diretórios LDAP ou substituição do serviço DF da FIPA?

Resultados X recursos Uma única interface de busca que procure por objetos de aprendizagem em todos os repositórios registrados na federação, independente da forma de implementação de cada repositório. Esta interface de busca estará disponível na Web, e para dispositivos móveis. Para TV Digital (diferentes versões de Set-top Box), verificou-se que não é possível ter interatividade no sentido de upload.

Resultados Especificar um padrão de referência que descreva como construir repositórios interoperáveis através da criação de uma infra-estrutura de federações de repositórios (protótipo como prova de conceito) Necessidade vinculada ao projeto OBAA/FINEP. Como consequência da forma de operação da federação, será possível a busca de objetos educacionais de: acesso irestrito e de acesso restrito (acesso mediante registro do usuário ou pagamento de taxas). Este projeto pretende, ainda, definir um modelo e um conjunto de normas para congregar federações.