dissertação de mestrado - repositorio.ufpe.br · referente ao domínio do orçamento. os dados...

PUBLICAÇÃO DE DADOS CONECTADOS SOBRE DESPESAS ORÇAMENTÁRIAS DO GOVERNO FEDERAL BRASILEIRO

por

Webber de Souza Fantini

Dissertação de Mestrado

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CIN - CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

[email protected] www.cin.ufpe.br/~posgraduacao

RECIFE 2015

mailto:[email protected]

UNIVERSIDADE FEDERAL DE PERNAMBUCO CIN - CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO [email protected]

www.cin.ufpe.br/~posgraduacao

PUBLICAÇÃO DE DADOS CONECTADOS SOBRE DESPESAS ORÇAMENTÁRIAS DO GOVERNO FEDERAL BRASILEIRO

Webber de Souza Fantini

Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Ciência da Computação, área de concentração em Banco de Dados, do Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

ORIENTADOR: Profo. Dra. Bernadette Lóscio Farias

RECIFE 2015

mailto:[email protected]

Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571

F216p Fantini, Webber de Souza Publicação de dados conectados sobre despesas

orçamentárias do governo federal brasileiro / Webber de Souza Fantini – Recife: O Autor, 2015.

154 f.: il., fig., tab. Orientador: Bernadette Farias Lóscio. Dissertação (Mestrado) – Universidade Federal de

Pernambuco. CIn, Ciência da Computação, 2015. Inclui referências e apêndice.

1. Banco de dados. 2. Web semântica. 3. Ontologia. I. Lóscio,

Bernadette Farias (orientadora). II. Título. 025.04 CDD (23. ed.) UFPE- MEI 2015-186

Dissertação de Mestrado apresentada por Webber de Souza Fantini à Pós-Graduação em

Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob

o título “PUBLICAÇÃO DE DADOS CONECTADOS SOBRE DESPESAS

ORÇAMENTÁRIAS DO GOVERNO FEDERAL BRASILEIRO” orientada pela Profa.

Bernadette Farias Lóscio e aprovada pela Banca Examinadora formada pelos professores:

______________________________________________

Profa. Ana Carolina Brandão Salgado

Centro de Informática/UFPE

______________________________________________

Profa.Damires Yluska de Souza Fernandes

Unidade Acadêmica de Informática / IFPB

_______________________________________________

Profa. Bernadette Farias Lóscio

Centro de Informática / UFPE

Visto e permitida a impressão.

Recife, 28 de agosto de 2015.

___________________________________________________

Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Dedicatória

Aos meus pais.

Agradecimentos

Primeiramente, agradeço a Deus.

Agradeço imensamente aos meus pais Roberto Fantini e Wena Lúcia pelo carinho, apoio,

por estarem ao meu lado em todos os momentos, pelos conselhos, por serem minha fortaleza.

Agradeço todos os dias a Deus por eles existirem.

Agradeço muito à minha irmã Wilne Fantini (Ninha) por ser minha melhor amiga, amada

e confidente, e por todo seu apoio e conselhos.

A toda minha família, Souza e Fantini, pela força, compreensão e por acreditarem em

mim, em especial minha avó, Cremilda, e meus tios Rui, Sérgio e Edite, e meus primos Serginho

e Rodrigo.

A uma pessoa linda em minha vida, minha namorada, Luana Possas (Lua), por me

proporcionar momentos felizes, por me dar força e apoio, por me ajudar nos momentos mais

difíceis. Espero que continue ao meu lado sempre. Agradeço também a Ana Melo, Ana Isabel,

Davi Possas, Carolina e Laís.

Toda a família Ponce, especialmente meu amigo e irmão Enrique Ponce pelo apoio.

Ao meu amigo Ticiano Figueiredo por toda força, compreensão e sólida amizade, como

também sua esposa e amiga Camilla.

Aos meus amigos do bairro, pela amizade, força e compreensão pelos momentos de

ausência, em especial Fábio Falcão.

A todos os colegas e amigos de pós-graduação que conheci e por quem construí uma

amizade. Um abraço para Myller Claudino, Sidartha Azevedo, Emanoel Carlos, Herbett Diniz,

Patrícia Vieira, Priscilla Vieira, Carla Cristina, Aline Chagas, Marcelo Iury entre outros. Em

especial, Bruno Iran Maciel, pela amizade e valiosas contribuições durante o desenvolvimento

do trabalho.

Aos meus amigos Ana Luiza, Rodrigo Lins, Marcello Mello, que contribuíram

indiretamente para este trabalho.

Aos Prof. Dr. Ricardo Amorim e Dinani Amorim pela força.

A Kellyton Brito, pelas conversas, pela força. Por ter contribuído para o meu

crescimento.

Um agradecimento muito especial a Luís Sérgio Araújo, um conterrâneo, que em pouco

tempo mostrou-se ser um amigo de verdade. Obrigado pela paciência, presteza e amizade. Pelas

contribuições e sugestões valiosas para a construção deste trabalho.

Ao Matheus Souza Fonseca por também ter me ajudado no desenvolvimento deste

trabalho com suas dicas valiosas.

A todos os professores da pós-graduação que contribuíram para meu crescimento, em

especial, aos professores Ana Carolina Salgado, Fernando Fonseca de Souza, Flávia de Almeida

Barros.

A todos os funcionários do Centro de Informática da Universidade Federal de

Pernambuco – Cin - UFPE.

Em especial à minha orientadora, Prof.a Dr.a. Bernadette Farias Lóscio, por todo seu

caráter, profissionalismo, paciência, e dedicação para comigo durante as diversas atividades de

pesquisa e andamento deste trabalho. O meu Muito Obrigado!

Aos integrantes da banca, Prof.a Dr.a Damires Yluska de Souza Fernandes e o Prof.a

Dr.a Ana Carolina Salgado, por se prestarem como avaliadores do trabalho. Meus sinceros

agradecimentos.

A todos que colaboraram direta ou indiretamente com este trabalho.

A todos pela compreensão da minha ausência, em vários momentos. Agradeço a todos

meus amigos que torceram por mim, para que eu concluísse com sucesso esse desafio.

Ósculos e Amplexos.

Resumo

Para transparência e fortalecimento da democracia, é de suma importância que a sociedade tenha

acesso às informações livremente. No controle social e na fiscalização do governo, o Orçamento

Público é um grande aliado que pode determinar quais ações (despesas) serão feitas pelo

Governo com os recursos originados de contribuições (receitas) da sociedade. A iniciativa de

disponibilização dos dados orçamentários em formato aberto foi concretizada, e para isso ser

realizado, utilizou-se uma ontologia do orçamento federal, denominada LOA, com o objetivo de

representar a classificação das despesas do orçamento. Ela possibilita discriminar e detalhar os

valores da despesa em categorias denominadas classificações orçamentárias de tal forma que é

possível identificar, por meio dessas classificações, em quais categorias se enquadra uma

determinada despesa. Porém, entre as informações nela descritas, não consta a identificação das

empresas ou pessoas e os respectivos pagamentos recebidos. Neste contexto, este trabalho realiza

uma extensão ao modelo ontológico do Orçamento Federal Brasileiro, de modo a apresentar

valores de execução orçamentária, discriminando os pagamentos efetuados, os respectivos

valores e os favorecidos – pessoas, empresas ou organizações. Esta expansão da ontologia

proposta neste trabalho permite uma representação do conhecimento dos dados de pagamentos

referente ao domínio do orçamento. Os dados disponibilizados pelo governo no Portal da

Transparência são convertidos para o formato RDF e conectados com os conjuntos de dados do

Portal de Dados Abertos do Governo Brasileiro. O novo conjunto de dados é publicado e

acessado em um terminal de consultas denominado endpoint, por meio da linguagem SPARQL,

visando dar suporte a um monitoramento público, para o planejamento e a execução do

orçamento. Como forma de avaliação, é construída uma aplicação como prova de conceito da

publicação dos dados conectados e, para avaliação da ontologia, são criadas Questões de

Competência (QCs) que permitem que a ontologia desenvolvida neste trabalho esteja de acordo

com os requisitos levantados, bem como com os conceitos referentes ao domínio orçamentário.

Palavras-chave: Orçamento Público. Transparência de Dados. Ontologia. Web Semântica.

Abstract

It is crucial that the society has open access to information easily in order to keep the

transparency and strength of democracy. The Public Budget is a great ally in social control and

government invigilation which can determine which actions (expenses) will be taken by the

Government with the income collected by taxes. An ontology of the Federal Budget, named

LOA, has been used to represent the classification of the budget expenses, since the budgetary

data has been provided. It allows the discrimination and detailing of the value of each expense in

categories, named budgetary classifications, in a way we can identify, through this classification,

in which category each expense falls into. The identification of the companies or people and the

respective payment they got, however, is not included in it. Having considered all these issues,

this work shows the results of an extension of the ontological model of the Brazilian Federal

Budget, in order to present the budget execution data, differentiating the payments finalized, its

respective values and who received them – people, companies or organizations. The ontology

expansion proposed in this work allows for the representation of budgetary data disclosure. The

data made available through the Portal de Transparência (transparency portal) is converted into

RDF format and connected to the data from the Portal de Dados Abertos do Governo Brasileiro

(Brazilian Government Open Data Portal). The new data set is published and accessed in a

consult terminal designated endpoint, through SPARQL language, aiming to maintain public

monitoring, throughout the planning and execution of the data. As an evaluation, an application

has been built to prove the concept of the publication of the connected data, and, to evaluate the

ontology, we designed Competence Questions (CQs) to allow the ontology to be in accordance

with the requirements raised in this work, as well as the concepts related to the budgetary

domain.

Keywords: Public Budget. Data transparency. Ontology. Semantic Web.

Lista de Figuras

FIGURA 1 - EVOLUÇÃO DA TRANSPARÊNCIA NAS CONTAS PÚBLICAS ............................................................................................ 14 FIGURA 2 - PROCESSO INTEGRADO DE PLANEJAMENTO E ORÇAMENTO ........................................................................................ 20 FIGURA 3 - ITEM DE DESPESA DA LOA DE 2013 .................................................................................................................... 24 FIGURA 4 - ARQUITETURA EM CAMADAS DA WEB SEMÂNTICA.. ................................................................................................ 34 FIGURA 5 - EXEMPLO DE UMA TRIPLA RDF. ........................................................................................................................... 36 FIGURA 6 - EXEMPLO DE UM GRAFO RDF. ............................................................................................................................ 37 FIGURA 7 - LOD CLOUD...................................................................................................................................................... 42 FIGURA 8 - ESQUEMA DE MATURIDADE DE PUBLICAÇÃO DE DADOS ABERTOS. ............................................................................... 43 FIGURA 9 - DIAGRAMA DA ONTOLOGIA DO GOVERNO UK. ....................................................................................................... 47 FIGURA 10 - PASSOS DA TÉCNICA DE TRADUÇÃO DAS QCS. ...................................................................................................... 56 FIGURA 11 - ITEM DE DESPESA. .......................................................................................................................................... 60 FIGURA 12 - DIAGRAMA DE CLASSES E PROPRIEDADES DA ONTOLOGIA DA LEI ORÇAMENTÁRIA ANUAL.. ........................................... 61 FIGURA 13 - RELAÇÃO DE ITEM DE DESPESA COM PAGAMENTOS............................................................................................... 63 FIGURA 14 - DIAGRAMA DE CLASSES E PROPRIEDADES DA ONTOLOGIA ONTOPAG. ....................................................................... 66 FIGURA 15 - ARQUITETURA DA APLICAÇÃO COP .................................................................................................................... 72 FIGURA 16 - CONJUNTOS DE DADOS PARA DOWNLOAD ........................................................................................................... 75 FIGURA 17 - EXTRAÇÃO E CARGA NA BASE DE DADOS .............................................................................................................. 78 FIGURA 18 - COMPONENTES DA ARQUITETURA DO FRAMEWORK D2RQ. .................................................................................... 80 FIGURA 19 - MAPEAMENTO DA CLASSE FAVORECIDO ............................................................................................................. 82 FIGURA 20 - MAPEAMENTO DA CLASSE PAGAMENTO. ............................................................................................................ 83 FIGURA 21 - PARÂMETROS DE CONEXÃO UTILIZADOS PELO ARQUIVO DE MAPEAMENTO. ................................................................ 84 FIGURA 22 - ARQUIVO RDF (FORMATO TURTLE) GERADO ....................................................................................................... 86 FIGURA 23 - EXEMPLO DE CONSULTA SPARQL – SOMATÓRIO PAGAMENTO 2014 ...................................................................... 90 FIGURA 24 - RESULTADO DA CONSULTA – SOMATÓRIO PAGAMENTO 2014 ................................................................................ 90 FIGURA 25 - EXEMPLO DE CONSULTA SPARQL – PAGAMENTOS PÚBLICOS/SIGILOSOS ................................................................. 91 FIGURA 26 - RESULTADO DA CONSULTA – PAGAMENTOS PÚBLICOS/SIGILOSOS ............................................................................ 91 FIGURA 27 - EXEMPLO DE CONSULTA SPARQL – VALORES ESFERA ........................................................................................... 92 FIGURA 28 - RESULTADO DA CONSULTA CONECTADA .............................................................................................................. 92 FIGURA 29 – RESULTADO DA CONSULTA 1 .......................................................................................................................... 103 FIGURA 30 - RESULTADO DA CONSULTA 2 .......................................................................................................................... 103 FIGURA 31 - RESULTADO DA CONSULTA 3 .......................................................................................................................... 104 FIGURA 32 - RESULTADO DA CONSULTA 4 .......................................................................................................................... 105 FIGURA 33 - RESULTADO DA CONSULTA 5 .......................................................................................................................... 106 FIGURA 34 - RESULTADO DA CONSULTA 6 .......................................................................................................................... 107 FIGURA 35 - RESULTADO DA CONSULTA 7 .......................................................................................................................... 109 FIGURA 36 - RESULTADO DA CONSULTA 8 .......................................................................................................................... 110 FIGURA 37 - RESULTADO DA CONSULTA 9 .......................................................................................................................... 111 FIGURA 38 - RESULTADO DA CONSULTA 10 ........................................................................................................................ 112

Lista de Tabelas

TABELA 1 - CATEGORIAS DE USO DE ONTOLOGIAS PARA A ÁREA DA CIÊNCIA DA COMPUTAÇÃO. ....................................................... 28 TABELA 2 - EXEMPLOS DE CONSTRUTORES EM RDF/RDFS ....................................................................................................... 37 TABELA 3 - TIPOS DE LIGUAGEM OWL. ................................................................................................................................ 40 TABELA 4 - TRABALHOS RELACIONADOS ............................................................................................................................... 49 TABELA 5 - TABELA DE VALORES DAS QCS ............................................................................................................................ 58 TABELA 6 - PROPRIEDADES DE OBJETO DA ONTOLOGIA ONTOPAG ............................................................................................. 68 TABELA 7 - PROPRIEDADES DE DADOS DA ONTOLOGIA ONTOPAG .............................................................................................. 69 TABELA 8 - EXEMPLO DE N-TRIPLES ..................................................................................................................................... 87 TABELA 9 - TABELA DE QCS ............................................................................................................................................... 96 TABELA 10 - TABELA DAS RESPOSTAS ESPERADAS DAS QCS ...................................................................................................... 97 TABELA 11 - TABELA DAS ENTIDADES EXTRAÍDAS DAS QCS E SUAS RESPOSTAS ............................................................................. 98 TABELA 12 – TABELA COM ENTIDADES E SUA LOCALIZAÇÃO NA ONTOLOGIA ................................................................................. 99 TABELA 13 - CONSULTA 1 ................................................................................................................................................ 102 TABELA 14 - CONSULTA 2 ................................................................................................................................................ 103 TABELA 15 - CONSULTA 3 ................................................................................................................................................ 104 TABELA 16 - CONSULTA 4 ................................................................................................................................................ 105 TABELA 17 - CONSULTA 5 ................................................................................................................................................ 106 TABELA 18 - CONSULTA 6 ................................................................................................................................................ 107 TABELA 19 - CONSULTA 7 ................................................................................................................................................ 108 TABELA 20 - CONSULTA 8 ................................................................................................................................................ 109 TABELA 21 - CONSULTA 9 ................................................................................................................................................ 110 TABELA 22 - CONSULTA 10.............................................................................................................................................. 111 TABELA 23 - TABELA DE VALORES DAS QCS DE ACORDO COM A RESPOSTA DAS CONSULTAS SPARQL ............................................. 112

Sumário

1 INTRODUÇÃO .............................................................................................................................................. 12

1.1 MOTIVAÇÃO ..................................................................................................................................................... 13 1.2 CARACTERIZAÇÃO DO PROBLEMA .......................................................................................................................... 15 1.3 OBJETIVOS ....................................................................................................................................................... 17

1.3.1 Objetivo Geral ..................................................................................................................................... 17 1.3.2 Objetivos Específicos ........................................................................................................................... 17

1.4 CONTRIBUIÇÕES ................................................................................................................................................ 17 1.5 ORGANIZAÇÃO DA DISSERTAÇÃO ........................................................................................................................... 18

2 FUNDAMENTAÇÃO TEÓRICA ....................................................................................................................... 19

2.1 ORÇAMENTO PÚBLICO ........................................................................................................................................ 20 2.1.1 Classificação Orçamentária ................................................................................................................. 21

2.2 DADOS GOVERNAMENTAIS ABERTOS ..................................................................................................................... 25 2.3 ONTOLOGIAS .................................................................................................................................................... 28

2.3.1 Metodologias para construção de ontologias ..................................................................................... 29 2.4 PADRÕES DA WEB SEMÂNTICA ............................................................................................................................. 34

2.4.1 RDF ...................................................................................................................................................... 36 2.4.2 SPARQL ................................................................................................................................................ 38 2.4.3 OWL ..................................................................................................................................................... 38

2.5 LINKED DATA .................................................................................................................................................... 41 2.6 TRABALHOS RELACIONADOS ................................................................................................................................. 44 2.7 CONSIDERAÇÕES ................................................................................................................................................ 49

3 PROCESSO DE DESENVOLVIMENTO DA ONTOLOGIA ONTOPAG .................................................................. 51

3.1 INTRODUÇÃO .................................................................................................................................................... 52 3.2 DESENVOLVIMENTO DA ONTOLOGIA ONTOPAG ....................................................................................................... 53

3.2.1 Modelo Ontológico das Classificações da Despesa - LOA.................................................................... 59 3.2.2 A Ontologia OntoPag .......................................................................................................................... 63

3.3 CONSIDERAÇÕES ................................................................................................................................................ 69

4 COP: APLICAÇÃO PARA CONECTAR E PUBLICAR DADOS ORÇAMENTÁRIOS ................................................. 70

4.1 ARQUITETURA DA APLICAÇÃO COP ....................................................................................................................... 71 4.1.1 Fontes de Dados de Origem ................................................................................................................ 73 4.1.2 Extração, Transformação e Carga dos Dados ..................................................................................... 76 4.1.3 Mapeamento ....................................................................................................................................... 78 4.1.4 Triplificação ......................................................................................................................................... 84 4.1.5 Publicação e Acesso aos Dados ........................................................................................................... 88

4.2 CONSIDERAÇÕES ................................................................................................................................................ 93

5 AVALIAÇÃO DA ONTOLOGIA ONTOPAG ...................................................................................................... 94

5.1 AVALIAÇÃO DA ONTOLOGIA ONTOPAG .................................................................................................................. 95 5.2 CONSIDERAÇÕES .............................................................................................................................................. 114

6 CONCLUSÕES E TRABALHOS FUTUROS ...................................................................................................... 115

6.1 CONCLUSÕES .................................................................................................................................................. 116 6.2 TRABALHOS FUTUROS ....................................................................................................................................... 117

REFERÊNCIAS...................................................................................................................................................... 118

APÊNDICES ......................................................................................................................................................... 125

APÊNDICE A .......................................................................................................................................................... 126 APÊNDICE B .......................................................................................................................................................... 135 APÊNDICE C .......................................................................................................................................................... 145 APÊNDICE D .......................................................................................................................................................... 154

Capítulo 1 – Introdução

12

Capítulo

1 1 Introdução

Este capítulo descreve a introdução deste trabalho, bem como a motivação, a

questão de pesquisa e os objetivos do trabalho. Por fim, é apresentada a estrutura desta

dissertação em capítulos.


13

1.1 Motivação

O governo federal brasileiro movimenta, anualmente, um enorme montante em recursos

financeiros. São recursos provenientes de impostos, contribuições, financiamentos destinados ao

pagamento de bens e serviços para o Estado, bem como transferências para entes e pessoas

físicas. O valor total anual estimado gira em torno de 37% do Produto Interno Bruto – PIB,

incluindo união, estados e municípios1.

A movimentação dos recursos financeiros segue um princípio básico de finanças

públicas, segundo o qual nenhuma despesa pode ser realizada sem autorização legislativa. Esta

autorização é realizada pelo orçamento público, que especifica e descreve todas as despesas e

receitas da entidade pública para o período de um ano, conhecido também como ano fiscal

(GIAMBIAGI, 2008). Desta maneira, é de grande importância para a sociedade e poder público

estimular ações e fortalecer a transparência juntamente como o livre acesso às informações de

interesse coletivo.

O interesse por uma gestão pública mais transparente deu início a esforços em nível

global, atraindo atenção de governos e nações em geral. Por exemplo, os Estados Unidos (EUA)

foram uma das nações pioneiras em firmar acordo no sentido de aumentar a transparência da

gestão pública, fortalecendo também o poder de fiscalização da sociedade. O principal interesse

das medidas adotadas para melhorar a transparência consiste basicamente em um compromisso

da administração em garantir a confiança pública e estabelecer um sistema de transparência,

participação da sociedade e colaboração (OBAMA, 2014).

Em vista das influências e tendências internacionais, o governo brasileiro adotou um

conjunto de medidas no sentido de fortalecer a transparência da gestão pública. Em 2011, uma

das principais contribuições foi a Lei de Acesso à Informação2

(LAI) - Lei 12.527, que define a

publicidade como princípio geral para assegurar aos cidadãos o direito de acesso à informação de

interesse público e o sigilo como exceção. As medidas, em geral, são possíveis graças ao avanço

das Tecnologias da Informação e Comunicação (TIC), capazes de viabilizar a implantação e uso

de ferramentas por parte da sociedade em geral.

A legislação brasileira recomenda o uso da Web como meio de divulgação para diversas

áreas como, por exemplo, a orçamentária. Segundo Craveiro et al. (2013), a Organização para a

Cooperação Econômica e Desenvolvimento, o Fundo Monetário Internacional (FMI) e a

Federação Internacional de Contabilistas, além de sugerirem ações que se traduzem em boas

1 http://www.ibge.gov.br/

2http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12527.htm


14

práticas, também apontaram o uso da Web como um meio de comunicação com o potencial de

fornecer informações de forma oportuna e transparente para os diversos atores sociais.

A publicação de dados governamentais na Web contribui para o desenvolvimento de

iniciativas de ordem da sociedade. O uso dos conjuntos de dados disponibilizados viabiliza a

descoberta de informações e conhecimento em geral. Um dos grandes benefícios do uso dos

dados abertos disponibilizados na Web está na capacidade de combiná-los, possibilitando o

cruzamento de dados e a geração de novos conjuntos de dados.

Este trabalho tem interesse particular nos dados relevantes ao orçamento público, pois é

de grande importância para o poder público e para a sociedade acompanhar e fiscalizar os

recursos financeiros administrados pelo governo, como os recursos usados para manutenção de

serviços como saúde, educação, transporte e demais áreas.

Na Figura 1, são apresentados de maneira cronológica fatos relacionados à evolução da

transparência nas contas públicas de acordo com Corrêa (2010):

Figura 1 - Evolução da transparência nas contas públicas

O progresso da legislação brasileira sobre orçamento público proporcionou uma melhor

forma de controle social, inclusive os órgãos públicos devem disponibilizar em tempo real

informações detalhadas do orçamento em meios eletrônicos de acesso público (Brasil, 2009).

As consultas aos dados do orçamento público, bem como os pagamentos efetuados com

recursos do Orçamento Federal Brasileiro, podem ser feitas por meio de alguns portais/sistemas

orçamentários. Algumas das soluções são: (i) Sistema Integrado de Administração Financeira do

Governo Federal – SIAFI; (ii) Sistema de Informações sobre o Orçamento Público – SIGA

Brasil3; e (iii) Portal da Transparência

4. No entanto, os dados que estão nesses portais são de

difícil acesso e manipulação, já que não estão disponibilizados em notação que permita

3 http://www12.senado.gov.br/orcamento/sigabrasil

4 http://www.portaldatransparencia.gov.br/


15

expressividade dos dados, assim como liberdade de acesso, edição e compartilhamento,

dificultando a integração com outros conjuntos de dados. A seguir, será caracterizado o problema

de pesquisa.

1.2 Caracterização do Problema

O orçamento contém informações sobre as autorizações para gastos com suas

classificações (quanto para cada órgão, finalidade, entre outros) e valores (quanto foi orçado,

quanto foi empenhado, quanto foi pago). Mesmo tratando-se de objetos relacionados, essas bases

de dados não estão conectadas. Com os dados do orçamento, por exemplo, é possível identificar

quanto foi pago em um programa de governo por um determinado órgão, mas não é possível

saber, do valor pago, quais foram as empresas ou organizações que receberam o dinheiro. Essas

informações só poderão ser encontradas em outras bases de dados como uma base sobre

pagamentos.

O setor orçamentário e financeiro do governo federal apresenta uma série de

características interessantes como estudo de caso de Linked Data na Web. Em primeiro lugar, os

dados orçamentários e financeiros são públicos. Um dos princípios básicos do orçamento

público é a publicidade. No entanto, o grande volume de dados e suas complexas formas de

apresentação tornam esses dados quase impossíveis de serem tratados e compreendidos pelos

cidadãos. Para conjuntos de dados com esse grau de complexidade, torna-se necessário algum

instrumento de organização como sistemas gerenciadores de bancos de dados, que permitam

consultas estruturadas e seletivas. Tais instrumentos, contudo, não são disponibilizados pelos

órgãos públicos.

O orçamento federal é publicado em formato PDF, totalizando em torno de 3.000

páginas. Esse problema foi amplamente diminuído com a publicação dos dados do orçamento

federal em RDF, que avançou significativamente ao disponibilizar seus dados na Web com alto

nível de expressividade. Para alcançar uma melhor expressividade semântica dos dados, utilizou-

se a ontologia5, denominada LOA (ARAÚJO e CRUZ, 2012), resultado de um projeto do acordo

de cooperação técnica entre a Secretaria de Orçamento Federal do Ministério do Planejamento,

Orçamento e Gestão – SOF/MP6 e a Universidade de Brasília

7, para expressar sem ambiguidades

as categorias em que são classificadas as despesas do orçamento. Os conjuntos de dados do

orçamento público de 2000 a 2015 estão disponibilizados em formato RDF, padrão recomendado

5 http://vocab.e.gov.br/2013/09/loa

6 http://www.orcamentofederal.gov.br/

7 http://www.unb.br/


16

pelo W3C (World Wide Web Consortium) para descrição de recursos na Web, possibilitando à

sociedade o acesso irrestrito e tempestivo às informações, até então, impossíveis de serem

obtidas.

No entanto, os dados da base de dados do orçamento não respondem a todas as perguntas

dos interessados nos gastos públicos. O orçamento público é um plano previamente preparado

com estimativas agregadas de gastos, classificados em categorias denominadas classificações. O

principal objetivo do orçamento é conferir autorização aos órgãos públicos para realizarem os

gastos durante o período de um ano. Portanto, uma rubrica orçamentária, também chamada de

dotação orçamentária especifica um determinado volume de recursos financeiros a serem gastos

em um período de um ano. O orçamento não especifica em que data e qual a empresa ou

organização que será contratada para atender a determinada demanda do setor público. Esta

informação é registrada no Sistema de Contabilidade do Governo Federal – SIAFI, porém não

faz parte da base de dados do orçamento. A base de dados do orçamento disponibiliza a soma

dos valores pagos em cada rubrica orçamentária sem, contudo, indicar os pagamentos

individualmente.

No entanto, as infomações sobre os pagamentos são amplamente demandadas, tanto pela

população em geral como também pelos próprios agentes públicos, a maioria dos quais não tem

acesso irrestrito às bases de dados oficiais. Além disso, as informações orçamentárias de cada

pagamento são importantes, uma vez que é o orçamento que traz o contexto mais amplo da

despesa. É no orçamento que pode ser identificada a responsabilização pelo gasto (a unidade

administrativa), o objeto do gasto (despesa de pessoal, aquisição de material de consumo), o

impacto econômico do gasto (despesa corrente ou de capital) e muitas outras.

Pode-se dizer que a informação sobre os pagamentos complementa a informação do

orçamento, de forma que o ciclo do gasto público, que se inicia no orçamento, é concluído na

fase do pagamento.

A disponibilização da informação de pagamento em RDF, por si só, já traz um grande

benefício social. No exercício de 2014, foram registrados 14.741.885 de pagamentos. Cada

pagamento identificado com CPF ou CNPJ, nome do favorecido, data do pagamento, valor pago,

categorias orçamentárias relacionadas e outros detalhes.

Dado o contexto e relevância dos dados orçamentários, este trabalho é motivado por meio

do desafio de conectar computacionalmente dados orçamentários, de tal maneira que seja

possível identificar favorecidos e valores dos recursos envolvidos, o que não é possível com

as informações disponíveis hoje. Considerando que as despesas públicas consistem em um

ciclo que se inicia com a aprovação do orçamento e é concluído com pagamentos para alguma


17

pessoa ou entidade, verificou-se esta etapa como uma das mais importantes para manutenção da

civilidade e fiscalização por parte da sociedade em geral.

Sendo assim, a partir do problema de pesquisa foi formulada a seguinte questão de

pesquisa: Como possibilitar que os dados sobre os pagamentos efetuados com recursos do

Orçamento Público Federal sejam conectados aos dados de despesas, publicados em

formato RDF, de forma a permitir consultas que ofereçam uma visão integrada sobre

dados distribuídos nestes dois repositórios?

1.3 Objetivos

Para responder à pergunta de pesquisa, foram definidos os seguintes objetivos, divididos

em geral e específicos:

1.3.1 Objetivo Geral

Este trabalho tem como objetivo geral propor uma solução para geração de dados

conectados sobre o Orçamento Público Federal, incluindo dados sobre Pagamentos. A solução

proposta faz uso de ontologias para descrição do domínio orçamentário e dos princípios de

Linked Data para a geração dos dados conectados.

1.3.2 Objetivos Específicos

Estender a ontologia de domínio do Orçamento Público Federal (LOA), a fim de permitir

a representação de dados relativos a pagamentos;

Especificar uma aplicação para facilitar a conexão dos dados de orçamento público com

os dados de pagamentos e os respectivos favorecidos;

Desenvolver uma aplicação para geração e manipulação dos dados conectados sobre o

Orçamento Público Federal;

Avaliar a ontologia para representação dos dados de pagamentos por meio de questões de

competência.

1.4 Contribuições

Este trabalho apresenta, portanto, alternativas que possam ajudar o cidadão e poder

público na tarefa de fiscalização dos recursos de origem do governo federal brasileiro. A


18

possibilidade de vincular os favorecidos com os valores gastos contribui para a fiscalização dos

recursos repassados.

A proposta apresentada serve de ponto de partida para o desenvolvimento de aplicações

que façam a publicação e vinculação dos diversos dados provenientes do governo federal

brasileiro. O público-alvo é composto por cidadãos que conhecem seus direitos e contribuem

ativamente na fiscalização da gestão pública.

Este trabalho tem como principais contribuições:

Apresentação de um estudo abrangente dos temas Dados Abertos Governamentais, Web

Semântica e Modelo Orçamentário, de modo a facilitar o desenvolvimento de futuros

trabalhos dentro desses tópicos;

Extensão do modelo ontológico da classificação das despesas do Orçamento Público

Federal Brasileiro e desenvolvimento da ontologia OntoPag, a qual permite a

representação de dados orçamentários relativos a pagamentos;

Desenvolvimento de uma aplicação que permite a geração e manipulação dos dados

conectados do Orçamento Público Federal Brasileiro, incluindo dados relativos a

despesas e dados de pagamentos (favorecidos e valores pagos).

1.5 Organização da dissertação

Além deste capítulo, esta dissertação está organizada da seguinte forma: no Capítulo 2, é

apresentada a Fundamentação Teórica referente aos conceitos básicos para o entendimento deste

trabalho. No Capítulo 3, é apresentado a ontologia de orçamento público federal e o

desenvolvimento da ontologia de pagamentos. No Capítulo 4, é detalhada a aplicação, bem como

a implementação da proposta para conectar os dados de orçamento público. No Capitulo 5, é

descrito o processo de avaliação da ontologia OntoPag. Por fim, no Capítulo 6, é apresentada

uma conclusão do trabalho e os trabalhos futuros.

Capítulo 2 – Fundamentação Teórica

19

Capítulo

2 2 Fundamentação Teórica

Este capítulo tem como objetivo apresentar os principais conceitos dos temas

relacionados com este trabalho, bem como os trabalhos relacionados com esta pesquisa.


20

2.1 Orçamento Público

Parte das informações do orçamento público que devem ser disponibilizadas para a

sociedade é definida durante o planejamento do orçamento que acontece no ano anterior à sua

execução. Nesta seção, são apresentados os principais aspectos do Orçamento Público.

O Orçamento Público consiste em um instrumento de planejamento e execução para as

finanças públicas. Nele, são estimadas as receitas e fixadas as despesas orçamentárias que serão

realizadas durante o exercício correspondente.

De acordo com o Manual Técnico do Orçamento 2015 (MTO), o planejamento

orçamentário brasileiro baseia-se na elaboração e execução de 3 (três) leis – o Plano Plurianual

(PPA), a Lei de Diretrizes Orçamentárias (LDO) e na Lei de Orçamentos Anuais (LOA) – que,

em conjunto, colocam em prática o planejamento e a execução das políticas públicas. O PPA

consiste no planejamento de um período de quatro anos, nos quais nenhuma despesa que

ultrapasse um exercício poderá ocorrer sem ter sido nele incluída. A LDO tem como principal

finalidade orientar a elaboração dos orçamentos fiscais e da seguridade social e de investimento

do Poder Público. A LOA, por sua vez, é o orçamento propriamente dito, contendo as previsões

de receitas e fixação das despesas que serão executadas no exercício correspondente (MTO,

2015).

Para Giacomoni (2009), a integração do PPA e a LOA ficam bem explicitadas pelo papel

cumprido pela LDO, pois, além de a Lei de Diretrizes Orçamentárias fornecer orientação para a

elaboração dos orçamentos anuais, ela também destaca, da programação plurianual, as

prioridades e metas a serem cumpridas em cada LOA.

Na Figura 2, temos um resumo do processo integrado de planejamento e orçamento.

Figura 2 - Processo integrado de planejamento e orçamento. Fonte: (Giacomoni, 2009).


21

A fim de conferir racionalidade, eficiência e transparência aos processos de elaboração,

execução e controle do orçamento público (MTO, 2015), foram estabelecidos os seguintes

princípios orçamentários (Brasil, 1964) (Brasil, 1988):

Unidade ou Totalidade: cada ente governamental deve elaborar uma única LOA;

Universalidade: a LOA de cada ente federado deve conter todas as receitas e despesas

de todos os Poderes, órgãos, entidades, fundos e fundações instituídas e mantidas pelo

poder público;

Anualidade ou Periodicidade: o exercício financeiro coincide com o ano civil (1º de

janeiro a 31 de dezembro) e corresponde ao período de tempo ao qual se referem à

previsão das receitas e fixação das despesas documentadas na LOA;

Exclusividade: a LOA não conterá nada além da previsão das receitas e fixação das

despesas;

Orçamento Bruto: o registro das receitas e despesas deve ser feito com seu valor total

e bruto, sem quaisquer deduções;

Não Vinculação da Receita de Impostos: é vedada a vinculação de receitas de

impostos a órgão, fundo ou despesa, salvo exceções estabelecidas pela CF.

2.1.1 Classificação Orçamentária

Há 2 (dois) tipos de classificação orçamentária: as Receitas e as Despesas. Porém, para

este trabalho, apenas será abordada a classificação orçamentária Despesa.

Despesas

Com a finalidade de permitir um melhor detalhamento dos gastos públicos (Slomski,

2008), a despesa orçamentária possui uma classificação estruturada, subdividida em

Programação Qualitativa e Programação Quantitativa.

Segundo o MTO (2015), a Programação Qualitativa é composta pelas seguintes

características:

a. Esfera: informa sobre a qual orçamento pertence a despesa. O orçamento pode ser:

Fiscal, da Seguridade Social ou de Investimento;


22

b. Classificação Institucional: fornece a informação sobre qual órgão e unidade

orçamentária realiza a despesa. É definida por um código de cinco dígitos, dos quais

os dois primeiros representam o órgão e o restante, a unidade orçamentária;

c. Classificação Funcional: dividida em função e subfunção, essa classificação

responde à indagação “em que” área de ação aquela despesa será realizada. É

definida por um código de cinco dígitos, os dois primeiros representam a função, o

restante, a subfunção;

d. Classificação Programática: toda ação do governo está estruturada em programas

orientados para atingir o objetivo do período correspondente ao PPA. Os programas

podem ser temáticos ou de gestão, manutenção e serviços ao Estado. São

identificados por um código de quatro dígitos e contêm uma ou mais ações. As ações

são operações das quais resultam produtos que contribuem para o objetivo de um

programa. Cada ação é identificada por um código alfanumérico de oito dígitos. O

primeiro dígito identifica o tipo da ação, podendo ser um projeto, uma atividade ou

uma operação especial. Do segundo ao quarto, é detalhada a ação. Os quatro últimos

identificam o subtítulo da ação. Estes são utilizados especialmente para descrever a

localização da ação.

A Programação Quantitativa define a programação física, ou seja, quanto será

desenvolvido e também a programação financeira, que determina o que adquirir e com quais

recursos. Essas informações quantitativas estão definidas nos seguintes blocos:

a. Metafísica da Ação: define, em nível de subtítulo, a quantidade do produto que será

ofertada em uma determinada ação;

b. Natureza da Despesa: semelhante à natureza da receita, também é definida por um

código numérico de oito dígitos, porém, subdivididos em cinco níveis: categoria

econômica (1º dígito), grupo de natureza da despesa (GND) (2º dígito), modalidade

da aplicação (3º e 4º dígitos), elemento de despesa (5º e 6º dígitos) e subelemento (7º

e 8º dígitos);

c. Identificador de Uso (IDUSO): destina-se a indicar se os recursos compõem

contrapartida nacional de empréstimos ou de doações ou destinam-se a outras

aplicações;

d. Identificador de Doação e de Operação de Crédito (IDOC): identifica as doações de

entidades internacionais ou operações de crédito contratuais;

e. Identificador de Resultado Primário: tem como finalidade auxiliar a apuração do

resultado primário previsto na LDO.


23

O autor Sanches (2004) descreve que as despesas públicas no orçamento brasileiro,

segundo a estrutura técnico-jurídica vigente, são executadas em quatro estágios/etapas distintas,

são elas: fixação ou planejamento, empenho, liquidação e pagamento.

A etapa de fixação ou planejamento da despesa pode ser definida como a materialização

pela publicação da Lei Orçamentária Anual ou do ato de abertura do crédito adicional

(SANCHES, 2004).

O estágio empenho, segundo a Lei nº 4.320, define que “é o ato emanado de autoridade

competente que cria para o Estado obrigação de pagamento pendente ou não de implemento de

condição” (Brasil, 1964).

A etapa de liquidação consiste na verificação do direito adquirido pelo credor, tendo por

base os títulos e documentos comprobatórios do respectivo crédito, e tem por objetivo apurar a

regularidade do objeto, a importância e a quem se deve o pagamento (Brasil, 1964).

O estágio final, o pagamento, é constituído pela formalização do despacho do ordenador

de despesa, autorizando-o, e, pela entrega de numerário ao credor por meio de cheque

nominativo, ordens de pagamentos ou crédito em conta. Esta etapa só poderá ser efetuada após a

etapa de liquidação da despesa (SANCHES, 2004).

A elaboração da Lei Orçamentária Anual e as alterações concretizadas ao longo do

exercício são realizadas no Sistema Integrado de Planejamento e Orçamento – SIOP. O Sistema

Integrado de Administração Financeira – SIAFI contabiliza os valores orçados, bem como as

operações e os registros relacionados a cada etapa da execução da despesa. O SIOP atualiza o

SIAFI com as informações das dotações vigentes na Lei Orçamentária Anual (Brasil, 2012).

Ao longo do exercício financeiro, cada rubrica é anotada para permitir a verificação de

quanto foi orçado (dotação inicial; etapa de fixação ou planejamento), quanto foi empenhado

(empenho), quanto foi liquidado (liquidação) e quanto foi pago efetivamente (pagamento).

De acordo com ARAÚJO e CRUZ et al. (2012),

[...] a base para a compreensão do orçamento público é o

sistema de classificação. É por meio desse sistema que o

orçamento é organizado, ou seja, segmentado com base em

critérios. Essa estrutura permite que os técnicos e gestores

públicos consigam estratificar os dados e estabelecer as relações

entre os valores financeiros do orçamento e os fenômenos da

administração pública associados (ex. gasto em quê, para quê,

sob a responsabilidade de quem).


24

A Figura 3 apresenta um exemplo de estrutura de despesa em que é possível considerar

um item de despesa da LOA de 2013 com os seus respectivos atributos qualitativos e

quantitativos.

Figura 3 - Item de Despesa da LOA de 2013. Fonte: (Brasil, 2012).

A execução orçamentária tem uma estrutura composta fundamentalmente dos mesmos

elementos existentes na estrutura de classificações utilizada na elaboração do orçamento, ou seja,

de uma lista de itens de despesa com seus respectivos valores. Deste modo, cada item é

representado por um código de 44 dígitos que os vinculam aos critérios de classificação da

despesa. No Manual Técnico do Orçamento 2015 – MTO podem ser encontrados o significado

de cada critério de classificação e os códigos correspondentes (MTO, 2015).


25

2.2 Dados Governamentais Abertos

Segundo a Open Definition8: “dado aberto é um dado que pode ser livremente utilizado,

reutilizado e redistribuído por qualquer um”. Essa definição ainda contém alguns pontos

importantes:

Disponibilidade e acesso: o dado necessita estar disponível, de preferência por

meio de download na Web, por inteiro e um custo acessível; bem como deve estar

num formato conveniente e modificável;

Reúso e redistribuição: o dado precisa ser fornecido em condições de

reutilização e redistribuição, e que permita o cruzamento com outros conjuntos de

dados;

Participação universal: todos podem utilizar, reutilizar e redistribuir, não

havendo discriminação contra áreas de atuação, pessoas ou grupos;

Dados Abertos, em especial os governamentais, possuem grande potencial econômico e

social, porém ainda pouco explorado. Tanto as organizações quanto os indivíduos coletam uma

infinidade de diferentes tipos de dados para executar suas tarefas. O governo tem um papel

importante nesse contexto, tanto pela quantidade dos dados que coleta como pelo princípio de

que esses tais dados são de finalidade pública.

Governo Aberto é um recente movimento para uma maior abertura e transparência no

governo e dados abertos são uma parte importante dessa grande tendência. O setor

governamental produz enorme quantidade de informação, como parte de suas operações diárias,

que abragem diversas áreas como economia, turismo, saúde, entre outras, que são importantes,

com um cunho do benefício desse movimento para vários grupos de indivíduos e organizações,

inclusive o próprio governo (MAALI et al. 2010).

Costumeiramente, os termos Governo Aberto e Dados Governamentais Abertos são

tratados como sinônimos, porém, Governo Aberto é um conceito mais amplo. Significa a

disponibilização de todas as informações (em qualquer formato), que estejam sob a

responsabilidade de um governo. Isto não implica, necessariamente, a utilização da tecnologia

da informação ou formatos pré-estabelecidos (LINKEDDATABOOK, 2011).

Há um grande número de iniciativas em que os dados abertos estão gerando grande valor,

e pode existir potencial para muito mais. São citados alguns exemplos como: transparência e

controle democrático; participação popular; empoderamento dos cidadãos; inovação; melhores

ou novos produtos e serviços privados; medição do impacto das políticas; melhora na efetividade

e eficiência de serviços governamentais, entre outras.

8 http://opendefinition.org/


26

Os Dados Abertos Governamentais (DAGs) devem conter 3 (três) características

peculiares, também chamadas de leis9, que são:

1. Se o dado não pode ser encontrado e indexado na Web, ele não existe;

2. Se não estiver aberto e disponível em formato compreensível por máquina, ele não pode

ser reaproveitado;

3. Se algum dispositivo legal não permitir sua replicação, ele não é útil;

Em 2007, além das leis, o portal Open Government Data10

, que congrega interessados em

discutir as iniciativas de Dados Governamentais Abertos, define que os dados governamentais

são considerados abertos quando publicados de acordo com os seguintes princípios:

1. Completos: Todos os dados públicos são disponibilizados. Dados são informações

eletronicamente gravadas, incluindo, mas não se limitando a, documentos, bancos de

dados, transcrições e gravações audiovisuais. Dados públicos são dados que não estão

sujeitos a limitações válidas de privacidade, segurança ou controle de acesso, reguladas

por estatutos.

2. Primários: Os dados são publicados na forma coletada na fonte, com a mais fina

granularidade possível e não de forma agregada ou transformada.

3. Atuais: Os dados são disponibilizados tão rápido quanto necessário para preservar o seu

valor.

4. Acessíveis: Os dados são disponibilizados para o público mais amplo possível e para os

propósitos mais variados possíveis.

5. Processáveis por máquina: Os dados são razoavelmente estruturados para possibilitar o

seu processamento automatizado.

6. Acesso não discriminatório: Os dados estão disponíveis a todos, sem que seja necessária

identificação ou registro.

7. Formatos não proprietários: Os dados estão disponíveis em um formato sobre o qual

nenhum ente tenha controle exclusivo.

8. Livres de licenças: Os dados não estão sujeitos a regulações de direitos autorais, marcas,

patentes ou segredo industrial. Restrições razoáveis de privacidade, segurança e controle

de acesso podem ser permitidas na forma regulada por estatutos.

Apesar de as leis e os princípios terem sido pensados e propostos para os Dados Abertos

Governamentais, pode-se dizer que eles se aplicam também aos Dados Abertos de modo geral.

Para Diniz (2010), “A disponibilização de dados governamentais abertos permite que as

informações sejam utilizadas da maneira e conveniência do interessado de tal forma que elas

9 http://eaves.ca/2009/09/30/three-law-of-open-government-data/

10 www.opengovdata.org/home/8principles


27

possam ser misturadas e combinadas para agregar mais valor aos dados”. Para o autor, o objetivo

de que as informações públicas sejam disponibilizadas segundo as regras dos dados abertos é

“superar as limitações existentes para que usuários de informações do serviço público possam

facilmente encontrar, acessar, entender e utilizar os dados públicos segundo os seus interesses e

conveniências”.

Não é sem motivo, portanto, que o W3C define dados governamentais abertos como “a

publicação e disseminação das informações do setor público na Web, compartilhados em

formato bruto e aberto, compreensíveis logicamente, de modo a permitir sua reutilização em

aplicações digitais desenvolvidas pela sociedade”.

Além disso, o W3C entende que os governos devem incentivar os cidadãos a usarem os

dados abertos disponíveis pelos governos, ou seja, eles devem ser estimulados a reutilizarem os

dados conforme as suas necessidades e vontades. Diniz (2010) resume o objetivo desse

incentivo: “Não há valor na disponibilização de dados governamentais abertos se a sociedade

não tem interesse em reutilizá-los”.

Um ponto importante a ser destacado diz respeito à relação entre transparência e DAG. A

defesa dos dados abertos como promotor de transparência se deve às possibilidades de tornar os

dados governamentais acessíveis a todos, eliminando as restrições referentes à tecnologia,

legislação e acessibilidade para garantir o irrestrito acesso e utilização dos dados públicos pelos

cidadãos.

A relevância da oferta de dados abertos no setor público encontra fundamento no interesse

público que envolve as informações governamentais e na regulação que envolve a questão. A

maioria dos Estados de Direito Constitucional adotam o princípio da publicidade que entende a

transparência dos dados governamentais como a regra e o sigilo como exceção. Para Bobbio, a

república democrática “exige que o poder seja visível (...) as reuniões da assembleia devem ser

abertas ao público de modo a que qualquer cidadão a elas possa ter acesso” (BOBBIO, 1987).

Para Ribeiro (2009), existe uma disputa entre diversas visões da transparência: as distintas

visões apresentam a transparência como sinônimo do princípio da publicidade; de accountability

que, de modo geral, se refere à prestação de contas e à definição dos objetos sobre as quais se

prestarão contas juntamente com a sua responsabilização (LEVY, 1999); ou openness que pode

ser definido como: “abertura para o fornecimento de informação, entendida como o

fornecimento livre e universal de informações para seu público-alvo” (VAZ, 2002). Em adição a

essas visões, compreende que a transparência também pode ser entendida a partir da visão de

dados governamentais abertos.


28

2.3 Ontologias

Ontologia é um ramo da filosofia que lida com a natureza e a organização do ser.

Segundo Ferreira (1988), ontologia é uma “parte da Filosofia que trata do ser enquanto ser, isto

é, do ser concebido como tendo uma natureza comum que é inerente a todos e a cada um dos

seres”.

Esse termo foi recentemente adotado também pelas comunidades de Inteligência

Artificial e Gestão do Conhecimento para se referir a conceitos e termos que podem ser

utilizados para descrever alguma área do conhecimento ou construir uma representação.

Entre as diversas definições de ontologia existentes, uma bastante interessante e mais

usual é a de Gruber (1993), “uma ontologia é uma especificação formal e explícita de uma

conceitualização compartilhada”. Quando se refere à palavra “conceitualização” quer se aludir a

um modelo abstrato de algum fenômeno que identifique conceitos relevantes desse fenômeno.

Uma especificação “explícita” significa que os conceitos e as limitações do uso desses conceitos

devem ser definidos de forma explícita. A palavra “formal” refere-se ao fato de que a ontologia

deve ser passível de ser processada por uma máquina. Por fim, o termo “compartilhada” reflete a

noção de que a ontologia captura um conhecimento consensual, isto é, esse conhecimento não

deve ser restrito a alguns indivíduos, mas aceito por um grupo de pessoas (FENSEL, 2001).

Ontologias possuem várias utilizações. Uschold et al. (1996) definem categorias para

utilização, listadas na Tabela 1.

Tabela 1 - Categorias de uso de ontologias para a área da Ciência da Computação.

Categorias de Utilização Aplicação

Comunicação Provê um entendimento compartilhado entre as pessoas com

necessidades e pontos de vista diferentes.

Interoperabilidade Permite a integração de ambientes de ferramentas de software

diferentes.

Engenharia de Sistemas Facilita o processo de identificação dos requisitos dos sistemas e

entendimento das relações entre os componentes do sistema.

Fonte: (Uschold et al., 1996)

O uso de ontologias, no contexto da Web Semântica, requer uma linguagem de ontologia

compatível com a Web, com uma sintaxe e uma semântica bem definida, suporte ao raciocínio

eficiente e expressivo. Também requer a implementação explícita da semântica das informações

para prover o suporte necessário para o processamento de dados por parte das máquinas, ou seja,


29

o conteúdo abordado deve estar munido de contexto e vocabulário comuns. As ontologias têm

sido utilizadas com a finalidade de prover informações semânticas. As linguagens de ontologia

para Web são, geralmente, expressas em uma linguagem lógica, a lógica descritiva, garantindo as

distinções entre as classes, propriedades e relações, evitando ambiguidades. Uma ontologia

define formalmente os termos usados para descrição e representação deste domínio.

Há elementos básicos que constituem uma ontologia que são as classes, slots, axiomas e

instâncias (CHAUDHRI et al., 1998). Classes (conceitos ou elementos do domínio) são coleções

de objetos que possuem propriedades similares. Slots descrevem atributos e propriedades de

classes. Instâncias são membros individuais de classes (NOY et al., 2004). E por fim, os axiomas

consistem em restrições sobre determinado domínio (GUARINO, 1998).

Para que as ontologias sejam criadas e representadas formalmente, elas devem ser

descritas em uma linguagem formal. Uma das linguagens para a construção de ontologias é a

OWL (Web Ontology Language) (MCGUINNESS et al., 2004), uma linguagem de definição de

ontologias, executável por computadores, incluindo nessas as definições de classes, propriedades

e axiomas (SMITH et al., 2004).

2.3.1 Metodologias para construção de ontologias

Não obstante uma grande variedade de ontologias já ter sido desenvolvida por distintas

comunidades, não há conformidade com relação ao processo metodológico de desenvolvimento

de ontologias. A escolha de uma metodologia para a construção de uma ontologia está

relacionada aos objetivos finais que se deseja alcançar com sua construção, como o detalhamento

dos processos utilizados e sua manutenção (MORAIS e AMBRÓSIO, 2007).

Metodologias de desenvolvimento de ontologias existem no intuito de sistematizar a

construção e manipulação de ontologias (MORAIS e AMBRÓSIO, 2007). Todas possuem

abordagens e características diversas. Existem metodologias para construção de ontologias de

forma colaborativa, para aprendizado sobre a estrutura de ontologias e para a integração de

ontologias. Entretanto, nenhuma delas ainda é totalmente madura, principalmente se comparadas

com metodologias de Engenharia de Software.

Para Guimarães (2002), uma prática muito comum entre os desenvolvedores de

ontologias é passar diretamente do passo de aquisição de conhecimento para o passo de

implementação, o que pode gerar alguns problemas, como:

Os modelos conceituais da ontologia ficam implícitos no código da implementação;

Dificuldades de reúso da ontologia, pois o projeto da ontologia e as decisões de

projeto estão implícitos no código.


30

Problemas de comunicação devido às dificuldades que o especialista no domínio da

ontologia tem para entender o código da implementação. Isso é um sério problema,

pois ele tende a ser a principal fonte de informação sobre o domínio.

Dificuldades no desenvolvimento de ontologias complexas, pois a passagem da

aquisição de conhecimento para a implementação é muito abrupta.

Dependendo da linguagem escolhida para a codificação pode-se limitar a capacidade

de descrição conceitual do domínio da ontologia.

Dessa forma, faz-se necessária a adoção de uma metodologia para, assim, reduzir as

dificuldades acima citadas.

Na literatura, há algumas metodologias para construção de ontologias, que são: a

metodologia de Gruninger e Fox, também conhecida como TOVE (Toronto Virtual Enterprise)

(GRUNINGER e FOX, 1995); método de Uschold e King ou metodologia Enterprise Ontology

(USCHOLD e KING, 1995); metodologia Methontology (FERNANDEZ, GOMEZ-PEREZ e

JURISTO, 1997); metodologia On-To-Knowledge (STAAB et al., 2001); método 101 (NOY e

McGUINNESS, 2001). Há outros métodos como Sensus (SWARTOUT et al., 1996); método

Cyc (REED e LENAT, 2002); método Kactus (BERNARAS, LARESGOITI e CORERA, 1996),

entre outras.

A seguir, serão explicadas algumas das metodologias utilizadas para desenvolvimento de

ontologias:

Metodologia de Gruninger e Fox

Essa metodologia foi proposta por Michael Gruninger e Mark Fox em 1995

(GRUNINGER e FOX, 1995), tendo como base para o seu desenvolvimento a experiência obtida

no projeto Toronto Virtual Enterprise – Tove. Ela é formada pelas seguintes etapas:

o Definir os cenários motivadores – Identifica possíveis problemas que demandem

uma nova ontologia. O cenário motivador também fornece intuitivamente um

conjunto de soluções possíveis para o problema.

o Definir informalmente questões de competência – Dado o cenário motivador,

um conjunto de perguntas irão surgir que necessitarão de uma ontologia para que

elas sejam respondidas. Essas perguntas são as questões de competência da

ontologia. Elas não são expressas em linguagem formal.


31

o Especificação em lógica de primeira ordem da terminologia – Uma vez que as

questões de competência foram definidas informalmente a fim de propor ou

estender uma ontologia, a terminologia da ontologia deve então ser especificada

usando lógica de primeira ordem ou equivalente.

o Especificar as questões de competência formalmente – Uma vez que foram

definidas informalmente as questões de competência e a terminologia da

ontologia, as questões de competência são definidas em linguagem formal.

o Especificação formal dos axiomas – Criação das regras, descritas em linguagem

formal, a fim de definir a semântica dos termos e relacionamentos da ontologia.

o Verificação através dos teoremas de completude – Através desses teoremas são

fornecidos meios de determinar a extensibilidade da ontologia, fazendo

explicitamente o papel que cada axioma executa no teorema.

Metodologia de Uschold e King

O método foi proposto inicialmente por Mike Uschold e Martin King em 1995

(USCHOLD e KING, 1995) e estendido em 1996 por Mike Uschold e Michael Gruninger

(USCHOLD e GRUNINGER, 1996), na experiência de desenvolvimento da Enterprise

Ontology. A seguir são descritas as etapas da metodologia:

o Identificação do propósito – Identificar o porquê da construção da ontologia e as

suas intenções de uso.

o Construção da ontologia – Essa etapa é subdividida em 3 (três) estágios:

Captura da ontologia – Identificar conceitos e relacionamentos do

domínio de interesse para produzir uma definição precisa dos mesmos.

Codificação – Codificar a ontologia em uma linguagem formal.

Integração com ontologias existentes – Integrar a nova ontologia com as

ontologias existentes.

o Avaliação – Identificar critérios técnicos como verificação da especificação de

requisitos, validação das questões de competência, comparação com o mundo

real, etc.

o Documentação – Deve conter toda a descrição do processo, podendo ter formato

diferente para tipos distintos de ontologias, mas que será determinante para o

reúso da ontologia desenvolvida.


32

Uma das desvantagens desta metodologia é que ela não descreve de maneira precisa as

técnicas para executar as diferentes atividades. O nível de detalhamento da metodologia é baixo,

só oferecendo princípios gerais muito vagos.

Metodologia Methontology

A metodologia Methontology foi desenvolvida no laboratório de Inteligência Artificial da

Universidade de Madrid para a construção de ontologias (LOPÉZ, 1997) e (PÉREZ, 1998). A

Methontology é baseada no processo padrão IEEE para o desenvolvimento de software (GOMÉZ

e LOPÉZ, 2004). Diferentemente de outras, esta metodologia descreve a identificação do

processo de desenvolvimento da ontologia, dividindo-o em tipos de atividades a serem

desenvolvidas; descreve o ciclo de vida de uma ontologia, a partir da evolução de protótipos,

assim como técnicas específicas para cada atividade executada. Suas atividades principais são

