Metadados legislativos e sem√Ęntica

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).

2 curtidas

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.

Status quo de padr√Ķes para trocar esse tipo de informa√ß√£o (gloss√°rios)

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.

Das falta de ferramentas para quem cria tal conte√ļdo

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:

Como Legislativo ter criado o gloss√°rio compartilhado pelo autor

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).


Problema em aberto

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.

1 curtida

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.

1. De como contribuidores chegam a conclus√Ķes

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.

1.1. Exemplos pr√°ticos

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).

1.1.1. SKOS

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.

1.1.2. Do Glossário de Termos Legislativos (e provavelmente centenas de outros glossários e afins que seriam necessários também no Brasil)

Tomemos como base o Deputado Federal

https://www.congressonacional.leg.br/legislacao-e-publicacoes/glossario-legislativo/-/legislativo/termo/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.

1.2. Referências no assunto

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).

2. Alguns exemplos de √°reas que teriam gloss√°rios (e que s√£o relevantes para troca de dados)

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):

  • Geografia | Ir at√© o IBGE e perguntar:
    • quais vocabul√°rios voc√™s tem, e gostariam de garantir consist√™ncia? Voc√™s j√° t√™m sistemas de c√≥digos e etiquetas, talvez defini√ß√Ķes?
  • Medicina | Ir at√© o Minist√©rio da Sa√ļde e perguntar (talvez sindicatos m√©dicos):
    • voc√™s j√° tem alguma terminologia? Algum sistema de c√≥digos? Padr√Ķes de termos para usar em trocas de dados?
  • Policia (tempo de paz) | descobrir entidades interessadas, ent√£o perguntar:
    • h√° uma car√™ncia de padr√Ķes de dados entre seus pr√≥prios setores? Se sim, o que seria mais urgente?
      • Nota: as vezes a mera anota√ß√£o de diversas entidades de um setor de o que mereceria um vocabul√°rio controlado √© perfeito; isso √© super relevante em √°reas menos integradas.
  • Defesa civil | descobrir quantas organiza√ß√Ķes de refer√™ncia atual atuam em resposta a emerg√™ncia, e perguntar:
    • algum de voc√™s j√° t√™m vocabul√°rios em comum? Se n√£o tem, h√° interesse em rascunhar algo? O que precisam de ajuda para publicar os resultados, visto que h√° interesse de usu√°rios que ajudemos voc√™s nisso?
  • Educa√ß√£o | Seja o MEC, ou outras do setor:
    • voc√™s j√° tem gloss√°rios ou outros sistemas de c√≥digos? Como voc√™s distribuem eles? H√° interesse em ter ajuda em ajudar consumidores a terem tais dados sempre atualizados?

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.

3. Sobre contexto de glossários / terminologia / vocabulários / códigos-de-máquina no Brasil

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

Interoperabilidade na Uni√£o Europeia

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.

Padr√Ķes de interoperabilidade no Brasil

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.

Do processo de constru√ß√£o de padr√Ķes

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:

  1. A plataforma Colab do Interlegis, que integra listas de e-mails e reposit√≥rios de controle de vers√£o para solu√ß√Ķes em software livre para as casas legislativas locais. Infelizmente, mais recentemente anda meio abandonada e sofre com excesso de spam que n√£o tem sido moderado.
  2. O Portal do Software P√ļblico, reformulado em 2015 tendo o Colab Interlegis como inspira√ß√£o, que tamb√©m foi abandonado a partir de 2017.
  3. O processo de participa√ß√£o social da INDA, aberto √† participa√ß√£o de qualquer pessoa interessada, que contou com reuni√Ķes presenciais e virtuais, planejamento coletivo, issue tracking, controle de vers√£o de c√≥digo, etc., para construir o Portal Brasileiro de Dados Abertos, entre os anos de 2011 e 2012.
  4. A e-PING, que no passado era desenvolvida em 5 grupos tem√°ticos, com participa√ß√£o volunt√°ria de servidores p√ļblicos, em reuni√Ķes presenciais na sua maior parte, mas tamb√©m com trocas de e-mails. Tamb√©m parou de se reunir por meados de 2015. Considerando o VCGE como parte do grupo e-PING, percebo uma falta de participa√ß√£o por desinteresse das pessoas depois da reformula√ß√£o ‚Äú2.0‚ÄĚ de 2013, que por diversos motivos, tornou esse vocabul√°rio muito pobre e pouco √ļtil para classifica√ß√£o.
  5. A plataforma de colabora√ß√£o JoinUp da Comiss√£o Europeia, que recebeu investimento do programa ISA¬≤ de interoperabilidade. Conta com diversas ferramentas de gest√£o de comunidade. Alguns dos grupos fazem reuni√Ķes periodicamente para discutir a evolu√ß√£o dos padr√Ķes at√© hoje. Entre essas comunidades est√° a Semantic Interoperability Community - SEMIC, que inclusive tem usado o Git e o Github para manter os padr√Ķes de interoperabilidade sem√Ęntica em constante evolu√ß√£o.

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.

