Feeds:
Posts
Comentários

Nota: as opiniões aqui escritas são minhas e não refletem a opinião do meu empregador.

Chamo de biodiversidade digital todos os aspectos que envolvem a biodiversidade no mundo digital.

Tendo um pouco de experiência em digitalização e publicação da biodiversidade então irei descrever aqui o que eu acho que deve mudar para que o campo avance e possamos nos preocupar mais com coisas mais relevantes.

Padrões

EML

Estado da arte e apresenta poucos espaços disponíveis para melhoria. Não consigo me lembrar da última vez que nesses últimos seis meses que sequer citei o EML no trabalho. Acredito que quando a solução de um problema passa desapercebido significa que ele foi bem resolvido.

DwC

O padrão em si precisa ser mais aberto a sugestões e a equipe do TDWG (“mantedora” do padrão)  precisa de mais pessoas na equipe. É muito triste entrar na página de um padrão tão usado e o link de histórico permanecer quebrado a vários meses.

Muitas melhorias precisam ser feitas no grupo de taxonomia, falta várias sub/sob categorias e uma solução como a dada aos dados ecológicas seria o ideal. Informar o rank taxonômico e seu valor parece uma solução melhor do que termos fixos que contemplam apenas rankings básicos da taxonomia (é muita gente usa tribo!).

Ideal

Uma solução onde os dados são alimentados ao sistema na forma como o pesquisador descreveu sem a necessidade de modificações ou transformações. Também é precisa se desligar da ideia que todo dado é representado por tabelas. Quem grava o áudio/vídeo/fotos não fica usando tabela para salvar o produto. Links na tabela para esses recursos multimídia não são a solução, quando eu baixo um pacote de dados eu quero todos os dados dentro do pacote. Se ocorrer problemas no local da hospedagem o meu pacote de dados se torna inútil.

Solução para o problema é dar uma olhada nas ideias do padrão noSQL, onde é possível ter um formato híbrido com formato tabular e objetos (nossos vídeos).

Ferramentas

IPT

Uma opção para armazenamento de dados em algum banco de dados. Iria facilitar a indexação de recursos assim como a geração de métricas dos dados. Relacionado a isso o IPT precisa urgente de uma API. Só existe a necessidade de indexadores devido a falta de uma API…

A definição dos termos DwC em núcleos começa a ser irritante mostrando suas limitações no padrão estrela. Essa definição dos núcleos não pertence ao padrão do DwC. Nenhum pesquisador gosta de ideia de modificar sua tabela  e depois ter que dividi-la em outras três por uma implementação de um padrão de forma arbitraria pela ferramenta de publicação.

Metacat

Estou afastado da ferramenta a alguns meses. Ainda assino a lista de desenvolvimento para acompanhar as novidades e parece que última relevante é relacionada ao sistema de busca da DataONE (off-topic da ferramenta) que parece ter sofrido melhorias consideráveis.

Tentei fazer o download do último código fonte e desisti depois de ver o tamanho de quase 900 mb. Me pergunto como um código fonte pode chegar a esse tamanho absurdo? Este projeto também já deveria ter migrado para o GitHub. Se o financiamento acabar também podemos perder acesso ao código fonte. O GitHub daria o prolongamento da vida da ferramenta por contribuições da comunidade.

Ainda possui recursos que eu sonho em ver no IPT como a replicação que permite compartilhar seus dados de forma segura entre instalações da ferramenta. API local que permite criação de portal de dados com a própria ferramenta e indexação por Solr.

Ideal

Uma ferramenta com todos os recursos listados no último paragrafo do Metacat mas com a interface de adição de recursos do IPT e com um novo modelo de armazenamento de dados que também iria implicar em um novo padrão superior ao DwC. A noção de dados de ocorrência ou ecológicos deve desaparecer para o software e existir apenas na cabeça do pesquisador.

E claro que não seja em Java, não adianta falar que Java roda em qualquer plataforma se todo mundo usa servidores Linux eliminando assim a principal vantagem argumentada. Java não é ruim, mas desenvolvedores competentes parecem escassos. Toda vez que eu olhei para um campo na ferramenta e imaginei “se eu fizer isso vai dar pau” aconteceu. Eu sou um biólogo, se é óbvio para mim deveria ser ridículo para um programador com diploma. Um desses bugs que reportei pode simplesmente travar o IPT por vários segundos, com um pouco de maldade eu poderia travar todas os IPTs disponíveis por quanto tempo eu tivesse paciência. Esses bugs são comuns em ambas as ferramentas.