formadas pelo conjunto de etapas:

o Atividades de gerenciamento de ontologias - elaboração de cronogramas,

controle, garantia da qualidade.

o Atividades ligadas ao desenvolvimento de ontologias - estudo do ambiente,

estudo de viabilidade, especificação, conceitualização, formalização,

implementação, manutenção, uso.

o Atividades de suporte/manutenção - aquisição do conhecimento, avaliação,

integração, documentação, integração, gerência da configuração, alinhamento.

Essas atividades podem ser apoiadas pelo ODE (Ontology Development Environment),

que fornece apoio automatizado ao processo de desenvolvimento de ontologias. Os autores

utilizam técnicas de elicitação bem semelhantes às que têm sido praticadas no levantamento de

requisitos de software (BREITMAN e LEITE, 2003), por exemplo, entrevistas estruturadas,

questionários, e leitura de documentos do domínio. É interessante notar que a Methontology

realiza uma previsão para o reúso de conceitos de outras ontologias por meio do método de

reengenharia de ontologias.

Metodologia On-To-Knowledge

Esta metodologia permite construir ontologias para aplicações de gestão do

conhecimento, sendo altamente dependente da aplicação (STAAB et al., 2001). Ela é baseada em

4 (quatro) fases: kick-off, refinamento, avaliação e manutenção.


33

o Fase kick-off - os requisitos para construção da ontologia são capturados e

especificados; questões de competência são identificadas, ontologias

potencialmente reutilizáveis são estudadas e uma primeira versão da ontologia é

construída.

o Fase refinamento - uma ontologia mais madura é construída a partir da primeira

versão.

o Fase avaliação - os requisitos e as questões de competência são checados e a

ontologia é colocada em ambiente de produção.

o Fase manutenção - envolve atividades de adaptação da ontologia às mudanças

nos requisitos e correção de erros.

Método 101

Método 101, desenvolvido por Natalya Noy e Deborah McGuiness, consiste de “um guia

para a criação da sua primeira ontologia” (NOY e MCGUINESS, 2001) e tem a função de um

roteiro com tópicos a serem observados na construção de uma ontologia. São discutidas questões

gerais, bem como o possível processo de construção de uma ontologia, utilizando uma

abordagem iterativa, ou seja, parte de uma versão inicial da ontologia, que será revisada e

refinada durante o processo.

Noy e McGuinness (2001) ressaltam algumas regras consideradas fundamentais na

elaboração de uma ontologia:

Não existe apenas uma forma correta de modelar um domínio, sempre há alternativas

viáveis. A melhor solução depende da aplicação que se tem em mente e as extensões

desejadas;

O desenvolvimento de uma ontologia é um processo iterativo;

Conceitos na ontologia devem estar ligados a objetos - físicos ou lógicos - e

relacionamentos em seu domínio de interesse. Estes são mais suscetíveis de serem

substantivos (objetos) ou verbos (relacionamentos) em sentenças que descrevem seu

domínio.

Noy e McGuinness (2001) também lembram que uma ontologia é um modelo do mundo

real e os conceitos dessa ontologia devem refletir essa realidade.


34

2.4 Padrões da Web Semântica

Em 2001, surgiu a ideia da Web Semântica, em um artigo publicado na revista Scientific

American pelo autor Tim Berners-Lee e colaboradores (BERNERS-LEE et al., 2001). Os autores

discutem que a Web Semântica é uma extensão da Web atual, a qual permite que a informação

sobre páginas e recursos seja recuperada com significado bem definido, fazendo com que

humanos e computadores trabalhem de forma otimizada. Dessa forma, as máquinas podem

“entender” os dados que elas apenas exibem na Web atual.

A recuperação inteligente de informação das páginas Web é uma das principais

contribuições da Web Semântica. A utilização dos padrões e das ferramentas definidas pela Web

Semântica, muitas vezes, eliminam, por parte dos usuários, o trabalho de interpretar, combinar e

filtrar as informações advindas das diversas fontes de informações. Ademais, são levadas em

consideração informações implícitas nas fontes de dados e o contexto do usuário na formulação

de pesquisas.

A semântica é utilizada com uma ideia da natureza do significado (ALLEMANG e

HENDLER, 2008) e se refere à informação sobre o conteúdo de documentos disponíveis na

Web, na qual essa informação é denominada de Metadado (dado sobre dados) e é processável

por máquinas (ANTONIOU e HARMELEN, 2008).

Como acontece na Web comum, cada camada da Web Semântica foi pensada para

trabalhar complementando a camada inferior e de forma independente das superiores (SANTOS

e ALVES, 2009). Na Figura 4, é possível conferir a arquitetura em camadas da Web Semântica.

Figura 4 - Arquitetura em camadas da Web Semântica. Fonte: (Santos e Alves, 2009).


35

A camada inferior está relacionada ao caráter global da Web. Unicode é uma codificação

padrão de caracteres que permite a manipulação consistente de cadeias de caracteres

provenientes da grande maioria dos sistemas de escrita que existem. Quanto ao URI (Uniform

Resource Identifier) trata-se de um padrão de identificação de recursos que já é utilizado na Web

tradicional. Há alguns tipos de URI e o mais conhecido é o URL (Uniform Resource Locator) ele

é um nome ou identificador que representa um endereço único e global de acesso a um recurso

na Web. URI utiliza espaços de nomenclatura para identificar o domínio ao qual pertence o

recurso, evitando a repetição de nomes. É bastante útil para identificar recursos em ambientes

intrinsecamente descentralizados, como é o caso da Web (RAMALHO et. al., 2007).

A camada sintática opera com a linguagem XML (eXtensible Markup Language), é de

fácil utilização, permite escrever documentos estruturados com facilidade pelo usuário. É

bastante empregada no transporte de dados pela Web (W3C, 2012).

Na camada de dados, as entidades deverão ser representadas formalmente de uma

maneira bem definida, podendo ser identificados seus atributos e relacionamentos com outras

entidades. Nessa camada tem-se: o RDF (Resource Description Framework), que é um modelo

de dados básico que descreve assertivas sobre recursos na Web. Essa camada é baseada na

linguagem XML, porém não é dependente da mesma, visto que existem outras representações

em que é possível escrever RDF. O RDF-S (RDF Schema) é uma extensão semântica do modelo

RDF e provê primitivas de modelagem para objetos na Web como: classes, subclasse,

propriedades e restrições de domínio.

Na quarta camada, a camada ontologia, visa à representação do conhecimento que se dá

de forma distribuída, diferentemente dos sistemas tradicionais de IA. Nesta formalização

descentralizada dos diferentes domínios do conhecimento, a Web Semântica faz uso de

ontologias.

A camada lógica apresenta todo o processo dedutivo. É responsável pelo tratamento das

informações advindas das camadas inferiores, fazendo as inferências lógicas de acordo com as

regras declaradas para o modelo de dados.

A camada de prova contém todos os mecanismos de avaliação da veracidade de uma

informação. Além disso, é checada a consistência de dados oriundos da Web Semântica.

E por fim, a camada de confiança está relacionada a assinaturas digitais e todo processo

de certificação para a credibilidade das fontes de informações acessadas na Web.

A seguir, algumas tecnologias mais relevantes para o desenvolvimento do trabalho serão

apresentadas.


36

2.4.1 RDF

RDF é sigla para Resource Descripition Framework. O RDF é um padrão no qual é um

modelo de dados simples é criado com o objetivo de descrever recursos da Web (MANOLA e

MILLER, 2004). O RDF pode ser considerado um elemento chave da Web semântica e possui

vários formatos de sintaxe. Seguem alguns exemplos de representações como: XML, Notation 3

(N3) (W3C, 2005), NTriples (W3C, 2001) e Turtle (W3C, 2008).

O RDF é composto por 3 (três) conceitos básicos:

Os recursos, que correspondem a qualquer entidade, objeto ou coisa que se refere

ao que existe no mundo (pessoas, livros, páginas da Web, entre outros) e são

identificados através de um endereço único chamado de URI (Uniform Resource

Identifiers) (BERNERS-LEE et al., 1998);

As propriedades, que são características a respeito dessas entidades (idade, título,

data de criação, entre outros), também são identificadas através de URIs;

A sentença, que é formada por um bloco de construção encapsulado em conjuntos

de triplas (sujeito – propriedade - valor) (ANTONIOU e HARMELEN, 2008), que

pode ser utilizado para fazer declarações sobre esses recursos.

Os documentos em RDF representam dados de uma forma simples para expressar

afirmações sobre esses recursos. Como já foi dito, a unidade de informação utilizada por esse

modelo é chamada de tripla, que é composta pelos seguintes recursos: sujeito, predicado

(propriedade) e objeto, formando assim uma afirmação (statement). Para um recurso ser

identificado no contexto apresentado pela Web Semântica é atribuído a ele um Uniform

Resource Identifier (URI), ou seja, o sujeito, predicado e objeto estão associados a um

identificador de recursos. É importante ressaltar que o valor de um objeto também pode ser um

literal. Para um melhor entendimento, a Figura 5 apresenta um exemplo de uma tripla que é

utilizada no vocabulário da LOA.

Figura 5 - Exemplo de uma tripla RDF. Fonte: (LOA, 2012).

Um conjunto de triplas pode ser visualizado como um grafo, no qual uma tripla é

representada por dois “nós” e a aresta entre eles. No entanto, um arquivo RDF é constituído por

várias triplas interligadas, que resultam em afirmações a respeito dos relacionamentos entre

recursos. Cada nó pode ser um URI que identifica um recurso, um literal, ou até mesmo um nó

em branco.


37

A Figura 6 ilustra um exemplo de um grafo.

Figura 6 - Exemplo de um grafo RDF. Fonte: (LOA, 2012).

Para um arquivo RDF ser construído e disponibilizado, é necessário que ele esteja em

formato serializável, como RDF/XML, Turtle e N-Triples11

. O RDF/XML é uma linguagem

baseada em XML, enquanto que o Turtle é um formato mais simples, no que tange à leitura e

escrita por humanos, além de englobar as características da forma de serialização do formato N-

Triples. O N-Triples é uma versão mais simples do Turtle, pois não tem abreviações e utiliza

prefixos para URIs, aumentando a performance de seu processamento por máquinas e

complicando a leitura e escrita humana.

O RDF, definido como sendo basicamente um modelo de dados, possui um vocabulário

chamado RDF-Schema (RDFS). Na visão da Web Semântica este vocabulário é responsável por

adicionar semântica ao RDF (ANTONIOU e HARMELEN, 2008). As primitivas de modelagem

principais do RDFS são relativas a organização de vocabulários em hierarquias: relacionamentos

de subclasses e subpropriedades, restrições de domínio e limites e instâncias de classes. A

Tabela 2, lista alguns exemplos RDF/RDFS.

Tabela 2 - Exemplos de construtores em RDF/RDFS

Construtor Características

rdfs:Class Construtor responsável por definir recursos que são Classes.

rdf:type Descreve que um recurso é do tipo de uma instância de uma classe.

rdfs:resource Tudo em RDF é descrito como um recurso. Esse construtor define instâncias da

classe rdfs:Class.

rdfs:range É uma propriedade que define que uma instância é de uma ou mais classes.

Fonte: (Antoniou e Harmelen, 2008).

11

http://www.w3.org/RDF/


38

2.4.2 SPARQL

Algumas iniciativas foram desenvolvidas para a consulta aos dados no padrão RDF,

como a RQL (RDF Query Language) (ANTONIOU e HARMELEN, 2008), RDQL (RDF Data

Query Language) (W3C, 2004), SeRQL (Sesame RDF Query Language) (BROEKSTRA et al.,

2004), SPARQL (SPARQL Protocol and RDF Query Language) (PRUD'HOMMEAUX et al.,

2008), entre outras.

Criada pela W3C em 2008, SPARQL é uma linguagem de consulta a documentos

descritos em RDF. Pode ser utilizada em diversas fontes de dados que estejam em formato de

triplas em RDF ou que possuam um middleware para conversão dos dados em diversos formatos

para triplas RDF. Um middleware pode ser visto como um programa de computador que

transporta dados de diferentes plataformas mascarando, assim, a heterogeneidade das diversas

fontes de informação.

Na linguagem SPARQL, para formular uma consulta, é necessária a utilização de

cláusulas. As principais são SELECT, para selecionar os recursos a serem recuperados,

possibilitando inclusão de filtros para a pesquisa, e a cláusula WHERE para informar quais

triplas devem ser analisadas. Para representar os recursos nas triplas que estão sendo consultadas,

são utilizadas variáveis de consulta, as quais são identificadas por serem termos, antecedidos por

um símbolo de interrogação “?”.

Visando à disponibilização para consultas, são utilizados endpoints SPARQL, que são

interfaces que podem ser utilizadas por usuários ou aplicações para realizar consultas SPARQL

em uma base de dados RDF. Sua função é servir como ponto de acesso aos dados, recebendo

uma requisição de uma consulta e ativando um motor de consulta que acessa o triple store,

retornando o resultado. O endpoint pode ter como front-end uma aplicação Web ou stand-alone.

O endpoint pode ser acessado por intermédio de uma URL, na qual é disponibilizada uma

interface para que a consulta seja informada e, posteriormente, os resultados exibidos. Se o

usuário for uma aplicação, o acesso ao endpoint é realizado por alguma API especializada, como

a biblioteca Jena de desenvolvimento de aplicações para a Web Semântica em Java.

2.4.3 OWL

Essa camada diz respeito às linguagens formais para a modelagem de ontologias. Na

literatura, existem diversas linguagens de construção de ontologias, dentre elas, a SHOE

(HEFLIN et al. 1999), DAML (DAML, 2001), OIL (FENSEL et al. 2000), DAML+OIL

(DAML, 2001) e OWL (MCGUINNESS et al., 2004). Dentre elas, a linguagem Web Ontology

Language (OWL) destaca-se por possuir semântica bem definida em termos da lógica


39

matemática (ANTONIOU e HARMELEN, 2008) e, atualmente, é recomendada pela W3C

(Consórcio World Wide Web) como um padrão para a construção de ontologias.

Comparando com RDFS, as ontologias escritas na linguagem OWL apresentam um maior

grau de expressividade, por causa da base que existe no formalismo de Lógica de Descrições. Os

construtores definidos permitem que as ontologias sejam processáveis por máquina, sendo

capazes de inferir novas relações através de motores de raciocínio. O motivo pelo qual isso

ocorre é pelo fato de quanto maior o poder de expressividade de uma linguagem, maior a

complexidade do raciocínio por computadores. A seguir seguem exemplos de algumas

limitações do RDFS em relação à linguagem OWL (ANTONIOU e HARMELEN, 2008):

Disjunção entre classes: o RDF-Schema define apenas as relações de subclasses. Outras

relações como a disjunção não podem ser definidas. Dessa forma, por exemplo, não se

pode dizer que ‘Macho’ e ‘Fêmea’ são classes disjuntas;

Escopo local de propriedades: o construtor rdfs:range define um escopo único para

propriedades de classes. Por isso, não se pode, para uma propriedade de uma classe,

definir restrições de um escopo. Por exemplo, a classe ‘Vaca’ não pode ter sua

propriedade ‘alimenta-se’ de apenas planta ao mesmo tempo em que a classe ‘Leão’

possua a propriedade ‘alimenta-se’ de carne, plantas e vegetais;

Combinações booleanas de classes: o RDF-Schema não permite as operações de união,

intersecção e complemento entre classes. Por exemplo, não se pode definir que a classe

‘Pessoa’ é formada pela união das classes disjuntas ‘Macho’ e ‘Fêmea’;

Restrições de cardinalidade: Não se pode definir a quantidade de valores que uma

propriedade pode assumir. Por exemplo, não se pode definir que uma pessoa pode ter

exatamente dois irmãos ou que um professor só pode ser responsável por, no máximo,

duas disciplinas;

Características especiais de propriedades: no RDF-Schema não é permitido representar

características de propriedades. Por exemplo, não há como descrever que uma

propriedade é transitiva, única ou inversa de outra propriedade.

A linguagem OWL, em sua segunda versão conhecida como OWL2, possui três tipos de sub-

linguagens que foram definidas tomando como base o grau de expressividade e a capacidade de

raciocínio.


40

Na Tabela 3, são apresentados os tipos de linguagem OWL e suas características.

Tabela 3 - Tipos de liguagem OWL.

Tipo da Linguagem Características

OWL-EL Subconjunto da OWL 2 que tem como base a Lógica de Descrição (DL). A

OWL-EL foca na expressividade terminológica usada em ontologias.

OWL-QL Subconjunto da OWL 2 que permite a consulta a dados. Com o uso da OWL-

QL é possível realizar consultas simples a banco de dados por mecanismos de

reescrita do SQL para conceitos da ontologia.

OWL-RL Subconjunto da OWL 2 que se assemelha a uma linguagem baseada em regras.

Os axiomas definidos nas subclasses da ontologia, que implementam esse

perfil, podem ser entendidos como regras de implicação entre a superclasse

(premissa) e a subclasse (conclusão).

Fonte: (W3C, 2009)

A OWL foi concebida para prover uma linguagem de ontologia que pudesse ser utilizada

para descrever, de uma maneira natural, classes e relacionamentos entre elas em documentos e

aplicações Web. A utilização dos termos em uma ontologia deve ser escritos de uma forma que

possam ser interpretados sem ambiguidade e usados por agentes de software.

Para construção de uma ontologia OWL, são necessários alguns elementos básicos como: as

classes, as instâncias (também chamadas de indivíduos) das classes e os relacionamentos (as

propriedades) entre estas instâncias.

1. Classes e Indivíduos

As classes fornecem um mecanismo de abstração que agrupa recursos com características

similares, ou seja, uma classe define um grupo de indivíduos que compartilham algumas

propriedades. O conjunto de indivíduos que estão associados a uma classe é chamado de

extensão de classe (BECHHOFER, et. al., 2010). Os indivíduos em uma extensão de classe são

denominados de instâncias da classe.

Cada indivíduo na OWL é membro da classe owl:Thing. Desta maneira, ela é superclasse de

todas as classes OWL definidas pelos usuários. Ademais, existe a classe owl:Nothing (não possui

instâncias), que é uma subclasse de todas as classes OWL. Uma classe é sintaticamente

representada como uma instância nomeada da owl:Class, que é uma subclasse da rdfs:Class.


41

2. Propriedades

Para Smith et al., (2004), as propriedades, que são consideradas relações binárias, podem ser

usadas para estabelecer relações entre indivíduos ou então, entre indivíduos e valores de dados.

Estes relacionamentos permitem afirmar fatos gerais sobre os membros das classes e podem

também especificar fatos sobre indivíduos A OWL aponta entre duas categorias principais de

propriedades:

Propriedades de tipos de dados (datatype properties): relação entre indivíduos e valores

de dados.

Propriedades de objetos (object properties): relação entre indivíduos.

Uma propriedade de objeto é definida como instância da classe owl:ObjectProperty. Uma

propriedade de tipo de dado é definida como uma instância da classe owl:DatatypeProperty.

Além disso, ambas são subclasses da classe RDF rdf:Property. Sendo assim, as propriedades do

RDF-Schema são herdadas, ou seja, rdfs:subPropertyOf, rdfs:domain e rdfs:range.

OWL também permite a especificação de características sobre as propriedades, incluindo,

owl:TransitiveProperty, owl:SymmetricProperty, owl:FunctionalProperty,

owl:InverseFunctionalProperty e owl:inverseOf entre outras propriedades SMITH et al. (2004).

2.5 Linked Data

Linked Data (dados conectados) se refere às melhores práticas para a publicação e

interligação de dados na Web. De maneira mais detalhada, Linked Data pode ser definido como

o conjunto de princípios que permite a publicação, recuperação e interligação de dados

estruturados de forma padronizada e global (BERNERS-LEE, 2011). Estes princípios buscam a

criação de um grande e único grafo global de dados, denominado de Web de Dados. O grafo é

formado por triplas de RDF, no qual já é uma realidade a existência desses grafos e, a cada ano,

novos conjuntos de dados são criados e interligados formando uma grande nuvem de dados

(BERNERS-LEE, 2009 e 2012). A Figura 7 ilustra a nuvem dos conjuntos de dados conectados

atualmente cadastrados na nuvem do projeto LOD.


42

Figura 7 - lod cloud. Fonte: (http://lod-cloud.net/versions/2014-08-30/lod-cloud_colored.png)

Periodicamente, no website do The Linking Open Data cloud diagram são publicados

diagramas que exibem o estado atual do grafo (ou nuvem) gerado por dados publicados e

interligados, utilizando os princípios de Linked Data. Os conjuntos de dados são representados

por círculos, que são os nós do grafo. Na nuvem aparecem conjuntos de dados de 9 (nove)

domínios diferentes cada um com uma cor que os representam, domínios como: mídia,

geográfico, publicações, governo, domínios variados, ciências entre outros.

Os princípios de Linked Data são:

1. Usar URIs para identificar “coisas” (recursos);

2. Usar URIs HTTP para que se possa acessar os recursos;

3. Disponibilizar informações úteis, utilizando os padrões (RDF e SPARQL, entre

outros);

4. Interligar recursos por meio de URIs para que se descubram mais informações.

Quando se fala de estratégias de Dados Abertos, que vão além de simplesmente publicar

informações, pode-se trazer à discussão o conceito de Dados Ligados ou, além disso, como

Dados Abertos Ligados ou Linked Open Data (LOD).

A atividade de abertura de dados, ou então, de publicação de dados abertos na Web, é

ainda incipiente para uma parcela pequena do governo. Para grande parte dos órgãos a falta de

pessoas capacitadas é o principal motivo que contribui com essa realidade. Existem várias

abordagens: algumas rápidas e outras mais complexas. É nessa perspectiva que nasce a

necessidade de se criar um modelo de maturidade (OKFN, 2013).


43

Tim Berners-Lee (2009), criador da World Wide Web, diz que “Dados Abertos Ligados

são Dados Ligados publicados por meio de licenças abertas”. Há casos em que os dados ligados

não necessariamente precisam ser abertos, porém, em se tratando de dados abertos ligados, é

bem diferente. Para estimular a difusão destes dados, Tim Berners-Lee criou um esquema de

maturidade de publicação de dados baseado em estrelas, para classificar o nível de

comprometimento das bases de dados com relação aos princípios de Linked Data e Dados

Abertos.

Por meio dessa classificação, ganha uma estrela a iniciativa que tornou pública uma

informação e a disponibilizou em formato aberto. A partir disso, as iniciativas recebem

progressivamente mais estrelas de acordo com o grau de abertura e acessibilidade dos dados. A

Figura 8 apresenta o esquema de classificação.

Figura 8 - Esquema de maturidade de publicação de dados abertos. Fonte: (http://5stardata.info/)

A seguir a classificação proposta por Tim Berners-Lee:

★☆☆☆☆ Dados estão disponíveis na Web, independente de formato, sob uma licença

aberta (Por exemplo um documento PDF sob uma licença aberta).

★★☆☆☆ Deve atender a condição anterior e também estar em um formato

estruturado e legível por máquina (Por exemplo um arquivo Excel ao invés de uma

imagem escaneada de uma tabela).

★★★☆☆ Todas as condições anteriores, e deve utilizar um formato não

proprietário (Por exemplo um arquivo CSV ao invés de um Excel).


44

★★★★☆ Todas as condições anteriores, e deve utilizar URIs bem desenhadas para

identificar os recursos, então as pessoas podem referenciá-las.

★★★★★ Todas as condições anteriores e, além disso, devem ligar seus dados com

dados de outras pessoas para prover contexto.

As bases de dados publicadas na Web em formatos não estruturados (ou não tratáveis por

computador) são classificadas com uma estrela. Já as bases composta por dados em RDF,

referenciando outras fontes de dados, seguindo os padrões da W3C e todos os princípios de

Linked Data, são consideradas cinco estrelas, a melhor classificação.

2.6 Trabalhos Relacionados

Nesta seção, são apresentados alguns trabalhos relacionados com a aplicação de

ontologias de orçamento para o setor público. Apesar de não ser tão frequente na literatura,

existem alguns trabalhos semelhantes a esta pesquisa, como o trabalho de Silva (2014), que

propõe uma extensão de um modelo ontológico do orçamento; o trabalho de Martins et al.

(2013), que propõe uma ontologia para receitas e despesas do orçamento público; o trabalho de

ARAÚJO e CRUZ, (2012), que desenvolve uma ontologia para o Orçamento Federal Brasileiro;

a Ontologia “Payments” (Ontology, 2010), desenvolvida dentro do contexto de dados abertos do

governo britânico e, por fim, o trabalho de Brusa, Caliusco e Chiotti (2006), com o objetivo do

desenvolvimento de uma ontologia do Setor Público para uma província na Argentina. Segue

abaixo uma breve descrição e análise dos trabalhos considerados relacionados.

Silva (2014)

O trabalho de Silva (2014) propõe uma extensão da ontologia das Classificações da

Despesa do Orçamento Federal, a ontologia LOA, descrita em ARAÚJO e CRUZ (2012), por

meio da formação de um ambiente de exploração de dados triplificados, o qual é composto pelos

itens de despesa e os seus classificadores orçamentários.

A motivação principal é a disponibilização dos dados governamentais em formato aberto

por meio das recomendações da Web Semântica, possibilitando aos desenvolvedores um

reaproveitamento mais eficiente dos dados. De forma complementar, o desenvolvimento da

aplicação da prova de conceito pretende demonstrar que a publicação de dados governamentais,

em formato aberto, simplificará etapas de desenvolvimento de aplicações, visto que os dados já

estarão tratados e prontos para uso. Em particular, os dados de planejamento e de execução do


45

Orçamento Federal são de grande interesse para tal forma de publicação, haja vista que

caracterizam diretamente as condições de realização dos gastos públicos.

A ontologia estendida no trabalho incluiu as classes “Exercicio” e os atributos

“valorEmpenhado”, “valorLiquidado” e “valorPago”. Após a expansão da ontologia LOA foi

realizado um processo automatizado de extração, transformação e armazenamento dos dados

orçamentários em formato compatível com os padrões brasileiros de dados abertos,

triplificando os dados, armazenando-os e disponibilizando-os por meio de terminais

específicos. Para consultar o arquivo RDF, utilizou-se um terminal para realização de consultas

SPARQL. O autor utilizou um Item de Despesa da ontologia LOA do ano de 2013 para

realização dos experimentos. Após, foi executada a transformação dos dados estruturados em

sentenças RDF. Foram utilizados os dados do portal do SIOP12

para realização dos testes.

Martins et al. (2013)

Esse trabalho propõe uma ontologia para descrever a elaboração e execução das receitas e

despesas do Orçamento Público Federal Brasileiro. Foi utilizada uma metodologia de

desenvolvimento de ontologias, o método iterativo Deronto (Caliari, 2007), o qual possibilita a

definição de uma ontologia por meio de um diagrama entidade-relacionamento (DER) do

domínio. A Ontologia foi construída usando o editor de ontologias Protégé. Para validar a

ontologia, foram realizadas inferências e consultas com os dados do orçamento federal referentes

à execução das receitas e despesas dos anos de 2010 e 2011, obtidos no Portal Siga Brasil13

. Com

isso, o trabalho demonstrou uma proposta de uso que pode auxiliar no desenvolvimento de

aplicações que permitam ao cidadão exercer seu direito de fiscalização dos gastos públicos.

A metodologia adotada para a realização do trabalho constituiu de várias fases como i)

conceitualização: a ontologia foi desenvolvida a partir de um modelo DER com os conceitos

básicos de orçamento, despesas e receitas, sofrendo modificações de acordo com a necessidade

percebida; ii) definição: foram definidos os conceitos e subconceitos da ontologia, definindo,

assim, as propriedades e relacionamentos das despesas e receitas; iii) avaliação da ontologia: a

ontologia foi testada e foram criadas algumas regras na linguagem Semantic Web Rule Language

(SWRL) para realizar inferências e verificar se o domínio estava modelado corretamente; e, por

fim, iv) a fase de desenvolvimento de uma aplicação teste: foi desenvolvida uma aplicação

utilizando o Jena Framework a partir dos dados convertidos de CSV para RDF.

12

https://www1.siop.planejamento.gov.br/acessopublico 13

http://www12.senado.gov.br/orcamento/sigabrasil


46

ARAÚJO e CRUZ (2012)

Esse trabalho tem como objetivo a criação de uma ontologia, em OWL, para a

classificação das despesas do orçamento federal contemplando as categorias e conceitos

consolidados no Manual Técnico Orçamentário. O trabalho visa a publicação dos dados em

formato computacionalmente tratável. O trabalho é direcionado à comunidade de

desenvolvedores, que poderá utilizá-lo para criar produtos voltados aos técnicos em finanças

públicas e aos cidadãos comuns entre outros.

A ontologia descrita é composta pelos itens de despesa e os respectivos classificadores

orçamentários, por exemplo, Função, Subfunção, Programa, entre outros. Após a criação da

ontologia, foi realizada uma prova de conceito que converte as informações constantes nos

bancos de dados relacionais em triplas RDF, tomando como base os conceitos definidos nas

classes da ontologia. Ocorreu o processo de triplificação, geração de um arquivo em formato

RDF e, por fim, este arquivo foi armazenado em um repositório para consultas SPARQL. A

ontologia LOA14

populada com os dados da Lei Orçamentária Federal 2012 gerou um arquivo

RDF com 824.591 triplas, publicado com a especificação OWL no portal SIOP15

.

Payments Ontology (2010)

No Reino Unido, em 2010, surgiu uma iniciativa para publicação de dados sobre

