1. Universidade Federal de Mato Grosso do Sul
Cˆmpus de Coxim
a
Bacharelado em Sistemas de Informa¸ao
c˜
Uma Estrat´gia para Publica¸˜o dos Dados
e ca
da Base do CEB-INEP/MEC no Padr˜o a
Linked Open Data
Fernando Maia da Mota
UFMS-CPCX
Coxim - MS
Junho/2011

2. Universidade Federal de Mato Grosso do Sul
Cˆmpus de Coxim
a
Bacharelado em Sistemas de Informa¸ao
c˜
Fernando Maia da Mota
Uma Estrat´gia para Publica¸˜o dos Dados
e ca
da Base do CEB-INEP/MEC no Padr˜o a
Linked Open Data
Trabalho de conclus˜o de curso apresen-
a
tado ao Cˆmpus de Coxim da Univer-
a
sidade Federal de Mato Grosso do Sul-
UFMS, como requisito parcial para a
obten¸ao do t´
c˜ ıtulo de Bacharel em Sis-
temas de Informa¸˜o sob orienta¸ao da
ca c˜
Profa Ma. Karen Kiomi Nakazato e coori-
enta¸ao do Prof. Dr. Marcelo Augusto
c˜
dos Santos Turine.
Coxim - MS
Junho, 2011

4. Agradecimentos
`
A meus pais e familia, pela educa¸˜o que me deram, onde sempre me
ca
mostraram que a honestidade e trabalho, s˜o as melhores formas de alcan¸ar
a c
os objetivos na vida.
Aos mestres que me deram a oportunidade de amadurecimento pessoal
e profissional atrav´s de seus ensinamentos dentro da sala de aula e pelos
e
exemplos de vida, em especial aos mestres Amaury Antˆnio de Castro Junior,
o
Gedson Faria, Leila Lisiane Rossi e minha estimada orientadora Karen Kiomi
Nakazato pela orienta¸ao, aten¸ao, confian¸a, apoio e amizade n˜o s´ durante
c˜ c˜ c a o
a cria¸ao deste trabalho mas sim durante toda a gradua¸ao.
c˜ c˜
`
A todos os amigos, que sem sua presen¸a e apoio tornaria esta camin-
c
hada muito mais desgastante e mon´tona, em especial aos CAFF(Claudeir,
o
Ameixa, eu e Fuska) e Glasielly.
Por fim, a todos que contribu´ıram direta ou indiretamente.

5. Resumo
Dados governamentais abertos consistem na publica¸ao de dados sobre in-
c˜
forma¸oes p´blicas em formatos que permitem o seu compartilhamento,
c˜ u
acesso, descoberta e f´cil manipula¸ao pelos consumidores desses dados.
a c˜
Linked Open Data ´ um padr˜o da Web semˆntica que se baseia na rep-
e a a
resenta¸˜o de dados em forma de triplas RDF. Este trabalho prop˜e uma
ca o
estrat´gia para publica¸ao dos dados da base de dados do Censo Educa-
e c˜
cional Brasileiro(CEB) no padr˜o Linked Open Data, neste censo s˜o co-
a a
letados dados sobre os estabelecimentos de ensino, matr´ ıculas, fun¸˜es dos
co
docentes e rendimento escolar. A estrat´gia se caracteriza em 6 passos, s˜o
e a
eles a carga dos microdados do Instituto Nacional de Estudos e Pesquisas
Educacionais(INEP) para um Sistema de Gerenciamento de Banco de Da-
dos(SGBD), a avalia¸˜o das tabelas criadas para a cria¸˜o de um mod-
ca ca
elo l´gico normalizado de banco de dados, a implementa¸ao de uma fer-
o c˜
ramenta em JAVA para carregar os dados no novo modelo criado, e em
seguida a aplica¸ao da ferramenta STDTRIP, gera¸˜o das triplas em RDF
c˜ ca
utilizando a ferramenta TRIPLIFY e finalmente o armazenamento das triplas
em um servidor de triplas. Esta estrat´gia foi implementada neste trabalho
e
utilizando–se os dados do CEB do ano de 1995.
Palavras chave: CEB, Linked Open Data,RDF, Web semˆntica. a
4

6. Abstract
Open government data consists in the publication of public information data
in formats that allow them to be share, access, discovery and easy handling by
consumers of such data. Linked Open Data is a Semantic Web standard based
on the representation of data as RDF triples. This work proposes a data
publication strategy from the Brazilian Educational Census (CEB) database
in a Linked Open Data format. In this census are collected data about
schools, enrollment, teachers’ roles, and educational school performance. The
strategy consist in six stages. In the first stage the Educational Research
National Institute (INEP) microdata is loaded into a Database Management
System (DBMS), secondly the database is normalized in a third normal form
(3NF) model, third a Java tool was implemented to load the data into the
new normalized model, in the fourth stage the StdTrip tool was applied to
assist in the ontology conceptual model, in the fifth stage the Triplify tool
generate the RDF triples and finally the RDF triples were stored into a triples
store. This strategy was implemented in this work using data from the 1995
year Brazilian Educational Census.
Keywords: CEB, Linked Open Data,RDF, Semantic Web.
5

7. Conte´ do
u
1 Introdu¸˜o
ca 9
1.1 Contexto e motiva¸˜o . . . .
ca . . . . . . . . . . . . . . . . . . . 9
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1 Objetivos espec´ıficos . . . . . . . . . . . . . . . . . . . 10
1.3 Organiza¸˜o do texto . . . .
ca . . . . . . . . . . . . . . . . . . . 11
2 Fundamenta¸˜o Te´rica
ca o 12
2.1 O projeto Web–PIDE . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Web semˆntica . . . . . . . . . . . . . . . . . . . . . . .
a . . . 16
2.3 Ontologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Reuso de ontologias . . . . . . . . . . . . . . . . . . . . 17
2.4 Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . 17
2.5 Resource Description Framework (RDF) . . . . . . . . . . . . 19
2.6 Dados abertos governamentais . . . . . . . . . . . . . . . . . . 20
2.7 Princ´
ıpios de Linked Open Data . . . . . . . . . . . . . . . . . 21
2.8 SPARQL Protocol and RDF Query Language (SPARQL) . . . 23
3 A Estrat´gia para Publica¸˜o dos Dados
e ca 24
3.1 Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Implementa¸˜o da etapa de carga dos dados . . . . . . . . .
ca . 26
3.3 Implementa¸˜o da etapa de normaliza¸ao . . . . . . . . . . .
ca c˜ . 32
3.4 Implementa¸˜o da etapa de extra¸ao e carga para o modelo
ca c˜
normalizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Implementa¸˜o da etapa de cria¸ao da ontologia . . . . . . .
ca c˜ . 37
3.5.1 Processo STDTRIP . . . . . . . . . . . . . . . . . . . . 38
3.5.2 Aplica¸˜o da STDTRIP . . . . . . . . . . . . . . . .
ca . 40
3.6 Implementa¸˜o da etapa de triplifica¸ao . . . . . . . . . . .
ca c˜ . 41
3.6.1 Aplica¸˜o do TRIPLIFY . . . . . . . . . . . . . . . .
ca . 41
3.7 Implementa¸˜o da etapa de armazenamento das triplas . . .
ca . 42
6

8. Conte´do
u ufms
4 Conclus˜o
a 44
4.1 Contribui¸˜es do trabalho . . . . . . . . . . . . . . . . . . . . 44
co
4.2 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . 46
4.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . 46
A Modelo Normalizado do CEB/1995 47
Referˆncias
e 50
7

9. Lista de Figuras
2.1 Bases de Dados do INEP (2010) . . . . . . . . . . . . . . . . . 14
2.2 Arquitetura da Plataforma Web–PIDE[Turine et al. , 2006] . . 15
2.3 Declara¸ao de Namescapes[Vanni, 2009] . . . . . . . . . . . . . 18
c˜
3.1 Etapas para publica¸˜o dos dados no padr˜o Linked Open Data
ca a 25
3.2 Parte do Arquivo ”Leia-me.pdf” do CEB de 1995[INEP, 2011] 28
3.3 Exemplo de arquivo ASCII, microdados de 1995 . . . . . . . . 29
3.4 Exemplo de arquivo SAS para leitura de dados, microdados
de 1995 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Arquitetura da ferramenta ata Extractor ASCII to Relational-
DEAR[Siqueira, 2009] . . . . . . . . . . . . . . . . . . . . . . 31
3.6 1o Modelo normalizado criado . . . . . . . . . . . . . . . . . . 33
3.7 Exemplo de normaliza¸ao das colunas n´mericas . . . . . . . .
c˜ u 34
o
3.8 2 Modelo relacional normalizado . . . . . . . . . . . . . . . . 36
3.9 Ordem de Execu¸˜o da DEPOM . . . . . . . . . . . . . . . . .
ca 37
3.10 Arquitetura STDTRIP[Salas et al. , 2010b] . . . . . . . . . . . 38
3.11 Sequˆncia dos passos[Salas et al. , 2010b] . . . . . . . . . . . .
e 39
3.12 Servidor OPENLINK VIRTUOSO . . . . . . . . . . . . . . . . 43
4.1 Exemplo de consulta sobre os dados triplicados do CEB do
ano de 1995 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8

