Metadata #2
Noches, meus queridos leitores.
Continuaremos falando sobre metadata.
Como os metadados devem ser coletados? Qual é o grau de padronização destes elementos? Quem deve coletar estes dados? O produtor dos dados? O usuário final? Ou alguém entre os dois?
Existem diversos debates sobre como estes procedimentos devem ocorrer, mas de forma geral, os metadados são coletados com uma relação 1:1. Um dataset, ou um conjunto de feições deve ter, obrigatoriamente um registro nos metadados. Mas como definimos o que é um conjunto?
Para responder esta pergunta, primeiramente precisamos analisar o que iremos documentar. São uma série de fotografia pertencentes à um artigo? Ou é uma série de fotografias pertencentes à diversos artigos, relacionados pelo tema? É uma imagem de satélite, um mosaico ou um conjunto de relatórios gerenciais, com mês, escopo e informações correlacionadas?
Bem, após identificarmos o objeto (ou conjunto de objetos) devemos definir uma raiz comum aos mesmos. Podemos criar metadados para diversos níveis de informações: uma imagem bruta de satélite, um mosaico de imagens, um conjunto de vetores específico e até mesmo feições específicas. Perceba, que conforme especializamos a coleta de metadados, o número de informações também aumenta, por devemos manter a relação 1:1 mencionada acima. Um objeto (seja ele um conjunto de outros objetos) deve ter seus registros de metadados, e isto deve ser aplicado à todos os registros de suas bases.
Não adianta nada documentarmos determinados objetos em um nível e outros não. Seria como (no exemplo da Biblioteca Nacional, do post anterior) ter 1000 caixas com livros diversos e apenas 100 delas descritas no conteúdo.
Este planejamento é importante, pois não queremos informação demais, nem de menos. Informação, na verdade, nunca é demais, mas o custo para a criação de metadados muito detalhados é muito mais caro. Deve existir um balanço entre o que documentar, e o que não documentar.
Na prática, a maior parte dos dados é coletado no nível de datasets, ou seja, no conjunto, e não na particularidade. Um conjunto de imagens SRTM não devem ser catalogadas individualmente (existem dados interessantes para catalogarmos, como a altitude mínima e máxima, coordenadas geográficas, entre outros), mas sim no conjunto de processamento.
Caso os dados SRTM seja processados (interpolados, por exemplo), deve se criar um novo dataset, e catalogá-lo à partir daí.
Agora, quem deve catalogar os dados? O produtor dos dados? O usuário final?
É outra briga de muitas perspectivas. O produtor dos dados, obviamente deve realizar um cadastro minucioso dos processos utilizados para gerar aquela informação. Mas o usuário final, o indivíduo que requisitou aquela informação, tem a capacidade de complementar os metadados, já que somente ele sabe como aqueles dados serão efetivamente utilizados.
Criar metadados é bem parecido com catalogar livros em uma biblioteca. Quem deve realizar este procedimento dentro de sua empresa? Uma pessoal especialmente contratada para isto? (bem, é forçar um pouco a barra, já que muito poucas empresas darão um braço à torcer para um funcionário extra, só para catalogar "mapinhas"). Em geral, os próprios analistas devem catalogar seus dados, mas a maioria dos profissionais pode chiar, alegando que:
- É muito difícil produzir metadados;
- Não veêm os benefícios dos metadados;
- Não existe tempo suficiente para a produção dos metadados;
Bem, todos os casos acima são argumentos razoavelmente válidos, mas facilmente desmantelados por um profissional com conhecimento técnico, pois:
- Produzir metadados exige cuidado e paciência. Mas não é um procedimento difícil. É trabalhoso.
- Quando sua base de dados chegar a uma centena de datasets, ele irá pedir tempo para criar os metadados. Bases de médio porte, com centenas de datasets não são incomuns.
- Um pouquinho de tempo por dia, vinte minutos, meia hora por dia é suficiente para uma pequena equipe atualizar todo o cadastro de metadados de uma base razoavelmente grande. Será que a perda de tempo de um dia inteiro na criação dos metadados para um dataset coletado ao longo de diversos meses é realmente uma perda de tempo? Com certeza não é.
Claro, coletar uma quantidade muito grande de metadados ao mesmo tempo pode ser enfadonho e moroso, portanto o ideal é coletar os metadados aos poucos, conforme os dados são produzidos/inseridos dentro do banco de dados.
Certo, certo, mas qual é a forma de criar e manter um catálogo de metadados para seus dados geográficos? Isto depende de alguns fatores: tamanho da organização, tamanho e diversidade dos dados geográficos e basicamente de gerência departamental.
Pode-se começar de forma pequena, utilizando pequenos documentos formato texto ou utilizar XML. Atualmente existem diversos padrões (falaremos deles depois) que podem ser seguidos, que auxiliam o usuário a criar seus metadados. A maioria dos programas de GIS possuem módulos específicos para a criação e manutenção dos metadados. O ArcGIS possui um módulo embutido no ArcCatalog. Para os utilizadores OpenSource, ou quem não gosta do administrador de metadados do ArcGIS/outros programas proprietários podem utilizar o GeoNetwork, um programa desenhado especificamente para este propósito.
Outros caminhos para o armazenamento dos metadados é o uso de um banco de dados ou arquivos estruturados em XML, que é a maneira mais comum atualmente. Somente grandes sistemas e organizações conseguem migrar todos os metadados para um ambiente relacional, mas não deveria ser assim. Aplicações tem de ser desenvolvidas para suprir essa deficiência. Algumas, como o GeoNetwork já existem.
Duas dicas importantes:
- Não invente seu próprio modelo de metadados (já existem vários! um deve servir para você. reiventar a roda é (na maioria dos casos) perda de tempo)
- Não confunda a apresentação dos metadados com os metadados. Como já diziam, uma coisa é uma coisa, e outra coisa é outra coisa. A capacidade de traduzir os dados brutos em informação real (como relatórios de "estoque" de dados geográficos) é vital para o sucesso dos metadados.
Esta, como disse, é uma discussão praticamente sem fim, pois através dos metadados podemos simplificar de forma exponencial o trabalho e os retrabalhos com nossos dados espaciais. Buscar dados existentes (especialmente em grandes organizações), catalogar as novas informações e publicar isto aos usuários dá agilidade, confiança e principalmente economia de recursos (humanos e capital financeiro).
Na próxima ediçao, padrões de metadados.
Abraços
Related posts:
Páginas
Tag Cloud
ArcGIS ArcObjects Banco de Dados Banco de Dados Geográficos Conceitos dev ESRI Geo Aplicado Geoprocessamento GIS OpenSource PostGIS PostgreSQL Python SIG
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Últimos artigos
- Analise de adequacao do terreno para implantacao de Parques Publicos, usando SIG e AHP – parte 4: conclusoes
- Analise de adequacao do terreno para implantacao de Parques Publicos, usando SIG e AHP – parte 3: resultados
- Analise de adequacao do terreno para implantacao de Parques Publicos, usando SIG e AHP – parte 2: metodologia
- Analise de adequacao do terreno para implantacao de Parques Publicos, usando SIG e AHP – parte 1: apresentando o problema
- Nova Geracao do Sensor Web Enablement – parte 4: desafios e trabalho futuro
- Nova Geracao do Sensor Web Enablement – parte 3: mudancas previstas
- Nova Geracao de Sensor Web Enablement – parte 2: precedentes em Sensor Web
- Diquinhas de ArcGIS #3
- GeoKettle 2.0 lançado
- Diquinhas de ArcGIS #2
- Map of Metal
- Nova Geracao de Sensor Web Enablement – parte 1: apresentando o problema
- Diquinhas de ArcGIS #1
- Jaspa 2.0 disponibilizado
- 52N lança novas versões de softwares
Categorias
- Adriano Hantequeste
- Alex Tinoco
- Alfredo A. Guimarães
- George Silva
- João Tácio Silva
- Rodrigo Sperb
- Uncategorized
- Vicente Martins
Administração
Stats
Visitas hoje: 83
Visitas totais: 301
Visitantes online: 1
janeiro 30th, 2010 - 15:08
Muito Bom !
[Translate]