Conclusão ou tl;dr

Desaparecimento dos padrões de formatação de tabelas. Não queremos mais tabelas! Queremos poder usar vídeos e áudio nos pacotes de dados, nada de anexo. Um vídeo por registro se assim eu desejar.

A ferramenta deve se virar para resolver meu problema. Eu me adaptar a soluções dos informáticos não é solução do problema. Se a minha “tabela” está nesse formato deve ter um motivo muito bom. Será que é o formato mais comum para a análise deste tipo de dado? Será que meus pares de pesquisa também gostariam de receber nesse formato? Se eu apresentar em outro formato isso vai ajudar o compartilhamento de dados sobre a biodiversidade? São todas perguntas que parecem esquecidas e precisam ser feitas e refeitas até a exaustão para avançarmos para o próximo nível.

Fim da relação política/financeira dessas ferramentas/padrões. Sim várias vezes eu consigo notar que todo mundo sabe do problema, concorda com o problema, mas não vamos fazer nada por motivos políticos.

Que se foda *****, eu quero é resolver o problema.

Conclusão no final da discussão sobre o “estado da arte” da biodiversidade digital

Durante esse mês que passou muitas coisas aconteceram no desenvolvimento do IPT. A meu ver a principal delas para comunidade ecológica foi a incorporação do core de eventos e a aceitação dos metadados com o tipo evento de amostragem.

Durante os testes da versão de desenvolvimento notei que apesar da criação de um core dedicado para eventos ainda era necessário associar uma extensão de ocorrência. O que não é uma verdade para dados ecológicos. É comum a coleta de variáveis ambientais sem espécies associados, como por exemplo, emissão de carbono ou qualidade da água. Com isso fiz um pull request que foi aceito mas com a ressalva de exibir um aviso de atenção, já que não consideram o cenário comum no momento.

Outra mudança interessante foi o versionamento das extensões que também contam com um sistema de atualização mais inteligente. Anteriormente era necessário atualização manual das extensões ou correria o risco dos dados parassem de exibir na interface web.

E finalmente o lançamento da versão 2.3 do IPT contendo as mudanças citadas acima e a migração para o github.com.

Então que venham os dados ecológicos para avaliar as mudanças novo IPT.

Para os leitores que não conhecem as ferramentas e o contexto atual irei dar uma breve introdução.

Metacat

Software do tipo serviço (ou daemon) onde são armazenados principalmente dados ecológicos e suas descrições (metadados). Aceita outros formatos mas a comunidade sempre que escuta sobre Metacat associa com dados ecológicos. O Metacat segue o padrão EML de descrição dos dados. O principal objetivo do EML é conseguir descrever dados usando um formato flexível como os dados ecológicos. Dessa forma o Metacat trabalha com o formato repositório de dados onde as colunas não são fixas em nomenclatura e/ou quantidade possível.

Pontos fortes: padrão flexível que permite descrever qualquer formato de tabela.

IPT Integrated Publishing Toolkit

Também é um software serviço sendo associado principalmente a dados de coleção. Segue o padrão Darwin Core para formatação das tabelas. O padrão é fixo, o que significa que as colunas de sua tabela precisam estar de acordo com os termos já publicados ou seus dados não podem ser disponibilizados. Dessa forma o Darwin Core é ideal para banco de dados pois já sabemos exatamente o que esperar em número de colunas e nomenclatura.

Pontos fortes: facilita a coleta de informação em massa para tomada de decisões e minimiza o número de erros.

Dados de coleção no Metacat?

O padrão Darwin Core pode ser descrito dentro do EML. Você poderia deixar um EML template seguindo o formato Darwin Core e apenas preencher as células com a informação que chegasse na coleção.

Apesar de simples o processo mas não é o ideal para administração. O Metacat não guarda a tabela de dados dentro do seu banco de dados, são simples arquivos de texto soltos em uma pasta no servidor. Então com o tempo essa tabela deve crescer ao ponto que o nosso humilde Calc ou Excel não irão mais conseguir gerenciar uma tabela desse porte. O Metacat é ideal para pacotes individuais de dados, ele guarda bem dados ecológicos pelo fato de um dia a tabela parar de crescer em número de registros. Em uma coleção a tabela de um grupo provavelmente nunca vai parar de crescer, tornando o Metacat uma ferramente fraca para o trabalho.

Dados ecológicos no IPT?

Sim! Agora é possível com os termos de eventos e mensuração. Irei usar como exemplo um dataset armazenado no Metacat do Peld-1.

A tabela possui essa estrutura:

sitio trilha parcela N posicao X Y especie mês ano cacho numero_frutos densidade abertura_copa serrapilheira
DUCKE LO8 LO8_3500 20822 D 84.34 1.80 Is Maio 2009 Cacho1 52 2 2 20
DUCKE LO8 LO8_3500 365 D 133.80 1.00 Se Maio 2009 Cacho1 261 3 4 0
DUCKE LO8 LO8_3500 20872 D 204.52 1.19 Is Maio 2009 Cacho1 238 3 2 0

Estamos interessados em explorar três termos do Darwin Core para processar esses dados: measurementIDmeasurementTypemeasurementValue. Esses três termos são o minimo para descrever qualquer dado ecológico.

Como converter uma tabela com várias colunas relacionadas para um formato minimo de três colunas sem perda de informação? Com uma coluna de chave primaria, muitos se esquecem desse recurso que identifica cada linha de forma única em um banco de dados. Não precisamos de nada muito complexo, vamos adicionar uma nova coluna aos dados. Todas as manipulações são feitas em R.


dados = read.table('fecosta.257.1-contagem_frutos.txt', header = T, encoding = 'latin1', sep = '\t')
dados$primid = 1:nrow(dados)

Nossa coluna se chama primid e possui valores sequencias até o número de linhas que a tabela dados possui. Com isso temos um identificador único para cada linha e podemos fazer uma manipulação conhecida como tabela dinâmica.


library(reshape2)
dadosm = melt(dados, id.vars = 'primid')

O pacote reshape2 permite mudar a forma que a tabela é apresentada (long ou wide). Usamos a função melt para deixar nossa tabela no formato mais longo possível usando como ancora a coluna primid. O resultado pode ser visto na tabela abaixo.

primid variable value
6 sitio DUCKE
6 trilha LO8
6 parcela LO8_3500
6 N 403
6 posicao E
6 X 139.3
6 Y 3.68
6 especie Is
6 mês Maio
6 ano 2009
6 cacho Cacho1
6 numero_frutos 29
6 densidade 1
6 abertura_copa 4
6 serrapilheira 6

Temos uma tabela com três colunas e sem perda alguma de informação. Essa tabela já pode entrar no IPT, durante a importação só é necessário mapear as colunas com os termos respectivos. Existem outros termos que são relevantes como measurementUnit que não são usados aqui mas toda publicação ecológica deveria preencher, leia a referência do Darwin Core para mais informações.

Algumas pessoas podem comentar que não sabem manipular tabelas dessa forma ou que não tem experiência com tabela dinâmica. Para voltar a tabela ao formato exatamente igual ao inicial basta digitar:


dcast(dadosm, primid ~ variable)

Conclusão

O padrão Darwin Core aos poucos começa a englobar áreas que não explorava antes e a maioria dos pesquisadores não estão dando chance a ferramenta. Eu mesmo já achei loucura dados ecológicos no IPT, mas depois de testar com um dataset de 35 variáveis e 205 mil linhas achei ele bastante robusto. Fora a parte descrita aqui existe a parte administrativa das ferramentas. Mais ferramentas significam mais problemas.

Algumas pessoas andaram me perguntando o que eu acho de alguma dessas linguagens e irei dar minha opinião como programador e como professor visando a parte acadêmica.

Como programador: a melhor das listadas acima é de longe Julia, linguagem recente que talvez ninguém tenha ouvido falar mas com velocidade de processamento impressionante. Na imagem abaixo mostra a comparação de várias linguagens executando algum algoritmo intensivo em relação a linguagem mais rápida do momento, C.

velocidades

Julia não é a linguagem mais fácil de programar mas faz bem o que promete, ter velocidade superior ao R e já possuir suporte completo a processamento paralelo. Se você for fazer uma modelagem séria e souber programar de verdade (fazer gráfico não é programar!) a escolha fica entre Fortran, Go, C e o Java. Eu ficaria com Go, suporte a paralelismo e tão fácil de programar quanto R.

