segunda-feira, 11 de dezembro de 2017

Avaliando a qualidade dos Portais Brasileiros de Dados Abertos Governamentais

Por Thiago Ávila e Rodrigo Hickmann Klein

Desde meados de 2011, com a entrada em vigor da Lei de Acesso à Informação - LAI e consequentemente, a existência do Portal Brasileiro de Dados Abertos (www.dados.gov.br) e a Infraestrutura Nacional dos Dados Abertos – INDA, o Brasil passou a constar no seleto grupo de nações globais a ofertar Dados Abertos Governamentais (DAG) em caráter institucional, em Portais oficiais para este propósito, assim como o Reino Unido, Rússia, Estados Unidos da América, Quênia, Espanha e outras nações globais.

Todavia, em que pese a LAI estar em vigor há mais de 5 anos e o Art. 8º, §3, incisos II, III e IV serem muito claros quanto a determinação que os sítios que promovam o acesso a informação o façam:
II - possibilitando a gravação de relatórios em diversos formatos eletrônicos, inclusive abertos e não proprietários, tais como planilhas e texto, de modo a facilitar a análise das informações”;
III - o acesso automatizado das informações por sistemas externos em formatos abertos, estruturados e legíveis por máquina”; e ainda
IV - divulgar em detalhes os formatos utilizados para estruturação da informação”.
ou seja, como dados abertos governamentais, com exceção da União Federal e alguns poucos estados como Alagoas, Distrito Federal, Rio Grande do Sul e São Paulo, e municípios como Recife, Fortaleza e Rio de Janeiro, o cumprimento desta determinação legal de ofertar informações como dados abertos governamentais, em portais adequados para este propósito, ainda é uma realidade aquém do que poderia ser no contexto federativo brasileiro. Por outro lado, diversos entes subnacionais vem disponibilizando Dados Abertos Governamentais não em portais próprios, mas como seções dos seus Portais de Transparência.

Neste contexto, a pesquisa de doutorado “Mecanismos de ampliação da transparência em portais de dados abertos governamentais brasileiros à luz da Accountability Theory”, realizada no âmbito do Programa de Pós Graduação em Administração da PUCRS [1], identificou mecanismos que ampliam a transparência dos Dados Abertos Governamentais (DAG), através da opinião de especialistas nacionais e, principalmente, pela opinião de pessoas que utilizam esses dados.

Nessa pesquisa os mecanismos são processos, arranjos e relacionamentos, que objetivam a ampliação da transparência, respeitando princípios. Cada princípio direciona um mecanismo que atende a metas, que utilizam e são monitoradas por indicadores, conforme descrito na Figura 1.




Figura 1 – Modelo conceitual da pesquisa (Klein, 2017)

Os princípios da transparência governamental, denominados Usefulness e Stewardship, definem que as informações disponibilizadas precisam estar adequadas ao propósito (utilidade) e ao uso (garantia) [2]. Para melhor compreender esses princípios, podemos compará-los ao uso de um medicamento que tem o propósito de resolver um problema de saúde, porém é necessário verificar se esse medicamento tem condições de uso, ou seja, verificar vencimento, condições de armazenagem, adulterações, dentre outros aspectos que podem tornar ineficaz o tratamento do problema. O mesmo ocorre com o DAG, primeiro é necessário identificar o seu propósito, que pode ser inovação, controle social, dentre outros, e posteriormente identificar suas condições para o uso.

Dessa forma, a transparência não é o propósito final, ela é um meio, uma forma de disponibilizar dados que atendam a um propósito [3]. No caso dos usuários de DAG, respondentes dessa pesquisa, o principal propósito era obter Dados Abertos Governamentais para conferência da prestação de contas governamentais e para a responsabilização de agentes públicos, não apenas no sentido de sanções previstas na legislação, mas na identificação dos responsáveis que estarão sujeitos a consequências diversas, tanto negativas quanto positivas. Normalmente, a responsabilização é um termo mais associado às consequências negativas. No entanto, entre as consequências positivas, podemos citar, como exemplo, a boa avaliação, a popularidade e a aprovação do governante por seus eleitores.

Nesse sentido, a pesquisa demonstrou a atuação da democracia participativa no contexto brasileiro, por intermédio das avaliações e opiniões coletadas de entidades de ativismo social, como por exemplo, a opinião de membros de Observatórios Sociais, que utilizam DAG para controle social. Como resultado de maior tangibilidade, a pesquisa resultou na criação do Índice de Transparência para Portais Brasileiros de Dados Abertos Governamentais (ITPBDAG), baseado em 18 critérios de qualidade que, segundo o referencial teórico da pesquisa, devem ser contemplados nestes Portais de Dados Abertos Governamentais.


Figura 2 – Critérios de avaliação do ITPBDAG (Klein, 2017)

