No contexto fundamental da Biblioteconomia e da Ciência da Informação, a maneira como os dados são organizados definem como eles podem ser pesquisados. Esta realidade se aplica a diversos suportes, ambientes e ferramentas informacionais e ganha destaque na “Era dos Dados” com o catálogo de dados corporativos (Data Catalog) que permite uma visão abrangente de todos os dados existentes em uma organização, subsidiando a descoberta de dados, a recuperação de informação e futuramente a criação de grafos de conhecimento (Olesen-Bagneux, 2023).

Com o avanço das tecnologias da informação e comunicação e principalmente da web, a disponibilização de dados, processáveis por máquinas, na internet, por meio de Application Program Interface (API), tornou-se uma fonte de informação da atualidade. Esta fonte de informação na web é utilizada por muitas empresas e governos para publicar e principalmente para trocar dados entre sistemas.

A interoperabilidade entre essas novas fontes de informação é possível graças a arquitetura de microsserviços que utiliza as APIs para implementar o acesso por máquina padronizado, com definições compartilhadas em suas documentações, para uma interação fácil e eficaz (Fowler, 2019; Saudate, 2021).

O movimento de acesso aberto, iniciado em 2001, durante a conferência Budapest Open Access Iniciative, fomentou o acesso aberto aos dados de pesquisa (Budapest Open Access Initiative, ©2024) e foi empreendido em outras áreas como a governamental. O termo open government data foi criado em 2007, em uma conferência em Sebastopol, Califórnia, para definir os princípios relacionados (Open Gov Data, 2007) e caracterizar os dados abertos sobre o governo, ou Dados Governamentais Abertos (DGA) (Albano, 2014). Essa nova tipologia de dados ganhou muito destaque, sendo considerado um fenômeno político e socioeconômico, promovendo envolvimento cívico e estimulando inovações no setor público e em diversas áreas (Nikiforova et al., 2023).

Com o passar dos anos, surgiram legislações e políticas específicas para publicação de dados abertos pelos órgãos governamentais. No Brasil, o marco inicial foi a Lei de Acesso à Informação (LAI), Lei Nº 12.527/2011, mas a Política de Dados Abertos foi oficializada pelo Decreto Nº 8.777/2016, somente em 2016 (Brasil, 2011; Brasil, 2016a). A partir dessas novas regulações, o volume de DGA aumentou significativamente, assim como a diversidade de formatos e padrões utilizados, tornando-se uma tarefa cada vez mais difícil colocá-los em um contexto significativo para extrair informações valiosas (Kalampokis; Tambouris; Tarabanis, 2013).

Considerando a importância dos DGA, as APIs são recursos tecnológicos em potencial neste contexto informacional, apoiando o acesso, a organização e a recuperação de grandes volumes de dados para serem reutilizados em análises e novos produtos e serviços de informação (Silva, 2022). No Brasil, a recuperação de DGA em APIs é dificultada pela ausência de um padrão geral para publicação e pela falta de centralidade das informações que estão fragmentadas nos sites e portais dos órgãos que disponibilizam esse serviço (Silva, 2023).

É nesse contexto informacional que o catálogo de dados pode ser utilizado para otimizar a descoberta de dados e a recuperação de informação, permitindo a democratização dos DGA e seu reúso. O catálogo é um longínquo instrumento de guarda e permanência que está diretamente associado à organização e controle de um acervo (Pedrão, 2019), mas com a evolução dos suportes e novos ambientes de informação tem sofrido alterações em relação a sua concepção e implementação. Para Olesen-Bagneux (2023) o catálogo de dados é um mecanismo de pesquisa, sendo essencialmente um banco de dados contendo metadados extraídos de fontes de informação. Na atualidade, essa ferramenta tem sido utilizada junto à governança de dados para acompanhar todo o ciclo de vida dos dados e permitir pesquisar e encontrar efetivamente os dados de uma organização.