pagamentos dentro do contexto de dados abertos do governo britânico a Payments Ontology16

.

Como os dados são geralmente publicados em planilhas, a ideia é publicá-los utilizando os

padrões Web abertos para facilitar a combinação e a comparação dos dados. Dessa forma, foi

desenvolvida uma ontologia, denominada “Payments”, como um vocabulário de propósito

comum para representar as informações de gastos organizacionais em geral e não se limitar a

aplicações governamentais. O trabalho descreve uma ontologia de pagamentos.

14

http://vocab.e.gov.br/2013/09/loa 15

www.siop.planejamento.gov.br 16

https://data.gov.uk/resources/payments


47

A Figura 9 apresenta a Payments Ontology:

Figura 9 - Diagrama da ontologia do Governo UK. Fonte:http://data.gov.uk/resources/payments

A Payments Ontology17

(Ontologia de Pagamentos) fornece a capacidade para representar

um conjunto de pagamentos, e foi projetada para ser flexível quanto à riqueza do detalhe

disponível. A seguir, será descrito brevemente cada item da ontologia de pagamento do Reino

Unido.

No centro da ontologia está o conceito de um pagamento com um payer (pagador)

associado, payee (beneficiário, recebedor) e date. O pagamento pode ser melhor descrito por um

número de propriedades opcionais, incluindo a parte da organização pagador envolvido

(unidade), o recolhimento de bens ou serviços adquiridos e links para recursos que documentam

o processo tais como a ordem, contrato e fatura.

Associado a cada pagamento, normalmente, há alguma forma de expenditure analysis

(análises de despesas) que define como o pagamento é contabilizado. Um único pagamento pode

ser dividido em uma série de linhas de análise de despesas separadas. Estas linhas de análises

podem indicar a finalidade para a qual foram adquiridos bens ou serviços, assim como, um item

de nível detalhado sobre o que foi comprado. Este nível detalhado da análise de despesas nem

sempre precisa ser incluído em um conjunto de dados publicados definidos. Mas, quando estão

presentes, estes representam cada linha de análise utilizando ExpenditureLine (linha de

despesas), que está vinculado ao pagamento do qual é uma parte pelo par de

17

https://data.gov.uk/resources/payments


48

payment/expenditureLine de propriedades inversas. As linhas de despesa individuais incluem

pelo menos custo líquido (netAmount) e um expenditureCategory associado que define a

finalidade da compra.

Além do pagamento individual, existe o PaymentDataset, que é uma coleção de

informações de pagamento. Metadados, tais como data de publicação ou informações de

licenciamento deve ser anexados ao conjunto de dados. O conjunto de dados aponta para o

conjunto de pagamentos que ele contém. A ontologia Payments Ontology reutiliza alguns

vocabulários como Dublin Core, FOAF.

Brusa, Caliusco e Chiotti (2006)

Esse trabalho discute o processo do desenvolvimento de uma ontologia para o Setor

Público. O processo foi aplicado para o desenvolvimento de uma ontologia de domínio

Orçamentário e Informação Financeira para a província de Santa Fé, na Argentina. Entretanto, o

principal objetivo do trabalho é apresentar uma abordagem sobre como técnicas da engenharia

ontológica podem ser aplicadas para a solução de problemas de descoberta, agregação e

compartilhamento de conteúdo em ambientes de e-government.

Para o trabalho, a ontologia considera apenas as necessidades para a criação de um

orçamento analítico com conceitos relacionados às despesas. Ele não considera os conceitos

relacionados a outras etapas como execução orçamentária, contabilidade, pagamentos, compras

ou fecho do ano fiscal. Portanto, ele inclui conceitos gerais para o ciclo de vida do orçamento e

conceitos específicos para a formulação.

A Tabela 4 resume as principais características dos trabalhos discutidos. Além dos

trabalhos discutidos, a tabela apresenta as principais características da ontologia proposta neste

trabalho, a OntoPag.


49

Tabela 4 - Trabalhos Relacionados

Vin

cula

ção

com

ou

tras

on

tolo

gia

s

Não

Não

Não

Não

Não

Sim

Pu

bli

caçã

o

em F

orm

ato

RD

F

Sim

Sim

Sim

Sim

Sim

Sim

Uso

de

da

do

s

de

pa

gam

ento

s

e fa

vore

cid

os

Não

Não

Não

Sim

Não

Sim

On

tolo

gia

de

orç

am

ento

Sim

Sim

Sim

Sim

Sim

Sim

Ob

jeti

vos

Ex

ten

são

da

on

tolo

gia

de

clas

sifi

caçã

o d

e d

esp

esas

--

LO

A

Pro

põ

e on

tolo

gia

par

a a

estr

utu

ra d

a el

abo

raçã

o e

exec

uçã

o d

as r

ecei

tas

e

des

pes

as d

o O

rçam

ento

Pú

bli

co F

eder

al B

rasi

leir

o

Co

nst

ruçã

o d

e um

a

on

tolo

gia

de

clas

sifi

caçã

o d

e

des

pes

as

Inic

iati

va

par

a p

ub

lica

ção

de

dad

os

sob

re p

agam

ento

s

den

tro

do

con

tex

to d

e d

ado

s

aber

tos

do

go

ver

no

bri

tân

ico

.

Des

env

olv

imen

to d

e u

ma

on

tolo

gia

de

do

mín

io

Orç

amen

tári

o e

info

rmaç

ão

fin

ance

ira

par

a a

pro

vín

cia

de

San

ta F

é n

a A

rgen

tin

a.

Inic

iati

va

par

a p

ub

lica

ção

de

dad

os

con

ecta

do

s so

bre

pag

amen

tos

e fa

vo

reci

do

s d

o

orç

amen

to p

úb

lico

Bra

sile

iro

Tra

balh

os

Sil

va

(20

14)

Mar

tin

s et

al.

(2

01

3)

Ara

újo

e C

ruz

(20

12

)

Pa

ymen

ts O

nto

log

y

(20

10

)

Bru

sa,

Cal

iusc

o e

Ch

iott

i (2

00

6)

On

toP

ag (

201

5)

2.7 Considerações

Neste capítulo, foi apresentada uma revisão bibliográfica sobre os principais conceitos e

aspectos referentes ao Orçamento Público. Conceitos sobre Dados Abertos e Transparência de

Dados. Em seguida, foram apresentadas as Ontologias e os Padrões da Web Semântica e, por

fim, uma visão geral sobre Linked Data. Foi apresentada, também, uma breve descrição de

alguns trabalhos que existem na literatura os quais abordam os conceitos de ontologias no


50

domínio orçamentário, bem como os conceitos de publicação de dados. Por fim, também foi

apresentado um quadro comparativo entre as características de alguns trabalhos relacionados

com esta pesquisa.

Pode-se destacar o trabalho Payments Ontology, que é uma iniciativa do governo

Britânico para publicação de dados sobre pagamentos com relação aos dados abertos do governo

Reino Unido. A iniciativa OntoPag é semelhante a iniciativa da Payments Ontology, porém, há

um diferencial que, além de tratar os dados sobre pagamentos, a OntoPag também pode

identificar o favorecido, ou seja, para qual pessoa (física ou jurídica) foi destinado o pagamento e

o respectivo valor. E por fim, este trabalho possibilita a conexão dos dados de pagamentos com

outros dados orçamentários, gerá-los e publicá-los em formato aberto.

Capítulo 3 – Processo de Desenvolvimento da Ontologia

51

Capítulo

3

3 Processo de desenvolvimento da Ontologia OntoPag

Este capítulo tem como objetivo apresentar o processo de desenvolvimento da

ontologia OntoPag: uma ontologia para representação de conceitos relacionados aos dados de

Pagamentos do Orçamento Público Federal. Também será apresentada uma breve descrição do

modelo ontológico da Classificação das Despesas do Orçamento Federal Brasileiro (LOA), que

serviu como base para a ontologia OntoPag.


52

3.1 Introdução

A construção de uma ontologia não é uma tarefa simples, embora o uso de ontologias seja

muito comum em diversos domínios. Para Mattos et al. (2010), há alguns desafios encontrados

na construção de ontologias, em que se destacam os problemas referentes à estruturação de

dados, falta de padronização na representação do conhecimento e dificuldades para a

implementação da ontologia.

No processo de construção de ontologias, usualmente são aceitas como atividades

constituintes, a especificação, conceitualização, formalização, implementação e manutenção.

Dentre estas atividades, há também, a atividade de Avaliação da Ontologia, que se mostra tão

importante quanto as demais. Segundo Gómez-Pérez, Corcho e Fernández-López (2004), a

Avaliação da Ontologia é um tipo de julgamento técnico da ontologia durante cada fase e entre

fases do ciclo de vida de uma ontologia e do seu processo de desenvolvimento. Busca-se avaliar

os componentes da ontologia de forma a se determinar o que ela define corretamente, o que não

define e o que define incorretamente (GÓMEZ-PÉREZ, CORCHO e FERNÁNDEZ-LÓPEZ,

2004). Constituem-se parte do processo de Avaliação a Verificação da Ontologia e a Validação

da Ontologia.

Como método de desenvolvimento da ontologia OntoPag, optou-se por fazer uso da

metodologia de construção de ontologias de Uschold e King (1995), pois este é um método

simples e, além disso, visa à fase de identificação da proposta da ontologia, visa o porquê da

construção da ontologia e intenções de uso e, como validação, deixa claro o uso de questões de

competência (QCs).

A ontologia OntoPag foi desenvolvida com o objetivo de permitir a descrição de

informações relativas aos Pagamentos efetuados dentro do Orçamento Público. Levando-se em

consideração os trabalhos existentes na literatura, os quais não abordam a descrição de

pagamentos, e a relevância desses dados para a realização de análises sobre o Orçamento

Público, constatou-se a necessidade do desenvolvimento da ontologia de pagamentos. A

OntoPag é uma extensão da ontologia LOA. Dessa forma, espera-se facilitar a criação de dados

conectados do Orçamento Público Federal.


53

3.2 Desenvolvimento da Ontologia OntoPag

Nesta seção será descrcita a aplicação do método proposto por Uschold e King (1995) no

processo de desenvolvimento da ontologia OntoPag. A seguir, serão descritas as etapas desta

metodologia:

Identificação do propósito:

Visa identificar o porquê da construção da ontologia e as suas intenções de uso. Seguem

algumas questões que foram concebidas para identificação do propósito:

1. Qual é o domínio que a ontologia cobrirá?

A ontologia abordará os conceitos relacionados a Orçamento Público e Finanças

Públicas, com ênfase nos pagamentos de despesas do governo federal e as entidades

favorecidas (pessoas físicas e jurídicas). Uma parte dos recursos do orçamento federal

não é paga diretamente pelo governo federal e sim transferida para outros entes

federados (estados e municípios). Esta parte dos recursos não será coberta pela

ontologia.

2. Qual será o uso da ontologia?

O principal objetivo da ontologia será oferecer o acesso pela Web à base de dados de

pagamento do orçamento federal em formato aberto e conectado para consultas

diretas em SPARQL ou para acesso direto automatizado por programadores. Como a

ontologia de pagamentos está vinculada à ontologia do orçamento, é possível também

estabelecer conexões entre os dados de pagamento e os dados do orçamento, que

representam a autorização formal para a realização das despesas públicas.

3. Quem vai utilizar e manter a ontologia?

A ontologia será utilizada para o desenvolvimento deste trabalho, sendo

disponibilizada para consulta e reúso por parte das pessoas interessadas na área

orçamentária e finanças públicas, como estudantes, economistas, administradores,

órgãos públicos. A manutenção ocorrerá à medida que surgirem novas necessidades

ou situações que demandam ajustes na ontologia.

As respostas a estas questões ajudam a delimitar o alcance da ontologia e, como foram

realizadas em um determinado instante, podem variar no decorrer do tempo.


54

Construção da ontologia: Esta etapa é subdividida em 3 (três) fases:

o Captura da ontologia:

Visa identificar conceitos e relacionamentos do domínio de interesse para produzir uma

definição precisa dos mesmos.

Para a execução deste passo, foram analisadas as colunas do conjunto de dados de

despesas – gastos diretos – que se encontram no Portal da Transparência18

. Dessa análise, foram

identificados os conceitos que representam, relacionando aqueles que já estão definidos na

ontologia do orçamento e estabelecendo as relações entre os respectivos significados.

Foram definidas as classes e a hierarquia de classes da ontologia. A lista obtida no passo

anterior serviu de base para a criação das classes. Para a vinculação superclasse/subclasse foram

analisadas as características de cada classe para verificar a existência de especializações ou

generalizações entre elas. Como exemplo, tem-se a classe pagamento, que foi especializada em

duas subclasses: pagamento sigiloso e pagamento público.

Foram criadas propriedades para descrever as classes e os relacionamentos existentes

entre essas classes. Foram identificadas relações entre objetos da ontologia de pagamento com

objetos da ontologia do orçamento. A criação destas relações pode ser feitas com a reutilização

da ontologia do orçamento. Também foram criadas propriedades de tipos de dados para conectar

um indivíduo a um valor.

o Codificação:

Existem vários ambientes para codificação de uma ontologia como: GKB-Editor (Generic

Knowledge Base Editor)19

, JOE (Java Ontology Editor)20

, OntoEdit21

, WebODE22

, WebOnto23

,

Protégé24

, entre outras.

A ferramenta escolhida para este trabalho foi Protégé. Algumas características

favoreceram esta opção, como (UserGuide, 2005): i) a ferramenta é gratuita e de código aberto;

ii) permite a inserção de novos recursos por intermédio de plug-ins ou extensões desenvolvidas

para sua customização; iii) ferramenta multiplataforma (funciona em ambientes Windows, Mac

OS X, Linux, e outros); iv) possui interface gráfica interativa e amigável; v) permite que vários

18

http://www.portaltransparencia.gov.br/ 19

http://www.ai.sri.com/~gkb/ 20

http://cit.cse.sc.edu/demos/java/joe/joeBeta-jar.html 21

http://www.daml.org/tools/#OntoEdit 22

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/old-technologies/60-webode 23

http://projects.kmi.open.ac.uk/webonto/ 24

http://protege.stanford.edu/


55

usuários editem simultaneamente uma mesma ontologia; vi) extensível, facilita a inclusão de

gráficos, tabelas e mídias como, imagem, som e vídeo; vii) oferece suporte a diferentes tipos de

formatos de armazenamento, tais como: OWL, RDF, XML e HTML; viii) amplamente difundida

e utilizada.

Após a escolha do Protégé como ferramenta para edição de ontologias, iniciou-se o

processo de construção da ontologia OntoPag, a partir da reutilização de alguns termos da

ontologia das Classificações da Despesa do Orçamento Federal.

o Integração com ontologias existentes:

Visa integrar a nova ontologia com as ontologias existentes.

A seguir, é apresentado o repositório da ontologia consultada:

Ontologia LOA

Modelo ontológico da Classificação das Despesas do Orçamento Federal Brasileiro.

Namespace: < http://vocab.e.gov.br/2013/09/loa>

Avaliação:

A avaliação é feita por meio de critérios técnicos como verificação da especificação de

requisitos, validação das questões de competência (QCs), comparação com o mundo real, entre

outros.

Validação por questões de competência é uma técnica muito comum para levantar,

especificar e formalizar os requisitos de uma ontologia. As QCs representam as questões que a

ontologia deve ser capaz de responder. Estas questões, além de justificar a existência da

ontologia, servem para auxiliar a avaliação da ontologia depois de construída (Grunninger e Fox,

1995).

Em Ghomari e Ghomari (2013), é proposto um método de verificação da capacidade da

ontologia em responder às Questões de Competência (QCs) levantadas na especificação dos

requisitos. Esses autores propõem a validação por meio de:

i. tradução da QCs em forma de consultas (queries) implementadas em alguma

linguagem formal;

ii. a associação de cada consulta a um conjunto de resultados esperados;

iii. a execução da consulta sobre a ontologia;

iv. a comparação dos resultados obtidos com os resultados esperados.


56

Em geral, adota-se a linguagem SPARQL para construção de consultas sobre ontologias,

além de possuir alta expressividade, possibilitando a representação de um maior número de

Questões de Competências (QCs).

Todavia, traduzir as QCs especificadas em linguagem natural para consultas SPARQL

não é uma tarefa trivial. Sendo assim, um método de tradução proposto por Ghomari e Ghomari

(2013) pode ser sumarizado nos seguintes passos descritos na Figura 10 apresenta esses passos.

Figura 10 - Passos da técnica de tradução das QCs. Fonte: Ghomari e Ghomari (2013)

Para o primeiro passo, as possíveis categorias das QCs que podem ser consideradas são:

Questões de Definição (QD): aquelas que se iniciam com “O que é/são...” ou com “O que

significa...”;

Questões Booleanas (QB): aquelas que admitem resposta “Sim/Não”;

Questões Factuais (QF): aquelas cuja resposta é um fato ou uma informação precisa;

Questões de Listas (QL): aquela cuja resposta é uma lista de entidades;

Questões Complexas (QC): aquelas que se iniciam com “Como...” e “Por que...” e nas

quais se obter uma resposta precisa é bastante improvável.

Tendo como base este método de Ghomari e Ghomari (2013) de uso das QCs e suas

respectivas traduções para consultas SPARQL, este trabalho segue algumas etapas deste

conjunto de atividades que devem ser executadas para o processo de Validação da Ontologia. A

seguir são descritas as atividades.

1. Selecionar QCs: efetua-se a seleção de um conjunto de QCs que serão utilizadas para

validar a ontologia. Seleção manual de QCs a partir de consultas aos especialistas do

domínio;

2. Traduzir QCs selecionadas: efetua-se a tradução das QCs selecionadas na Atividade 1 para

consultas em SPARQL. Composta das seguintes tarefas:

2.1. Identificar categorias das QCs: a partir da lista de QCs selecionadas na Atividade 1,

procura-se identificar a categoria de cada um delas de acordo com as categorias;

2.2. Determinar respostas esperadas: procura-se determinar a resposta esperada, perfeita

ou ideal, para cada uma das QCs selecionadas e categorizadas;


57

2.3. Extrair entidades das QCs e das respostas: realiza-se a extração dos termos relevantes

tanto das QCs quanto das suas respostas. Esses termos devem ter alguma entidade

(classe, objeto, relação) equivalente na ontologia para que a consulta SPARQL seja

capaz de obter alguma resposta da ontologia. Essa é uma condição obrigatória e

importante na validação da ontologia, pois pode alertar para a necessidade de

complementação e atualização da ontologia com entidades faltantes;

2.4. Identificar os tipos das entidades da ontologia: as entidades da ontologia identificadas

devem ser representadas na consulta SPARQL em alguma das seguintes formas: classe,

propriedade de dados, propriedade de objeto, axioma, instância ou anotação. Isto se deve

ao fato de a sintaxe das consultas SPARQL ser altamente dependente do tipo de entidade

da ontologia na qual se irá procurar pela resposta que se espera;

2.5. Construir as consultas SPARQL: uma vez que as respostas esperadas para as QCs, as

entidades e sua localização na ontologia foram identificados, as consultas SPARQL

correspondente devem ser escritas.

3. Executar as consultas SPARQL: as consultas obtidas na atividade 2 devem ser executadas

sobre a ontologia avaliada, registrando-se as respostas obtidas.

4. Avaliar resultados das consultas: avalia-se a capacidade da ontologia em responder as QCs

comparando as respostas das consultas SPARQL às respostas esperadas das QCs. Propõe-se

um método para quantificar essa capacidade: para cada QC selecionada, atribuiu-se um valor

conforme os critérios abaixo:

Se a QC pode ser completamente traduzida – a ontologia possuía todas as entidades

necessárias – e se a consulta SPARQL retornou a resposta esperada integralmente,

atribuiu-se o valor 3 (três);


necessárias – e se a consulta SPARQL não retornou a resposta esperada integralmente

(resposta parcial, mas correta), atribuiu-se o valor 2 (dois);


necessárias – mas a consulta SPARQL não retornou a resposta esperada corretamente

(resposta errada), atribuiu-se o valor 1 (um);

Se a QC não pode ser completamente traduzida – a ontologia não possuía todas as

entidades necessárias – atribuiu-se o valor 0 (zero).


58

Tabela 5 - Tabela de Valores das QCs

QC Tradução Completa Resposta Esperada Valor

QC1 Sim Integral 3

QC2 Sim Parcial 2

QC3 Não Errada 1

Fonte: Bortolato (2014)

A partir dos valores atribuídos, calculou-se a capacidade da ontologia de responder as

QCs (Cobertura) por meio da fórmula:

100_º

referenciaValordeQCsn

ValorQCCobertura

Onde:

Cobertura é o valor, em porcentagem, da capacidade da ontologia responder o rol

de QCs selecionados para a validação.

∑ValorQC é a somatória dos valores atribuídos a cada uma das QCs selecionadas.

n° de QCs é a quantidade de QCs selecionadas para a validação.

Valor_referencia = 3, já que essa é a escala definida por ser o valor máximo que

pode ser atribuído a cada QC {0, 1, 2 ou 3}.

As Questões de Competência (QCs) serão apresentadas no Capítulo 5 descritas na Seção

de Avaliação.

Documentação:

Após a criação de classes e propriedade, o resultado final, em formato OWL, da ontologia

OntoPag pode ser observado no Apêndice A em representação em formato Turtle (*.ttl) e no

Apêndice B representação em formato OWL/RDF, que foi gerada utilizando o Protégé.

Após criação da ontologia e extração dos códigos nos respectivos formatos, Turtle e

OWL/RDF, foi gerada uma documentação por meio de um serviço denominada LODE: Live

OWL Documentation Environment25

, este tem como objetivo extrair automaticamente as classes,

propriedades de objetos, propriedades de dados, indivíduos nomeados, propriedades de anotação,

axiomas gerais e declarações de namespace de uma ontologia owl e owl2, e torná-las como listas

ordenadas, juntamente com a suas definições textual (em uma página HTML legível).

25

http://www.essepuntato.it/lode


59

O ontologia OntoPag e a documentação da OntoPag pode ser acessada por meio do link

da URL26

, e também a documentação da ontologia por ser consultada no Apêndice C.

Nas próximas seções, serão descritas em detalhes a ontologia LOA que foi base para o

desenvolvimento da ontologia OntoPag. Além disso, também será apresentada a ontologia

OntoPag.

3.2.1 Modelo Ontológico das Classificações da Despesa - LOA

Inicialmente, é importante uma reflexão ontológica sobre o significado do orçamento

público. O orçamento contém informações sobre toda a receita e despesa prevista para ser

realizada pelo período de um ano por um ente público. Os orçamentos em geral são estabelecidos

por Lei e representam essencialmente autorização para gastar. Ele decorre de um princípio

basilar de Finanças Públicas, segundo o qual nenhuma despesa pública pode se realizar sem

autorização legislativa.

O conceituado autor na área de orçamento público, Aaron Wildavsky (1996), escreveu

sobre o conceito de orçamento público, referindo-se, em específico, ao orçamento federal dos

Estados Unidos, ele comenta que “... um orçamento contém palavras que propõem gastos com

determinados objetos e propósitos. Estas palavras descrevem tipos de despesas (salários,

equipamentos de viagem) ou fins (prevenção da guerra, a melhoria da saúde mental, habitação de

baixa renda), e os números são anexados a cada item...”

O autor Aaron Wildavsky (1996) ainda relata que “... um orçamento, portanto, também

pode ser caracterizado como uma série de metas com etiquetas de preços em anexo. Como os

fundos são limitados e têm de ser divididos de uma forma ou de outra, o orçamento torna-se um

mecanismo para fazer escolhas entre despesas alternativas...Se o orçamento inclui especificações

detalhadas de como os objetivos sejam alcançados, também pode servir como um plano de

trabalho para aqueles que assumem a tarefa de implementação...”

Finalizando o pensamento do autor, presume-se que os que fazem um orçamento

pretendem que haja uma ligação direta entre o que está escrito no orçamento e eventos futuros,

que o orçamento une os recursos financeiros e o comportamento humano, a fim de alcançar

objetivos políticos. Pode haver uma grande diferença, porém, entre as intenções daqueles que

compõem um orçamento e suas realizações.

Embora a língua de um orçamento apela para alcançar determinados objetivos, através de

despesas previstas, a investigação pode revelar que não há fundos que foram gastos para esses

26

https://github.com/wsfantini/OntoPag


60

fins, que o dinheiro foi usado para outros fins, que os objetivos bastante diferentes foram

alcançados, ou que os mesmos objetivos foram alcançados em diferentes formas.

No Brasil, o orçamento federal é apresentado como uma lista de itens de despesa. Cada

item desta lista está associado a valores financeiros que correspondem às várias estapas da

execução orçamentária, as quais são o valor do PLOA – Projeto de Lei Orçamentaria Anual,

valor da LOA – Lei Orçamentária Anual (também chamado de Dotação Inicial), valor da LOA

mais Créditos (também chamado de Dotação Atual), valor Empenhado, valor Liquidado e valor

Pago. A cada Item de Despesa é associado um código de 44 dígitos, que os vinculam aos

critérios de classificação da despesa, constantes do MTO (Brasil, 2013). A Figura 11 apresenta,

de uma maneira resumida, a estrutura de um item de despesa apenas com o valor de dotação

inicial para a LOA 2012, com a apresentação de seus códigos e descrições.

Figura 11 - Item de Despesa. Fonte: (LOA, 2012)

A definição da ontologia LOA teve como princípio refletir esta organização na publicação

dos dados da despesa orçamentária. A Figura 12 apresenta o diagrama com a estrutura das

classes, que são representadas por retângulos na cor cinza, e as relações entre elementos de

classes, representados por retângulos pretos. Linhas tracejadas representam relações de

subclasse. O range (alcance) das relações é representado por uma seta sem preenchimento,

enquanto o domain (domínio) é representado por uma seta com preenchimento.


61

Figura 12 - Diagrama de classes e propriedades da Ontologia da Lei Orçamentária Anual. Fonte: Araújo e

Cruz (2012).


62

A classe ItemDeDespesa é a classe central da ontologia que representa uma linha do

orçamento. Cada ItemDeDespesa tem 6 (seis) valores associados por meio das relações

valorProjetoLei, valorDotacaoInicial, valorLeiMaisCreditos, valorEmpenhado, valorLiquidado e

valorPago. A soma total destes valores da relação valorDotacaoInicial de cada Item de Despesa é

o valor total do orçamento do exercício em questão.

As classificações possuem relação de especialização com a classe Classificador e para cada

classificador existe um rótulo descritivo (label) e um código. As classes referentes a essas

classificações foram definidas de modo a abranger todos os 44 dígitos do código de um item de

despesa.

A Secretaria do Orçamento Federal criou a ontologia em OWL para representação dos

dados orçamentários Federais de 2012, a Ontologia da Lei Orçamentária Anual de 2012 (Brasil,

2012). Constatou-se que algumas classes e propriedades da ontologia LOA 2012 se adequavam

ao modelo de dados das despesas deste trabalho. Porém, vários conceitos relativos à execução

orçamentária ainda não estavam abordados. Isto motivou a integração com a ontologia LOA,

com outra nova ontologia, acrescentando informações que identificassem o valor de pagamento e

os favorecidos.

ARAÚJO e CRUZ (2012) relatam que as classificações orçamentárias possuem relação de

especialização com a classe Classificador e cada classificador possui um rótulo descritivo (label)

e um código. Por fim, para representação do exercício em que o Item de Despesa está inserido,

toda instância dessa classe possui uma relação temExercicio com um objeto da classe Exercicio.

Os recursos da classe Exercicio possuem a propriedade dataUltimaAtualizacao (em

formato dateTime) que define a última data em que o exercício financeiro foi atualizado. O

recurso também possui um identificador que consiste no ano que o exercício representa.

A partir do desenvolvimento da ontologia LOA, os dados do orçamento, que permitem

identificar todas as classificações, foram disponibilizados em formato RDF. Entretanto, os dados

com o detalhamento da execução do orçamento, ou seja, discriminando cada pagamento

efetuado, ainda não estão disponíveis neste formato. É importante destacar que esses dados

permitiriam identificar, para cada categoria de orçamento, os respectivos pagamentos efetuados e

os favorecidos.

Então, partindo desse ponto, este trabalho propõe uma extensão da LOA, a partir da

utilização de classes, relações e atributos, bem como a criação de novos conceitos, a fim de

permitir a descrição de dados relativos a pagamentos e relacioná-los com os Itens de Despesa do

orçamento, por meio dos atributos que são comuns a ambas as classes, Item de Despesa, da

ontologia do orçamento (LOA) e Pagamento, da ontologia dos Pagamentos (OntoPag). A

próxima seção apresenta a ontologia OntoPag, que é a expansão da ontologia LOA.


63

3.2.2 A Ontologia OntoPag

Nesta seção é apresentada a ontologia OntoPag. Esta ontologia estende alguns

componentes da Ontologia das Classificações das Despesas do Orçamento Federal Brasileiro. A

Figura 13 apresenta a relação dos classificadores de um Item de Despesa (LOA) com

Pagamentos (OntoPag).

Figura 13 - Relação de Item de Despesa com Pagamentos

A Figura 13 apresenta uma relação de um Item de Despesa com Pagamentos, essas classes

estão representadas por retângulos. Os classificadores, representados por círculos preenchidos,

representam a lista de características de um Item de Despesa, essa lista é composta por Unidade

Orçamentária, Função, Subfunção, Programa, entre outras, esses classificam um Item de

Despesa. Os classificadores de um Item de Despesa podem ou não estar ligados ao classificador

da classe Pagamento. As linhas cheias são as relações que existem de fato entre a Classe Item de