Os 18 mecanismos resultantes da pesquisa, foram identificados a partir de pesquisas científicas atuais, a partir de sistemas de avaliações internacionais e nacionais, e pela análise da legislação federal sobre o assunto. Todos os mecanismos identificados foram considerados importantes, muito importantes ou extremamente importantes por 92% das pessoas que utilizam DAG. A partir desse grau de importância atribuído aos mecanismos, foi elaborado um índice para avaliar os portais nacionais que disponibilizam DAG para download, mantidos pela Administração Direta do Poder Executivo, analisados entre 05/01/17 e 24/03/17. Os cinco primeiros colocados foram os portais mantidos pelo Poder Executivo do Município de Recife, do Estado de Alagoas, do Município de São Paulo, do Município do Rio de Janeiro e o portal de DAG do Governo Federal.

Figura 3 – Resultados mensurados pelo ITPBDAG, nos Portais que disponibilizam Dados Abertos Governamentais no Brasil (Klein, 2017)

Entretanto, ainda há muito trabalho à frente, em prol da prestação de contas e da responsabilização por intermédio dos Dados Abertos Governamentais e a pesquisa demonstra os aspectos que podem ser aprimorados gradativamente. 

Como exemplo, dentre os portais analisados muitos não apresentavam a maioria dos mecanismos identificados pela pesquisa. Além disso, poderiam existir mais portais que disponibilizam DAG para download, pois dentre os 88 municípios com mais 300.000 habitantes e as 27 Unidades Federativas, foram identificados somente 18 portais atualizados desde 01/01/2015.

A pesquisa completa está disponível em: http://tede2.pucrs.br/tede2/handle/tede/7724. A leitura desta tese é obrigatória para os interessados no assunto.

Até a próxima!!!

[1] Pesquisa acadêmica de doutorado realizada por Rodrigo Hickmann Klein, no âmbito do Programa de Pós Graduação em Administração da PUCRS, orientado pela Dra. Edimara Mezzomo Luciano.
[2] DAWES, S. S. Stewardship and usefulness: Policy principles for information-based transparency. Government Information Quarterly, v. 27, n. 4, p. 377-383, 2010.
[3] BALL, C. What is transparency?. Public Integrity, v. 11, n. 4, p. 293-308, 2009.”

sexta-feira, 8 de dezembro de 2017

Usando a modelagem de decisão para enriquecer modelos de processos

No último post comentei como a modelagem de processos de negócio pode ser complementada usando a notação CMMN (Case Management Model and Notation) para tratar situações que são melhor modeladas aplicando conceitos de gestão de casos. Dessa forma, pode-se criar modelos de processos usando em conjunto as notações CMMN e BPMN (Business Process Model and Notation).

Hoje, comento sobre outro padrão OMG (Object Management Group) que também pode ser utilizado na modelagem de processos de negócio de modo a produzir modelos mais eficazes e robustos. Esse padrão é o DMN (Decision Model and Notation) desenvolvido para representar as regras de negócio que devem ser seguidas na execução dos processos.


De forma semelhante à BPMN, o principal objetivo da OMG com o DMN é prover uma notação padrão para modelagem de regras de negócio que possa ser usada pelas diversas equipes do negócio, sejam eles gerentes e executantes dos processos, analistas responsáveis pela definição das regras, ou desenvolvedores responsáveis pela aplicação delas na automação de decisões. Como o padrão DMN define a lógica das regras de negócio através de uma linguagem própria de modelagem, e não a forma como elas são aplicadas nos processos de negócio, o modelo DMN é independente de como as regras são efetivamente implementadas nos processos de negócio, seja manualmente ou através de automação. Assim, o DMN promove o intercâmbio de modelos entre organizações e a possibilidade de que esses modelos possam ser executados em qualquer máquina de regras compatível com o padrão.

Dado que o objetivo de uma regra de negócio é direcionar uma tomada de decisão durante a execução de um processo de negócio, o principal elemento DMN é definido como a "Decisão", responsável por determinar um valor de saída (a decisão) como resultado da aplicação de uma lógica de decisão (definida com base em regras e conhecimentos de negócio) a um conjunto de dados de entrada. Um modelo DMN pode ser composto por múltiplos elementos interligados em um diagrama chamado DRD (Decision Requirements Diagram), como no exemplo da figura abaixo, onde a “Decisão A” é consequencia de uma determinada lógica de negócio aplicada aos valores dos parâmetros de entrada Dados A1, Dados A2 e Decisão B: 
A formulação da lógica de decisão pode ser feita de diversas formas, sendo que o mais comum é através de tabelas de decisão, onde os valores possíveis de decisão são definidos pelo mapeamento das regras de negócios nos valores possíveis nas entradas. No exemplo abaixo, o valor atribuído ao fator de risco é 0.5 sempre que o risco for classificado como alto, ou 0.7 quando for classificado como médio:

O padrão DMN prevê também a utilização de expressões lógicas compostas por linguagem própria denominada FEEL (Friendly Enough Expression Language). Mas uma descrição detalhada do padrão DMN não cabe neste curto post, inclusive porque o Antonio Plais, nosso colega de blog, já discorreu muito bem sobre o assunto aqui e nesta série. Assim, vou apenas tentar mostrar como o DMN pode ser usado para enriquecer modelos BPMN.

