Construção de um Mashup de Compras Municipais usando LIDMS
Roberval Mariano - [email protected]
Vânia Maria Ponte Vidal - [email protected]
Introdução• Dados Governamentais Abertos estão sendo cada vez mais
publicados na Web, contribuindo para a transparência e a sua reutilização.
• Ao mesmo tempo, a prática de publicar dados no padrão “linked Data”, vem crescendo muito nos últimos anos, permitindo o desenvolvimento de aplicações melhores e mais inteligentes.
• Neste contexto, este trabalho tem como proposta apresentar resultados preliminares do projeto "Ligado nas compras municipais", que utiliza práticas de dados ligados na criação de um mashup de dados abertos de compras Públicas municipais ( CPM_Mashup) com informações coletadas de diferentes fontes..
Introdução• O CPM_Mashup foi desenvolvido usando o
framework LDMF, o qual busca minimizar o custo de construção e manutenção de mashups de dados através do uso de tecnologias da Web Semântica.
• O framework LDMF é baseado no uso de Linked Data Mashup Services (LIDMS).
• LIDMS são serviços Web que combinam e integram dinamicamente dados de múltiplas fontes e retornam o resultado no padrão de Linked Data.
CPM_Mashup• Domínio da aplicação
– Compras Públicas Municipais• Público-Alvo:
– Ordenadores de Despesas– Fiscais dos Tribunais de Contas– A Sociedade
• Objetivo Geral– Publicar e Integrar dados abertos de
diversas fontes de dados relacionadas às compras públicas
• Conjuntos de dados usados:
Exemplos de questões que se deseja responder com o CPM_Mashup
1. Quais empresas fornecedoras cadastradas no SICAF, que não têm restrições, que podem fornecer determinado produto a um município do Ceará?
2. Quais fornecedores não são monitorados pelo TCM-CE e estão cadastrados no SICAF?
3. Quais liquidações, empenhos e pagamentos foram realizados para empresas inidôneas após a declaração de inidoneidade?
4. Quais contratos foram assinados após a a declaração de inidoneidade?
5. Quantas empresas por município, existem nas listas de restrições do TCU, CGU e TSE?
6. Quais empresas apresentaram certificados de regularidade falsos ou cometeram falsidade ideológica?
Desafios na Integração de Dados
• Descobertas das fontes relevantes • Heterogeneidade das fontes de dados e
vocabulários• Qualidade dos dados, que podem ser
fragmentados, incorretos, inconsistentes e incompletos.
• Conflitos de URI, uma vez que diferentes URIs podem se referir ao mesmo objeto.
RDF Store RDBMS
Wrapper
Application Code
RDFaRDF/XML
CMS
Data Access, Integration and Storage Layer
Web of Data
Publication Layer
Application Layer
Web of DataIntegration
Central Repository
Data source federation
Architectures for Linked Data Integration
Architecture based on the use of LIDMS
LIDMS Execution Environment
Query PlanExecutor
RDF Store RDBMS
Wrapper
Federated QueryPlan
Client
URILIDMSResults
LIDMSProcessor
FASE 1: Integração Semântica
FASE 2: Carga e Limpeza dos Dados
FASE 3: Geração dos LIDMS (Linked Data Mashup Services)
Framework para Desenvolvimento de Linked Data Mashup com LIDMS
FASE 1: Integração Semântica
PASSO 1: Modelagem da Ontologia de Domínio.
PASSO 2: Seleção das Fontes de Dados
PASSO 3: Geração da Ontologias Exportadas (esquemas)
PASSO 4: Especificação das heurísticas para descoberta de same-as links.
FASE 1: Integração Semântica
12
Mediated mappings
Domain Ontology(schema)
Exported Ontology (schema)
Exported Ontology (schema)
Inter-OntologyLinks specifications
Data Source Schema
Data Source Schema
Data Source Mappings
...
“Organizing data integration around the domain ontology provides the middle layer that makes data integration more efficient – reducing the cost, maintenance and risk of the project”.
Domain Ontology: Formally specifies the concepts of the application Domain. It is used as the common vocabulary for data integration.
Exported Ontologies: formally describes the local source schemas in terms of the DO. The application ontology is a sub set of the Domain ontology.
Data Source Mappings: specifies the semantic mappings between the AO and Data source Schemas.
Mediated Mappings: specifies the instances of the DO using the GAV approach.
FASE 1: Integração Semântica
PASSO 1: Modelagem da Ontologia de Domínio.
PASSO 2: Seleção das Fontes de Dados
PASSO 3: Geração da Ontologias Exportadas (esquemas)
PASSO 4: Especificação das heurísticas para descoberta de same-as links.
FASE 1: Integração Semântica
PASSO 1: Modelagem da Ontologia de Domínio.
PASSO 2: Seleção da Fontes de Dados
PASSO 3: Geração das Ontologias Exportadas (esquemas)
PASSO 4: Especificação das heurísticas para descoberta de same-as links.
Onde achar os DGA de Compras Públicas?
SICAFFortaleza + 183
inabilitação inidoneidade
Inaptidão, suspensão
Cadastro Nacional de Empresas Inidôneas e
Suspensas (CEIS)
Abordagem de integração semântica Pay-as-You-Go
Só existem estes?
VCGE
FOAF
SICAF
Compras municipais enriquecida com Linked Data.
Fontes de dados relevantese ligações
FASE 1: Integração Semântica
PASSO 1: Modelagem da Ontologia de Domínio.
PASSO 2: Seleção dad Fontes de Dados
PASSO 3: Geração das Ontologias Exportadas (esquemas)
PASSO 4: Especificação das heurísticas para descoberta de same-as links.
API do TCM-CE
DGA formatos: CSV, RDF, JSON e XML
Ontologia Exportada TCM-CE**TCM-CE – Tribunal de Contas dos Municípios do Ceará
• Controladoria-Geral da União • (http://dados.gov.br/dataset/cadastro-nacional-de-empresas-inidoneas-e-suspensas/
resource/220837fc-820e-4b5a-b3b0-cf7c04d83925)
DGA formato .CSV
Ontologia Exportada CGU*
(http://www1.receita.fazenda. gov.br/)
DGA formato .TXT
Ontologia Exportada SPED*
*Sistema Público de Escrituração Digital
- Publica dados do IBGE e BACEN, relativos aos municípios, estados e países.
DGA formatos: CSV, RDF, JSON e XML
API do SICAF
Ontologia Exportada SICAF**SICAF - Sistema de Cadastramento Unificado de Fornecedores
DGA formatos: CSV e PDF
Ontologia Exportada TCU*
*TCU – Tribunal de Contas da União
(http://www.tse.jus.br/internet/tcu/ResponsaveisContasJulgadasIrregulares Eleicoes2012_Alfabetico.csv)DGA formatos: CSV e XLS
Ontologia Exportada TSE**Tribunal Superior Eleitoral
FASE 1: Integração Semântica
PASSO 1: Modelagem da Ontologia de Domínio.
PASSO 2: Seleção da Fontes de Dados
PASSO 3: Geração da Ontologias Exportadas (esquemas)
PASSO 4: Especificação das heuristicas para descobertas de same-as links.
• Pessoa Física: Usar CPF– O CPF determina o Nome e a sua filiação**. – sameAs para pessoas com o mesmo CPF e nome.
• Pessoa Jurídica: Usar CNPJ– O CNPJ determina a empresa (CNPJ base 8 primeiros
números) e o estabelecimento (matriz ou filial) (CNPJ completo - as 14 posições).
– sameAs para empresas com o mesmo CNPJ completo e nome.
Heurísticas Para Pessoas
** Uma pessoa pode ter vários CPF. Um ativo e outros suspensos, baixados, cancelados, etc.
Heurísticas para Município• Uso das informações do IBGE, em relação à país,
Estados e municípios, por ser fonte primária destas informações.
• Realizar junções pelo código do município do IBGE, em relação aos dados do: TCM-CE e SICAF.
• Exemplo: – TCM-CE.Id (032) SPED. Municipio.CodigoIBGE(2302602)– SICAF.Id (13510) SPED. Municipio.CodigoIBGE(2302602)– SPED.CodigoMunicipio.IBGE(2302602) = “Camocim”– Criar sameAs em relação ao SPED. Municipio.CodigoIBGE para
TCM-CE e SICAF
Compras Públicas Ontologias de Exportadas
Prefixes
@prefix map: <file:///stdout#> .@prefix db: <> .@prefix vcge: <http://vocab.e.gov.br/2011/03/vcge#> .@prefix vocab: <http://localhost:9092/vocab/resource/>. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .@prefix d2rq: <http://www.wiwiss.fu-berlin.de/suhl/bizer/D2RQ/0.1#> .@prefix jdbc: <http://d2rq.org/terms/jdbc/> .@prefix vcard: <http://www.w3.org/2006/vcard/ns#>.@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>.@prefix dbr: <http://dbpedia.org/resource/> .@prefix dbo: <http://dbpedia.org/ontology/> .@prefix dc: <http://purl.org/dc/terms/>.@prefix foaf: <http://xmlns.com/foaf/0.1/>.@prefix owl: <http://www.w3.org/2002/07/owl#> .@prefix spd: <http://arida.lia.ufc.br/sped>.@prefix tcm: <http://arida.lia.ufc.br/tcmce>.@prefix cgu: <http://arida.lia.ufc.br/restricao_cgu>.@prefix tcu: <http://arida.lia.ufc.br/restricao_tcu>.@prefix tse: <http://arida.lia.ufc.br/restricao_tse>.@prefix sic: <http://vocab.e.gov.br/sicaf#> .
FASE 2: CARGA, INTEGRAÇÃO E LIMPEZA DOS DADOS
– Step #1. Populate the Application Ontologies.
• Uses the semantic mappings to translate source data into EO vocabulary.
– Step #2. Resolve Identity conflits• Uses Heuristics to discovery inter-
ontology links. • Data sources that overlap in content
use different identifiers for the same real-world entity.
– Step #3. Cleanse data; resolving the conflicting values .
31
Inter-Ontologylinks
...
Carga, Integração e Limpeza dos Dados
Data Source
Data Source
Data Source
EO1 EOn
Carga dos DadosConsumo, via API: TCM-CE e SICAF. Após contatos algumas consultas, via API, foram ajustadas e passaram a disponibilizar os dados. Preocupação, quanto à proveniência, a qual será incluída na próxima versão.
Limpeza dos Dados
• Divergências no nome de município foram resolvidas pelo código IBGE. Exemplos:– Informado Beriutaba Correto para o código IBGE
2311702 (Reriutaba)– Isto resultou em: Icapui ser alterado para Icapuí,
Milagress ser alterado para Milagres e Vazea Alegre ser alterado para Várzea Alegre.
• Números com Dígito Verificador - DV, como CNPJ e CPF, foram recalculados os DV – Inconsistências repassadas às instituições responsáveis pela
fonte de dados. Algumas já providenciaram as correções.
Limpeza dos Dados
• CNPJ_CPF convertidos em CPF e CNPJ: – Detectados casos que não eram CNPJ e nem CPF. Instituições
informaram criar um número, quando não tinham a informação.
• CPF, com CNPJ ou nulo: – Instituição informou estar saneando as inconsistências e
republicando diariamente o arquivo com as informações. • Recursos da Dbpedia sendo referenciadas, mas com link
quebrado: – Programa em desenvolvimento, para realizar consumo, via
consulta SPARQL. Ao ser detectado o link quebrado se sinaliza para a fonte de dados. Caso não seja corrigido após um tempo t é retirada a referência no Mashup.
Compras Públicas Ontologias de Exportadas
FASE 3: GERAÇÃO DOS LIDMS
LIDMS Licitação• Problema Jurídico :
– Para a contratação de serviços por meio de empresas terceirizadas, é preciso que sejam realizadas licitações.
• Problema Administrativo :– Para que se possa iniciar o processo licitatório é preciso estabelecer a
média do custo do serviço a ser contrato, com base nos valores informados por, no mínimo, três empresas capazes de participar da licitação, a fim de se fazer o provisionamento orçamentário necessário.
• Solução atual do problema:– Procedimento manual (envio de cartas, e-mail, consulta a sites),
procurando identificar empresas capazes de fornecer a proposta de serviço.
– Principais dificuldades: • Encontrar as empresas (o máximo possível) que executam o serviço e não
tenham restrições para participar da futura licitação. • Combater a carterização*, com a chamada de novas empresas e empresas
externas ao município.
LIDMS Licitação• CONSULTA
Dada um atividade (CNAE) obter: 1. Os fornecedores que executam o serviço.2. As restrições no TCU, CGU e TSE dos fornecedores, caso
existam. 3. Os empenhos já emitidos pelos fornecedores. (Ou seja,
comprovar que a empresa já presta, ou prestou, serviço a alguma prefeitura).
** CNAE : Classificação Nacional de Atividades Econômicas
LIDMS – Linked Data Mashup Services
• Web services that specifies transformation and integration of data from multiple sources and return the result as Linked Data.
• Each LIDMS is associated with a federated query plan defined at design time.– Plans defined at design time allow precise adjustments to improve its
performance.
• Data extraction based on input parameters.• URIs composed of:
– query plan identification;
– query plan parameters;
– output format.
LIDMS GENERATION
LIDMSExecution Environment
Execution Engine
RDF StoreCache,
Metadata
RDF Store RDBMS
Wrapper
LIDMS Creation Environment
Execution Plan Generation
SemanticIntegration
Application Code
Integration View Specification
Execution Plan
LIDMS Generation Process• LIDMS Specification
• Triple < P, O, Q >
– P – Parameters
– O – Ontology that describes the returned format
– Q – Parameterized SPARQL Query
• LIDMS Implementation– Plan is generated automatically from the
parameterized SPARQL query on the DO.
– Conversion from plan to QEF Template for storage in specific repository.
Passo 1: Projeto conceitual dos LIDMS– Visão de integração definida através de uma
consulta parametrizada SPARQL sobre a OD.
VCD1 VCD2 VCDn...
OD
Visões de conteúdo dinâmico
Ontologia de Domínio
Consultas parametrizadas sobre OD
Ontologias Exportadas
OE1 OE2 OE3... OEn
Passo 2: Geração dos planos de execução– Ocorre em tempo de projeto.– Processo adaptado a partir de [Pinheiro et al.
2009]
ConsultaSPARQL
Tradução Reformulação daConsulta
A B
C
C
Otimização
A B
C
Plano deExecução
Iter1
Iter2
Iter3
Iter4
A
B
C
RESULTADO
PREFIX s:<http://sales/>PREFIX rdf:<...> SELECT ?t WHERE { ?p rdf:type s:Book. ?p s:title ?t . ?p s:hasPub ?pub . ?pub s:country ?c FILTER regex(?c, ?:country) .}
Pós-processamento
A
B
C
1 2 3 4 5
Passo 1: Especificação Conceitual do LIDMS LicitaçãoP: Parâmetros de EntradaCódigo do CNAE
O: Descrição da SaídaDados do Fornecedor, a identificação no SICAF e TCM-CE, o(s) CNAE(s), as restrições que existirem (TCU, CGU, TSE), o número empenho e o município, para o qual prestou serviço.
Q: QueryPREFIX cm:<http://arida.lia.ufc.br/compras_municipais>
SELECT ?cnpj ?name ?address ?post_code ?phone ?id ?cnae ?restricao ?empenho ?municipioWHERE {?dforn cm:CNAE ?:codigoCNAE; dbr:CNPJ ?cnpj; foaf:name ?name; foaf:address ?address; vcard:post_code ?post_code; foaf:phone ?phone dbr:id ?id.?cnpj cm:restricao ?restricao.?cnpj cm:participa ?empenho. ?undorc cm:realiza ?empenho? undorc cm:orgao ?orgao.?Munic cm:ehCompostoDe ?Orgao.?munic cm:codigoibge ?ibge?ibge vcard:city ?municipio.}
Passo 2: LIDMS IMPLEMENTATIONPROJECT
(?cnpj ?name ?address ?post_code ?phone ?id ?cnae
?restricao ?empenho ?municipio)
BGP?munic cm:codigoibge ?ibge?ibge vcard:city ?municipio.
SERVICEspd:municipio
LEFT_JOINBGP
?dforn sic:CNAE “8621601”; dbr:CNPJ ?cnpj; foaf:name ?name;
foaf:address ?address;vcard:post_code ?post_code;
foaf:phone ?phone; dbr:id ?id.
SERVICEsic:fornecedor
BGPsameAs tcm:CNPJ ?CNPJ.sameAs tcu:CNPJ ?CNPJ.sameAs cgu:CNPJ ?CNPJ.
?Empenho tcm:participa ?CNPJ?Empenho tcm:numero ?Emp
SERVICEtcm:fornecedor
LEFT_JOIN
LEFT_JOIN
BGP?id dbr:CNPJ ?CNPJ.?id tcu:sancao ?tcu
BGP?id dbr:CNPJ ?CNPJ.?id cgu:sancao ?cgu
SERVICEcgu:Empresa
SERVICEtcu:EmpresaJOIN
PROJECT(?cnpj ?name ?address ?post_code
?phone ?id ?cnae ?restricao ?empenho ?municipio)
?dforn cm:CNAE “8621601”; dbr:CNPJ ?cnpj;foaf:name ?name;foaf:address
?address;vcard:post_code ?post_code; foaf:phone ?phone dbr:id ?id.?cnpj cm:restricao ?restricao.
?cnpj cm:participa ?empenho. ?undorc cm:realiza ?empenho.? undorc cm:orgao ?orgao.
?Munic cm:ehCompostoDe ?Orgao.?munic cm:codigoibge ?ibge
?ibge vcard:city ?municipio.
Federated Query Plan
Conclusão e trabalhos futuros• O framework proposto busca minimizar
o custo de construção e manutenção de mashups de dados através do uso de tecnologias da Web Semântica.
• Como trabalhos futuros, pretende-se:– Adição da Proveniência, com uso de ancoragem temporal, com o time stamp dado pelo
Observatório Nacional.– MD5 dos arquivos e das linhas do arquivo, para atualização apenas das informações
realmente alteradas e não de todo o arquivo.– Uso de agentes de software – Uso de uma ferramenta de benchmark de Linked Data. – Especificação do mecanismo de consulta SPARQL temporal. – Automatização das cargas. – Apresentação dos resultados às instituições proprietárias das fontes de dados e solicitação,
para que disponibilizem seus dados como Linked Data, via endpoint SPARQL. – Inclusão da lista de preços máximos aos órgãos públicos, para aquisição de remédios, pela
ANVISA. – Adições de novas fontes externas: SEFAZ/CE, ANVISA, NCM e GTIN.
O que passamos a saber, após o Mashup das Compras Municipais
Temos controles , cuja ausência de interligação entre eles permite saber o que ocorreu, mas não coibir o que vai acontecer.