Despesa da ontologia LOA e a Classe de Pagamento da ontologia OntoPag as quais podem ser

encontrados no Portal da Transperência, entretanto, as linhas pontilhadas representam que não há

relação entre os classificadores da Classe Item de Despesa e a Classe Pagamento.

É importante observar que as instâncias da classe Pagamento não possuem, ou não estão

disponíveis, todos os atributos da classe Item de Despesa, representados pelas setas tracejadas.

Isto significa que não é possível determinar, com as informações disponibilizadas na OntoPag,


64

para cada pagamento, qual o seu respectivo Item de Despesa do orçamento. Porém, é possível,

por meio dos atributos comuns (representados pelas setas preenchidas), determinar qual o

conjunto de Itens de Despesa que se relaciona com o Pagamento. Esse conjunto, que foi

denominado de Grupo de Itens, pode ser pensado como uma versão condensada ou menos

detalhada do orçamento, porém, ainda com grande utilidade, com muitas informações a serem

extraídas dos atributos (classificadores) que a ele estão associados.

Os classificadores que são comuns às classes Item de Despesa e Pagamento são (MTO,

2015):

Unidade Orçamentária - Representa a unidade administrativa responsável pela despesa;

Função - Área de atuação governamental onde será aplicado o recurso;

Subfunção – Representa um nível de agregação imediatamente inferior à função e deve

evidenciar cada área da atuação governamental;

Programa - Instrumento de organização da ação governamental visando à concretização

dos objetivos pretendidos;

Ação - Instrumento de organização da ação governamental visando à concretização dos

objetivos de um programa. Pode ser um projeto, uma atividade ou uma operação especial;

GND – Grupo de Natureza de Despesa - Agregação de elementos de despesa que

apresentam as mesmas características quanto ao objeto do gasto.

Estes atributos comuns estabelecem a conexão conceitual entre as duas ontologias,

permitindo confrontar os dados de despesa com os dados de pagamento. Por exemplo, uma

categoria da classe GND é “Outras Despesas Correntes”. Portanto, combinando os atributos

Unidade Orçamentária e GND é possível obter a informação de quanto foi gasto de Outras

Despesas Correntes na Unidade “Universidade Federal de Pernambuco”. Esta informação está na

base de dados do orçamento. Por outro lado, a ontologia dos Pagamentos pode ser consultada

para saber, desse valor, quais foram os pagamentos efetuados, em que data, para quem, em que

valor, entre outras informações.

Como foi descrito antes, a ontologia do orçamento não contempla o detalhamento dos

pagamentos. Assim, é possível identificar o que foi pago em um determinado Item de Despesa,

mas não os detalhes de cada pagamento, por exemplo, quem recebeu o pagamento e a data.

Esta é uma informação muito demandada e bastante útil para a área financeira. O Portal da

Transparência do governo federal oferece algumas consultas que permitem identificar os

pagamentos efetuados segundo alguns critérios de consulta. Porém, as consultas são limitadas e

não permitem o cruzamento com as informações do orçamento. Por exemplo, obter uma lista

dos pagamentos efetuados por Unidade Orçamentária, excluído despesas de pessoal. No entanto,


65

o Portal oferece a possibilidade de baixar uma planilha com a relação de todos os pagamentos

efetuados em cada mês.

A ontologia LOA (ARAÚJO e CRUZ, 2012) é uma ontologia que representa o domínio

orçamentário – despesas do orçamento - e, por isso, descreve muito bem entidades que modelam

orçamento, como é o caso do item de despesa. Como extensão dessa ontologia, classes foram

criadas para representar as entidades que foram identificadas e sobre as quais existem

informações disponíveis no Portal da Transparência27

. Essas informações são de grande

importância prática no processo orçamentário porque sensibilizam mais diretamente um grande

número de interessados.

A Figura 14 apresenta o diagrama de classes da ontologia OntoPag, que apresenta as

classes e propriedades e relações que foram inseridas nesta ontologia. O diagrama foi construído

utilizando a ferramenta de linguagem visual para representar, chamada yEDEditor28

. A

representação do grafo, dos nós e arestas customizadas para ontologias, foi baseada na

especificação de Graffoo29

de Peroni (2013), o qual apresenta um framework para representar

graficamente ontologias.

27

www.portaldatransparencia.com.br 28

https://www.yworks.com/en/products/yfiles/yed/ 29

http://www.essepuntato.it/graffoo/

https://www.yworks.com/en/products/yfiles/yed/


66

Figura 14 - Diagrama de classes e propriedades da Ontologia OntoPag.

A classe pag:Pagamento representa os eventos em que o governo efetua um pagamento,

em reais, a uma pessoa física ou jurídica. É importante frisar que a informação sobre

pagamentos, individualmente, não consta da ontologia do orçamento do governo federal, que

contempla as categorias ou grupos de despesa agregadamente, mas não os pagamentos

individuais.

Cada elemento da classe pag:Pagamento é caracterizado por se relacionar com um ou mais

indivíduos de um Grupo de Itens Despesa e com um ou mais indivíduos de pag:Favorecido.

Possui também os atributos: pag:numeroDocumento, pag:valorPagamento, pag:dataPagamento.

A classe pag:Pagamento está relacionada com a classe pag:UnidadeGestora e possui duas

subclasses pag:PagamentoSigiloso e pag:PagamentoPublico. A classe pag:PagamentoPublico


67

está relacionada com a classe pag:Favorecido. Por fim, a classe pag:Pagamento está relacionada

com as diversas instâncias da ontologia LOA como órgãos, programa, função, subfunção, ação,

grupo de despesa, entre outras.

A primeira classe, pag:PagamentoSigiloso, representa o pagamento, que é considerado

com informações sigilosas, ou seja, não possui informações de código, data, entre outros, até

mesmo do favorecido. A Lei de Acesso à Informação - LAI30

se preocupou em garantir os meios

para que a sociedade acesse a informação pública e que efetivamente a utilize. Porém, em se

tratando de informações pessoais e sigilosas, a LAI estabelece que o Estado tem o dever de

protegê-las. Estas devem ter acesso restrito e serem protegidas não só quanto à sua integridade,

mas contra vazamentos e acessos indevidos, pois isso poderia causar graves danos, podendo

trazer riscos à sociedade ou até mesmo ao governo. Exemplos de informações sigilosas são:

fiscal, sigilo bancário, comercial, militar entre outros. A classe pag:PagamentoPublico

representa o pagamento que é público, transparente ao interesse público, sem trazer riscos à

sociedade.

A classe pag:Favorecido representa as pessoas, físicas ou jurídicas, que recebem os

pagamentos. Contêm atributos como, pag:identificadorFavorecido e o pag:nomeFavorecido. É

uma classe fundamental uma vez que a informação sobre o favorecido é de bastante interesse por

parte da sociedade e dos órgãos (todos querem saber quem recebeu, quem contratou, em que ano

e quanto).

A classe pag:UnidadeGestora representa as unidades gestoras. É a unidade orçamentária

ou administrativa investida do poder de gerir recursos orçamentários e financeiros, próprios ou

sob descentralização. A classe pag:UnidadeGestora contêm os atributos

pag:codigoUnidadeGestora e pag:nomeUnidadeGestora. Esta classe pode ser vista como uma

entidade classificadora. Ela possui propriedades que descrevem o código e o nome das Unidades

Gestoras. Unidade Gestora é um conceito utilizado na contabilidade pública. Segundo o

glossário do SIAFI, Unidade Gestora é a unidade orçamentária ou administrativa que realiza atos

de gestão orçamentária, financeira ou patrimonial. Este conceito está vinculado à ideia de

responsabilização pelos atos de gestão. É diferente do conceito de Unidade Orçamentária

utilizada para efeito de gestão do orçamento apenas.

30

http://www.acessoainformacao.gov.br/perguntas-frequentes-2/aspectos-gerais-da-lei


68

A Tabela 6 especifica as propriedades de objetos (Object Proprieties) que foram criadas

para a Ontologia OntoPag.

Tabela 6 - Propriedades de objeto da ontologia OntoPag

Propriedade de Objeto Descrição

pag:temFavorecido Propriedade que representa a relação entre a classe

pag:PagamentoPublico (domain) e a classe

pag:Favorecido (range).

pag:temUnidadeGestora Propriedade que relaciona a classe pag:Pagamento

(domain) com a classe pag:UnidadeGestora (range).

pag:temOrgao Propriedade que relaciona a instância da classe

pag:Pagamento (domain) com as instâncias da classe

loa:Orgao (range).

pag:temUnidadeOrcamentaria Propriedade que relaciona a instância da classe


loa:UnidadeOrcamentaria (range).

pag:temFuncao Propriedade que relaciona a instância da classe


loa:Funcao (range).

pag:temSubfuncao Propriedade que relaciona a instância da classe


loa:subFuncao (range).

pag:temPrograma Propriedade que relaciona a instância da classe


loa:Programa (range).

pag:temAcao Propriedade que relaciona a instância da classe


loa:Acao (range).

pag:temGND Propriedade que relaciona a instância da classe


loa:GND (range).

pag:temElemetoDespesa Propriedade que relaciona a instância da classe


loa:ElementoDespesa (range).


69

A Tabela 7 especifica as propriedades de tipos de dados (Data Properties) que foram

criadas para a Ontologia OntoPag.

Tabela 7 - Propriedades de dados da ontologia OntoPag

Propriedade de tipo de

dados

Descrição

pag:identificadorFavorecido Propriedade que representa o número do CPF, para o Favorecido

seja uma pessoa física, ou o número do CNPJ, caso o Favorecido

seja uma pessoa jurídica. Tem como domínio a classe

pag:Favorecido e como range o tipo primitivo xsd:string, para

representar uma cadeia de caracteres.

pag:nomeFavorecido Propriedade que representa o nome de cada Favorecido tem

como domínio pag:Favorecido e range xsd:string.

pag:codigoGestaoPagamento Propriedade que representa o código do Pagamento.

pag:dataPagamento Propriedade que representa a data do Pagamento efetuado.

pag:codigoDocumento Propriedade que representa o número do Documento.

pag:valorPagamento Propriedade que representa o valor do Pagamento.

pag:linguagemCidadã Propriedade que representa nomes mais intuitivos pelos quais as

ações governamentais são apresentadas aos cidadãos.

pag:codigoUnidadeGestora Propriedade que representa o código da Unidade Gestora.

pag:nomeUnidadeGestora Propriedade que representa o nome da Unidade Gestora.

Esta seção mostrou o modelo ontológico que foi estendido da ontologia LOA, assim como

foram explicadas as suas classes e popriedades.

3.3 Considerações

Neste capítulo foi apresentada a metodologia utilizada e as respectivas etapas para o

desenvolvimento da ontologia OntoPag. Uma introdução sobre a ontologia de classificações de

despesas do orçamento federal brasileiro, a LOA, que foi utilizada como base para o

desenvolvimento da ontologia OntoPag . Além disso, foi descrito o processo de desenvolvimento

da ontologia OntoPag, como a descrição das classes e propriedades.

No próximo capítulo será apresentada uma estratégia de tranformação e publicação dos

dados sobre orçamento público e pagamentos/favorecidos. Após esta publicação, será possível

consultar esses dados via endpoint por meio de consultas SPARQL.

Capítulo 4 – COP: Aplicação para conectar e publicar dados orçamentários 70

Capítulo

4 4 COP: Aplicação para conectar e

publicar dados orçamentários

Este capítulo apresenta a aplicação COP, que foi desenvolvida como parte da

solução proposta para publicação de dados conectados do Orçamento Público Federal.


4.1 Arquitetura da Aplicação COP

O acesso aos dados das finanças públicas é essencial para a transparência das ações dos

governos, em geral, aumentando a capacidade de confiança por parte da sociedade e

responsabilidade dos administradores. Os movimentos da Nova Gestão Pública e da Nova

Gestão das Finanças Públicas (FREDERICKSON, 1996) (POLLITT,2000) apresentam a

importância da transparência como um pré-requisito para a prestação de contas. De acordo com a

Organização para Cooperação e Desenvolvimento Econômico – OECD - Organization for

Economic Cooperation and Development - (2002), a contribuição para uma boa governança se

dá a partir de uma formulação de políticas públicas por meio do acesso à informação, pesquisa e

participação para promover, assim, uma máxima transparência.

Uma das maneiras de prover acesso aos dados do governo é a partir da publicação de

dados governamentais abertos. Apesar de ser uma iniciativa bastante promissora, em geral, os

dados abertos publicados pelo governo ainda não estão em formatos que permitam a sua fácil

manipulação. Uma grande parcela dos conjuntos de dados governamentais abertos não são

publicados em formatos estruturados. Dentre os dados de orçamento disponíveis, 49,27% foram

publicados em CSV ou XLS e, o restante em PDF (Craveiro et al., 2013). Apenas 30,07% dos

conjuntos de dados estavam em CSV (Craveiro et al., 2013) e não podem ser considerados cinco

estrelas, pois esse formato não suporta links, assim, não é possível nesse cenário fazer a ligação

entre dados orçamentários no Brasil.

Adicionalmente, na publicação de dados estruturados abertos, para garantir que seja

preservada a semântica original das informações, é necessário conhecer a base de dados que se

deseja publicar, ter informação de quais dados estão sendo representados dentro da área de

conhecimento para a qual base foi criada e seus possíveis formatos de representação. Desse

modo, torna-se muito importante a busca por ontologias (ou vocabulários) conhecidas que que

descrevem as informações que se quer publicar. Este passo pode fazer reúso de ontologias,

fundamental para vincular dados, como prega os princípios de Linked Data. Se não forem

encontrados termos de ontologias que definam satisfatoriamente a semântica dos dados a

publicar, deve-se modelar uma ontologia que a defina.

Visando a publicação de dados orçamentários em um formato que possa ser manipulado

por máquinas e que permita a criação de dados conectados, neste trabalho foi desenvolvida a

aplicação COP. Esta aplicação tem como principal objetivo permitir a transformação e

publicação dos dados do Orçamento Público Federal de forma aberta e conectada. Para isso, a

aplicação faz uso da ontologia LOA e da ontologia OntoPag, as quais permitem a representação


de dados sobre Itens de Despesa e Pagamentos. A partir do uso destas duas ontologias, é possível

gerar um conjunto de dados conectados sobre o orçamento, ou seja, dados definidos de acordo

com os princípios de Linked Data. Considerando que os dados do orçamento público estão

distribuídos em diferentes fontes e dados, a aplicação também oferece meios para a extração de

dados e conversão para o modelo RDF.

A Figura 15 apresenta a arquitetura da aplicação COP, que tem como objetivo realizar a

publicação dos dados conectados obtidos a partir de bases de dados do Orçamento Público

Federal. No restante deste capítulo, a arquitetura de aplicação COP será apresentada em detalhes,

bem como seus principais módulos e descrição do funcionamento de cada um deles.

Figura 15 - Arquitetura da Aplicação COP

A arquitetura da aplicação COP apresenta uma visão geral dos módulos para permitir a

publicação e conexão dos dados do Orçamento Público. A arquitetura tem início no módulo de

Extração, Transformação e Carga dos Dados advindos do Portal da Transparência. Após este

módulo completo, o módulo de Mapeamento irá mapear os dados armazenados para um banco

relacional com os conceitos representados em uma ontologia. É a partir deste Módulo que os

dados do Portal de Dados Abertos são utilizados. Com o Mapeamento efetuado, o processo passa


para o Módulo de Triplificação dos dados. É neste que os dados são transformados para o

formato RDF (com os dados do Portal da Transparência e Portal de Dados Abertos). Os dados

triplificados são armazenados em um repositório específico para este tipo de formato, e, por fim,

o Módulo de Publicação e Acesso aos Dados permite aos usuários, por meio de consultas, em

uma linguagem específica, consultar os dados conectados que foram disponibilizados.

4.1.1 Fontes de Dados de Origem

Os dados sobre orçamento público são disponibilizados por meio de ferramentas digitais e,

atualmente, é possível encontrar Portais de Transparência que oferecem dados sobre o

orçamento, em nível federal, estadual e municipal. Os órgãos públicos federais criaram,

progressivamente, formas de dar acesso aos dados e hoje se pode contar com páginas eletrônicas

por unidade orçamentária (ou seja, por órgão – cada Ministério, Agência Pública, Empresa

Estatal, entre outros), como também com ferramentas que concentram os dados do orçamento

das diversas unidades em um só portal. Estas formas de acesso podem ser por meio do Portal

Siga Brasil31

, uma iniciativa do Senado Federal, que consiste em um sistema de informações

sobre orçamento público, que permite acesso ao Sistema SIAFI32

e a outras bases de dados sobre

planos e orçamentos públicos por meio de uma única ferramenta de consulta; e o Orçamento

Federal ao Alcance de Todos (OFAT), da Secretaria de Orçamento Federal (SOF), um

documento simplificado que visa potencializar a acessibilidade aos complexos dados

orçamentários33

(INESC, 2014).

Para o contexto deste trabalho foi utilizado o Portal da Transparência do Governo

Federal34

, que consiste em uma iniciativa da Controladoria-Geral da União (CGU), lançada em

novembro de 2004. A união de vários órgãos públicos que disponibilizam os respectivos dados

para serem armazenaos no portal, as principais fontes de dados que contribuem para essa

iniciativa são o SIAFI (Sistema Integrado de Administração), Caixa Econômica Federal, Banco

do Brasil e Ministérios. O objetivo é aumentar a transparência da gestão pública, permitindo que

o cidadão acompanhe como o dinheiro público está sendo utilizado e ajude a fiscalizar os gastos

realizados pelo governo.

O Portal da Transparência do Governo Federal oferece ao usuário uma forma rápida e

prática na consulta e obtenção dos dados disponíveis. O Portal disponibiliza os conjuntos de

31

http://www12.senado.gov.br/orcamento/tematico 32

Sistema Integrado de Administração Financeira do Governo Federal, que consiste no principal instrumento

utilizado para registro, acompanhamento e controle da execução orçamentária, financeira e patrimonial do Governo

Federal. 33

http://www.orcamentofederal.gov.br/educacao-orcamentaria/ofat/ofat 34

http://transparencia.gov.br/


dados em formato apropriado para download por Exercícios (Anos) e os respectivos meses (ex:

2015, 2014, 2013 entre outros). O formato dos arquivos que ele disponibiliza é o CSV (Comma-

separated Values).

No Portal da Transparência, podem ser encontrados diversos conjuntos de dados como

transferências de Recursos (para estados, municípios, pessoas jurídicas, físicas), dados sobre

Gastos Diretos do Governo Federal (contratação de obras, serviços e compras governamentais,

que podem ser vistas por órgão, por ação governamental ou por favorecidos). Há também

conjuntos de dados de Servidores, Convênios, Imóveis funcionais, Programas sociais, Receitas,

Despesas e Beneficiários, entre outros.

O conjunto de dados de Despesas permite que o cidadão acompanhe como o governo

emprega os recursos públicos para que possa obter tanto informações diárias quanto mensais

sobre essas despesas. Ela é dividida em Despesas por Transferências, que possibilita o

acompanhamento dos recursos públicos transferidos pela União ao exterior, a estados e

municípios brasileiros, ao Distrito Federal, a instituições privadas e aos cidadãos. A segunda

Despesa é a Gastos Diretos – Pagamentos, que será detalhada neste trabalho, que permite

conferir os gastos diretos do Poder Executivo Federal, como na contratação de obras e compras

governamentais, por órgão, despesas por ação governamental, por favorecidos (empresas

privadas ou pessoas físicas), diárias pagas, cartões de pagamento do Governo Federal.

Para este trabalho foram escolhidos os conjuntos de dados das Despesas por Gastos Diretos

- Pagamentos, do ano de 2014 nos períodos dos meses de janeiro a dezembro, pois o interesse é

apenas verificar os gastos que o Estado faz diretamente dos recursos bem como quem foi

favorecido com o pagamento. Não é de interesse, neste momento, as transferências e os repasses

de recursos públicos.

Os Dados de Gastos Diretos são disponibilizados em formato CSV, um para cada mês de

um ano, contendo informações em 24 colunas, sendo elas: Código Órgão Superior; Nome Órgão

Superior; Código Órgão Subordinado; Nome Órgão Subordinado; Código Unidade Gestora;

Nome Unidade Gestora; Código Grupo Despesa; Nome Grupo Despesa; Código Elemento

Despesa; Nome Elemento Despesa; Código Função; Nome Função; Código Subfunção; Nome

Subfunção; Código Programa; Nome Programa; Código Ação; Nome Ação; Linguagem Cidadã;

Código Favorecido; Nome Favorecido; Número Documento Pagamento; Gestão Pagamento;

Data Pagamento; e Valor Pagamento.


A Figura 18 apresenta as informações mencionadas contidas no Portal da Transparência.

Figura 16 - Conjuntos de dados para download

A partir destas informações foi criado um modelo conceitual dos dados como forma de um

melhor entendimento de como estão dispostos os dados. Este modelo possui 3 (três) tabelas, a de

Pagamento, Favorecido e a Unidade Gestora. O modelo conceitual pode ser visto no Apêndice

D.

A entidade pagamento representa de forma integral o CSV disponibilizado, já a entidade

favorecido contém somente o código e nome do favorecido, e a unidade gestora com o código e

nome das unidades. A ideia é que inicialmente todo o conteúdo do arquivo CSV seja carregado

na tabela pagamento, após isso, então, a tabela favorecido será preenchida com os dados já

existentes na tabela pagamento. Essa decisão de criar a tabela favorecido com informações

redundantes (pois as mesmas já existem na tabela pagamento) é uma decisão de projeto visando

a um melhor desempenho na triplificação dos dados.

Para complementar as análises dos dados, tem-se outro Portal importante, que é o Portal

Brasileiro de Dados Abertos35

, onde estão armazenados os conjuntos de dados do orçamento

público.

O Portal funciona como um grande catálogo que facilita a busca e uso de dados publicados

pelos órgãos do governo. O Portal tem o objetivo de disponibilizar todo e qualquer tipo de dado.

Como exemplo, dados da saúde suplementar, do sistema de transporte, de segurança pública,

indicadores de educação, gastos governamentais, processo eleitoral, entre outros. Além disso, o

35

http://dados.gov.br/


portal de dados abertos disponibiliza dados sobre o orçamento público federal. Para este trabalho

os conjuntos de dados do Portal Brasileiro de Dados Abertos serão utilizados no módulo de

mapeamento, já que os dados se encontram em formato RDF, e apenas é necessário referenciar

as instâncias no momento do mapeamento.

4.1.2 Extração, Transformação e Carga dos Dados

Este módulo é responsável pela extração dos dados do Portal da Transparência, limpeza

desses dados e o armazenamento em um banco de dados relacional.

Na aplicação proposta são tratados apenas arquivos em formato CSV, uma vez que este é o

formato encontrado no Portal da Transparência. Esse processo pode ser comparado a um

processo convencional de ETL (Extract Transform Load) (Kozielski e Wrembel, 2008). Este

trabalho não utilizará o processo de ETL à risca ou alguma ferramenta específica, porém é usado

o conceito.

Apenas para facilitar o entendimento do que é realizado por este módulo, será apresentada

uma breve ideia do conceito de ETL. Segundo Kozielski e Wrembel (2008, p. 21), este processo

constitui de 3 (três) etapas, que são: extração, transformação e carga.

1. Extração: é a primeira etapa do processo ETL, sendo responsável pela aquisição e

extração do conteúdo de fontes de dados heterogêneas (LIU e ZSU, 2009, p. 677).

2. Transformação: é o processo que transforma os dados, ou seja, realiza uma limpeza,

retira inconsistências obtidas através das diversas fontes de dados e, além disso, promove

a padronização do formato dos arquivos dos derivados de várias fontes. Para Liu e Zsu

(2009, p. 677), essa atividade também consiste em refinar e integrar os dados.

3. Carga: etapa que efetua a carga dos dados transformados que podem estar armazenados

em um ou vários bancos de dados relacionais ou em outros repositórios. Para Liu e Zsu

(2009, p. 677), consiste em carregar os dados em repositórios de dados após a sua

concepção previamente definida.

No Módulo de ETL deste trabalho, para realizar estes procedimentos citados, foi escolhida

uma linguagem de script para este processo de Extração – Limpeza – Carga.

A linguagem utilizada foi o shell script, mais especificamente para o interpretador padrão

da maioria das distribuições Linux, o Bash. Esta escolha se deve pela facilidade de programação

e sua interação nativa com os binários existentes em um ambiente Linux, o que facilita bastante


quando se trabalha com rotinas de infraestrutura (e.g. rotinas de backup, rotinas de carga, rotinas

de envio de email, entre outras).

A extração dos dados consiste em realizar o download automático dos arquivos CSV

contendo os dados de pagamentos em forma tabular, acessíveis no Portal da Transparência. O

download é parametrizado com o mês e o ano do dado a que refere, sendo acessível via a URL36

.

Além da realização do download do arquivo é necessário descompactá-lo, pois eles se encontram

originalmente em formato ZIP.

A etapa de transformação de dados consiste em adequar o arquivo CSV para o banco de

dados escolhido, o Postgresql. Foram realizadas 4 (quatro) tarefas de transformação:

1. Conversão do formato de codificação dos caracteres de Latin1 (ISO 8859-1) para o

formato UTF-8, formato padrão de um banco de dados Postgresql;

2. Substituição do separador de casas decimais de vírgula (",") para ponto ("."), pois no

arquivo fonte CSV eles se encontram com vírgula, enquanto o Postgresql para interpretá-

lo necessita que seja separado com ponto;

3. Substituição de bytes que representam valores nulos, no caso, o arquivo CSV utilizou um

byte nulo (0x00 na base hexadecimal), mas para o Postgresql esse tipo de byte não é

interpretado, sendo necessário substituir esse byte por um tipo de flag que representa a

nulidade (e.g., a string "<null>");