Como exemplo, escolhi um trecho de um processo fictício onde a atribuição da atividade “Tratar Item” é determinada segundo uma regra de negócios pré-definida. Conforme mostra o diagrama BPMN, o centro funcional responsável pela atividade é definido com base no valor de 3 propriedades do processo: Produto, Local e Nível. Por exemplo, caso o produto seja do tipo “X” e o local igual a “Z”, a atividade deverá ser executada pelo centro funcional “X-A1”, enquanto que para produtos do tipo “Y” e Nível igual a “2”, independentemente do local a atividade deverá ser executada pelo centro funcional “Y-A2”.
O problema dessa modelagem é que a complexidade do diagrama cresce muito rapidamente a medida que aumenta o número de combinações possíveis dos valores de entrada e/ou o número de centros funcionais que podem ser atribuídos. Além disso, frequentemente o mapeamento entre as variáveis de entrada e o centro funcional desejado não é estático na linha do tempo. Ou seja, após a primeira mudança no mapeamento “entradas x centro funcional“ o modelo representado no diagrama fica desatualizado.

O DMN nos permite modelar em um diagrama separado a atribuição do centro funcional e explicitar as regras de negócio que compõem a lógica dessa decisão. No exemplo, o diagrama de requisitos da decisão (DRD) mostra que a decisão “Centro Responsável” depende das propriedades Produto, Local e Nível.
Além disso, o mapeamento entre os valores das propriedades e os centros funcionais é determinado pela tabela de decisão:
O modelo DMN pode ser incluído como elemento do modelo BPMN substituindo a lógica de decisão anteriormente desenhada no diagrama. No exemplo abaixo, o modelo DMN é representado pela atividade “Centro Responsável”, marcada como atividade DMN, a ser executada automaticamente para atribuição do centro funcional, enquanto que a raia “Centro Virtual” corresponde a uma raia virtual cuja atribuição é resolvida no momento de execução do processo: 
É importante notar que, a integração entre as notações mostrada acima não está prevista na especificação BPMN atual porque o padrão DMN é posterior a ela, mas quase certamente será incluída em uma próxima versão. Mesmo porque já existem ferramentas de modelagem BPMN que possibilitam a inclusão de modelos DMN, como o Camunda Modeler usado neste post.

Finalmente, o valor que o padrão DMN traz para a modelagem de processo pode ser resumido nos itens seguintes:
  • Aumento da qualidade do modelo - o diagrama de decisão reduz a ambiguidade do diagrama BPMN explicitando as decisões a serem tomadas nas atividades do processo, os requisitos para que elas aconteçam, e a lógica que determina como a decisão é tomada com nível de detalhamento suficiente para que ela possa ser validada;
  • Separação do modelo de decisão do restante do modelo do processo, possibilitando frequências de atualizações independentes que aumentam a confiabilidade dos modelos como referências do processo de negócio;
  • Simplificação no modelo de processo ao substituir a modelagem de regras de negócio complexas através apenas dos elementos BPMN originais;

Com este post encerramos nossos encontros este ano, boas festas a todos e até um próximo encontro. 



quinta-feira, 7 de dezembro de 2017

O FACIN na prática com o Projeto GEO - Parte 10

No post anterior abordamos o detalhamento das visões Programas e Projetos e Sociedade com a aplicação da dinâmica de Análise de Cenário utilizada na Oficina FACIN-ABEP, realizada pelo Serpro em parceria com a Associação Brasileira de Entidades Estaduais de Tecnologia da Informação e Comunicação (ABEP).
A dinâmica compreende as atividades de identificação do problema, modelagem, análise e construção dos cenários atual e proposto (solução do problema).
Na PRODEMGE o cenário utilizado foi a implantação de uma solução corporativa de geoprocessamento no Estado de Minas Gerais, aqui identificada apenas como Projeto GEO.
Nesta postagem abordaremos o detalhamento dos Padrões e Modelos de Referência do Projeto GEO utilizando o Framework de Arquitetura Corporativa para Interoperabilidade no Apoio à Governança (FACIN), conforme figura 1.

Figura 1: Detalhamento da visão Padrões e Modelos de Referência do Projeto GEO

A figura 2 apresenta uma visão dos Padrões de Geoprocessamento utilizados na Implantação da Solução Corporativa de GEO em consonância com os estabelecidos pela ePING - Padrões de Interoperabilidade de Governo Eletrônico. Dentre eles podemos destacar os padrões de serviços WEB de geoprocessamento, de arquivos georreferenciados e de infraestrutura de serviços WEB georreferenciados.

Figura 2: Visão de padrões tecnológicos da Solução GEO

1.   Padrões de serviços WEB de geoprocessamento
Os padrões OGC (Open Geospatial Consortium) aos quais produtos e serviços precisam se adequar para a interação entre diversas fontes de dados e informações espaciais (georreferenciadas) no Estado de Minas Gerais são:
•         WMS (Web Map Service) define um serviço para a produção de mapas que serão apenas uma representação visual dos dados espaciais e não os dados em si. Estas representações serão geradas no formato de imagem, como JPEG, PNG e GIF ou em formato vetorial, como o Scalable Vector Graphics (SVG).
•         WFS (Web Feature Service) define um serviço para que clientes possam recuperar feições especiais em formato GML (Geographic Markup Language) ou Geojson.
•         WCS (Web Coverage Service) define o acesso aos dados que representam fenômenos com variação contínua no espaço. Este serviço é especificado para tratamento de dados modelados como geocampos (ou atributos geográficos).

