OPeNDAP

1. OPeNDAP Acessando dados heterogêneos em ambientes distribuídos David Moises William Voorsluys

2. Introdução • Na distribuição de dados científicos, as questões de incompatibilidade de formatos é um obstáculo significante • impede cientistas de compartilhar livremente seus dados • desencoraja o acesso a dados disponibilizados por centros de referência • Para tratar questões como esta em relação ao dados de oceanografia, alguns cientistas lançaram em 1993 um projeto chamado DODS (Distributed Oceanographic Data System)

3. Introdução • O objetivo de tal projeto é facilitar o compartilhar de dados • Permitindo que cientistas importem dados para suas ferramentas de análise diretamente de sites remotos, sem se preocupar com o formato no qual os dados estão armazenados • O esforço do projeto DODS tem duas partes fundamentais • Como dados são transferidos pela rede até o software cliente — Data Access Protocol (DAP) • Aplicações para o uso do protocolo

4. Introdução • Dados relacionados a oceanografia envolvem uma grande variedade de tipos de dados e estruturas de organização • Então, o resultado é que foi desenvolvido um protocolo razoavelmente genérico • Sendo assim, embora desenvolvido para a comunidade de Oceanografia, DAP não tem nada que seja específico desta área

5. Introdução • Alguns cientistas logo reconheceram isto e adotaram DAP • Sendo assim, surgiram várias especializações do protocolo, gerando deste modo, uma duplicação de esforços desnecessária

6. O que é OPeNDAP? • Para resolver este problema, OPeNDAP (Open Source Project for a Network Data Access Protocol) foi estabelecido em 2000 • Desenvolvimento e promoção de softwares que facilitam o acesso de dados via rede • Mais abrangente do que oceanografia

7. Por que usar OPeNDAP? • Exemplo: FTP versus OPeNDAP • Considere um cientista que deseja fazer análises de alguns dados que estão contida no site X • Para efeitos de comparação, ele precisará de outros dados que estão no site Y

8. Por que usar OPeNDAP? Cenário com FTP • Importe o arquivo do site X para a máquina local do usuário. Isto requer outros passos: • Deve ser feito o download dos dados usando FTP • Em seguida, os dados devem ser convertidos para um formato que pode ser lido pelo programa que realiza a análise • Examine os dados e formule a requisição para o site Y • Importe o resultado para a máquina local. • Novamente deve ser feito o download e conversão dos dados • Analise os resultados finais

9. Por que usar OPeNDAP? Cenário com OPeNDAP • Uma vez feita a requisição, os dados são baixados e convertidos automaticamente para a aplicação do usuário • Restrições podem ser feitas e, deste modo, poupar tráfego na rede • Examine os dados e formule a requisição para o site Y • Mais uma vez, os dados são baixados e convertidos automaticamente • Analise os resultados finais

10. Por que usar OPeNDAP?

11. Por que usar OPeNDAP? • Benefícios • O usuário não precisa aprender qualquer formato de dados • Consultas podem extrair uma parte dos dados de um arquivo remoto no formato tratado por sua aplicação • Dados desnecessários não são transmitidos • Adicionando restrições a URL, o usuário pode consultar dados usando técnicas que não estão disponíveis na sua aplicação

12. Arquitetura Cliente/Servidor • O cliente OPenDAP é um programa que requisita e recebe dados • O servidor OPeNDAP é um programa que envia dados em um formatointermediário • Servidor Web que utiliza um conjunto de scripts CGI ou servlets JAVA • Segurança • Podem ser definidos usuários e senhas para acesso aos dados (Servidor Web) • O protocolo OPeNDAP define como clientes e servidores comunicam um com o outro

13. Acesso a dados (cliente) Acessa dados remotos através de aplicações rotineiras Matlab GrADS Qualquer aplicação netCDF Excel etc Não precisa saber o formato no qual os dados estão armazenados Pode consultar subconjuntos dos dados Publicação de dados (servidor) Pode fornecer dados em vários formatos netCDF FreeForm JGOFS DSP Etc DAP provê um representação intermediária para dados Permite consultar subconjuntos dos dados Arquitetura Cliente/Servidor