4. Substituição da mensagem que representa informações sigilosas (no caso a mensagem é

"Informações protegidas por sigilo, nos termos da legislação, para garantia da segurança

da sociedade e do Estado"). Como decisão de projeto, essa mensagem também foi

convertida para a flag de representação de nulidade, pois, já que os dados não estavam

presentes, não seria interessante para a modelagem dos dados representá-los.

Um dos grandes benefícios do uso do shell script é a sua integração nativa com os

comandos Linux, e isso foi essencial na interação com o banco de dados Postgresql, já que o

mesmo disponibiliza o programa "psql" como cliente do seu serviço, este sendo utilizado para

realizar a carga dos dados. Usando o psql e a devida configuração de conexão com o banco de

dados, os arquivos CSV foram carregados via o comando "COPY37

" do interpretador do

Postgresql.

Ao final do processo, foram carregados 6.073.760 registros de pagamentos para o ano de

2014, além da identificação e enumeração de 1.793.070 de registros de favorecidos distintos,

36

http://arquivos.portaldatransparencia.gov.br/downloads.asp?a=<ANO>&m=<MES>&consulta=GastosDiretos 37

http://www.postgresql.org/docs/9.4/static/sql-copy.html

http://arquivos.portaldatransparencia.gov.br/downloads.asp?a=

http://www.postgresql.org/docs/9.4/static/sql-copy.html


entre eles pessoas jurídicas e pessoas físicas. Esses dados são oriundos de 12 arquivos CSV (1

para cada mês), o que totalizou o tamanho de mais de 7GB de informações em texto UTF-8.

A Figura 19 apresenta o processo de extração dos conjuntos de dados e carregamento no

banco de dados relacional.

Figura 17 - Extração e Carga na base de dados

Todo esse processo foi realizado utilizando uma máquina virtual com a ferramenta

VirtualBox38

, sendo instalado o sistema operacional Debian 7 e o banco de dados Postgresql 9.3.

A configuração da VM foi de 3GB de memória RAM e 1 CPU para processamento. O processo

de extração, transformação e carga dos dados levou aproximadamente 4 horas, para os dados de

pagamentos do ano de 2014.

Como forma de dados estatísticos, a quantidade de registros no banco relacional referente à

tabela de Favorecidos é igual a 1.793.070 de registros; a quantidade de registros no banco

relacional de Unidades Gestoras é igual a 3.606 de registros; a quantidade de registros no banco

relacional de Pagamentos é igual a 14.942.368 de registros.

4.1.3 Mapeamento

O mapeamento entre o modelo relacional e o modelo RDF tem sido alvo de um amplo

corpo de pesquisa em diversas áreas e tem levado à implementação tanto de ferramentas

genéricas de mapeamento, como de aplicações de domínio específico. Além disso, o papel de

38

https://www.virtualbox.org/


RDF como um modelo de integração para dados de múltiplas fontes, principalmente as

relacionais, é uma das fundamentais motivações que têm estimulado pesquisas sobre

mapeamentos de dados relacionais para RDF (SAHOO et al., 2009).

De maneira geral, o mapeamento entre um Banco de Dados Relacional (BDR) e RDF pode

ser efetuado por meio de duas técnicas: a do mapeamento estático e a do mapeamento dinâmico.

O mapeamento estático, também chamado de RDF dump, é uma técnica em que um repositório

RDF é criado a partir da conversão de todas as tabelas e colunas de um BDR, com base em um

arquivo de mapeamento. A outra técnica é o mapeamento dinâmico que efetua a conversão das

tabelas e colunas de um BDR para o formato de triplas RDF on-line, ou seja, de acordo com as

respostas a serem retornadas às consultas elaboradas pelo usuário ou pelas ferramentas de

publicação de dados abertos ligados (ZHOU, 2010).

Existem diversas linguagens de mapeamento entre BDR e RDF (HERT et al., 2011).

Dentre as principais pode-se destacar: o SquirrelRDF (STEER, 2006), eD2R (BARRASA et al.,

2003), R2O (BARRASA et al., 2004), Relational.OWL (LABORDA et al., 2005), R3M

(HERT et al., 2010), Triplify (AUER et al., 2009), R2RML (DAS et al., 2012) e D2RQ

(BIZER et al., 2004).

Para este trabalho foi adotada a ferramenta D2RQ, uma linguagem declarativa escrita em

RDF na representação Turtle. A biblioteca D2RQ é uma API Java, que permite consultar bancos

de dados relacionais em SPARQL, acessar conteúdo de banco de dados através de Linked Data

(BIZER et al., 2009), criar cópias de banco de dados em formato RDF e acessar informações de

banco de dados através da API JENA. Sua utilização torna mais fácil o mapeamento de tabelas e

colunas de RDBs para as classes e propriedades de uma ontologia (HEBELER et al., 2009).

A arquitetura da plataforma D2RQ pode ser visualizada na Figura 23. Os mapeamentos

entre o esquema relacional e os vocabulários RDFS ou ontologia OWL são expressos em uma

linguagem declarativa de mapeamentos.


A Figura 20 ilustra os componentes do framework D2RQ.

Figura 18 - Componentes da arquitetura do framework D2RQ. Fonte: (Bizer et. al., 2004)

Os 3 (três) principais componentes que compõem a arquitetura são (BIZER et al., 2004):

D2RQ Server: um servidor HTTP que permite a visualização dos dados através de

HTML, Linked Data e protocolo SPARQL para serviços Web;

D2RQ Mapping File: uma linguagem declarativa para descrever os mapeamentos

das relações entre uma ontologia e um modelo de dados relacional;

D2RQ Engine: um plug-in para o JENA, que utiliza mapeamentos para reescrever

as consultas em SPARQL para consultas SQL e repassa os resultados da consulta

até as camadas que os chamou.

O D2RQ foi escolhido para ser utilizado neste trabalho por alguns fatores, dentre os quais:

flexibilidade da linguagem de mapeamentos, comandos simples e geração de dumps RDF,

tornando possível reutilizar este dataset em conjunto com outras ferramentas de publicação de

dados na Web Semântica, além desta plataforma.

Neste contexto, o módulo de Mapeamento é responsável pela definição das

correspondências entre as tabelas do banco de dados relacional (BDR) que armazenam os dados

extraídos do Portal da Transparência e as classes da ontologia OntoPag, bem como das colunas

para as propriedades da ontologia. Utilizando o componente de mapeamento da D2RQ (Mapping


File), foi criado um arquivo de mapeamento (mapping-ontopag.ttl) que irá relacionar a base de

dados criada com as classes e instâncias das ontologias.

Em um arquivo de mapeamento o banco de dados é mapeado para termos RDF utilizando

d2rq:ClassMaps e d2rq:PropertyBridges. A cláusula d2rq:ClassMaps é o objeto mais

importante dentro do mapeamento. Um map representa uma classe ou um grupo de classes

semelhantes da ontologia. Ele especifica como os URIs são gerados para as instâncias da classe.

Estes têm um conjunto de d2rq:PropertyBridges, que especificam como as propriedades de uma

instância são criadas. Já a cláusula d2rq:PropertyBridges é usada para anexar propriedades para

os recursos RDF criados por um ClassMap. Os valores destas propriedades são frequentemente

literais, mas também podem ser URIs ou nós em branco que se relacionam com o recurso a

outros recursos.

A plataforma D2RQ provê 6 (seis) mecanismos diferentes para atribuição de

identificadores das instâncias no banco de dados, são:

1. URI patterns: instanciados por meio da inserção de valores de determinadas colunas do

banco de dados em um padrão;

2. Relative URI patterns: padrão URI que gera relative URIs;

3. URI columns: bases de dados que já contêm URIs que podem ser usadas como

identificadores de recursos;

4. URI expressions: podem ser gerados por meio de uma expressão SQL, especificada pela

propriedade com um d2rq:uriSqlExpression. A expressão produz um URI válido;

5. Blank nodes;

6. Singleton class maps: produz apenas um único recurso com identidade estática fixa, já

que o ClassMap geralmente produz muitos recursos.


A Figura 21 apresenta um exemplo de mapeamento de Favorecido.

Figura 19 - Mapeamento da Classe Favorecido

A Figura 21 apresenta o mapeamento entre a Tabela Favorecido e a Classe favorecido e os

respectivos atributos da ontologia OntoPag. No arquivo, o d2rq:ClassMaps representa a classe

map:favorecido que define como as instâncias da classe são identificadas. O d2rq:dataStorage

representa a referência na qual as instâncias dos dados são armazenadas. O d2rq:uriPattern

especifica um padrão URI, que é usado para identificar as instâncias da classe mapeada, como

ilustra o exemplo da Figura 24, d2rq:uriPattern:

<"http://www.cin.ufpe.br/~wsf/ontopag/id/Favorecido/@@favorecido.cod_favorecido|urlify@@

";>. A propriedade d2rq:class apresenta a classe OWL. Todos os recursos gerados por ClassMap

são instâncias da classe favorecido. E o d2rq:classDefinitionLabel especifica um rótulo, uma

etiqueta para todas as definições de classe associados.

A propriedade d2rq:PropertyBridges especifica como as propriedades de uma instância

são criadas para o map:favorecido. Na propriedade d2rq:belongsToClassMap especifica que a

propriedade pertence a uma classe da propriedade d2rq:ClassMap, ou seja, o map:favorecido. A

propriedade d2rq:property especifica a propriedade RDF que liga o ClassMap com o objeto ou

literal que foi criado. Deve ser especificado para cada d2rq:PropertyBridges, as propriedades

pag:codigoFavorecido e pag:nomeFavorecido. A propriedade d2rq:column especifica

propriedades com valores literais, ou seja, a coluna de banco de dados que contém estes valores,

como: favorecido.cod_favorecido e favorecido.nome_favorecido.

http://www.semanticweb.org/wf/2015/08/ontopag/id/Favorecido/@@favorecido.cod_favorecido%7Curlify@@

http://www.semanticweb.org/wf/2015/08/ontopag/id/Favorecido/@@favorecido.cod_favorecido%7Curlify@@


A Figura 22 apresenta um exemplo do mapeamento de Pagamento.

Figura 20 - Mapeamento da Classe Pagamento.

A Figura 22 apresenta o mapeamento entre a Tabela Pagamento e a Classe pagamento e os

respectivos atributos da ontologia OntoPag, bem como a ligação com as instâncias da ontologia

LOA. Este arquivo de mapeamento também contém as cláusulas d2rq:ClassMaps e as

respectivas propriedades (d2rq:dataStorage, d2rq:uriPattern, d2rq:class,

d2rq:classDefinitionLabel), bem como a cláusula d2rq:PropertyBridges e as respectivas

propriedades (d2rq:belongsToClassMap, d2rq:property, d2rq:classDefinitionLabel).

Além dessas propriedades, a d2rq:PropertyBridges também tem uma importante

propriedade para o mapeamento que é a d2rq:uriSqlExpression (propriedade em que o valor

pode ser uma URI em vez de um literal). Funcionam da mesma forma da d2rq:ClassMap, então,

para esse mapeamento, é utilizado o mecanismo de identificadores para as instâncias o URI

expressions que, por meio de expressões SQL, são geradas URI válidas utilizando a propriedade

d2rq:uriSqlExpression.

Um exemplo da propriedade d2rq:uriSqlExpression pode-se observar no arquivo de

mapeamento na Figura 24 de Órgão: d2rq:uriSqlExpression "CASE WHEN

pagamento.data_pagamento IS NULL THEN 'http://orcamento.dados.gov.br/id/2014/Orgao/' ||

pagamento.cod_orgao_superior ELSE 'http://orcamento.dados.gov.br/id/' || EXTRACT(YEAR

FROM pagamento.data_pagamento) || '/Orgao/' || pagamento.cod_orgao_superior END";.


4.1.4 Triplificação

O Módulo de Triplificação visa à conversão dos dados persistidos no esquema relacional

para o formato RDF. A ferramenta D2RQ é a responsável por triplificar os dados relacionais,

gerando como saída um arquivo RDF. Ela é capaz de gerar mapeamentos automáticos da base

relacional, no entanto, não são suficientes para descrever as relações entre as tabelas e a

ontologia. Para efetuar esta conversão, foi necessário descrever a relação entre o modelo de

dados relacional e a ontologia em um arquivo de mapeamento que foi apresentado na seção

anterior. Para que esta tarefa seja concluída, é necessária a configuração deste arquivo de

mapeamento mencionado.

Além disso, neste arquivo de mapeamento, é essencial que na primeira parte deste

mapeamento seja configurada a conexão para o banco relacional remoto ou local.

A Figura 23 apresenta a definição dos parâmetros de conexão com o banco de dados

relacional.

Figura 21 - Parâmetros de conexão utilizados pelo arquivo de mapeamento.

A Figura 23 apresenta um conjunto de namespaces que demonstram os diferentes

contextos utilizados. O prefixo pag representa a ontologia de domínio que foi criada neste

trabalho. Em seguida, são informados os parâmetros de conexão com o banco de dados

relacional, assim como URL, driver de conexão, usuário e sua respectiva senha.

Após o arquivo de mapeamento ser configurado, é possível realizar a transformação

concreta dos dados persistidos no banco de dados relacional para um único arquivo RDF. Esta

conversão é realizada pela ferramenta Dump-rdf, presente na plataforma D2RQ, com objetivo de

realizar uma conversão materializada dos dados.


Para realizar a triplificação, é necessário apenas informar o formato de serialização do

arquivo de saída, o padrão de URL a ser utilizado e o próprio arquivo de mapeamento. Segue a

linha de execução do comando para realizar a triplificação dos dados de pagamentos.

Dump-rdf –f N-TRIPLES –o ontopag-rdf.nt mapping-ontopag.ttl

-o ontopag-rdf.nt, indica que o arquivo RDF gerado será chamado ontopag-rdf.nt

mapping-ontopag.ttl, indica qual é o arquivo de mapeamento a ser utilizado

O formato de serialização N-TRIPLE (o mais ideal para grande volume de dados)

representa a informação de maneira simples, não fazendo uso de namespaces e abreviações.

Entretanto, reduz drasticamente o tempo da triplificação se comparado a outros tipos mais

utilizados como, por exemplo, o TURTLE, justificando, assim, sua escolha (Beckett et al.,

2014).

Após executar o script da triplificação dos dados foram gerados alguns dados estatísticos

como: a quantidade total de triplas geradas foi de 264.215.111 de triplas em um tempo

aproximado de triplificação de 19 horas para o arquivo de pagamento do ano de 2014, que gerou

um tamanho do arquivo RDF (*.nt) igual a 45BG e compactado em formato GZIP(*.nt.gz) igual

a 1,2GB.

Para exemplificar, a Figura 24 apresenta um exemplo de um arquivo RDF que foi gerado

na triplificação. O exemplo apresenta as sentenças RDF criadas, tomando como base a definição

de conceitos e relações da ontologia e deram origem a uma descrição RDF serializada em

formato Turtle.


Figura 22 - Arquivo RDF (Formato Turtle) gerado

Na Figura 24, da linha 1 até a linha 4 estão definidos os prefixos para os seguintes

namespaces que compõem a descrição RDF: (i) http://www.w3.org/1999/02/22-rdf-syntax-ns# –

faz referência ao vocabulário padrão RDF; (ii) http://www.cin.ufpe.br/~wsf/ontopag/ - para as

definições da ontologia; (iii) http://www.w3.org/2001/XMLSchema# – namespace padrão para a

definição dos tipos de dados utilizados na especificação; e (iv) http://www.w3.org/2000/01/rdf-

schema# – faz referência ao vocabulário padrão RDF.

Na linha 6, é apresentado o recurso pagamento e da linha 7 até a linha 22 são descritas as

propriedades que o pagamento tem, os datatype properties e object properties. Da linha 24 em

diante são os dados sobre os recursos a que o pagamento se refere, descrevendo também as suas

propriedades.


Outro exemplo de arquivo RDF gerado na triplificação é apresentado na Tabela 8, que

representa algumas sentenças RDF serializadas em formato N-Triples.

Tabela 8 - Exemplo de N-Triples

Sujeito Predicato Objeto

<http://www.cin.ufpe.br/~wsf/ontopag/id/

Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temFa

vorecido>

<http://www.cin.ufpe.br/~wsf/ontopag/id/Favorec

ido/18715508000131> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#lingua

gemCidada>

"Administra\u00E7\u00E3o de unidade" .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temG

ND>

<http://orcamento.dados.gov.br/id/2014/GrupoNa

tDespesa/3> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temPr

ograma>

<http://orcamento.dados.gov.br/id/2014/Program

a/2125> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#codig

oDocumento>

"2014OB800174" .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#valor

Pagamento>

"153.22"^^<http://www.w3.org/2001/XMLSche

ma#decimal> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#dataP

agamento>

"2014-02-

06"^^<http://www.w3.org/2001/XMLSchema#da

te> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temEl

ementoDespesa>

<http://orcamento.dados.gov.br/id/2014/Elemento

Despesa/92> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#codig

oGestaoPagamento>

"11301" .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temU

nidadeOrcamentaria>

<http://orcamento.dados.gov.br/id/2014/Unidade

Orcamentaria/47205> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temS

ubfuncao>

<http://orcamento.dados.gov.br/id/2014/Subfunca

o/122> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temA

cao>

<http://orcamento.dados.gov.br/id/2014/Acao/20

00> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temF

uncao>

<http://orcamento.dados.gov.br/id/2014/Funcao/0

4> .


Pagamento/667607>

<http://www.cin.ufpe.br/~wsf/ontopag#temO

rgao>

<http://orcamento.dados.gov.br/id/2014/Orgao/20

113> .


Pagamento/667607>

<http://www.w3.org/2000/01/rdf-

schema#label>

"Administra\u00E7\u00E3o de unidade" .


Pagamento/667607>

<http://www.w3.org/1999/02/22-rdf-syntax-

ns#type>

<http://www.cin.ufpe.br/~wsf/ontopag#Pagament

o> .

A Tabela 8 apresenta as triplas RDF que representam o Pagamento. Cada linha da tabela

representa uma única tripla, onde o sujeito de todas as triplas descritas é o mesmo recurso

<http://www.cin.ufpe.br/~wsf/ontopag/id/Pagamento/667607> (o Pagamento em questão).

No formato de serialização N-Triples não existem prefixos para os namespaces, então eles

ficam descritos completamente nos recursos, classes e propriedades. Nesta parte explicada do

RDF estão contidos 4 diferentes namespaces, (1)

http://www.cin.ufpe.br/~wsf/ontopag/id/NOME_DA_CLASSE/ID_UNICO_INSTANCIA -


representam os recursos (instâncias) dos dados de pagamento, (2)

http://www.cin.ufpe.br/~wsf/ontopag#PROPRIEDADE_OU_CLASSE - representam as

propriedades e classes da ontologia de Pagamentos definidos no arquivo OWL disponibilizado,

(3) http://www.w3.org/1999/02/22-rdf-syntax-ns#PROPRIEDADE - representa o vocabulário

padrão do RDF. Neste caso foi utilizada a sua propriedade type para indicar a que classe um

recurso pertence, (4) http://www.w3.org/2001/XMLSchema#PROPRIEDADE - representa o

vocabulário padrão de definição de tipos de dados.

Nessa parte do arquivo estão listadas as propriedades e atributos de alguns dos recursos

que se relacionaram com o pagamento e item de despesa, mais especificamente, foram definidos

os seus tipos, códigos e descrições. Os recursos que não foram listados seguem o mesmo padrão.

Para apresentar como é realizada a triplificação, tem-se a seguinte maneira, por exemplo: o

Portal da Transparência, já contém em suas informações QUAL É A AÇÃO relacionada aquele

pagamento, por exemplo, em algum dos registros do arquivo CSV tem um pagamento de R$

50,00, nesta mesma linha fala qual é o CÓDIGO da função, subfunção, programa, ação, etc, que

está relacionado com este pagamento específico de R$ 50,00.

A partir do código da ação consegue-se realizar uma ligação com o recurso RDF, desta

mesma ação que está publicada na internet, ou seja, se a ação tem o código A100, pode-se fazer

uma ligação do pagamento com o recurso http://orcamento.dados.gov.br/id/2014/Acao/A100, em

que 2014 é o exercício financeiro da ação, e consegue-se o ano a partir da DATA do pagamento.

4.1.5 Publicação e Acesso aos Dados

Por fim, o Módulo de Publicação e Acesso aos dados que finaliza o fluxo da arquitetura da

aplicação COP. É neste momento que os dados de pagamentos e orçamentários são publicados,

disponibilizados ao acesso de qualquer pessoa que tenha interesse nessas informações por meio

de consultas. Também pode-se efetuar o download do arquivo em formato RDF na URL39

.

Toda organização que deseja publicar conjuntos de dados deve manter um repositório de

dados que possa estar disponível na Web. Existem diferentes formas de construção de repositório

de dados na Web. Uma delas é a utilização de ferramentas de Gestão de conteúdo, geralmente

utilizada em portais de órgãos institucionais. Além disso, cada um deles deve possuir

procedimento e normas para manutenção deste catálogo/portal de dados, ser responsável por

garantir a integridade, disponibilidade e autenticidade dos dados disponíveis.

Para a aplicação proposta, após a geração do arquivo RDF foi necessário carregá-lo em um

repositório, um triple store específico para RDF. O repositório de triplas escolhido foi o

39

http://cin.ufpe.br/~wsf/ontopag/

http://orcamento.dados.gov.br/id/2014/Acao/A100


OpenLink Virtuoso40

, que é um servidor multiplataforma que implementa funcionalidades de

servidor Web, servidor de arquivos e de gestor de bases de dados. É uma triple store disponível

com licença aberta. Suporta execução de consultas em SPARQL juntamente com SQL para

consultar dados RDF armazenados dentro do banco de dados (VIRTUOSO, 2015). No servidor

Digital Ocean41

foi criado uma instância do Virtuoso que está disponível na URL42

para consulta

dos dados utilizando a linguagem SPARQL.

O upload dos arquivos para o triple store foi realizado de forma automática, via script

“carga-remota-virtuoso-ontopag.sh”. Este script faz o upload do arquivo RDF da OntoPag local

para o servidor remoto (Virtuoso) via linha de comando de forma remota com acesso SSH. O

script ainda realiza a carga do RDF da ontologia LOA no ano que fica definido na variável

EXERCICIO_ANO internamente no script, neste caso o ano de 2014.

Ao executar o script da carga do arquivo RDF para o Virtuoso no formato N-Triples foi

analisado que o tempo médio para realizar a carga no servidor Virtuoso foi de aproximadamente

4 (quatro) horas para o ano de 2014 do conjunto de dados de pagamento.

Como resultado da etapa e publicação, qualquer usuário terá a possibilidade de realizar

consultas SPARQL sobre os dados conectados referentes a pagamentos e dados orçamentários

(classificadores dos Itens de Despesa) como Ação, Programa de governo, Função entre outros,

bem como às informações dos favorecidos e, consequentemente, o valor que foi efetuado.

A seguir, são representados alguns exemplos de consultas SPARQL para demonstrar como

pode ser feito o acesso aos dados de pagamentos armazenados no endpoint SPARQL do

Virtuoso.

As Figuras 25 e 26 apresentam, respectivamente, um exemplo de consulta SPARQL e o

resultado da mesma. Este exemplo de consulta SPARQL tem como objetivo realizar o somatório

de todos os pagamentos do ano de 2014.

40

http://virtuoso.openlinksw.com/ 41

https://www.digitalocean.com/signups/ 42

http://104.236.67.141:8890/sparql

http://104.236.67.141:8890/sparql


Figura 23 - Exemplo de Consulta SPARQL – Somatório pagamento 2014

Resultado:

Figura 24 - Resultado da Consulta – Somatório pagamento 2014

As Figuras 27 e 28 apresentam, respectivamente, um exemplo de consulta SPARQL

executada no Endpoint Virtuoso e o resultado da mesma. Este exemplo de consulta SPARQL

tem como objetivo realizar os somatórios de todos os pagamentos públicos e todos os

pagamentos sigilosos.


Figura 25 - Exemplo de Consulta SPARQL – Pagamentos Públicos/Sigilosos

Resultado:

Figura 26 - Resultado da consulta – Pagamentos Públicos/Sigilosos

As Figuras 29 e 30 apresentam, respectivamente, um exemplo de consulta SPARQL

executada no Endpoint Virtuoso e o resultado da mesma. Este exemplo de consulta SPARQL

demonstra a conexão dos dados de pagamentos (OntoPag) com orçamento (LOA) e tem como

objetivo realizar um somatório de todos pagamentos realizados ao favorecido "CAIXA

ECONOMICA FEDERAL [CEF MATRIZ]"" (CNPJ igual a "00360305000104"), agrupando os

valores por Esfera (Classificação de uma despesa que identifica se está inserida no orçamento

fiscal, seguridade social ou investimento das empresas estatais).


Figura 27 - Exemplo de Consulta SPARQL – Valores Esfera

Resultado:

Figura 28 - Resultado da Consulta conectada

Esta consulta é um ótimo exemplo para apresentar a conexão dos dados de pagamento e

orçamento, da ontologia OntoPag com a ontologia da LOA. A informação de Esfera está

presente apenas na base do orçamento (ontologia LOA) e não está presente em pagamentos

(ontologia OntoPag). Então, para que seja necessário somar os pagamentos realizados ao

favorecido em questão, e ainda agrupando os valores por Esfera, é preciso consultar as duas

bases, realizando a conexão via os itens de despesa da LOA.


4.2 Considerações

Neste capítulo foi apresentada a arquitetura da aplicação da solução proposta para

conectar e publicar dados abertos do domínio orçamentário. O processo de publicação pode ser

dividido em módulos como, análise dos dados, a extração e carga em um banco relacional, o

mapeamento com a ontologia, a transformação para um arquivo em formato RDF e, por fim, o

acesso a esses dados. Também foram apresentados exemplos de consultas que ilustram o acesso

aos dados conectados.

Capítulo 5 – Avaliação da ontologia OntoPag 94

Capítulo

5 5 Avaliação da ontologia OntoPag

Este capítulo tem como objetivo apresentar os passos executados na avaliação da

ontologia OntoPag por meio das Questões de Competência como forma de avaliar a proposta

do trabalho.


5.1 Avaliação da Ontologia OntoPag

O processo de avaliação de uma ontologia visa verificar e validar se a ontologia expressa

corretamente o mundo real de acordo com o seu conceito, taxonomia e axiomas. A avaliação de

ontologias é um tópico, por si só, complexo e, normalmente, é medido pela capacidade que a

ontologia oferece em responder a um conjunto de questões às quais ela deve trazer respostas.

Após a realização da avaliação, garante-se que a ontologia corresponde à sua suposta finalidade,

de acordo com os documentos de especificação de requisitos (Bortolato, 2014).

A Verificação da Ontologia avalia se a ontologia está sendo desenvolvida corretamente, de

acordo com os requisitos levantados e o planejamento do projeto de construção. Já a Validação

da Ontologia é a atividade que confere os significados das definições e conceitos da ontologia

em relação aos conceitos do mundo real que se pretende conceitualizar e modelar. Esta forma de

avaliação assegura que a ontologia está sendo construída corretamente, que atenda à necessidade

e requisitos dos usuários (respondendo corretamente as questões de competência), constituindo

importante parte do processo de medição da qualidade de ontologias e procurando assegurar a

acurácia do conhecimento codificado na ontologia em relação ao domínio (GÓMEZ-PÉREZ,

CORCHO e FERNÁNDEZ-LÓPEZ, 2004). Questões de Competência (QCs) representam as

questões que a ontologia deve ser capaz de responder. Essas questões, além de justificar a

existência da ontologia, servem para auxiliar a avaliação da ontologia depois de construída.

Avaliar ontologias é uma atividade em que se torna maior a necessidade de interação com

especialistas de domínio e também com os usuários da ontologia. Foram identificados alguns

requisitos juntamente com especialistas do domínio. O envolvimento de usuários e especialistas

poderá avaliar a ontologia em relação à sua utilidade, usabilidade e reutilização em outras

aplicações.

A avaliação realizada teve como objetivo identificar se a ontologia OntoPag consegue

alcançar seu objetivo principal, que é permitir a disponibilização de dados sobre Pagamentos,

bem como sua vinculação com a ontologia LOA. A seguir, é descrito o método de avaliação nas

seguintes etapas definidas no método de Ghomari e Ghomari (2013) para a avaliação da

ontologia construída.

1. Selecionar QCs: constatou-se um total de 10 QCs levantadas na especificação de requisitos,

no entanto, foi gerada uma lista de QCs selecionadas para a Validação da Ontologia.

Algumas foram traduzidas, na atividade subsequente, para consultas SPARQL.

2. Traduzir QCs selecionadas: efetuaram-se algumas traduções das QCs selecionadas na

Atividade 1 para consultas em SPARQL. As tarefas executadas foram:


2.1. Identificar categorias das QCs: identificar a categoria de cada uma delas. A Tabela 9

apresenta as Questões de Competências (QCs) selecionadas.

Tabela 9 - Tabela de QCs

QCs Questão de Competência Categoria

QC1 Realiza os somatórios de todos os pagamentos públicos e todos os

pagamentos sigilosos?

Questões

Factuais (QF)

QC2 Realiza o somatório de todos os pagamentos com a função "Educação"

(código "12")?

Questões

Factuais (QF)

QC3 Realiza o agrupamento de todos os favorecidos por função, ordenando

do que mais recebeu pagamentos para o que menos recebeu?

Questões de

Listas (QL)

QC4 Realiza o somatório de todos os pagamentos a todos os favorecidos? Questões

Factuais (QF)

QC5 Realiza o somatório de todos os pagamentos sigilosos, agrupando pelo

Órgão Superior, Órgão (Unidade Orçamentária) e Unidade Gestora?

Questões

Factuais (QF)

QC6 Realiza o somatório de todos os pagamentos para favorecidos em que

o seu identificador possui 11 dígitos (quantidade presente no CPF)?

Questões

Factuais (QF)

QC7 Lista todos os pagamentos feitos a pessoa física "ERAI MAGGI

SCHEFFER" (CPF igual a "33511705991"). Essa pessoa é um grande

fazendeiro brasileiro.

Questões de

Listas (QL)

QC8 Faz um somatório de todos pagamentos realizados ao favorecido

"CAIXA ECONOMICA FEDERAL [CEF MATRIZ]"" (CNPJ igual a

"00360305000104"), agrupando os valores por Subtítulo (Localizador

orçamentário da despesa)?

Questões

Factuais (QF)

QC9 Lista favorecidos de um grupo de itens, pesquisando pelo nome? Questões de

Listas (QL)

QC10 Lista todos os pagamentos de um Grupo de Itens agrupando por

favorecido?

Questões

Factuais (QF)


2.2. Determinar respostas esperadas: procurou-se determinar a resposta esperada para cada

uma das QCs selecionadas e categorizadas. A Tabela 10 apresenta as respostas

esperadas.

Tabela 10 - Tabela das respostas esperadas das QCs

QCs Respostas Esperadas

QC1 Valor do Pagamento Público

Valor do Pagamento Sigiloso

QC2 Soma dos pagamentos

Função

QC3 Favorecidos

Função

Valores

QC4 Valor Somado e os Favorecidos

QC5 Todos os pagamentos sigilosos

QC6 Valor total para cada favorecido

QC7 Lista os pagamentos de um favorecido

QC8 Valores do pagamento e os favorecidos

QC9 Apresenta os favorecidos

QC10 Valores do pagamento

Alguns grupo de Itens

Favorecido

2.3. Extrair entidades das QCs e das respostas: extração dos termos relevantes tanto das

QCs quanto das suas respostas e que tivessem alguma entidade equivalente na ontologia

para que a consulta SPARQL seja capaz de obter alguma resposta. A Tabela 11

apresenta a lista de QCs, os termos extraídos e suas entidades correspondentes na

ontologia.


Tabela 11 - Tabela das entidades extraídas das QCs e suas respostas

QCs Termos da QC Termos da Resposta Entidades na ontologia

QC1 Somatórios

Pagamentos sigilosos

Pagamentos públicos

Valor do Pagamento

Público

Valor do Pagamento

Sigiloso

Valor Pagamento

Valor do Pagamento

Sigiloso

QC2 Somatórios

Pagamentos

Função (Item de Despesa)

Soma dos pagamentos

Função

Valor Pagamento


QC3 Favorecidos


Pagamentos

Favorecidos

Função

Valores

Favorecidos


Valor Pagamento

QC4 Somatórios

Pagamentos

Favorecidos

Valor Somado

Favorecidos

Valor Pagamento

Favorecido

QC5 Somatórios

Pagamentos sigilosos

Item de Despesa(Órgão, UO,

UG)

Todos os pagamentos

sigilosos

Valor Pagamento

Grupo Itens (Item de

Despesa)

QC6 Somatórios

Pagamentos

Favorecidos

Identificador

Valor total para cada

favorecido

Valor Pagamento

Favorecido

QC7 Pagamentos

Favorecidos

Identificador

Lista os pagamentos de

um favorecido

Valor Pagamento

Favorecido

QC8 Somatórios

Pagamentos

Favorecidos

Item de Despesa(Subtítulo)

Valores do pagamento

e os favorecidos

Valor pagamento

Favorecido

Item Despesa