1 curtida

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)

1. Informa√ß√Ķes de contexto

1.1. Compara√ß√£o entre refer√™ncias endossadas pela OCHA, padr√Ķes da ISO e os datasets (de projetos relacionados) da Open Knowledge

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.

1.2 Silos de dados são uma realidade; impraticável um armazém de dados global (contexto humanitário)

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:

  • Gerentes de informa√ß√£o podem ter opini√Ķes t√©cnicas sobre melhor ferramenta para organizar seus dados
  • Gerentes de informa√ß√£o podem ter que dar suporte a sistemas legados
  • Gerentes de informa√ß√£o podem ser respons√°veis por tanto conte√ļdo que n√£o saberiam por onde come√ßar
  • A cultura do departamento pode intencionalmente n√£o querer que seus dados sejam compat√≠veis sem convers√£o com outros padr√Ķes

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.

1.3 Da necessidade de dados de referência estarem a todo momento prontos para resposta de emergência (contexto humanitário)

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.

1.4 Dicion√°rios focados s√£o mais f√°ceis de manter (analogia: dicion√°rio maior pode importar outros)

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

1.4.1 E, se for seguir a risca como homologar cada dicionário implícito de formulários, são áreas completamente diferentes

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.

1.5 Quantidade alta de dicion√°rios tem√°ticos

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.

1.5.1 Da expectativa de usu√°rios de encontrar ‚Äútodas as palavras no dicion√°rio‚ÄĚ

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.

2. De (algumas) ideias acion√°veis

2.1. Do arquivamento de longuíssimo prazo

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.

2.1.1 Do arquivamento de curto prazo (sem opini√£o)

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√°.

2.1.2 De algum arquivamento que permite pessoal acadêmico usar para ser citado (sem opinião); mas tomando cuidado para evitar competição futura

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.

2.2 Da ideia de ter volunt√°rios (e setores compartilhados) atuarem como copista como meio de otimizar para exportar v√°rios formatos

  • Contexto
    • Exceto por quem provavelmente j√° trabalha com ontologias ou RDF, o padr√£o √© assumir que todo mundo que de fato organiza o que queremos n√£o saberia como empacotar algo que justamente pode ser usado para documentar outros dados.
    • Outra situa√ß√£o rara s√£o casos onde alguma automa√ß√£o √© poss√≠vel. Geralmente isso s√≥ vai ocorrer quando a quantidade de conceitos √© alta, o que fica mais claro em tabelas de c√≥digo (exemplo: tabelas j√° publicadas de c√≥digos do IBGE, provavelmente de outros departamentos como IDs de unidades de sa√ļde).
  • Implica√ß√£o
    • Meu argumento principal √© que a maioria dos conjuntos de vocabul√°rios s√£o pequenos e (por limita√ß√£o de quem os decide) alterado com pouca frequ√™ncia.

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.

2.2.1 De volunt√°rios (pro bonŇć publico)

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).

2.2.2 De compartilhamento dentro do governo de tarefas em comum sobre lexicografia (n√£o pro bonŇć publico, mas talvez padr√£o de coopera√ß√£o)

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.

2.3 De Idea de vocabularios (inclusive os sem atualização) serem exportados em diversos formatos de arquivos independente da fonte original em toda versão nova da biblioteca inteira

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

2.4 Compatibilidade com dados interligados e web sem√Ęntica pode exigir uso de URNs para lidar bem com arquivamento de longo prazo

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.

2.5 Do ponto de vista de aprovação, analogia com fluxo de trabalho da IETF e ISO (porém não burocratizar até ser necessário)

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/

2.5.1 Cooperar com provedores de fontes prim√°rias (quando eles quiserem cooperar)

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.

2.5.2 Da ideia de não procurar validação nos primeiros anos (ou CADA setor define própria burocracia)

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.

2.6 Da ideia de servir de interliga√ß√£o entre especialistas de diferentes regi√Ķes

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)

3. De protótipos funcionais (apenas parte de arquivos dos dicionários)

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.