Diante da necessidade de recuperação dos DGA, no contexto das fontes de informação automatizadas, o catálogo de dados pode ser uma solução interessante para este domínio de investigação, ainda pouco explorado, mas com um grande potencial a ser revelado. Considerando todo esse cenário, o estudo parte das seguintes problemáticas: quais os tipos de dados existentes nas APIs de DGA? Como um catálogo de dados pode ser utilizado para descoberta de dados nas APIs de DGA do Brasil? O objetivo da pesquisa foi modelar um catálogo de dados para APIs de DGA no contexto brasileiro. Especificamente buscou-se: (i) analisar os dados e metadados das APIs de DGA brasileiras, (ii) definir os atributos e metadados para representação das APIs e (iii) modelar um catálogo de dados. Metodologicamente a pesquisa foi dividida em três etapas, uma para cada objetivo específico, e foi caracterizada como descritiva e aplicada.

Este estudo integra um projeto de pesquisa maior, intitulado: Observatório de Dados Abertos (https://observatoriodedadosabertos.eci.ufmg.br/) que reúne estudos sobre interoperabilidade, organização, recuperação e reúso de dados abertos do governo brasileiro. Esta pesquisa apresenta uma solução prática para modelagem de um catálogo de dados para um domínio específico, considerando os aspectos da organização e representação da informação, temáticas essenciais da Ciência da Informação que fazem intersecção com ferramentas tecnológicas da Ciência da Computação para alcançar um objetivo comum dos DGA que é a sua recuperação e o reúso pela sociedade. Estima-se que otimizar a representação, organização e recuperação dos dados abertos poderá viabilizar o acesso e uso dos dados por parte da sociedade e potencializar a criação de novos conhecimentos e oportunidades de inovação.

A pesquisa foi caracterizada como descritiva, por descrever as características de uma população ou determinado fenômeno (Gil, 1999), neste estudo representado pelas APIs de DGA, e aplicada, por ter um interesse prático, onde os resultados serão utilizados imediatamente na solução de um problema real (Lakatos; Marconi, 2002), ou seja, a modelagem de um catálogo de dados. A investigação foi estruturada em três etapas: Etapa 1 - Estudo das APIs de DGA existentes no Brasil; Etapa 2 - Definição de metadados para representação das informações das APIs e Etapa 3 - Modelagem do catálogo de dados.

É importante ressaltar que este estudo considerou o objetivo do catálogo de dados, definido na literatura por Olesen-Bagneux (2023, p. 77), para: “saber que tipo de dados sua organização detém”, esse objetivo vai de encontro com a problemática do estudo, no contexto dos DGA, que envolve saber os tipos de dados existentes nas APIs de DGA. No entanto, algumas adaptações foram necessárias para a modelagem deste catálogo de dados, visto que os dados não foram acessados diretamente em seus sistemas de origem e sim pelas APIs que disponibilizam os DGA de forma aberta para sociedade.

A Etapa 1 foi realizada com um dos artefatos do projeto que este estudo integra e mapeou a recuperação de dados abertos em APIs de DGA no Brasil. Uma pesquisa exploratória nos sites, instrumentos e documentos da política de dados abertos identificou as APIs de dados abertos dos órgãos do governo federal e mapeou, até 2023, 19 APIs de 14 órgãos que disponibilizam dados abertos (Nascimento Silva, 2023; Nascimento Silva; Da Silva, 2023). Para cada API foi observado seu conteúdo, a estrutura de dados, assim como os elementos que integram a API (rotas, parâmetros, retornos) para definição dos domínios, fontes de dados e ativos.

A Etapa 2 definiu uma estrutura padrão, a partir dos elementos que compõem as APIs, que deve ser considerada para representar e recuperar dados e informações no catálogo de dados. Foram considerados elementos para representação descritiva ou catalogação de dados abertos, envolvendo instrumentos do governo como o padrão de metadados e-PMG (https://www.gov.br/governodigital/pt-br/governanca-de-dados/PMGVersao1_1.pdf), um padrão específico para representação de informação no governo eletrônico, e da representação temática, a partir de um vocabulário controlado para classificação das APIs. De forma adicional, foram incluídos metadados técnicos para um maior detalhamento das APIs.

A Etapa 3 consistiu na modelagem do catálogo de dados, a partir dos resultados obtidos nas Etapas 1 e 2. A documentação da modelagem proposta foi o objeto em destaque nesta etapa que tem como objetivo relatar a arquitetura do catálogo de dados, assim como apresentar as definições, ações e procedimentos realizados. A Figura 1 apresenta um resumo das etapas, destacando os principais procedimentos, pré-requisitos utilizados, artefatos gerados e trabalhos futuros após a modelagem (implementação e consultas).

As três etapas foram iniciadas no segundo semestre de 2023 e concluídas em 2024. A equipe de trabalho envolveu inicialmente dois pesquisadores e a partir de outubro de 2023, três, de forma direta. Todas as atividades do projeto foram gerenciadas pela primeira autora e coordenadora do projeto, seguindo os eventos e artefatos do framework Scrum, com ciclos (sprints) semanais. O ambiente de trabalho (diretórios com documentações e modelagens, ferramentas de gestão e acompanhamento do projeto e salas de reunião online), foi construído em ferramentas web com de armazenamento em nuvem e utilizado por todos os integrantes para execução das atividades. O framework Scrum foi selecionado por ser uma metodologia ágil empregada em projetos em que não se conhece todos os requisitos, e mudanças podem ocorrer em seu desenvolvimento (Valente, 2020), situação identificada já na Etapa 1 ao identificar APIs heterogêneas e despadronizadas.

Na Etapa 1 foi feita uma análise das 19 APIs mapeadas, a fim de identificar as áreas que estavam relacionadas e a estrutura básica comum para a maioria das APIs de dados abertos. Conforme Olesen-Bagneux (2023), a eficácia do catálogo de dados depende de como ele é estruturado e isso afeta diretamente a sua capacidade de pesquisa.

Assim, a partir dessa estrutura básica e do conteúdo identificado nas APIs foi definida a organização do catálogo de dados. Essa organização considerou a classificação das APIs em domínios, fontes de dados e ativos. A maioria das APIs eram bem distintas e envolviam diversos órgãos, desta forma foram definidos 11 domínios, conforme classificação do Vocabulário Controlado de Governo Eletrônico (VCGE), e 14 fontes de dados, em uma relação direta com os órgãos responsáveis, conforme apresentado no Quadro 1.

Para classificação das APIs e definição dos domínios foi escolhido o VCGE, um vocabulário controlado para indexar informações do governo federal brasileiro que abrange os assuntos dos domínios especificados no âmbito do governo e dos padrões vigentes de interoperabilidade (ePING, https://eping.governoeletronico.gov.br/) para o governo digital no Brasil (Brasil, 2016b). Optou-se por criar domínios mais abrangentes, visto que as APIs são bem diversas e apresentam conteúdos bem diversificados sobre uma área de assunto. Cada API foi considerada um ativo, visto que tinham características próprias. Destaca-se que nesta modelagem inicial foi considerado como ativo para o Instituto Brasileiro de Geografia e Estatística (IBGE) somente a API de dados agregados, por ser mais “conhecida”, com dados de pesquisas e censos, e por sua estrutura manter a conformidade com as outras APIs disponibilizadas pelo órgão.

Na Etapa 2, os elementos comuns à estrutura das APIs, observados na Etapa 1, foram analisados para definição de uma estrutura padrão. Conforme destacado por Kobashi (1996), para representar a informação contida em um documento, o profissional da informação precisa ter conhecimento da instituição que mantém o arquivo (estrutura e funcionamento), da essência documental (de que trata e para que fins foi criado o documento) e a quem se destina o uso. Dessa forma, além da estrutura comum observada nas APIs foram analisados os ativos, o contexto e a tipologia dos dados abertos disponibilizados.

A arquitetura de microsserviços, definida e padronizada por APIs, foi um fator decisivo para estabelecer os elementos para representação das APIs no catálogo. Com isso, foram considerados os elementos que compõem uma API. Os microsserviços adotam APIs como canais para atender aos usuários, sendo similar a uma “função” na programação, que é composta pelo nome da função, parâmetros de entrada e a saída a ser gerada (Ghani; Zakaria, 2018). Com isso, baseado nas características dessa arquitetura e do seu funcionamento, os elementos comuns que compõem as APIs, considerados para sua representação foram: URL padrão, endpoint ou rotas disponíveis, também conhecido como path, parâmetros disponíveis para cada endpoint e retorno do endpoint (metadados retornados) com um exemplo do objeto retornado pela API.

A Figura 2 apresenta a validação dos elementos definidos na API da Câmara dos Deputados que possui a URL padrão: https://dadosabertos.camara.leg.br/api/v2/ e os endpoints: (1) /blocos (2) /deputados (3) /eventos (4) /frentes. Cada endpoint admite parâmetros específicos e para cada parâmetro repassado haverá um retorno associado. É importante destacar que a URL padrão irá executar somente se possuir a indicação do endpoint e respectivos parâmetros, conforme apontado na documentação da API (https://dadosabertos.camara.leg.br/swagger/api.html).

Conforme destacado por Ferneda (2012), um Sistema de Recuperação de Informação (SRI) deve representar o conteúdo dos documentos do corpus e apresentá-los ao usuário de uma forma que permita a rápida seleção dos itens que satisfazem total ou parcialmente a necessidade de informação. Fazendo uma associação com as APIs, esta necessidade que geralmente é formalizada por uma expressão de busca e formulada pelo usuário, em um SRI convencional, agora está padronizada e definida com endpoints e parâmetros, estruturados no catálogo de dados. Com isso, considerando ainda a analogia com um SRI, a operação de tradução (representação da expressão de busca) que é comparada com a representação dos documentos no corpus, pela função de busca, no modelo de recuperação de informação, tornou-se uma requisição, uma operação simples e direta na API.

A partir dessas definições sobre a recuperação de informação e características observadas, foram mapeados todos os metadados necessários para descrever e representar as APIs, contendo a descrição da estrutura e caracterização das fontes. O padrão de metadados do governo eletrônico (e-PMG) foi considerado para caracterização dos componentes, contudo não havia uma correspondência direta com todos os elementos das APIs. Apesar de as APIs governamentais não utilizarem um padrão de metadados, essa condição não impediu a modelagem do catálogo, que considerou recursos comuns e mais gerais. Destaca-se que foram realizados vários testes, com dados já mapeados nas APIs, para validar se os metadados definidos atendiam as APIs mais diversas.

O uso apropriado do padrão de metadados assegura uma descrição normalizada e como consequência uma representação de qualidade que facilita o intercâmbio de informações e a recuperação da informação, promovendo a interoperabilidade (Alves, 2010). Nesse sentido, estabelecer um padrão de metadados para o desenvolvimento de uma API é essencial para promover a sua interoperabilidade com outros serviços, permitir a integração com outros frameworks, inclusive semânticos, catálogos e bases de dados. Além disso, essa padronização poderá contribuir com a governança de dados nas instituições e no contexto dos dados abertos, com a conformidade regulatória, implementada por legislações e pela Política de Dados Abertos do governo federal brasileiro.

Com os resultados das etapas 1 e 2 foi modelado em um banco de dados relacional para armazenamento dos metadados, ou seja, a modelagem propriamente dita do catálogo de dados para as APIs (Etapa 3). Conforme Olesen-Bagneux (2023, p. 25) um catálogo de dados é “[...] essencialmente um banco de dados contendo metadados que foram enviados ou extraídos de fontes de dados no cenário de TI de uma determinada empresa”.

Para modelagem do catálogo de dados foram criadas oito tabelas: ‘apis’, ‘institutions’, ‘api_endpoints’, ‘endpoint_parameters’, ‘parameters’, ‘api_responses’, ‘tags’ e ‘endpoint_tags’, conforme detalhado no Quadro 2. O diagrama completo com todas as tabelas e relacionamentos foi apresentado na Figura 3.

A nomenclatura do esquema seguiu o padrão snake case patterns. Neste padrão utiliza-se a separação das palavras com o caractere underscore, como por exemplo: ‘api_endpoints’. Adotar o idioma inglês para as nomenclaturas foi uma decisão de design e boas práticas, uma vez que ele é amplamente utilizado entre desenvolvedores de sistemas e comandos de banco de dados, proporcionando uma maior consistência. A chave primária das tabelas, ou seja, o elemento que identifica unicamente cada linha foi incrementado sequencialmente, de forma automática, a cada inserção na tabela. Além dos atributos criados para descrição e detalhamento das APIs, foram criados atributos de controle para identificar, por exemplo, a exigência de autenticação em uma API.

Todas as tabelas criadas para o catálogo estão relacionadas e os relacionamentos foram pautados na composição padrão de uma API. Assim, uma API mantém uma conexão com N endpoints, os quais estão associados a N parâmetros. Cada endpoint, por sua vez, possui uma relação com um response (retorno) específico. As APIs foram classificadas conforme os assuntos do vocabulário VCGE e suas especificações. Destaca-se que devido às singularidades de cada API, os assuntos de VCGE ainda eram muito abrangentes, o que demandou a criação de tags mais específicas para categorizar os endpoints. Assim, cada endpoint pode estar associado a diferentes tags, que são responsáveis por classificar tematicamente os recursos disponibilizados. Essas tags foram criadas a partir de uma análise de assunto realizada pelos autores, com os resultados da Etapa 1 e consultas realizadas nas APIs.

Ao longo desta pesquisa foi possível observar que o catálogo de dados, neste estudo, também pode ser considerado um repositório de metadados, visto que seu objetivo é a pesquisa por dados em um banco de dados de referência. A partir dessa solução, um cidadão poderá saber quais tipos de informação determinada API retorna, respondendo a problemática deste estudo que envolve a descoberta de dados nas APIs de DGA do Brasil.

É importante destacar que muitas APIs ainda estão em desenvolvimento, apresentam instabilidades e sofrem modificações. Na documentação da API da Câmara, Câmara dos Deputados (2024), por exemplo, é informada a identificação da versão atual com a data da publicação e um alerta indicando que a versão “ainda é incompleta, sujeita a mudanças e que não substitui a versão original dos Dados Abertos”, fazendo referência à página de publicação dos conjuntos e dados abertos do órgão.

Outro destaque é referente à documentação do VCGE, que estava disponibilizado no site do governo federal, mas em uma consulta, realizada em setembro de 2024, já não estava disponível, sendo acessado somente por um serviço de arquivo na internet (https://web.archive.org/web/20220124204600/https://www.gov.br/governodigital/pt-br/governanca-de-dados/vcge_2_1_0.pdf). A indisponibilidade de documentos oficiais é um problema que também se repete no acesso às APIs, visto que há alterações de versões, links e documentações, às vezes, sem nenhum tipo de comunicação aos usuários.

Considerando que o catálogo de dados terá uma interface (front-end) para os usuários realizarem pesquisas, serão criadas consultas para permitir executar buscas no catálogo de dados, por meio de filtros e pesquisa direta. Com isso, a entrada principal do catálogo de dados irá considerar a arquitetura de domínio criada e a representação das APIs será refletida na navegabilidade do catálogo de dados, permitindo aos usuários pesquisar por dados abertos de forma objetiva e padronizada. Os scripts para criação das tabelas e as consultas estão disponíveis no diretório do projeto (https://github.com/ObservatorioDadosAbertos/) e após conclusão da implementação do catálogo serão disponibilizados com acesso aberto.

A modelagem de um catálogo de dados é um dos artefatos do projeto de pesquisa “Observatório de Dados Abertos” que investiga temáticas recentes e inéditas sobre dados abertos com processamento automatizado, no contexto da representação, organização e recuperação de dados e informação, em interface com a Ciência da Informação e a Ciência da Computação. A partir de questionamentos sobre os dados existentes nas APIs de DGA e da função do catálogo de dados, a pesquisa teve como objetivo apresentar uma proposta inicial de modelagem de um catálogo de dados para APIs de DGA no contexto brasileiro.

Metodologicamente a construção do catálogo envolveu três etapas, a saber: Etapa 1 - Estudo das APIs de DGA existentes no Brasil; Etapa 2 − Definição de metadados para representação das informações das APIs e Etapa 3 − Modelagem do catálogo de dados. O mapeamento das APIs existentes foi realizado em uma pesquisa anterior e foi basilar para o estudo das APIs, permitindo a definição dos domínios, fontes de informação e ativos na Etapa 1. Na Etapa 2, a representação das APIs no catálogo de dados considerou os componentes padrões da arquitetura das APIs, utilizando, quando possível, elementos do padrão de metadados e-PMG em conjunto com o VCGE para classificação temática das APIs.

Com base nos resultados das Etapas 1 e 2, a Etapa 3 consistiu na modelagem do catálogo de dados, por meio da criação de um banco de dados relacional com oito tabelas, refletindo a estrutura de uma API. A solução envolveu conceitos e técnicas para representação, organização e recuperação de dados nas APIs de DGA, bem como padrões de projeto de Sistemas de Informação e fundamentos de Engenharia de Software, considerando elementos da pesquisa por dados, ou seja, a descoberta dos metadados disponibilizados nestas APIs, que atualmente estão descentralizadas em portais e serviços de dados abertos nos órgãos do governo federal. Esta etapa permitiu a melhor compreensão do estudo, por todos os pesquisadores, sendo fundamental para manutenibilidade do catálogo de dados que estará em constante evolução para refletir as modificações das fontes de informação.

Em se tratando de APIs governamentais, um desafio constante é lidar com a instabilidade dos ambientes (servidores de aplicação, repositórios e ferramentas de documentação) e as modificações realizadas sem controle de versão. Essas questões afetam diretamente o catálogo que será alimentado com os dados das APIs oficiais dos órgãos do governo federal, podendo gerar retrabalho e manutenções não planejadas. Instabilidades em instrumentos do governo, como o VCGE, e a inexistência de padrões de representação e organização para o desenvolvimento de APIs nos órgãos federais também ampliaram os desafios, especialmente no desenvolvimento da modelagem.

Conclui-se que o catálogo de dados é um instrumento que permitiu organizar e armazenar os metadados das APIs de DGA e esta solução pode ser utilizada em outros domínios de dados. Destaca-se que apesar de a arquitetura do catálogo ter sido concluída, esse é um primeiro release. Assim, modificações não estão descartadas, visto que algumas APIs de DGA são bem específicas e podem sofrer alterações, assim como em qualquer projeto de software.

Estima-se que o catálogo de dados abertos permita aos cidadãos identificarem as APIs de DGA existentes no Brasil e descobrir metadados para recuperar conjuntos de dados, incentivando o reúso dos dados abertos e a interoperabilidade com outras aplicações. Como trabalhos futuros, consultas serão implementadas em um front-end do catálogo de dados, para pesquisa e interação dos usuários, e o banco de dados, “populado” com as APIs de DGA, será utilizado na implementação do catálogo de dados abertos.