2.   Padrões de arquivos georreferenciados
•         GML (Geographic Markup Language) é um conjunto de regras com as quais um usuário pode definir sua própria linguagem para descrever seus dados. Permite a interoperabilidade entre dados geográficos.  Definindo como será o armazenamento e transporte de informações geográficas, incluindo propriedades espaciais e não espaciais das entidades geográficas. O GML é usado também em serviços WFS para trocar feições entre clientes e servidores, servindo, portanto como suporte ao serviço WFS.
•         KML (Keyhole Markup Language) é uma extensão de um XML utilizado pelo Google para tornar possível a visualização de dados geográficos em suas tecnologias: Google Earth, Google Maps, etc.
•         SLD (Styled Layer Descriptor) é arquivo XML que representa graficamente entidades geográficas (textos, pontos, objetos lineares ou polígonos). Na linguagem SLD podem ser definidas regras que agrupam objetos em diferentes categorias e definindo para cada grupo um estilo diferente.
•         GeoTIFF é o formato padrão internacional de intercâmbio de dados raster com saída no formato de grids (para uso em modelos de elevação, modelos digitais de terreno e de superfície). Além de ser um formato aberto, sem copyright, atende perfeitamente as exigências de informações e dados georreferenciados para utilização em qualquer software de análise espacial de dados, com a sua importação amplamente habilitada.

3.   Padrões de Infraestrutura de Serviços WEB Georreferenciados
•         GeoServer (Servidor de Informação Geoespacial) é um servidor de WMS, WCS e WFS, que segue as especificações da OGC.
•         Openlayers (Framework Javascript para Webmapping) é uma biblioteca open source JavaScript que pode ser usada para disponibilizar/exibir dados geográficos na internet.
•         Geonetwork (Catálogo de Metadados) - Perfil MGB (Metadados Geoespaciais do Brasil) em conformidade com a norma ISO 19115:2003.
•         JBoss (Servidor de aplicação) - JEE (Java Enterprise Edition) com código fonte aberto baseado na plataforma, implementado na linguagem de programação Java.
•         Integração com SSC (Sistema de Segurança Corporativa) é o sistema de segurança e monitoramento da PRODEMGE.
•         SGBDE (Sistema Gerenciador de Banco de Dados Espacial) -  Postgre SQL / PostGIS ou Oracle Spatial.
•         SQL (Linguagem para consulta e manipulação de dados em sistemas de gerenciadores de bancos de dados) segundo a norma ISO/IEC 13249 SQL/MM padroniza extensões para dados multimídia e aplicações específicas SQL, sendo estendido para gerenciar dados como texto, imagens, dados espaciais e mineração de dados.

A figura 3 destaca os demais Padrões utilizados no Projeto GEO que foram abordados anteriormente nesta série com seus respectivos links.
  

Figura 3: Visão dos Padrões utilizados no Projeto GEO

•         DAMA-DMBOK (Data Management Body of Knowledge)

O modelo proposto utiliza-se de dois componentes: elementos e relacionamentos, descritos na tabela 1. As cores dos elementos representam as camadas do ArchiMate e sua respectiva correspondência com o TOGAF.

Tabela 1: Elementos e Relacionamentos da visão Padrões e Modelos de Referência



Fonte: ArchiMate 3.0 – Um Guia de Bolso

Acesse aqui o detalhamento completo da aplicação da dinâmica de Análise de Cenário, apresentada na Oficina FACIN-ABEP e utilizada pela PRODEMGE, para implantar uma solução corporativa de geoprocessamento no Estado de Minas Gerais, utilizando o FACIN.

No próximo artigo abordaremos o detalhamento da visão Governança, Riscos e Conformidade do Projeto GEO utilizando o FACIN, não percam!


Autores: Ademilson Monteiro, Antonio Plais, Guttenberg Ferreira Passos, Leonardo Grandinetti Chaves e Sandro Laudares

sexta-feira, 1 de dezembro de 2017

Modelagem de dados para a publicação de Dados Abertos (Conectados) - parte 02


Por Thiago Ávila*

Dando continuidade à nossa série de artigos sobre Dados Abertos (conectados), vamos apresentar a terceira melhor prática para a publicação de Dados Abertos Conectados, aplicando-os no contexto Governamental. Estes artigos têm como fundamentação a dissertação de mestrado, “Uma Proposta de Modelo de Processo para Publicação de Dados Abertos Conectados Governamentais”[1], onde desenvolvi uma revisão de literatura que identificou 70 recomendações para a publicação de Dados Abertos Conectados Governamentais, distribuído entre as 10 melhores práticas estabelecidas pelo W3C[12], que estão sendo exploradas em continuidade a esta série de artigos aqui no blog, cuja metodologia apresentei no artigo anterior.