10. Cap´
ıtulo 1
Introdu¸˜o
ca
Neste capitulo s˜o apresentados o contexto, a motiva¸˜o, objetivo e a
a ca
organiza¸ao deste trabalho.
c˜
1.1 Contexto e motiva¸˜o
ca
Com o crescente volume de informa¸˜es no nosso dia a dia surge a neces-
co
sidade de ferramentas automatizadas que auxiliem no processo de armazena-
mento e recupera¸ao dos dados de forma r´pida e pr´tica. Nas institui¸oes de
c˜ a a c˜
ensino ´ realizada uma s´rie de provas para avaliar a qualidade e as condi¸oes
e e c˜
da educa¸˜o no Brasil. O Instituto de Estudos e Pesquisas em Educa¸˜o
ca ca
An´ Teixeira(INEP)–MEC ´ respons´vel pelas avalia¸oes do Sistema Ed-
ısio e a c˜
ucacional Brasileiro. Atrav´s das pesquisas realizadas pelo INEP ´ poss´
e e ıvel
obter informa¸oes claras e confi´veis aos gestores, pesquisadores, educadores e
c˜ a
p´blico em geral. Contudo, essas informa¸˜es nem sempre s˜o de f´cil acesso
u co a a
a essas pessoas. Com o objetivo de contribuir e facilitar as consultas sobre os
dados do INEP obtidos atrav´s das provas e pesquisas promovidas por ele,
e
foi proposto pela UFMS em parceria com a UFSCar o projeto de pesquisa
Web–PIDE o qual prevˆ a cria¸˜o de uma plataforma de integra¸˜o dos da-
e ca ca
dos educacionais do INEP[Turine et al. , 2006]. Este trabalho apresenta uma
iniciativa de Linked Open Data que prevˆ o uso de padr˜es abertos, suporta-
e o
dos pela World Wide Web Consortium(W3C), para exposi¸˜o dos dados na
ca
Web por meio de princ´ ıpios simples, envolvendo padroniza¸˜o semˆntica por
ca a
tr´s dos dados, este trabalho em especial foi desenvolvido em parceria com a
a
PUC-Rio, polo de pesquisas sobre Web semˆntica.a
Para potencializar a utilidade desses dados, ´ necess´rio implantar o con-
e a
ceito de Linked Data, que al´m de disponibilizar liga a informa¸˜o a out-
e ca
ros dados, podendo assim, ser acessada e reutilizada com mais facilidade
9

11. 1.2. Objetivos ufms
[Berners-Lee & Hendler, 2001].
Este trabalho utiliza parte da base de dados do Censo Educacional
Brasileiro (CEB)–INEP–MEC, que com atualiza¸ao anual disp˜e de in-
c˜ o
forma¸oes sobre as institui¸oes escolares nos diversos n´
c˜ c˜ ıveis de ensino, como
n´mero de matr´
u ıculas, o volume de alunos, o movimento escolar, carac-
ter´ısticas b´sicas da institui¸˜o, equipamentos e edifica¸˜es existentes, al´m
a ca co e
de dados sobre o pessoal t´cnico e administrativo e as caracter´
e ısticas dos
docentes, entre outros.
Os dados das bases de dados do INEP s˜o disponibilizados atualmente
a
no formato de microdados[INEP, 2011](arquivos de texto), esse formato difi-
culta a sua reutiliza¸˜o por parte da sociedade. Segundo Berners-Lee (2001)
ca
as vantagens de disponibilizar os dados abertos para a sociedade s˜o ines-a
tim´veis, pois n˜o h´ como prever qual dire¸ao os conjuntos de dados abertos,
a a a c˜
ligados a outros dados n˜o dispon´
a ıveis ao primeiro fornecedor, ir˜o tomar.
a
Com o uso de Web semˆntica ´ poss´ criar novas informa¸oes por meio
a e ıvel c˜
das interliga¸˜es de dados governamentais abertos com outras fontes de da-
co
dos, o que possibilita para qualquer interessado o desenvolvimento de pro-
gramas e aplica¸˜es de interesse p´blico ou privado, utilizando os dados de
co u
forma que se quer foi prevista pelo fornecedor dos dados, neste formato a
utilidade destes dados ´ incalcul´vel[Baldus, 2011].
e a
Portanto al´m do fator cient´
e ıfico este trabalho tamb´m possui um fator
e
social e pol´ıtico.
1.2 Objetivos
Este trabalho tem por objetivo geral propor uma estrat´gia para a
e
publica¸ao dos dados da base de dados do CEB no padr˜o Linked Open
c˜ a
Data para utiliza¸˜o posterior em aplica¸˜es de Web Semˆntica. Esses
ca co a
dados atualmente s˜o disponibilizados pelo INEP/MEC no formato de
a
microdadados[INEP, 2011].
1.2.1 Objetivos espec´
ıficos
Para que o objetivo geral fosse alcan¸ado, objetivos espec´
c ıficos foram
desenvolvidos e conclu´
ıdos, conforme sequˆncia abaixo:
e
• Estudo da base de dados do CEB disponibilizados, seus relacionamen-
tos, objetos e tipo dos dados;
• Estudo dos conceitos de Web Semˆntica;
a
10

12. 1.3. Organiza¸˜o do texto
ca ufms
• Estudo do modelo RDF de intercˆmbio de metadados;
a
• Estudo da linguagem SPARQL utilizada na consulta de triplas;
• Pesquisar a ferramenta TRIPLIFY para a transforma¸ao dos dados em
c˜
RDF;
• Pesquisar a ferramenta STDTRIP que dar´ suporte no processo de
a
cria¸ao e interoperabilidade da ontologia a ser desenvolvida neste tra-
c˜
balho, al´m de gerar automaticamente o arquivo de configura¸˜o da
e ca
ferramenta TRIPLIFY;
• Pesquisar o servidor OPEN LINK VIRTUOSO para ser utilizado como
reposit´rio de triplas;
o
1.3 Organiza¸˜o do texto
ca
Este trabalho est´ organizado em 4 Cap´
a ıtulos e 1 anexo, sendo que seus
respectivos objetivos s˜o resumidos a seguir.
a
Capitulo 1 – Introdu¸˜o, caracteriza o contexto e evidencia as lacunas
ca
que motivaram o desenvolvimento deste trabalho, apresentando tamb´m seus
e
objetivos.
Capitulo 2 – O projeto Web–PIDE, conceitos de Web Semˆntica, Ontolo-
a
gias, Reuso de Ontologias, Dados Abertos Governamentais e princ´ ıpios de
Linked Open Data al´m das tecnologias OWL e RDF.
e
Capitulo 3 – A estrat´gia, seu desenvolvimento e as etapas necess´rias
e a
para a conclus˜o do trabalho.
a
Capitulo 4 – Conclus˜es, apresenta as conclus˜es obtidas no trabalho, as
o o
limita¸˜es detectadas e sugest˜es de trabalhos futuros.
co o
O anexo A apresenta por completo e em qualidade de resolu¸˜o o modelo
ca
l´gico da base de dados normalizada criada para a conclus˜o do trabalho.
o a
11

13. Cap´
ıtulo 2
Fundamenta¸˜o Te´rica
ca o
Neste cap´ ıtulo ser˜o expostos os principais conceitos e suas referˆncias
a e
sobre a transforma¸ao de dados para publica¸˜o no formato Linked Open
c˜ ca
Data.
Tamb´m ser˜o apresentados os resultados dos estudos apresentados nos
e a
objetivos espec´ıficos deste trabalho: estudo da base de dados do CEB, estudos
dos conceitos de Web semˆntica, estudo do modelo RDF de intercˆmbio de
a a
dados e a linguagem SPARQL para consulta de triplas.
2.1 O projeto Web–PIDE
A produ¸˜o de dados e informa¸oes estat´
ca c˜ ıstico–educacionais de forma agil
´
e de qualidade, que retrate a realidade do setor educacional, ´ o instrumento
e
b´sico de avalia¸˜o, planejamento e aux´ ao processo decis´rio para o es-
a ca ılio o
tabelecimento de pol´ ´
ıticas de melhoria da educa¸ao brasileira. E por meio
c˜
dos censos educacionais que se busca garantir a utiliza¸˜o da informa¸ao
ca c˜
estat´
ıstica neste processo, gerando os indicadores necess´rios ao acompan-
a
hamento do setor educacional[Jannuzzi, 2001].
Neste contexto, o Minist´rio da Educa¸ao (MEC) disponibiliza, por meio
e c˜
do INEP, uma s´rie de bases e informa¸˜es das diversas modalidades de
e co
avalia¸oes educacionais do sistema educacional brasileiro. O INEP tem
c˜
um papel estrat´gico, unico e essencial para o fortalecimento da gest˜o de
e ´ a
pol´
ıticas educacionais e o desenvolvimento da educa¸˜o brasileira.
ca
O INEP ´ respons´vel pelo levantamento e produ¸˜o das estat´
e a ca ısticas
b´sicas da educa¸˜o nacional, por meio da realiza¸˜o de levantamentos
a ca ca
peri´dicos que abrangem os diferentes n´
o ıveis e modalidades de ensino. A
fim de ampliar o conhecimento sobre a realidade do sistema educacional
brasileiro, o INEP desenvolve v´rios estudos sobre as avalia¸˜es que possam
a co
12

