O texto original, o tal "TXT com retrancas" é horrível para mostrar para o grande público e impalatável para qualquer sistema de análise computacional... Assim existem dois objetivos maiores na transcrição do TXT-retrancado em algo mais útil e bonito (podemos supor XML):
- Extrair metadados: do ponto de vista computacional o conteúdo em si de um lei, decreto, contrato, extrato, etc. não interessa, pode ser repassado ao usuário tal qual foi entregue; mas interessam trechos e códigos (identificadores) que servirão de atributos daquele conteúdo. Exemplos: reconhecer identificador do documento (ex. epígrafe de um decreto), identificador de tipo de documento (ex. distinguir tipo ou autoridade de uma lei), CNPJ da entidade associado ao documento, localização da entidade expressa por nome de logradouro, numeração predial e CEP.
- Reconhecer e converter marcas XHTML relevantes: parágrafos, negritos, itálicos, seções, subseções, etc. que for possível. Em seguida, idealmente, "dar um tapa" para ficar parecido com o layout do Diário Oficial, ou para dar destaque aos metadados.
A seguir um lembrete, para todos podermos falar a "mesma língua" neste projeto, assim como verificarmos consensos, sobre os limites da automação, e as soluções clássicas do problema... Se o lembrete faz sentido, fica a sugestão: documentar mais formalmente e usar como referência nas discussões e na justificativa das decisões de projeto.
Limites da automação
- Limites na extração automática de metadados: o reconhecimento de padrões (ex. regular expressions ou parsers estatísticos) depende do texto original cumprir com esses padrões. Tanto o baixo controle do processo (o autor tem liberdade de errar) como a estatística (amostragens sobre as fontes do Diário Livre) demonstram a alta diversidade de padrões, e variabilidade não-padronização nos originais. A viabilidade do projeto é proporcional à satisfação do público com essa taxa de erros.
- Limites da conversão automática para XHTML: apenas grandes blocos de conteúdo, e as marcas de retrancas, podem ser utilizados para a conversão XHTML. O reconhecimento por exemplo de artigos, itens, alienas, etc. de uma lei ou decreto, requer um tratamento mais sofisticado (vide "Investimento computacional" abaixo).
Ignorando-se as limitações quanto à "riqueza de informação", indicadas acima, resta ainda a "completeza", ou seja, o percentual de documentos que pode de fato ser convertido com sucesso sem intervenção humana. Numa análise otimista, pode-se supor que 80% dos textos do Diário Livre podem ter seu processamento primário automatizado. A limitação de completeza seria caracterizada pelos 20% restantes, que não foram processados ou que se supõe processados mas possuem falhas.
Soluções
As soluções clássicas de tratamento de TXT podem ser exemplificadas pela biblioteca de regular expressions da tese de Dorante 1997, e pelo software GutenMark. As limitações clássicas são bem conhecidas...
Além disso o input TXT é ruim e pobre, o ideal (e uma solução!) seria obter na origem o texto marcado, exportado por exemplo como HTML.
Lobby por melhor input
Na CGM de São Paulo tem tomado a frente dessa importante solução, que seria válida para documentos futuros, mas fica o problema para todo o acervo retrospectivo, de anos.
Investimento humano
Numa análise otimista, pode-se supor que 80% dos textos podem ter seu processamento primário automatizado. Temos dois problemas:
- Como saber se um documento faz ou não parte dos 20% falhos?
- O que fazer com esses 20%, descartar? E quando um documento de interesse da comunidade está justamente contido nesses 20%?
Já foram sugeridos mecanismos do tipo "Like" para que navegantes indiquem que o documento por onde navegou estava em ordem ou não, solucionando (informalmente) o primeiro problema.
Já quanto a não-descartar: uma comunidade de interesse (estilo Wikipedia) ou prestação de serviços paga (a custo avaliado em R$5 a R$50 por documento) assumiriam a revisão desses 20%, ou pelo menos dos documentos relevantes e contidos nesses 20%.
Investimento computacional
Existem ferramentas computacionais, mas elas exigem investimento muito maior por dois motivos:
- requerem um uma amostragem de "original vs corrigido" para que as soluções sejam testadas e calibradas. Logo, demanda investimento humano lembrado acima, mesmo que reduzido não é desprezível.
- requerem arquitetura mais complexa (vide ex. soluções NLP), muito mais memória e CPU por documento, e gente especializada para fazer os dividos ajustes e adaptações. Estatísticas, redes neurais, etc. todos demandam adaptação e experts bem treinados para fazer essas adaptações. Problema adicional: são soluções especializadas num corpus ou estilo de texto, se muda o estilo ou o comportamento do corpus, a solução não resolve. Em geral o primeiro passo é organizar os documentos em grupos e avaliar quais grupos são maiores e/ou de maior interesse.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent