A equipe LexML do Senado vem aprimorando a sua ontologia fundacional (ref) com a ajuda de bibliotecas e outros grupos inter-institucionais, além do pessoal da Câmera e do Senado… Com a ontologia pronta puderam desenvolver o “Glossário de Termos Legislativos do Senado”, de 2018
É uma importante referência para quem está tentando desvendar dados legislativos, ou querendo entender o “processo legislativo federal”… Como metadado, vale a pena solicitarmos (XML ou JSON da ontologia inteira).
Em primeiro lugar, acho super maravilhoso esse tipo de trabalho!
Mas vou comentar aqui uma dificuldade de termos esse tipo de informação em formato legível por máquinas. Pensar em como pessoas (que sabem da ideia, mas não tem ferramentas) poderiam contribuir para compilar esses dados de modo gerar uma revolução para quem precisa deles de forma estruturada.
O padrão de dados (que não envolveria usuário aprender editar RDF na mão) mais próximo do que isso que você propõe seria o TermBase Exchange. A versão de TBX de 2008 ficou aberta porque a organização criadora faliu.
NOTA: marcação XML/JSON para algo como glossário não é ciência de foguetes. Resumindo: forma de hierarquia é anexar a domain (área de conhecimento do conceito) e como normalmente são multilingues, é obrigatório especificar o idioma de cada termo. Por isso tudo que vou dizer aqui requer muito menos tags do que um subset do HTML que vocês conhecem.
Eu gosto da ideia de ter um formato JSON, mas até o XML parou no tempo. Toda revolução da indústria de sair de padrões XML para troca de informações em JSON (e mais tarde JSON-LD), nunca aconteceu com relação à terminologia.
Terminologia (seja monolingual, apenas e apenas um país, ou para ter consistência entre países) é indiscutivelmente importante para sociedade. Não obstante como quem insere os dados implica em um público pequeno (não por acaso um dos usuários é o Europe IATE) até mesmo ferramentas iniciadas mais de uma década atrás (talvez pelo entusiasmo de desenvolvedores) parou no tempo.
Então, por mais que criar tais glossários (mesmo multilingues) é bem mais padrão que gerenciar RDF completo, não apenas open source ferramentas para criar, mas para ler/extrair dados de .tbx, tem bugs.
Mais sobre o Europe IATE aqui:
Muito provavelmente o glossário foi feito usando editor de texto como MS Word na base de copiar e colar. Imaginem a motivação de humanos para atualizar esse tipo de documento ou manter sincronizado com outras fontes internas mais estruturadas.
Com passar do tempo cada lugar talvez crie própria ferramenta para gerenciar o próprio tipo de glossário (gastos extras; inviável generalizar para outros setores até mesmo do governo; padrão de troca de dados incompatíveis).
Notem que “o que importa” (os termos, descrição, área de conhecimento,…) desse documento, mesmo para quem não conhece TBX, não é algo que pareceria ser difícil de expressar em um JSON da vida. Mas na falta de ferramentas (pelo menos que sejam mais simples do que poder completo de interface de RDF) que ajudem a gerar documentos como esse, a vida dos usuários para ajudar a organizar dados é muito prejudicada.
Imaginem a quantidade de servidor público que poderia ajudar a organizar termos (como os que poderiam mais tarde aparecer em dicionários de dados usados para descrever conjuntos de dados) mas… (sem cada lugar criar próprio software), o estado da arte para fazerem isso é MS Word trocado por e-mails!
Não sei se a Câmara e o Senado usam algum padrão de dados, banco de dados ou sistema interno para fazer a manutenção do glossário, mas suponho que sim. Ainda mais considerando o histórico do Senado com a criação do LexML e o uso de ontologias, liderado pelo Dr. João Lima. Acho muito improvável que o documento tenha sido produzido usando trocas de e-mails com documentos do MS Word anexados.
Hoje em dia existem muitos softwares prontos, inclusive livres, para a criação e a manutenção de glossários, como o TemaTres, iQVoc, SkoHub, Skosmos, etc. E o padrão de dados adotado pelo W3C para tesauros é o SKOS, que também é usado para estruturar o EuroVoc em algumas opções de download. EuroVoc é o tesauro multilíngue para assuntos da União Europeia.
Estou adorando onde essa conversa pode levar! Vou separar em 3 argumentos.
TL:DR: No contexto de dados abertos (que é o foco do fórum) glossários / terminologia / vocabulários / códigos-de máquina são ligados aos… metadados (como documentar / garantir consistência) na troca de dados. Além do foco do post, quase tudo que seria considerado chave primária em conjuntos de dados abertos e é endossado por alguma entidade governamental é um candidato para destaque.
Uma questão de ordem aqui.
Acho muito improvável que o documento tenha sido produzido usando trocas de e-mails com documentos do MS Word anexados.
O padrão final que tipicamente vemos em entregáveis é apenas um resumo da informação, e a quantidade de pessoas para “copiar e colar” é muito pequena. Vou dar dois exemplos (o segundo por inferência natural).
Trivia: dos links que passou, o SKOS (que é algo mais próximo de RDF, então imaginem conceitos/termos mais perto de usuário final) foi discutido também por e-mails:
https://lists.w3.org/Archives/Public/public-esw-thes/
Entendo que o SKOS, assim como SchemaOrg, e até mesmo HTML5, envolvem discussão, mas a decisão de conceitos e como usar códigos para eles sempre envolve discussões que não vão no resultado final que é exportado para consumidores.
Tomemos como base o Deputado Federal
O próprio glossário de Deputado Federal dá uma ideia de onde tal termo pode ter vindo: “CF, art. 45.”. Não obstante como chegaram nessa definição? Como descobriram que essa tal CF teria o conceito que eles precisam? Eles tiveram que ler toda essa CF? Por analogia com o que ocorre com lexicografia técnica, será que a escolha dos conceitos/termos não envolveu muito mais pesquisa do que apenas essa CF?
Até mesmo se pegarmos áreas que parecem “mais uniformes” (imaginem códigos + nomes + geometria de locais, como os códigos do IBGE) toda cadeia de decisão para gerar os conceito é muito sofisticada.
Vou evitar escrever mais sobre estratégias de lexicografia (mas existem) mas a maioria das automações e guias são focados para dicionários de termos em toda uma língua, onde automação é usada para obter textos de referência, converter eles em um formato legível por máquina, e então ver frequência em que termos aparecem.
Não obstante, quando falamos de lexicografia prática, cada área pode ter próprios padrões para definir o que é importante: é necessário pesquisa de usuário (ou pelo menos ver com experts ou organizações do setor o que eles querem garantir consistência na troca de informações). E possivelmente eles já tem alguma forma de organizar esse tipo de informação, e ao republicar tais dados, daí sim, pode ser um processo de principalmente conversão de arquivos.
Vale lembrar que dependendo do que é considerado glossário, a analogia mais perfeita seria uma nomenclatura técnica (vide atlas de medicina), ou mesmo uma tabela de códigos ISO (códigos de região abaixo de país) (mesmo que o publico alvo seja um país apenas).
O EuroVoc citado, a eurovoc_export_pt.xlsx, tem apenas 16.945 conceitos. Vamos imaginar se for feita uma pesquisa aqui o Brasil com cada área interessada, áreas como (lista obviamente não completa):
Obviamente tem outras áreas aqui, mas meu argumento é que glossários como os do link do autor merecem padrões de dados compartilháveis, mas mesmo se formos apenas converter arquivos, apenas o setor de geografia daria muito mais conceitos do que os 16.945 do EuroVoc.
No caso da Europa, o Europe IATE (que não substitui outros silos de dados, mas é o mais democrático; equivalente se feito no Brasil seria cada cidadão poder usar eCPF para se autenticar e então poder contribuir; mas modo visitante permitir outras pessoas) num dump que fiz quase agora deu 947.768 conceitos. Porém o Europe IATE é baseado em décadas de compilação de dados (ele já teve mais conceitos, mas repetições foram removidas).
No momento dessa postagem, não tenho como dizer quantos conceitos estamos falando, mas focando apenas em conceitos para interligar coisas (e, embora seja super missão crítica para tomada de decisão como resposta de emergência, excluir estatísticas de dados populacionais) ainda assim seria na ordem de 100.000s conceitos. Em teoria, seria mais fácil chegar nesse ponto se eventualmente houvesse um ou mais locais para publicar dados estruturados (e que já não seja um CKAN), mas a decisão para chegar nisso poderia levar anos ou, no mínimo, envolver testar alternativas, pois é super importante algo amigável a usuário final.
Como dito no TL:DR;, esse tipo de discussão faz muito sentido no contexto de dados abertos.
O problema vai além do que @ppkrauss comentou, e não digo apenas por compartilhar em formato estruturado, mas o fato de que não existe uma estratégia no Brasil de tratar de forma diferenciada o que é considerado informação para interligar dados (e que já não seja um servidor SPARQL completo). Na falta de citar outros países, a analogia mais próxima são o que a UN OCHA (que atua em mais de um país) chamaria de Common Operational Datasets e Vocabularies.
A UN OCHA (que eu saiba) não tem um servidor SPARQL da vida (e o local oficial para compartilhar vocabularies é uma landing page, o resultado são ou páginas HTML ou JSONs sem schema). Os conjuntos de dados que servem para interligar outros dados ao menos são tratados com tags diferentes no CKAN deles. Por exemplo, uma vantagem de tratar (mesmo que seja no CKAN nacional) tais datasets de referência com mais destaque, é que isso estimula demais conjuntos de dados passarem a usar a chave primária deles (em vez de cada um usar próprio padrão). Cada setor da sociedade pode ter seus conjuntos de referência para interligar dados. No caso da OCHA, normalmente eles endossam um padrão de um tipo por vez (ou compartilham uma tabela que exibe mais de um padrão) e a linha base inicial é apenas “ser a melhor referência possível para uso em caso de urgência”; por analogia, endossar um vocabulário usado em um estado que até que haja consenso nacional (que pode nunca vir) é super útil.
Enfim, mesmo que demore alguns anos para diferençar de dados abertos em geral, dar mais destaque/estimular/ajudar a empacotar esse tipo de mais-do-que-conjunto-de-dados vale a pena.
PS.: Adorei que você postou ferramentas focadas em permitir coletar dados de colaboradores (e que já não são de proposito muito genérico)! Eu já conhecia o UNESCO Thesaurus
(e não sabia que era baseado nesse software aberto, o skosmos). Sobre o Europe IATE, tenho impressão que não é código aberto. Vou dar mais uma olhada em especial no padrão SKOS
Certamente que sim. É por isso que na União Europeia, há alguns anos, se formaram grupos de trabalho para criar os Core Vocabularies, que definem quais são os campos padronizados para diversas temáticas como órgãos públicos, empresas, pessoas, etc. Definiram, ainda, as fontes únicas para identificar chaves primárias de diversas coisas também como órgãos públicos, regiões administrativas, etc., que são os chamados Base Registries.
Com todos os diálogos feitos entre o Brasil e a União Europeia, o nome Base Registries chegou até a inspirar o nome do Cadastro Base do Cidadão, mas, à parte de toda a polêmica gerada pela implementação desse cadastro, que não seguiu o mesmo rigor que se vê nas discussões europeias sobre o tema, parou por aí a ideia de definir “cadastros base” que servissem como chave estrangeira para qualquer outro sistema. O máximo que foi feito é um catálogo de APIs de governo que podem ser usadas por outros entes governamentais – o que já é um avanço, considerando que nem mesmo isso existia antes.
Aqui no Brasil, temos os Sistemas Estruturadores, também chamados sistemas estruturantes, da administração pública federal. Eles deveriam ser as fontes primárias para identificar itens em temáticas como órgãos públicos, servidores públicos, orçamento público, licitações, etc. Digo deveriam pois, embora o uso dos códigos oficiais como chave estrangeira seja obrigatório, é comum ver sistemas na administração pública que não usam essas chaves e definem as suas próprias chaves para os mesmos conceitos, causando uma bagunça, dificultando a vida de quem vai fazer análise de dados e aumentando os custos de análise e implementação de políticas públicas oriundos da falta de interoperabilidade.
Do ponto de vista de padrões de dados para a interoperabilidade, existe no governo federal a e-PING, muito baseada no e-GIF do Reino Unido. Para a classificação de assuntos, há o Vocabulário Controlado de Governo Eletrônico, o VCGE, que antes de chamava Lista de Categorias de Governo – LCG, inspirado literalmente na Government Category List - GCL, também do Reino Unido, substituída em 2005 pela Integrated Public Service Vocabulary - IPSV. Ao contrário do IPSV, que procurou integrar termos de governos locais e ser um vocabulário abrangente, em 2013 o VCGE passou por uma reformulação radical e controversa, cortando quase todos os seus termos e se tornando quase como um “espelho” do COFOG, uma classificação de funções do orçamento público com apenas dois níveis e quantidade muito limitada de termos.
Tudo isso andou quase que abandonado no governo federal desde 2017, não entrando nos ciclos de planejamento estratégico, não recebendo investimento, sem ter uma unidade formal designada, sem equipe definida responsável pela temática e sem prioridade. A única pessoa que ainda levava a coisa “nas horas vagas”, heroicamente, era o Roberto Lyra, falecido recentemente, que chegou a fazer uma atualização da e-PING em 2018, com poucas mudanças. A Secretaria de Governo Digital nem mesmo soltou uma nota de pesar pelo falecimento do Lyra. Depois disso, a Portaria SGD/ME n.º 15.065, de 24 de dezembro de 2021, instituiu um grupo de trabalho para discutir o futuro dessas temáticas, para “realizar um diagnóstico e propor a atualização ou a extinção” desses padrões, mas depois disso não fiquei mais sabendo de nenhuma informação, nem mesmo se esse grupo se reuniu alguma vez ou não.
Os processos de construção são os mais diversos possíveis, passando por reuniões presenciais, webinars, grupos e listas de discussão, trocas de e-mails e mais recentemente até mesmo usando controle de versões com o Git.
Para não ficar muito extenso, limito-me a ressaltar alguns exemplos interessantes, que contaram com um pouco mais de investimento e cuidado metodológico:
Percebe-se que para existir uma comunidade ativa mantendo padrões de alta qualidade é necessário haver investimento e priorização política. Por exemplo, somente considerando o período entre 2016 e 2020, a Comissão Europeia investiu 131 milhões de euros no programa ISA² de interoperabilidade para a administração pública.
TL:DR: sua resposta tem desdobramentos sobre estratégias maiores do que vou comentar aqui; então agora vai um a resposta até processar tudo. Além de convenções de padrões de troca de vocabulários e abstrair complexidade de especialistas terem voz final sobre rascunhos (que podem ou não virar convenção de setor, de país, ou internacional) já estou preocupado com seguinte: arquivamento (preferencialmente além de apenas otimizar exportar formato livro) , uso de numeração interoperável mesmo fora da Internet e, (quando passar a exigir ter uma cadeia de decisão) processo de homologação minimalista. Os dicionários que forem sendo compilados com dados de referencia do Brasil já vão automaticamente permitir serem lincados uns com os outros (tópico 3.3 falo disso).
Nessa resposta enorme, divido em 1. Informações de contexto e (do que consegui resumir nesse momento, ou seja, isso é uma tanto uma tempestade de ideias como pode estar incompleto ou mudar de opinião com o tempo) o 2. De (algumas) ideias acionáveis. e 3. De protótipos funcionais (apenas parte de arquivos dos dicionários)
Nota: comento na forma como a ISO usa número para seus padrões como um exemplo para entender a ideia de usar números para nomear os dicionários focados em cada tópico. Se for para endossar, melhor diretamente organizações humanitárias ou organizações em cada país que estejam interessadas em padrões de licença aberta, traduzidos em mais de 100 línguas, e em formatos imediatamente consumíveis por software. Nada impede também de o número genérico da versão internacional ter nome/código diferente do nacional
Embora para arquivamento de longo prazo a melhor analogia seja a biblioteca mais antiga (não raro elas são muito mais antigas que a própria fundação da ISO e da ONU) para quem não conhece os CODs, uma analogia aqui seria a ISO, porém com uma distribuição de dados parecida com o que alguns projetos via Open Knowledge fazem.
Um fato curioso sobre a ISO (que a maioria das pessoas não sabe, mas poderia estranhar, pois ela mantém um copyright ferrenho): a ISO não cria os próprios padrões que a maioria aqui usa. A exceção é, talvez, aos do TC37 sobre lexicografia/organização de padrões como os da ISO. Praticamente todos os vocabulários relevantes dela (códigos para língua, códigos para locais, etc; obviamente não se aplica a padrões que são especificações técnicas não relacionadas a troca de dados) são re-empacotar e dar número para algo feito por organização externa e, então, dar um número único para o padrão.
Uma analogia ao que a OCHA é quando ela distribui data sets prontos para uso (link a seguir) é, mais ou menos o que alguns projetos da Open Knowledge falarem:
Como referência, as automações que a OCHA usa (isso não apenas CODs) para puxar dados de outros lugares, alterar o formato (normalmente para o HXL Standard), e então re-publubiar no CKAN é este aqui
A ideia de “pegar dos outros e re-empacotar” e deixar automações rodando por ano não é algo absurdo. Na verdade é uma forma de garantir padrão mesmo que fontes não sejam padrões!. Porém isso não é feito em escala (que é minha ideia aqui; voltada em fazer em produção) no caso de vocabulários usados para troca de dados (ou ao menos, não os que não sejam principalmente COD-ABs). Existe interesse de voluntários ao redor do mundo para ajudar com traduções de terminologia se tudo já tiver sido preparado para usos como os que são feitos no meio meio humanitário. Mas isso esbarra num problema: tanto projetos da Open Knowledge como a OCHA tem problemas de licenciamento, e isso fica óbvio em vocabulários. Por isso que até mesmo quando é necessário meramente compilar traduções terminológicas que já dão domínio público, fazer isso volta de chaves primárias que têm licença (ou “traduzir padrões ISO”) são algo que vale a pena ir direto para ideia de criar padrões abertos desde o zero; quando relevante ainda é possível relacionar com padrões existentes.
Ao menos no contexto humanitário, um fato observado é que ideias de criar um silo de dados único onde todos concordam é irrealista. Entre outros fatores:
Países podem ter outros motivos. No Brasil, por exemplo, a LGPD é usada para impedir que dados de pessoas para um fim sejam pedidos por outros departamentos sem autorização dessas pessoas. Meu argumento aqui é que silos de dados são uma realidade. Essa realidade não vai mudar.
Uma das propostas é justamente permitir sempre que dicionários sejam exportados em vários formatos é um meio de ajudar automação nos pontos em que os responsáveis teriam que tranportar dados de um lugar para o outro.
Nota: embora esteja usando resposta de emergência como exemplo, abordagens que funcionem até casos extremos tendem a ser mais fáceis de serem adotadas em situações onde há tempo.
Não só porque cada emergência pode envolver desafios novos para quem atua como gerente de informação para ajudar países novos, mas também pelo fato anterior (que silos de dados são uma realidade) a todo momento armazéns de dados tem que ser re-criados do zero.
Outro motivo forte para isso é que com frequência quem já tem silo de dados (que foram testados e deixados pronto para uso) tende a estar usando tabelas antigas, tipicamente desatualizada há anos, por isso não basta estar usando dados de referência, elea devem estar atualizados.
Temos que tem em consideração que toda organização que cria dados de referência sempre vai ter carinho pelo próprio trabalho, e assumir que toda cadeia de usuários realmente atualiza os dados na frequência adequada. Não obstante, para implementadores, existem tantos, mas tantos dados de referência, e cada um requer ler documentação e afins, criar scripts de conversão, etc, que nem mesmo uma organização que promove dados de referência em um tópico deve ter seus sistemas internos atualizados com dados de referências das demais!
Embora o contexto humanitário fique mais claro (pois é otimizado para recriar do zero, com frequência de dumps em CSV), esse problema já acontece no serviço público em geral e em provedores de software com aplicações para o respectivo país.
Isso aqui envolve mais empirismo meu do que referências que eu tenha lido, mas por mais que as ferramentas que tenho usado permitem criar subníveis de conceitos e códigos de forma super rápida e já distribuir com traduções enciclopédicas, não dividir o que pode ser prejudica reusabilidade.
Um exemplo claro é que geralmente cada de formulários HTML se tornam um novo grupo de dicionário
Exemplo não intuitivo. Um campo de formulário (como os da Cruz Vermelha) que tenha de identidade de genero e outro de sexo biologico, mesmo que a criação rápida de dicionários dedicados pareça ser mesma coisa (afinal, muitos lugares usam até mesmas legendas) mas quem poderia opinar sobre tais conceitos são até de áreas diferentes. Não estou dizendo que não dê para rascunhar dicionários, mas a validação deles pode demorar anos.
Mas temos outros casos mais óbvios, mas são super comuns em quase tudo. Campos como nomes e códigos de lugares (como municípios do Brasil) para usuário final ou desenvolvedor de software que copia de algum lugar pode não fazer diferença: está mais preocupado em não precisar editar manualmente.
Uma implicação direta do 1.4 é que a melhor forma de otimizar para manutenabilidade é ter muitos, muitos dicionários temáticos. A quantidade é tão alta, que já vale a pena nomear por números, e não burocratizar quando for realmente necessário criar.
Um problema documentado durante a produção do A New English Dictionary on Historical Principles; Founded Mainly on the Materials Collected by The Philological Society é que (por analogia) colaboradores para tarefas de lexicografia, se a gente não pedir explicitamente para priorizarem o que é mais comum, vão se focar em termos mais exoticos. Isso não só torna a tarefa de compilação mais demorada, mas frustra usuários do resultado final.
Embora cada grupo de dicionários pode eventualmente ter especialistas para decidir o que deve estar lá (e, evitar potencial viés contra minorias) pelo menos a decisão de quais grupos de dicionários deve-se ter (o que vem antes da existência de especialistas) preferencialmente deve estar alinhada com o que é necessário no mundo real para troca de dados, e não nossa opinião sobre o que deveria ser trocado.
Trivia: A lexicografia tradicional usa de algumas ferramentas para descobrir quais temas são mais importantes, e faz isso ao importar texto de muitas fontes e então permitir analisar a frequência em que palavras aparecem lá. Porém não sei dizer se a mesma inferência é aplicável ao nosso caso, que tem prioridade em saber quais campos de formulários são mais comuns.
Reparem o seguinte: de organizações que se envolveram com web semântica no mundo, as que são bibliotecas (em oposição que tinha experiência em tecnologias; inclusive projetos de pesquisadores) têm maior chance de estarem ainda no ar.
Mesmo que serviços de cada setor do Brasil tenha sua URL ativa, vejo que temos uma oportunidade perdida aqui. Ao que tudo indica isso (de usar bibliotecas) aconteceu no Brasil, mas o formato usado foi… imprimir livros! ! 
Sabemos que existem outras formas de compartilhar arquivos semânticos e que tais formatos vão evoluir com as décadas (se não RDF com SKOS, até mesmo CSVs, que são até mais leves que PDFs; espaço não é um problema; escaneamento de livros de séculos atrás podem chegar a mais de 1 GB). Porém acho que além dos PDFs de livros, se houver um esforço também de ter alternativas digitais (mesmo que não seja obrigatório, mas ao menos a forma como bibliotecas guardam arquivos), estamos protegendo o esforço dos colaboradores.
Relembrando do seguinte: glossários, dicionários, terminologia, possivelmente até mapas cartográficos… são relevantes não apenas para troca de dados, mas em uma interseção com o que se espera de bibliotecas. A ética de trabalho da profissão de bibliotecas entende a ideia de destruir algo porque deixou de ser relevante para a opinião atual o equivalente a queimar livros.
Não tenho opinião sobre se algo mais estruturado (como endpoints SPARQL, ou URLs fixas) deveriam ficar sob responsabilidade da biblioteca central. Na verdade, até a Wikidata é focada na última versão da informação (e já é comum bibliotecas do mundo usarem Wikidata para armazenar dados estruturados delas) então conforme os dicionários ficam mais preparados isso já permite serem integrados lá.
Contexto: alguns pequenos dicionários (por exemplo: imagine algo que poderia se tornar equivalente de uma ISO/IEC 5218, mas para identidade de gênero; para uso internacional; na verdade a gente até precisa de uma versão aberta de um ISO/IEC 5218, mas até isso poderia precisar de validação científica) poderiam ser bons o suficiente para continuarem serem reusados por séculos e é justamente isso que queremos: algo que tenham tendência, não só do ponto de vista tecnológico, mas de competição entre criação inicial e futuros mantenedores, de não valer a pena criar algo novo simplesmente para ser diferente.
Fato: com uma quantidade altíssima de pequenos dicionários uma das formas de garantir uma homologação/validação científica inicial é… independe de como estivermos usando em produção anos antes, eventualmente um ou mais especialistas da área acadêmica publicarem primeiro tema criticando/recomendando/validando versão inicial. Isso pode iniciar do Brasil, pode vir de outros lugares, mas na falta de uma comissão internacional, as coisas podem começar pequenas.
Problema: se a versão genérica, reusável a nível internacional, ficar com CC-BY dos acadêmicos iniciais, ou ficar muito claro que alguma região do mundo em especial é “dona” deles, isso vai gerar competição. Isso se torna ainda mais complicado se considerarmos que uma pequena parte desses dicionários, similar do que aconteceria com nomenclatura cientifica onde o primeiro “descobridor” da um nome, ficaria por séculos sem alterar.
Como NÃO acho interessante isso ser otimizado: a ISO resolve ao a própria organização “ser dona” de padrão, e permitir que com passar do tempo trocar quem dá manutenção. Porém sou da ideia de que códigos internacionais já deveriam de alguma forma ser domínio publico e a adoção ser voluntária. Outra forma que a ISO “evita” padrões secundários é direitos autorais agressivos, que é justamente o que não queremos, pois adoção deveria ser voluntária e meritocratica.
Situação que poderia ser otimizada: Assumindo que padrões iniciais (que forem apenas criados sem validação alguma, com numeração genérica, testados em produção, …) já poderiam ser domínio publico, na falta de comissão internacionais, a gente permita que acadêmicos tenham uma forma de validar (talvez até anexar a convenção de dados que eles validaram) e ajudar que eles sejam de alguma forma encontrados por outros, MAS… isso não poderia ser feito de forma que gerasse competição entre futuros acadêmicos ou desinteresse de manter o padrão.
Embora o PDF do post original (glossário de termos) seja uma exceção, a maioria do que de fato vai em um vocabulário (o que é relevante para uso em software), mesmo em um PDF de 100 páginas (que normalmente explica como ser usado, exemplos, etc), são umas tabelas de duas ou três páginas. Desde que a burocracia esteja resolvida (e licença é uma delas), mesmo se surgisse dezenas de equipes no Brasil com candidatos a vocabulário em áreas em que são especialistas, a tarefa de “copiar e colar” não conseguiria saturar quem faz isso.
No caso de algo totalmente governamental, 90% de protótipos de dicionários podem ter nenhum apoio financeiro (ou ser algo esquecido) que ainda assim é viável que sempre tenha gente nova capaz de atualizar/ajudar especialistas sem que eles se importam em como explicar os formatos de arquivos exportados. Na verdade, até mesmo os antigos, poderiam ser re-generados com correções de esquemas de dados.
Pelo menos os dicionários que de alguma forma sejam relevantes para uso humanitário (sentido: aliviar sofrimento humano) eu pessoalmente consigo me comprometer na questão até “do copia e cola”, e faço pro bonō publicō. Não obstante, a maioria desse tipo de referência já tem uma tendência forte a ter gente o tempo todo, outros brasileiros querendo ajudar de alguma forma, então eventualmente seria viável redundância nisso. O argumento aqui é que o que for de relevância pública e estivesse minimamente pronto para ser convertido, não seria por falta de ajuda.
Outro ponto é que causas humanitárias, resposta a desastres naturais, etc, naturalmente tem uma tendência fortíssima a ter ajuda até que quem tipicamente estaria em situação de oposição (partido político VS partido político; força policial vs crime organizado; etc).
Mesmo software e estratégias usadas para enriquecer usadas com ajuda de voluntários em geral, pode ser aplicada a questão do governo, desde que as tarefas cruciais, mais especializadas (tipicamente as centralizadoras que são caras demais para iniciar, mas depois podem escalonar), por padrão sejam genéricas, o que implicaria a infraestrutura ou o profissional (mesmo que pago por um departamento) estar aberto a processar dados de outros.
Digo isso porque, mesmo resolvida alguma solução neutra para armazenar dados , como o comentário em 2.1., sempre haverão tarefas que já não sejam meramente usar software, como as de copista e o impacto na sociedade pode não ser suficiente para gerar interesse de pessoas voluntárias.
Resolvido 2.2 (que naturalmente implica em centralização), ficaria em aberto quais formatos de arquivos exportar cada dicionário. Essa decisão de formatos pode ser mais alinhada com demanda de usuários (que podem ter usos de caso como 1.2 e 1.3) e, se for feita com um tipo de dicionário, os demais do mesmo tipo também são re-exportados com novo formato.
Algumas coisas são conversões triviais; por exemplo, para algo já em RDF/XML, também oferecer em Turtle. Não obstante, o ideal é padronizar de tal forma que (aqui um exemplo) se usuários quiserem ajuda para importar em base de dados SQL, haja uma forma de fazer isso (mesmo que seja exportar script pequeno que tem instruções de como carregar dados de um CSV na tabela com nome correto).
Notem que com o passar dos anos, os formatos exportados vão evoluir; até mesmo os RDF da W3C eventualmente também poderão ser exportados em JSON-LD (então é natural ter que re-exportar mesmo aqueles que estão em esquema não obsoleto). Exceto talvez por algo já arquivado a longuíssimo prazo faz sentido que arquivos de trabalho acompanhem padrões de arquivos que forem convenientes para uso imediato. A todo momento deve ser possível subir um armazém de dados.
Esse ponto creio que vale discussão separada. Inclusive consigo provas de conceito funcionais
Uma das formas de serialização é a chamada web semântica. Não obstante, as URLs vão perder sentido com o passar do tempo. Quando relevante, a garantia de identificação única poderia ser mais parecida com DOI ou ISBN (aka uma organização seleciona o que é relevante) e não URLs. Outro desafio é que com frequência termos usado para descrever conceitos eventualmente percebe-se que foi uma má escolha para representar aquele conceito, então surge o risco de o que fazer com o termo usado como chave primária.
A discussão seria longa, mas tanto para facilitar o trabalho de lexicografia (os copistas humanos) como permitir reuso de mesmo padrões ao longo dos anos, até mesmo padrões que especialistas já não usarem números opacos, vale a pena a chave primária ser numérica. Porém as fundações da web semântica, com RDF, são documentadas usando URIs e URIs englobam pelo menos URLs e URNs.
Esse é um outro ponto que eu faria discussão separada.
Essa é a parte que estou menos certo do melhor processo. Porém os rascunhos de dicionários que tenho feito dão a entender que mesmo que 2.1 armazenamento de longo prazo e 2.2 copistas já estejam funcionando, se o objetivo for algo a nível de Brasil (ou então padrão internacional) o fluxo completo poderia envolver algum nível de formalização. Um caso mais extremos (e lento demais) seria como a ISO faz:
A IETF também tem um processo (embora ele seja ainda menos genérico que a ISO):
https://www.ietf.org/standards/process/
Padrões que forem principalmente um empacotamento de algo que já é endossado por uma organização no Brasil, mesmo após o empacotamento, faz sentido se eles tem interesse de cooperar de alguma forma (ou mesmo re-distribuir também as versões adicionais).
Não obstante, notem que a versão produzida pode já ter links com outros padrões nacionais e internacionais (talvez até mesmo traduções da Wikipédia). Então não raro as fontes primárias vão estar cientes, vão até usar para resolver inconsistências, mas pelo menos o nome de como chamar o recurso genérico poderia evitar confusão. Em caso extremo, tal abordagem também mitiga situações (as que forem distintas o suficiente) onde algum provedor de algum país pode querer restringir a distribuição.
Em especial para padrões que não são genéricos o suficiente para ser internacionalização (código de lugares são exemplo óbvio), se a chave primária já é numérica e existe uma política clara de consistência (exemplo: fins estatísticos), sou da opinião de o dicionário tenha como chave primária aquela referência e daí tenha como uma propriedade interlinguistica o tal código repetido. Essa propriedade interlinguisrica passa a ser documentada em outro dicionário do que ela representa.
Um local que usa conceito de propriedades é a Wikidata
https://www.wikidata.org/wiki/Wikidata:Database_reports/List_of_properties/all
E um exemplo de propriedade que já existe lá são os códigos do IBGE
Cuja discussão de como foi aprovado está em
https://www.wikidata.org/wiki/Wikidata:Property_proposal/Archive/27#P1585
Esse é um exemplo perfeito (nem é preciso ir na Wikidata propor novo atributo). Mas a maioria das chaves primeiras do Brasil a tendência é usarmos algo que informalmente seria uma dessas propriedades.
Essa ação é implicação direta do 1.4 e 1.5 e especialmente relevante em dicionários que nem mesmo tem alguma ISO. As áreas que mais têm carência de padrões são as que seriam prejudicadas se burocratizarmos.
O motivo para não deixar uma área ditar regras de o que mereceria ou não estar em outra está no 1.5.1: é necessário compilar pelo menos o que é comumente trocado, mesmo que fique claro erros, mas tão logo começa a ter interesse de especialistas na área, o ideal é refletir o consenso no limite do que computação permite.
Boa parte das discussões sobre padrões internacionais para trocas de dados hoje em dia requerem saber inglês e eu pessoalmente acho isso uma oportunidade perdida.
Meu último ponto é sobre implicitamente já haver preocupação para permitir que os dicionários ajudem outras regiões sem que isso requeira que especialistas locais precisem saber outras línguas, mas ao mesmo tempo sem tirar autonomia deles de ter padrão local diferente (não mera questão de tradução, mas conceito é diferente). Um desafio é que, diferente do que pode acontecer com quem trabalha com tecnologia com inglês, na maioria das vezes, especialistas de cada área técnica de cada país dificilmente teriam alguma língua em comum. Não obstante, para conteúdo que vai nos dicionários, a cooperação constante de tradução permite um acesso justo em relação a outras alternativas. Essa abordagem pode permitir autonomia local visto que por padrão toda tecnologia para converter os dicionários não obriga escolha de uma “língua de trabalho”.
Algumas coisas são extremamente locais, mas ainda assim o formato de arquivo e a forma de catalogar poderia permitir interoperabilidade internacional. Um caso são regiões administrativas onde tanto UN P-Codes e ISO 3166-2 dividem por níveis. Nesse caso, sempre que possível deveríamos permitir que software para resposta de emergência que funcione com geografia do Brasil seja portável para outros países que poderia haver interesse de ajuda humanitária.
Outras, por estarem em alguma área ligada à ciência, tendem a ter uma tendência a ter conceitos em comum, mas países podem ter algumas especializações. Uma das vantagens de quebrar em dicionários menores é que aumenta a reusabilidade e apenas onde houver conflitos, a nível regional, partes menores são sobrescritas. Esse é um dos casos onde sempre que possível, uma proposta de padrão internacional poderia já tolerar numerações explícitas que não seriam usadas.
(continua no proximo post, excedeu limite de 30000)
(continuação)
Como diria o Torvalds
“Talk is cheap. Show me the code.” ― Linus Torvalds
Tanto a parte de fazer boostrap dos dicionários como de criar diversas versões, é mais fácil testar/validar na pratica e ter mais alguns feedbacks. Já tenho links disso, mas melhor quebrar em mais tópicos. Mas em geral, tudo que vou comentar aqui no Dados Abertos é porque já estou abrindo caminho com lições apreendidas com como as coisas funcionam lá fora.
Todo ponto foram minhas ideias que tenderiam a afetar protótipos funcionais saírem da informalidade e se tornarem algo tão útil que pelo menos uma parte dos gerentes de informação atuais voluntariamente ajudariam. Não obstante, automação é tão pesada que muita coisa pode ser feita com poucos copistas.
Nota: no 3.3 Do ideia de dados interligados (não apenas RDF e web semântica) é que resumo o que já é possível fazer com ferramentas atuais. O 3.1 e 3.2 são contexto que diferencia.
#hashtags e +atributos do padrão HXLEste é o link principal que estou falando:
E esse é um auxílio para escolher que tags usar
https://hxlstandard.github.io/hxl-hashtag-chooser
A forma como padrão HXL é projetada permite que ele seja usado até mesmo como um ETL avançado (tem as funcionalidades mais comuns que você usaria) e, até o limite de umas 500.000 linhas (que pode estourar o timeout de 60 segundos do proxy público), pode-se fazer tudo usando planilhas como Google Sheets. Óbvio que por ser membro do grupo de usuários do HXL-CPLP, sou suspeito de falar isso, mas a ferramenta foi projetada para ajudar a fazer gambiarra em tempo real para gerar relatórios, gráficos ou datasets que dependem de outro cuja URL de destino é o HXL-Proxy com instruções de como processar as fontes. Mas isso já é uso final. Não vou falar aqui.
Não obstante, o dicionário público do HXL tem uma limitação, até mesmo para uso humanitário: ele sugere convenções de #hashtags e +atributos mais focadas em datasets que tipicamente já são públicos (como já publicados no The Humanitarian Data Exchange), e documenta melhor dados agregados. Sim, o padrão permite qualquer pessoa criar atributos novos, mas para criar ferramentas que tem compreensão avançada (já que usuário tem expectativa de detecção automática) requer saber de antemão quais atributos poderiam aparecer.
Os pontos do 3.1 exemplificam um caso mais extremo (que pode dar ideia do tipo de otimização de como padrão HXL é usado). Um cenário como o Brasil tende a não precisar de todas as funcionalidades, mas pode dar ideia de como conseguem re-distribuir tantos dados com tão pouca gente sem ficarem sobrecarregados. Não obstante, eles fazem isso com datasets finais (muito mais dados do que vocabulários) então se não fosse pelo fato de eu já estar pro ponto criar vocabulários novos, os dados de referência do Brasil dificilmente seriam difíceis de alguém resolver toda vez que alguma URL ou campo muda.
Algumas diferenças e ou peculiaridades em relação a como HXL (e troca de dados humanitária é feita), logo seria inovação de nós brasileiros:
Possivelmente tem outros pontos que estou esquecendo, mas explicitamente tem algo que acho que não vale a pena prometer (pois isso dá muita agilidade em para quem prepara dados, que é o caso de usuários de vocabulários mais tarde): não tem como prometer que não haveria mudança de schemas de dados (em especial com passar dos anos); um exemplo é alguém consumir um formato de arquivo que teria algum erro de sintaxe, mas o erro é reportado e corrigido e na próxima regeneração todos os dicionários são afetados; se isso quebrar alguém que importa, então corrija sua funcionalidade que importa os dados.
Nos meus testes atuais, creio que todo dicionário que for documentado o que seus dados significam a forma em que são exportados permite que eles estejam interligados!
A implicação prática é que implementadores poderiam importar apenas o que precisam, mas se quiserem importar TUDO, seja num SPARQL ou um armazém de dados usando bancos SQL tradicionais, é super viável!
Para permitir que isso funcione com mínima intervenção humana, torna-se essencial que a forma de nomear os dicionários (não apenas o que tem neles) precisa ser gatantida de não haver conflito (isto é: nunca dois dicionários com mesmo código completo precisam ser carregados juntos).
A maioria dos dicionários que estou testando são pequenos para editar na mão (mas com traduções, as menos de 10 colunas podem expandir com automação via Wikidata para mais de 250 colunas). Esse é um uso de caso.
Não obstante, vários dicionários de interesse são tabelas enormes, como códigos do IBGE para locais, códigos de unidades de saúde, dados de CNPJ, …
Esses demais casos, creio que tenho que fazer alguns ajustes. Mas em geral eles envolveriam converter a tabela original no formato intermediário (o que já é usado hoje é feito a mão para tabelas menores) e daí todos os demais arquivos são gerados. Vale lembrar que tudo que for citado nesses dicionários referenciados outros precisa também ser explicado pelo menos uma vez com código único global.
Nota: esse é um ponto que não tenho prova de conceito. Quando eventualmente começar ter dicionários, provavelmente valeria a pena começar com explicar conceito de CNPJ com dados de exemplo, mas já sabendo que outros podem importar conjuntos mais completos.
Entendo que isso vai gerar receio em um contexto que falamos de dados abertos, mas a semântica de coisas que são óbvios dados pessoais, como conceito de CPF, número de título de eleitor, cartão do SUS, etc precisa ser documentada. No mínimo implicaria em ter número reservado para guardar cada tipo de chave primária tanto em disco como se fosse importado em RDF.
Além da lógica de isso eventualmente seria um pedido comum em quem tem acesso autorizado aos dados (ou seja, estaria apenas usando a lógica para fazer inferências nos dados que já possuí), ao documentar pelo menos os prefixos seriam ponto de entrada para esses dados de referência, tem-se a oportunidade de explicar tanto a nível de linguagem de máquina como de documentação aos usuários implicações de segurança e de da lei.
Um uso comum do padrão HXL envolvia até formas de anonimizar dados. Embora existam outros termos que teriam tendência a ser candidatos a dados pessoais (imagine “nome_pessoa”, “nomeCompleto”, “Nome”,…) esses tipos de campo tendem a ter dicas fortes do que são quando aparecem em formulários aqui no Brasil ( exemplo: “CPF”, “pessoa_cpf”, “cpf-socio”…) o que pode permitir aplicações relevantes mesmo quando um esquema de dados não está explicitamente documentado
Como cada conceito precisa de pelo menos um meio único a nível de mundo de acessá-lo (mesmo que apontem para a mesma coisa) isso permite uma série de funcionalidades super bacanas sem necessidade de acessar servidor remoto.
Na verdade, como números são mais opacos (33 em algo como NNNN:NN:NN:33 em vez de MG em algo como uf) a probabilidade de erro humano definitivamente implicaria ter esse tipo de ajuda de contexto quando aquele humano já está autorizado a acessar o recurso. As implementações que tenho feito já procuram permitir que cada dicionário possa ser representado como arquivos disco, mas em geral quase tudo é generalizável, o que permite reuso de ferramentas e agrupamentos (que podem ser dicionários ou referências a dados reais que os usam) privados. Na verdade, toda abordagem de sempre poder ter dicionários em disco local é otimizado para contextos onde requer nível alto de segurança.
Vale lembrar que as mesmas implicações de privacidade que se aplicam ao código sem caminho completo, também se aplicam com ele completo. Um exemplo é que mesmo que usuário esteja autorizado a ver o próprio CPF, e mesmo que o acesso seja via web, via HTTPS, se ele poderia estar fazendo acesso de uma rede não confiável (como uma lan house), não é recomendável que o dado sensível faça parte de parâmetros GET (se necessário, melhor por POST).
PS: sobre seu comentário sobre falta de investimento, interoperabilidade e afins, os argumentos aqui não implicam em que isso não seja relevante. Inclusive o Brasil tem uma preocupação enorme com a participação da sociedade civil (e isso é algo que eu exploro no meu argumento, mesmo que tenha falado mais da área acadêmica). Em geral para o tipo de dicionário que precisaria ser criado para interligar coisas (e já digo isso pensando em rascunhar no Brasil o que pode ser usado na área humanitária internacional, inclusive violações de lei humanitária internacional), mais de 90% deles nunca haveria interesse de patrocínio e envolvem dados que são super sensíveis, como prontuários médicos e investigações policiais onde quem investiga está sobrecarregado e possivelmente não entende a língua.