# Ata - 14ª Reunião das pessoas mantenedoras *Quinta-feira, 26 de maio de 2022* [TOC] ## Presentes - Giulio Carvalho - Ariane Alves - Juliana Trevine - Pedro Guimarães - Renne Rocha - Lucas Guima - Luana Freitas - Bernardo Baron - Vittorio ## Recados - Decisão da novas 6 cidades: - Vila Velha (ES) - Sobral (CE) - Guarulhos (SP) - Nova Iguaçu (RJ) - Londrina (PR) - Uberaba (MG) - Novidades do QD deste mês - Informes: - Base da Receita Federal integrada à API por meio de busca por CNPJs. Ainda finalizando a carga, então não oficializamos a ferramenta. Iremos divulgar em breve quando os dados estiverem no padrão e completos - Endpoints de busca por tema também integrada à API. O tema escolhido, por enquanto, é apenas de temática ambiental. Também vamos divulgar em breve após validações por usuários do Diário do Clima forem feitas. Assim, os temas ainda serão melhorados - Foram feitas mudanças em alguns campos de entrada e resposta na API (o front já foi atualizado) - Busca com mais de um município ao mesmo tempo foi adicionada na API - Muitas mudanças foram feitas no repositório de processamento de dados e na API para que o estúdio de software que está desenvolvendo o site do Diário do Clima (Jurema) possa utilizar a API como apoio de desenvolvimento. Então, o caminho escolhido foi de disponibilizar o quanto antes estas funcionalidades e construir os testes depois. Os testes da API são prioritários pois o projeto estava com 100% de coverage - Convite à comunidade para submeter atividades para a (Python Nordeste)[https://2022.pythonnordeste.org/] e a (Python Brasil)[https://python.org.br/] - Renne: - PyCon US foi muito boa. O pessoal se interessou pelo tópico, principalmente outros países da América Latina que também tem problemas com Diários Oficiais. Parte das soluções trazidas pelo QD podem ser utilizadas em outros contextos, como a melhoria da busca semantica - Juliana: - Informe que lançaremos em breve um chamado de parcerias com universidades para apoiar o estudo e uso de Ciência de Dados no QD ## Mobilizações da Comunidade - Luana: se voluntariou para colaborar com o teste da API - Lucas: se voluntariou para acompanhar o desenvolvimento do frontend - Renne: - contato de aluna da UTFPR de uma matéria de Software Livre que escolheu o QD como projeto para trabalhar na disciplina. Para acompanharmos ela. - contato de um voluntário querendo contribuir com raspadores. Giulio também foi contatado pela mesma pessoa e já encaminhou ## Pauta: Como aproveitar cidades que não publicam o diário inteiro (páginas, atos, etc). - Contexto: Hoje o projeto tem como unidade a publicação impressa de um diário. Porém, algumas cidades como São Paulo ou cidades de Santa Catarina podem publicar em unidades diferentes como "seções", "páginas" ou até "atos individuais". Como podemos integrar essas cidades no projeto? - Nível de segmentação muito bom seria ato-por-ato, o que é raro - Possíveis obstáculos: - Como consumir esses diários e encaixar eles no formato do banco que adotamos atualmente. E também se preocupar em como esse dado será consumido na ponta através da API e do Frontend - Renne: - O problema principal é o armazenamento dos metadados, não necessariamente dos dados - Hoje, focamos em raspar os diários inteiros. Sugere desenhar classes de documentos (documentos completos, seções, decretos, etc) e definir modelos de raspagem e busca específicos para cada uma dessas classes. - Integrar com o banco de dados parece ser o menor dos problemas, é só adaptar o banco - Utilizar a categoria "outros" quando não soubermos qual categoria atribuir - Bernardo: - Repara que o banco é relacional e a referência é o número da edição. - Sugestões de classificação: - modelagem de dados por entidades (edição com cadernos, seção de decretos, atos) - aponta que o modelo relacional talvez não seja o que mais ajude nesse problema, mas que também não sabe quão complexo vai ser lidar com esse problema - sugere que a referencia deveria ser a menor unidade de um diário, no caso um ato, e atacar usando NLP - Giulio: - Comenta da experiência que tivemos com a pesquisa de segmentação de diários com o André Assumpção (Cientista de Dados) - Segmentação segue sendo um obstáculo muito central. A dúvida é qual será que é o melhor momento para atacar o problema? - É um problema muito difícil e que não se tem uma solução pra isso - Será que segmentações intermediárias já resolveriam temporariamente? Ou outras questões que poderiamos lidar antes que ofereça condições para seguirmos em frente e avançando, mesmo que ainda não da forma mais perfeita - Bernardo: - Talvez a segmentação por página seja um meio-do-caminho pois é uma unidade menor que a edição completa mas ainda não tão granular quanto o ato - Renne: - Página não me parece ser muito informativo, um ato pode ter várias páginas ou ser somente um trecho de página então talvez não funcione muito bem - Sugere começar com umas 3 cidades com padrões distintos e usar como referência. Utilizar elas para identificar um padrão e pensar numa modelagem interessante a partir deles - Lista de Diários sugeridos: - Goiânia: https://diariooficial.abc.go.gov.br/portal/visualizacoes/html/5129/#e:5129 - São Paulo: https://apilib.prefeitura.sp.gov.br/store/apis/info?name=Diario_Oficial&version=v1&provider=admin#tab1 - Santa Catarina: https://diariomunicipal.sc.gov.br/?r=site/index&q=cod_entidade%3A4 - detalhe do DO: https://diariomunicipal.sc.gov.br/?r=site/page&view=entidades - Giulio: - Problema da taxonomia e as complicações que isso teria pra comunidade e pras pessoas que contribuem com raspadores. Talvez seja pesado jogar pras quem estiver fazendo a raspagem a tarefa de identificar quais tipos de metadados ou unidade de publicação estão raspando e categorizá-los - Sugere irmos para uma via de dados mais semi-estruturados e sermos mais permissivos com a estrutura de dados que recebemos no banco pós-raspagem. Depois da posse dos dados raspados poderíamos fazer o tratamento e adequação desses dados para o padrão que desejarmos - Permitiria raspagem de vários formatos, metadados e tipos de unidade de publicação - Evolução da Taxonomia com o tempo e reprocessamento de toda a base conforme isso evolui, mas sem raspar tudo de novo - Pedro: - Aponta que pode ser uma etapa intermediária, que podemos definir a unidade de publicação utilizada no QD e também qual a taxonomia de atos utilizada e também definir a melhor maneira de implementar isso - Resposta ao comentário do Bernardo sobre o banco ser relacional: não é exatamente uma base relacional, é um armazenamento no elasticsearch - Sugere extrair macroentidades comuns aos diários e ir balanceando com 'outros' e futuramente aprimorar a classificação de outros - Bernardo: - Comenta que realmente pode ser complexo colocar na raspagem o peso de detalhamento dos dados a serm raspados e a colaboração poderia ficar prejudicada - Entende que o problema central é dos metadados que são necessários para fazer a classificação ###### tags: `Maintainers`, `May`, `2022`