14. 2.1. O projeto Web–PIDE ufms
servir de base para a elabora¸˜o de pol´
ca ıticas p´blicas educacionais.
u
As avalia¸oes aplicadas pelo INEP at´ o ano de 2010 podem ser mapeadas
c˜ e
quanto ao dom´ ınio (Educa¸ao B´sica ou Superior) ou sistema de avalia¸ao.
c˜ a c˜
Deste modo, pode–se observar na figura 2.1 uma estrutura das avalia¸˜es co
mapeadas juntamente com outros dados importantes: nome da divulga¸˜o, ca
ano de aplica¸˜o e situa¸˜o.
ca ca
Segundo Cerqueira e Rigotti (2001), as bases de dados educacionais
consideradas de maior importˆncia s˜o o Censo Escolar ou Censo Es-
a a
colar Brasileiro(CEB) e o Sistema Nacional de Avalia¸ao da Educa¸ao
c˜ c˜
B´sica(SAEB), devido a sua magnitude e abrangˆncia, sendo que o CEB
a ` e
´ o foco deste trabalho.
e
O CEB ´ um levantamento de dados estat´
e ıstico–educacionais de ambito
ˆ
nacional, realizado todos os anos e desenvolvido com a colabora¸˜o das sec-
ca
retarias estaduais e municipais de Educa¸˜o, com a participa¸ao de todas as
ca c˜
escolas p´blicas e privadas do pa´ Assim, o CEB ´ considerado o princi-
u ıs. e
pal instrumento de coleta de informa¸oes da educa¸ao b´sica, que abrange o
c˜ c˜ a
ensino regular (educa¸ao infantil e ensinos fundamental e m´dio), educa¸ao
c˜ e c˜
especial e educa¸ao de jovens e adultos (EJA). Neste caso, s˜o coletados da-
c˜ a
dos sobre os estabelecimentos de ensino, matr´ ıculas, fun¸˜es dos docentes,
co
movimento e rendimento escolar[Hernandes, 2010].
13

15. 2.1. O projeto Web–PIDE ufms
Figura 2.1: Bases de Dados do INEP (2010)
Em janeiro de 2007 foi aprovado pelo INEP/CAPES o projeto de pesquisa
da Funda¸˜o Universidade Federal de Mato Grosso do Sul (UFMS) em parce-
ca
ria com a Universidade Federal de S˜o Carlos (UFSCar) intitulado ”Web–
a
PIDE — Uma Plataforma Aberta para Integra¸˜o e Avalia¸˜o de Dados Ed-
ca ca
ucacionais na Web”, como parte do Programa Observat´rio de Educa¸˜o que
o ca
objetiva ser um sistema computacional para integrar e disponibilizar os da-
dos educacionais do INEP por meio de uma linguagem comum e padronizada
de marca¸˜o intitulada LIDE (Linguagem de Marca¸˜o de Dados Educa-
ca ca
cionais). As LIDEs s˜o definidas com a linguagem de marca¸ao XML (eX-
a c˜
tensible Markup Language), que torna os documentos leg´ıveis para as pessoas
e manipul´veis pelos computadores. Para completar a camada respons´vel
a a
14

16. 2.1. O projeto Web–PIDE ufms
pelos dados na arquitetura do projeto Web–PIDE, utiliza-se a tecnologia
de Data Warehouse (DW) e de Data Marts (DM) para sistematizar e ar-
mazenar os dados hist´ricos com o objetivo de facilitar a tomada de decis˜o
o a
pelos gestores[Savitraz, 2010], de acordo com a Figura 2.2.
Figura 2.2: Arquitetura da Plataforma Web–PIDE[Turine et al. , 2006]
Para a cria¸ao da P–LIDE, considerando todas as atividades necess´rias
c˜ a
para sua cria¸˜o, utiliza–se o P–LIDE — Processo para defini¸˜o da lin-
ca ca
guagem para integra¸˜o de Dados Educacionais, que tem na SEVTool (Search
ca
and edition Visualization) um apoio computacional para permitir que os da-
dos referentes `s avalia¸oes do INEP sejam padronizadas sintaticamente,
a c˜
sendo que o uso de visualiza¸ao facilita essa tarefa. Ambas ferramentas
c˜
foram desenvolvidas como produtos de uma disserta¸ao de mestrado na
c˜
UFSCar[Hernandes, 2010].
Outra contribui¸˜o para o projeto Web–PIDE, na forma de disserta¸˜o
ca ca
de mestrado, ´ a utiliza¸ao do SB-INDEX para o projeto de um Data Ware-
e c˜
house geogr´fico [Siqueira, 2009], que provˆ mecanismo de indexa¸˜o capaz
a e ca
de reduzir o tempo de resposta das consultas envolvendo grandes quanti-
15

17. 2.2. Web semˆntica
a ufms
dades de dados, utilizando predicados espaciais, al´m de propor o modelo de
e
representa¸˜o de DW no esquema estrela.
ca
O CEB ´ uma das bases de dados de estudo do projeto Web–PIDE, que
e
ser´ utilizada neste trabalho.
a
2.2 Web semˆntica
a
Atualmente, a maior parte dos recursos prim´rios presentes na Web est´
a a
em linguagem natural, de modo que s´ podem ser interpretados por seres
o
humanos. Nos deparamos com essa situa¸ao diariamente, quando realizamos
c˜
buscas na Web e somos for¸ados a ”filtrar” informa¸˜es que, mesmo dentro
c co
dos crit´rios de busca solicitados, pertencem a diferentes contextos. Um
e
exemplo simples ´ fazer uma pesquisa sobre arvores – carvalhos. O resultado
e ´
dessa busca, al´m de p´ginas referentes a esse tipo de ´rvore, tamb´m traz
e a a e
pessoas cujo sobrenome ´ Carvalho, empresas de guindaste e escrit´rios de
e o
advocacia [Breitman, 2005].
Segundo Benners-Lee, Hendler e Lassila(2001) ”[...] a Web Semˆntica ´
a e
uma extens˜o da Web atual, na qual ´ dada ` informa¸˜o um significado bem
a e a ca
definido, permitindo que computadores e pessoas trabalhem em coopera¸˜o.”
ca
Para Breitman(2005), a Web atual pode ser definida como a Web
Sint´tica, onde os computadores s˜o respons´veis apenas por apresentar as
a a a
informa¸˜es, mas a interpreta¸˜o fica a cargo do usu´rio, ocasionando difi-
co ca a
culdades em encontrar informa¸oes de forma eficiente e eficaz na Web como
c˜
mostrado no exemplo de busca sobre a ´rvore carvalho.
a
A proposta da Web Semˆntica ´ atender a quest˜o anterior atrav´s de
a e a e
metadados que descrevem os dados contidos em um recurso da Web, esses
metadados devem ser padronizados para que a sua utiliza¸˜o seja feita por
ca
pessoas e softwares. Um desses padr˜es mais utilizados pela Web Semˆntica
o a
´ o uso de ontologias, que nada mais s˜o do que vocabul´rios que descrevem
e a a
uma ´rea do conhecimento.
a
2.3 Ontologias
Uma ontologia define os termos utilizados para descrever e representar
uma area de conhecimento. Ontologias s˜o utilizadas por pessoas, bases
´ a
de dados e aplica¸˜es que necessitam de partilhar informa¸˜o sobre um
co ca
dom´ınio (um dom´ ınio espec´
ıfico ´ apenas uma ´rea tem´tica ou ´rea do
e a a a
conhecimento, como medicina, constru¸ao, fabrica¸˜o de ferramenta, bens
c˜ ca
imobili´rios, repara¸˜o autom´vel, gest˜o financeira, etc.)[W3C, 2011].
a ca o a
16

18. 2.4. Web Ontology Language (OWL) ufms
Ontologias incluem defini¸˜es de conceitos b´sicos no dom´ e relaciona-
co a ınio
mentos entre eles. As ontologias codificam o conhecimento sobre um dom´ ınio
e conhecimento que cobre mais do que um dom´ ınio. Desta forma, elas fazem
com que esse conhecimento seja reutiliz´vel.
a
A palavra ontologia tem sido usada para descrever artefatos com difer-
entes graus de estrutura. Estas v˜o desde simples taxonomias (como hierar-
a
quia Yahoo), esquemas de metadados (como o Dublin Core), at´ as teorias
e`
l´gicas. A Web Semˆntica precisa de ontologias com um grau significativo
o a
de estrutura. E´ necess´rio especificar descri¸oes para os seguintes tipos de
a c˜
conceitos:
• Classes (aspectos gerais) em muitos dom´
ınios de interesse
• Rela¸oes que podem existir entre coisas
c˜
• Propriedades (ou atributos) que essas coisas podem ter
As ontologias s˜o figura proeminentes na Web Semˆntica, emergentes
a a
como uma forma de representar a semˆntica dos documentos, permitindo
a
que a semˆntica possa ser utilizada por aplica¸oes Web e agentes inteligentes.
a c˜
Ontologias podem revelar-se muito uteis para a comunidade como uma forma
´
de estruturar e definir o significado de termos, os metadados, que s˜o atual-
a
mente recolhidos e padronizados. Usando ontologias, as aplica¸˜es futuras
co
podem vir a ser ”inteligentes”, no sentido de que se possa trabalhar com mais
precis˜o a um n´ conceitual humano [W3C, 2011].
a ıvel
2.3.1 Reuso de ontologias
O reuso de ontologias ´ um ponto muito importante da Web semˆntica,
e a
pois garante a interoperabilidade de informa¸˜es entre contextos diferentes,
co
como explica Cantele(2009) ”O reuso de ontologias existentes ´ um ponto
e
cr´
ıtico na Web semˆntica pois cada vez mais ontologias est˜o surgindo e
a a
precisam ser adaptadas de um dom´ ınio para outro, ou estendidas na sua
abrangˆncia.”
e
A possibilidade de estender ontologias existentes tamb´m ´ interessante,
e e
pois permite que adapta¸˜es sejam realizadas, sem preju´ para a comu-
co ızo
nica¸˜o entre contextos e sem necessidade de reescrita da ontologia[Baldus, 2011].
ca
2.4 Web Ontology Language (OWL)
OWL ´ uma linguagem semˆntica, que ´ utilizada para publica¸˜o e com-
e a e ca
partilhamento de recursos semˆnticos. Seu objetivo ´ ser uma linguagem
a e
17

