search

HXL-CPLP / forum

Fórum do Grupo de Usuários do Padrão HXL da Comunidade dos Países de Língua Portuguesa, "HXL-CPLP"
https://github.com/HXL-CPLP/forum/issues
The Unlicense
2 stars 0 forks source link

HXL-CPLP-Dictionarium_Vaccinum: Lexicografia de conceitos usados na troca de dados relacionada a vacinação (inclusive COVID-19) #59

Open fititnt opened 2 years ago

fititnt commented 2 years ago

Esse tópico fica como referência interna nossa para fins de como documentamos conceitos relacionados a troca de dados relacionada a vacinação.

Nota: a descrição desse tópico é um rascunho. Eventualmente podemos adicionar mais informações.

Anexos:

Alterações no tópico:

fititnt commented 2 years ago

ping @augusto-herrmann @ppKrauss. Tem algo que tenho interesse de que acabe sendo revisado por vocês dois: os campos relacionados a descrever conceitos que se aplicam a locais no mapa. Uma e outra coisa prática podemos deixar lá no tópico https://github.com/augusto-herrmann/transparencia-dados-abertos-brasil/issues/26 do Herrmann (já que isso seria muito relacionado a P-Codes).

A questão de como representar locais (seja por códigos, seja por nomenclatura a nível de país) é super importante (e, isoladamente da um trabalho dedicado) porém como uma das metas é que o resultado final tenha tradução técnica eventualmente tradução viável para ser oficializada (isto é, endossável por organizações ou governos) então seja troca de dados pública, ou privada, os softwares que processam isso vão depender zelo extra. Esse zelo extra começa com taxonomia, depois com garantir que sistemas existentes (sejam P-Codes da OCHA, ou OpenStreetMap, ou outros, como o ISO 3166-2, que já tem subdivisão), consigam tanto associar informações com mapas, como com dados populacionais.