14. Arquitetura Cliente/Servidor

15. Como OPeNDAP encontra dados? • Protocolo: protocolo de uma requisição via Internet • Host: endereço Internet do servidor • Servidor: característica especial do servidor para executar scripts CGI • Diretório: pasta que contém o arquivo desejado • Nome do arquivo • Sufixo: especificação do tipo de requisição • diferentes sufixos demandam diferentes serviços do servidor

16. Serviços OPeNDAP • Data Attribute (.das) • Define os atributos dos dados • Data Descriptor (.dds) • Descreve a estrutura dos dados • OPeNDAP Data (.dods) • Retorna os dados requisitados pela URL • ASCII Data (.ascii) • Representação ASCII dos dados requisitados • WWW Interface (.html) • Apresenta um formulário HTML para pode ser usado para construção da URL para requisitar dados • Information (.info) • Fornece informações sobre o servidor e o arquivo de dados, em um formato HTML legível para humanos • Version (.ver) • Mostra a versão do Servidor OPeNDAP • Help • Retorna algum texto útil como resposta a uma URL especificada de forma imprópria Existe uma entidade responsável por decidir qual serviço processar e como o programa deve passar os parâmetros extraídos da requisição

17. Serviços OPeNDAP • Um exemplo de consulta • Usando o serviço ASCII • Restringindo a consulta por tempo http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/data/nc/coads_climatology.nc.ascii?TIME[0:1:11]

18. Organização dos dados • Modelo de dados • Conversão entre formatos • Componentes do “DAP” • Representação de dados • Tipos de dados • Estruturas de dados • Meta-dados • Sintáticos • Semânticos

19. Modelo de dados O que é? • Um conjunto de dados é formado por: • Dados • Um modelo de dados • Modelo de dados • Define os tamanhos e a organização dos valores • Define a relação entre os valores • Computacionalmente falando ... • Tipos de dados (inteiro, real, string) • Coleções de dados (Estrutura, Array, Vetor)

20. Modelo de dados Exemplo • Representando a “Temperatura da Superfície do Mar” • Informações a representar em cada ponto: • Coordenadas geográficas (latitude, longitude) • Tempo (Dia, Hora) • Valores (Temperatura, Profundidade)

21. Modelo de dados Exemplo • Mesmo dado • Diferentes modelos de dado Dataset { Float64 lat; Float64 lon; Int32 minutes; Int32 day; Int32 year; Sequence { Float64 depth; Float64 temperature; } cast; } station; Dataset { Structure { Float64 lat; Float64 lon; } location; Structure { Int32 minutes; Int32 day; Int32 year; } time; Sequence { Float64 depth; Float64 temperature; } cast; } station; Dataset { Structure { Float64 lat; Float64 lon; } location; Structure { Int32 minutes; Int32 day; Int32 year; } time; Float64 depth[500] Float64 temperature[500] } station;

22. Modelo de dados API • Biblioteca de funções para operar sobre os dados • Funções da API estão “amarradas” ao modelo de dados • Funções desejáveis para uma API • Ler • Escrever • Consultar • Retirar subconjuntos • OPeNDAP suporta APIs bem distintas • Ex.: netCDF e JGOFS

23. Conversão entre formatos • Questão central na implementação do OPeNDAP • Não é possível efetuar conversões entre “quaisquer modelos” • Muitas vezes a conversão implica em perda de informação • Informações contidas no modelo são essenciais para a correta análise dos dados

24. O DAP (Data Access Protocol) • Consiste de 4 componentes • Formato intermediário de representação • Formato para metadados (dados auxiliares) • Metadado sintático (DDS) • Metadado semântico (DAS) • Um procedimento para recuperar dados e metadados de fontes remotas (serviços) • Uma API para implementar o protocolo

25. Representação dos dados • Objetivos do formato intermediário • Adequado para transmissão pela rede • Ser genérico o suficiente para representar as abstrações de diversos formatos • Evitar perda de informações durante a conversão • Modelo OPeNDAP consiste de: • Conjunto básico de tipos de dados • Conjunto avançado de estruturas de dados e operadores • Representação externa • Formato independente de arquitetura • Sun XDR (External Data Representation) RFC 1832