19. 2.4. Web Ontology Language (OWL) ufms
dispon´ para aplica¸˜es que n˜o ir˜o apenas exibir as informa¸˜es, mas que
ıvel co a a co
necessitem compreender o significado das informa¸˜es, seus relacionamentos
co
entre classes, disjun¸oes e metadados mais complexos dos que os suportados
c˜
pelo RDF. E ´ poss´ trabalhar com desigualdade ou igualdade de classes, re-
ıvel
stri¸oes de funcionalidades e caracter´
c˜ ısticas das propriedades[Baldus, 2011].
Para criar uma ontologia, s˜o informados os vocabul´rios espec´
a a ıficos que
devem ser utilizados, atrav´s de namespaces XML (xmlns), no in´
e ıcio da
defini¸ao da ontologia[Vanni, 2009]. O exemplo da figura 2.3 ilustra o uso de
c˜
namespaces em um arquivo OWL.
Figura 2.3: Declara¸ao de Namescapes[Vanni, 2009]
c˜
As linhas 2 e 3 apresentam a identifica¸ao da ontologia corrente. Ou
c˜
seja, se n˜o for utilizado nenhum prefixo namespaces nas declara¸oes de
a c˜
elementos da ontologia, deve ser compreendido como parte da ontologia
corrente. Da mesma forma, se for utilizado o prefixo ”rede”, que de-
fine o vocabul´rio da ontologia. Na linha 4, ´ definido que o names-
a e
pace XML ”acesso” ´ referˆncia para a ontologia definida no endere¸o,
e e c
”http://www.icmc.usp.br/ rporto/DOHand/OWL/acesso”, que n˜o possui a
o mesmo vocabul´rio da ontologia corrente[Vanni, 2009].
a
As outras declara¸˜es de namespaces (owl, rdf, rdfs e xsd), informam que
co
elementos que iniciem com o prefixo owl, rdf, rdfs e xsd, sejam compreen-
didos como defini¸˜es destes vocabul´rios, respectivamente vocabul´rio da
co a a
linguagem OWL, RDF, esquema RDF e XML esquema.
Realizadas as declara¸oes iniciais, ser´ observado que ”[...] a maioria dos
c˜ a
elementos em uma ontologia OWL trata de classes, propriedades, instˆncia a
de classes e relacionamento entre instˆncias.” [Vanni, 2009].
a
A principal superclasse da linguagem owl ´ owl:Thing, ou seja, ”[...] Tudo
e
que for declarado em OWL ´ membro da classe owl:Thing.”[Vanni, 2009]. As
e
declara¸oes s˜o realizadas no formato de tags XML e os principais constru-
c˜ a
tores est˜o representados no c´digo 1.
a o
18

20. 2.5. Resource Description Framework (RDF) ufms
Code 1 Classe OWL[Vanni, 2009]
01 <owl:Class rdf:ID="ClasseTeste">
02 o que estiver aqui dentro referencia a classe em questao
03 <rdfs:subClassOf rdf:recource=URI da superclasse/> Define heranca
04 </owl:Class>
05 ...
2.5 Resource Description Framework (RDF)
O uso de metadados sobre um recurso Web permite o conhecimento
de seu significado, caracter´ ısticas, uso, localiza¸˜o e relacionamento com
ca
outros recursos[Vanni, 2009]. Com isso em mente foi criado, pelo grupo
de trabalho de Web semˆntica da W3C o padr˜o RDF, com o intuito
a a
de descrever e representar os metadados relacionados a qualquer recurso
web[Berners-Lee & Hendler, 2001].
O Resource Description Framework(RDF) ´ um XML padr˜o para in-
e a
tercˆmbio de metadados, conforme elucida Oliveira(2002) ”Enquanto a
a
fun¸ao principal do metadado ´ descrever um documento atrav´s de atributos
c˜ e e
conferidos a um objeto, retratando as suas caracter´ ısticas como dimens˜o,
a
formato, autoria, localiza¸ao e outros com o objetivo de intercambiar dados,
c˜
o RDF ´ um grafo para descrever e intercambiar metadado.”
e
O conceito base no qual o RDF est´ fundamentado ´ o seu modelo de
a e
dados[Oliveira, 2002], que ´ composto por declara¸˜es a respeito dos recur-
e co
sos,contendo: a) Resource (Recurso) atributo que contem a identifica¸ao c˜
unica, normalmente utilizando Uniform Resource Identifier, b) Propriedade,
´
que ´ o conjunto de fonte com um nome que possui uma propriedade, e
e
c) Afirma¸ao, a uni˜o de uma fonte com propriedade e com a afirma¸˜o,
c˜ a ca
partes tamb´m conhecidas como assunto, predicado e afirma¸˜o. Com estes
e ca
metadados do RDF, podem ser identificadas outras informa¸˜es a respeito
co
dos dados e dos metadados[Baldus, 2011].
Um RDF segue a formata¸˜o b´sica do XML, contendo informa¸oes so-
ca a c˜
bre os dados e os metadados, sendo o ponto de partida para o modelo a ser
adotado pela web semˆntica, contendo apenas conceito sobre asser¸ao (asser-
a c˜
tion) e de ’quotation’ – criando asser¸˜es sobre asser¸oes, portanto necessita
co c˜
de implementa¸˜es e aplica¸˜es como convers˜o de linguagem, leis da l´gica,
co co a o
com o objetivo de imprimir l´gica aos documentos; predicado l´gico (not,
o o
and, or) e leis de quantifica¸ao (para todo x y (x))[Baldus, 2011].
c˜
No c´digo 2 temos um exemplo de XML, contendo informa¸˜es no formato
o co
RDF, dispon´ no site W3CSchools:
ıvel
19

21. 2.6. Dados abertos governamentais ufms
Code 2 C´digo RDF. Fonte:http://www.w3schools.com/rdf/default.asp
o
01 <?xml version="1.0"?>
02
03 <rdf:RDF
04 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
05 xmlns:si="http://www.w3schools.com/rdf/">
06
07 <rdf:Description rdf:about="http://www.w3schools.com">
08 <si:title>W3Schools</si:title>
09 <si:author>Jan Egil Refsnes</si:author>
10 </rdf:Description>
11
12 </rdf:RDF>
13 ...
2.6 Dados abertos governamentais
Dados Abertos Governamentais s˜o a publica¸ao e dissemina¸ao das in-
a c˜ c˜
forma¸oes do setor p´blico na Web, compartilhados em formato bruto e
c˜ u
aberto, compreens´ ıveis logicamente, de modo a permitir sua reutiliza¸ao em
c˜
aplica¸oes digitais desenvolvidas pela sociedade[W3C, 2011].
c˜
Uma outra defini¸ao por Breitman(2010), diz que ”Dados governamentais
c˜
abertos consistem na publica¸˜o de dados sobre informa¸oes p´blicas em
ca c˜ u
formatos que permitem o seu compartilhamento, acesso, descoberta e f´cil a
manipula¸˜o pelos consumidores desses dados”.
ca
Dados abertos governamentais s˜o regidos por trˆs leis b´sicas, conforme
a e a
Eaves(2009):
• Se o dado n˜o pode ser encontrado e indexado na Web, ele n˜o existe.
a a
• Se n˜o estiver aberto e dispon´
a ıvel em formato compreens´
ıvel por
m´quina, ele n˜o pode ser reaproveitado.
a a
• Se algum dispositivo legal n˜o permitir sua reaplica¸˜o, ele n˜o ´ util.
a ca a e´
Al´m das trˆs leis dos dados abertos governamentais, ainda h´ oito
e e a
princ´
ıpios b´sicos. Os dados para serem considerados dados abertos gov-
a
ernamentais devem ser (OPENGOVDATA.ORG, 2007):
1. Completos. Todos os dados p´blicos est˜o dispon´
u a ıveis. Dado p´blico ´
u e
o dado que n˜o est´ sujeito a limita¸oes v´lidas de privacidade, segu-
a a c˜ a
ran¸a ou controle de acesso.
c
20

22. 2.7. Princ´
ıpios de Linked Open Data ufms
2. Prim´rios. Os dados s˜o apresentados tais como os coletados na fonte,
a a
com o maior n´ poss´ de granularidade e sem agrega¸˜o ou modi-
ıvel ıvel ca
fica¸˜o.
ca
3. Atuais. Os dados s˜o disponibilizados t˜o rapidamente quanto necess´ria
a a a
a preserva¸ao do seu valor.
` c˜
4. Acess´
ıveis. Os dados s˜o disponibilizados para o maior alcance poss´
a ıvel
de usu´rios e para o maior conjunto poss´ de finalidades.
a ıvel
5. Compreens´ıveis por m´quinas. Os dados s˜o razoavelmente estrutura-
a a
dos de modo a possibilitar processamento automatizado.
6. N˜o discriminat´rios. Os dados s˜o dispon´
a o a ıveis para todos, sem
exigˆncia de requerimento ou cadastro.
e
7. N˜o propriet´rios. Os dados s˜o dispon´
a a a ıveis em formato sobre o qual
nenhuma entidade detenha controle exclusivo.
8. Livres de licen¸as. Os dados n˜o est˜o sujeitos a nenhuma restri¸˜o de
c a a ca
direito autoral, patente, propriedade intelectual ou segredo industrial.
Restri¸oes sensatas relacionadas ` privacidade, seguran¸a e privil´gios
c˜ a c e
de acesso s˜o permitidas.
a
Segundo Baldus(2011), ”[...] n˜o h´ obrigatoriedade de um formato para
a a
a disponibiliza¸˜o de dados, que pode ser em XML, CSV, RDF, ou in´meras
ca u
possibilidades, desde que respeitados os princ´
ıpios b´sicos.”
a
2.7 Princ´
ıpios de Linked Open Data
A Web tornou-se o principal meio de dissemina¸˜o de informa¸˜es digitais,
ca co
valendo-se especialmente da publica¸˜o e interliga¸ao de documentos e pos-
ca c˜
teriormente como poderoso canal de comunica¸˜o e relacionamento atrav´s
ca e
das redes sociais. Al´m disso, consolidou-se como front-end para acesso a
e
dados publicados dinamicamente atrav´s de aplica¸˜es especialmente desen-
e co
volvidas para este ambiente. No entanto, esses dados permanecem ainda em
silos, onde pouco ou nenhum compartilhamento e interliga¸ao de recursos s˜o
c˜ a
praticados. Como exemplo, tomemos a grande quantidade de dados governa-
mentais dispon´ ıveis na Web, gerados a partir das muitas iniciativas de e-gov
e open-government, que defendem a ampla divulga¸˜o de dados aos cidad˜os
ca a
e organiza¸oes.
c˜
No entanto, o consumo conjunto e reutiliza¸ao desses dados ainda ´ dif´
c˜ e ıcil,
dadas as suas interfaces voltadas apenas para consulta ou extra¸˜o ad-hoc,
ca
21