QC9 Favorecidos

Grupo de Itens (Item de

Despesa)

Apresenta os

favorecidos

Favorecido

Grupo Itens

QC10 Pagamentos

Grupo de Itens (Item de

Despesa)

Favorecidos

Valores do pagamento

Alguns grupo de Itens

Favorecido

Valor pagamento

Grupo Itens

Favorecido


2.4. Identificar os tipos das entidades da ontologia: as entidades da ontologia identificadas

foram representadas na consulta SPARQL por meio de classes, propriedades de dados,

propriedades de objeto, anotações ou instância. Os tipos identificados e o mapeamento

das entidades podem ser encontrandos na Tabela 12.

Tabela 12 – Tabela com entidades e sua localização na ontologia

QCs Tipo de Entidade Localização

QC1 Classes

pag:Pagamento

Propriedade

valorPagamento

pag:PagamentoSigiloso e

pag:PagamentoPublico é subClassOf de

pag:Pagamento

QC2 Classes

pag:Pagamento

loa:Funcao

Propriedade

valorPagamento

codigoFuncao

nomeFuncao

pag:Pagamento pag:temFuncao

loa:Funcao

QC3 Classes

pag:Pagamento

loa:Funcao

pag:Favorecido

Propriedade

codigofuncao

nomefuncao

codigoFavorecido

nomeFavorecido

valorPagamento


loa:Funcao

pag:Pagamento pag:temFavorecido

pag:Favorecido

QC4 Classes

pag:Pagamento

pag:Favorecido

Propriedade

codigoFavorecido

nomeFavorecido

valorPagamento


pag:Favorecido

Continua...


...continuação


QC5 Classes

pag:Pagamento

pag:Favorecido

pag:Unidade Gestora

loa:Orgao

loa:UnidadeOrcamentaria

Propriedade

codigoorgaosuperior

nomeorgaosuperior

codigoorgao

nomeorgao

codigoUnidadeGestora

nomeUnidadeGestora

codigoUnidadeOrcamentaria

nome UnidadeOrcamentaria

valorPagamento


pag:Favorecido

pag:Pagamento pag:temUnidadeGestora

pag:UnidadeGestora

pag:Pagamento pag:temOrgao

loa:Orgao

pag:Pagamento

pag:temUnidadeOrcamentaria


QC6 Classes

pag:Pagamento

pag:Favorecido

Propriedade

codigoFavorecido

nomeFavorecido

valorPagamento


pag:Favorecido

QC7 Classes

pag:Pagamento

pag:Favorecido

loa:Orgao


loa:Funcao

loa:Programa

loa:Acao

Propriedade

codigoFavorecido

nomeFavorecido

valorPagamento

codigoorgao

nomeorgao

codigoUO

nomeUO

codigofuncao

nomefuncao

codigoprograma

nomeprograma

codigoacao

nomeacao


pag:Favorecido

pag:Pagamento pag:temOrgao

loa:Orgao

pag:Pagamento




loa:Funcao

pag:Pagamento pag:temPrograma

loa:Programa

pag:Pagamento pag:temAcao loa:Acao

Continua...


...continuação


QC8 Classes

pag:Pagamento

pag:Favorecido

loa:Subtitulo


loa:Funcao

loa:Subfuncao

loa:Programa

loa:Acao

Propriedade

codigoFavorecido

nomeFavorecido

valorPagamento

codigoSubtitulo

nomeSubtitulo


pag:Favorecido

pag:Pagamento pag:temSubtitulo

loa:Subtitulo

pag:Pagamento




loa:Funcao

pag:Pagamento pag:temSubfuncao

loa:Subfuncao


loa:Programa


QC9 Classes

pag:Pagamento

pag:Favorecido


loa:Acao

Propriedade

codigoFavorecido

nomeFavorecido

valorPagamento


pag:Favorecido


pag:Pagamento



QC10 Classes

pag:Pagamento

pag:Favorecido


loa:Acao

loa:Funcao

loa:Subfuncao

loa:Programa

loa:Acao

loa:GND

loa:ElementDespesa

Propriedade

codigoFavorecido

nomeFavorecido

valorPagamento


pag:Favorecido

pag:Pagamento





loa:Funcao

pag:Pagamento pag:temSubfuncao

loa:Subfuncao


loa:Programa

pag:Pagamento pag:temGND loa:GND

pag:Pagamento

pag:temElementoDespesa

loa:ElementoDespesa


2.5. Construir as consultas SPARQL: uma vez que as respostas esperadas para as QCs, as

entidades e sua localização na ontologia foram identificados, as consultas SPARQL

correspondentes puderam ser escritas. As consultas são apresentadas no próximo tópico

(3).

3. Executar as consultas SPARQL: as consultas obtidas na atividade 2 foram executadas,

registrando-se as respostas obtidas. Para executar essa tarefa, usou-se o Endpoint Virtuoso.

Seguem as consultas e os respectivos resultados.

Consultas SPARQL

Ao acessar o servidor Virtuoso43

, ele permite a realização de consultas SPARQL que

acessam dados obtidos a partir das ontologias, LOA e OntoPag.

A partir do arquivo RDF gerado, podem ser feitas inúmeras consultas SPARQL para

mostrar o cruzamento realizado pelas ontologias abordadas neste trabalho. A seguir, serão

apresentadas as consultas e os resultados que foram gerados a partir das questões de competência

consideradas relevantes.

Consulta 1:

Tabela 13 - Consulta 1

Descrição: Realiza os somatórios de todos os pagamentos públicos e todos os pagamentos

sigilosos.

SELECT

(SUM(?valorPublico) as ?somaPagamentosPublicos)

(SUM(?valorSigiloso) as ?somaPagamentosSigilosos)

WHERE {

{

?pagPublico a pag:PagamentoPublico .

?pagPublico pag:valorPagamento ?valorPublico

}

UNION {

?pagSigiloso a pag:PagamentoSigiloso .

?pagSigiloso pag:valorPagamento ?valorSigiloso

}

}

43

http://104.236.67.141:8890/sparql

http://104.236.67.141:8890/sparql


Resultado:

Figura 29 – Resultado da Consulta 1

Consulta 2:


Descrição: Realiza o somatório de todos os pagamentos com a função "Educação" (código

"12").

SELECT

?codigoFuncaoEducacao

?nomeFuncaoEducacao

(SUM(?valor) as ?somaPagamentos)

WHERE {

?funcao a loa:Funcao .

?funcao loa:codigo "12" .

?funcao loa:codigo ?codigoFuncaoEducacao .

?funcao rdfs:label ?nomeFuncaoEducacao .

?pag pag:temFuncao ?funcao .

?pag pag:valorPagamento ?valor

} GROUP BY ?codigoFuncaoEducacao ?nomeFuncaoEducacao

Resultado:

Figura 30 - Resultado da Consulta 2


Consulta 3:


Descrição: Realiza o agrupamento de todos os favorecidos por função, ordenando do que mais

recebeu pagamentos para o que menos recebeu.

SELECT

?codigoFuncao

?nomeFuncao

?codigoFavorecido

?nomeFavorecido


WHERE {

?funcao a loa:Funcao .

?funcao loa:codigo ?codigoFuncao .

?funcao rdfs:label ?nomeFuncao .


?pag pag:valorPagamento ?valor .

?pag pag:temFavorecido ?favorecido .

?favorecido pag:nomeFavorecido ?nomeFavorecido .

?favorecido pag:codigoFavorecido ?codigoFavorecido .

} GROUP BY ?codigoFuncao ?nomeFuncao ?codigoFavorecido ?nomeFavorecido

ORDER BY DESC(?somaPagamentos)

Resultado:



Consulta 4:


Descrição: Realiza o somatório de todos os pagamentos a todos os favorecidos.

SELECT

?nomeFavorecido

?idFavorecido


WHERE {




?favorecido pag:codigoFavorecido ?idFavorecido .

} GROUP BY ?idFavorecido ?nomeFavorecido


Resultado:



Consulta 5:


Descrição: Realiza o somatório de todos os pagamentos sigilosos, agrupando pelo Órgão

Superior, Órgão (Unidade Orçamentária) e Unidade Gestora.

SELECT

?codigoOrgaoSuperior ?nomeOrgaoSuperior

?codigoOrgao ?nomeOrgao

?codigoUnidadeGestora ?nomeUnidadeGestora

(SUM(?valor) as ?somaPagamentosSigilosos)

WHERE {

?pag a pag:PagamentoSigiloso .


?pag pag:temOrgao ?orgaoSuperior .

?pag pag:temUnidadeOrcamentaria ?orgao .

?pag pag:temUnidadeGestora ?unidadeGestora .

?orgaoSuperior loa:codigo ?codigoOrgaoSuperior .

?orgaoSuperior rdfs:label ?nomeOrgaoSuperior .

?orgao loa:codigo ?codigoOrgao .

?orgao rdfs:label ?nomeOrgao .

?unidadeGestora pag:codigoUnidadeGestora ?codigoUnidadeGestora .

?unidadeGestora pag:nomeUnidadeGestora ?nomeUnidadeGestora .

}

GROUP BY ?codigoOrgaoSuperior ?nomeOrgaoSuperior ?codigoOrgao ?nomeOrgao

?codigoUnidadeGestora ?nomeUnidadeGestora

ORDER BY DESC(?somaPagamentosSigilosos)

Resultado:



Consulta 6:


Descrição: Realiza o somatório de todos os pagamentos para favorecidos em que o seu

identificador possui 11 dígitos (quantidade presente no CPF).

SELECT

?nomeFavorecido

?idFavorecido


WHERE {


FILTER(fn:string-length(?idFavorecido) = 11)




} GROUP BY ?idFavorecido ?nomeFavorecido


Resultado:



Consulta 7:


Descrição: Lista todos os pagamentos feitos à pessoa física "ERAI MAGGI SCHEFFER" (CPF

igual a "33511705991"). Essa pessoa é um grande fazendeiro brasileiro.

SELECT

?idFavorecido ?nomeFavorecido

?codigoOrgao ?nomeOrgao

?codigoUO ?nomeUO

?codigoFuncao ?nomeFuncao

?codigoSubfuncao ?nomeSubfuncao

?codigoPrograma ?nomePrograma

?codigoAcao ?nomeAcao

?valor

WHERE {

?favorecido pag:codigoFavorecido "33511705991" .




?pag pag:temOrgao ?orgao .

?pag pag:temUnidadeOrcamentaria ?uo .


?pag pag:temSubfuncao ?subfuncao .

?pag pag:temPrograma ?programa .

?pag pag:temAcao ?acao .


?orgao rdfs:label ?nomeOrgao .

?orgao loa:codigo ?codigoOrgao .

?uo rdfs:label ?nomeUO .

?uo loa:codigo ?codigoUO .

?funcao rdfs:label ?nomeFuncao .

?funcao loa:codigo ?codigoFuncao .

?subfuncao rdfs:label ?nomeSubfuncao .

?subfuncao loa:codigo ?codigoSubfuncao .

?programa rdfs:label ?nomePrograma .

?programa loa:codigo ?codigoPrograma .

?acao rdfs:label ?nomeAcao .

?acao loa:codigo ?codigoAcao .

} ORDER BY DESC(?valor)


Resultado:


Consulta 8:


Descrição: Realiza um somatório de todos pagamentos realizados ao favorecido "CAIXA

ECONOMICA FEDERAL [CEF MATRIZ]"" (CNPJ igual a "00360305000104"), agrupando os

valores por Subtítulo (Localizador orçamentário da despesa).

SELECT

?codigoSubtitulo

?nomeSubtitulo

?idFavorecido

?nomeFavorecido


WHERE {

?favorecido pag:codigoFavorecido "00360305000104" .




?pag pag:temUnidadeOrcamentaria ?uo .


?pag pag:temSubfuncao ?subfuncao .

?pag pag:temPrograma ?programa .

?pag pag:temAcao ?acao .


?item loa:temUnidadeOrcamentaria ?uo .

?item loa:temFuncao ?funcao .

?item loa:temSubfuncao ?subfuncao .

?item loa:temPrograma ?programa .

?item loa:temAcao ?acao .

?item loa:temSubtitulo ?subtitulo .

?subtitulo rdfs:label ?nomeSubtitulo .

?subtitulo loa:codigo ?codigoSubtitulo .

} GROUP BY ?codigoSubtitulo ?idFavorecido ?nomeSubtitulo ?nomeFavorecido



Resultado:


Consulta 9:


Descrição: Lista favorecidos de um grupo de itens, pesquisando pelo nome.

SELECT ?UO ?acao ?nomeFavorecido (SUM (?valor) AS ?total)

WHERE {

?p pag:temUnidadeOrcamentaria ?UO .

?p pag:temAcao ?acao .

FILTER (REGEX (?UO, "20101", "i")) .

#FILTER (REGEX (?acao, "2000", "i")) .

FILTER (REGEX (?nomeFavorecido, "informatica", "i")) .

?p pag:temFavorecido ?favorecido .


?p pag:valorPagamento ?valor .

}

GROUP BY ?UO ?acao ?nomeFavorecido

ORDER BY DESC (?total)


Resultado:


Consulta 10:


Descrição: Lista todos os pagamentos de um Grupo de Itens agrupando por favorecido.

SELECT ?UO ?acao ?nomeFavorecido (SUM (?valor) AS ?total)

WHERE {

?p pag:temUnidadeOrcamentaria ?UO .

?p pag:temFuncao ?funcao .

?p pag:temSubfuncao ?subfuncao .

?p pag:temPrograma ?programa .

?p pag:temAcao ?acao .

?p pag:temGND ?GND .

?p pag:temElementoDespesa ?elemento

FILTER (REGEX (?UO, "39101", "i")) .

FILTER (REGEX (?funcao, "26", "i")) .

FILTER (REGEX (?subfuncao, "122", "i")) .

FILTER (REGEX (?programa, "2126", "i")) .

FILTER (REGEX (?acao, "2000", "i")) .

FILTER (REGEX (?GND, "3", "i")) .

FILTER (REGEX (?elemento, "39", "i")) .

?p pag:temFavorecido ?favorecido .


?p pag:valorPagamento ?valor .

}

GROUP BY ?UO ?acao ?nomeFavorecido

ORDER BY DESC (?total)


Resultado:


4. Avaliar resultados das consultas: avaliou-se a capacidade da ontologia em responder às

QCs comparando as respostas das consultas SPARQL às respostas esperadas das QCs. A

partir dos critérios descritos nesse método, montou-se a tabela de QCs com os respectivos

critérios e valores atribuídos, conforme apresentado na Tabela 25.

Tabela 23 - Tabela de valores das QCs de acordo com a resposta das consultas SPARQL

QCs Tradução Completa Resposta Esperada Valor

QC1 Sim Integral 3

QC2 Sim Parcial 2

QC3 Sim Integral 3

QC4 Sim Integral 3

QC5 Sim Parcial 2

QC6 Sim Integral 3

QC7 Sim Integral 3

QC8 Sim Integral 3

QC9 Sim Parcial 2

QC10 Sim Integral 3


Para avaliar quantitativamente, foi utilizada a fórmula do trabalho de Bortolato (2014)

para validação de ontologias. A partir dos valores atribuídos, calculou-se a capacidade da

ontologia de responder às Questões de Competência QCs (Cobertura), utilizando a fórmula

proposta pelo método de Bortolato (2014):

%00,90100310

27

Cobertura

A ontologia OntoPag possui capacidade aproximada de responder às Questões de

Competência (QCs) elicitadas, com um valor de 90,00% de Cobertura.


5.2 Considerações

Neste capítulo foi apresentada a avaliação da ontologia OntoPag por meio de Questões de

Competência (QCs), utilizando o método de Ghomari e Ghomari (2013), apresentado no

Capítulo 3, bem como todas as atividades do processo de avaliação. Também foram apresentadas

neste Capítulo, consultas na linguagem SPARQL, que respondem às QCs. Por fim, foi aplicada

uma fórmula de Bortolato (2014) para avaliar quantitativamente o quão a ontologia desenvolvida

pode responder às Questões de Competência.

Capítulo 6 – Conclusão e Trabalhos Futuros 115

Capítulo

6 6 Conclusões e Trabalhos Futuros

Este capítulo tem como objetivo apresentar as conclusões e contribuições da

presente dissertação, assim como apresentar os trabalhos futuros que poderão ser feitos a

partir desta dissertação.


6.1 Conclusões

O domínio Orçamento Público é amplo, complexo, dominado por muitas regras e não

poderia ser diferente, pois trata de questões que afetam a todos. No entanto, é justamente neste

setor que o Governo Federal avançou mais concretamente na disponibilização de dados em

formato aberto, cumprindo o comando da Lei 12.527/2011, art. 8º (Lei de Acesso à Informação).

A disponibilização dos dados do orçamento e sua execução em formato aberto permitiu a

possibilidade da criação de uma nova base de dados conectados conduzindo à criação de uma

rede de conhecimento coletivo com enorme potencialidade. Esta é a principal contribuição deste

trabalho. Mais do que um mero exercício acadêmico, foi demonstrado como é possível com as

ferramentas e com o conhecimento disponível, criar bases de conhecimento compartilháveis e de

alto valor social.

Uma ontologia de pagamento foi desenvolvida, denomidada OntoPag, com o objetivo de

representar os conceitos do domínio de orçamento focando a parte de pagamentos, pois não

existia essa representação de pagamentos e favorecidos semanticamente. Isto facilita a

representação semântica e oferece um maior conhecimento sobre os dados da execução

orçamentária. O objetivo essencial com o desenvolvimento da ontologia OntoPag foi atendido,

qual seja tornar públicas informações de interesse social. No entanto, fez-se necessário a criação

de uma nova base de dados abertos e conectados a partir da uma construção de uma aplicação

que foi seguida passo a passo desde os dados armazenados em um Portal de Transparência até a

disponibilização desses dados, em formato RDF, fornecendo, assim, uma possibilidade de

realização de consultas semânticas.

A base de dados em RDF representa uma infraestrutura de conhecimento, que poderá

servir de base de apoio para outros desenvolvimentos (produtos e serviços) que atendam mais

diretamente a outros públicos. A base de conhecimento pode ser utilizada pela comunidade de

especialistas para o desenvolvimento de aplicações voltadas aos técnicos de finanças públicas e

ao público em geral.

O trabalho utilizou dados do exercício de 2014, que é o último ano encerrado no presente

momento. Mas desenvolvimentos futuros deverão ampliar a base para os exercícios anteriores e,

principalmente, para o exercício corrente. Este último apresenta um desafio maior porque os

dados do exercício corrente são atualizados diariamente pelo sistema de contabilidade do

governo federal.

Talvez, a principal limitação do trabalho seja justamente não ter mostrado o verdadeiro

potencial de utilização das informações geradas. As limitações de tempo e recursos impediram


um trabalho mais amplo de pesquisa junto aos potenciais interessados nas informações. Também

não foi possível desenvolver uma aplicação mais amigável, demonstrando potenciais

funcionalidades que poderiam ser oferecidas a partir das consultas a essas bases.

6.2 Trabalhos Futuros

Durante o estudo, foram levantadas algumas questões com o intuito de explorar as

oportunidades que não puderam ser tratadas neste trabalho. Então, foi pensado como toda essa

ideia de publicação e interligação dos dados abertos no domínio de orçamento público podem ter

um crescimento tanto no sentido acadêmico/pesquisa, quanto no sentido de mercado a fim de

auxiliar usuários comuns no acesso a esses dados. Segue abaixo uma lista de possíveis trabalhos

futuros:

Estender o conjunto de dados criados com dados dos outros anos das bases de dados

disponíveis no Portal da Transperência;

Implementar uma ferramenta automatizada que inclua todos os módulos da aplicação

COP, relizando o processo de cada módulo automático e não manualmente;

Implementação de axiomas de domínio. Os axiomas devem ser necessários e suficientes

para expressar as questões de competência e para caracterizar suas soluções;

Implementar uma aplicação ou desenvolver um Portal que apresente as informações de

forma mais amigável, utilizando técnicas de Interação Humano Computador (IHC);

Inserir outros conceitos de orçamento e finanças públicas, como restos a pagar,

transferências públicas, convênios, consultas temáticas;

Estender a ontologia para receitas públicas.

Referências 118

Referências

Referências 119

ALLEMANG D.; HENDLER, D. Semantic Web for the Working Ontologist, 1st

edition. Morgan Kaufmann publ., Amsterdam, Netherlands. 2008.

ANTONIOU G.; HARMELEN, V. A Semantic Web Primer. 2ª Edição. The Mit Press, 2008.

ARAÚJO, L.; CRUZ, F. W. Uma ontologia das classificações da despesa do Orçamento

Federal. In: V Seminário de Pesquisa em Ontologias do Brasil / VII International Workshop on

Metamodels, Ontologies, Semantic Technologies, Pernambuco, Brasil, 2012.

BECHHOFER, S. et al. OWL Web Ontology Language Reference. Disponível em:

<http://www.w3.org/TR/2004/REC-owl-ref-20040210/>. Acesso em: 11/10/2014.

BECKETT, D. et al. RDF 1.1 Turtle. Diponível em: <http://www.w3.org/TR/turtle/>. Acesso

em: 20/10/2014.

BERNARAS, A.; LARESGOITI, I.; CORERA, J. Building and reusing ontologies for

electrical network applications. In: THE EUROPEAN CONFERENCE ON ARTIFICIAL

INTELLIGENCE, ECAI, 1996. Proceedings, 1996. p. 298-302.

BERNERS-LEE, Tim. Tim Berners-Lee on the next Web. (conferência) TED Ideas Worth

Spreading 2009, fevereiro de 2009.

BERNERS-LEE, Tim et al. Linked Open Government Data: lessons from data.gov.uk.

Intelligent Systems, IEEE , vol.27, no.3, pp.16,24, maio-junho 2012.

BERNERS-LEE, T. et al. The Semantic Web. Scientific American., v. 284, n. 5, p. 34-43,

maio 2001.

BOBBIO, N. Estado, governo, sociedade; para uma teoria geral da política. Rio de Janeiro:

Paz e Terra, 1987.

BORTOLATO, F. Ligando Dados Governamentais Abertos: uma ontologia do Processo

Legislativo de São Paulo. São Paulo, 2014. 252 f. Dissertação (Mestrado em Engenharia de

Computação) - Instituto de Pesquisas Tecnológicas de São Paulo (IPT).

BRASIL. Lei nº 4.320, de 17 de março de 1964. Estatui Normas Gerais de Direito Financeiro

para elaboração e contrôle dos orçamentos e balanços da União, dos Estados, dos Municípios e

do Distrito Federal. Disponível em: <http://www.planalto.gov.br/ccivil_03/leis/l4320.htm>.

Acesso em: 20/09/2014.

BRASIL. BRASIL. Lei Complementar n o 131. Mai. 2009. Disponível em:

<http://www.planalto.gov.br/ccivil_03/leis/lcp/lcp131.htm>.

Referências 120

BRASIL. Brasil: “Lei nº 12.527”. 2011. Disponível em:

<http://www.planalto.gov.br/ccivil_03/_Ato2011-2014/2011/Lei/L12527.htm>.

BREITMAN, K.K., LEITE, J.C.S.P.: Ontology as a Requirements Engineering Product,

Proceedings of the International Conference on Requirements Engineering, IEEE Computer

Society Press, 2003.

Brusa, G., Caliusco, L., e Chiotti, O. (2006). A process for building a do-main ontology: an

experience in developing a government budgetary ontology. Disponível em:

<http://www.planalto.gov.br/ccivil 03/ ato2011-2014/2011/lei/l12527.htm>. Acesso em:

14/09/2014.

CALIARI, F. M. (2007). Deronto: Método para construção de ontologias a partir de

diagramas entidade-relacionamento. 2007.

CHAUDHRI et al. A programmatic foundation for knowledge base interoperability. In:

15th national conference on artificial intelligence (AAAI-98), 1998.

CORRÊA, I. A Experiência Brasileira na Promoção da Transparência. In Seminário

internacional sobre acesso à informação: desafios de implementação. Brasília: CGU. Disponível

em: http://www.cgu.gov.br/acessoainformacao/eventos/seminario-

internacional/arquivos/Izabela-Correa-A-experiencia-brasileira-na-promocao-da-transparencia-

ativa-1.pdf, 2010. Acesso em: 15/04/2014.

CRAVEIRO et al. Assessing Open Government Budgetary Data in Brazil. ICDS 2013, The

Seventh International Conference on Digital Society, (pp. 20–27). Disponível em:

<http://www.thinkmind.org/download.php?articleid=icds_2013_1_40_10183>. Acesso em:

21/06/2014.

DINIZ, Vagner. Como conseguir dados governamentais abertos. Trabalho apresentado no III

Congresso CONSAD de Gestão Pública realizado nos dias 15, 16, 17 de março de 2010 em

Brasília. Disponível em: <http://www.consad.org.br/sites/1500/1504/00001870.pdf>. Acesso

em: 27/01/2014.

Fensel, D. Ontologies: a silver bullet for knowledge management e electronic commerce.

[S.L]: Springer, 2001.

Fernandez, A. Gomez-Perez, and N. Juristo. METHONTOLOGY: From Ontological Arts

Towards Ontological Engineering. In Proceedings of the AAAI97 Spring Symposium

Series on Ontological Engineering, Stanford, USA, pages 33--40, March 1997.

Referências 121

FERREIRA, A. B. H. Dicionário Aurélio Básico da Língua Portuguesa. Nova Fronteira, 1 a

edition, 1988.

FREDERICKSON, H. G.: “Comparing the Reinventing Government Movement with the

New Public Administration,” Public Administration Review, 1996, 56(3), 263-270.

GHOMARI, L.Z.; GHOMARI, A.R.. Translating Natural Language Competency Questions

into SPARQLQueries: A Case Study. In: ThinkMind WEB 2013, The First International

Conference on Building and Exploring Web Based Environments. Seville, Spain, 2013.

GIACOMONI, J. (2009). Orçamento Público. Atlas, 14ª edition.

GOMÉZ, P, A.; LOPÉZ, Corcho, O. Ontology Engeneering - Springer Verlag, 2004.

GÓMEZ-PÉREZ, A; CORCHO, O.; FERNÁNDEZ-LÓPEZ, M. Ontologic Engineering: with

examples from the areas of knowledge management, e-commerce and the semantic web.

Springer-Verlag, 2004.

GRUBER, T. R. A translation approach to portable ontology specifications. Knowledge

acquisition, v.5, n.2, p.199-220, 1993. Disponível em: <http://tomgruber.org/writing/ontolingua-

kaj-1993.pdf>. Acesso em: 19/05/2014.

GRUNINGER M e FOX MS. Methodology for the design and evaluation of ontologies. In:

IJCAI95 Workshop on Basic Ontological Issues in Knowledge Sharing. Montreal, Canada.

GUARINO, N. Formal Ontology and Information Systems. Formal Ontology in

Information Systems. Proceedings of FOIS’98. Anais... [S.l: s.n.]., 1998.

GUIMARÃES, F. J. Z. Utilização de ontologias no domínio B2C. Pontifícia Universidade

Católica do Rio de Janeiro. Departamento de Informática2002.

INESC. Avaliando os websites de transparência orçamentária nacionais e subnacionais e

medindo impactos de dados abertos sobre direitos humanos no Brasil. Instituto de Estudos

Socioeconômicos – Inesc. 2014. Disponível em: <

http://www.inesc.org.br/biblioteca/publicacoes/textos/pesquisa-transparencia-orcamentaria-nos-

websites-nacionais-e-sub-nacionais>. Acesso em: 22/10/2014.

LEVY, E. (art.) Controle social e controle de resultados - um balanço dos argumentos e da

experiência recente. In: BRESSER PEREIRA, Luiz Carlos; CUNILL GRAU, Nuria. O público

não-estatal e a reforma do Estado. Rio de Janeiro: Editora Fundação Getúlio Vargas, 1999.

LINKEDDATABOOK. Disponível em <www.linkeddatabook.com>. 2011. Acesso em:

15/09/2014.

Referências 122

LIU, L.; ZSU, M. T. Encyclopedia of Database Systems. 1st. ed. [S.l.]: Springer Publishing

Company, Incorporated, 2009. ISBN 0387355448, 9780387355443.

LOA. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Orçamento Federal.

Lei orçamentária anual LOA 2012 em formato aberto: Manual de referência. Brasília, 2012.

Disponível em: <http://vocab.e.gov.br/2013/09/loa>. Acesso em: 15/07/2014.

MAALI et al. Enabling Interoperability of Government Data Catalogues. DERI. National

University of Ireland, Glaway, 2010.

MANOLA, F.; MILLER, E. RDF Primer. W3C Recommendation. 2004. Disponível em:

<http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#conceptsummary>. Acesso em:

20/08/2014.

MARTINS et al. Definicão e Validação de uma Ontologia para o Orçamento Público

Federal Brasileiro (v.1.0). Escola de Artes, Ciências e Humanidades – Universidade de São

Paulo São Paulo – SP, Brasil. http://www.each.usp.br/ppgsi. 2013.

MCGUINNESS et al. OWL Web Ontology Language: Overview. Disponível em:

<http://www.w3.org/TR/owlfeatures/>. 2014.

MORAIS, E. A e AMBRÓSIO, A. P. Ontologias: conceitos, usos, tipos, metodologias,

ferramentas e linguagens. Technical report, Universidade Federal de Goiás, 2007.

MTO. Manual Técnico Orçamentário, Versão 2015, Brasília: Ministério do Planejamento,

Orçamento e Gestão – Secretaria de Orçamento Federal. Disponível em:

