Pular para o conteúdo principal

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.


Voltar

Comentários