23. 2.7. Princ´
ıpios de Linked Open Data ufms
al´m dos altos custos e problemas envolvidos na an´lise de dados. Nesse sen-
e a
tido, as iniciativas de Linked Open Data (LOD) prop˜em o uso de padr˜es
o o
abertos, suportados pelo W3C, para exposi¸ao de dados na Web por meio de
c˜
princ´ıpios simples, inspirados no sucesso da ”Web de Documentos”, envol-
vendo padroniza¸ao da semˆntica por tr´s dos dados[LinkedDataBR, 2011].
c˜ a a
LOD usa tecnologias da Web Semˆntica para publicar dados estruturados
a
na Web e criar liga¸˜es entre dados de diferentes fontes de dados. Segundo
co
Tim Berners-Lee [Hendler, 2001], seus princ´ ıpios s˜o:
a
1. Usar URIs como nomes para recursos.
2. Usar URIs HTTP de forma que pessoas possam procurar por estes
nomes.
3. Quando algu´m procura uma URI, fornecer informa¸ao RDF util.
e c˜ ´
4. Incluir senten¸as RDF que ligam a outras URIs para que possam
c
descobrir outros recursos.
Berners-Lee (2006), discorre sobre estas regras, quando informa que
identificar as coisas com URIs (1o regra), ´ um princ´
e ıpio b´sico, n˜o da
a a
Linked Data, mas sim da Web semˆntica e ´ bem compreendida pela
a e
maioria das pessoas que utilizam esta tecnologia. Se n˜o utilizar o con-
a
junto de s´ ımbolos universais URI, n˜o pode ser caracterizada como web
a
semˆntica[Berners-Lee, 2006].
a
O uso de HTTP URIs (2o regra), tamb´m ´ amplamente compreendido.
e e
Por´m aqui h´ uma tendˆncia constante nas pessoas para inventar novos
e a e
esquemas URI, como LSIDs, XRIs e assim por diante, por v´rios motivos.
a
Normalmente, estes motivos n˜o envolvem querer concorrer com o estabele-
a
cido Domain Name System (DNS) para a delega¸˜o de autoridade, mas para
ca
construir algo sob controle separado[Berners-Lee, 2006].
A terceira regra, onde diz que se deve dar informa¸oes para a web so-
c˜
bre a URI em quest˜o tamb´m ´ seguida pela maioria das ontologias, mas,
a e e
por alguma raz˜o, n˜o ´ para alguns conjuntos de dados grandes. Pode-se,
a a e
ao procurar as propriedades e classes, encontrar dados e obter informa¸˜es co
a partir das ontologias RDF, RDFS e OWL, incluindo as rela¸˜es entre os
co
termos na ontologia. O formato b´sico aqui para disponibilizar estas in-
a
forma¸oes ´ RDF/XML. Grandes conjuntos de dados oferecem um servi¸o
c˜ e c
de consulta SPARQL Protocol and RDF Query Language (SPARQL), mas
os dados b´sicos devem ser fornecidos tamb´m[Berners-Lee, 2006].
a e
A quarta regra, que diz respeito a fazer liga¸˜es com dados em outros
co
lugares, implica na necessidade de ligar – sem limites – os dados que ex-
istem com a web, onde se pode encontrar todo tipo de coisa, assim como
constru´ ımos a Webhipertexto[Berners-Lee, 2006].
22

24. 2.8. SPARQL Protocol and RDF Query Language (SPARQL) ufms
2.8 SPARQL Protocol and RDF Query Lan-
guage (SPARQL)
SPARQL, que tem seu nome originado do acrˆnimo (em inglˆs) SPARQL
o e
Protocol and RDF Query Language, possui trˆs caracter´
e ısticas, sendo elas:
linguagem de consulta de triplas RDF, formato para os resultados e protocolo
de acesso[Breitman et al. , 2010].
SPARQL pode ser usada para expressar consultas em diversas fontes
de dados, se os dados s˜o armazenados nativamente como RDF ou visto
a
como RDF via middleware. Cont´m tamb´m recursos para consultar triplas
e e
padr˜es obrigat´rios e facultativos, juntamente com suas conjun¸˜es e dis-
o o co
jun¸oes, o valor extens´ de testes e restringindo as consultas pela fonte das
c˜ ıvel
triplas RDF[W3C, 2011].
Portanto segundo Baldus(2011), ”[...] SPARQL prop˜e uma forma de re-
o
alizar pesquisa em triplas RDF (por meio da linguagem de consulta) com fil-
tros e ordena¸oes, a´m de possibilitar que os resultados estejam num formato
c˜ e
padr˜o de resposta e permite o tr´fego desses dados pela web (utilizando o
a a
protocolo de acesso SPARQL). Com isso ´ poss˜ integrar bases de dados
e ivel
distintas que disponibilizem os dados em RDF.”
Como as consultas s˜o realizadas em triplas RDF, os resultados s˜o com-
a a
postos por uma tabela com trˆs colunas: sujeito, predicado e objeto, que s˜o
e a
os dados armazenados nas triplas RDF. E, valores de triplas RDF (sujeito,
predicado e objeto) podem ser referˆncias a outras informa¸˜es de objetos
e co
que possuem outro conjunto de triplas RDF[Cyganiak, 2005].
A linguagem SPARQL ser´ utilizada neste trabalho de forma simples e
a
objetiva, visando validar os dados publicados atrav´s de consultas sobre as
e
triplas em RDF que ser˜o armazenadas no servidor de triplas OPEN LINK
a
VIRTUOSO[Virtuoso, 2011].
23