Como professor: Python é de longe a melhor para aprender devido as boas praticas que ensina. Lembra aquele código bizarro que fez a um mês e parece uma bíblia na tela de tão mal formatado que saiu? Nem roda no Python! Repare que não é a maravilha das velocidades mas para os alunos que no máximo vão fazer um índice nem se nota a diferença. E ainda temos o plus que Python é usado em muitos programas bacanas (ArcGIS, Quantum GIS), então você pode estender a capacidade desses programas para as suas necessidades.

Conclusão

Python para ensinar/iniciantes em programação, Julia para pessoas com dois anos ativos de experiência no Python e finalmente Go/Fortran para quem se sente confortável com mais de duas linguagens de programação. Já no nível guru você vai querer dar uma olhadinha na linguagem C, boa sorte manipulando a memoria manualmente!

Não gosto de R, feia e lenta. A única coisa que me agrada é a comunidade que é muito mais amigável do que de todas as outras linguagens que trabalhei. Em três dias você consegue publicar um pacote no CRAN, nas outras linguagens pode levar seis meses ou nunca :D

Como todo grande método eu nasci fora do trabalho. Meu pai, Stanislaw Ulam esta doente e jogava paciência para passar o tempo. Paciência é um jogo onde as chances de vitoria são baixas e meu pai queria saber qual a chance de vitoria com um deck padrão de 52 cartas. Após muitas tentativas de resolver o problema analiticamente ele desistiu e pensou que seria mais simples apenas simular vários jogos e verificar o número de sucessos. No final desses raciocino o inconsciente do meu pai conversou com o consciente e lembrou que o mesmo poderia ser aplicado no trabalho sobre a difusão de nêutrons e muitos outros no campo da matemática e física. Entendendo a importância do que havia imaginado, meu pai correu para o meu futuro padrinho John Von Neumann que me batizou como Monte Carlo, devido a minha necessidade de números aleatórios que o lembrava do casino de Mônaco.

Fiquei bastante popular durante o projeto Manhattan pelo desenvolvimento da bomba de hidrogênio. Hoje em dia todo mundo me conhece junto com meus amigos Markov e Metropolis. Com eles resolvemos integrais que seriam impossíveis, campos inteiros se tornaram viáveis e são populares novamente, como a estatística Bayesiana e o método de máxima verossimilhança usados em resolução de problemas complexos. Meu uso só deve crescer no mundo científico, afinal os problemas sempre ficam mais complexos com tempo.

Espero que a lorota acima tenha agradado porque agora começa a matemática de verdade da publicação. Como descrito acima o método surgiu para solucionar problemas que são muito complicados analiticamente. Durante o projeto Manhattan eles não podiam ficar explodindo uma nova bomba para cada nova possibilidade, assim como Ulam não estava conseguindo calcular a probabilidade de vencer um jogo de paciência. Com isso uma solução numérica pareceu mais simples, vamos dar um exemplo de como calcular o valor de π.

Irei dar um exemplo simples usando a imagem abaixo para descrever a lógica da solução:

quadrado e circulo

Temos um quadrado com o circulo no seu interior. O circulo possui raio r e área \pi r^2, o quadrado por usa vez possui lado 2r e área (2r)^2. Podemos então calcular a proporção de área que o circulo ocupada dentro do quadrado realizando uma divisão:

p = \frac{\pi r^2}{(2r)^2}

Desenvolvendo a equação e isolando a incógnita \pi:

\pi = 4p

Ficamos travados na solução acima, não temos o valor de \pi e também não temos o valor de p. A solução é descobrir o valor de p. Nós temos bastante informação sobre o problema e podemos elaborar algo bastante criativo para solucionar a falta da proporção para descobrir o valor de \pi.

Utilizando a nossa imagem acima podemos calcular a proporção realizando arremessos de dardos dentro da área do quadrado. Todos os dardos estão dentro do quadrado, mas um grupo menor desses cai dentro da área do circulo. Assim podemos definir a proporção como:

p = \frac{\text{dentro do circulo}}{\text{N. de arremessos}}

A nossa acurácia na estimativa de p\pi depende do nosso número total de arremessos. A imagem abaixo foi criada com 10000 arremessos e o \pi = 3.1228.

quadrado, circulo e lançamentos