26. Elementos do DAP (1) • Tipos de dado básicos • Byte, Int32, UInt32, Float64, String, Url • Estruturas • List • Coleção de elementos de qualquer tipo • Array • Estrutura indexada. Uma ou mais dimensões. • Structure • Representa relação entre variáveis • Sequence • Conjunto ordenado de grupos de variáveis • Grid • Associação de um array de N dimensões com N vetores de índices

27. Elementos do DAP (2) • Operadores • Byte, Int32, UInt32, Float64 • < > = != <= >= • String • = != ~= • URL • * • Array • [start:stop] [start:stride:stop] • List • length(list), nth(list,n), member(list,elem) • Structure, Sequence • “.” • Grid • [start:stop] [start:stride:stop], “.”

28. Elementos do DAP (2) • Operadores • Byte, Int32, UInt32, Float64 • < > = != <= >= • String • = != ~= • URL • * • Array • [start:stop] [start:stride:stop] • List • length(list), nth(list,n), member(list,elem) • Structure, Sequence • “.” • Grid • [start:stop] [start:stride:stop], “.”

29. Dados auxiliares (metadados) • Objetivo • Fornecer informação sobre a “forma e tamanho” dos dados • Associar atributos às variáveis • Representações textuais • Dois tipos de metadado • DDS (Dataset Descriptor Structure) • DAS (Dataset Attribute Structure)

30. DDS (Dataset Descriptor Structure) • Informações sintáticas • Tipos de dados • Relação entre os dados • Independente da área de estudo Dataset { Structure { Float64 lat; Float64 lon; } location; Int32 time; Sequence { Float64 depth; Float64 temperature; } cast } station;

31. DAS (Dataset Attribute Structure) Attributes { station { location { lat { String units “degrees north” Float64 actual_range 0, 30.0; } lon { String units “degrees east” Float64 actual_range -50.0, -48.0; } } time { String format “Second since 1/1/1970”; } cast { depth { String units “meters”; } temperature { String units “degrees C”; } } } • Informações semânticas • Associa atributos às variáveis • Dá significado aos valores • Pode conter atributos globais • Dependente da área de estudo

32. Exemplos • http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/data/nc/coads_climatology.nc.das • http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/data/nc/coads_climatology.nc.dds • http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/data/nc/coads_climatology.nc.html

33. Como servir seu dado?

34. Como construir um novo Cliente/Servidor OPeNDAP? • Usar a biblioteca (API) OPeNDAP • Frameworks (C++ e JAVA) • Servidor e Cliente • Open source • Da parte do servidor • implementar os serviços DAS, DDS e DODS • mapear as variáveis para serem representadas usando os tipos disponíveis pelo protocolo DAP • a API inclui software que gera automaticamente os outros serviços a partir destes implementados • implementar restrições que clientes podem fazer através de URLs • Da parte do cliente • traduzir os dados intermediários usando DAS e DDS • gerenciar abertura e encerramento de conexões

35. Catálogo • Se restringe a uma lista estática de URLs de arquivos • http://www.opendap.org/data/datasets.cgi?xmlfilename=datasets.xml&exfunction=none • Um arquivo pode ser registrado através do link www.opendap.org/data/addtolist.html • as informações necessárias são: • Nome do arquivo • URL • Servidor • E-mail

36. Potenciais aplicações no SegHidro • Aproveitamento de resultados de previsões atmosféricas • Um resultado pode conter outro resultado • Aproveitar rodadas de produção em simulações ad hoc • Disponibilizar arquivos GRADS, PMH e PHR para análise em outras ferramentas (Matlab, Excel, etc) • Utilizar dados observados produzidos por outros centros para comparação

37. Considerações Finais • OPeNDAP e SegHidro • Podem contribuir para uma ciência melhor • Facilitando o compartilhamento de conhecimento entre parceiros • Limitações • Documentação desatualizada