25. Cap´
ıtulo 3
A Estrat´gia para Publica¸˜o
e ca
dos Dados
Uma vez que os objetivos espec´ ıficos foram alcan¸ados, a seguir ser˜o
c a
apresentados os resultados do desenvolvimento e implementa¸ao da estrat´gia
c˜ e
para publica¸ao dos dados da base de dados do CEB–INEP/MEC no padr˜o
c˜ a
Linked Open Data.
Para concep¸ao da estrat´gia proposta neste trabalho, partiu-se de um
c˜ e
conhecimento sobre o CEB adquirido durante o desenvolvimento de um tra-
balho de inicia¸˜o cient´
ca ıfica[Mota et al. , 2010] pertencente ao projeto Web–
PIDE, que demonstrou a falta de padr˜o no que se refere `s quest˜es for-
a a o
muladas para o censo ao longo dos anos. Esse cen´rio ocasiona grande di-
a
ficuldades ao se tentar reutilizar as mesmas estruturas de pesquisa em anos
diferentes, uma vez que as quest˜es sofrem grandes altera¸˜es ao longo dos
o co
anos. Desta forma o padr˜o Linked Open Data se mostra como uma pos-
a
sibilidade real para a solu¸ao deste problema, uma vez que este padr˜o se
c˜ a
caracteriza pela publica¸˜o de dados utilizando conceitos de Web semˆntica
ca a
atrav´s de triplas RDF e ontologias que descrevem clara e objetivamente os
e
dados.
Assim foi concebida a estrat´gia para a publica¸˜o de dados que parte da
e ca
carga dos microdados do INEP para tabelas de banco de dados, em seguida
essas tabelas foram avaliadas para cria¸ao de um modelo l´gico relacional
c˜ o
normalizado de banco de dados, que verificou–se ser pr´–requisito de entrada
e
das ferramentas STDTRIP e TRIPLIFY[Auer et al. , 2009], que foram con-
struidas para dar suporte ao processo de publica¸ao de dados no padr˜o
c˜ a
Linked Data. Sendo que a ferramenta STDTRIP desenvolvida na PUC-
Rio[Salas et al. , 2010b] visa a cria¸˜o e reuso de ontologias e a ferramenta
ca
TRIPLIFY que de fato implementa a triplifica¸˜o dos dados.
ca
24

26. 3.1. Etapas ufms
3.1 Etapas
Para a publica¸ao dos dados s˜o necess´rias etapas(6), na figura 3.1 estas
c˜ a a
etapas s˜o apresentadas de forma sequencial.
a
Figura 3.1: Etapas para publica¸˜o dos dados no padr˜o Linked Open Data
ca a
25

27. 3.2. Implementa¸ao da etapa de carga dos dados
c˜ ufms
Na etapa de carga dos dados (1) a base de dados do CEB utilizada neste
trabalho est´ no formato microdado[INEP, 2011]. Esses dados s˜o carregados
a a
para o SGBD PostgreSQL utilizando a ferramenta DEAR criada pela equipe
do projeto Web–PIDE/UFSCar.
Na etapa de normaliza¸˜o (2) foi desenvolvido um modelo de banco de
ca
dados normalizado, baseado na descri¸˜o das quest˜es da pesquisa do ano
ca o
de 1995, esse modelo tamb´m ´ traduzido para o Inglˆs, ambos s˜o pr´–
e e e a e
requisitos para utiliza¸˜o da ferramenta STDTRIP, que ser´ utilizada na
ca a
cria¸ao da ontologia e triplifica¸ao dos dados.
c˜ c˜
Na etapa de extra¸ao e carga para o modelo normalizado (3) foi desen-
c˜
volvida uma ferramenta na linguagem JAVA com o objetivo de recuperar os
dados que est˜o no banco PostgreSQL e inseri-los no banco Normalizado que
a
ser´ armazenado no SGBD MySQL.
a
Na etapa de cria¸˜o da ontologia (4) foi aplicada a ferramenta STDTRIP
ca
sob o banco de dados que esta no MySQL, que tem como sa´ ıdas a ontologia
em OWL dos dados e o arquivo de configura¸ao da ferramenta TRIPLIFY.
c˜
Na etapa de triplifica¸ao (5) foi utilizada a ferramenta TRIPLIFY para
c˜
a triplifica¸ao dos dados.
c˜
Na etapa de armazenamento das triplas (6), estas s˜o armazenadas no
a
servidor de triplas OPENLINK VIRTUOSO, que al´m de armazenar as
e
triplas fornece uma interface Web para consultas em SPARQL.
3.2 Implementa¸˜o da etapa de carga dos da-
ca
dos
A base de dados do CEB esta dispon´ no site do INEP para download
ıvel
dividida por ano de pesquisa, estes s˜o chamados de microdados e est˜o em
a a
formato ASCII, os microdados s˜o acompanhados de inputs, ou seja, canais
a
de entrada para leitura dos arquivos por meio da utiliza¸ao dos softwares SAS
c˜
e SPSS. Para que esses dados pudessem ser utilizados no projeto Web–PIDE
na constru¸˜o de Data Warehouses e neste trabalho j´ que a STDTRIP e o
ca a
TRIPLIFY utilizam os dados a partir de um Sistema de Gerenciamento de
Banco de Dados(SGBD) para a gera¸˜o das triplas em RDF, foi necess´rio
ca a
o carregamento desses dados em um SGBD, que no caso foi escolhido o
PostgreSQL.
Os microdados portanto s˜o formados pelo arquivo ASCII que cont´m
a e
os dados brutos, pelos arquivos de leitura SAS e SPSS e por um arquivo
em Portable document format(PDF) chamado de ”Leia-me”que apresenta as
caracter´
ısticas do dados do ano de pesquisa em quest˜o, como o significado
a
26

28. 3.2. Implementa¸ao da etapa de carga dos dados
c˜ ufms
dos dados e seu tipo(num´rico ou alfanum´rico)[INEP, 2011]. Na figura 3.2
e e
pode ser visto um exemplo do arquivo ”Leia-me”do ano de 1995.
27

29. 3.2. Implementa¸ao da etapa de carga dos dados
c˜ ufms
Figura 3.2: Parte do Arquivo ”Leia-me.pdf” do CEB de 1995[INEP, 2011]
28

30. 3.2. Implementa¸ao da etapa de carga dos dados
c˜ ufms
Na figura 3.3 ´ exibido um exemplo do arquivo ASCII e na figura 3.4 um
e
exemplo do arquivo SAS de leitura dos dados brutos.
Figura 3.3: Exemplo de arquivo ASCII, microdados de 1995
29

31. 3.2. Implementa¸ao da etapa de carga dos dados
c˜ ufms
Figura 3.4: Exemplo de arquivo SAS para leitura de dados, microdados de
1995
Para o carregamento desses dados no SGBD PostgreSQL foi desenvolvido
pela UFSCar[Siqueira, 2009], uma ferramenta entitulada Data Extractor
ASCII to Relational(DEAR), onde o usu´rio seleciona o arquivo de leitura e
a
o arquivo ASCII que cont´m os dados e a ferramenta se encarrega de gerar
e
os scripts SQL de insert no banco de dados. A arquitetura da ferramenta
pode ser melhor visualizada na figura 3.5.
30

32. 3.2. Implementa¸ao da etapa de carga dos dados
c˜ ufms
Figura 3.5: Arquitetura da ferramenta ata Extractor ASCII to Relational-
DEAR[Siqueira, 2009]
Uma vez carregada a base de dados do CEB, ela se caracteriza por tabelas
de banco de dados que correspondem a cada ano de avalia¸˜o e, em que
ca
cada tabela existem v´rias colunas que correspondem a cada quest˜o do
a a
question´rio aplicado `s institui¸oes de ensino. Para este estudo de caso se
a a c˜
escolheu a tabela que corresponde ao ano de 1995 por ser a que cont´m o e
menor n´mero de colunas (479) pois devido ao tamanho da base e a falta de
u
padroniza¸˜o ao longo dos anos de pesquisa no que se refere aos question´rios
ca a
[Mota et al. , 2010], seria muito dispendioso estender este trabalho a todos
os anos presentes na base de dados. Cada coluna da tabela ´ nomeada com
e
um c´digo que corresponde ao seu c´digo apresentado no arquivo ”Leia-
o o
me”apresentado anteriormente, portanto se desejarmos saber o significado
de uma coluna em especial ´ necess´rio consultar o arquivo ”Leia-me”.
e a
31