Esse processo de arremessos em posições aleatórias com a finalidade de solucionar um problema por aproximação é um exemplo da aplicação do método de Monte Carlo. Existem vários exemplos como o paradoxo de Monty Hall ou o próprio problema do jogo de paciência de Ulam. O que precisa ser lembrado é que programas de estatística geralmente não possuem uma forma de simular o seu problema, isso torna a programação algo importante para pesquisadores que não desejam ser limitados. O código fonte em R pode ser encontrado no meu repositório de exemplos: https://github.com/dvdscripter/r-snippets.

Essa semana estive na disciplina Spatial Analysis ministrada pela MarieJosée Fortin. Reparei a tendencia em que a alguns duvidas eram sobre como os coeficientes espaciais “roubavam” a explicação das outras variáveis. O momento era de regressões com fatores aleatórios que capturavam o ruido criado pela autocorrelação espacial.

Correlação não significa causalidade! Vamos imaginar que você esta interessado em saber se o motoristas de caminhão são geralmente acima do peso. Logo você realiza sua coleta e quer quantificar essa relação por uma regressão. Você um resultado maravilhoso com inclinação do modelo diferente de zero e conclui que dirigir caminhões deixa as pessoas acima do peso.

Você esta errado mas não fique triste muita gente erra como você. O excesso de peso é causado por N fatores que você pode ter ignorado e estão influenciando o peso dos motoristas. O fato é que a maioria acima do peso possui uma predisposição inata e combinada com falta de exercícios e alimentação não balanceada causa o aumento do peso.

Quando você fez a regressão imagino um mundo perfeito onde A -> B (A causa B), mas o mundo não é perfeito e A&C -> B (A e C causam B) é bem possível. Se você não é capaz de controlar todos os fatores que afetam seu experimento é incorreto afirmar causa em uma correlação. É por isso que experimentos controlados em laboratório são tão valorizados, isolamento de fatores permite inferir causa. Existe um cenário ainda pior e possível tanto A como C são influenciados por um outro fator Z que causa o aumento de B. Neste caso você pode estar simplesmente trabalhando com um uma variável que serve de via de acesso (proxy).

Isso não invalida suas regressões, apenas muda suas conclusões. Correlações são mais fáceis de serem executas e dão grande poder preditivo dado que os fatores se repitam. Então para os ecólogos de plantão: sim, a abundancia de suas plantas pode ser correlacionada apenas com uma variável que tenta capturar o espaço em vez da qualidade do solo.

Como alguns devem saber eu presto consultoria usando exclusivamente o R. Com isso você acaba criando algumas funções próprias. Em uma consultoria que posso acabar vindo a prestar para uma empresa terei que utilizar alguns cálculos comuns em inventários florestais. Observando as opções de software no momento percebi que constituem uma caixa preta para modificações e verificações dos algoritmos usados. Então resolvi implementar algumas dessas funções no R e disponibilizar o pacote criado para qualquer pessoa.

O pacote se chama FI (forest inventory) e implementa três métodos de cubagem rigorosa assim como os fatores de empilhamento e forma. As funções estão muito bem documentadas e possui até uma planilha de exemplo (instale o pacote e digita ?FI ou ?volume no console do R). Para as pessoas que entendem um pouquinho mais de R ou querem reportar um bug também existe a página de desenvolvimento do pacote, onde podem verificar as últimas modificações realizadas assim como criar um issue informando um bug.

Em um futuro não muito distante deve ser criado uma extensão do pacote FI que acomodo o ajuste dos modelos volumétricos comumente usados. São modelos gerais (utilizando DAP e altura das árvores) e locais (somente DAP), no total resultando em 19 equações.

Devo alguns agradecimentos acadêmicos pelo conhecimento que adquiri utilizando o R. Bruno Spacek Godoy em meu último ano de graduação me introduziu o R e a inferência Bayesiana. A partir desse ponto minha curiosidade por ambas as áreas cresceu bastante e sinto que sem esse chute eu não teria despertado a curiosidade por conta própria. Obrigado Bruno, sei que perdeu muito do seu precioso tempo se esforçando para me fazer entender um novo mundo naquela época.

Atualmente tento virar um guRu na linguagem R aprendendo os três sistema de classes disponíveis (S3, S4 e R5), isso permitira a criação de pacotes realmente grandes como o famoso vegan usado por muitos ecólogos.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 244 outros seguidores