<http://www.orcamentofederal.gov.br/informacoes-orcamentarias/manual-

tecnico/mto_2015_1a_edicao-150514.pdf.>. Acesso em: 18/02/2015.

NOY, F. e McGUINNESS, D. L. Ontology development 101: a guide to create your first

ontology. 2001. Disponível em: <http://ksl.stanford.edu/people/dlm/papers/ontology-tutorial-

noy-mcguinness.doc>.

NOY et al. Ontology Evolution: Not the Same as Schema Evolution. Knowledge and

Information Systems, v. 6, n. 4, p. 428-440, 2004. Disponível em:

<http://springerlink.metapress.com/openurl.asp?genre=article&id=doi:10.1007/s10115-003-

0137-2>. Acesso em: 15/06/2014.

OBAMA, B. Transparency and Open Government. 2014.

<http://www.whitehouse.gov/the_press_office/TransparencyandOpenGovernment>. Disponível

em: <http://www.whitehouse.gov/the_press_office/TransparencyandOpenGovernment>. Acesso

em: 21/08/2014.

Referências 123

ONTOLOGY, P. (2010). Guide to the payments ontology. Disponível em:

<http://data.gov.uk/resources/payments#structure>. Acesso em: 12/07/2014.

POLLITT, C.: “Is the emperor in his underwear? An analysis of the impact of public

management reform,” Public Management, 2000, 2(2), 181-199.

RAMALHO et. al. Web Semântica: uma investigação sob o olhar da Ciência da Informação.

DataGramaZero, Rio de Janeiro, v. 8, p. 4, 2007.

REED, S. L.; LENAT, D. B. Mapping ontologies into cyc. 2002. Disponível em:

<http://www.cyc.com/doc/white_papers/mapping-ontologies-into-cyc_v31.pdf>. Acesso em:

22/04/2014.

RIBEIRO, M. M. Transparência nos portais do governo federal: os casos do

COMPRASNET e do Portal da Transparência, 2009. (Trabalho de Conclusão de Curso),

Universidade de São Paulo, São Paulo.

SAHOO, S. S.; et al. "A survey of current approaches for mapping of relational databases to

rdf." W3C RDB2RDF Incubator Group Report, 2009.

SANCHES, O. (2004). “Dicionário de Orçamento, Planejamento e Áreas Afins”.

PRISMA/OMS2ª ed. Brasília, Brasil.

SANTOS, P. e ALVES, R. Metadados e Web Semântica para estruturação da Web 2.0 e

Web 3.0 (ARTIGO 04). DataGramaZero, Rio de Janeiro, v.10, n.6, dezembro de 2009.

SILVA, A. Daniel. (2014). Aplicação de Inferência Semântica para Exploração Conceitual

de Bases de Dados Relacionais. Dissertação de Mestrado em Engenharia Elétrica, Publicação

PPGEE.DM-561/2014. Departamento de Engenharia Elétrica, Universidade de Brasília, Brasília,

DF, 115p.

SMITH et. al. OWL Web Ontology Language Guide. Disponível em:

<http://www.w3.org/TR/2004/REC-owl-guide-20040210/>.

STAAB et. al. Knowledge processes and ontologies. IEEE Intelligent Systems, 16(1):26–34.,

2001.

SWARTOUT, B. et al. Toward distributed use of large-scale ontologies. 1996.

Disponível em: <http://ksi.cpsc.ucalgary.ca/KAW/KAW96/swartout/Banff_96_final_2.html>.

Acesso em: 20/05/2014.

USCHOLD, M.; GRUNINGER, M. Ontologies: Principles, methods and applications.

Knowledge engineering review, v. 11, n. 2, p. 93–136, 1996. Cambridge Univ Press. Disponível

Referências 124

em: <http://journals.cambridge.org/production/action/cjoGetFulltext?fulltextid=4071856>.

Acesso em: 10/05/2014.

USCHOLD, M. and KING, M. Towards A Methodology for Building Ontologies, IJCAI-95

Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, Canada, 1995.

USERGUIDE. User guide: contents (2005). Disponível em:

<http://protege.stanford.edu/doc/users_guide/index.html>. Acesso em: 17/10/2014.

VAZ, J. C. Administração pública e governança eletrônica: possibilidades para a tecnologia

da informação. In: Governo eletrônico - os desafios da participação cidadã. Fortaleza: Fundação

Konrad Adenauer, Série Debates n. 24, dez. 2002.

VIRTUOSO. OpenLink Virtuoso. Disponível em: <http://virtuoso.openlinksw.com/>. Acesso

em: 17/05/2015.

W3C. World Wide Web Consortium. N-Triples. Disponível em:

<http://www.w3.org/2001/sw/RDFCore/ntriples/>. Acesso em: 20/10/2014.

W3C. World Wide Web Consortium. Notation 3 Logic. Disponível em:

<http://www.w3.org/DesignIssues/Notation3>. Acesso em: 17/06/2014.

W3C. World Wide Web Consortium. Turtle - Terse RDF Triple Language. Disponível em:

<http://www.w3.org/TeamSubmission/turtle/>. Acesso em: 17/06/2014.

W3C. World Wide Web Consortium. OWL2. Disponível em: <http://www.w3.org/TR/owl2-

syntax/>. Acesso em: 21/09/2014.

WILDAVSKY, Aaron. The new politics of the budgetary process. 3.ed. New York: Longman,

1996.

ZHOU, S. Exposing relational database as RDF.In: INTERNATIONAL CONFERENCE ON

INDUSTRIAL AND INFORMATION SYSTEMS, 2., 2010, Dalian. Proceedings. Piscataway:

IEEE, 2010. p. 237-240.

Apêndices 125

Apêndices

Esta seção apresenta os Apêndices para complementar a compreensão do texto.

Estes são materiais relevantes produzidos durante a sua elaboração e aspectos

complementares pertinentes a esta dissertação.

Apêndices 126

APÊNDICE A

Ontologia Ontopag – Formato Turtle

@prefix : <http://www.cin.ufpe.br/~wsf/ontopag/> .

@prefix loa: <http://vocab.e.gov.br/2013/09/loa#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix pag: <http://www.cin.ufpe.br/~wsf/ontopag/> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix xml: <http://www.w3.org/XML/1998/namespace> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@base <http://www.cin.ufpe.br/~wsf/ontopag/> .

<http://www.cin.ufpe.br/~wsf/ontopag/> rdf:type owl:Ontology ;

rdfs:label "Ontologia de gastos diretos com pagamentos do

governo federal brasileiro."^^xsd:string ;

rdfs:comment "Ontologia de gastos diretos com pagamentos do

governo federal brasileiro, contendo conexões com a Ontologia da LOA (Lei Orçamentária

Anual) brasileira."^^xsd:string ;

owl:versionInfo "v2 2015/08"^^xsd:string ;

owl:imports loa: .

#################################################################

#

# Annotation properties

#

#################################################################

### http://www.cin.ufpe.br/~wsf/ontopag/linguagemCidada

:linguagemCidada rdf:type owl:AnnotationProperty ;

rdfs:domain :Pagamento ;

rdfs:subPropertyOf rdfs:label .

### http://www.cin.ufpe.br/~wsf/ontopag/nomeFavorecido

:nomeFavorecido rdf:type owl:AnnotationProperty ;

rdfs:domain :Favorecido ;

Apêndices 127


### http://www.cin.ufpe.br/~wsf/ontopag/nomeUnidadeGestora

:nomeUnidadeGestora rdf:type owl:AnnotationProperty ;

rdfs:domain :UnidadeGestora ;


#################################################################

#

# Object Properties

#

#################################################################

### http://www.cin.ufpe.br/~wsf/ontopag/temAcao

:temAcao rdf:type owl:ObjectProperty ;

rdfs:range loa:Acao ;

rdfs:subPropertyOf :temClassificadorOrcamentario .

### http://www.cin.ufpe.br/~wsf/ontopag/temClassificadorOrcamentario

:temClassificadorOrcamentario rdf:type owl:AsymmetricProperty ,

owl:FunctionalProperty ,

owl:IrreflexiveProperty ,

owl:ObjectProperty ;

rdfs:range loa:Classificador ;

rdfs:domain :Pagamento .

### http://www.cin.ufpe.br/~wsf/ontopag/temElementoDespesa

:temElementoDespesa rdf:type owl:ObjectProperty ;

rdfs:range loa:ElementoDespesa ;

Apêndices 128


### http://www.cin.ufpe.br/~wsf/ontopag/temFavorecido

:temFavorecido rdf:type owl:AsymmetricProperty ,




rdfs:range :Favorecido ;

rdfs:domain :PagamentoPublico .

### http://www.cin.ufpe.br/~wsf/ontopag/temFuncao

:temFuncao rdf:type owl:ObjectProperty ;

rdfs:range loa:Funcao ;


### http://www.cin.ufpe.br/~wsf/ontopag/temGND

:temGND rdf:type owl:ObjectProperty ;

rdfs:range loa:GrupoNatDespesa ;


### http://www.cin.ufpe.br/~wsf/ontopag/temOrgao

:temOrgao rdf:type owl:AsymmetricProperty ,




rdfs:range loa:Orgao ;

rdfs:domain :Pagamento .

### http://www.cin.ufpe.br/~wsf/ontopag/temPrograma

Apêndices 129

:temPrograma rdf:type owl:ObjectProperty ;

rdfs:range loa:Programa ;


### http://www.cin.ufpe.br/~wsf/ontopag/temSubfuncao

:temSubfuncao rdf:type owl:ObjectProperty ;

rdfs:range loa:Subfuncao ;


### http://www.cin.ufpe.br/~wsf/ontopag/temUnidadeGestora

:temUnidadeGestora rdf:type owl:AsymmetricProperty ,





rdfs:range :UnidadeGestora .

### http://www.cin.ufpe.br/~wsf/ontopag/temUnidadeOrcamentaria

:temUnidadeOrcamentaria rdf:type owl:ObjectProperty ;

rdfs:range loa:UnidadeOrcamentaria ;


#################################################################

#

# Data properties

#

#################################################################

### http://www.cin.ufpe.br/~wsf/ontopag/codigoDocumento

Apêndices 130

:codigoDocumento rdf:type owl:DatatypeProperty ,

owl:FunctionalProperty ;

rdfs:domain :PagamentoPublico ;

rdfs:range xsd:string .

### http://www.cin.ufpe.br/~wsf/ontopag/codigoFavorecido

:codigoFavorecido rdf:type owl:DatatypeProperty ,




### http://www.cin.ufpe.br/~wsf/ontopag/codigoGestaoPagamento

:codigoGestaoPagamento rdf:type owl:DatatypeProperty ,




### http://www.cin.ufpe.br/~wsf/ontopag/codigoUnidadeGestora

:codigoUnidadeGestora rdf:type owl:DatatypeProperty ,




### http://www.cin.ufpe.br/~wsf/ontopag/dataPagamento

:dataPagamento rdf:type owl:DatatypeProperty ,



rdfs:range xsd:dateTime .

Apêndices 131

### http://www.cin.ufpe.br/~wsf/ontopag/linguagemCidada

:linguagemCidada rdf:type owl:DatatypeProperty ;



### http://www.cin.ufpe.br/~wsf/ontopag/nomeFavorecido

:nomeFavorecido rdf:type owl:DatatypeProperty ;



### http://www.cin.ufpe.br/~wsf/ontopag/nomeUnidadeGestora

:nomeUnidadeGestora rdf:type owl:DatatypeProperty ;



### http://www.cin.ufpe.br/~wsf/ontopag/valorPagamento

:valorPagamento rdf:type owl:DatatypeProperty ,



rdfs:range xsd:decimal .

#################################################################

#

# Classes

#

#################################################################

Apêndices 132

### http://www.cin.ufpe.br/~wsf/ontopag/Favorecido

:Favorecido rdf:type owl:Class ;

rdfs:subClassOf [ rdf:type owl:Restriction ;

owl:onProperty :codigoFavorecido ;

owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;

owl:onDataRange xsd:string

] ,

[ rdf:type owl:Restriction ;

owl:onProperty :nomeFavorecido ;

owl:someValuesFrom xsd:string

] .

### http://www.cin.ufpe.br/~wsf/ontopag/Pagamento

:Pagamento rdf:type owl:Class ;


owl:onProperty :linguagemCidada ;


] ,


owl:onProperty :temUnidadeOrcamentaria ;

owl:onClass loa:UnidadeOrcamentaria ;

owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger

] ,


owl:onProperty :temSubfuncao ;

owl:onClass loa:Subfuncao ;


] ,


owl:onProperty :valorPagamento ;


owl:onDataRange xsd:decimal

] ,


owl:onProperty :temElementoDespesa ;

owl:onClass loa:ElementoDespesa ;


] ,


owl:onProperty :temGND ;

owl:onClass loa:GrupoNatDespesa ;


] ,


owl:onProperty :temAcao ;

owl:onClass loa:Acao ;

Apêndices 133


] ,


owl:onProperty :temFuncao ;

owl:onClass loa:Funcao ;


] ,


owl:onProperty :temPrograma ;

owl:onClass loa:Programa ;


] ,


owl:onProperty :temUnidadeGestora ;

owl:onClass :UnidadeGestora ;


] .

### http://www.cin.ufpe.br/~wsf/ontopag/PagamentoPublico

:PagamentoPublico rdf:type owl:Class ;

rdfs:subClassOf :Pagamento ,


owl:onProperty :codigoDocumento ;



] ,


owl:onProperty :dataPagamento ;


owl:onDataRange xsd:dateTime

] ,


owl:onProperty :codigoGestaoPagamento ;


] ;

owl:disjointWith :PagamentoSigiloso .

### http://www.cin.ufpe.br/~wsf/ontopag/PagamentoSigiloso

:PagamentoSigiloso rdf:type owl:Class ;

rdfs:subClassOf :Pagamento .

Apêndices 134

### http://www.cin.ufpe.br/~wsf/ontopag/UnidadeGestora

:UnidadeGestora rdf:type owl:Class ;


owl:onProperty :nomeUnidadeGestora ;


] ,


owl:onProperty :codigoUnidadeGestora ;



] .

### Generated by the OWL API (version 3.5.1) http://owlapi.sourceforge.net

Apêndices 135

APÊNDICE B

Ontologia Ontopag – Formato OWL

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [

<!ENTITY owl "http://www.w3.org/2002/07/owl#" >

<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >

<!ENTITY loa "http://vocab.e.gov.br/2013/09/loa#" >

<!ENTITY pag "http://www.cin.ufpe.br/~wsf/ontopag/" >

<!ENTITY xml "http://www.w3.org/XML/1998/namespace" >

<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >

<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >

]>

<rdf:RDF xmlns="http://www.cin.ufpe.br/~wsf/ontopag/"

xml:base="http://www.cin.ufpe.br/~wsf/ontopag/"

xmlns:loa="http://vocab.e.gov.br/2013/09/loa#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:pag="http://www.cin.ufpe.br/~wsf/ontopag/"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:xml="http://www.w3.org/XML/1998/namespace">

<owl:Ontology rdf:about="http://www.cin.ufpe.br/~wsf/ontopag/">

<rdfs:label rdf:datatype="&xsd;string">Ontologia de gastos diretos com pagamentos do

governo federal brasileiro.</rdfs:label>

<rdfs:comment rdf:datatype="&xsd;string">Ontologia de gastos diretos com pagamentos

do governo federal brasileiro, contendo conexões com a Ontologia da LOA (Lei Orçamentária

Anual) brasileira.</rdfs:comment>

<owl:versionInfo rdf:datatype="&xsd;string">v2 2015/08</owl:versionInfo>

<owl:imports rdf:resource="http://vocab.e.gov.br/2013/09/loa#"/>

</owl:Ontology>

Apêndices 136



<owl:AnnotationProperty rdf:about="&pag;linguagemCidada">

<rdfs:domain rdf:resource="&pag;Pagamento"/>

<rdfs:subPropertyOf rdf:resource="&rdfs;label"/>

</owl:AnnotationProperty>



<owl:AnnotationProperty rdf:about="&pag;nomeFavorecido">

<rdfs:domain rdf:resource="&pag;Favorecido"/>





<owl:AnnotationProperty rdf:about="&pag;nomeUnidadeGestora">

<rdfs:domain rdf:resource="&pag;UnidadeGestora"/>







<owl:ObjectProperty rdf:about="&pag;temAcao">

<rdfs:range rdf:resource="&loa;Acao"/>

<rdfs:subPropertyOf rdf:resource="&pag;temClassificadorOrcamentario"/>

</owl:ObjectProperty>



<owl:ObjectProperty rdf:about="&pag;temClassificadorOrcamentario">

<rdf:type rdf:resource="&owl;AsymmetricProperty"/>

<rdf:type rdf:resource="&owl;FunctionalProperty"/>

Apêndices 137

<rdf:type rdf:resource="&owl;IrreflexiveProperty"/>

<rdfs:range rdf:resource="&loa;Classificador"/>





<owl:ObjectProperty rdf:about="&pag;temElementoDespesa">

<rdfs:range rdf:resource="&loa;ElementoDespesa"/>





<owl:ObjectProperty rdf:about="&pag;temFavorecido">




<rdfs:range rdf:resource="&pag;Favorecido"/>

<rdfs:domain rdf:resource="&pag;PagamentoPublico"/>




<owl:ObjectProperty rdf:about="&pag;temFuncao">

<rdfs:range rdf:resource="&loa;Funcao"/>





<owl:ObjectProperty rdf:about="&pag;temGND">

<rdfs:range rdf:resource="&loa;GrupoNatDespesa"/>





<owl:ObjectProperty rdf:about="&pag;temOrgao">

Apêndices 138

<rdfs:range rdf:resource="&loa;Orgao"/>





<owl:ObjectProperty rdf:about="&pag;temPrograma">

<rdfs:range rdf:resource="&loa;Programa"/>





<owl:ObjectProperty rdf:about="&pag;temSubfuncao">

<rdfs:range rdf:resource="&loa;Subfuncao"/>





<owl:ObjectProperty rdf:about="&pag;temUnidadeGestora">





<rdfs:range rdf:resource="&pag;UnidadeGestora"/>




<owl:ObjectProperty rdf:about="&pag;temUnidadeOrcamentaria">

<rdfs:range rdf:resource="&loa;UnidadeOrcamentaria"/>

Apêndices 139



<owl:DatatypeProperty rdf:about="&pag;codigoDocumento">



<rdfs:range rdf:resource="&xsd;string"/>

</owl:DatatypeProperty>



<owl:DatatypeProperty rdf:about="&pag;codigoFavorecido">


<rdfs:domain rdf:resource="&pag;Favorecido"/>





<owl:DatatypeProperty rdf:about="&pag;codigoGestaoPagamento">







<owl:DatatypeProperty rdf:about="&pag;codigoUnidadeGestora">


<rdfs:domain rdf:resource="&pag;UnidadeGestora"/>





<owl:DatatypeProperty rdf:about="&pag;dataPagamento">



<rdfs:range rdf:resource="&xsd;dateTime"/>

Apêndices 140



<owl:DatatypeProperty rdf:about="&pag;linguagemCidada">





<owl:DatatypeProperty rdf:about="&pag;nomeFavorecido">





<owl:DatatypeProperty rdf:about="&pag;nomeUnidadeGestora">





<owl:DatatypeProperty rdf:about="&pag;valorPagamento">



<rdfs:range rdf:resource="&xsd;decimal"/>






<owl:Class rdf:about="&pag;Favorecido">

<rdfs:subClassOf>

<owl:Restriction>

Apêndices 141

<owl:onProperty rdf:resource="&pag;nomeFavorecido"/>

<owl:someValuesFrom rdf:resource="&xsd;string"/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;codigoFavorecido"/>

<owl:qualifiedCardinality

rdf:datatype="&xsd;nonNegativeInteger">1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="&xsd;string"/>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>



<owl:Class rdf:about="&pag;Pagamento">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temElementoDespesa"/>

<owl:onClass rdf:resource="&loa;ElementoDespesa"/>



</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temFuncao"/>

<owl:onClass rdf:resource="&loa;Funcao"/>



</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;valorPagamento"/>



<owl:onDataRange rdf:resource="&xsd;decimal"/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temAcao"/>

<owl:onClass rdf:resource="&loa;Acao"/>



</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

Apêndices 142

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;linguagemCidada"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temGND"/>

<owl:onClass rdf:resource="&loa;GrupoNatDespesa"/>



</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temUnidadeGestora"/>

<owl:onClass rdf:resource="&pag;UnidadeGestora"/>



</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temPrograma"/>

<owl:onClass rdf:resource="&loa;Programa"/>



</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temSubfuncao"/>

<owl:onClass rdf:resource="&loa;Subfuncao"/>



</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;temUnidadeOrcamentaria"/>

<owl:onClass rdf:resource="&loa;UnidadeOrcamentaria"/>



</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>



<owl:Class rdf:about="&pag;PagamentoPublico">

Apêndices 143

<rdfs:subClassOf rdf:resource="&pag;Pagamento"/>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;codigoGestaoPagamento"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;dataPagamento"/>



<owl:onDataRange rdf:resource="&xsd;dateTime"/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;codigoDocumento"/>




</owl:Restriction>

</rdfs:subClassOf>

<owl:disjointWith rdf:resource="&pag;PagamentoSigiloso"/>

</owl:Class>



<owl:Class rdf:about="&pag;PagamentoSigiloso">

<rdfs:subClassOf rdf:resource="&pag;Pagamento"/>

</owl:Class>



<owl:Class rdf:about="&pag;UnidadeGestora">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;nomeUnidadeGestora"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="&pag;codigoUnidadeGestora"/>




</owl:Restriction>

Apêndices 144

</rdfs:subClassOf>

</owl:Class>

</rdf:RDF>

Apêndices 145

APÊNDICE C

Ontologia de gastos diretos com pagamentos do governo federal brasileiro.

IRI:

http://www.cin.ufpe.br/~wsf/ontopag/

Current version:

v2 2015/08

Imported Ontologies:

http://vocab.e.gov.br/2013/09/loa# (visualise it with LODE)

Other visualisation:

Ontology source

6.3 Abstract

Ontologia de gastos diretos com pagamentos do governo federal brasileiro, contendo conexões

com a Ontologia da LOA (Lei Orçamentária Anual) brasileira.

6.4 Table of Content

1. Classes

2. Object Properties

3. Data Properties

4. Annotation Properties

5. Namespace Declarations

6.5 Classes

favorecido

pagamento

pagamento publico

pagamento sigiloso

unidade gestora

6.5.1 favorecidoc back to ToC or Class ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/Favorecido

has super-classes

nome favorecidodp

some string

codigo favorecidodp

exactly 1

http://vocab.e.gov.br/2013/09/loa

http://www.essepuntato.it/lode/owlapi/http:/vocab.e.gov.br/2013/09/loa

http://eelst.cs.unibo.it/apps/LODE/source?url=http://www.essepuntato.it/tmp/1444335235-ontology

http://www.essepuntato.it/lode/http:/www.essepuntato.it/tmp/1444335235-ontology#classes

http://www.essepuntato.it/lode/http:/www.essepuntato.it/tmp/1444335235-ontology#objectproperties

http://www.essepuntato.it/lode/http:/www.essepuntato.it/tmp/1444335235-ontology#dataproperties

http://www.essepuntato.it/lode/http:/www.essepuntato.it/tmp/1444335235-ontology#annotationproperties

http://www.essepuntato.it/lode/http:/www.essepuntato.it/tmp/1444335235-ontology#namespacedeclarations

http://www.essepuntato.it/lode/http:/www.essepuntato.it/tmp/1444335235-ontology#d4e272





http://www.essepuntato.it/lode/http:/www.essepuntato.it/tmp/1444335235-ontology#toc




Apêndices 146

is in domain of

codigo favorecidodp

, nome favorecidodp

is in range of

tem favorecidoop

6.5.2 pagamentoc back to ToC or Class ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/Pagamento

has super-classes

tem elemento despesaop

exactly 1 elemento despesa

tem funcaoop

exactly 1 funcao

valor pagamentodp

exactly 1

tem acaoop

exactly 1 acao

linguagem cidadadp

some string

tem g n dop

exactly 1 grupo nat despesa

tem unidade gestoraop

exactly 1 unidade gestorac

tem programaop

exactly 1 programa

tem subfuncaoop

exactly 1 subfuncao

tem unidade orcamentariaop

exactly 1 unidade orcamentaria

has sub-classes

pagamento publicoc, pagamento sigiloso

c

is in domain of

linguagem cidadadp

, tem classificador orcamentarioop

, tem orgaoop

, tem unidade gestoraop

,

valor pagamentodp

6.5.3 pagamento publicoc back to ToC or Class ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/PagamentoPublico

has super-classes

pagamentoc

codigo gestao pagamentodp

some string

data pagamentodp

exactly 1

codigo documentodp

exactly 1

is in domain of

codigo documentodp

, codigo gestao pagamentodp

, data pagamentodp

, tem favorecidoop

is disjoint with

pagamento sigilosoc

6.5.4 pagamento sigilosoc back to ToC or Class ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/PagamentoSigiloso

has super-classes

pagamentoc

is disjoint with






































Apêndices 147

pagamento publicoc

6.5.5 unidade gestorac back to ToC or Class ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/UnidadeGestora

has super-classes

nome unidade gestoradp

some string

codigo unidade gestoradp

exactly 1

is in domain of

codigo unidade gestoradp

, nome unidade gestoradp

is in range of

tem unidade gestoraop

6.6 Object Properties

tem acao

tem classificador orcamentario

tem elemento despesa

tem favorecido

tem funcao

tem g n d

tem orgao

tem programa

tem subfuncao

tem unidade gestora

tem unidade orcamentaria

6.6.1 tem acaoop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temAcao

has super-properties

tem classificador orcamentarioop

has range

acao

6.6.2 tem classificador orcamentarioop back to ToC or Object Property

ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temClassificadorOrcamentario

has characteristics: asymmetric, functional, irreflexive


























Apêndices 148

has sub-properties

tem acaoop

, tem elemento despesaop

, tem funcaoop

, tem g n dop

, tem programaop

, tem

subfuncaoop

, tem unidade orcamentariaop

has domain

pagamentoc

has range

classificador

6.6.3 tem elemento despesaop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temElementoDespesa



has range

elemento despesa

6.6.4 tem favorecidoop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temFavorecido


has domain

pagamento publicoc

has range

favorecidoc

6.6.5 tem funcaoop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temFuncao



has range

funcao

6.6.6 tem g n dop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temGND



has range

grupo nat despesa























Apêndices 149

6.6.7 tem orgaoop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temOrgao


has domain

pagamentoc

has range

orgao

6.6.8 tem programaop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temPrograma



has range

programa

6.6.9 tem subfuncaoop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temSubfuncao



has range

subfuncao

6.6.10 tem unidade gestoraop back to ToC or Object Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temUnidadeGestora


has domain

pagamentoc

has range

unidade gestorac














Apêndices 150

6.6.11 tem unidade orcamentariaop back to ToC or Object Property

ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/temUnidadeOrcamentaria



has range

unidade orcamentaria

6.7 Data Properties

codigo documento

codigo favorecido

codigo gestao pagamento

codigo unidade gestora

data pagamento

linguagem cidada

nome favorecido

nome unidade gestora

valor pagamento

6.7.1 codigo documentodp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/codigoDocumento

has characteristics: functional

has domain

pagamento publicoc

has range

string

6.7.2 codigo favorecidodp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/codigoFavorecido


has domain

favorecidoc

has range

string




















Apêndices 151

6.7.3 codigo gestao pagamentodp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/codigoGestaoPagamento


has domain

pagamento publicoc

has range

string

6.7.4 codigo unidade gestoradp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/codigoUnidadeGestora


has domain

unidade gestorac

has range

string

6.7.5 data pagamentodp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/dataPagamento


has domain

pagamento publicoc

has range

date time

6.7.6 linguagem cidadadp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/linguagemCidada

has range

string

is also defined as

annotation property













Apêndices 152

6.7.7 nome favorecidodp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/nomeFavorecido

has range

string

is also defined as

annotation property

6.7.8 nome unidade gestoradp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/nomeUnidadeGestora

has range

string

is also defined as

annotation property

6.7.9 valor pagamentodp back to ToC or Data Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/valorPagamento


has domain

pagamentoc

has range

decimal

6.8 Annotation Properties

linguagem cidada

nome favorecido

nome unidade gestora

6.8.1 linguagem cidadaap back to ToC or Annotation Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/linguagemCidada


label

has domain

pagamentoc

is also defined as
















Apêndices 153

data property

6.8.2 nome favorecidoap back to ToC or Annotation Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/nomeFavorecido


label

has domain

favorecidoc

is also defined as

data property

6.8.3 nome unidade gestoraap back to ToC or Annotation Property ToC

IRI: http://www.cin.ufpe.br/~wsf/ontopag/nomeUnidadeGestora


label

has domain

unidade gestorac

is also defined as

data property

6.9 Namespace Declarations back to ToC

default namespace


loa

http://vocab.e.gov.br/2013/09/loa#

owl

http://www.w3.org/2002/07/owl#

pag


rdf

http://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs

http://www.w3.org/2000/01/rdf-schema#

xsd

http://www.w3.org/2001/XMLSchema#

This HTML document was obtained by processing the OWL ontology source code through

LODE, Live OWL Documentation Environment, developed by Silvio Peroni.











http://www.essepuntato.it/lode

http://www.essepuntato.it/

Apêndices 154

APÊNDICE D

Modelo Conceitual

dissertação de mestrado - repositorio.ufpe.br · referente ao domínio do orçamento. os dados...

Documents