33. 3.3. Implementa¸ao da etapa de normaliza¸˜o
c˜ ca ufms
3.3 Implementa¸˜o da etapa de normaliza¸˜o
ca ca
Apresentado a etapa 1, o pr´ximo passo ´ normalizar a tabela do banco
o e
de dados que armazena os dados de 1995. A seguir ´ demonstrado o modelo
e
em que a tabela se encontrava. Podemos ver a seguir parte do script em
Structured Query Language (SQL) de cria¸˜o da tabela:
ca
Code 3 Parte do script de cria¸˜o da tabela do CEB que armazena os dados
ca
do ano de 1995.
01 CREATE TABLE ceb1995_censoesc
02 (
03 mascara character varying(10) NOT NULL,
04 co_ibge character varying(14),
05 nu_ano integer,
06 uf character varying(50),
07 sigla character varying(2),
08 munic character varying(50),
09 dep character varying(10),
10 loc character varying(10),
11 codfunc character varying(11),
12 nivelpre character varying(1),
13 niv_1grau character varying(1),
14 niv_2grau character varying(1),
15 enssuplet character varying(1),
16 permanen integer,
17 noestab integer,
18 provisor integer,
19 foraesta integer,
20 funcion integer,
21 profess integer,
22 vpe1001 integer,
23 vpe1002 integer,
24 ...
Observando o exemplo acima, at´ a linha 15 temos as colunas que ar-
e
mazenam dados descritivos, de tipo alfan´merico, a partir de ”permanen”,
u
ou seja, na linha 16 se iniciam as colunas do tipo n´mericas. A partir disso
u
foi proposto o primeiro modelo da base de dados normalizada, d´ısponivel na
figura 3.6. Esse modelo foi construido baseado nas colunas do tipo descriti-
vas, a priori, as colunas do tipo n´merica seriam inseridas todas na tabela
u
32

34. 3.3. Implementa¸ao da etapa de normaliza¸˜o
c˜ ca ufms
”census”, mas ao aplicar a ferramenta STDTRIP(mais ` frente a ferramenta
a
STDTRIP ser´ melhor explicada) a este modelo os resultados com rela¸˜o `
a ca a
reutiliza¸ao de termos das ontologias padr˜es da Web(ontologias em grande
c˜ o
escala de uso) se mostrou ineficiente, isto evidenciou a superficialidade deste
modelo, portanto seria necess´rio um modelo normalizado muito mais con-
a
sistente para que o projeto obtivesse o sucesso esperado.
Figura 3.6: 1o Modelo normalizado criado
Uma vez que as colunas do tipo alfan´merico j´ haviam sido estudadas e
u a
normalizadas, as colunas n´mericas passaram a ser analisadas para a cria¸˜o
u ca
do novo modelo, at´ que se chegou a seguinte proposta:
e
As quest˜es do CEB do tipo num´ricas possuem alguns padr˜es, por
o e o
exemplo:
• Docentes no pr´-escolar com capacita¸˜o e 1o grau completo
e ca
• Docentes de 1o a 4o s´rie com capacita¸˜o e magist´rio com-
e ca e
pleto
• Docentes no 2o grau com magist´rio completo
e
Essas quest˜es est˜o relacionadas ao n´mero de docentes de uma deter-
o a u
minada institui¸˜o de ensino, onde contˆm alguns adjetivos que ´ o tipo de
ca e e
ensino ministrado e sua forma¸ao, a partir deste exemplo ´ poss´ visualizar
c˜ e ıvel
um relacionamento entre duas entidades de banco de dados, no caso, ”tipo de
33

35. 3.3. Implementa¸ao da etapa de normaliza¸˜o
c˜ ca ufms
ensino” e ”forma¸ao do professor” ambas relacionadas por ”docente”. Esse
c˜
esquema pode ser visualizado na figura 3.7.
Figura 3.7: Exemplo de normaliza¸ao das colunas n´mericas
c˜ u
Analisadas todas as colunas num´ricas, foram identificadas as entidades
e
de relacionamento a seguir:
• EducationCityData – Armazena e relaciona dados referentes ao mu-
nic´
ıpio, como unidade federativa, n´mero de funcion´rios e n´mero de
u a u
docentes.
• EducationCity – Armazena e relaciona dados referentes a educa¸˜o
` ca
no munic´
ıpio, como o tipo de ensino oferecido.
• Teacher – Armazena e relaciona dados referentes aos docentes, como
sua forma¸ao e capacita¸ao.
c˜ c˜
• Class – Armazena e relaciona dados referentes as turmas, como s´rie
` e
e per´
ıodo.
• Enrollment – Armazena e relaciona dados referentes a matr´
` ıculas,
como quantidade de matriculas por s´rie e per´
e ıodo.
• RemovedByDesertion – Armazena e relaciona dados referentes aos
estudantes afastados por abandono.
• Approved – Armazena e relaciona dados referentes aos alunos aprova-
dos.
• Repeater – Armazena e relaciona dados referentes aos alunos repe-
tentes.
• CitySchoolZone – Armazena e relaciona dados referentes ` zona(rural
a
ou urbana) escolar do munic´
ıpio.
34

36. 3.3. Implementa¸ao da etapa de normaliza¸˜o
c˜ ca ufms
• CityAdministrativeDependence – Armazena e relaciona dados ref-
erentes a dependˆncia administrativa da institui¸˜o de ensino.
` e ca
• RemovedbyTransfer – Armazena e relaciona dados referentes aos
alunos afastados por transferˆncia.
e
• Graduate – Armazena e relaciona dados referentes aos alunos aprova-
dos.
• CityWorkingCondition – Armazena e relaciona dados referentes a
`
condi¸ao de trabalho da institui¸ao.
c˜ c˜
Desta forma, na figura 3.8 ´ apresentado o novo modelo relacional nor-
e
malizado, j´ com os nomes das entidades e seus atributos traduzidos para o
a
Inglˆs conforme requisito para a interoperabilidade de ontologias atrav´s da
e e
ferramenta STDTRIP que ser´ explicado na etapa 4.
a
35

37. 3.3. Implementa¸ao da etapa de normaliza¸˜o
c˜ ca ufms
Figura 3.8: 2o Modelo relacional normalizado
36

38. 3.4. Implementa¸ao da etapa de extra¸˜o e carga para o modelo
c˜ ca
normalizado ufms
3.4 Implementa¸˜o da etapa de extra¸˜o e
ca ca
carga para o modelo normalizado
Uma vez criado o modelo da base de dados era necess´rio a carga dos
a
dados no novo modelo, para este processo foi desenvolvida uma ferramenta
entitulada Data Extractor PostgreSQL to MySQL(DEPOM) com o objetivo
de acessar a tabela do CEB de 1995 no PostgreSQL, recuperar os dados e
inseri–los no novo modelo instanciado no MySQL, de acordo com as regras
de relacionamento entre as entidades. Esta ferramenta foi desenvolvida em
JAVA e faz parte deste trabalho para a obten¸ao dos resultados esperados.
c˜
Na imagem a seguir ´ representado a ordem de execu¸ao da ferramenta e
e c˜
de carga dos dados nas tabelas do modelo normalizado.
Figura 3.9: Ordem de Execu¸ao da DEPOM
c˜
3.5 Implementa¸˜o da etapa de cria¸˜o da
ca ca
ontologia
Um esquema de banco de dados ´ uma descri¸˜o de alto n´ de como
e ca ıvel
conceitos de banco de dados s˜o organizados, geralmente como um con-
a
junto de classes de objetos e seus atributos. Triplification ´ o processo pelo
e
qual um banco de dados e sua estˆncias s˜o transformados em um conjunto
a a
de dados RDF. Isto ´ feito mapeando conceitos de bancos de dados para
e
uma ontologia, para ser utilizado como base para se gerar as triplas RDF.
37

39. 3.5. Implementa¸ao da etapa de cria¸˜o da ontologia
c˜ ca ufms
A constru¸ao desta ontologia ´ extremamente importante porque quanto
c˜ e
mais se utiliza padr˜es, mais f´cil ser´ para interligar com dados de out-
o a a
ras bases. A maioria das ferramentas de triplifica¸˜o hoje d˜o apoio ao
ca a
processo mecˆnico de transforma¸˜o dos dados existentes. No entanto, nen-
a ca
huma fornece suporte ao usu´rio durante a fase de modelagem conceitual.
a
Para dar suporte ao usu´rio neste processo foi desenvolvido pela PUC-Rio
a
a ferramenta STDTRIP [Salas et al. , 2010b], se poss´ a ferramenta pro-
ıvel
move a reutiliza¸˜o de padr˜es da W3C para cria¸ao de ontologias, ou sugere
ca o c˜
o reaproveitamento de ontologias j´ adotadas por outros conjuntos de dados
a
RDF.
3.5.1 Processo STDTRIP
A arquitetura do processo da STDTRIP se divide em 6 etapas sequenciais:
Conversion, Alignment, Selection, Inclusion, Completion e Output. Sendo
que as etapas de Inclusion e Completion n˜o s˜o obrigat´rias, conforme pode
a a o
ser visto na figura 3.10.
Figura 3.10: Arquitetura STDTRIP[Salas et al. , 2010b]
• Conversion: Esta etapa consiste em transformar a estrutura do banco
de dados relacional em uma ontologia RDF. Nesta fase, o usu´rio se-
a
leciona manualmente quais partes do conjuntos de dados devem ser
utilizados para a gera¸ao das triplas em RDF.
c˜
• Alignment: Esse passo usa o K-MATCH, ferramenta de alinhamento
de ontologias para comparar com a ontologia obtida na etapa anterior
com um conjunto de ontologias padr˜o. O processo de alinhamento
a
considera o esquema da ontologia previamente obtida como o esquema
de origem para ser recursivamente alinhado com cada termo que repre-
senta a ontologia padr˜o. Essas ontologias s˜o o alvo e cada resultado
a a
no alinhamento ´ alocada para cada termo. Eventualmente, os resul-
e
tados s˜o apresentados como sugest˜es para cada, ou seja, para cada
a o
38

40. 3.5. Implementa¸ao da etapa de cria¸˜o da ontologia
c˜ ca ufms
elemento do esquema (tabela ou atributo) uma lista de poss´
ıveis com-
bina¸˜es ´ apresentado.
co e
• Selection: Esta etapa apresenta ao usu´rio uma lista de possibilidades
a
do que ele ou ela pode selecionar como o elemento do vocabul´rio que
a
melhor representa cada conceito na base de dados. Na figura 3.11 ´ e
exibido mais claramente os passos Conversion, Alignment e Selection.
Figura 3.11: Sequˆncia dos passos[Salas et al. , 2010b]
e
• Inclusion: Se, para um determinado elemento, o processo n˜o pro- a
duz nenhum resultado (n˜o h´ nenhum elemento nas ontologias padr˜o
a a a
que coincide com o conceito do banco de dados), ou nenhuma das sug-
est˜es na lista ´ considerado adequado por parte do usu´rio, STDTRIP
o e a
fornece uma lista de termos de outros vocabul´rios que poderia ser uma
a
poss´ıvel correspondˆncia. Isso ´ feito usando Watson, uma interface
e e
Web para a busca semˆntica de ontologias e documentos utilizando
a
palavras-chave. O racioc´ ınio ´ o seguinte ”se o seu conceito n˜o est´
e a a
abrangido por qualquer dos padr˜es conhecidos, olhar em volta e ver
o
como outras pessoas lidaram com isso. Ao escolher uma ontologia j´ em
a
uso, vocˆ ir´ tornar mais f´cil interligar o seu vocabul´rio, no futuro,
e a a a
do que pela cria¸˜o de uma nova ontologia.”
ca
39

41. 3.5. Implementa¸ao da etapa de cria¸˜o da ontologia
c˜ ca ufms
• Completion: Para os termos em que n˜o foi encontrado nenhuma cor-
a
respondˆncia, os usu´rios s˜o informados das melhores pr´ticas para a
e a a a
publica¸˜o de novas ontologias.
ca
• Output: A ferramenta gera dois arquivos de sa´ıda: (1)um arquivo de
configura¸ao, que ´ utilizado pela ferramenta TRIPLIFY que triplica
c˜ e
os dados em triplas.(2) Uma ontologia que cont´m os mapeamentos
e
do esquema do banco de dados original para uma ontologia no padr˜o
a
RDF.
3.5.2 Aplica¸˜o da STDTRIP
ca
Com todos os requisitos satisfeitos para a utiliza¸˜o da STDTRIP, a
ca
aplica¸ao da mesma na base de dados normalizada e carregada ofereceu os
c˜
resultados esperados pela ferramenta: a ontologia dos dados e o arquivo
de configura¸ao da ferramenta TRIPLIFY respectivamente apresentados no
c˜
c´digo 4 e 5.
o
Code 4 Parte da Ontologia Criada pela STDTRIP no Formato OWL/RDF.
01 <?xml version="1.0" encoding="ISO-8859-1"?>
02 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
03 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
04 xmlns:owl="http://www.w3.org/2002/07/owl#"
05 xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
06 xmlns:ceb="http://purl.org/education/ceb#"
07 xmlns:dbpedia="http://dbpedia.org/ontology/"
08 xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#"
09 xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
10 xmlns:dc="http://purl.org/dc/elements/1.1/">
11
12 <rdfs:Class rdf:about="http://purl.org/education/ceb#AdministrativeDependence"
13 <rdfs:label xml:lang="en">AdministrativeDependence</rdfs:label>
14 <rdfs:comment xml:lang="en"> administrative dependence</rdfs:comment>
15 </rdfs:Class>
16
17 <rdfs:Class rdf:about="http://purl.org/education/ceb#Approved">
18 <rdfs:label xml:lang="en">Approved</rdfs:label>
19 <rdfs:comment xml:lang="en">stores data of students approved</rdfs:comment>
20 </rdfs:Class>
21 ...
40

42. 3.6. Implementa¸ao da etapa de triplifica¸˜o
c˜ ca ufms
Code 5 Parte do Arquivo de Configura¸˜o do TRIPLIFY.
ca
01 ...
02 $triplify[’namespaces’]=array(
03 "rdf" => "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
04 "rdfs" => "http://www.w3.org/2000/01/rdf-schema#",
05 "owl" => "http://www.w3.org/2002/07/owl#",
06 "xsd" => "http://www.w3.org/2001/XMLSchema#",
07 "dbpedia" => "http://dbpedia.org/ontology/",
08 "ceb" => "http://purl.org/education/ceb#",
09 "dcterms" => "http://purl.org/dc/terms/",
10 "vcard" => "http://www.w3.org/2006/vcard/ns#",
11 "geo" => "http://www.w3.org/2003/01/geo/wgs84_pos#",
12 "school" => "http://education.data.gov.uk/ontology/school#",
13
14 );
15
16 $triplify[’classMap’]=array(
17 "AdministrativeDependence" => "dbpedia:AdministrativeRegion",
18 "Approved" => "ceb:Approved",
19 "ApprovedParticularity" => "ceb:ApprovedParticularity",
20 ...
3.6 Implementa¸˜o da etapa de triplifica¸˜o
ca ca
A ferramenta TRIPLIFY[Auer et al. , 2009], tem como objetivo explorar
a estrutura de dados em um banco de dados relacional, por tr´s de aplica-
a
tivos Web, para criar representa¸oes semˆnticas na Web[Baldus, 2011]. Ou
c˜ a
seja, com a ferramenta TRIPLIFY, ´ poss´
e ıvel acessar uma base de dados
relacional, e gerar as triplas RDF, que podem ser entendidas como repre-
senta¸oes semˆnticas. A maioria das aplica¸oes Web possuem banco de da-
c˜ a c˜
dos relacionais, por´m estes dados n˜o est˜o dispon´
e a a ıveis para pesquisa nos
motores de busca ou outras aplica¸˜es semˆnticas.
co a
3.6.1 Aplica¸˜o do TRIPLIFY
ca
A ferramenta necessita que todo o diret´rio TRIPLIFY esteja dentro de
o
outro diret´rio com servidor Web ativo. Com o arquivo de configura¸ao ger-
o c˜
ado pela ferramenta STDTRIP, a gera¸ao das triplas se tornou um processo
c˜
relativamente simples, bastando apenas inserir o arquivo na pasta de arquivos
41

43. 3.7. Implementa¸ao da etapa de armazenamento das triplas
c˜ ufms
da ferramenta. Para executar a ferramenta ´ necess´rio acessar o endere¸o
e a c
http://host/triplify, e ser´ gerado um arquivo com os dados em quest˜o.
a a
Ap´s triplificado o banco de dados, foi gerado um arquivo as triplas RDF
o
do tamanho de 1.1 gigabytes.
3.7 Implementa¸˜o da etapa de armazena-
ca
mento das triplas
OPENLINK VIRTUOSO[Virtuoso, 2011] ´ um middleware e sistema
e
gerenciador de banco de dados que combina a funcionalidades de um banco
de dados convencional com banco de dados RDF. Tamb´m pode ser utilizado
e
como um servidor de aplica¸ao para servi¸os Web[LinkedDataBR, 2011].
c˜ c
Para carga do arquivo RDF com as triplas geradas na etapa anterior, foi
utilizado o m´dulo ”isql” do OPENLINK VIRTUOSO, este m´dulo oferece
o o
uma interface Web para execu¸˜o de comandos. O comando utilizado em
ca
quest˜o pode ser visualizado no c´digo 6.
a o
Code 6 Comando para carregar arquivo RDF no servidor OPENLINK VIR-
TUOSO.
ld_dir_all(’/root/local/RDF/CEB.rdf’, ’*.*’, ’http://purl.org/education/ceb’);
O servidor tamb´m oferece um interface Web para consultas em SPARQL,
e
essas interfaces normalmente s˜o chamadas de SPARQLEndPoint. O servi-
a
dor pode ser acessado pelo endere¸o http://webpide.ledes.net:8890 e o
c
m´dulo SPARQLEndPoint em http://webpide.ledes.net:8890/sparql. Na
o
figura 3.12 ´ exibida a interface principal do servidor para intera¸˜o dos
e ca
usu´rios.
a
42

44. 3.7. Implementa¸ao da etapa de armazenamento das triplas
c˜ ufms
Figura 3.12: Servidor OPENLINK VIRTUOSO
43

45. Cap´
ıtulo 4
Conclus˜o
a
Neste cap´ıtulo ser˜o apresentados os principais resultados alcan¸ados ao
a c
t´rmino deste trabalho, al´m das dificuldades encontradas e sugest˜es de
e e o
trabalhos futuros.
4.1 Contribui¸oes do trabalho
c˜
Este trabalho teve como objetivo principal demonstrar uma estrat´gia de
e
publica¸˜o dos dados do CEB do ano de 1995, estrat´gia esta apresentada nos
ca e
cap´
ıtulos anteriores. A seguir ´ apresentado um exemplo de consulta sobre
e
os dados triplificados e na figura 4.1 o resultado da consulta. Esta consulta
apresenta o n´mero de funcion´rios e professores por cidade no estado de
u a
Mato Grosso do Sul.
Code 7 Exemplo de Consulta em SPARQL.
01 SELECT distinct ?s ?Cidade ?NumeroFuncionarios ?NumeroProfessores WHERE
02 {
03 ?s a <http://purl.org/education/ceb#EducationCityData>;
04 <http://dbpedia.org/ontology/city> ?Cidade;
05 <http://dbpedia.org/ontology/numberOfStaff> ?NumeroFuncionarios;
06 <http://purl.org/education/ceb#numberOfTeachers> ?NumeroProfessores;
07 <http://dbpedia.org/ontology/state> ?s1.
08 ?s1 <http://dbpedia.org/ontology/abbreviation> ?o.
09 FILTER regex(?o, "MS")
10 }
11 ...
44

46. 4.1. Contribui¸oes do trabalho
c˜ ufms
Figura 4.1: Exemplo de consulta sobre os dados triplicados do CEB do ano
de 1995
Em uma outra perspectiva, posso citar que este trabalho foi muito en-
riquecedor tecnicamente desde de a sua elabora¸˜o, que iniciou–se no III Con-
ca
gresso Internacional de Software Livre e Governo Eletrˆnico (CONSEGI),
o
atrav´s de um mini–curso de dados abertos governamentais realizado pela
e
equipe de Web semˆntica do departamento de inform´tica da Pontif´ Uni-
a a ıcia
versidade Cat´lica do Rio de Janeiro (PUC-Rio), de onde pude verificar as
o
correla¸oes do tema Dados Abertos Governamentias com a inicia¸˜o cient´
c˜ ca ıfica
que desenvolvia na ´poca. Para a realiza¸ao dos estudos em conjunto com a
e c˜
equipe da PUC-Rio foram utilizadas ferramentas de comunica¸˜o que permi-
ca
tiram o compartilhamento de materiais, conhecimento e ideias para a cron-
cretiza¸ao efetiva da estrat´gia definida e implementada neste trabalho.
c˜ e
Uma outra contribui¸˜o foi a apresenta¸˜o deste trabalho no IV Congresso
ca ca
Internacional de Software Livre e Governo Eletrˆnico (CONSEGI), cujo tema
o
era ”Censo Escolar Brasileiro INEP/MEC: Normaliza¸ao, Interoperabilidade
c˜
e Triplifica¸ao dos Dados em RDF”. Durante esta apresenta¸ao surgiu a opor-
c˜ c˜
45

47. 4.2. Dificuldades encontradas ufms
tunidade de um contato maior justamente com os servidores do INEP que s˜o a
os respons´veis pela elabora¸ao, aplicaca¸ao e disponibiliza¸ao dos dados do
a c˜ c˜ c˜
CEB. Este contato permitiu que a estrat´gia apresentada pudesse ser avaliada
e
por quem de direito pode avaliar as reais possibilidades de implementa¸˜oca
da estrat´gia criada neste trabalho. Vale ressaltar que este primeiro con-
e
tato serviu para que novos canais de comunica¸ao entre a UFMS e o INEP
c˜
pudessem ser vislumbrados.
4.2 Dificuldades encontradas
Este trabalho utilizou a base de dados do CEB, uma base de tamanho
consider´vel o que tornou o desenvolvimento dos objetivos algo dispendioso
a
de tempo e `s vezes de hardware. Outro fator de dificuldade foi a necessi-
a
dade de tradu¸ao do modelo normalizado do banco de dados utilizado neste
c˜
trabalho, que por muitas vezes sofreu altera¸˜es o que por conta de seu
co
tamanho tamb´m ocasionava a utiliza¸˜o de grandes partes de tempo na sua
e ca
atualiza¸ao.
c˜
Embora a troca de conhecimentos com a equipe da PUC-Rio tenha sido
muito satisfat´ria, o trabalho foi desenvolvido em grande parte a distˆncia.
o a
E apesar de vivenciarmos uma grande onda de comunica¸ao, o trabalho lado
c˜
a lado ainda ´ a melhor forma de trocar informa¸oes.
e c˜
4.3 Trabalhos futuros
Este trabalho buscou servir de motiva¸˜o para que mais bases de dados
ca
do INEP, e consequentemente governamentais sejam publicados no formato
de Linked Open Data, desta forma a seguir s˜o listadas algumas sugest˜es
a o
de trabalhos futuros:
• Extender este trabalho aos outros anos da base de dados do CEB.
• Estudar outras estrat´gias de publica¸˜o de dados no formato Linked
e ca
Open Data.
• Cria¸ao de Marshups, que s˜o aplica¸˜es Web que produzem in-
c˜ a co
forma¸oes aos usu´rios utilizando dados de fontes distintas.
c˜ a
• Continuar este trabalho para que de fato as triplas do CEB sejam
ligadas as outros reposit´rios de triplas.
o
• Estudar e implementar uma estrat´gia de publica¸˜o de dados no for-
e ca
mato Linked Data a partir de um Data Warehouse.
46

48. Anexo A
Modelo Normalizado do
CEB/1995
47

49. ufms
Figura A.1:
48

50. ufms
Figura A.2:
49