Para identificar recomendações voltadas a implementar a terceira melhor prática, “3. Modelar os dados”, foi estabelecida a seguinte questão de pesquisa: “O que os processos de publicação de dados abertos (conectados) recomendam a ser feito para contemplar a melhor prática de Modelar os Dados?". Neste artigo apresentaremos outras quatro recomendações para modelagem de dados, complementando as outras três recomendações apresentadas no artigo anterior.

3.4. Anonimizar dados sensíveis

Em que pese as políticas de dados abertos estimularem a publicização dos dados, este processo de abertura e publicação de dados deve ser feita com muita responsabilidade de maneira que não cause prejuízos a indivíduos e organizações. Assim, a recomendação de anonimização dos dados foi identificada como a técnica a ser adotada para não expor dados privados/particulares no arcabouço de uma oferta de dados públicos.
Janssen (2012) [14] apresenta alguns motivos para que nem todos os dados sejam publicizados. Dentre eles, destacamos:
  • Dados podem permitir o rastreamento reverso chegando a identificação de indivíduos e resultando em violação de privacidade e direitos individuais;
  • A abertura de dados inconsistentes pode gerar mais “confusões” do que benefícios, pois os cidadãos podem não obter as respostas que desejam e ainda, gerar questionamentos desnecessários as agências governamentais decorrentes de uma má interpretação dos dados;
  • As legislações dos países apresentam casos explícitos em que certos dados devem ser restritos; e 
  • Certos dados são estratégicos e necessários a políticas de competitividade (por exemplo, dados sobre prospecção de recursos minerais são essenciais para a sustentabilidade de países e podem influenciar a disputa comercial e tecnológica entre empresas públicas que atuam neste setor).



A anonimização de dados é uma tarefa complexa, e se não for feita de forma eficaz, cria riscos a iniciativa de publicação de dados, especialmente por permitir a revelação de dados privados que não devem ser publicados. Apesar da importância desta atividade, apenas os processos do Equador e COMSODE apresentaram recomendações e técnicas a serem adotadas, detalhadas abaixo (COMSODE,2014) [7]:
  • Projeção (projection): Ocorre quando atributos particulares com dados privados são removidos do conjunto de dados. Por exemplo, no caso de arquivos tabulares, isto pode ser implementado mediante a remoção de colunas.
  • Agregação (aggregation): Consiste na mesclagem de vários itens num único dado estatístico (por exemplo, a mesclagem de pessoas e suas idades numa região, publicando-se apenas a idade média das pessoas em cada região).
  • Remoção de conexões (removing links): Providência que deve ser adotada especialmente quando se tratar de dados conectados, devendo ser analisado se as conexões com outros dados revelam dados privados. Caso isto ocorra é necessário remover os links antes de publicar o conjunto de dados.
Cumpre destacar que a anonimização consiste de uma estratégia de mitigação de riscos relacionados ao processo de publicação e caso for negligenciada, pode inviabilizar toda a estratégia de abertura decorrente dos impactos negativos da publicação de dados que não deveriam ser publicados.

3.5. Modelar rotinas automatizadas (ETL) 

Além da oferta de dados em vários formatos, é recomendado que estas rotinas de publicação e manutenção dos dados sejam automatizadas, reduzindo o esforço humano com esta atividade e ainda, ofertando maiores garantias de disponibilidade e atualização dos dados para os usuários. Para esta atividade, serão apresentadas as recomendações de diversos processos com algum nível de detalhamento.

Para automatizar a publicação de dados, os processos do Brasil [4], Uruguai [20] e COMSODE [7] recomendam o estabelecimento de rotinas de extração, tratamento e carga (ETL). A publicação manual de dados deve ser estabelecida apenas para dados que não possuem atualização periódica.

O processo COMSODE detalha tópicos relevantes que devem ser estabelecidos na modelagem de rotinas automatizadas. Para os extratores, deve ser fortemente considerada a origem dos dados a serem publicados. Dependendo desta origem, um extrator pode ser (COMSODE, 2014):
  • Um componente que faz download de um arquivo de dados a partir de uma dada URL;
  • Um componente que copia um arquivo de dados de um sistema de arquivos local;
  • Um componente que acessa um banco de dados relacional com consultas SQL (SELECT);
  • Um componente que acessa um banco de dados RDF com consultas SPARQL (SELECT, CONSTRUCT).
Quanto aos transformadores estes podem ser:
Componentes para transformar a estrutura e os formatos de dados, como:
  • Um componente para transformar formatos proprietários tabulares (XLS (x), ODS, DBF, etc.) e os resultados de consultas SQL para o formato CSV;
  • Um componente para transformar arquivos XML para outros arquivos XML na base de scripts XSLT;
  • Um componente para transformar arquivos JSON para outros arquivos JSON;
  • Um componente para transformar arquivos JSON para arquivos XML e vice-versa.
  • Um componente para transformar CSV, XML e JSON para formatos de representação RDF. Em caso de XML, que pode ser baseada em scripts XSLT.
  • Um componente para transformar representação RDF usando a linguagem SPARQL.
