Estabelecer rotinas de convers˜ao de dados para formatos leg´ıveis por m´aquina (3C)

distintos e que fazem uso de tecnologias e formatos distintos, e ainda, que o volume de dados a serem publicados e mantidos costuma aumentar, outra recomenda¸c˜ao relevante consiste no estabelecimento de rotinas de convers˜ao de dados para v´arios formatos leg´ıveis por m´aquina. Os processos P1, P2, P3 e P4 buscam detalhar esta etapa (COLOMBIA, 2012; ECUADOR, 2014). Recomendam que, posteriormente `a modelagem, os dados sejam convertidos para formatos leg´ıveis por m´aquina, como o XML, CSV, TXT, JSON, KML ou RDF. Devem ser eliminados conte´udos que n˜ao sejam relevantes ao usu´ario, como t´ıtulos, subt´ıtulos e informa¸c˜oes extra dos arquivos. O P3 enfatiza que as rotinas de convers˜ao dos dados tamb´em contemplem a gera¸c˜ao de metadados que detalhem a estrutura¸c˜ao dos arquivos de dados.

4.2.6.4 Anonimizar dados sens´ıveis (3D)

Em que pese as pol´ıticas de dados abertos estimularem a publiciza¸c˜ao dos dados, este processo de abertura e publica¸c˜ao de dados deve ser feita com muita responsabilidade de maneira que n˜ao cause preju´ızos a indiv´ıduos e organiza¸c˜oes. Assim, a recomenda¸c˜ao de anonimiza¸c˜ao dos dados foi identificada como a t´ecnica a ser adotada para n˜ao expor dados privados/particulares no arcabou¸co de uma oferta de dados p´ublicos.

Janssen, Charalabidis e Zuiderwijk (2012) apresentam alguns motivos para que nem todos os dados sejam publicizados. Dentre eles, destacamos: (i) Dados podem permitir o rastreamento reverso chegando a identifica¸c˜ao de indiv´ıduos e resultando em viola¸c˜ao de privacidade e direitos individuais; (ii) A abertura de dados inconsistentes podem ge- rar mais “confus˜oes” do que benef´ıcios, pois os cidad˜aos podem n˜ao obter as respostas que desejam e ainda, gerar questionamentos desnecess´arios as agˆencias governamentais decorrentes de uma m´a interpreta¸c˜ao dos dados; (iii) As legisla¸c˜oes dos pa´ıses apresentam casos expl´ıcitos em que certos dados devem ser restritos; e (iv) Certos dados s˜ao estrat´e- gicos e necess´arios a pol´ıticas de competitividade (por exemplo, dados sobre prospec¸c˜ao de recursos minerais s˜ao essenciais para a sustentabilidade de pa´ıses e podem influenciar a disputa comercial e tecnol´ogica entre empresas p´ublicas que atuam neste setor).

A anonimiza¸c˜ao de dados ´e uma tarefa complexa, e se n˜ao for feita de forma eficaz, cria riscos a iniciativa de publica¸c˜ao de dados, especialmente por permitir a revela¸c˜ao de dados privados que n˜ao devem ser publicados. Apesar da importˆancia desta atividade, apenas os processos P4 e P14 apresentaram recomenda¸c˜oes e t´ecnicas a serem adotadas, detalhadas abaixo (COMSODE, 2014b):

• Proje¸c˜ao (projection): Ocorre quando atributos particulares com dados privados s˜ao removidos do conjunto de dados. Por exemplo, no caso de arquivos tabulares, isto pode ser implementado mediante a remo¸c˜ao de colunas.

• Agrega¸c˜ao (aggregation): Consiste na mesclagem de v´arios itens num ´unico dado es- tat´ıstico (por exemplo, a mesclagem de pessoas e suas idades numa regi˜ao, publicando- se apenas a idade m´edia das pessoas em cada regi˜ao).

• Remo¸c˜ao de conex˜oes (removing links): Providˆencia que deve ser adotada especial- mente quando se tratar de dados conectados, devendo ser analisado se as conex˜oes com outros dados revelam dados privados. Caso isto ocorra ´e necess´ario remover os links antes de publicar o conjunto de dados.

Cumpre destacar que a anonimiza¸c˜ao consiste de uma estrat´egia de mitiga¸c˜ao de riscos relacionados ao processo de publica¸c˜ao e caso for negligenciada, pode inviabilizar toda a estrat´egia de abertura decorrente dos impactos negativos da publica¸c˜ao de dados que n˜ao deveriam ser publicados.

4.2.6.5 Modelar rotinas automatizadas (ETL) (3E)

Al´em da oferta de dados em v´arios formatos, ´e recomendado que estas rotinas de publica¸c˜ao e manuten¸c˜ao dos dados sejam automatizadas, reduzindo o esfor¸co humano com esta atividade e ainda, ofertando maiores garantias de disponibilidade e atualiza¸c˜ao dos dados para os usu´arios. Para esta atividade, ser˜ao apresentadas as recomenda¸c˜oes de diversos processos com algum n´ıvel de detalhamento.

Para automatizar a publica¸c˜ao de dados, os processos P1, P5 e P14 recomendado o estabelecimento de rotinas de extra¸c˜ao, tratamento e carga (ETL). A publica¸c˜ao manual de dados deve ser estabelecida apenas para dados que n˜ao possuem atualiza¸c˜ao peri´odica. O processo P14 detalha t´opicos relevantes que devem ser estabelecidos na modela- gem 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 (2014b):

• 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 (SE-

LECT);

• Um componente que acessa um banco de dados RDF com consultas SPARQL (SE- LECT, CONSTRUCT).

Quanto aos transformadores estes podem ser:

– Um componente para transformar formatos propriet´arios 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 formatos de represen- ta¸c˜ao RDF. Em caso de XML, que pode ser baseada em scripts XSLT.

– Um componente para transformar representa¸c˜ao RDF usando a linguagem SPARQL.

• Ou ainda, componentes que transformem o conte´udo de um conjunto de dados aplicando t´ecnicas de higieniza¸c˜ao ou anonimiza¸c˜ao de dados;

• Bem como, componentes para enriquecimento de dados associando-os ao conte´udo de outros conte´udos de dados decorrente de conex˜oes pr´e-estabelecidas;

• Por fim, um transformador pode ser um componente de preenchimento automati- zado e manual de metadados em conjuntos de dados de acordo com um esquema (ou vocabul´ario) de dados pr´e-estabelecido.

Quanto aos carregadores, consistem da etapa final antes da publica¸c˜ao do dado. S˜ao componentes que garantem que o dado exportado da origem estar´a armazenado num servidor de dados com a qualidade e os formatos adequados para serem publicados. O processo estabelece as seguintes recomenda¸c˜oes para carregadores:

• Se o conjunto de dados estar´a dispon´ıvel apenas para usu´arios que far˜ao 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´arios via protocolos HTTP ou FTP. Tamb´em ´e poss´ıvel carregar os arquivos para um servidor Git, por exemplo, o Github.com. • Se o conjunto de dados estar´a dispon´ıvel atrav´es 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¸co REST que seja capaz de fornecer o acesso program´atico para os itens do conjunto de dados e retornar a representa¸c˜ao dos itens em formatos JSON, CSV, ou XML. Os dados devem ser armazenados numa base de dados relacional ou numa base de dados noSQL.

– 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 P1 ressalta que as rotinas automatizadas deve contemplar desde a extra¸c˜ao inicial dos dados a partir do seu ambiente de produ¸c˜ao at´e o local onde a base ser´a disponibilizada como dados abertos. Por exemplo, se tiver sido decidido publicar os dados em arquivos csv, essa etapa contempla a obten¸c˜ao dos dados, tratamento e hospedagem dos dados extra´ıdos ap´os convers˜ao para o formato csv em um servidor de arquivos para a Web BRASIL (2014c). O processo P3 recomenda, que preferencialmente, a origem dos dados das rotinas ETL sejam sistemas de informa¸c˜oes governamentais confi´aveis e estruturados (COLOMBIA, 2012).

O processo P6 apresenta as diversas ferramentas para minera¸c˜ao e modelagem de da- dos utilizadas num experimento. Por se tratar de uso de dados geoespaciais, se fizeram necess´arios softwares de manipula¸c˜ao de ontologias, conversores de dados de bancos rela- cionais para servidores de triplas RDF e sistemas de informa¸c˜oes geogr´aficas (CONSOLI et al., 2014). Este processo, apesar de pouco detalhado, destaca-se pela utiliza¸c˜ao de da- dos geoespaciais, cuja complexidade para abertura e publica¸c˜ao ´e maior. Ademais, toda a rotina ETL deve ser exaustivamente testada antes de entrar em produ¸c˜ao COMSODE (2014b).