Um problema super importante aqui: por questões de licenciamento, associar trabalho sério de traduções (mesmo que seja "recomendar ler padrão técnico para entender implementação de lexicografia final) a códigos que dependeriam da ISO 3166-2 não é viável, pois a ISO ativamente não tolera traduções, o que implica que tipicamente apenas Inglês/Frances teriam algo oficial. Some a isso que boa parte dos padrões ISO 3166-2 não tem nível granular melhor do que equivalente a Estado/Província na maioria das regiões comparado a outros sistemas, então além de impedir obras derivadas, nem mesmo é util.

Outros comentarios a respeito de "entregáveis"

Ainda que, pelo menos nós do HXL-CPLP, vamos tentar ter tabela que serve tanto para guardar dados que permitem adicionar traduções, como relacionar padrões de códigos (por exemplo, como países podem não estar usando "o termo mais ideal", ter coluna que diga qual equivalente algum país (ou regiões de país) estão usando, é provável que o que seria consumido por outras aplicações seriam formatos mais simples do que as planilhas que a gente usa.

Além do que é publicado no https://github.com/HXL-CPLP/Auxilium-Humanitarium-API (que usa Ruby) a ideia é permitir que implementadores consigam exportar partes que lhes interessam do dicionário publico principal. Uma implementação está aqui https://hdp.etica.ai/hxltm/archivum/ (ela permite exportar HXLTM para algo mais comum, como TMX, TBX, XLIFF, etc) porém eu já sei que é necessário otimizar que pessoa desenvolvedora criar template (e, por parametros extras, a pessoa escolha qual idioma quer gerar) para que possa usar HXMTL diretamente para gerar documentação técnica ou scripts.

A tendência final é que seria possível deixar especialistas gerenciando de forma colaborativa até um Google Planilhas e toda uma automação pode re-gerar todo resto.

augusto-herrmann commented 2 years ago

Sobre os conceitos aplicáveis a descrever locais no mapa, no Brasil há um padrão adotado pelo governo federal (Exército Brasileiro, e-PING, Comissão Nacional de Cartografia). São as Especificações Técnicas para Estruturação de Dados Geoespaciais Vetoriais (EDGV). Ele contém vocabulários controlados para diversos elementos topográficos (relevo, hidrografia), sistemas de transporte (rodoviário, aéreo, etc.) e outros. Exemplo:

viaduto

Não sei se é exatamente isso que você tinha em mente, @fititnt, mas fica aí a referência.

fititnt commented 2 years ago

Caralho, eu conhecia a Infraestrutura Nacional de Dados Abertos (INDA) não sabia que existia a Infraestrutura Nacional de Dados Espaciais (INDE) (link https://inde.gov.br/).

O INDE até mesmo tem um visualizador em https://visualizador.inde.gov.br/ (que libera para carregar camadas de outras regiões, inclusive de fora do Brasil).

Eu estou lendo o ET-EDGV 3.0, link https://bdgex.eb.mil.br/portal/media/edgv/ET-EDGV-3_0_210518.pdf, e o IBGE é _apenas_um membro. O INDA literalmente tem várias partes interessadas, e o documento mostra que existe um interesse não só em melhorar a troca de dados dentro do Brasil, mas uma busca por interoperabilidade internacional. Mas eu sei que essa interoperabilidade internacional é complicada (vou comentar logo em seguida).

Relação com CODs

Captura de tela de 2021-10-16 09-25-44 Link: https://www.humanitarianresponse.info/applications/data/country-region

Tudo me leva a crer que uma parte muito interessada seria o próprio INDE. O IBGE é mais conhecido porque ele publica os codigos e os shapefiles usáveis, mas fora COD-AB (shapefiles e afins) e COD-PS (população), quase todo o resto dos do que poderiam ser CODs reusáveis seria o INDE, não IBGE.

Vou parar e ver um pouco mais e já continuo aqui. Mas, embora tudo isso que falou até resolve um problema maior. Mesmo que demore, vale a pena.

fititnt commented 2 years ago

Voltei. Resposta longa, mesmo se evoluir colaboração, super ok levar meses, pois documentação é complicado. Mas vale a pena já a médio prazo!

Não tão fora de tópico, mas relacionado: sobre CODs do Brasil

Creio vou citar rapidinho sobre potencialmente a gente ir atrás do INDE Aproveitar o INDE (não IBGE) para sugerir ser fonte oficial de governo enviando CODs do Brasil. O motivo disso é eles já seriam os maiores interessados não só no COD-AB do Brasil, mas de ter outros CODs nacionais no HDX (link do Brasil: https://data.humdata.org/group/bra, link geral dos países: https://data.humdata.org/group).

Não existe muita referência de como ajudar, mas ao mesmo tempo não tem informação de que ajuda é necessária (mas eu sei que é). Então, na dúvida, fica aqui minha impressão pessoal de o quanto brasileiros podem ter impacto positivo ao ser proativo em vez de reclamar de que as coisas não estão funcionando.

Então, normalmente as equipes que preparam datasets lá, que já são super reduzidas considerando o impacto e a complexidade além de apenas uma língua, focam em cuidar de datasets de lugares que tem resposta humanitária. Muitos outros datasets do resto do mundo são tipo gerados automaticamente de forma padronizada (como do WordBank, Facebook, Insecurity Insight, etc; código dos cralwers está público em https://github.com/orgs/OCHA-DAP), mas tem coisa que é feita de forma bem mais individualizada, como caso dos shapefiles. Existe uma preocupação em ter pelo menos os COD-AB atualizados uma vez por ano (mesmo de países sem ação focada).

Além do COD-AB do Brasil (que foi atualizado para ter P-Codes baseado nos códigos do IBGE) ouvi meses atrás que os da Argentina e do Chile não estavam no ITOS Standard e passaram a quebrar o pipeline de automação da WFP (mas quem falou isso comentou que esses países têm governos funcionais que teriam capacidade de resolver isso). Na época eu lembro de perguntar onde tinha o tal ITOS Standard, (que na prática provavelmente era sobre renomear campos de XLSX e shapefiles olhando como é feito nos outros países) mas mesma pessoa falou que talvez esse tipo de coisa não esteja bem documentada a ponto de gente de fora fazer os tais CODs para enviar para o HDX porque provavelmente isso é incomum.

Voltar ao assunto agora

1. Da ideia original da postagem (foco dados geo)

O motivo original do tópico (citei antes o ping @augusto-herrmann e @ppKrauss) não era criar/publicar CODs (mas aproveitei pra comentar que vale a pena incentivar isso!!!) e sim mais de nomenclatura reusável ao trocar dados; os terminologia relacionados a geografia são especialmente reusáveis em quase tudo (não apenas sobre vacinas).

Uma coisa muito interessante de rever CODs do Brasil é, mesmo que os convenções (quando existirem) no meio humanitário não estejam muito bem documentadas, super valeria a pena não apenas incentivar via INDE publicação de candidatos a CODs, mas documentar como outros poderiam fazer isso. Essa documentação também é relevante porque a partir dela dá para criar ferramentas que entendem dados publicados em CODs ao redor do mundo, e mesmo se houver mudanças em padrões, daria para acompanhar como o INDE mudou a documentação.

Meses atrás comecei a fazer isso lá no Hapi (https://hapi.etica.ai/, https://github.com/HXL-CPLP/Auxilium-Humanitarium-API) mas parei para fazer outras coisas quando passou a ser necessário ir mais fundo em taxonomias, principalmente relacionadas a P-Codes. Eu ainda estou vendo áreas mais abrangentes, mas o problema de saber como documentar da melhor forma convenções que já existem (ou propor novas se nada formal tiver) nessa questão de dados GIS (em especial como a anexar metadados às coordenadas) precisa existir antes de começar a traduzir.

Vale lembrar que até mesmo dentro da ONU (no caso, dados publicados no HDX) eles não têm automação para chegar se por exemplo os XLSX com metadados enviados para o CKAN de datasets marcados como CODs estão num padrão. Ou seja, criar utilitários que validem se dados tabulares estão em conformidade pode ajudar tanto colaboradores externos como checagem automatizada no futuro também deles.

Em outras palavras: baseado em minhas experiência no @HXL-CPLP, acredito que o INDE pode ser fundamental para melhorar ainda mais interoperabilidade de dados no Brasil, mesmo que isso implique em ajudar a definir padrões internacionais. Tanto pessoas que já atuam no meio humanitario que são do _global north_ estão sobrecarregadas e ter traduções igualmente equivalentes em português não se trata apenas de ajudar o Brasil (que já tem uma cultura de dados abertos, logo padrões terminologia aberta não seria novidade), mas até mesmo por causa de licenciamento muitos padrões como os da ISO, que são apenas Inglês/Frances, não atendem uma demanda da área humanitária nem mesmo nessas línguas.

1.1 Sobre vocabulários controlados multilíngue (um exemplo de colaboração relevante)

No meio humanitário geralmente se usa HXL e (embora não encontre local que explique) campos como admin2Name_en e admin2Pcode (o COD-AB do Brasil não está assim; os únicos outros que também não estavam era ou talvez continue sendo Argentina e Chile, que não são local com foco). Daí que pelo menos ter documentação (mesmo que tenha que ser criada em Português, em vez de esperar traduzir algo que talvez nem exista) faz sentido. O HXL a gente do HXL-CPLP + comunidade HXL internacional consegue (e podemos nos basear em opiniões daqui), mas falta o resto.

A ideia de vocabulário multilíngue (que interliga conceitos de forma revista, melhor do que minerar Wikidata/Wikipedia) é que, no mínimo, dois usos de caso. Daí pelo menos duas necessidades distintas

1.1.A. Exportar glossários e facilitar geração de documentação entre línguas diferentes.

Inicialmente, pelo menos termos primitivos, como (em português) latitude deveriam ter o máximo de informações, ao estilo do que aconteceria em uma terminologia tradicional. Isso permite tanto gerar glossários como, aqui muito relevante, o cuidado extra de adicionar definições e explicar mais a fundo os termos chave, facilita na etapa de traduzir termos chaves para novos idiomas.

O cuidado extra para adicionar contexto maior também permite que se uma pessoa falante de português checa não so o termo latitude, mas ve informações adicionais (desde referências a glossários externos, mas descrição na língua dela) ela se sinta mais segura para saber que pode usar termo relacionado aquele conceito e gerar documentação do seu software para outros idiomas de forma controlada.

Sem se alongar, usos de casos são Europe IATE https://iate.europa.eu/fields-explained. Padrão de dados mais próximo é TBX https://en.wikipedia.org/wiki/TermBase_eXchange.

1.1.B Viabilizar meios de relacionar conceitos do 1.1.1 com o que, de fato, convenções usam.

Nota: boa parte do que é dito aqui é também inspirado na forma como HXL usa "+attributos", vide https://hxlstandard.org/standard/1-1final/dictionary/, para entender o que algo significa em formato tabular sem necessidade de usar algo mais estruturado como JSON e XML. Embora tais relações poderiam ajudar humanos a entenderem outras implementações e criarem manualmente conversores, também poderiam acabar gerando os conversores em si.

Ainda que um cuidado para desejar o 1.1.1 como se fosse um dicionário idealizado (com grafia recomendada, ter abreviação, etc) implementações de fato (em especial em situação de urgência) mesmo quando a informação é primitiva (isto é, e geralmente um campo não teria apenas 'latitude', mas 'coisa_latitude') o que de fato cada país pode usar pode mudar. Ou seja, Brasil e Portugal ainda poderiam trocar dados a nível nacional de forma diferente.

Então, tem também a questão de que mesmo dentro de um país, como o Brasil, cada região poderia estar trocando dados de forma diferente (e os conceitos mais importantes são os mesmos; informações extras muito específicas tendem a não precisar documentar). Então se existisse uma forma de anotar as relações entre os campos (como forma de que cada lugar chama latitude em uma tabela de equivalência de 1 para 1, que na prática não é viável, mas às vezes é quase) seria possível abstrair como é feita a troca de dados. E normalmente atualizações envolveriam alterar o local onde ensina as equivalências, não ir sempre para código que converte.

Enquanto o glossário 1.1.1 é projetado para longo prazo (pense dicionários, algo que quando bem escrito, é reusável por décadas ou séculos; por isso informações como 'formato de dado' não devem ser hardcoded em definições de conceitos) as convenções de facto, podem ficar a cargo de especialistas de tecnologia. Infelizmente o mundo real é complicado, e casos onde depende de apenas renomear colunas são incomuns, se situações mais simples são aquelas em que a necessidade de lógica extra é apenas converter formato de dados (como data). O mais comum são dados que dependem de coluna extra (como população por região geográfica, para fazer cálculos). Sempre vão existir campos que são tão específicos de um implementador que não teria como explicar relação com dicionários, então nem mesmo com scripts customizados isso seria viável.

1.1.B.1 Tecnicamente, uma abstract syntax tree (AST)

Nota: essa explicação sobre AST não importa muito para a questão do glossário (mas um uso avançado que depende de conceitos bem criados).

Programas que tentem usar o dicionário para explicar o que cada campo significa, ou para converter entre formatos, não requerem definição de um padrão universal. Implicitamente essa relação é uma representação não binária de uma Abstract Syntax Tree (AST).

Na questão ligada a geo, essa AST fica mais simples se subdivisões de países usarem conceito adm1, adm2, adm3, adm4, e adm5, mesmo que localmente tenha outro nome. Também deveria ter uma forma intuitiva de explicar como uma pessoa converte um dado local, por exemplo códigos do IBGE, para um P-Code (TL;DR: adicionar prefixo BR).

Não tenho certeza de como generalizar coisas como explicar de forma simples conversão de CEP (que é de uso obrigatório no Brasil) para Código IBGE (ou diretamente P-Code. Mas deveria ser possível anotar que uma coluna de dados depende de conversão com outra tabela em disco (mesmo que isso implique ter tabelas pré-compiladas).

Algo que simplifica ASTs é garantir que informações usadas com frequência o usuário tenha condições de baixar uma cópia local. Porém desestimula que usuários coloquem dados privados nela (como senhas de bancos de dados). Outro uso do caso é dar pelo menos alternativa de arquivos que funcionem com e sem acesso a internet por questões de segurança. Formas de atender esses requisitos é dar alternativa de usar um nível de abstração, como URNs (prova de conceito aqui https://github.com/EticaAI/HXL-Data-Science-file-formats/issues/13). Se bem feitinho, até mesmo ASTs que fazem tratamento de dados sensíveis não têm risco de ficarem expostas, podendo inclusive ser deputadas de forma separada. Isso permite que quem de suporte não precise ter acesso aos dados.

Na data atual, 2021-10-18, não tem prova de conceito de AST de convenção, mas ficou claro na semana passada que os estudos de caso de compartilhamento de vacinas já ia exigir algo nesse nível. Brasil por exemplo compartilha dado individual e vi Califórnia nos EUA já fazendo de forma agregada, então estou pensando em pelo menos as relações entre conceitos ficarem em formato YAML em vez de diretamente mas planilhas HXL. Essa abordagem pode também ser menos intimidadora para quem programa.

2. Exemplos práticos de conceitos necessários

Eu sei que esse comentário aqui ficou amplo demais, porém vou dar exemplos do que sei que temos dificuldade de explicar e que estão aparecendo muito e que são são relacionados a forma de representar conceitos relacionados a locais no globo terrestre.

Eles (e forma de relacionar população com eles) são extremamente reusáveis no meio humanitário.

2.1 O básico: conceito de latitude, de longitude e de altitude/elevação e afins (conceito Internacional)

Caso seja viável a descrição do conceito ser em linguagem culturalmente neutra (se é que isso faz sentido; considerem o ponto de vista de todos os hemisférios) melhor.

Tanto altitude/elevação parecem ser usados em português para o mesmo conceito. Sinônimos são viáveis, porém como uma meta seria eventualmente ir atrás de validação a nível da língua portuguesa, o português europeu além da Europa também influência no resto da CPLP, logo se até mesmo rascunho já considerar ponto de vista deles (ou ter justificativa de porque seria melhor termo) maximizar chance de não ser revisado.

Na dúvida, o interesse maior de foco são termos que aparecem na troca de dados. Em geral tais descrições não contém formatação do dado (isso facilita traduções e impede duplicar conceitos por causa de formato).

Conceitos relevantes para glossário (mas que não costumam aparecer em campos de dados) são bem vindos, mas a otimização final é menos complexa. Então anotar diferenças do que pode ser campo de dados e o que não é, se torna relevante.

2.2 Regiões administrativas: adm1, adm2, adm3, adm4, adm5 (conceito internacional, linguagem neutra)

O mais próximo que existe de nomenclatura para compilar dados de todo mundo é usar regiões administrativas. Se até mesmo no Brasil a primeira subdivisão já usa nomenclaturas diferentes, imaginem o resto do mundo. A forma de nomear campos vai muito além da tradução.

Esses conceitos são usados em trocas de dados humanitários mas, exceto pelo próprio padrão HXL, a documentação que poderia ser otimizada mais tarde para traduções igualmente confiáveis é escassa. Outro problema é que mesmo que a gente tente pedir uma explicação formal, talvez nem mesmo quem trabalhe mas agências da ONU se sintam confiante em dar uma definição mais formal. Mas, se eventualmente houver rascunhos de propostas do que, via especialistas do INDE (não algo informal, como sem ajuda a gente do HXL-CPLP conseguiria), de definições e afins, no mínimo é possível pedir ajuda para saber se "não está errado", e, dar tempo que isso pode evoluir para algo mais assertivo.

Eu sei que não é o ideal, mas provavelmente muita coisa evoluiu de projetos mais antigos que nunca foram documentados. As pessoas que trabalham hoje podem não ter certeza.

2.3 Nomenclaturas tipicamente usadas no Brasil ligadas a posição geográfica de endereços (conceito local linkado a equivalente global)

O que é logradouro? Logradouro é um termo mais correto do que rua? Para conceito de logradouro (como usado no Brasil) é possível saber em caráter não oficial se português europeu também usa a mesma palavra (mesmo que com grafia diferente) e não uma palavra totalmente diferente?

Terminologicamente falando, um campo que contenha valores que representam IBGE31 (Minas Gerais) e IBGE 53 (Distrito Federal) deveria ter qual termo (exemplos vistos: "estado", abreviação "uf", e porque? Muito importante (para conversões entre padrão internacional e nacional): à qual região administrativa esse conceito seria convertido a nível internacional? O que o IBGE chama de município também é relevante.

Para terminologias mais únicas do Brasil (que não são mera tradução, pois variam de país para país, que é o caso de regiões administrativas), mesmo que a longo prazo, seria viável (assumindo habilidade para manter/revisar conhecer Excel intermediário e se comunicar com partes interessadas, mesmo que seja receber e-mails) ter até mesmo traduções oficiais dos termos para outras línguas ao ponto de ser usável sem receio até em nível de comunicação diplomática? Receber comunicação significaria deixar pronto como é o Brasil, mas depois de pronto quem mantém atualizado (exemplo, traduções de outros idiomas) pode ser gente que atua em secretaria (sem necessidade de gasto adicional).

Ainda sob o parágrafo anterior, mesma lógica de explicar Brasil (conceitos usados para tipos, de adm1, adm2, adm3, e não nomes de lugares pois é politicamente sensível) toda estrutura de documentar (e do Excel gerar gerar formatos mais amigáveis) de como Brasil, pode evoluir para receber de outras embaixadas (ou da sociedade civil) como outras regiões se chamam internamente seus tipos (como o que aqui seria UF e município). Isso é uma necessidade internacional e nacional.

Outros conceitos relacionados a locais podem ser sugeridos, os relacionados a como são chamadas regiões administrativas, embora de para rascunhar algo (inclusive automação para gerar formatos finais reusáveis internacionalmente) cedo ou tarde precisariam ser revisados ou atualizados. A ISO é inviável (burocracia, falta de traduções, incapacidade de gerar formatos parseáveis por máquina), e a ONU não tem recursos de pessoal (além da burocracia e pressões internas) mas nada impede a gente considerar algo que, até ficar na mão de alguma pessoa que ajuda tanto Brasil como outros países. Por exemplo, USA de forma pública tem CIA World Factbook e a Library of Congress o language codes (equivalente ao ISO 639-2) que é licença domínio público, logo a ideia de um país compilar e publicar dados do mundo é comum.

2.4 Terminologia que possa ser útil em missões de paz e gerenciamento de emergência

Não digo que precisa ser desde o início, mas se começar a ter rascunho de dicionário, como onde INDE também tem membros das forças armadas, uma sugestão que faço é tentar ver opiniões de quem tenha trabalhado em logística de alguma operação de paz e de resposta humanitária do Brasil na ONU. Sugestões baseadas em experiência em campo de falta de terminologias que sentiu falta de padronização/tradução ao trocar dados com outros países seria extremamente relevante. Por exemplo: como descrever poço artesiano, tanto nome como códigos para por em mapas é algo intuitivo, mas talvez a pessoa de contato possa dar sugestões adicionais, como necessidade de ter código para anotar se posso está vazio (o que economiza combustível e tempo). Aqui apenas da do exemplo.

Uma curiosidade: tanto HXL Standard como outras iniciativas, a exemplo do Translators Without Borders, citam Haiti 2010 como motivo que gerou o início deles. Porém mesmo na comunidade internacional do HXL, a maioria ativo hoje não estava ativo no evento do Haiti (e o padrão na época era bem diferente), mas sabe-se que era muito complicado conciliar dados. A natureza tipicamente de caráter sensível impedia também a documentação pública de Terminologia usada.

O ideal aqui, além dos dados que já são úteis genericamente de posicionamento, é ter pelo menos códigos para atributos como nomenclatura para usar na troca de dados de operações de campo. Talvez até os shapefiles e .dbf tenham alguma convenção, mas a gente do HXL-CPLP não sabe se alguma agência da ONU tem documentado algo para sugerir ao compartilhar dados em HXL. Então quando surgir algo (se é que isso já não é necessário de forma frequente) daí já tem se padrões mínimos para uso do que aparece em mapas e planilhas.

2.5 Outras sugestões? São bem vindas.

Caso o pessoal do INDE tenha outras sugestões de termos, nossa preocupação via HXL-CPLP é implicitamente ajudar a documentar terminologia usada no Brasil e viabilizar linkar com internacional, mesmo que conceito internacional precise ser criado. Então tentar trabalhar para permitir receber traduções.

Também temos muita preocupação em otimizar que a atualização possa ser feira por pessoal que trabalha em secretaria, mesmo que ferramentas tenham que ser criadas para isso.

Um próximo passo a médio e longo prazo, para cada lexicografia que precise de correções constantes, é tentar "doar" para alguma entidade que um humano com condições de atualizar. Por isso também nosso interesse de fazer dogfooding de ferramentas que tranformem planilhas em algo imediatamente pronto para ser usado por todo o resto. Isso porque a tendência é que nesse tipo de fase alguns dicionários tenderiam a envolver receber sugestões por e-mail de qualquer pessoa do mundo (ou talvez via governo, solicitar ajuda de embaixadas Brasileiras lá fora; ou então órgãos do governo que tem interesse) ajuda com situação de terminologia (normalmente traduções). Creio que analogia com exemplos dados dos EUA (CIA vs Library of Congress) para coisas que precisam atualização seja mais para biblioteca (ou o próprio INDE), e não a ABIN. Óbvio que esse tipo de padronização é útil para troca de dados (inclusive contexto de missões de paz) mas é mais sobre um dicionário, termos em língua natural.

Enfim, conceitos de latitude, longitude, altitude/elevação, adm1, adm2, adm3, adm4 eadm5` já seria algo fantástico!