Ou ainda:
  • Componentes que transformem o conteúdo de um conjunto de dados aplicando técnicas de higienização ou anonimização de dados;
  • Bem como, componentes para enriquecimento de dados associando-os ao conteúdo de outros conteúdos de dados decorrente de conexões pré-estabelecidas;
  • Por fim, um transformador pode ser um componente de preenchimento automatizado e manual de metadados em conjuntos de dados de acordo com um esquema (ou vocabulário) de dados pré-estabelecido.
Quanto aos carregadores, consistem da etapa final antes da publicação do dado. São componentes que garantem que o dado exportado da origem estará armazenado num servidor de dados com a qualidade e os formatos adequados para serem publicados. O processo estabelece as seguintes recomendações para carregadores:
  • Se o conjunto de dados estará disponível apenas para usuários que farão o download de dados em grandes volumes, a rotina ETL deve carregar os arquivos de dados para um local que pode ser acessado por usuários via protocolos HTTP ou FTP. Também é possível carregar os arquivos para um servidor Git, por exemplo, o Github.com.
  • Se o conjunto de dados estará disponível através de uma API, a rotina ETL deve carregar os dados para um servidor de banco de dados.
  • Para a oferta de dados em 3 e 4 estrelas, a API deve ser um serviço REST que seja capaz de fornecer o acesso programático para os itens do conjunto de dados e retornar a representação dos itens em formatos JSON, CSV, ou XML. Os dados devem ser armazenados numa base de dados relacional ou numa base de dados no SQL.
  • Para a oferta de dados em 5 estrelas, a API deve ser um endpoint SPARQL. Os dados devem ser armazenados em um banco de dados RDF ou em um banco de dados relacional com uma camada que permite visualizar os dados relacionais como dados RDF e avaliar consultas SPARQL.
O processo do Brasil [4] ressalta que as rotinas automatizadas devem contemplar desde a extração inicial dos dados a partir do seu ambiente de produção até o local onde a base será disponibilizada como dados abertos. Por exemplo, se tiver sido decidido publicar os dados em arquivos csv, essa etapa contempla a obtenção dos dados, tratamento e hospedagem dos dados extraídos após conversão para o formato csv em um servidor de arquivos para a Web (Brasil, 2014). O processo da Colômbia recomenda, que preferencialmente, a origem dos dados das rotinas ETL sejam sistemas de informações governamentais confiáveis e estruturados (Colombia:2012) [6].

O processo proposto por Consoli (2014) [8] apresenta as diversas ferramentas para mineração e modelagem de dados utilizadas num experimento. Por se tratar de uso de dados geoespaciais, se fizeram necessários softwares de manipulação de ontologias, conversores de dados de bancos relacionais para servidores de triplas RDF e sistemas de informações geográficas (Consoli, 2014). Este processo, apesar de pouco detalhado, destaca-se pela utilização de dados geoespaciais, cuja complexidade para abertura e publicação é maior. Ademais, toda a rotina ETL deve ser exaustivamente testada antes de entrar em produção.

3.6. Analisar se os dados serão conectados ou não

Considerando a relevância de se produzir dados conectados, o processo COMSODE [7] sugere que devem ser estabelecidas atividades que visem identificar a conexão do conjunto de dados a ser aberto com outros conjuntos de dados (COMSODE, 2014). Para desempenhar esta tarefa, o processo proposto por Hyland e Wood (2011) [13] destaca que a modelagem de dados se compõe das atividades de identificação, modelagem, nomeação e teste. Na identificação deve-se obter uma cópia lógica e física do modelo do banco de dados, obter dicionários de dados e criar dados de forma que sejam replicáveis. Por último, deve ser observado no mundo real, objetos de interesse relacionados com os dados, como pessoas, locais, coisas e localidades (Hyland e Wood, 2011).

Segundo Hyland e Wood (2011), na modelagem em si, devem ser desenvolvidas as seguintes atividades:
  • Esboçar ou desenhar os objetos em um quadro branco (ou similar) e desenhar linhas para expressar como eles estão relacionados uns com os outros;
  • Investigar como os outros publicadores estão descrevendo dados semelhantes ou relacionados. Devem ser reutilizados vocabulários comuns para facilitar a fusão de dados e seu reuso; Devem ser analisadas ainda, ocorrências de duplicação de dados.
  • Devem ser colocadas de lado às necessidades imediatas e/ou específicas de qualquer aplicação. O dado precisa ser útil para qualquer aplicação.
  • Deve se utilizar finalmente, o bom senso para decidir se o dado será ou não conectado a outro dado;
  • Complementarmente, devem ser utilizadas URIs para referenciar os objetos de dados, devendo ser levado em consideração como os dados poderão ser atualizados ao longo do tempo. Por exemplo, devem ser evitados nas URIs, siglas ou nomes de instituições que podem sofrer alterações decorrentes de mudanças de natureza política ou de mudança governamental. Ademais, as hipóteses estabelecidas no esquema devem ser testadas com especialistas familiarizados com os dados.
