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.
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.
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>.
[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.
Comentários
Postar um comentário