OPeNDAP
Acessando dados heterogêneos
em ambientes distribuídos
David Moises
William Voorsluys
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)

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
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
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
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
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
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:
1.
•
•
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
2.
Examine os dados e formule a requisição para o
site Y
3.
Importe o resultado para a máquina local.
•
4.
Novamente deve ser feito o download e conversão dos
dados
Analise os resultados finais
Por que usar OPeNDAP?
Cenário com OPeNDAP
1.
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
2.
Examine os dados e formule a requisição para o
site Y
3.
Mais uma vez, os dados são baixados e
convertidos automaticamente
4.
Analise os resultados finais
Por que usar OPeNDAP?
Conversão de
formatos
- semântica
dos dados
- ordem das
variáveis
Restrições
FTP
OPeNDAP
Manual
Automática
Não
Sim
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
Arquitetura Cliente/Servidor


O cliente OPenDAP é um programa que requisita e
recebe dados
O servidor OPeNDAP é um programa que envia dados
em um formato intermediá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
Arquitetura Cliente/Servidor

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
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
Serviços OPeNDAP

Data Attribute (.das)


Data Descriptor (.dds)



Retorna os dados requisitados pela URL
ASCII Data (.ascii)


Descreve a estrutura dos dados
OPeNDAP Data (.dods)


Define os atributos dos dados
Representação ASCII dos dados requisitados
Existe uma entidade responsável por
decidir
serviço
e usado
comopara
 Apresenta
um qual
formulário
HTMLprocessar
para pode ser
construção da URL para requisitar dados
o programa deve passar os
Information (.info)
parâmetros
extraídos
daerequisição
 Fornece
informações sobre
o servidor
o arquivo de dados, em
WWW Interface (.html)
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
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/nphdods/data/nc/coads_climatology.nc.ascii?TIME[0:1:11]
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
Modelo de dados
O que é?

Um conjunto de dados é formado por:



Modelo de dados



Dados
Um 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)
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)
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;
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
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
O DAP (Data Access Protocol)

Consiste de 4 componentes
1.
2.
3.
4.
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
Representação dos dados

Objetivos do formato intermediário




Modelo OPeNDAP consiste de:



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
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
Elementos do DAP (1)

Tipos de dado básicos


Byte, Int32, UInt32, Float64, String, Url
Estruturas

List


Array



Estrutura indexada. Uma ou mais dimensões.
Structure


Coleção de elementos de qualquer tipo
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
Elementos do DAP (2)

Operadores

Byte, Int32, UInt32, Float64


String


length(list), nth(list,n), member(list,elem)
Structure, Sequence


[start:stop] [start:stride:stop]
List


*
Array


= != ~=
URL


< > = != <= >=
“.”
Grid

[start:stop] [start:stride:stop], “.”
Elementos do DAP (2)

Operadores

Byte, Int32, UInt32, Float64


String


length(list), nth(list,n), member(list,elem)
Structure, Sequence


[start:stop] [start:stride:stop]
List


*
Array


= != ~=
URL


< > = != <= >=
“.”
Grid

[start:stop] [start:stride:stop], “.”
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)
DDS (Dataset Descriptor Structure)

Informações sintáticas
Dataset {
Structure {
Float64 lat;
Float64 lon;
} location;
Int32 time;
Sequence {
Float64 depth;
Float64 temperature;
} cast
} station;

Tipos de dados

Relação entre os dados

Independente da área de estudo
DAS (Dataset Attribute Structure)
Attributes {
station {
location {
lat {
String units “degrees north”
Float64 actual_range 0, 30.0;
}
lon {
String units “degrees east”

Informações semânticas

Associa atributos às variáveis
Float64 actual_range -50.0, -48.0;

}
Dá significado
aos valores
}
time {
String format “Second since
1/1/1970”;
}
cast {
depth {
String units “meters”;
}
temperature {
String units “degrees C”;
}

Pode conter atributos globais

Dependente da área de estudo
}
}
Exemplos



http://dodsdev.gso.uri.edu/dods-3.4/nphdods/data/nc/coads_climatology.nc.das
http://dodsdev.gso.uri.edu/dods-3.4/nphdods/data/nc/coads_climatology.nc.dds
http://dodsdev.gso.uri.edu/dods-3.4/nphdods/data/nc/coads_climatology.nc.html
Como servir seu dado?
Como construir um novo
Cliente/Servidor OPeNDAP?

Usar a biblioteca (API) OPeNDAP
 Frameworks (C++ e JAVA)



Open source
Da parte do servidor

implementar os serviços DAS, DDS e DODS




Servidor e Cliente
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
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

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
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