Para uma maior familiarização com esta atividade, é recomendado que sejam modelados dois ou três objetos para se iniciar uma rotina de abertura de dados com maior volume. Durante esta atividade, os especialistas envolvidos devem descobrir as relações e identificar como cada objeto se relaciona com o mundo real. Tal atividade pode ser apoiada com base em um grande quadro branco ou site wiki colaborativo. O processo apresentado por Galiotou (2013) [11] explana que foi adotada inicialmente a interconexão de dados de um mesmo domínio geográfico (neste caso um país, a Grécia) e após a conclusão deste domínio, foram buscados conjuntos de dados de outros países que poderiam ser interconectados (Galiotou, 2013).

Nesta oportunidade, ontologias amplamente utilizadas como a DBPedia devem ser avaliadas como candidatas a se interconectar com o conjunto de dados a ser aberto.

3.7. Estabelecer ou aprimorar documentação de dados (esquemas, vocabulários e ontologias)

Para a melhoria da qualidade dos dados a serem publicados, durante a modelagem alguns processos recomendam o estabelecimento de uma boa documentação ou ainda, o aprimoramento da documentação existente, utilizando esquemas, vocabulários ou ainda, ontologias.

Quando houver a publicação de dados tabulares, por exemplo, deve ser realizada uma boa definição das colunas que contém as informações dos arquivos, definindo títulos compreensíveis pelos usuários, bem como quais são os tipos de dados aceitáveis em cada coluna de cada planilha. Em caso de publicação de arquivos XML ou JSON, definir a estrutura básica do documento. É possível, mas não necessário, estabelecer documentos XML Schema ou JSON Schema para validação. Para estas atividades, devem ser solicitados os esquemas e documentação das bases de dados, como modelos UML ou entidade-relacionamento, dicionário de dados, etc. (Brasil,2014, Chile,2013, Ecuador, 2014) [4, 5, 10].






Para uma documentação mais aprimorada, após as etapas de identificação e seleção dos conjuntos de dados, é necessário estabelecer as ontologias que serão utilizadas para modelar o domínio de uso destes conjuntos de dados. Nestes casos, orienta-se que seja reutilizado o maior número de vocabulários e outras ontologias, aproveitando o conhecimento produzido anteriormente. Esta abordagem baseada em reutilização acelera o desenvolvimento de ontologias, contribuindo para que os governos poupem tempo, esforço e recursos. O processo “Methodological Guidelines” descreve esta atividade nas seguintes tarefas (Villazon-Terrazas, 2011) [17]:

(i)     Devem ser procurados os vocabulários mais adequados para serem reutilizados em repositórios populares como o Schema Web[1], SchemaCache[2], Swoogle[3] e LOV[4]. Para esta escolha, este processo recomenda seguir um guia elaborado disponível em (Gómez-Pérez, 2009) [12] que explica como reusar vocabulários de diferentes níveis de granularidade, como ontologias gerais, ontologias de domínio, bem como declarações de ontologias;
(ii)    No caso de não se encontrar nenhum vocabulário apropriado para o propósito, o vocabulário deve ser criado, tentando reusar recursos de dados existentes (como outros vocabulários) sempre que possível. Para esta atividade, o autor recomenda os guias propostos em (Villazon-Terrazas, 2010) [18] que demonstra como: (1) procurar recursos de dados governamentais a partir de sites altamente confiáveis, sites relacionados com os domínios e catálogos de governo; (2) a seleção de recursos de dados governamentais mais adequadas; e (3) transformação destes vocabulários em ontologias;
(iii)    Finalmente, se você não encontrou nenhum vocabulário ou recursos para construção de ontologias, você deve fazê-lo a partir do zero. Para este propósito, devem ser utilizadas metodologias para o desenvolvimento de ontologias, como a NeOn Methodology e ferramentas que fornecem suporte tecnológico para essa atividade como o Protége[5], NeOn Toolkit[6], TopBraid Composer[7] e Altova SemanticWorks[8].

Daremos continuidade na apresentação de recomendações para a publicação de Dados Abertos Conectados nos próximos artigos desta série.

Até a próxima!!!

* Este artigo foi desenvolvido a partir da pesquisa de Mestrado “Uma Proposta de Modelo de Processo para Publicação de Dados Abertos Conectados Governamentais”, de autoria de Thiago José Tavares Ávila, no âmbito do Programa de Pós-Graduação em Modelagem Computacional do Conhecimento, do Instituto de Computação da Universidade Federal de Alagoas (UFAL).