3.1 Meta comentários de fluxo de trabalho otimizados até para resposta humanitária em geral

  1. Tipicamente usa automação pesada
    1. A primeira vez que um conector/crawler √© criado, √© necess√°rio ler documenta√ß√£o; normalmente ela vai conter mais op√ß√Ķes (exemplo: certas regi√Ķes podem ter mais detalhes que outras) do que o resultado criado
    2. Quando fonte muda API ou campos nos arquivos (fato descoberto quando algo quebra), o conector é atualizado; isso leva menos tempo do que criar algo novo
    3. Com o tempo os conectores ficam bem parecidos e fica f√°cil criar conector novo
    4. Provedores de dados podem pedir para remover/obter novamente algo cacheado (caso comum: dados privados)
  2. Colaboração de provedores abaixo da linha de comando é totalmente opcional; Uso agressivo de redistribuição (que também funciona como cache intermediário) em formato padronizado dentro das possibilidades do que o contexto permitir
    1. O principal uso de caso é resposta de emergência onde governo abaixo está sobrecarregado ou mesmo colapsou.
    2. Mesmo que governo local tenha API ou link para dados de referência tudo que for considerado missão crítica têm crawlers que fazem cópia em formato padronizado no repositório central
  3. O padrão de troca envolve sempre dados tabulares e dump completo pois são mais fáceis de lidar em situação de urgência
    1. At√© mesmo padr√Ķes que t√™m APIs XML como IATI Standard que √© requerido por doadores no meio humanit√°rio seriam re-exportados em formato tabular
    2. Casos especiais podem envolver formato binário (exemplo: shapefiles usados em COD-ABs, mas isso é processo manual; pensem eles acessando site do IBGE de uns 100 países)
    3. Nem todos usam HXL Standard; mas como HXL-Proxy permite um ETL simplificado usando vários datasets para criar um novo, tipicamente o que é mais reusável tem mais cuidado
  4. Mesmo conte√ļdo publicado de forma padronizada pode sofrer mudan√ßas de esquema de dados sem aviso pr√©vio
    1. Embora a ideia de ter datasets de v√°rias regi√Ķes abaixo (mesmo que com n√≠vel de detalhamento as vezes menor) sem precisar acessar um por um, e isso √© fant√°stico para solu√ß√Ķes usando dados, √© garantido que o esquema pode levemente mudar (talvez uma vez por ano)
    2. Note que s√£o pouqu√≠ssimos profissionais tratando e republicando dados de todo o mundo (v√°rios pa√≠ses, v√°rias l√≠nguas, v√°rios setores de conhecimento); o HXL Standard tolera ate melhor altera√ß√Ķes do que quem processa como CSV com valores hardcoded justamente para facilitar isso.
    3. Tipicamente formatos mais estruturados (pense uma API, ou republicar em outros padr√Ķes de dados) que se baseiam nessas planilhas tem cache anterior e toda vez que algo quebra altera para aceitar tanto padr√£o antigo e padr√£o novo.

3.1.1 Limita√ß√Ķes do dicion√°rio de #hashtags e +atributos do padr√£o HXL

Este é 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.

3.2 Meta comentários de sobre os protótipos funcionais

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:

  1. Primeira coisa que estar√≠amos fazendo s√£o dados de refer√™ncia (os que s√£o usados para explicar outros dados), que aqui vou abreviar ‚Äúdicion√°rios‚ÄĚ; o in√≠cio pode n√£o ser ‚Äúformal‚ÄĚ mas a metodologia √© ordenada/planejada
    1. Exceto talvez pelos CODs, mesmo os vocabulários endossados pela OCHA não são tão ostensivamente (aka puxar orelha do coleguinha) se deixarem de serem usados; creio que no nosso caso sempre que tiver uma opção melhor (exemplo: código do IBGE vs CEP) a gente além de inteligar ela a tudo, poderia ativamente defender a referência como a ideal
  2. Automação padrão até de documentação de dos dicionários (de o que há nele, como usar o tipo de arquivo, etc); não há limite de quantos idiomas poderia ser gerada tal documentação (mas o que é gerado gerado em cada pacotinho vai do interesse)
    1. Documentação de como usar conjuntos de dados no meio humanitário é limitada; no nosso caso pelo menos automatizada sempre teria
  3. Todos os dicionários seriam exportados em todos os formatos de arquivos viáveis; vamos facilitar a vida de quem quer usar e de quem quer sincronizar cópias
    1. Tanto dentro como fora do meio humanitário, exceto por quem já usa RDF, quem fornece vocabularios costuma publicar apenas em um formato oficial; no nosso caso automação permite sempre fazer em vários

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.

3.3 Do ideia de dados interligados (n√£o apenas RDF e web sem√Ęntica)

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).

3.3.1 Dicion√°rios p√ļblicos grandes com muito conceitos (por√©m tabela fonte padronizada)

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.

3.3.2 Dicion√°rios com dados sens√≠veis que tipicamente aparecem em formul√°rios precisam ter a sem√Ęntica explicada (sem obviamente compartilhar publicamente)

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

3.3.3 Usos fora de RDF ou armazéns de dado SQL: até auto-completar de seu software favorito, de linha de comando, etc

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.