Referências:
[1] ÁVILA, T. J. T. Uma proposta de modelo de processo para publicação de dados abertos conectados governamentais. 223 p. Dissertação (Mestrado) — Instituto de Computação, Universidade Federal de Alagoas, Maceió, Alagoas, Brasil, 2015. Dissertação de Mestrado em Modelagem Computacional do Conhecimento.
[2] BAUER, F.; KALTENBÖCK, M. Linked Open Data: The Essentials - A Quick Start
Guide for Decision Makers. Semantic Web Company, 2012. 59 p. ISBN 9783902796059. Disponível em: <http://www.semantic-web.at/LOD-TheEssentials.pdf>.
[3] BERNERS-LEE, T. Linked Data. 2006. Disponível em: <http://www.w3.org/
DesignIssues/LinkedData.html>.
[4] BRASIL. Manual para Elaboração de Plano de Dados Abertos. [S.l.], 2014. v. 7, 38 p. Disponível em: <http://www.planejamento.gov.br/secretarias/upload/Arquivos/governoáberto/manual_elaboracao_plano_dados_abertos.pdf>.
[5] CHILE. Norma Técnica para Publicación de Datos Abiertos en Chile.
[S.l.], 2013. 1-28 p. Disponível em: < http://instituciones.gobiernoabierto.cl/NormaTecnicaPublicacionDatosChile_v2-1.pdf>.
[6] COLOMBIA. Guía para la apertura de datos en Colombia. [S.l.], 2012. 67 p. Disponível em: < http://programa.gobiernoenlinea.gov.co/apc-aa-files/da4567033d075590cd3050598756222c/Datos_Abiertos_Guia_v2_0.pdf >.
[7] COMSODE. Methodology for publishing datasets as open data - COMSODE. [S.l.], 2014.1-31 p. Disponível em: <http://www.comsode.eu/index.php/deliverables/>.
[8] CONSOLI, S. et al. Geolinked Open Data for the Municipality of Catania. Proceedings of the 4th International Conference on Web Intelligence, Mining and Semantics (WIMS14), p. 58, 2014.
[9] DING, L. et al. TWC LOGD: A Portal for Linked Open Government Data Ecosystems. Journal of Web Semantics, Elsevier B.V., v. 9, n. 3, p. 325-333, 2011. ISSN 15708268.
[10] ECUADOR. Guia de Política Pública de Datos Abiertos. [S.l.], 2014. 21 p. Disponível em: <http://www.gobiernoelectronico.gob.ec/wp-content/uploads/2014/12/GPP-DA-v01-20141128-SNAP-SGE.pdf>.
[11] GALIOTOU, E.; FRAGKOU, P. Applying Linked Data Technologies to Greek Open Government Data: A Case Study. Procedia - Social and Behavioral Sciences, v. 73, p. 479-486, 2013. ISSN 18770428. Disponível em: <http://linkinghub.elsevier.com/
retrieve/pii/S187704281300373X>.
[12] GÓMEZ-PÉREZ, A.; SUÁREZ-FIGUEROA, M. C. NeOn Methodology for Building Ontology Networks: a Scenario-based Methodology. In: Proceedings of International Conference on Software, Services & Semantic Technologies. Sofia, Bulgaria: [s.n.], 2009. ISBN 978-954-9526-62-2.
[13] HYLAND, B.; WOOD, D. The Joy of Data - A Cookbook for Publishing Linked Government Data on the Web. In: . Linking Government Data. [S.l.: s.n.], 2011. p. 3-25.
[14] JANSSEN, M.; CHARALABIDIS, Y.; ZUIDERWIJK, A. Benefits, adoption barriers and myths of open data and open government. Information Systems Management, Taylor & Francis, v. 29, n. 4, p. 258-268, 2012.
[15] MENDONÇA, R. R. d. et al. LOP - Capturing and Linking Open Provenance on
LOD Cycle. In: Proceedings of the Fifth Workshop on Semantic Web Information
Management - SWIM '13. ACM Press, 2013. p. 1-8. Disponível em: <http://dl.acm.org/citation.cfm?id=2484712.2484715>.
[16] OKF. Guia de Dados Abertos. 2015. Disponível em: <http://opendatahandbook.org/guide/pt_BR>.
[17] VILLAZÓN-TERRAZAS, B. et al. Methodological guidelines for publishing government linked data. Linking Government Data, p. 27-49, 2011.
[18] VILLAZÓN-TERRAZAS, B.; SUÁREZ-FIGUEROA, M. C.; GÓMEZ-PÉREZ, A. A Pattern-Based Method for Re-Engineering Non-Ontological Resources into Ontologies. International Journal on Semantic Web and Information Systems (IJSWIS), v. 6, n. 4, p. 27-63, 2010.
[19] W3C. Best Practices for Publishing Linked Data. 2014. Acessado em 02/05/2017. Disponível em: <http://www.w3.org/TR/ld-bp/>.
[20] URUGUAY. Guía rápida de publicación em datos.gub.uy. Montevideo, 2012.
17 p. Disponível em: < https://www.agesic.gub.uy/innovaportal/file/2478/1/guia_publicacion_datos_abiertos.pdf>.





[1] Disponível em http://schemaweb.info
[2] Disponível em http://schemacache.com
[3] Disponível em http://swoogle.umbc.edu
[4] Linked Open Vocabularies - disponível em http://labs.mondeca.com/dataset/lov/index.html
[5] Disponível em http://protege.stanford.edu
[6] Disponível em http://www.neon-toolkit.org
[7] Disponível em http://www.topquadrant.com/products/TBComposer.html
[8] Disponível em http://www.altova.com/semanticworks.html.